個人認為建模在中臺中起到至關重要的作用瀑罗，是做好架構的基礎胸嘴，是在做好磨刀的事，是為后續(xù)治理環(huán)節(jié)奠基斩祭。

為什么要數據倉庫建模呢劣像？

如果把數據看作圖書館里的書，我們希望看到它們在書架上分門別類地放置摧玫；如果把數據看作城市的建筑耳奕，我們希望城市規(guī)劃布局合理；如果把數據看作電腦文件和文件夾诬像，我們希望按照自己的習慣有很好的文件夾組織方式屋群，而不是糟糕混亂的桌面，經常為找一個文件而不知所措坏挠。

數據模型就是數據組織和存儲方法芍躏，它強調從業(yè)務、數據存取和使用角度合理存儲數據降狠。Linux的創(chuàng)始人Torvalds有一段關于“什么才是優(yōu)秀程序員”的話：“爛程序員關心的是代碼对竣，好程序員關心的是數據結構和它們之間的關系”，最能夠說明數據模型的重要性榜配。只有數據模型將數據有序的組織和存儲起來之后否纬，大數據才能得到高性能、低成本芥牌、高效率烦味、高質量的使用，一般可以從四個方面概括數據倉庫模型的價值：

性能：良好的數據模型能幫助我們快速查詢所需要的數據壁拉，減少數據的I/O吞吐，提高使用數據的效柏靶。

成本：良好的數據模型能極大地減少不必要的數據冗余弃理，也能實現計算結果復用，極大地降低存儲和計算成本屎蜓。

效率：良好的數據模型在業(yè)務或系統發(fā)生變化時痘昌，可以保持穩(wěn)定或很容易地實現擴展，提高數據穩(wěn)定性和連續(xù)性

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

那么算灸，數據倉庫一般為什么要分層設計呢？

以下是一個示例：

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

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

數據血緣追蹤：能夠快速準確地定位到問題，并清楚它的危害范圍骑冗。

減少重復開發(fā)：規(guī)范數據分層赊瞬，開發(fā)一些通用的中間層數據，能夠減少極大的重復計算贼涩。

把復雜問題簡單化：將復雜的任務分解成多個步驟來完成巧涧，每一層只處理單一的步驟，比較簡單和容易理解遥倦。當數據出現問題之后谤绳，不用修復所有的數據，只需要從有問題的步驟開始修復

屏蔽原始數據的異常：不必改一次業(yè)務就需要重新接入數據袒哥。

知道了數據倉庫的好處闷供，很多行業(yè)和企業(yè)也都經歷了數據倉庫建模，但如果問哪家數據模型建得好统诺，各行業(yè)各企業(yè)就很難分出個高下了歪脏。

但這個問題又很重要，因為有標桿認識到差距才能進步粮呢，有伙伴邀筆者去講講數據建模婿失，說實話，筆者也不知道怎么講啄寡，因為這個跟企業(yè)自己的業(yè)務和數據太相關了豪硅，所謂的業(yè)界的標準建模理論和方法也變得無足輕重。

大神Inmon的《數據倉庫》和kimball《數據倉庫工具箱》算是兩個經典吧挺物，最近出了本很厚的《數據倉庫與商業(yè)智能寶典》懒浮，但也是人家kimball以前經典文章的合集。

關系建模又叫ER建模识藤，是數據倉庫之父Inmon推崇的砚著，其從全企業(yè)的高度設計一個3NF模型的方法，用實體加關系描述的數據模型描述企業(yè)業(yè)務架構痴昧，在范式理論上符合3NF稽穆，其是站在企業(yè)角度進行面向主題的抽象，而不是針對某個具體業(yè)務流程的赶撰，它更多是面向數據的整合和一致性治理舌镶，正如Inmon所希望達到的“single version of the truth”柱彻。

維度模型則是數據倉庫領域另一位大師Ralph Kimball 所倡導的。維度建模以分析決策的需求為出發(fā)點構建模型餐胀，一般有較好的大規(guī)模復雜查詢的響應性能哟楷，更直接面向業(yè)務，典型的代表是我們比較熟知的星形模型否灾，以及在一些特殊場景下適用的雪花模型卖擅。

Inmon的ER建模優(yōu)點體現在規(guī)范性較好，冗余小坟冲，數據集成和數據一致性方面得到重視磨镶，適用于較為大型的企業(yè)級、戰(zhàn)略級的規(guī)劃健提，但缺點是需要全面了解企業(yè)業(yè)務琳猫、數據和關系，對于建模人員要求很高私痹，實施周期非常長脐嫂，成本昂貴，筆者剛進公司的時候就經歷了中國移動的的ER數據倉庫項目紊遵，的確不是一個新人能短時消化的账千。

Kimball的維度建模相對能快速上手，快速交付暗膜，但缺點是冗余會較多匀奏，靈活性比較差，但其實現在看來也沒什么学搜，淘寶在大數據之路書中也提到“淘寶數據平臺變遷的過程正好解釋了二者的不同娃善，最初，淘寶業(yè)務單一瑞佩、系統簡單聚磺，主要是簡單的報表系統；后期數據量越來越大炬丸，系統越來越多瘫寝，嘗試用ER建模的數據倉庫，但是在實踐中發(fā)現快速變化的業(yè)務之下稠炬，構建ER模型的風險和難度都很高焕阿，現在則主要采用基于維度建模的模型方法了∷岣伲”

但Inmon和kimball關于關系建模和維度建模的爭論其實也沒什么值得探討的捣鲸，沒有誰更好，在企業(yè)內闽坡，這兩種建模方式往往同時存在栽惶，底層用關系建模合適一點，技術的優(yōu)雅換來了數據的精簡疾嗅，往上維度建模更合適一些外厂，靠數據的冗余帶來了可用性，優(yōu)勢互補代承，都說關系建模不易汁蝶，概念模型是個坎，其實維度建模也不易论悴，維度的梳理和運營是艱巨的掖棉，否則就是爛攤子的活。

在數據建模上膀估，很多人糾結于如何建模幔亥，用關系建模、維度建模亦或其它察纯？回過頭來也是浮云帕棉，其實剛起步的時候沒有那么多的循規(guī)蹈矩，滿足報表和取數的需求即可饼记，盡量做到“高內聚香伴，松耦合”，這是服務的原則具则，放到數據建模照樣適用即纲。

很多企業(yè)花了巨大的代價建設了一套數據模型，周期長達1-2年博肋，幾年后卻推倒重來低斋，問題的根子不在于當初的項目完成的情況如何，包括建模方式是否合理束昵，而在于項目完成了成鳥獸散拔稳，缺乏持續(xù)的運營。

想想企業(yè)的數據倉庫模型锹雏，有多大的比例在日常的運營中進行了改進呢巴比，有10%嗎？阿里在建設數據中臺礁遵，很大的挑戰(zhàn)在于日常運營中對于中臺業(yè)務的把控能力和持續(xù)改進的勇氣轻绞，數據模型要成為使能者，不是簡單的滿足需求佣耐，也不是為了博得業(yè)務人員一時的滿意政勃，而是要立足于長遠，始終主動兼砖、自發(fā)和持續(xù)的自我進化奸远。

前段時間團隊成員說為了滿足數據挖掘需求要做一張超級寬表既棺，很能說明問題，任何一個企業(yè)的數據模型都會碰到類似的挑戰(zhàn)懒叛，但這也是混亂的開始丸冕，以下是經典的對話：

A：“現在數據挖掘變量準備太慢了，要搞一張大寬表薛窥，我們已經梳理了胖烛，需要從幾十張表中取出字段，這個是這些表的清單诅迷？”

B：“跨度這么大佩番，這么多字段，從DWD到DWI罢杉，再到DWA趟畏，有想過更好的辦法嗎？”

A：“這個屑那？我們看了拱镐，融合模型缺這缺那的，還是再做一張吧持际，只是為這類數據做的沃琅！”

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

數據倉庫模型的持續(xù)提升始終來自于日常樸實無華的需求驅動澈歉，數據中臺蘊含著企業(yè)數據文化的再造展鸡，涉及到一系列機制流程的完善，認識到這點很重要埃难。

作者：傅一平

鏈接：http://www.reibang.com/p/4674aad41988

來源：簡書

著作權歸作者所有莹弊。商業(yè)轉載請聯系作者獲得授權，非商業(yè)轉載請注明出處涡尘。