1.資料倉庫的概念

資料倉庫是一個為資料分析而設計的企業級資料管理系統，資料倉庫可集中、整合多個資訊源的大量資料，借助資料倉庫的分析能力，企業可從資料中獲得寶貴的資訊進而改進決策，同時，隨著時間的推移，資料倉庫中積累的大量歷史資料對于資料科學家和業務分析師也是十分寶貴的，

目前大資料平臺的架構有以下三種架構:

①  資料倉庫(Data Warehouse)是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化的（Time Variant）資料集合，用于支持管理決策和資訊的全域共享，

②  資料湖（Data Lake）是一個存盤企業的各種各樣原始資料的大型倉庫，其中的資料可供存取、處理、分析及傳輸，資料湖是以其自然格式存盤的資料的系統或存盤庫，通常是物件blob或檔案，

③  湖倉一體(Data LakeHouse): 為企業提供一個統一的、可共享的資料底座，避免傳統的資料湖、資料倉庫之間的資料移動，將原始資料、加工清洗資料、模型化資料，共同存盤于一體化的“湖倉”中，既能面向業務實作高并發、精準化、高性能的歷史資料、實時資料的查詢服務，又能承載分析報表、批處理、資料挖掘等分析型業務，

1.1資料倉庫的核心架構

1.2 資料倉庫建模的意義

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

資料模型就是資料組織和存盤方法，它強調從業務、資料存取和使用角度合理存盤資料，只有將資料有序的組織和存盤起來之后，資料才能得到高性能、低成本、高效率、高質量的使用，

高性能：良好的資料模型能夠幫助我們快速查詢所需要的資料，

低成本：良好的資料模型能減少重復計算，實作計算結果的復用，降低計算成本，

高效率：良好的資料模型能極大的改善用戶使用資料的體驗，提高使用資料的效率，

高質量：良好的資料模型能改善資料統計口徑的混亂，減少計算錯誤的可能性，

1.2 資料倉庫建模方法論

1.2.1 ER模型

資料倉庫之父Bill Inmon提出的建模方法是從全企業的高度，用物體關系（Entity Relationship，ER）模型來描述企業業務，并用規范化的方式表示出來，在范式理論上符合3NF，

1）物體關系模型

物體關系模型將復雜的資料抽象為兩個概念——物體和關系，物體表示一個物件，例如學生、班級，關系是指兩個物體之間的關系，例如學生和班級之間的從屬關系，

2）資料庫規范化

資料庫規范化是使用一系列范式設計資料庫（通常是關系型資料庫）的程序，其目的是減少資料冗余，增強資料的一致性，

這一系列范式就是指在設計關系型資料庫時，需要遵從的不同的規范，關系型資料庫的范式一共有六種，分別是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF），遵循的范式級別越高，資料冗余性就越低，

3）三范式

    省略………………

下圖為一個采用Bill Inmon倡導的建模方法構建的模型，從圖中可以看出，較為松散、零碎，物理表數量多，

這種建模方法的出發點是整合資料，其目的是將整個企業的資料進行組合和合并，并進行規范處理，減少資料冗余性，保證資料的一致性，這種模型并不適合直接用于分析統計，

1.2.2 維度模型

資料倉庫領域的令一位大師——Ralph Kimball倡導的建模方法為維度建模，維度模型將復雜的業務通過事實和維度兩個概念進行呈現，事實通常對應業務程序，而維度通常對應業務程序發生時所處的環境，

注：業務程序可以概括為一個個不可拆分的行為事件，例如電商交易中的下單，取消訂單，付款，退單等，都是業務程序，

下圖為一個典型的維度模型，其中位于中心的SalesOrder為事實表，其中保存的是下單這個業務程序的所有記錄，位于周圍每張表都是維度表，包括Date（日期），Customer（顧客），Product（產品），Location（地區）等，這些維度表就組成了每個訂單發生時所處的環境，即何人、何時、在何地下單了何種產品，從圖中可以看出，模型相對清晰、簡潔，

維度建模以資料分析作為出發點，為資料分析服務，因此它關注的重點的用戶如何更快的完成需求分析以及如何實作較好的大規模復雜查詢的回應性能，

1.3維度建模之事實表

事實表是維度建模的核心表和基本表，

它存盤了業務程序中的各種度量和事實，而這些度量和事實正是下游資料使用人員所要關心和分析的物件，

目前事實表主要探討三種：

• · 事務事實表
• · 快照事實表
• · 累計快照事實表

還有一種特殊的事實表——無事實的事實表，最后還將討論事實表的聚集和匯總，

1.3.1事務事實表

事務事實表是維度建模事實表中最為常見、使用最為廣泛的事實表，

事務事實表通常用于記錄業務程序的事件，而且是原子粒度的事件，事務事實表中的資料在事務事件發生之后，資料的粒度通常是每個事務一條記錄，一旦事務被提交，事實表資料被插入，資料就不再進行更改，

我們通過事務事實表存盤單次業務事件 / 行為的細節，以及存盤與事件相關的維度細節，用戶即可以單獨或者聚合分析業務事件和行為，

事務事實表的粒度確定是事務事實表設計程序中的關鍵步驟，一般都會包含可加的度量和事實，理解概念的最佳途徑無疑是實際的例子，因此下面將結合超市零售業務以及維度建模的四個環節來說明事務事實表，

（1）選擇業務程序

在超市的零售示例中，業務用戶做的事情是更好的理解POS系統記錄顧客購買的情況，那么很容易確定業務程序就是POS系統記錄的顧客購買情況，即在什么時候、什么商品、哪個收銀臺、銷售了哪些產品等，

（2）定義粒度

顧客單次購買行為的體現是一張購物小票，但是事務事實表應該選擇最原子粒度的事件，所以小票的子項（在業務上的動作即為收銀員每次掃描的商品條碼）應該是超市零售事務事實表的粒度，

（3）確定維度

小票子項的粒度確定后，銷售日期、銷售商品、銷售收銀臺、銷售門店等維度很容易被確定了，另一個不太容易考慮到的是維度是促銷行為，但是通過和業務人員交流或者查看報表表頭等也能夠發現此維度，

（4）確定事實

維度設計的最后一步，是確定哪些事實和度量應該在事實表中出現，對于本例，商品銷售數量、銷售價格和銷售金額很容易確定下來，但是實際上，商品的成本價是確定的，因此可以很容易地確定商品的銷售毛利：（商品實際銷售價格－商品成本價） 銷售數量，基于下游使用便利這一因素，也應該將此放人事務事實表中，

基于毛利潤也可以計算出毛利率，那么毛利率這種比例應該放入事務事實表嗎？在事實表的設計中，一個常見的原則是只存放比例的分子和分母，因此比例的計算是和業務強，業務邏輯可能非常的復雜，所以一般不加入事實表中，

至此，我們也完成了超市零售事務的事實表和維度表的設計，超市零售事務事實表以及相關的維度表如圖所示：

1.3.2快照事實表

在實際的業務活動中，除了關心單次的業務事件和行為外，很多時候還關心業務的狀態（當前狀態、歷史狀態），以超市零售業務為例，管理人員和分析人員除了關心銷售情況，還會關心商品的庫存情況，例如哪些商品的庫存情況，例如哪些商品庫存告罄需要補貨、哪些積壓需要促銷，而這正是快照事實表（也叫周期快照事實表）所要解決發范疇，

所謂周期快照事實表，是指間隔一定的周期對業務的狀態進行一次拍照并記錄下來的事實表，最常見的例子是銷售庫存、銀行賬戶余額等，

與事務事實表的稀疏性不同（這里的稀疏性是相對的），周期快照事實表通常被認為是稠密的，因此事務事實表只有事務發生才會記錄，但是周期快照則必須捕獲當前每個物體的狀態，

比如，某個商品如果某天沒有銷售，那么這個商品不會存在于當天的事務事實表中的，但是為了記錄其庫存情況，即使沒有銷售行為，也必須再周期快照事實表中對其進行拍照，

周期快照事實表的周期通常需要和業務方共同確定，最常見的周期是天、周和月等，

周期快照事實表中的事實一般是半可加的，如某個商品的庫存可以跨商品、倉庫等相加，但是明顯在時間上相加是沒有意義的，

下面就以超市的庫存業務為例來介紹周期快照事實表的設計程序，

（1）選擇業務程序

本例是為了更好地理解超市的庫存情況，因此業務程序就是商品的庫存情況，即在什么時候、什么商品、哪個倉庫的庫存量如何，

（2）定義粒度

這里的粒度主要指庫存的周期，商品的粒度很容易確定（注意這里是 SKU 級別），選擇庫存的周期需要考慮到資料量膨脹情況，

考慮如下例子，某個超市有 萬個商品（即SKU）， 其有 100 家連鎖店，那么每天對其庫存拍照將有 100*10000=100 萬行記錄，那么一年將有 365*1000000=3.65億條記錄，當然隨著目前存盤的日益廉價，這些都不是問題，但是設計人員需要考慮到這些因素，

（3）確認維度

對于超市零售庫存，相應的維度為周期（天 周、月等） 商品、倉庫（總倉、分倉或者門店等），

（4）確定事實

這里的事實很容易確定，即庫存量，但是僅僅記錄現存庫存是不夠充分的，因為業務上通常會和其他事實協同來度量庫存的變化趨勢、快慢等，所以還可對周期快照事實表的事實進行增強 ，

基于上述設計的周期快照事實表及相關維度如圖所示：

1.3.3累計快照事實表

事實表的第三種型別是累計快照事實表，相比前兩者，累計快照事實表沒那么常見，但是對于某些業務場景來說非常有價值，

累計快照事實表非常適用于具有作業流或者流水線形式業務的分析，這些業務通常涉及多個時間節點或者有主要的里程碑事件，而累計快照事實表正是從全流程角度對其業務狀態的拍照，

考慮車險理賠業務，一次車險的理賠通常包括客戶報案、保險公司立案、客戶提交理賠材料、理賠審批通過和付款等關鍵步驟，而累積快照事實表正是從全流程角度對每個車險理賠單的拍照，拍照內容即是其關鍵步驟的各個狀態，便于業務人員一目了然地分析各個理賠單的狀態、步驟間的耗時等，

下面以車險理賠業務為例來介紹累計周期快照事實表，

（1）選擇業務程序

本例是為了更好地理解保險公司的車險理賠業務，因此業務程序就是車險理賠，即在什么時候、 哪個理賠申請所處的狀態如何，

（2）定義粒度

累計周期快照事實表的粒度一般很容易確定，就是業務的某個物體，這里即為保險理賠申請，

（3）確定維度

對于累計周期快照事實表，相關的維度包含快照周期（天、周、月 和年等）、理賠申請人、受理 、審核人、網點 電話或者物體）等，

（4）確定事實

這里的事實包括索賠金額、審批金額、打款金額、處理時長等，

1.3.4無事實的事實表

在維度建模中，事實表是程序度量的核心，也是存盤度量的地方 但事實表并不總是需要包含度量和事實，這類不包含事實的事實表被稱為 無事實的事實表，

乍一聽有點奇怪，但是請考慮下面業務場景，銀行客戶服務中心接受客戶電話咨詢或者在線業務咨詢，這里并沒有任務的業務度量值，唯一的度量值就是單次咨詢事件，其他類似事件還有學生課程出席情況、用戶在網站上的瀏覽行為、客戶對廣告的點擊行為等，

無事實的事實表通常人為增加一個常量列（其列的值總是為 1) 來方便對業務時間的統計分析，其實就是類似于事務事實表的特殊情況，

以學生在各門課程中的出席情況為例給出無事實的事實表的維度設計方案：

1.3.5總結

在經典的維度建模事實表設計中，事實表將僅存盤維度表外鍵、選定的度量以及退化維度等，例如我們前面提到的超市零售事務事實表，

這樣的設計主要是出于存盤的成本以及處理的性能考慮 ，如果把維度的屬性欄位等都放在事實表中，那么將帶來大量的存盤開銷，而且處理性能也將大大受到影響，但是在大資料時代，隨著 HDFS、MapReduce 為代表的各種分布式存盤和計算技術的發展，存盤成本以及性能等不再是關鍵，所以在維度建模理論反規范化思想的基礎上，可以更進一步地把常用的維度屬性沉淀在事實表中，這樣下游使用更為直接和便捷，不需要每次都關聯相關維度表獲取有關維度屬性 也就是說，以存盤的冗余為代價，換來了下游的使用便捷以及多次關聯計算開銷，而在大資料時代，這是完全劃算的，

1.4 維度建模之維度表

1.4.1 維度表概述

維度表是維度建模的基礎和靈魂，前文提到，事實表緊緊圍繞業務程序進行設計，而維度表則圍繞業務程序所處的環境進行設計，維度表主要包含一個主鍵和各種維度欄位，維度欄位稱為維度屬性，

1.4.2 維度表設計步驟

1）確定維度（表）

在設計事實表時，已經確定了與每個事實表相關的維度，理論上每個相關維度均需對應一張維度表，需要注意到，可能存在多個事實表與同一個維度都相關的情況，這種情況需保證維度的唯一性，即只創建一張維度表，另外，如果某些維度表的維度屬性很少，例如只有一個**名稱，則可不創建該維度表，而把該表的維度屬性直接增加到與之相關的事實表中，這個操作稱為維度退化，

2）確定主維表和相關維表

此處的主維表和相關維表均指業務系統中與某維度相關的表，例如業務系統中與商品相關的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就稱為商品維度的主維表，其余表稱為商品維度的相關維表，維度表的粒度通常與主維表相同，

3）確定維度屬性

確定維度屬性即確定維度表欄位，維度屬性主要來自于業務系統中與該維度對應的主維表和相關維表，維度屬性可直接從主維表或相關維表中選擇，也可通過進一步加工得到，

確定維度屬性時，需要遵循以下要求：

（1）盡可能生成豐富的維度屬性

維度屬性是后續做分析統計時的查詢約束條件、分組欄位的基本來源，是資料易用性的關鍵，維度屬性的豐富程度直接影響到資料模型能夠支持的指標的豐富程度，

（2）盡量不使用編碼，而使用明確的文字說明，一般可以編碼和文字共存，

（3）盡量沉淀出通用的維度屬性

有些維度屬性的獲取需要進行比較復雜的邏輯處理，例如需要通過多個欄位拼接得到，為避免后續每次使用時的重復處理，可將這些維度屬性沉淀到維度表中，

1.4.3維度的設計要求

1.4.3.1 規范化與反規范化

規范化是指使用一系列范式設計資料庫的程序，其目的是減少資料冗余，增強資料的一致性，通常情況下，規范化之后，一張表的欄位會拆分到多張表，

反規范化是指將多張表的資料冗余到一張表，其目的是減少join操作，提高查詢性能，

在設計維度表時，如果對其進行規范化，得到的維度模型稱為雪花模型，如果對其進行反規范化，得到的模型稱為星型模型，

資料倉庫系統的主要目的是用于資料分析和統計，所以是否方便用戶進行統計分析決定了模型的優劣，采用雪花模型，用戶在統計分析的程序中需要大量的關聯操作，使用復雜度高，同時查詢性能很差，而采用星型模型，則方便、易用且性能好，所以出于易用性和性能的考慮，維度表一般是很不規范化的，

1.4.3.2 維度變化

維度屬性通常不是靜態的，而是會隨時間變化的，資料倉庫的一個重要特點就是反映歷史的變化，所以如何保存維度的歷史狀態是維度設計的重要作業之一，保存維度資料的歷史狀態，通常有以下兩種做法，分別是全量快照表和拉鏈表，

1）全量快照表

離線資料倉庫的計算周期通常為每天一次，所以可以每天保存一份全量的維度資料，這種方式的優點和缺點都很明顯，

優點是簡單而有效，開發和維護成本低，且方便理解和使用，

缺點是浪費存盤空間，尤其是當資料的變化比例比較低時，

2）拉鏈表

拉鏈表的意義就在于能夠更加高效的保存維度資訊的歷史狀態，

1.4.3.3 多值維度

如果事實表中一條記錄在某個維度表中有多條記錄與之對應，稱為多值維度，例如，下單事實表中的一條記錄為一個訂單，一個訂單可能包含多個商品，所會商品維度表中就可能有多條資料與之對應，

針對這種情況，通常采用以下兩種方案解決，

第一種：降低事實表的粒度，例如將訂單事實表的粒度由一個訂單降低為一個訂單中的一個商品項，

第二種：在事實表中采用多欄位保存多個維度值，每個欄位保存一個維度id，這種方案只適用于多值維度個數固定的情況，

建議盡量采用第一種方案解決多值維度問題，

1.4.3.4 多值屬性

維表中的某個屬性同時有多個值，稱之為“多值屬性”，例如商品維度的平臺屬性和銷售屬性，每個商品均有多個屬性值，

針對這種情況，通常有可以采用以下兩種方案，

第一種：將多值屬性放到一個欄位，該欄位內容為key1:value1，key2:value2的形式，例如一個手機商品的平臺屬性值為“品牌:華為，系統:鴻蒙，CPU:麒麟990”，

第二種：將多值屬性放到多個欄位，每個欄位對應一個屬性，這種方案只適用于多值屬性個數固定的情況，

2. 資料倉庫的設計與實施

2.1 指導方針

首先，在建設資料倉庫時，要進行充分的業務調研和需求分析，業務調研和需求分析做得是否充分直接決定了資料倉庫建設是否成功；其次，進行資料總體架構設計，主要是根據資料域對資料進行劃分，按照維度建模理論，構建總線矩陣、抽象出業務程序和維度；再次，對報表需求進行抽象整理出相關指標體系，依據工具完成指標規范定義和模型設計；最后，就是代碼研發和運維，

2.2. 實施作業流程

2.2.1資料調研

2.2.1.1業務調研

資料倉庫的建設是要涵蓋所有業務領域，還是各個業務領域獨自建設，業務領域內的業務線也同樣會面臨著這個問題，所以構建大資料倉庫，就需要了解各個業務領域、業務線的業務有什么共同點和不同點 ，以及各個業務線可以細分為哪幾個業務模塊，每個業務模塊具體的業務流程又是怎樣的，在數倉建設專案啟動前，可以請相關的業務人員介紹具體的業務，以便明確各個團隊的分析、運營人員的需求，可以詳細了解以下資訊：

1. 組織架構和分工界面，各個部門對數倉的需求不同，需要對不同部門分別進行調研（例如，資料分析、運營、維護部門），--沒做
2. 整體業務架構，各個業務模塊之間的聯系與資訊流動的流程，梳理出整體的業務資料框架，--沒有
3. 各個已有的業務系統的主要功能及獲取的資料，--有個框架

以電商業務為例，公司的電商業務板塊分為招商、供應鏈、營銷、服務四個板塊，梳理出各業務板塊的需求資料框架如下圖所示，

此外，還需要進一步了解各業務板塊中已有的業務流程，業務流程通常與業務板塊緊密耦合，對應一個或多個表及其所屬資料源，可以作為構建數倉的原始資料來源，

2.2.1.2需求調研

在未考慮資料分析師、業務運營人員資料需求的情況下，單純根據業務調研建設的資料倉庫，可能可用性較差，完成業務調研后，需要進一步收集資料使用者的需求，進而對需求進行深度思考和分析，并改進資料倉庫，

需求分析的途徑有兩種：

• 通過與分析師、業務運營人員的溝通獲知需求，
• 對報表系統中現有的報表進行研究分析，

在需求分析階段，您需要沉淀出業務分析或報表中的指標，以及指標的定義和粒度，粒度可以作為維度的輸入，建議您思考下列問題，對后續的資料建模將有巨大的幫助：

• 業務資料是根據什么（維度、統計粒度，簡稱“粒度”，是維度或維度組合）匯總的，衡量標準是什么？例如，“省份”或者“類目”是維度，訂單數是原子指標，
• 基于上個問題，進一步思考明細資料層的事實模型和公共可參考的維度模型、匯總資料層的匯總模型應該如何設計？是否有公共使用，命名及邏輯相似的統計指標，目前已經重復建設使用，需要通過上述設計規范化？

舉例： 資料分析師需要了解A公司電商業務中最近1天廚具類目的成交金額，

1. 當獲知這個需求后，您需要分析：根據什么（維度）匯總、匯總什么（原子指標）、匯總的范圍有多大（業務范圍即業務限定，時間范圍即統計周期），例如，類目是統計粒度（基于維度），成交金額的總和是原子指標，該案例中，粒度應該是“類目”，“類目為廚具”是業務限定，最近1天是統計周期，

說明 本例從類目為統計粒度的角度，分析需求處理，您可以在即席查詢中定義匯總模型的篩選過濾條件，設定統計粒度的維度屬性值為廚具，以免匯總模型資料稀疏，在真實業務場景下，可以根據業務需求、使用頻度、復用性及匯總層資料計算存盤進行考慮，拆解分析，例如，本例中還可以定義全表為粒度，只是該粒度中無需維度，然后定義業務限定是類目為廚具，其他保持不變，如無特殊資料情況，也可得到相同資料結果，只是計算存盤程序消耗可能有不同，上述案例，不同路徑，組合定義出來的派生指標，可能是相同結果，但是命名、計算邏輯實作可能略有不同，目前Dataphin上對于該類派生指標，認為是不同業務場景的指標，不進行強制去重，

2. 基于上述拆解，您還需要進一步思考并設計明細資料層的事實模型（原子指標中成交金額的資料來源）、公共可參考的維度模型（統計粒度的來源，且需要與成交金額所屬事實模型有關聯關系）和匯總資料層模型（原子指標、業務限定、統計周期的拆解和定義方式），

需求調研的分析產出通常是記錄業務需求的規范定義檔案（派生指標、原子指標、業務限定、統計周期、統計粒度（即維度）），結合業務調研情況，您可以進一步產出設計明細邏輯模型設計檔案（維度模型、事實模型）與概念模型設計檔案（維度、業務程序及其關系），

2.2.2數倉分層

2.2.2.1數倉分層概述

基于阿里巴巴OneData方法論最佳實踐，在阿里巴巴的資料體系中，建議將資料倉庫分為三層：資料引入層（ODS，Operational Data Store）、資料公共層（CDM，Common Dimenions Model）和資料應用層（ADS，Application Data Store），

資料倉庫自頂向下的分層和各層用途如下圖所示，

• 資料引入層（ODS，Operational Data Store，又稱資料基礎層）：將原始資料幾乎無處理地存放在資料倉庫系統中，結構上與源系統基本保持一致，是資料倉庫的資料準備區，這一層的主要職責是將基礎資料同步、存盤到MaxCompute，
• 資料公共層（CDM，Common Dimenions Model）：存放明細事實資料、維表資料及公共指標匯總資料，其中，明細事實資料、維表資料一般根據ODS層資料加工生成，公共指標匯總資料一般根據維表資料和明細事實資料加工生成，

CDM層又細分為維度層（DIM）、明細資料層（DWD）和匯總資料層（DWS），采用維度模型方法作為理論基礎， 可以定義維度模型主鍵與事實模型中外鍵關系，減少資料冗余，也提高明細資料表的易用性，在匯總資料層同樣可以關聯復用統計粒度中的維度，采取更多的寬表化手段構建公共指標資料層，提升公共指標的復用性，減少重復加工，

• 維度層（DIM，Dimension）：以維度作為建模驅動，基于每個維度的業務含義，通過添加維度屬性、關聯維度等定義計算邏輯，完成屬性定義的程序并建立一致的資料分析維表，為了避免在維度模型中冗余關聯維度的屬性，基于雪花模型構建維度表，

在Dataphin中，維度層的表通常也被稱為維度邏輯表，

• 明細資料層（DWD，Data Warehouse Detail）：以業務程序作為建模驅動，基于每個具體的業務程序特點，構建最細粒度的明細事實表，可以結合企業的資料使用特點，將明細事實表的某些重要屬性欄位做適當冗余，也即寬表化處理，

在Dataphin中，明細資料層的表通常也被稱為事實邏輯表，

• 匯總資料層（DWS，Data Warehouse Summary）：以分析的主題物件作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標表，以寬表化手段物理化模型，構建命名規范、口徑一致的統計指標，為上層提供公共指標，建立匯總寬表、明細事實表，

在Dataphin中，匯總資料層的表通常也被稱為匯總邏輯表，用于存放派生指標資料，

• 資料應用層（ADS，Application Data Store）：存放資料產品個性化的統計指標資料，根據CDM層與ODS層加工生成，

2.2.2.1各層的具體如何設計

（1) ODS(資料引入層)

ODS層存放您從業務系統獲取的最原始的資料，是其他上層資料的源資料，業務資料系統中的資料通常為長期累積的、非常細節的資料，且訪問頻率很高，是面向應用的資料，

1）資料引入層表設計

在ODS層主要包括的資料有：交易系統訂單詳情、用戶資訊詳情、商品詳情等，這些資料未經處理，是最原始的資料，在邏輯層面上，這些資料都是以二維表的形式存盤，嚴格地說，雖然ODS層不屬于數倉建模的范疇，但是合理地規劃ODS層并做好資料同步也非常重要，本教程中，使用了6張ODS表：

• 記錄用于拍賣的商品資訊：s_auction，
• 記錄用于正常售賣的商品資訊：s_sale，
• 記錄用戶詳細資訊：s_users_extra，
• 記錄新增的商品成交訂單資訊：s_biz_order_delta，
• 記錄新增的物流訂單資訊：s_logistics_order_delta，
• 記錄新增的支付訂單資訊：s_pay_order_delta，

說明

• 表或欄位命名盡量和業務系統保持一致，但是需要通過額外的標識來區分增量和全量表，在Dataphin中，di后綴的事實模型為增量表（事務型），df后綴的事實模型為全量表（周期快照型），
• 命名時需要特別注意沖突處理，例如，不同業務系統的表可能是同一個名稱，為區分兩個不同的表，您可以將這兩個同名表的來源資料庫名稱作為后綴或前綴，例如，表中某些欄位的名稱剛好和關鍵字重名了，可以通過規范定義后綴添加_col1解決，

2）ODS層設計規范

ODS層表命名、資料同步任務命名、資料產出及生命周期管理、資產質量規范，詳情請參見ODS層設計規范，

3）資料同步加載與處理

ODS的資料需要由各資料源系統同步、存盤到MaxCompute，才能用于進一步的資料開發，本教程建議您使用Dataphin的資料引入功能完成資料同步，詳情請參見概述，在使用資料引入功能的程序中，建議您遵循以下規范：

一個系統的源表只允許同步一次到MaxCompute，保持表結構的一致性，

資料引入支持全量資料同步、實時增量資料同步（分鐘或小時調度實作）兩種同步方式，

ODS層的表建議以統計日期及時間磁區表的方式存盤，便于管理資料的存盤成本和策略控制，Dataphin中默認時間磁區的名字為ds，

資料引入支持手動調整源表和目標表的同步欄位，

如果源表欄位在目標表中不存在，用戶需手動添加目標欄位，或洗掉源表欄位，

如果源表欄位與目標表欄位不匹配，用戶需先洗掉目標欄位，然后重新添加與之匹配的欄位，

（2) DIM(維度層)

參看章節1.4維度建模之維度表，

（3) DWD(明細資料層)

    參看章節1.3維度建模之事實表，

（4) DWS(匯總資料層)

匯總資料層以分析的主題物件作為建模驅動，基于上層的應用和產品的指標需求構建公共粒度的匯總表，匯總資料層的一個表通常會對應一個統計粒度（維度或維度組合）及該粒度下若干派生指標，

1)匯總表設計原則

聚集是指標對原始明細粒度的資料進行匯總，DWS匯總資料層是面向分析物件的主題聚集建模，在本教程中，最終的分析目標為：最近一天某個類目（例如，廚具）商品在各省的銷售總額、該類目銷售額Top10的商品名稱、各省用戶購買力分布，因此，我們可以以最終交易成功的商品、類目、買家等角度對最近一天的資料進行匯總，資料聚集的注意事項如下：

• 聚集是不跨越事實的，聚集是針對原始星形模型進行的匯總，為獲取和查詢與原始模型一致的結果，聚集的維度和度量必須與原始模型保持一致，因此聚集是不跨越事實的，所以原子指標只能基于一張事實表定義，但是支持原子指標組合為衍生原子指標，
• 聚集會帶來查詢性能的提升，但聚集也會增加ETL維護的難度，當子類目對應的一級類目發生變更時，先前存在的、已經被匯總到聚集表中的資料需要被重新調整，

此外，進行DWS層設計時還需遵循資料公用性原則，資料公用性需要考慮匯總的聚集是否可以提供給第三方使用，您可以思考，基于某個維度的聚集是否經常用于資料分析中，如果答案是肯定的，就有必要把明細資料經過匯總沉淀到聚集表中，

2)匯總表規范

公共匯總表命名規范：dws_統計粒度， 舉例如下：

• dws_report（report匯總表）
• dws_user（user匯總表）

3)創建匯總表

匯總模型的設計參考整理出的指標體系（主要是派生指標）即可，匯總表與派生指標的對應關系是，一張匯總表通常包含業務程序相同、統計周期相同、統計粒度相同的多個派生指標，

2.2.3 建模設計

2.2.3.1資料域劃分

資料倉庫是面向主題的應用，主要功能是將資料綜合、歸類并進行分析利用，資料倉庫模型設計除橫向的分層外，通常還需要根據業務情況縱向劃分資料域，資料域是聯系較為緊密的資料主題的集合，是業務物件高度概括的概念層次歸類，目的是便于資料的管理和應用，

通常您需要閱讀各源系統的設計檔案、資料字典和資料模型設計檔案，研究逆向匯出的物理資料模型，然后，進行跨源的主題域合并，梳理出整個企業的資料域，

資料域是指面向業務分析，將業務程序或維度進行抽象的集合，為保障整個體系的生命力，資料域需要抽象提煉，并長期維護更新，但不輕易變動，劃分資料域時，需滿足以下兩點：

• 能涵蓋當前所有的業務需求，
• 能在新業務進入時，無影響地被包含進已有的資料域中和擴展新的資料域，

在業務調研之后，可以進行資料域的劃分，劃分資料域，需要分析各個業務模塊中有哪些業務活動，資料域，可以按照用戶企業的部門劃分，也可以按照業務程序或者業務板塊中的功能模塊劃分，

例子1 A公司電商營銷業務板塊

A公司電商營銷業務板塊可以劃分為如下表所示的資料域，資料域中的每一部分，都是根據實際業務程序進行歸納、抽象得出的，

例子2 零售事業群的業務行態

零售事業群的業務行態分兩大塊，線上自營電商和線下商超，所涉及的主要業務流程有：

例子3 馬蜂窩數倉主題、主題域劃分

馬蜂窩數倉主題、主題域劃分案例

以馬蜂窩訂單交易模型的建設為例，基于業務生產總線的設計是常見的模式，首先調研訂單交易的完整程序，定位程序中的關鍵節點，確認各節點上發生的核心事實資訊，

例子4 網易云音樂數倉主題、主題域劃分

網易云音樂數倉主題、主題域劃分案例

網易云音樂將一級主題域劃分為參與者、服務及產品，著作權及協議、公共、事實這5個大的主題域，二級細節分類按照業務程序抽象獲得，

2.2.3.2構建總線矩陣

在進行充分的業務調研和需求調研后，就要構建總線矩陣了，需要做兩件事情 :明確每個資料域下有哪些業務程序;業務程序與哪些維度相關，并定義每個資料域下的業務程序和維度，

例子1:

例子2:

例子3:

一個業務程序對應維度模型中一張事務型事實表，一個維度則對應維度模型中的一張維度表，所以構建業務總線矩陣的程序就是設計維度模型的程序，但是需要注意的是，總線矩陣中通常只包含事務型事實表，另外兩種型別的事實表需單獨設計，

按照事務型事實表的設計流程，選擇業務程序à宣告粒度à確認維度à確認事實，得到的最終的業務總線矩陣需要包括度量值，

2.2.3.3明確統計指標

明確統計指標具體的作業是，深入分析需求，構建指標體系，構建指標體系的主要意義就是指標定義標準化，所有指標的定義，都必須遵循同一套標準，這樣能有效的避免指標定義存在歧義，指標定義重復等問題，

1）指標體系相關概念

（1）原子指標

原子指標基于某一業務程序的度量值，是業務定義中不可再拆解的指標，原子指標的核心功能就是對指標的聚合邏輯進行了定義，我們可以得出結論，原子指標包含三要素，分別是業務程序、度量值和聚合邏輯，

例如訂單總額就是一個典型的原子指標，其中的業務程序為用戶下單、度量值為訂單金額，聚合邏輯為sum()求和，需要注意的是原子指標只是用來輔助定義指標一個概念，通常不會對應有實際統計需求與之對應，

（2）派生指標

派生指標基于原子指標，其與原子指標的關系如下圖所示，

與原子指標不同，派生指標通常會對應實際的統計需求，請從圖中的例子中，體會指標定義標準化的含義，

（3）衍生指標

衍生指標是在一個或多個派生指標的基礎上，通過各種邏輯運算復合而成的，例如比率、比例等型別的指標，衍生指標也會對應實際的統計需求，

2）指標體系對于數倉建模的意義

通過上述兩個具體的案例可以看出，絕大多數的統計需求，都可以使用原子指標、派生指標以及衍生指標這套標準去定義，同時能夠發現這些統計需求都直接的或間接的對應一個或者是多個派生指標，

當統計需求足夠多時，必然會出現部分統計需求對應的派生指標相同的情況，這種情況下，我們就可以考慮將這些公共的派生指標保存下來，這樣做的主要目的就是減少重復計算，提高資料的復用性，

這些公共的派生指標統一保存在資料倉庫的DWS層，因此DWS層設計，就可以參考我們根據現有的統計需求整理出的派生指標，

標籤：大數據

上一篇：線上sql執行慢，分享3個優化案例

下一篇：gt-checksum 1.2.1發布，新增表結構校驗及修復等超實用特性