近日，2022年個推TechDay“治數訓練營”系列直播課第一期圓滿舉辦。個推資深大資料研發工程師為大家深入淺出地介紹了資料倉儲的前世今生以及資料建模的常用方法。
本文對“治數訓練營”第一期《資料倉儲與維度建模》的乾貨內容進行了總結，同時也挑選了直播間的精彩提問做了Q&A梳理，帶大家一起回顧首期課程。
點選觀看直播回放視訊>>https://mp.weixin.qq.com/s/NK...
一、資料倉儲快速入門
資料倉儲（Data Warehouse），簡稱“數倉”，是大資料從業者繞不開的一個概念。“資料倉儲之父”Bill Inmon最早提出數倉的概念，認為“資料倉儲是一個面向主題的、整合的、相對穩定的、反映歷史變化的資料集合，用於支援管理決策”。
此外，大資料架構專家Ralph Kimball在《The Data Warehouse Tookit》一書中，也對數倉進行了定義：“資料倉儲是一個將源系統資料抽取、清洗、規格化，然後提交到維度資料儲存的系統，為決策的制定提供查詢和分析功能的支撐和實現”。
Bill Inmon對數倉的定義更強調整體特性，Ralph Kimball則是從實施流程角度來定義數倉。無論哪個定義，我們都能從中看到企業建設資料倉儲的意義重大。企業通過建設數倉，不僅能夠將分散在各業務系統的資料進行集中化管理，打破資料孤島；還能為後續高效分析和應用資料，通過大資料賦能業務發展奠定基礎。
二、數倉建設與資料建模
那麼，企業如何建設資料倉儲？如何建設一個貼合業務需求的、高效、穩定、好用的資料倉儲？這就需要考慮資料模型的選擇和資料建模的問題。
“資料建模”是指對實體以及實體和實體之間的關係進行資料化描述和抽象的過程。“資料模型”，則是指組織和儲存資料的方法。
目前主流的資料建模方法有兩種，分別是正規化建模和維度建模：
正規化建模
正規化建模由Bill Inmon提出，指站在企業角度面向主題的抽象，我們一般使用E-R實體關係模型將事物抽象為“實體”“屬性”“關係”，來表示事物和事件關聯。正規化建模並非針對某個具體業務流程中實體物件關係的抽象，它需要建模人員全面地、整體地瞭解企業的業務和資料，不僅實施週期長，對建模人員的能力要求也比較高。
維度建模
維度建模由Ralph Kimball提出，主張從分析決策的需求出發構建模型，為分析需求服務。因此它重點關注如何使使用者更快速地完成資料分析，同時保持較好的大規模複雜查詢的響應效能。相較正規化建模，維度建模建設週期短，支援敏捷迭代，一般不會對數倉架構做過多複雜的設計。
在構建數倉時，我們要根據具體的資料分析場景和業務處理系統來選擇相應的資料建模方法。比如，就OLTP系統（On-line Transaction Processing：聯機事務處理）而言，由於其主要是面向隨機讀寫的資料操作，關注事務的處理，因此我們推薦使用OLTP系統及傳統資料庫的企業通過正規化建模的方法來設計資料模型，以解決在事務處理中的資料冗餘和一致性問題。而OLAP系統（On-line Analytical Processing ：聯機分析處理）面向批量讀寫資料的操作，不關注事務處理一致性，主要是關注資料的整合以及大資料查詢和處理中的效能，因此一般採用維度建模的方法。
具體如何進行正規化建模和維度建模呢？我們結合案例分別來看。
三、正規化建模方法及例項剖析
首先來看正規化建模的基本過程。
在進行正規化建模時，我們往往要遵從不同的規範要求設計出合理的模型，這些不同的規範要求就是“正規化”。目前行業中存在一正規化、二正規化、三正規化等不同的模型建設規範。越高的正規化帶來的資料庫冗餘越小，但是在資料計算方面會更復雜。企業大多采用三正規化建模，在保證靈活度以及資料計算速度的同時，降低資料處理的複雜度。
正規化建模的過程可以被拆解為以下四步：
- 抽象出主體
- 梳理主體之間的關係
- 梳理主體的屬性
- 畫出E-R關係圖
比如，我們要使用正規化建模的方式設計某課程管理系統的資料模型。
該系統主要用來管理某學校教師、學生和課程等相關資料，涉及課程選修、考試成績、教師授課、學生班級等方面。那我們首先要梳理出實體，為教師、課程、學生、班級；其次梳理出實體之間的關係，包括教師講授課程、學生選修課程、學生隸屬班級等；再次要羅列出各實體和關係的屬性，比如“學生”這個實體的屬性有姓名、性別、年齡等，“學生選修課程”這個關係的屬性有選修時間、總課時等；第四步，則是畫出E-R圖，用矩形表示“實體”，用菱形表示“關係”，用橢圓形表示“屬性”，以視覺化的方式清晰展示出主體和主體之間的關係。
四、維度建模方法及例項剖析
相比正規化建模，維度建模稍為複雜，包括事實表和維度表兩塊內容。
事實表
首先看事實表。事實表分三種，包括事務性事實表、週期性快照事實表、累計快照事實表。
事務性事實表通常用一條記錄表示某個時間點發生的事件或行為。比如電商業務場景中的訂單支付業務，一般就採用事務性事實表來組織和儲存資料。
週期性快照事實表的一條記錄描述的則是一個實體在某一段時間內的狀態或現狀，比如某顧客每月的積分餘額就屬於一條典型的週期性快照事實表記錄。
累計快照事實表的一條記錄則是對某業務流程中發生的多個事件的累計記錄，一般是為了滿足某個流程節點運轉效率的統計需求。
我們以一個事務性事實表的設計過程為例來了解事實表的設計方法：
- 選擇與資料分析需求有關的業務過程。“業務過程”是指在業務流程中不可拆分的行為事件。比如，電商業務場景下，購物的業務流程中就包括加購、下單、支付、商家發貨、使用者確認收貨等業務過程。如果我們要分析銷售額，那“支付”就是必選的業務過程。
- 宣告粒度。我們要儘量選擇最細粒度，精確定義事實表的每一行所表示的業務含義，以確保事實表有最大的靈活性。比如，使用者可能在一個訂單裡面購買多個商品，那每個購買的商品就是一個子訂單，我們一般選擇將子訂單作為宣告粒度。
- 確定維度。維度是指業務過程所處的環境資訊，比如使用者在某個時間購買了某個店鋪的某個商品，那店鋪所屬行業、商品所在類目等均可以被認為是維度。
- 確定事實，即確定業務過程的度量指標。比如“支付”這個業務過程的度量指標為支付金額，更復雜的電商業務場景下，可能還包括分攤郵費、折扣金額等指標。
需要說明的是，每個資料倉儲都包含一個或者多個事實表，事實表是對分析主題的度量，它包含了與各維度表相關聯的外來鍵，並通過Join方式與維度表關聯。
維度表
維度表則是使用者分析資料的視窗，記錄了事實表中相關事務、事件的屬性及屬性含義。
維度表的設計過程，主要分為以下四步：
- 選擇維度。比如要生成一個商品維度表，那我們選擇的維度就是商品維度。
- 確定主維表。比如要建商品維度表，那主維表就是來自於業務系統的商品表。
- 確定相關維度表。主維表確定之後，其他的相關維度表也就隨之確定。比如商品維度表的相關維度表有商品類目表、所屬品牌表、商品所屬行業表等。
- 確定維度屬性。這些屬性一般來自於主維表和相關維表。我們將主維表和相關維表的屬性整合，並對相同屬性合併（比如，商品類目表和所屬品牌表中可能都會有所屬行業屬性，那我們就可以對所屬行業這個屬性進行合併），然後將最終得到的屬性放到要生成的維度表裡。
此外，本期個推TechDay“治數訓練營”還對正規化建模與維度建模的基本原則、建模中的常見問題（比如正規化建模中的傳遞依賴問題、維度建模中的緩慢變化維問題等）、數倉分層等進行了詳細闡述。
更多精彩內容，猛戳直播回顧視訊Get吧！
彩蛋：直播間Q&A精選
1. 什麼樣的資料倉儲才算建設得比較完善？
資料倉儲主要是為資料分析服務。一個完善的數倉首先要滿足企業對業務分析的需求。
數倉的建設是一個不斷迭代和優化的過程，需要從成本、效能、效率等方面綜合考慮，以尋求平衡。一般來講，在企業業務穩定發展階段，我們的工作主要以維護現有數倉為主，同時做一些完善優化的工作；對於業務迭代比較快的企業，針對一些探索類的業務分析需求，我們需要對數倉進行新的開發投入。
2. 在數倉設計中，需求方的分析粒度會隨著時間和人員的理解以及需求的變化發生很大的變化，如何在數倉建設初期儘可能考慮到這個問題？
這就需要數倉建設團隊在前期就做好需求調研、業務調研、資料調研等工作。
使用維度建模的情況下，我們要嚴格遵循事實表的設計原則，在宣告粒度時，要儘量選擇最新的粒度，並且保留儘可能多的資料維度資訊，確保事實表有最大的靈活性。
3. 針對緩慢變化維的問題，是否可以將維度表變成拉鍊表來解決呢？
拉鍊表也是常用的解決思路，屬於插入新行的解決方法，與直播中講到的插入新行的例子很類似。
不同的是，我們直播中舉例的是“商品key”代理主鍵作為關聯事實表的欄位，所以可以通過修改“商品key”實現維度變化的處理；而拉鍊表是通過不修改關聯欄位，直接在表中增加兩個欄位start、end來標記資料行的有效時間，在使用時需要先篩選有效的資料行。
相對來說，修改代理主鍵的方法比較好理解，也更方便使用者使用。
4. 資料指標方面，在存在多個業務部門的情況下，如何將相同或者近似名稱的指標做統一管理？當出現名稱相同但定義不同的指標時，如何處理？
該問題涉及到數倉建設規範中的指標命名規範設計，可以在指標命名中避免該問題，比如在命名時增加部門維度等。
另外，在我們“治數訓練營”的後續課程中也會有相應的內容介紹，敬請期待。
推薦書目
當一個公司在戰略上決定做雲端計算和大資料服務後，如何將該戰略進行逐步分解，最終落地實施？這其中涉及技術構建、運營管理、組織能力建設等一系列活動，有哪些方法論和實踐可供借鑑？相信本書能給您帶來靈感！
**關注個推技術實踐微信公眾號，
後臺回覆“數倉”，
獲取本期直播課件~**