導讀：數倉在建設過程中，對數據的組織管理上，不僅要根據業務進行縱向的主題域劃分，還需要橫向的數倉分層規範。本文作者圍繞企業數倉分層展開分析，希望對你有幫助。

從事數倉相關工作的人員都知道數倉模型設計的首要工作之一就是進行模型分層，可見模型分層在模型設計過程中的重要性，确實優秀的分層設計是一個數倉項目能否建設成功的核心要素，讓數據易理解和高複用是分層的核心目标。

早期作者在考慮對公司數倉制定分層規範時，也是查了很多資料，網上資料也是較為全面，有使用阿裡大數據分層方案，也有分三層、或者四五層的都有，這麼多分層思路，讓作者一陣腦瓜疼。所以作者希望整理一篇文章，對數倉分層進行一個較為全面的剖析，講下自己對分層的見解和想法，和大家交流。

本文将對數據倉庫分層方法進行全方位的闡述和整理，具體包含如下内容：

1. 介紹為什麼分層，分層的作用，核心思想
2. 提出一種通用的數據分層設計，以及分層設計的原則
3. 一些不同的分層思路，各個大廠分層及思路講述
4. 講述可落地的實踐意見

一、數倉分層意義，也可以說數倉為什麼分層？

通過數據分層管理可以簡化數據清洗的過程，因為把原來一步的工作分到了多個步驟去完成，每一層的處理邏輯都相對簡單和容易理解，從而達到解耦的目的，這樣我們比較容易保證每一個步驟的正确性，當數據發生錯誤的時候，方便問題排查和追溯定位。

分層的核心思想就是解耦，再解耦，把複雜的問題簡單化，這直接影響了數據架構到底分幾層。

這裡再講下數據分層的好處：

• 清晰數據結構：每一個數據分層都有它的作用域和職責，在使用表的時候能更方便地定位和理解
• 減少重複開發：規範數據分層，開發一些通用的中間層數據，能夠減少極大的重複計算
• 統一數據口徑：通過數據分層，提供統一的數據出口，統一對外輸出的數據口徑
• 複雜問題簡單化：将一個複雜的任務分解成多個步驟來完成，每一層解決特定的問題

二、一種通用的分層架構

這裡介紹一種較為常見，也是适用性較廣的四層分層架構，至于出處的話，我感覺應該是阿裡吧，感興趣的同學可以看下《大數據之路：阿裡巴巴大數據實踐》這本書中有介紹，公衆号回複“大數據圖書”可以獲取電子版。

數據公共層CDM（Common Data Model）或者 企業級數據倉庫Edw （Enterprise Data Warehouse）主要用于存放明細事實數據、維表數據及公共指标彙總數據，其中明細事實數據、維表數據一般根據ODS層數據加工生成；公共指标彙總數據一般根據維表數據和明細事實數據加工生成。本層采用維度模型作為建模方法的理論基礎，更多的是通過采用一些維度退化手段，将維度退化至事實表中，減少維表和事實表的關聯，提高數據易用性。

三、一些不同的分層思路（大廠數倉分層案例）

1. 愛奇藝數倉分層架構

從上圖可以看到，可以跟看到其實愛奇藝數倉分層和通用的分層架構差别不太大，也是包含原始數據層、明細層，彙總層、應用層以及統一的維度層，下面主要介紹一些不同的地方。

愛奇藝的架構中，最底層是統一數倉，其實是将原始數據層、統一明細數據層和統一聚合數據層進行了整合。明細層負責對接下層所有的原始數據，百分之百還原所有業務域和業務過程的數據，同時屏蔽底層原始數據變動對上層造成的影響，是整個愛奇藝數倉的底層基礎。

最底層是統一數倉，主要分為統一明細數據層和統一聚合數據層。明細層負責對接下層所有的原始數據，百分之百還原所有業務域和業務過程的數據，同時屏蔽底層原始數據變動對上層造成的影響，是整個數倉 2.0 的底層基礎。

通過明細層完成業務關系到數據關系邏輯轉換，并補充相關的維度，保存最細粒度數據，進行複雜業務邏輯分離、數據清洗、統一規範化數據格式等 ETL 過程。

聚合層負責對通用的指标進行沉澱，向上提供統一口徑的計算指标，同時避免重複計算。除此之外，還會提供基于 OneID 體系的統一累計設備庫和新增設備庫供上層使用。

業務集市主要以業務訴求為主，建設滿足業務分析的各種數據集合。在業務集市建設過程中，按照盡可能細的粒度去劃分業務集市，且每個業務集市之間不會出現數據依賴和橫向引用，在應用層可以跨集市進行彙總計算對外提供數據服務。這樣做的好處是，如果出現一些組織架構調整或者工作職責的變更等情況，每個業務集市無需調整，隻需在應用層做相應的修改即可，同時也避免因為計算任務代碼混在一起、數據權限拆分等問題帶來的數據變更成本。

主題數倉以公司範圍内公共的主題域/主題角度，以一緻性維度為基礎，跨各業務做數據的整合分析和相關建設，包括流量數倉、内容數倉、用戶數倉等。

應用層包括業務報表、内容分析、用戶運營等數據應用産品，按照具體的場景和需求，從業務集市和主題數倉獲取數據。

2. SaaS收銀運營數倉分層架構

這裡作者的案例是美團站點分享的SaaS收銀運營數倉建設一文中的架構，這個分層架構大概是五層，雖然從名稱上看着和通用分層架構差異比較大，實際具體功能上，隻是增加了一個DWT主題寬表層，APP層和通用的ADS層作用基本一緻，DWA彙總層其實和通用的DWS層是類似的。

DWT層主題寬表層，其實是對DWD各層的信息進行join整合，基于主題，将業務過程相關的數據冗餘處理，從而方便上層DWS彙總數據使用。

3. 美團數倉分層架構

從上圖中，看起來美團數倉分層架構和通用分層架構也是差異較大，但是其實和通用的分層架構也是異曲同工，隻不過是将數據分的更新，做更多的解耦。

ODS數據源層不用多說，名字都和通用的原始數據層一緻，下面主要說下上面四層：

IDL數據集成層，整合多數據源的一緻性建模，完成數據維度，事實組合。這一層要注重特殊的兩個概念，一是寬表，二是聚合表。寬表與 kimball 的 fact table 不一樣，我們通常所說的fact table，實際上僅僅是明細表的統稱，而寬表，則是把相關的事實表，都整合到一起，這樣的好處，一是加快速度，二是一次查詢更加全面。這塊你看和《SaaS收銀運營數倉建設》案例中的DWT又是何其相識。

CDL數據組件層，用來完成聚合彙總，進一步按照粒度劃分，完成年月日級的聚合。至此，一個中央數據倉庫就完成了。

MDL數據集市層，按照業務單元，做數據集市。比如營運，銷售。這樣提供給數據應用層，就有了完整的、可複用的數據源。

1M0t81

最終的ADL應用層，會簡單很多，主要是選型，也就是針對業務數據應用，會選擇哪些數據庫技術，分析引擎技術，還有報表計算，歸納起來，離不開存儲，計算，可視化。

4. 網易嚴選數倉分層架構

這裡稍微簡單說下吧，其實網易嚴選數倉分層架構和通用數倉分層架構差别不大，也算是直觀的使用體現吧。

嚴選數倉分層模型将數據分為三層，ods，dw和dm層。其中ods是操作數據層，保留最原始的數據；dw包含dwd和dws層，這兩層共同組成中間層；dm是應用層，基于dw層做彙總加工，滿足各産品、分析師和業務方的需求。

5. 網易雲音樂數倉分層架構

四、分享作者數倉分層架構

不多說，這裡不同之處在于增加了stg緩沖層，用于存儲每天的增量數據和變更數據，配合ODS對數據進行沉澱，減少了抽取的複雜性，比如進行增量數據的合并操作等。

五、個人對如何設計數倉分層架構的想法（數倉到底分幾層）

數據倉庫分層沒有絕對的規範，适合的就是最好的，至于分幾層，建議按照目前的業務和建設現狀，進行合理解構和分層設計，一般剛開始做，建議3、4層。規劃1-1.5年的架構，然後不斷的建設、優化、再優化。不斷逼近滿足所有需求。

下面針對一些場景說下分層的想法：

場景一：時間緊任務重，急于看結果

這種場景，直接連各個業務數據庫，抽取數據到大數據平台，根據需求組合join或者彙總count、sum就行，就不要不分層了，作者現在公司服務的數倉項目前身就是這樣，将各個業務系統數據抽取到oracle，你看都沒有大數據平台就做了。

場景二：公司業務簡單，且相對比較固定，數據來源不多，結構也很清晰，需求也不多

那麼還弄啥來，直接使用通用的數倉架構就行，ODS起到解耦業務數據庫 異構數據源的問題，DWD解決數據髒亂差的問題，DWS服用的指标計算，ADS直接面向前台業務需求。

場景三：公司業務複雜，業務變化較快

那就多一層DWT層做彙總，多一層解耦，業務變化的時候，我們隻改DWS層就好了，最多穿透到DWT層。業務變化的時候調整一下，工作量也不會太大，最重要的是能保證底層結構的穩定和數據分析的可持續性。

場景四：公司業務較為複雜，集團性公司，下轄多個部門bu事業線，bu間業務内容交叉不大

可以在數倉通用分層架構上，增加一層DM層，也就是數據集市層，各個數據集市層，單獨供數，甚至有單獨的計算資源，這樣可以避免因為計算任務代碼混在一起、數據權限拆分等問題帶來的數據變更成本。

六、一個好的數倉模型分層，應該具備的要素

一個好的數倉模型分層，應該具備的要素是數據模型可複用，完善且規範的。

從完善度上來講，主要衡量DWD層和彙總層兩塊的完善度，DWD層完善度，主要是希望DWD等盡可能被彙總層引用，ODS層被除了DWD層外的盡可能少的引用，最好是沒有。

從複用度上來講，我們希望80%需求由20%的表來支持。直接點講，就是大部分（80%以上）的需求，都用DWS的表來支持。

從規範度上來講，主要從表名、字段名來看，一個規範的表名應該包括層級、主題域、分區規則，抽取類型等信息。字段規範應該是和詞根一緻，同字段同名等，具體這塊可以看作者寫得《數倉命名規範篇》

七、總結

數據倉庫分層沒有絕對的規範，适合的就是最好的，數據倉庫分層的核心邏輯是解耦，在有限時間、資源等條件下滿足業務需求，同時又要兼顧業務的快速變化。所以我們作為數據架構師，需要兼顧業務的複雜變化，以及開發的複雜度和可維護性，在兩者之間做一個平衡和取舍，選擇合适的分層架構。

另外分層架構是需要不斷的優化調整的，不能超前太多，也不能脫離業務。按照Inmon和Kimball吵了十幾年的經驗上看，建議架構設計時，按超越當前實際情況1~1.5年的設計是比較合适的。

本文由 @白程序員的自習室 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Pexels，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部