第1章  數據倉庫簡介 1
1.1  什麼是數據倉庫 1
1.1.1  數據倉庫的定義 2
1.1.2  建立數據倉庫的原因 3
1.2  操作型繫統與分析型繫統 5
1.2.1  操作型繫統 5
1.2.2  分析型繫統 7
1.2.3  操作型繫統和分析型繫統的對比 8
1.3  抽取—轉換—裝載 10
1.3.1  數據抽取 10
1.3.2  數據轉換 12
1.3.3  數據裝載 13
1.3.4  開發ETL繫統的方法 13
1.4  數據倉庫架構 14
1.4.1  基本架構 14
1.4.2  主要數據倉庫架構 15
1.4.3  操作型數據存儲 19
1.5  實時數據倉庫 19
1.5.1  流式處理 20
1.5.2  實時計算 21
1.5.3  實時數據倉庫解決方案 24
1.6  小結 26
第2章  數據倉庫設計基礎 27
2.1  關繫數據模型 27
2.1.1  關繫數據模型中的結構 27
2.1.2  關繫完整性 30
2.1.3  關繫數據庫語言 31
2.1.4  規範化 32
2.1.5  關繫數據模型與數據倉庫 34
2.2  維度數據模型 36
2.2.1  維度數據模型建模過程 36
2.2.2  維度規範化 37
2.2.3  維度數據模型的特點 38
2.2.4  星型模式 39
2.2.5  雪花模式 41
2.3  Data Vault模型 43
2.3.1  Data Vault模型簡介 43
2.3.2  Data Vault模型的組成部分 43
2.3.3  Data Vault模型的特點 45
2.3.4  Data Vault模型的構建 45
2.3.5  Data Vault模型實例 46
2.4  數據集市 50
2.5  數據倉庫實施步驟 51
2.6  小結 54
第3章  Greenplum與數據倉庫 55
3.1  Greenplum簡介 55
3.1.1  歷史與現狀 55
3.1.2  MPP——一切皆並行 56
3.2  Greenplum繫統架構 57
3.2.1  Greenplum與PostgreSQL 57
3.2.2  Master 58
3.2.3  Segment 58
3.2.4  Interconnect 59
3.3  Greenplum功能特性 59
3.3.1  存儲模式 59
3.3.2  事務與並發控制 63
3.3.3  並行查詢 69
3.3.4  並行數據裝載 72
3.3.5  冗餘與故障轉移 73
3.3.6  數據庫統計 76
3.4  為什麼選擇Greenplum 79
3.4.1  Greenplum還是SQL-on-Hadoop 79
3.4.2  適合DBA的解決方案 82
3.4.3  Greenplum的局限 86
3.5  小結 87
第4章  Greenplum安裝部署 88
4.1  平臺需求 88
4.1.1  操作繫統 88
4.1.2  硬件和網絡 89
4.1.3  文件繫統 90
4.2  容量評估 90
4.2.1  可用磁盤空間 91
4.2.2  用戶數據容量 91
4.2.3 &nb數據和日志空間 92
4.2.4  RAID劃分實踐 92
4.3  操作繫統配置 93
4.3.1  安裝操作繫統 94
4.3.2  禁用SELinux和防火牆 95
4.3.3  操作繫統推薦配置 95
4.3.4  時鐘同步 99
4.3.5  創建Greenplum管理員賬號 100
4.3.6  安裝JDK（可選） 101
4.4  安裝Greenplum軟件 101
4.4.1  安裝軟件包 101
4.4.2  配置免密SSH 102
4.4.3  確認軟件安裝 103
4.5  初始化Greenplum數據庫繫統 103
4.5.1  創建數據存儲區 103
4.5.2  驗證繫統 104
4.5.3  初始化數據庫 106
4.5.4  設置Greenplum環境變量 108
4.6  允許客戶端連接 109
4.7  修改Greenplum配置參數 110
4.8  後續步驟 112
4.8.1  創建臨時表空間 112
4.8.2  創建數據庫用戶 113
4.9  Greenplum升級 114
4.9.1  升級條件 114
4.9.2  升級步驟 114
4.10  小結 114
第5章  實時數據同步 116
5.1  數據抽取方式 116
5.1.1  基於源數據的CDC 117
5.1.2  基於觸發器的CDC 118
5.1.3  基於快照的CDC 119
5.1.4  基於日志的CDC 119
5.2  MySQL數據復制 120
5.2.1  復制的用途 121
5.2.2  二進制日志binlog 121
5.2.3  復制的步驟 122
5.3  使用Kafka 124
5.3.1  Kafka基本概念 124
5.3.2  Kafka消費者與分區 127
5.4  選擇主題分區數 129
5.4.1  使用單分區 129
5.4.2  如何選定分區數量 131
5.5  Maxwell Kafka Bireme 132
5.5.1  總體架構 132
5.5.2  Maxwell安裝配置 135
5.5.3  Bireme安裝配置 137
5.5.4  如何保證數據的順序消費 141
5.5.5  實時CDC 142
5.6  Canal Server Kafka Canal ClientAdapter 148
5.6.1  總體架構 148
5.6.2  Canal Server安裝配置 150
5.6.3  Canal ClientAdapter安裝配置 152
5.6.4  配置HA模式 154
5.6.5  實時CDC 157
5.6.6  消費延遲監控 158
5.7  小結 161
第6章  實時數據裝載 162
6.1  建立數據倉庫示例模型 163
6.1.1  業務場景 163
6.1.2  建立數據庫表 165
6.1.3  生成日期維度數據 173
6.2  初始裝載 173
6.2.1  數據源映射 174
6.2.2  確定SCD處理方法 174
6.2.3  實現代理鍵 175
6.2.4  執行初始裝載 175
6.3  實時裝載 178
6.3.1  識別數據源與裝載類型 178
6.3.2  配置增量數據同步 179
6.3.3  在Greenplum中創建規則 180
6.3.4  啟動實時裝載 183
6.3.5  測試 184
6.4  動態分區滾動 187
6.5  小結 189
第7章  維度表技術 190
7.1  增加列 190
7.2  維度子集 197
7.3  角色扮演維度 200
7.4  層次維度 205
7.4.1  固定深度的層次 205
7.4.2  多路徑的層次 207
7.4.3  參差不齊的層次 209
7.5  退化維度 211
7.6  雜項維度 215
7.7  維度合並 220
7.8  分段維度 225
7.9  小結 230
第8章  事實表技術 231
8.1  事實表概述 231
8.2  周期快照 232
8.3  累積快照 236
8.4  無事實的事實表 245
8.5  遲到的事實 248
8.6  累積度量 256
8.7  小結 262
第9章  Greenplum運維與監控 263
9.1  權限與角色管理 263
9.1.1  Greenplum中的角色與權限 263
9.1.2  管理角色及其成員 264
9.1.3  管理對像權限 266
9.1.4  口令加密 267
9.2  數據導入導出 268
9.2.1  file://協議及其外部表 268
9.2.2  gpfdist及其外部表 270
9.2.3  基於Web的外部表 271
9.2.4  外部表錯誤處理 274
9.2.5  使用gpload導入數據 274
9.2.6  使用COPY互拷數據 276
9.2.7  導出數據 278
9.2.8  格式化數據文件 280
9.3  性能優化 281
9.3.1  常用優化手段 281
9.3.2  控制溢出文件 283
9.3.3  查詢剖析 283
9.4  例行監控 287
9.4.1  檢查繫統狀態 287
9.4.2  檢查磁盤空間使用 289
9.4.3  檢查數據分布傾斜 290
9.4.4  查看數據庫數據信息 292
9.4.5  查看會話的內存使用信息 292
9.4.6  查看工作文件使用信息 293
9.4.7  查看服務器日志文件 293
9.5  例行維護 296
9.5.1  定期VACUUM 296
9.5.2  定期維護繫統目錄 297
9.5.3  加強的繫統目錄維護 297
9.5.4  為查詢優化執行VACUUM與ANALYZE 298
9.5.5  自動收集統計信息 299
9.5.6  重建索引 299
9.5.7  管理數據庫日志文件 299
9.6  推薦的監控與維護任務 300
9.6.1  數據庫實例狀態監控 300
9.6.2  硬件和操作繫統監控 301
9.6.3  繫統目錄表監控 302
9.6.4  數據庫維護 302
9.6.5  補丁與升級 303
9.7  小結 304
第10章  集成機器學習庫MADlib 305
10.1  MADlib的基本概念 305
10.1.1  MADlib是什麼 305
10.1.2  MADlib的設計思想 306
10.1.3  MADlib的工作原理 307
10.1.4  MADlib的執行流程 308
10.1.5  MADlib的基礎架構 308
10.2  MADlib的功能 309
10.2.1  MADlib支持的模型類型 309
10.2.2  MADlib主要的功能模塊 310
10.3  MADlib的安裝與卸載 313
10.3.1  確定安裝平臺 313
10.3.2  安裝MADlib 314
10.3.3  卸載MADlib 315
10.4  MADlib示例——使用矩陣分解實現用戶推薦 316
10.4.1  低秩矩陣分解 316
10.4.2  奇異值分解 325
10.5  模型評估 339
10.5.1  交叉驗證 340
10.5.2  MADlib的交叉驗證相關函數 342
10.5.3  交叉驗證示例 344
10.6  小結 346

從Bill Inmon在1991年提出數據倉庫的概念起，至今已有三十年的時間。在這期間人們所面對的數據，以及處理數據的方法都發生了翻天覆地的變化。起初數據倉庫繫統運行在單機或小型集群之上，程序以批處理方式周期性運行ETL作業。為常見的執行方式是在每天業務低峰期處理前一天產生的業務數據，即所謂的T 1模式。後來隨著互聯網和移動終端等應用的普及，需要處理的數據量不斷增大，出現了大數據的概念，以Hadoop及其生態圈組件為代表的新一代分布式大數據處理平臺逐漸流行。近年來隨著業務領域的不斷拓展，人們對數據分析的實時性要求越來越高，離線批處理方式所產生的延時已不能滿足需求。以Hadoop為代表的分布式框架並沒有給出實時計算解決方案，於是便出現了Storm、Spark Streaming、Flink等實時計算框架，可提供秒級的響應時間，在此基礎上實時數據倉庫應運而生。

作為DBA，我更傾向於采用一種不編程、組件少、門檻低、易上手、純SQL，並能處理包含歷史全量數據的方案，用來實現實時數據倉庫。不可否認，SQL仍然是數據庫、數據倉庫中常使用的開發語言，也是傳統數據庫工程師或DBA的必會語言，從它出現至今一直被廣泛使用。首先，SQL有堅實的關繫代數作為理論基礎，經過幾十年的積累，查詢優化器已經相當成熟。再者，對於開發者，SQL作為典型的非過程語言，其語法相對簡單，但語義卻相當豐富。據統計95%的數據分析問題都能用SQL解決，這是一個相當驚人的結論。

本書介紹的實現方案能滿足以上所有要求，涉及的具體技術包括：MySQL主從復制，保證為業務繫統提供可靠的數據庫服務，並提供數據來源；Canal Server實時獲取增量MySQL binlog，並將其傳入Kafka消息隊列；Kafka將消息持久化，同時提供可伸縮、高吞吐的消息服務；Canal ClientAdapter負責消費Kafka中的消息，將數據流傳輸到Greenplum數據庫；Greenplum作為數據倉庫繫統，提供實時ETL功能，自動維護操作數據存儲（ODS）、維度表與事實表。

Greenplum分布式數據庫采用無共享（Shared-Nothing）的大規模並行處理（MPP）架構，能充分利用集群的硬件資源，將並行處理發揮到極致。Greenplum具有可選存儲模式、事務支持、並行查詢與數據裝載、容錯與故障轉移、數據庫統計、過程化語言擴展等方面的功能特性，正是它們支撐Greenplum成為一款理想的分析型數據庫產品。

本書內容

全書共分10章。第1章說明數據倉庫相關的基本概念，包括數據倉庫定義、操作型繫統與分析型繫統、ETL、數據倉庫架構等。第2章介紹三種主流的數據倉庫設計模型，即關繫數據模型、維度數據模型和DATA VAULT模型。第3章介紹Greenplum繫統架構、功能特性、主要優缺點，以及為何適用於數據倉庫應用。第4章詳解Greenplum的安裝部署問題。第5章介紹實時數據同步的實現，包括MySQL數據復制在實時數據倉庫架構中所起的作用，如何使用Kafaka，以及Maxwell Kafka Bireme和Canal Server Kafka Canal ClientAdapter兩種具體實現。第6章用一個銷售訂單示例說明如何使用Greenplum的規則（rule）實現實時自動數據裝載。第7章和第8章分別詳解多維數據倉庫中常見的維度表和事實表技術，及其在Greenplum中的實現。第9章介紹Greenplum主要的、例行的與推薦的運維與監控工作。第10章作為完整數據分析體繫的組成部分，介紹如何在Greenplum中集成MADlib，實現基於SQL的機器學習。

讀者對像

本書所定位的讀者是大數據分析繫統設計和開發、數據倉庫繫統設計和開發、DBA、架構師等相關技術人員。所有的描繪場景與實驗環境都基於Linux操作繫統。假設讀者已具有一定的數據庫、數據倉庫、SQL與Linux基礎。

源碼下載

本書配套的源碼，需要使用微信掃描下面二維碼獲取，可按掃描後的頁面提示，把下載鏈接轉發到自己的郵箱中下載。如果發現問題或疑問，請電子郵件聯繫booksaga@163.com，郵件主題為“Greenplum構建實時數據倉庫實踐”。

致謝

在本書編寫過程中，得到了很多人的幫助與支持。首先，感謝我所在的公司——優貝在線提供的平臺和環境，感謝同事們在工作中的鼎力相助。沒有那裡的環境和團隊，也就不會有這本書。其次，感謝清華大學出版社圖格事業部的老師和編輯們，他們的辛勤工作使得本書得以盡早與讀者見面。再次，感謝CSDN提供的技術分享平臺，給我有一個將博客文章整理成書的機會。後，感謝家人對我一如既往的支持。

由於水平有限，疏漏之處在所難免，希望讀者批評指正。

編  者

2022年5月

推  薦  序

自從人類誕生以來，我們利用不同形式的生產工具推動社會不斷向前發展，繼農業時代、工業時代之後，隨著科技革命和產業變革的深入演進，我們已進入數字時代的快速發展時期。數字經濟以數據資源作為關鍵生產要素、以現代信息網絡作為重要載體、以信息通信技術的有效使用作為效率提升和經濟結構優化的重要推動力。數字化轉型正在驅動生產方式、生活方式和治理方式發生深刻的變革，對世界經濟、政治和科技格局產生深遠影響。

數據要素是數字經濟深化發展的核心引擎，企業作為數字經濟發展的主力軍，在研發生產、企業管理及市場經營的時候，一方面產生了各類海量數據，另一方面又迫切需要從海量聚集的數據中挖掘數據價值，從而推動技術、產品及模式的創新，增強企業市場競爭力，為全社會的經濟發展帶來強勁推動力。

中國作為全球數字時代的領先者，各領域的高速發展迫切需要在數據管理、數據利用等方面有更加高效、智能的工具平臺，降低經濟體在數據治理方面的成本，提升數據服務質量和體驗。

王雪迎作為國內數據工程領域的實踐者和教育者，在數據領域已從業近三十多年，在工作中不斷跟蹤、實踐和總結的數據技術。2021年3月，公司組織專家研討行業數據應用技術方案，我對王雪迎抱怨，目前市面上的各類數據庫、數據挖掘軟件五花八門，對中小企業來講難以選擇，OLTP、OLAP以及AI三位一體的實施應用成本太高，制約了中小企業在數據利用方面的能力。2022年初，王雪迎說通過一年的探索驗證，總結了一些新經驗即將出版成冊，這就是《Greenplum構建實時數據倉庫實踐》。

世間萬物都在變化，市場和客戶在變化，產品和技術在變化，經營環境在變化，企業本身也在變化。在不斷變化中，如何用一種優雅、簡潔和高效的方式，通過數據感知變化，將是數字時代下每個數據從業者都要思考和面臨的問題。

這本由清華大學出版社出版的《Greenplum構建實時數據倉庫實踐》，行文流暢、案例易懂、體繫完美，理論與實踐相結合。希望它能為國內數據工程領域帶來了“與時俱進”的變化，也希望這種變化為我們廣大從業者帶來更多的提升可能，從而實現各自更大的價值。

楊興兵

科技有限公司總經理

2022年3月

1.4  數據倉庫架構

前面三節介紹了數據倉庫、操作型繫統、分析型繫統、ETL等概念，也指出了分析型繫統的數據源一般來自數據倉庫，而數據倉庫的數據來自於操作型繫統。本節將從技術角度討論數據倉庫的組成和架構。

1.4.1  基本架構

“架構”是什麼？這個問題從來就沒有一個準確的答案。在軟件行業中，一種被普遍接受的架構定義是指繫統的一個或多個結構。結構中包括軟件的構建（構建是指軟件的設計與實現），構建的外部可以看到屬性以及它們之間的相互關繫。這裡參考此定義，把數據倉庫架構理解成構成數據倉庫的組件及其之間的關繫，那麼就有了如圖1-1所示的數據倉庫架構圖。

圖1-1  數據倉庫架構

圖1-1中顯示的整個數據倉庫環境，包括操作型繫統和數據倉庫繫統兩大部分。操作型繫統的數據由各種形式的業務數據組成，這其中可能有關繫數據庫、TXT或CSV文件、HTML或XML文檔，還可能存在外部繫統的數據，比如網絡爬蟲抓取來的互聯網數據等，數據可能是結構化、半結構化、非結構化的。這些數據經過抽取、轉換和裝載（ETL）過程進入數據倉庫繫統。

這裡把ETL過程分成了抽取和轉換、裝載兩個部分。抽取過程負責從操作型繫統獲取數據，該過程一般不做數據聚合和彙總，但是會按照主題進行集成，物理上是將操作型繫統的數據全量或增量復制到數據倉庫繫統的RDS（Raw Data Stores）中。轉換、裝載過程將對數據進行清洗、過濾、彙總、統一格式化等一繫列轉換操作，使數據轉化為適合查詢的格式，然後裝載進數據倉庫繫統的TDS（Transformed Data Stores）中。傳統數據倉庫的基本模式是首先用一些過程將操作型繫統的數據抽取到文件，然後用另一些過程將這些文件轉化成MySQL或Oracle這樣的關繫數據庫的記錄，後用第三部分過程把數據導入進數據倉庫。

RDS是原始數據存儲的意思。將原始數據保存到數據倉庫裡是個不錯的想法。ETL過程的bug或繫統中的其他錯誤是不可避免的，保留原始數據使得追蹤並修改這些錯誤成為可能。有時，數據倉庫的用戶會有查詢細節數據的需求，這些細節數據的粒度與操作型繫統的相同。有了RDS，這種需求就很容易實現，用戶可以查詢RDS裡的數據且不會影響業務繫統的正常運行。這裡的RDS實際上是起到了操作型數據存儲（Operational Data Store，ODS）的作用，關於ODS相關內容將在1.4.3小節詳細論述。

TDS意為轉換後的數據存儲。這是真正的數據倉庫中的數據。大量的用戶會在經過轉換的數據集上處理他們的日常查詢。如果前面的工作做得好，這些數據將以保證重要的和頻繁的查詢能夠快速執行的方式構建出來。

這裡的原始數據存儲和轉換後的數據存儲是邏輯概念，它們可能物理存儲在一起，也可能分開。當原始數據存儲和轉換後的數據存儲物理上分開時，它們不必使用同樣的軟硬件。傳統數據倉庫中，原始數據存儲通常是本地文件繫統，原始數據被組織進相應的目錄中，這些目錄是基於數據從哪裡抽取或何時抽取建立（例如以日期作為文件或目錄名稱的一部分）；轉換後的數據存儲一般是某種關繫數據庫。

自動化調度組件的作用是自動定期重復執行ETL過程。不同角色的數據倉庫用戶對數據的更新頻率要求也會有所不同，財務主管需要每月的營收彙總報告，而銷售人員想看到每天的產品銷售數據。作為通用的需求，所有數據倉庫繫統都應該能夠建立周期性自動執行的工作流作業。傳統數據倉庫一般利用操作繫統自帶的調度功能（如Linux的cron或Windows的計劃任務）來實現作業自動執行。

數據目錄有時也數據存儲，它可以提供一份數據倉庫中數據的清單。用戶通過它可以快速解決這些問題：什麼類型的數據被存儲在哪裡？數據集的構建有何區別？數據後的訪問或更新時間，等等。此外，還可以通過數據目錄感知數據是如何被操作和轉換的。一個好的數據目錄是讓用戶體驗到繫統易用性的關鍵。

查詢引擎組件負責實際執行用戶查詢。傳統數據倉庫中，它可能是存儲轉換後數據的Oracle、MySQL等關繫數據庫繫統內置的查詢引擎，還可能是以固定時間間隔向其導入數據的OLAP立方體，如Essbase cube。

用戶界面指的是終用戶所使用的接口程序。可能是一個GUI軟件，如BI套件中的客戶端軟件，也可能就是一個瀏覽器。

1.4.2  主要數據倉庫架構

在數據倉庫技術演化過程中，產生了幾種主要的架構方法，包括數據集市架構、Inmon企業信息工廠架構、Kimball數據倉庫架構和混合型數據倉庫架構。

1. 數據集市架構

數據集市是按主題域組織的數據集合，用於支持部門級的決策。有兩種類型的數據集市：獨立數據集市和從屬數據集市。

獨立數據集市集中於部門所關心的單一主題域，數據以部門為基礎部署，無須考慮企業級別的信息共享與集成。例如，制造部門、人力資源部門和其他部門都各自有他們自己的數據集市。獨立數據集市從一個主題域或一個部門的多個事務繫統獲取數據，用以支持特定部門的業務分析需要。一個獨立數據集市的設計既可以使用實體關繫模型，也可以使用多維模型。數據分析或商業智能工具直接從數據集市查詢數據，並將查詢結果顯示給用戶。一個典型的獨立數據集市架構如圖1-2所示。

圖1-2  獨立數據集市架構

因為一個部門的業務相對於整個企業來說要簡單得多，數據量也小得多，所以建立部門的獨立數據集市具有周期短、見效快的特點。如果從企業整體的視角來觀察這些數據集市，我們會看到每個部門使用不同的技術，建立不同的ETL過程，處理不同的事務繫統，而在多個獨立的數據集市之間還會存在數據的交叉與重疊，甚至會有數據不一致的情況。從業務角度看，當部門的分析需求擴展，或者需要分析跨部門或跨主題域的數據時，獨立數據集市會顯得力不從心。而當數據存在歧義，比如同一個產品，在A部門和B部門的定義不同時，將無法在部門間進行信息比較。

另外一種數據集市是從屬數據集市。如Bill Inmon所說，從屬數據集市的數據來源於數據倉庫。數據倉庫裡的數據經過整合、重構、彙總後傳遞給從屬數據集市。從屬數據集市的架構如圖1-3所示。

圖1-3  從屬數據集市架構

建立從屬數據集市的好處主要有：

• 性能：當數據倉庫的查詢性能出現問題，可以考慮建立幾個從屬數據集市，將查詢從數據倉庫移出到數據集市。


• 安全：每個部門可以完全控制自己的數據。


• 數據一致：因為每個數據集市的數據來源都是同一個數據倉庫，有效消除了數據不一致的情況。

2. Inmon企業信息工廠架構

Inmon企業信息工廠架構如圖1-4所示。

圖1-4  Inmon企業信息工廠架構

我們來看圖1-4中的組件是如何協同工作的。

• 應用繫統：這些應用是組織中的操作型繫統，用來支撐業務。它們收集業務處理過程中產生的銷售、市場、材料、物流等數據，並將數據以多種形式進行存儲。操作型繫統也叫源繫統，為數據倉庫提供數據。


• ETL過程：ETL過程從操作型繫統抽取數據，然後將數據轉換成一種標準形式，終將轉換後的數據裝載到企業級數據倉庫中。ETL是周期性運行的批處理過程。


• 企業級數據倉庫：是該架構中的核心組件。正如Inmon數據倉庫所定義的，企業級數據倉庫是一個細節數據的集成資源庫，其中的數據以粒度級別被捕獲，存儲在滿足三範式設計的關繫數據庫中。


• 部門級數據集市：是面向主題數據的部門級視圖，數據從企業級數據倉庫獲取。數據在進入部門數據集市時可能進行聚合。數據集市使用多維模型設計，用於數據分析。重要的一點是，所有的報表工具、BI工具或其他數據分析應用，都從數據集市查詢數據，而不是直接查詢企業級數據倉庫。

3. Kimball 數據倉庫架構

Kimball數據倉庫架構如圖1-5所示。

圖1-5  Kimball數據倉庫架構

對比圖1-4可以看到，Kimball與Inmon兩種架構的主要區別在於核心數據倉庫的設計和建立。Kimball的數據倉庫包含高粒度的企業數據，使用多維模型設計，這也意味著數據倉庫由星型模式的維度表和事實表構成。分析繫統或報表工具可以直接訪問多維數據倉庫裡的數據。在此架構中的數據集市也與Inmon中的不同。這裡的數據集市是一個邏輯概念，隻是多維數據倉庫中的主題域劃分，並沒有自己的物理存儲，也可以說是虛擬的數據集市。

4. 混合型數據倉庫架構

混合型數據倉庫架構如圖1-6所示。

圖1-6  混合型數據倉庫架構

所謂的混合型結構，指的是在一個數據倉庫環境中，聯合使用Inmon和Kimball兩種架構。從架構圖可以看到，這種架構將Inmon方法中的數據集市部分替換成了一個多維數據倉庫，而數據集市則是多維數據倉庫上的邏輯視圖。使用這種架構的好處是，既可以利用規範化設計消除數據冗餘，保證數據的粒度足夠細，又可以利用多維結構更靈活地在企業級數據倉庫實現報表和分析。