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層設計，就可以參考我們根據現有的統計需求整理出的派生指標。