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

0.數倉建模系列歷史篇章回顧

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

2. 數倉建模本質到底是什么？為什么維度建能模脫穎而出？

1.從小公司到大公司看數倉建模發展

數倉建模到底是什么，你可能看了很多理論知識，面試也知道怎么回答，但是心中還是有很多疑惑，數倉建模/維度建模其實是一整套抽象出來的方法規范體系，發展至今內部細節及其豐富，所以要想透徹了解他，運用它，你可以通過透視他的發展之路，看它是如何抽象總結出來的，這樣才能明白當企業什么場景，什么規模，才能應用什么模式，數倉建設到什么程度，而不是照搬大廠或主流的數倉建設體系，

1.1 小公司的數倉建模之路

有小伙伴說，數倉建模其實沒那么復雜，在我作業中不就是通過hive/spark等工具開發一張張表嗎？說直白點就是把公司各個業務系統資料通過調度系統每天定時抽過來，存盤到Hive資料倉庫里，然后基于這些資料，定時hive/spark等任務跑了很多業務需要的資料，比如報表，比如業務匯總統計資料，最終把這些資料推送到BI報表平臺或者業務庫，然后日常作業也就是接點新表到數倉，給業務開發一些新表等等這些，

數倉建模其實沒什么高大上的！！！！

我相信很多中小公司的小伙伴也有這些疑惑，現實中很多大資料開發也是這樣干的，覺得數倉建模被神話放大了，其實我剛作業時也有這種感覺，但是后來隨著去大廠做資料開發，見識了幾百PB資料規模，每天幾十萬個任務的資料倉庫，才發現如果還按照之前那套搞法根本行不通，為啥呢？

規模大的公司，PB級別的資料規模，每天上萬個任務，業務快速發展，應用場景繁雜且多變，資料時間要求嚴格，每天新增資料TB級別，幾萬張甚至幾十萬張表，跨部門跨子公司開發人員多，大家如何保障統計的資料一致，如何復用資料降低計算成本等等這些問題，如何解決這些問題？這時候你會發現，資料倉庫不僅僅是一張張表了，而是一個有著完整體系架構和規范的系統，而是一個系統化的方法體系，一個隨著業務的發展，需求增加的不斷豐富完善的方法體系，

1.2 大廠的數倉建設之路

沒有哪家公司上來就是王炸四帶二開局的，所有公司數倉的建設也都是跟隨業務的發展逐步完善的，有需求有應用場景才會有對應的解決方案，而逐步解決這些問題，解決這些需求程序中總結的成熟規范，方法，架構合起來就是一套數倉建設方案，國內如阿里巴巴就抽象出了一套自己的方法體系---OneData，當然它也是以Kimball的維度建模為核心理念基礎的模型方法論，同時對其進行了一定的升級和擴展，才構建了阿里集團的資料架構體系——OneData，

因為大廠的頭部效應，像阿里巴巴的onedata體系就是國內很多公司資料倉庫建設的的參考標桿，如下阿里巴巴OneData體系以及建模程序：

尖叫提示：

如上OneData體系以及數倉建模程序，可謂及其完善但實施起來也很繁瑣，對于Alibaba這樣海量資料規模，復雜業務場景，龐大開發人員的企業來說，通過這些約束規范的流程，“浪費”人力成本來保障資料質量，最終數學期望值最高，

但是所以對于很多小伙伴來說，沒有經歷過大廠的開發，去學習大廠完善的數倉建設體系會有所有種“脫離實際的感覺”，有形而上學的嫌疑，畢竟國內95%以上的公司也達不到阿里巴巴這樣的資料規模和要求，當然也完全沒必要搞這套，不劃算，

所以我后面講數倉建設，維度建模都是抓住本質核心去講，更多細節沒法辦法一一展開，因為對于很多公司沒用應用場景，所以大家學數倉建設，維度建模只需要抓住Killball大神的核心理念基礎即可，其他的旁枝末節知道即可，

2.維度建模核心剖析與實踐

2.1.維度模式設計主要四個步驟

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

前面說到數倉建模的本質，以及維度建模的四個步驟，對于維度建模來說其他所有的細節都是圍繞這四個程序展開的，看上去這四個程序很抽象，其實幾乎每個大資料開發小伙伴都經歷過，只是大家不識廬山真面目，只緣生在此山中，

其實幾乎每個大資料開發都搞過數倉建模，維度建模！

舉個例子，即使你在一家小公司里，每天的作業就是用hive/spark開發一張張表，業務方需要啥資料給他計算啥資料，但其實數倉建模就藏在你開發的程序中，比如業務讓你給他統計個資料，建個報表，下面我們來還原一下你建表開發前做了哪些事，

第一步：業務得告訴你開發口徑吧，選擇統計你們公司的什么資料？哪個業務的資料？甚至精確到哪個業務哪個程序的資料？是公司某個商品的每天交易資料？還是新增會員的資訊？統計什么？好吧，我們假設業務最終告訴你統計公司A產品某個程序的瀏覽人數，這其實就是維度建模的選擇業務程序，
第二步：前面業務告訴你統計什么業務資料，那么你還得知道他要統計的資料是按天統計明細，還是按周統計匯總，這樣你建表時表里一行存放什么資料，加工什么粒度的資料得知道哇，比如業務要的是每天的交易明細，那你表里存放的資料每行粒度就是天，這個確認資料粒度的程序其實就是宣告粒度，
第三步：前面業務告訴你統計公司哪個業務線哪個業務程序的資料，也告訴你是按天統計資料，每天給他出資料，但你還得知道按什么維度統計，瀏覽人數是PV分析，還是按UV分析，還是業務既要UV，也要PV，也要按手機號統計瀏覽人數，這個其實就是你最終資料的分析維度，從哪些角度分析，是從一個維度分析還是同時多個維度一起分析，這個就是數倉建模的確認維度，
第四步：上面這些都確認清楚了，分析哪個業務/程序的資料，分析的粒度是按天還是周，分析的維度有哪些，那么最后你就要考慮的是如何建表了，也就是事實表的建設，根據前面三個要求建設對應的表，通過hive/spark等生產對應的資料到表里，最后業務就可以通過使用你提供的事實表和維表進行關聯，查看資料了，（當然也有很多人直接將維度退化到事實表中，省去了關聯維表的機會，這個后面在說），這個程序其實就是數倉建模的確認事實，

尖叫總結：看，是不是我們在無形中完成了數倉粗放型的維度建模，只是大家沒有察覺而已，這里我們簡單地跟大家介紹了維度建模demo版，其實也是維度建模的核心基礎了，

3.維度建模：程序拆解與案例演示

假設我們有一個電信資料源，獲取的是手機連接基站等資訊的資料，資料是每隔1小時上傳一次，現在業務方需要通過手機連接基站的資訊情況，分析一下用戶手機型別，用戶主要分布在哪個城市，用戶運營商分類情況，挖掘一下用戶作業地，居住地等情況，甚至用戶性別等資訊做用戶畫像，

  TABLE `base_station_info`(
  `serdatetime` string COMMENT '服務器時間標準時間戳(13位數字)', 
  `ipaddr` string COMMENT '客戶端源IP', 
  `type` string COMMENT '資料型別', 
  `plat` string COMMENT '系統平臺', 
  `device` string COMMENT '設備標示', 
  `carrier` string COMMENT '運營商編碼', 
  `simopname` string COMMENT '運營商名字：聯通，電信，移動，鐵通，..', 
  `lac` string COMMENT '基站lac', 
  `datetime` string COMMENT '客戶端時間（經過服務端時間矯正標準時間戳(13位數字', 
  `mac` string COMMENT '設備Mac地址', 
  `model` string COMMENT '設備型號', 
  `duid` string COMMENT 'DUID(新版設備標示)', 
  `imei` string COMMENT '設備IMEI手機串號', 
  `serialno` string COMMENT '手機序列號', 
  `networktype` string COMMENT '網路型別', 
  `processtime` string COMMENT '服務器時間', 
  `product` string COMMENT '產品線', 
  `psc` int COMMENT 'UMTS的主要擾碼', 
  `lat` int COMMENT '基站緯度', 
  `lon` int COMMENT '基站經度', 
  `nearby` array<map<string,int>> COMMENT '鄰區基站資訊串列', 
  `language` string COMMENT '手機語言', 
  `cl` map<string,string> COMMENT '安卓快取的GPS資訊,安卓獲取快取經緯度', 
  `strategy_id` string COMMENT '定向調頻的策略Id', 
  `moid` string COMMENT '匿名設備識別符號,取值deviceinfo表oaid欄位的值', 
  `appkey` string COMMENT '應用的key', 
  `apppkg` string COMMENT '應用的包名', 
  `appver` string COMMENT '應用的版本號', 
  `sysver` string COMMENT '系統版本號', 
  `factory` string COMMENT '設備的廠商', 
  `commonsdkver` string COMMENT '公共庫的版本號', 
  `token` string COMMENT '唯一ID', 
  `data_network_type` string COMMENT '蜂窩網路型別', 
  `dc` int COMMENT '1為離線包,2為Maven線上包,3為定制包,4為MDC版本,6為GP版本', 
  `useridentity` string COMMENT '請求頭')

3.1.選擇業務程序

如上，開始建模前我們需要考慮自己有哪些資料源，資料的情況，以及業務方的需求，然后決定對哪種業務程序開展資料建模，這里業務方想通過手機基站連接資訊分析用戶情況，做用戶畫像，因此這里我們建模的業務程序是手機基站連接資訊，

3.2宣告粒度

上面我們知道我們的資料源的粒度是小時級別，資料是每小時更新上傳一次，基本資料越詳細，粒度越小獲取的事實就越多，可以分析的東西也就越多，原子粒度的資料具有更強大的多維性，比如按小時粒度的資料我就可以按小時，天，周，月匯總統計，但是按天的粒度的資料，可以上卷按天，周月統計，但是沒法下鉆按小時類別聚合了，所以一般為了防止業務變更需求，盡可能的話可以選擇原子粒度的資料，這里我們就選擇原子粒度的資料，

3.3確認維度

資料粒度選擇完以后，維度可以的選擇空間也就固定了下來，維度的選擇就很簡單了，為什么呢？因為資料的詳細粒度確認了事實表可以分析的主要維度，比如上面我們確認資料粒度以后，可以分析的維度也就是表里欄位的度量值，比如運營商分類，手機型別分類，網路型別，當然具體看業務需要哪些分析維度，因為不需要分析的維度我們完全不用存放這些資料，浪費計算和存盤空間等等，