看數(shù)據(jù)模型界兩大長老的神仙打架

如果有人問起，“L，對于編程，你最后悔的一件事情是什么？”我只能回答：“數(shù)據(jù)結構”。

故事，要從我最初學編程的動機，開始說起。

踏入編程這個行當，我是從Visual FoxPro 開始的。

上大學那會，本科學農，農學是養(yǎng)花養(yǎng)草的專業(yè)，和計算機一點兒關系沒有。但學校是有規(guī)定，大一大二要通過計算機二級。被教育了12年，別的本事沒有，要說證書這事，那是相當熱衷。所以早早就把 VFP 學好了，自然考試也輕松通過。

通過也就通過了，也沒留下特別的情感。轉機出現(xiàn)在大二，那年學統(tǒng)計，其中有各種公式，各種參數(shù)，紛繁復雜，作業(yè)題不難，但很多推演特別麻煩。那天做完統(tǒng)計學作業(yè)，正在圖書館發(fā)呆，過了2,4,6級，發(fā)現(xiàn)人生有些空虛，接下來還有2年半的時間要揮霍，不禁要焦慮，接下來該做什么，才能證明自己？

人生的苦惱，逃不過三大問題，我是誰，我從哪里來，要到哪里去

眼瞅著瞅著，就瞄到了作業(yè)題上去。這些可惡的參數(shù)，每次都要手寫，一寫就是一個長本，跟寫舞臺劇臺詞一樣。那有沒有好一點的方法來求解最終的答案呢？

就跟棒球突然擊中村上春樹文藝細胞一般，慵懶的午覺，加上一口激爽的冰咖，瞬間蟄醒了已充分回血的大腦。忽然就想到了VFP中的表單，想到了類里面的變量，這些變量不就是參數(shù)嘛，表單不就是每次作業(yè)題的草稿嘛。至于公式，那就是方法嘛。我把公式，參數(shù)，建成類，最終結果就讓計算機程序去算。為什么我要用筆去推算呢？

慢慢的思路磨就出來，于是，說干就干，到機房，插上1.44MB的磁盤，一個下午，把指數(shù)平滑公式給寫好了。接下來的作業(yè)，只要輸入表單對應參數(shù)值，按下計算按鈕，結果就出來了。

從此，作業(yè)變成了分析需求，編程成了我真正的作業(yè)。

你們看，我開始編程時，就在解決一些實際問題，將作業(yè)計算中的定量模型，抽象出K-V的數(shù)據(jù)模型，而計算公式則抽象出函數(shù)。

現(xiàn)在回首，我依然對廣義的數(shù)據(jù)結構和算法抱著極高的敬畏。同時，我也慶幸，我掌握了解決信息領域的數(shù)據(jù)結構與算法，即關系型數(shù)據(jù)庫的數(shù)據(jù)模型。

如果說，廣義的數(shù)據(jù)結構，比如鏈表，平衡樹和圖等，是一切編程的基礎，那么理解RDBMS的“數(shù)據(jù)結構”，比如范式，星型，雪花型，大寬表等，就是叱咤信息領域的基礎。無論你如何努力，都不會精通，卻可以解決無數(shù)實用的問題，帶來極大的心理成就感和滿足。

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

要做好這類數(shù)據(jù)分析的建模工作，離不開討論 Kimball 與 Inmon 的數(shù)據(jù)模型。兩種截然不同的模型，帶給項目的便利與挑戰(zhàn)，也是大不同。

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

首先從架構說起

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

從這個架構圖，很容易看出，數(shù)據(jù)倉庫只是負責收集數(shù)據(jù)，類似集線器，最終還是要把數(shù)據(jù)分流出去。

Kimball 的架構就不一樣了。如下圖所示，他也有一個大的數(shù)據(jù)倉庫，但少了數(shù)據(jù)集市的概念。

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

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

所以，Kimball 的理論，更多是數(shù)據(jù)從局部流向整體的策略，最終交付物，數(shù)據(jù)倉庫就像是企業(yè)數(shù)據(jù)流總線，誰要誰取，不必切換多個數(shù)據(jù)庫。

再對比數(shù)據(jù)模型的落地

曾經有位同事問我，為什么我們的表，設計了很多冗余字段，而不是嚴格按照三范式設計呢？其實答案就是 Kimball 的維度模型使然。在 Kimball 總線架構圖中，我特意用星型模型標注了數(shù)據(jù)倉庫的 schema.

很好看懂，中間一顆星，周圍直聯(lián)其他星星，有且只有一級聯(lián)系。這就是 Kimball 數(shù)據(jù)模型的精髓所在。與 Inmon 最大的區(qū)別，也就在這里。Inmon 的數(shù)據(jù)模型都是ER模型，范式用到了極致。

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

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

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

這就是很多入門的同學迷糊的地方，為什么在一個表里，會有很多看似冗余的數(shù)據(jù)，為什么不按照三范式拆出來呢？這里有個特別重要的原理，那就是空間換時間。

當所有的屬性都拿來做維度分析時，為了節(jié)省Join的時間，通常把這些維度屬性預先計算好。即時查詢分析，用GroupBy去隨機分組統(tǒng)計數(shù)據(jù)，假如沒有合適的索引，會非常慢。為了提高效率，我們只能把這些組合的統(tǒng)計與聚合，預先計算好，存起來。大部分的 OLAP 引擎，都是基礎這個原理，比如SQL Server Cube, Kylin等。

Kimball 給這種數(shù)據(jù)模型，起了個名字，“星型模型”。作為最終的交付產品，是數(shù)據(jù)倉庫的靈魂。

Kimball 理論也沒有放棄數(shù)據(jù)集市，只不過他將數(shù)據(jù)集市放在ETL階段實現(xiàn)了，用的是另外一種模型，叫做“雪花模型”。功能與 Inmon 的數(shù)據(jù)集市類似，實際上，數(shù)據(jù)模型也一致，就是標準的ER模型，即三范式結構。

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

那么現(xiàn)實中，我們該用哪種理論來設計數(shù)據(jù)倉庫的架構呢，用哪種數(shù)據(jù)模型來建模呢

現(xiàn)實世界沒有銀彈，一切取決于所在業(yè)務的復雜度。Kimball 理論顯然更適合BI套件，但留下冗余數(shù)據(jù)處理的復雜；Inmon 解決了數(shù)據(jù)一致性問題，但性能又是老大難的問題。

順便說下，阿里巴巴的大數(shù)據(jù)實踐，在第三階段，也采用了 Kimball 數(shù)據(jù)模型方法論?？梢姡幢闶窃诨ヂ?lián)網應用，數(shù)倉的眾多模型也是通用的。具體參考這本書《大數(shù)據(jù)之路-阿里巴巴大數(shù)據(jù)實踐》