作者基于多年的大資料處理經驗，當前管理著100PB+資料倉庫和2000+節點的集群，持續系統化給大家分享一下關于資料倉庫建設的經驗總結，本系列既有資料倉庫的形而上學理論體系，也有結合公司業務的實踐，既有大廠如阿里巴巴，京東，頭條的分享交流，也有小公司數倉迭代案例的建設分析，感興趣的小伙伴可以私信交流，

0.歷史系列篇章回顧

先見森林：資料倉庫的前世今生與體系框架

1.什么是數倉建模本質？

所謂的資料倉庫建模，聽著很高大，我們要透過現象看本質，其實本質就是解決如何管理組織企業中資料，并將其用于業務用戶的決策制定程序中的方法體系；從企業來說就是資料如何更好地商業智能（BI），從技術角度來說就是如何合理化管理企業資料的存盤和計算，

因為對于企業來說，資料規模可能是MB,GB,TB,PB等，不同資料體量數倉的管理模式是不一樣，資料規模越大，場景越復雜，管理起來的細節越豐富，需要考慮的問題也就越多，數倉建設管理也就越規范，故對于企業來說，會因為如資料規模，業務場景，成本，決策戰略等各種原因選擇不同的資料倉庫架構與建設方式，所以資料倉庫的資料組織建設方法其實有很多種方式，只是主流的，大家通用的就那么幾種，更常用的就是Killball的維度建模，這就好比android，ios是移動作業系統的標桿，你可以搞一個其他的出來，但是沒人用，影響力有限，

要知道Kimball的資料倉庫工具書1996就出版了，維度建模方法思想上個世紀就提出來了，截止到當前，唯一沒變的是其資料倉庫維度建模的思想，而很多最早Kimball提出來的數倉維度建模的細節已經跟實際脫節了，不過有些概念通過新的技術和實踐被逐漸完，企業實際數倉建設程序中都是用其維度建模思想方法體系，具體細節要結合實際去優化，所以如果你看資料倉庫工具書這本書時發現其中有很多想法跟實操都不一樣，請不要驚訝，

2.資料倉庫建模有哪些方法體系？

編程大家都是從基礎語法學習，然后不斷細節深入，最后技術高階后都要看一本編程思想的書，其實數倉建設也是這樣，要有數倉建設的思想轉變，資料倉庫建模本質就是組織管理企業資料，為企業資料商業智能服務，條條大路通羅馬，所以他的方法體系也不是唯一的，但是要抓住數倉的本質，企業付出成本搜集資料，存盤資料目的是為了挖掘資料價值，

所以資料倉庫的建設要能給用戶以簡單可理解的方式建設管理資料，同時給企業提供高效的資料查詢性能，一句話不能太復雜，建設不能太麻煩，成本太高，得不償失，后面大家發現還是用維度建模的方法體系建設資料倉庫的性價比最高，簡單高效，其他方法體系了解即可，一般面試時候會問下，重點了解其思想體系，以及之間的區別，

其他方法體系介紹參考博客：資料倉庫常見建模方法與建模實體演示

3.基于維度建模的數倉架構方案有哪些？

既然說資料倉庫的建設，是歷史和經驗讓我們選擇了維度建模方法體系，那么什么是維度建模，維度建模實施起來的的架構怎么樣？既然維度建模只是一個資料倉庫建設的方法體系，是方法體系那么不同的公司實施起來也有不同的架構方案，實施樣式，注意區別維度建模和資料倉庫架構的關系，維度建模只是數倉架構的環節的一部分應用，數倉架構是維度建模的實施方案，

3.1獨立的資料孤島架構

這種數倉架構最簡單，大企業，各個部門子公司每個部門都直接從源資料獲取資料ETL,然后創建屬于自己部門的獨立資料集市，這些資料集市采用維度建模方法，實作簡單快速建設，高效查詢的功能，但是這種架構不利于企業資料的融合，容易形成資料孤島，對企業資料的挖掘價值降低，存盤計算浪費等，好處就是各搞各的，不用考慮跨組織的資料控制和協調管理，不建議使用，大公司也很少使用了，當然也有公司還在使用，比如國企，

3.2 Killball大佬的數倉架構（主流）

Killball的數倉架構核心是資料隔離，整個后端從ETL開始關注資料質量，資料從不同的源系統獲取后，進行統一的資料ETL(轉換，清洗)，劃分維度和事實的同時關注資料的完整性，一致性，最終將資料加載到展示區域里的目標維度模型中，

3.3 Inmon的數倉架構

這個Inmon的架構是比較有影響力的，采用CIF模式（Corparate Information factiory企業資訊工廠模式），主要和killball區別是規范化ETL資料處理，采用資料庫3NF，其次資料架構建設理念也不同，雙方都有支持者，

關于具體Killball 和Inmon數倉建設都推薦維度建模，但是兩者資料架構建設理念不同，有所區別，小伙伴可以參考這篇博客了解下，沒必須糾結過多的細節，而且隨著發展，架構的區別也越來越小： 資料倉庫 Inmon與Kimball數倉理論對比

4.維度建模概述與步驟

4.1 維度建模是什么？

1. 維度建模是資料倉庫大師Ralph Kimball提出的，是資料倉庫工程領域最流行的數倉建模經典，
2. 維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的回應性能，
3. 維度建模是面向分析的，為了提高查詢性能可以增加資料冗余，反規范化的設計技術，
4. 維度建模是一種抽象出來的企業資料倉庫中資料組織與管理的方法體系，直白點說就是組織管理資料倉庫中各種業務資料表的，如何基于業務場景，業務程序，業務需求組織創建表，最終提供高效的查詢性能，

尖叫總結一下：換一種方式來解釋什么是維度建模，學過資料庫的小伙伴都應該都知道資料庫表之間關系：星型模型，一個業務表通過外掛了很多維表，這就是一個典型的維度模型，我們在進行維度建模的時候會建一張事實表，這個事實表就是星型模型的中心，然后會有一堆維度表，這些維度表就是向外發散的星星，而實際開發中維度表也不是那么嚴格，又可以有自己的維度表，維度表上可以掛維度表，這樣就像雪花一樣叫雪花模型，

4.2數倉采用維度建模的好處和壞處

4.2.1 資料倉庫采用使用維度建模的好處

1. 簡單易理解、構建的資料模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，屬于業務決策需求性，所以相比資料庫的3NF等規范要求的不高，規范也不那么嚴格，
2. 查詢的高性能、較好的大規模復雜查詢的回應，基于技術框架實作，后面再說，
3. 修改的靈活性和可擴充性，維度建模是一個可不斷擴充添加的程序，比如1.在現有的事實表中增加維度，2.在事實表中增加事實，3.在維度表中增加屬性，

4.2.2 維度建模的“壞處”：
有好處就是弊端，維度建模的壞處體現在，比如對于公共層，一致性維度規劃建設，資料模型的建設需要花費很大人天，這樣就沒有直接把結果搞出來的省事，

4.3 維度建模的步驟

所謂維度建模抽象出來其實就4個步驟，基于這四個步驟組織管理企業的資料，其他所有的展開都是圍繞和豐富這四個步驟細節的，以應對不同的業務場景，舉個例子，怎么把大象裝進冰箱?抽象完就三步，第一打開冰箱門，第二步把大象放進去，第三步關上冰箱門，

1.維度模式設計主要四個步驟程序：

1. 選擇業務程序
2. 宣告粒度
3. 確認維度（也有叫標識維度）
4. 確認事實（也有叫標識事實）

先這樣了解這些概念，胸有成竹，先見森林，再去結合實踐，先不要太關注細節，就像蓋房子一樣，你把沙子，石頭，水泥，鋼筋摸牌的再熟練，掌握的再熟悉，沒有建設過大樓，在應用實踐中操作過對你來說還是一堆零散的東西，學習掌握細節的最好的程序就是應用中，

4.3 維度建模里術語與概念

4.3.1 表分為：維度表和事實表

數倉基于維度建模，那么數倉里的表按這種分類只有兩種，一種是事實表，一種是維度表，所謂事實表簡單理解就是存放業務資料，業務事務程序的表，當然從各種業務源的資料中如何抽象出事實表，哪些欄位算是事實而不是維度，事實表有分哪些？所以這些會基于業務場景去詳細介紹，

同理維度表也是存放用戶分析維度的表，但維度表如何抽象出維度，維度緩慢變化的如何處理，有哪些處理方式？維表的存盤分類等等？這些只所以分的那么細，是因為有業務應用場景，后面詳細介紹，

4.3.2維度建模資料之間關系

維度建模按資料組織型別劃分可分為

1. 星型模型
2. 雪花模型
3. （星座模型），這個非主流認證

后續幾乎所有關于數倉維度建模的所以細節都是圍繞上面兩大模塊，表是維度表和事實表，表之間的組織關系則是為星型模型、雪花模型、星座模型