數據分層是數據倉庫設計中十分重要的一個環節，優秀的分層設計能夠讓整個數據體系更易理解和使用。
而目前網絡中大部分可以被檢索到相關文章只是簡單地提及數據分層的設計，或缺少明確而詳細的說明，或缺少可落地實施的方案，或缺少具體的示例說明。
因此，本文將指出一種通用的數據倉庫分層方法，具體包含如下內容：
介紹數據分層的作用
提出一種通用的數據分層設計，以及分層設計的原則
舉出具體的例子說明
提出可落地的實踐意見
一、數據分層
1、為什麼要設計數據分層？
這應該是數據倉庫同學在設計數據分層時首先要被挑戰的問題。類似的問題可能會有很多，比如說“為什麼要做數據倉庫？”、“為什麼要做元數據管理？”、“為什麼要做數據質量管理？”。
當然，這裡我們只聊一下為什麼要做設計數據分層。
作為一名數據的規劃者，我們肯定希望自己的數據能夠有秩序地流轉，數據的整個生命週期能夠清晰明確被設計者和使用者感知到。
直觀來講就是如下圖這般層次清晰、依賴關係直觀：
但是，大多數情況下，我們完成的數據體系卻是依賴複雜、層級混亂的。
如下圖，在不知不覺的情況下，我們可能會做出一套表依賴結構混亂，甚至出現循環依賴的數據體系：
因此，我們需要一套行之有效的數據組織和管理方法來讓我們的數據體系更有序，這就是談到的數據分層。數據分層並不能解決所有的數據問題，但是，數據分層卻可以給我們帶來如下的好處：
清晰數據結構：每一個數據分層都有它的作用域和職責，在使用表的時候能更方便地定位和理解
減少重複開發：規範數據分層，開發一些通用的中間層數據，能夠減少極大的重複計算
統一數據口徑：通過數據分層，提供統一的數據出口，統一對外輸出的數據口徑
複雜問題簡單化：將一個複雜的任務分解成多個步驟來完成，每一層解決特定的問題
二、一種通用的數據分層設計
為了滿足前面提到數據分層帶來的好處，我們將數據模型分為三層：數據運營層（ ODS ）、數據倉庫層（DW）和數據應用層（APP）。
如下圖所示：
簡單來講，我們可以理解為：
ODS層存放的是接入的原始數據；
DW層是存放我們要重點設計的數據倉庫中間層數據；
APP是面向業務定製的應用數據。
下面詳細介紹這三層的設計：
1、數據運營層（ODS）
“面向主題的”，數據運營層，也叫ODS層（Operational Data Store），是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗淨、傳輸，也就說傳說中的 ETL 之後，裝入本層。
本層的數據，總體上大多是按照源頭業務系統的分類方式而分類的。
一般來講，為了考慮後續可能需要追溯數據問題，因此對於這一層就不建議做過多的數據清洗工作，原封不動地接入原始數據即可，至於數據的去噪、去重、異常值處理等過程可以放在後面的DWD層來做。
2、數據倉庫層（DW）
數據倉庫層，DW（Data Warehouse），是我們在做數據倉庫時要核心設計的一層，在這裡，從 ODS 層中獲得的數據按照主題建立各種數據模型。
DW層又細分為 DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和DWS（Data WareHouse Servce）層。
1）數據明細層：DWD（Data Warehouse Detail）
該層一般保持和ODS層一樣的數據粒度，並且提供一定的數據質量保證。
同時，為了提高數據明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。
另外，在該層也會做一部分的數據聚合，將相同主題的數據彙集到一張表中，提高數據的可用性，後文會舉例說明。
2）數據中間層：DWM（Data WareHouse Middle）
該層會在DWD層的數據基礎上，對數據做輕度的聚合操作，生成一系列的中間表，提升公共指標的複用性，減少重複加工。
直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。
3）數據服務層：DWS（Data WareHouse Servce）
又稱數據集市或寬表。按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用於提供後續的業務查詢，OLAP分析，數據分發等。
一般來講，該層的數據表會相對比較少，一張表會涵蓋比較多的業務內容，由於其字段較多，因此一般也會稱該層的表為寬表。
在實際計算中，如果直接從DWD或者ODS計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在DWM層先計算出多個小的中間表，然後再拼接成一張DWS的寬表。
由於寬和窄的界限不易界定，也可以去掉DWM這一層，只留DWS層，將所有的數據在放在DWS亦可。
3、數據應用層（APP）
在這裡，主要是提供給數據產品和數據分析使用的數據，一般會存放在 ES、PostgreSql、Redis等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用。
比如我們經常說的報表數據，一般就放在這裡。
4、維表層（Dimension）
最後補充一個維表層，維表層主要包含兩部分數據：
高基數維度數據：一般是用戶資料表、商品資料表類似的資料表。數據量可能是千萬級或者上億級別。
低基數維度數據：一般是配置表，比如枚舉值對應的中文含義，或者日期維表。數據量可能是個位數或者幾千幾萬。
至此，我們講完了數據分層設計中每一層的含義，這裡做一個總結便於理解，如下圖：
三、舉個栗子
趁熱打鐵，舉個栗子說明一下，如下圖，可以認為是一個電商網站的數據體系設計：
我們暫且只關注用戶訪問日誌這一部分數據。
在ODS層中：由於各端的開發團隊不同或者各種其它問題，用戶的訪問日誌被分成了好幾張表上報到了我們的ODS層。
為了方便大家的使用，我們在DWD層做了一張用戶訪問行為天表，在這裡，我們將PC網頁、H5、小程序和原生APP訪問日誌匯聚到一張表裡面，統一字段名，提升數據質量，這樣就有了一張可供大家方便使用的明細表了。
在DWM層：我們會從DWD層中選取業務關注的核心維度來做聚合操作，比如只保留人、商品、設備和頁面區域維度。類似的，我們這樣做了很多個DWM的中間表
然後在DWS層：我們將一個人在整個網站中的行為數據放到一張表中，這就是我們的寬表了，有了這張表，就可以快速滿足大部分的通用型業務需求了。
最後在APP應用層，根據需求從DWS層的一張或者多張表取出數據拼接成一張應用表即可。
備註：例子只是為了簡單地說明每一層的作用，並不是最合理的解決方案，大家辯證地看待即可。
四、技術實踐
既然談到了數據分層，那不同的層次中會用到什麼計算引擎和存儲系統呢，本節來簡單分享一下。
數據層的存儲一般如下：
Data Source：數據源一般是業務庫和埋點，當然也會有第三方購買數據等多種數據來源方式。業務庫的存儲一般是Mysql 和 PostgreSql。
ODS 層：ODS 的數據量一般非常大，所以大多數公司會選擇存在HDFS上，即Hive或者Hbase，Hive居多。
DW 層：一般和 ODS 的存儲一致，但是為了滿足更多的需求，也會有存放在 PG 和 ES 中的情況。
APP 層：應用層的數據，一般都要求比較快的響應速度，因此一般是放在 Mysql、PG、Redis中。
計算引擎的話，可以簡單參考圖中所列就行，目前大數據相關的技術更新迭代比較快，本節所列僅為簡單參考：
五、思考
本文將思考和總結一下數據分層的原則是什麼？為什麼要這樣分層？每層之間的界限又是什麼？
我個人從這幾個角度來理解數據分層的劃分：
從對應用的支持來講：我們希望越靠上層次，越對應用友好。比如APP層，基本是完全為應用來設計的，很易懂，DWS層的話，相對來講就會有一點點理解成本，然後DWM和DWD層就比較難理解了，因為它的維度可能會比較多，而且一個需求可能要多張表經過很複雜的計算才能完成。
從能力範圍來講：我們希望80%需求由20%的表來支持。直接點講，就是大部分（80%以上）的需求，都用DWS的表來支持就行，DWS支持不了的，就用DWM和DWD的表來支持，這些都支持不了的極少一部分數據需要從原始日誌中撈取。結合第一點來講的話就是：80%的需求，我們都希望以對應用很友好的方式來支持，而不是直接暴露給應用方原始日誌。
從數據聚合程度來講：我們希望，越上層數據的聚合程度越高，看上面的例子即可，ODS和DWD的數據基本是原始日誌的粒度，不做任何聚合操作，DWM做了輕度的聚合操作只保留了通用的維度，DWS做了更高的聚合操作，可能只保留一到兩個能表徵當前描述主體的維度。從這個角度來看，我們又可以理解為我們是按照數據的聚合程度來劃分數據層次的。
六、總結
數據分層的設計，在某種程度上也需要通過數據命名來體現，本文的核心在於講解數據分層的思想和方法，後面會有單獨的文章來分享該如何根據數據分層來設計數據表的命名規範。
另外，公眾號不便於文章的後續更新和修改，因此公眾號會發文章的第一版，然後小的改動會在github上進行。因此，單獨建了一個github的repo，大家感興趣也可以點“閱讀原文”進入github地址。
有小夥伴問居士寫博客用什麼工具，這裡回覆一下：目前寫博客工具是 Typora（Markdown文字編輯） + Draw.io（繪圖） + Github（存儲）+ Hexo（騰訊雲博客部署）。偶爾會有 Xmind 畫思維導圖，用 Excel 處理表格數據。
作者：木東居士
來源：木東居士訂閱號（ID：Data_Engineering）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]
掌握數據庫運維新思維，獲得更優操作啟發
不妨來DAMS學點獨家技能
↓↓掃碼可瞭解更多詳情及報名↓↓
2019 DAMS中國數據智能管理峰會-上海站
相關推薦
