該如何設計數倉的彙總層 -DWS-

關於數據倉庫的分層，似乎大家都有一個共同的認識。但涉及到每一層該如何去建模，可能每個人都有自己的理解。數據建模，毫無疑問是數倉建設的重中之重，然後，在實際的開發過程中，會把大量的時間都投入到了需求開發，往往會忽略數據建模 (尤其是 DWS 層的建模)，長此以往，數據模型變的越來越雜亂，指標口徑無法統一，造成的結果就是：雖然表很多，但是卻很難取數。本文主要介紹 DWS 層建模的基本方法論，希望對你有所幫助。

數倉爲什麼要分層

合理的數據倉庫分層一方面能夠降低耦合性，提高重用性，可讀性可維護性，另一方面也能提高運算的效率，影響到數據需求迭代的速度，近而影響到產品決策的及時性。建立數據分層可以提煉公共層，避免煙囪式開發，可見一個合適且合理的數倉分層是極其重要。

通用分層設計思路

• CDM：通用數據模型，又稱爲數據中間層 (Common Data Model)，包含 DWD、DWS、DIM 層。

• DWD：數據倉庫明細層數據 (Data Warehouse Detail)。對 ODS 層數據進行清洗轉化，以業務過程作爲建模驅動，基於每個具體的業務過程特點，構建最細粒度的明細事實表。可以結合企業的數據使用特點，基於維度建模思想，將明細事實表的某些重要屬性字段做適當冗餘，也即寬表化處理，構建明細寬表。

• DWS：數據倉庫彙總層數據 (Data Warehouse Summary)，基於指標需求，構建初步彙總事實表，一般是寬表。基於上層的應用和產品的指標需求，構建公共粒度的彙總指標表。以寬表化手段物理化模型，構建命名規範、口徑一致的統計指標，爲上層提供公共指標。

• DIM：建立一致數據分析維表，可以降低數據計算口徑不統一的風險，同時可以方便進行交叉探查。以維度作爲建模驅動，基於每個維度的業務含義，通過添加維度屬性、關聯維度等定義計算邏輯，完成屬性定義的過程並建立一致的數據分析維表。

• ADS：面向應用的數據服務層 (Application Data Service)。整合彙總成分析某一個主題域的服務數據，面向應用邏輯的數據加工。該層主要存放數據產品個性化的統計指標數據，這一層的數據直接對接數據的消費者，是產品、運營等角色可以直接感知理解的一層，大多數這一層的表都可以直接在 BI 上通過圖表的形式直接透出。

沒有 DWS 層不行嗎

當我們在做數據需求時，會不會有這樣的疑問：我直接能從 DWD 層很方便的取出想要的數據，爲什麼還要多此一舉建立 DWS 層的彙總表呢？那是不是意味着可以不用建立 DWS 層的表呢，答案是：** 可以的。** 但是這有一個前提，就是業務場景不復雜。從短期來看可以快速滿足數據需求的開發，但是長期來看，會存在如下的問題：

• 對於複雜的業務場景而言，會出現很多跨域、跨事實的交叉探查，如果沒有沉澱出 DWS 層的指標進行統一口徑的收口，那麼相同的指標會出現不同的口徑和命名，其後果就是取數變得越來越不方便，而且容易造成業務懷疑數據是否正確的尷尬局面。

• 公共指標沒有統一計算，當每次需要相同的指標時，則需要重新計算一遍取數邏輯，不僅效率不高 (需要關聯表，計算指標)，而且會造成計算資源浪費。

DWS 層設計

以分析的主題對象作爲建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標表。以寬表化手段物理化模型，構建命名規範、口徑一致的統計指標，爲上層提供公共指標，建立彙總寬表。如：形成日，周，月粒度彙總明細，或者基於某一個維度，如商品類目粒度的彙總日表，統計便於下一步報表數據結構的組織。

DWS 層的基本特點

• DWS 層是面向分析維度進行設計的，分析維度通常是業務經常需要的看數據的角度。

• DWS 層的表服務於數據報表和數據產品的指標需求

• ADS 層的指標數據會存在交叉探查的情況，所以 DWS 層的指標要保持命名和口徑一致，避免 ADS 層的指標數據混亂

• DWS 是公共彙總層，提供不同維度的統計指標，指標的口徑要保持一致，並且要提供詳細的描述

• 以寬表的形式進行設計，比如相同粒度的統計指標可以放在一起，避免創建太多的表

• 公共彙總層的一個表通常會對應一個派生指標

• DWS 存儲派生指標 (統計週期 + 修飾詞 + 統計粒度 + 原子指標)，原子指標存儲在 DWD 層的事實表中

“

原子指標與派生指標

所謂原子指標，即是業務過程的度量，就是明細事實表中的度量值。比如訂單表，那麼某個訂單對應的訂單金額就是一個原子指標，這個指標是伴隨着訂單的業務過程而產生的。

所謂派生指標，即由統計週期 + 修飾詞 + 統計粒度 + 原子指標組合加工而成的指標

其中，統計週期：指的是想要統計的時間週期，比如天、周、月

  修飾詞：指的是業務的約束，通常出現在 SQL 的 where 條件中，比如訂單的下單渠道等等

  統計粒度：指的是維度組合，通常出現在 SQL 的 group by 中，比如統計商品一級類目對應的銷售額，那一級類目就是統計粒度

”

DWS 層的設計原則

關於彙總層的表建模應遵循以下的原則：

• 數據公用性比如，彙總的聚集表能否與他人公用？基於某個維度的聚集是否是數據分析或者報表中經常使用的？如果滿足這些情況，我們就有必要把明細數據沉澱到彙總表中。

• 不跨數據域數據域是在較高層次上對數據進行分類聚集的抽象，如交易統一劃到交易域下，商品的新增、修改放到商品域下。

• 區分統計週期表命名上要能說明數據的統計週期，如_1d 表示最近 1 天，_td 截止到當天，_nd 表示最近 N 天。

• 避免多個層級的數據應該避免將不同層級的數據放在一起，比如，如果存在 7 天和 30 天的事實，我們可以選擇用兩列存放 7 天和 30 天的事實，但是需要在列名和字段註釋上說明清楚。同時我們也可以使用兩張表分別存儲不同統計週期的數據加以區分。

• 聚集是不跨越事實的聚集是針對原始星型模型進行的彙總，爲了獲取和查詢原始模型一致的結果，聚集的維度和度量必須與原始模型保持一致，因此聚集是不跨事實的。橫向鑽取 (交叉探查) 是針對多個事實基於一致性維度進行的分析，很多時候採用融合事實表，預先存放橫向鑽取的結果，從而提高查詢性能。因此融合事實表是一種導出模式而不是聚集。

DWS 層設計步驟

• 首先，確定聚集維度，即確定統計粒度，比如商品粒度

• 然後，確定統計週期，比如天

• 最後，確定聚集事實，即派生指標

CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d
(
    item_id                 BIGINT COMMENT '商品ID',
    item_title               STRING COMMENT '商品名稱',
    cate_id                 BIGINT COMMENT '商品類目ID',
    cate_name               STRING COMMENT '商品類目名稱',
    mord_prov               STRING COMMENT '收貨人省份',
    confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天訂單已經確認收貨的金額總和'
)
COMMENT '商品粒度交易最近一天彙總事實表'
PARTITIONED BY (ds  STRING COMMENT '分區字段YYYYMMDD')
;

關於 DWS 層建設的一些問題

爲什麼一張 DWS 表通常只會對應一個派生指標？

在設計 DWS 表的時候，很多人會把所有可以聚合的維度進行 cube，這樣就得到了很多個派生指標，而這些派生指標放在同一張表中無疑會增加這張表的使用難度，比如在實際的取數時，往往只關心某個統計粒度的指標。實際上 cube 的數據儘量放在 ADS 層，這樣在開發數據接口或者應用層取數時都會比較方便。所以在設計 DWS 層時，應當遵循前文提到的一些原則，一言以蔽之，就是設計儘量體現出公共性、使用簡單並且用戶很容易理解。

怎麼設計出完美的 DWS 層表？

數倉建設是一個不斷迭代的過程，數據建模同樣是一個不斷迭代的過程。同時，業務是不斷變化的，建模人員對業務的理解也是變化的，這些也就註定了建模是一個迭代過程。雖然存在這些變化，但我們在數據建模的時候同樣要遵循一定的規範，切不可隨心所欲。

如何評價 DWS 層建設的好壞？

由於數倉的建設是與業務息息相關的，數倉建設的方法論僅僅只是指引我們構建數倉的一個方向，在實際的落地執行過程中會存在各種各樣的問題，且不可被這些理論所禁錮。簡單一句話就是：合適就好。所以，評價模型的好壞與否，更多的是從使用者的角度出發，比如簡單、易於取數、表的數量恰好。

總結

本文主要介紹了數據倉庫中 DWS 建設的基本思路，包括 DWS 層的特點、設計原則以及設計步驟，並對 DWS 層建設存在的一些問題進行了闡述。當然，這些只是 DWS 層建模的一些方法論，智者見智仁者見仁，在實際的數據建模過程中可以參考這些方法論，但也要注意與具體的業務場景相結合，數據建模是建立在自己對業務的理解基礎之上的，切不可一味地照搬，要靈活運用。另外，不要苛求建立完美的數據模型，應當追求簡單、方便、易用。換句話說，建模沒有對錯之分，合適就好。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ubqibiMqHvCaFenfKfyUvA