平時在工作中，一般都會遇到拿著 Excel 直接分析，給報表的場景，或者更近一些網際網路的分析工作，會用 SQL 取數，再用 Excel 分析。

那說到分析，就必然離不開BI、資料倉庫、資料建模等了，spark，hadoop等大資料平臺，也是搞這行的人得懂的知識。

可是，相比於那些架構、演算法，更讓我頭疼的是資料結構和模型。

現在回首，我依然對廣義的資料結構和演算法抱著極高的敬畏。同時，我也慶幸，我掌握瞭解決資訊領域的資料結構與演算法，即關係型資料庫的資料模型。

如果說，廣義的資料結構，比如連結串列，平衡樹和圖等，是一切程式設計的基礎，那麼理解RDBMS的“資料結構”，比如正規化，星型，雪花型，大寬表等，就是叱吒資訊領域的基礎。無論你如何努力，都不會精通，卻可以解決無數實用的問題，帶來極大的心理成就感和滿足。

為方便大家直觀地感受資料模型，在這兒出道題，比如對比雙11，雙12等前後價格波動，引起的銷量變化。分享下，你會如何涉及表結構，來滿足分析的需求。

要做好這類資料分析的建模工作，離不開討論 Kimball 與 Inmon 的資料模型。兩種截然不同的模型，帶給專案的便利與挑戰，也是大不同。

當然還有諸如 Data Vault 與 Anchor 模型等等

首先從架構說起

上圖，是 Inmon 的集線器架構圖。資料倉庫，並不是 Inmon 理論的交付產品，它只是一個集企業所有關鍵實體、業務流程資料於一體的儲存。面對各個部門自己的分析需求，資料倉庫最終還會繼續分流出各個業務需要的資料集市，所有單獨的業務都從分配到的資料集市中抽取資料。

從這個架構圖，很容易看出，資料倉庫只是負責收集資料，類似集線器，最終還是要把資料分流出去。

Kimball 的架構就不一樣了。如下圖所示，他也有一個大的資料倉庫，但少了資料集市的概念。

在Kimball的理論模型中，資料集市從來不是正規的交付物，而是ETL過程中自然產生的副產品。即ETL將業務資料集中抽到 Staging 時，會將資料按照實體，業務流程打包成一個ODS層(Operational Data Store)，任何單個業務部門，完全可以從ODS中查詢資料。功能上類似於 Inmon 的資料集市。

最終資料彙總到資料倉庫時，天然就帶有企業全域性屬性。只見樹木不見森林的尷尬，就被化解了。好比，面臨企業利潤的下滑，我們就能從成本，訂單量，單價上來做多維度分析，而不再是僅僅盯著訂單量一個維度去看。

所以，Kimball 的理論，更多是資料從區域性流向整體的策略，最終交付物，資料倉庫就像是企業資料流匯流排，誰要誰取，不必切換多個數據庫。

再對比資料模型的落地

曾經有位同事問我，為什麼我們的表，設計了很多冗餘欄位，而不是嚴格按照三正規化設計呢？其實答案就是 Kimball 的維度模型使然。在 Kimball 匯流排架構圖中，我特意用星型模型標註了資料倉庫的 schema.

很好看懂，中間一顆星，周圍直聯其他星星，有且只有一級聯絡。這就是 Kimball 資料模型的精髓所在。與 Inmon 最大的區別，也就在這裡。Inmon 的資料模型都是ER模型，正規化用到了極致。

我們來看 Kimball 的星型模型維度建模：

很直觀，圍繞著SalesOrder（銷售訂單）業務，假設有三個維度（即影響訂單的三個因素，實際上遠不止3個，300個都有，網際網路甚至還有3000個）Employee, Time, Components，即人，貨，時。

人的維度，還包括了人所在的部門，地址和職級；時間維度，算簡單的一個，實際應用中，會有多個記賬週期，時間略有複雜；貨的維度，就是商品，有廠家，地址，廠長和商品本身的屬性，大小，顏色等等。

這就是很多入門的同學迷糊的地方，為什麼在一個表裡，會有很多看似冗餘的資料，為什麼不按照三正規化拆出來呢？這裡有個特別重要的原理，那就是空間換時間。

當所有的屬性都拿來做維度分析時，為了節省Join的時間，通常把這些維度屬性預先計算好。即時查詢分析，用GroupBy去隨機分組統計資料，假如沒有合適的索引，會非常慢。

為了提高效率，我們只能把這些組合的統計與聚合，預先計算好，存起來。大部分的 OLAP 引擎，都是基礎這個原理，比如SQL Server Cube, Kylin等。

Kimball 給這種資料模型，起了個名字，“星型模型”。作為最終的交付產品，是資料倉庫的靈魂。

Kimball 理論也沒有放棄資料集市，只不過他將資料集市放在ETL階段實現了，用的是另外一種模型，叫做“雪花模型”。功能與 Inmon 的資料集市類似，實際上，資料模型也一致，就是標準的ER模型，即三正規化結構。

人的維度上，只保留人本身的屬性，比如性別，身高，年齡等，其他附屬屬性，比如地址，部門，職級，都分別存在不同的子表裡面。其他兩個維度也一樣，自留屬性與附加屬性都分別儲存。這樣一個壞處，就是Join比較多，而且容易造成效能緩慢。

那麼現實中，我們該用哪種理論來設計資料倉庫的架構呢，用哪種資料模型來建模呢？

現實世界沒有銀彈，一切取決於所在業務的複雜度。Kimball 理論顯然更適合BI套件，但留下冗餘資料處理的複雜；Inmon 解決了資料一致性問題，但效能又是老大難的問題。