為什麼要資料倉庫建模呢？

如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地放置；如果把資料看作城市的建築，我們希望城市規劃佈局合理；如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找一個檔案而不知所措。

資料模型就是資料組織和儲存方法，它強調從業務、資料存取和使用角度合理儲存資料。Linux的創始人Torvalds有一段關於“什麼才是優秀程式設計師”的話：“爛程式設計師關心的是程式碼，好程式設計師關心的是資料結構和它們之間的關係”，最能夠說明資料模型的重要性。只有資料模型將資料有序的組織和儲存起來之後，大資料才能得到高效能、低成本、高效率、高質量的使用，一般可以從四個方面概括資料倉庫模型的價值：

效能：良好的資料模型能幫助我們快速查詢所需要的資料，減少資料的I/O吞吐，提高使用資料的效。

成本：良好的資料模型能極大地減少不必要的資料冗餘，也能實現計算結果複用，極大地降低儲存和計算成本。

效率：良好的資料模型在業務或系統發生變化時，可以保持穩定或很容易地實現擴充套件，提高資料穩定性和連續性

質量：良好的資料模型能改善資料統計口徑的不一致性，減少資料計算錯誤的可能性。

那麼，資料倉庫一般為什麼要分層設計呢？

以下是一個示例：

分層設計的好處大致可以概括如下：

清晰資料結構：每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。

資料血緣追蹤：能夠快速準確地定位到問題，並清楚它的危害範圍。

減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。

把複雜問題簡單化：將複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。當資料出現問題之後，不用修復所有的資料，只需要從有問題的步驟開始修復

遮蔽原始資料的異常：不必改一次業務就需要重新接入資料。

知道了資料倉庫的好處，很多行業和企業也都經歷了資料倉庫建模，但如果問哪家資料模型建得好，各行業各企業就很難分出個高下了。

但這個問題又很重要，因為有標杆認識到差距才能進步，有夥伴邀筆者去講講資料建模，說實話，筆者也不知道怎麼講，因為這個跟企業自己的業務和資料太相關了，所謂的業界的標準建模理論和方法也變得無足輕重。

大神Inmon的《資料倉庫》和kimball《資料倉庫工具箱》算是兩個經典吧，最近出了本很厚的《資料倉庫與商業智慧寶典》，但也是人家kimball以前經典文章的合集。

關係建模又叫ER建模，是資料倉庫之父Inmon推崇的，其從全企業的高度設計一個3NF模型的方法，用實體加關係描述的資料模型描述企業業務架構，在正規化理論上符合3NF，其是站在企業角度進行面向主題的抽象，而不是針對某個具體業務流程的，它更多是面向資料的整合和一致性治理，正如Inmon所希望達到的“single version of the truth”。

維度模型則是資料倉庫領域另一位大師Ralph Kimball 所倡導的。維度建模以分析決策的需求為出發點構建模型，一般有較好的大規模複雜查詢的響應效能，更直接面向業務，典型的代表是我們比較熟知的星形模型，以及在一些特殊場景下適用的雪花模型。

Inmon的ER建模優點體現在規範性較好，冗餘小，資料整合和資料一致性方面得到重視，適用於較為大型的企業級、戰略級的規劃，但缺點是需要全面瞭解企業業務、資料和關係，對於建模人員要求很高，實施週期非常長，成本昂貴，筆者剛進公司的時候就經歷了中國移動的的ER資料倉庫專案，的確不是一個新人能短時消化的。

Kimball的維度建模相對能快速上手，快速交付，但缺點是冗餘會較多，靈活性比較差，但其實現在看來也沒什麼，淘寶在大資料之路書中也提到“淘寶資料平臺變遷的過程正好解釋了二者的不同，最初，淘寶業務單一、系統簡單，主要是簡單的報表系統；後期資料量越來越大，系統越來越多，嘗試用ER建模的資料倉庫，但是在實踐中發現快速變化的業務之下，構建ER模型的風險和難度都很高，現在則主要採用基於維度建模的模型方法了。”

但Inmon和kimball關於關係建模和維度建模的爭論其實也沒什麼值得探討的，沒有誰更好，在企業內，這兩種建模方式往往同時存在，底層用關係建模合適一點，技術的優雅換來了資料的精簡，往上維度建模更合適一些，靠資料的冗餘帶來了可用性，優勢互補，都說關係建模不易，概念模型是個坎，其實維度建模也不易，維度的梳理和運營是艱鉅的，否則就是爛攤子的活。

在資料建模上，很多人糾結於如何建模，用關係建模、維度建模亦或其它？回過頭來也是浮雲，其實剛起步的時候沒有那麼多的循規蹈矩，滿足報表和取數的需求即可，儘量做到“高內聚，鬆耦合”，這是服務的原則，放到資料建模照樣適用。

很多企業花了巨大的代價建設了一套資料模型，週期長達1-2年，幾年後卻推倒重來，問題的根子不在於當初的專案完成的情況如何，包括建模方式是否合理，而在於專案完成了成鳥獸散，缺乏持續的運營。

想想企業的資料倉庫模型，有多大的比例在日常的運營中進行了改進呢，有10%嗎？阿里在建設資料中臺，很大的挑戰在於日常運營中對於中臺業務的把控能力和持續改進的勇氣，資料模型要成為使能者，不是簡單的滿足需求，也不是為了博得業務人員一時的滿意，而是要立足於長遠，始終主動、自發和持續的自我進化。

前段時間團隊成員說為了滿足資料探勘需求要做一張超級寬表，很能說明問題，任何一個企業的資料模型都會碰到類似的挑戰，但這也是混亂的開始，以下是經典的對話：

A：“現在資料探勘變數準備太慢了，要搞一張大寬表，我們已經梳理了，需要從幾十張表中取出欄位，這個是這些表的清單？”

B：“跨度這麼大，這麼多欄位，從DWD到DWI，再到DWA，有想過更好的辦法嗎？”

A：“這個？我們看了，融合模型缺這缺那的，還是再做一張吧，只是為這類資料做的！”

B：“你這張寬表下次會碰到融合模型同樣的問題，融合模型是當前平衡做的相對好的，能否去增強融合模型，按欄位歸屬到各融合模型，而不要另起條線，資源也有限的，讓這些表的融合模型負責人過來討論下？”

資料倉庫模型的持續提升始終來自於日常樸實無華的需求驅動，資料中臺蘊含著企業資料文化的再造，涉及到一系列機制流程的完善，認識到這點很重要。