該如何涉及數倉的DWS層

關於數據倉庫的分層，彷佛你們都有一個共同的認識。但涉及到每一層該如何去建模，可能每一個人都有本身的理解。數據建模，毫無疑問是數倉建設的重中之重，而後，在實際的開發過程當中，會把大量的時間都投入到了需求開發，每每會忽略數據建模(尤爲是DWS層的建模)，久而久之，數據模型變的愈來愈雜亂，指標口徑沒法統一，形成的結果就是：雖然表不少，可是卻很難取數。本文主要介紹DWS層建模的基本方法論，但願對你有所幫助。

公衆號【大數據技術與數倉】首發，關注領取資料

數倉爲何要分層

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

通用分層設計思路

• ODS:操做型數據(Operational Data Store)，指結構與源系統基本保持一致的增量或者全量數據。做爲DW數據的一個數據準備區，同時又承擔基礎數據記錄歷史變化，之因此保留原始數據和線上原始數據保持一致，方便後期數據覈對須要。
• 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層建模的一些方法論，智者見智仁者見仁，在實際的數據建模過程當中能夠參考這些方法論，但也要注意與具體的業務場景相結合，數據建模是創建在本身對業務的理解基礎之上的，切不可一味地照搬，要靈活運用。另外，不要苛求創建完美的數據模型，應當追求簡單、方便、易用。換句話說，建模沒有對錯之分，合適就好。