對於數倉的分層，大家最耳熟能詳的就是基於 OneData 方法論的三層數倉劃分，分別是：數據引入層（ODS，Operational Data Store）、數據公共層（CDM，Common Dimenions Model）和數據應用層（ADS，Application Data Store）。
當然，涉及到每一層具體該怎麼建模，可能大家都有自己的理解。數據建模無疑是重中之重，如果我們把指標比作樹上的果實，那麼模型就好比是大樹的軀幹，想讓果實結得好，必須讓樹幹變得粗壯。
我們先來回想下，構建數據中臺的初衷是什麼：
-
沒有可以複用的數據，
-
大家不得不使用原始數據進行清洗、加工和計算指標...
這根源就在於數據模型的無法複用，數據開發都是煙囪式的。所以要解決這個問題，就要搞清楚健壯的數據模型該如何設計。
常見的數倉分層設計思路
下圖是數倉分層的邏輯架構圖，大家不妨回憶一下數據模型的分層設計：
-
數據引入層（ODS，Operational Data Store，又稱數據基礎層）：將原始數據幾乎無處理地存放在數據倉庫系統中，結構上與源系統基本保持一致，是數據倉庫的數據準備區。這一層的主要職責是將基礎數據同步、存儲。
-
數據公共層（CDM，Common Dimenions Model）：存放明細事實數據、維表數據及公共指標彙總數據。其中，明細事實數據、維表數據一般根據 ODS 層數據加工生成。公共指標彙總數據一般根據維表數據和明細事實數據加工生成。CDM 層又細分爲維度層（DIM）、明細數據層（DWD）和彙總數據層（DWS），採用維度模型方法作爲理論基礎， 可以定義維度模型主鍵與事實模型中外鍵關係，減少數據冗餘，也提高明細數據表的易用性。在彙總數據層同樣可以關聯複用統計粒度中的維度，採取更多的寬表化手段構建公共指標數據層，提升公共指標的複用性，減少重複加工。
-
維度層（DIM，Dimension）：以維度作爲建模驅動，基於每個維度的業務含義，通過添加維度屬性、關聯維度等定義計算邏輯，完成屬性定義的過程並建立一致的數據分析維表。爲了避免在維度模型中冗餘關聯維度的屬性，基於雪花模型構建維度表。
-
明細數據層（DWD，Data Warehouse Detail）：以業務過程作爲建模驅動，基於每個具體的業務過程特點，構建最細粒度的明細事實表。可將某些重要屬性字段做適當冗餘，也即寬表化處理。
-
彙總數據層（DWS，Data Warehouse Summary）：以分析的主題對象作爲建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標表。以寬表化手段物理化模型，構建命名規範、口徑一致的統計指標，爲上層提供公共指標，建立彙總寬表、明細事實表。
-
數據應用層（ADS，Application Data Store）：存放數據產品個性化的統計指標數據，根據 CDM 層與 ODS 層加工生成。
DWS 層很重要？
通常，大家都會有這樣的疑問：明明可以直接從 DWD 層取數，爲什麼要多此一舉建立 DWS 的彙總邏輯表呢？
我想說的是：如果在業務場景不復雜的情況下，那樣做是沒有問題的。可一旦面對複雜的業務場景，那這種做法無疑是混亂的根源所在，前面提到的煙囪式開發、計算資源的浪費等等情況，正是這樣產生的。
我們需要的是從數據明細層中做一個初步的彙總，抽象出來一些通用的維度：時間、用戶 ID、IP 等，並根據這些維度做一些統計，比如用戶每個時間段在不同登錄 IP 購買的商品數等。
這裏做一層輕度的彙總會讓計算更加的高效，在此基礎上如果計算僅 7 天、30 天、90 天的行爲的話會快很多。我們希望 80%的業務都能通過我們的 DWS 層計算，而不是 ODS 或者 DWD。
應該遵循的設計原則
聚集是指針對原始明細粒度的數據進行彙總。DWS 彙總數據層是面向分析對象的主題聚集建模，以零售的場景爲例，我們最終的分析目標爲：最近一天某個類目（例如，廚具）商品在各省的銷售總額、該類目銷售額 Top10 的商品名稱、各省用戶購買力分佈。
因此，我們可以以最終交易成功的商品、類目、買家等角度對最近一天的數據進行彙總。數據聚集的注意事項如下：
-
聚集是不跨越事實的。聚集是針對原始星形模型進行的彙總。爲獲取和查詢與原始模型一致的結果，聚集的維度和度量必須與原始模型保持一致，因此聚集是不跨越事實的，所以原子指標只能基於一張事實表定義，但是支持原子指標組合爲衍生原子指標。
-
聚集會帶來查詢性能的提升，但聚集也會增加 ETL 維護的難度。當子類目對應的一級類目發生變更時，先前存在的、已經被彙總到聚集表中的數據需要被重新調整。
此外，進行 DWS 層設計時還需遵循數據公用性原則。數據公用性需要考慮彙總的聚集是否可以提供給第三方使用。我們可以思考基於某個維度的聚集是否經常用於數據分析中，如果答案是肯定的，就有必要把明細數據經過彙總沉澱到聚集表中。
簡單的說就是：
-
主題
-
寬表
-
輕度彙總
圖解 DWS 層設計流程
以電商零售的場景爲例，我們已經基於 ODS 層的訂單表、用戶表、商品表、優惠券表等，經過 ETL 完成了 DWD 層的建模，一般是採用星型模型。
這裏嚴格按照：業務過程→聲明粒度→確認維度→確認事實 完成建模，過程如下：
接下來，便是到了 DWS 層設計的環節。按照我們上面的設計思路，通過從維度表去看事實表，便可得出每天的寬表。
這樣即可統計各個主題對象的當天行爲，服務於 ADS 層的主題寬表以及一些業務的明細數據，也可以以應對一些特殊的需求，例如：購買行爲，統計商品復購率等。
通過外鍵獲取相關的度量值，我們整合多個 DWD 的明細事實表度量值來構成新表。
在這裏，我們還是要遵循上文提到的設計原則，在設計上儘量體現出公共性、使用簡單並且用戶很容易理解。
思考：如何設計出完美的 DWS 層？
在我們數據中臺實際實施落地的過程中，團隊不但要建設公共數據層，形成數據中臺，還要承擔着新需求的壓力。
往往我們要先滿足需求（活下去），再研發公共數據層（構建美好未來），在滿足業務需求的過程中，再根據需求不斷對模型進行迭代和優化，隨着時間的推移，越來越多的業務需求可以通過 DWS 層的數據完成。
這一過程中，完善度是很好的考覈標準，主要看 DWS 層彙總的數據能滿足多少的查詢需求，如果彙總數據無法滿足需求，使用數據的人就必須使用明細的數據，甚至是 ODS 層的原始數據。
DWS/ADS 層的完善度越高，說明數據的上層建設越完善，而從使用者的角度來說，查詢快、易取數、用的爽，那纔是硬道理。