本文翻譯自“Dimensional Modeling and Kimball Data Marts in the Age of Big Data and Hadoop”，翻譯已獲得原作者 Uli Bethke 授權。Uli Bethke 是 Sonra 公司的 CEO，愛爾蘭 Hadoop 用戶組主席，也是 Oracle 的 ACE。
維度建模已死？
在回答這個問題之前，讓我們回頭來看看什么是所謂的維度數據建模。
為什么需要為數據建模？
有一個常見的誤區，數據建模的目的是用 ER 圖來設計物理數據庫，實際上遠不僅如此。數據建模代表了企業業務流程的復雜度，記錄了重要的業務規則和概念，并有助于規范企業的關鍵術語。它清晰地闡述、協助企業揭示商業過程中模糊的想法和歧義。此外，可以使用數據模型與其他利益相關者進行有效溝通。沒有藍圖，不可能建造一個房子或橋梁。所以，沒有數據模型這樣一個藍圖，為什么要建立一個數據應用，比如數據倉庫呢？
為什么需要維度建模？
維度建模是數據建模的一種特殊方法。維度建模有兩個同義詞，數據集市和星型結構。星型結構是為了更好地進行數據分析，參考下面圖示的維度模型，可以有一個很直觀的理解。通過它可以立即知道如何通過客戶、產品、時間對訂單進行分割，如何通過度量的聚集和比較對訂單業務過程進行績效評估。
維度建模最關鍵的一點，是要定義事務性業務過程中的最低粒度是什么。如果切割或鉆入數據，到葉級就不能再往下鉆取。從另一個角度看，星型結構中的最低粒度，即事實和維度之間沒有進行任何聚集的關聯。
數據建模和維度建模
標準數據建模的任務，是消除重復和冗余的數據。當數據發生變化時，我們只需在一個地方修改它，這有助于保證數據的質量，避免了不同地方的數據不同步。參考下面圖示的模型，它包含了代表地理概念的幾張表。在規范化模型中，每個實體有一個獨立的表，數據建模只有一張表：geography。在這張表中，city 會重復出現很多次。而對于每個 city，如果 country 改變了名字，就不得不在很多地方進行更新。
注：標準數據模型總是遵守 3NF 模式。
標準的數據建模，本身并不是為了商業智能的工作負載而設計的。太多的表會導致過多的關聯，而表關聯會導致性能下降，在數據分析中我們要盡力去避免這種情形發生。數據建模過程中，通過反規范化把多個相關表合并成一個表，例如前面例子里的多個表被預合并成一個 geography 表。
那么為何部分人認為維度建模已死？
一般人都認可數據建模的方式，而把維度建模當成特殊處理方式，它們都是有價值的。那為什么在大數據和 Hadoop 的時代，部分人會認為維度建模沒用了？
“數據倉庫之死”
首先，一些人混淆了維度建模和數據倉庫。他們認為數據倉庫已死，于是得出結論：維度建模也可以被丟進歷史的垃圾箱。這種論點在邏輯上是連貫的，但是，數據倉庫的概念遠沒有過時。我們總是需要集成的、可靠的數據來產生商業智能儀表盤（BI Dashboards）。
只讀結構的誤解
第二個常聽見的爭論，比如“我們遵循只讀方式的結構（Schema），所以不需要對數據再進行建模了”。依我看來，這是數據分析過程中最大的誤解之一。我同意起初僅轉儲原始數據，這時不過多考慮結構是有意義的。但是，這不應該成為不對數據進行建模的借口。只讀方式的結構只是降低了下游系統的能力和責任，一些人不得不咬牙去定義數據類型。訪問無模式數據轉儲的每一個進程都需要自己弄清楚發生了什么，而這完全是多余的。通過定義數據類型和正確的結構，可以很容易地避免這些工作。
再談反規范化和物理模型
是否那些宣傳維度建模的觀點實際上已過時了?的確有些觀點比上面列出的兩條更好，要理解它們需要對物理建模和 Hadoop 的工作方式有一些了解。
前面簡單提到采用維度建模的原因之一，和數據的物理存儲方式有關。標準數據建模中每個真實世界里的實體，有一個自己的表。我們這樣做，是為了避免數據冗余和質量問題在數據中蔓延。越多的表，就需要越多的關聯，這是標準建模的缺點。表關聯的代價是昂貴的，特別是關聯數據集中關聯大量記錄的時候尤其突出。當我們考慮維度建模時，會把多個表合并起來，這就是所謂的預關聯或者說數據反規范化。最后的結果是，得到更少的表、更少的關聯、更低的延遲和更好的查詢性能。
可參與領英上相關的討論。
徹底反規范化
為什么不把反規范化做到徹底？去掉所有的表關聯只保留一張表？的確，這樣做可以不需要對任何表進行關聯，但是可以想象到，它會帶來一些負面影響。首先，它需要更多的存儲，因為要存儲大量的冗余數據。隨著數據分析的列式存儲格式的出現，這一點現在不那么令人擔憂了。反規范化最大的問題是，每次屬性值發生變化，就不得不在很多地方進行更新，可能是幾千甚至幾百萬次更新。一個解決辦法是在晚上對模型進行全量重載，通常這比增量更新要更快、更容易。列式數據庫通常采用這種方法，首先將要做的更新存儲在內存中，然后異步地寫入磁盤。
分布式關系型數據庫(MPP)上的數據分布
在 Hadoop，例如 Hive、SparkSQL 上建立維度模型，要很好地理解一個技術上的核心特征，就是它和分布式關系型數據庫（MPP）上的建立方式是不一樣的。在 MPP 中的節點上分布數據，可以控制每條數據記錄的位置?；诜謪^策略，例如 Hash、List、Range 等，可以在同一個節點上跨表同定位（co-located）各個記錄的鍵值。由于數據的局部性得到保證，關聯速度會非?？?，因為不需要在網絡上發送任何數據。參考下面圖示的例子，在 ORDER 和 ORDER_ITEM 表中有相同 ORDER_ID 的記錄存儲在同一節點上：
ORDER 和 ORDER_ITEM 表中 ORDER_ID 對應的鍵值，在相同的節點做到同定位。
Hadoop上的數據分布
數據分布在基于 Hadoop 的系統中是非常不同的，我們將數據分割成大型的塊（chunks），并在 Hadoop 分布式文件系統（HDFS）的各個節點進行分發和復制。這種數據分發策略不能保證數據的一致性。參考下面圖示的例子，記錄 ORDER_ID 的鍵被存儲在不同的節點：
為了關聯它們，需要在網絡上發送數據，這樣做會影響性能。
處理這個問題的一個策略，是在集群的所有節點上復制要關聯的表，該策略被稱為廣播式關聯（broadcast join）。如果對 MPP 使用相同的策略，可以想象，只能用在較小的 lookup 或維度表中。
那么當關聯一個大的事實表和一個大的維度表，比如客戶或產品，甚至關聯兩個大型事實表時，我們該怎么辦？
Hadoop上的維度建模
為了解決性能問題，可以利用反規范化將大的維度表放進事實表，以保證數據是同定位的（co-located），而對較小的維度表可以在所有節點上廣播（broadcast）。
關聯兩個大型事實表時，可以把低粒度的表嵌套到更高粒度的表中，例如把 ORDER_ITEM 表嵌套到 ORDER 表中。高級的查詢引擎，比如 Impala 或 Drill 可以讓數據扁平化（flatten out）：
嵌套數據的策略很有用，類似于 Kimball 概念中用橋接表來表示維度模型中的 M:N 關系。
Hadoop和緩慢變化維
Hadoop 文件系統中的存儲是不可變的，換句話說，只能插入和追加記錄，不能修改數據。如果你熟悉的是關系型數據倉庫，這看起來可能有點奇怪。但是從內部機制看，數據庫是以類似的機制工作，在一個進程異步地更新數據文件中的數據之前，將所有變更保存在一個不可變的預寫式日志（WAL- write-ahead log，Oracle中稱為redo log）中。
不可變性（immutability）對維度模型有什么影響？你也許還記得維度建模課程中漸變維的概念（Slowly Changing Dimensions - SCDS）。SCDS 有選擇地保存屬性值變更的歷史，于是可以在某個時間點上對屬性值進行度量。但這不是默認的處理方式，默認情況下會用最新的值來更新維度表。那么在 Hadoop 上如何選擇呢？記住!我們不能更新數據。我們可以簡單地為 SCD 選擇默認方式并對每一個變化進行審核（audit）。如果想運行基于當前值的報表，可以在 SCD 之上創建一個視圖，讓它僅僅檢索到最新值，利用 Windows 函數可以很容易做到這一點。或者，可以運行一個所謂合并（Compaction）的服務，用最新的值物理地創建維度表的一個單獨版本。
Hadoop的存儲演化
Hadoop 平臺的供應商并沒有忽視這些 Hadoop 的限制，例如 Hive 就提供了滿足 ACID 的事務和可更新的表。根據大量的主要公開問題以及個人經驗，這個特性還沒有完善到可以部署生產環境。Cloudera 采取了另外一個手段，利用 Kudu 建立了一個新的可變更存儲格式，它并沒有基于 HDFS，而是基于本地 OS 操作系統。它完全擺脫了 Hadoop 的限制，類似于列式 MPP 的傳統存儲層。通常來說，在 Impala + Kudu 這樣一個 MPP 上運行 BI 和 Dashboard 的任何使用場景，會比 Hadoop 更好。不得不說，當它涉及到彈性、并發性和擴展性時，有自己的局限。當遇到這些限制時，Hadoop 和它的近親 Spark 是解決 BI 工作負載的好選擇。
判決：維度模型和星型模式過時了嗎？
我們都知道，Ralph Kimball 已經退休了，但他設計原則的思想和觀念仍然是有效的，也將會繼續存在。即使我們不得不讓它們適應新的技術和存儲類型，它們仍然能夠帶來巨大的價值。
補充閱讀
Tom Breur: The Past and Future of Dimensional Modeling
Edosa Odaro: 5 Radical Tips for Speedy Big Data Integration - The Anti Data Warehouse Pattern
京公網安備 11010502049343號