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

從事數(shù)倉相關(guān)工作的人員都知道數(shù)倉模型設(shè)計的首要工作之一就是進行模型分層，可見模型分層在模型設(shè)計過程中的重要性，確實優(yōu)秀的分層設(shè)計是一個數(shù)倉項目能否建設(shè)成功的核心要素，讓數(shù)據(jù)易理解和高復用是分層的核心目標。

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

本文將對數(shù)據(jù)倉庫分層方法進行全方位的闡述和整理，具體包含如下內(nèi)容：

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

一、數(shù)倉分層意義，也可以說數(shù)倉為什么分層？

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

分層的核心思想就是解耦，再解耦，把復雜的問題簡單化，這直接影響了數(shù)據(jù)架構(gòu)到底分幾層。

這里再講下數(shù)據(jù)分層的好處：

• 清晰數(shù)據(jù)結(jié)構(gòu)：每一個數(shù)據(jù)分層都有它的作用域和職責，在使用表的時候能更方便地定位和理解
• 減少重復開發(fā)：規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復計算
• 統(tǒng)一數(shù)據(jù)口徑：通過數(shù)據(jù)分層，提供統(tǒng)一的數(shù)據(jù)出口，統(tǒng)一對外輸出的數(shù)據(jù)口徑
• 復雜問題簡單化：將一個復雜的任務分解成多個步驟來完成，每一層解決特定的問題

二、一種通用的分層架構(gòu)

這里介紹一種較為常見，也是適用性較廣的四層分層架構(gòu)：

數(shù)據(jù)公共層CDM（Common Data Model）或者 企業(yè)級數(shù)據(jù)倉庫EDW （Enterprise Data Warehouse）主要用于存放明細事實數(shù)據(jù)、維表數(shù)據(jù)及公共指標匯總數(shù)據(jù)，其中明細事實數(shù)據(jù)、維表數(shù)據(jù)一般根據(jù)ODS層數(shù)據(jù)加工生成；公共指標匯總數(shù)據(jù)一般根據(jù)維表數(shù)據(jù)和明細事實數(shù)據(jù)加工生成。本層采用維度模型作為建模方法的理論基礎(chǔ)，更多的是通過采用一些維度退化手段，將維度退化至事實表中，減少維表和事實表的關(guān)聯(lián)，提高數(shù)據(jù)易用性。

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

1. 愛奇藝數(shù)倉分層架構(gòu)

從上圖可以看到，可以跟看到其實愛奇藝數(shù)倉分層和通用的分層架構(gòu)差別不太大，也是包含原始數(shù)據(jù)層、明細層，匯總層、應用層以及統(tǒng)一的維度層，下面主要介紹一些不同的地方。

愛奇藝的架構(gòu)中，最底層是統(tǒng)一數(shù)倉，其實是將原始數(shù)據(jù)層、統(tǒng)一明細數(shù)據(jù)層和統(tǒng)一聚合數(shù)據(jù)層進行了整合。明細層負責對接下層所有的原始數(shù)據(jù)，百分之百還原所有業(yè)務域和業(yè)務過程的數(shù)據(jù)，同時屏蔽底層原始數(shù)據(jù)變動對上層造成的影響，是整個愛奇藝數(shù)倉的底層基礎(chǔ)。

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

通過明細層完成業(yè)務關(guān)系到數(shù)據(jù)關(guān)系邏輯轉(zhuǎn)換，并補充相關(guān)的維度，保存最細粒度數(shù)據(jù)，進行復雜業(yè)務邏輯分離、數(shù)據(jù)清洗、統(tǒng)一規(guī)范化數(shù)據(jù)格式等 ETL 過程。

聚合層負責對通用的指標進行沉淀，向上提供統(tǒng)一口徑的計算指標，同時避免重復計算。除此之外，還會提供基于 OneID 體系的統(tǒng)一累計設(shè)備庫和新增設(shè)備庫供上層使用。

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

主題數(shù)倉以公司范圍內(nèi)公共的主題域/主題角度，以一致性維度為基礎(chǔ)，跨各業(yè)務做數(shù)據(jù)的整合分析和相關(guān)建設(shè)，包括流量數(shù)倉、內(nèi)容數(shù)倉、用戶數(shù)倉等。

應用層包括業(yè)務報表、內(nèi)容分析、用戶運營等數(shù)據(jù)應用產(chǎn)品，按照具體的場景和需求，從業(yè)務集市和主題數(shù)倉獲取數(shù)據(jù)。

2. SaaS收銀運營數(shù)倉分層架構(gòu)

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

DWT層主題寬表層，其實是對DWD各層的信息進行join整合，基于主題，將業(yè)務過程相關(guān)的數(shù)據(jù)冗余處理，從而方便上層DWS匯總數(shù)據(jù)使用。

3. 美團數(shù)倉分層架構(gòu)

從上圖中，看起來美團數(shù)倉分層架構(gòu)和通用分層架構(gòu)也是差異較大，但是其實和通用的分層架構(gòu)也是異曲同工，只不過是將數(shù)據(jù)分的更新，做更多的解耦。

ODS數(shù)據(jù)源層不用多說，名字都和通用的原始數(shù)據(jù)層一致，下面主要說下上面四層：

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

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

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

1M0t81

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

4. 網(wǎng)易嚴選數(shù)倉分層架構(gòu)

這里稍微簡單說下吧，其實網(wǎng)易嚴選數(shù)倉分層架構(gòu)和通用數(shù)倉分層架構(gòu)差別不大，也算是直觀的使用體現(xiàn)吧。

嚴選數(shù)倉分層模型將數(shù)據(jù)分為三層，ods，dw和dm層。其中ods是操作數(shù)據(jù)層，保留最原始的數(shù)據(jù)；dw包含dwd和dws層，這兩層共同組成中間層；dm是應用層，基于dw層做匯總加工，滿足各產(chǎn)品、分析師和業(yè)務方的需求。

5. 網(wǎng)易云音樂數(shù)倉分層架構(gòu)

四、分享作者數(shù)倉分層架構(gòu)

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

五、個人對如何設(shè)計數(shù)倉分層架構(gòu)的想法（數(shù)倉到底分幾層）

數(shù)據(jù)倉庫分層沒有絕對的規(guī)范，適合的就是最好的，至于分幾層，建議按照目前的業(yè)務和建設(shè)現(xiàn)狀，進行合理解構(gòu)和分層設(shè)計，一般剛開始做，建議3、4層。規(guī)劃1-1.5年的架構(gòu)，然后不斷的建設(shè)、優(yōu)化、再優(yōu)化。不斷逼近滿足所有需求。

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

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

這種場景，直接連各個業(yè)務數(shù)據(jù)庫，抽取數(shù)據(jù)到大數(shù)據(jù)平臺，根據(jù)需求組合join或者匯總count、sum就行，就不要不分層了，作者現(xiàn)在公司服務的數(shù)倉項目前身就是這樣，將各個業(yè)務系統(tǒng)數(shù)據(jù)抽取到oracle，你看都沒有大數(shù)據(jù)平臺就做了。

場景二：公司業(yè)務簡單，且相對比較固定，數(shù)據(jù)來源不多，結(jié)構(gòu)也很清晰，需求也不多

那么還弄啥來，直接使用通用的數(shù)倉架構(gòu)就行，ODS起到解耦業(yè)務數(shù)據(jù)庫+異構(gòu)數(shù)據(jù)源的問題，DWD解決數(shù)據(jù)臟亂差的問題，DWS服用的指標計算，ADS直接面向前臺業(yè)務需求。

場景三：公司業(yè)務復雜，業(yè)務變化較快

那就多一層DWT層做匯總，多一層解耦，業(yè)務變化的時候，我們只改DWS層就好了，最多穿透到DWT層。業(yè)務變化的時候調(diào)整一下，工作量也不會太大，最重要的是能保證底層結(jié)構(gòu)的穩(wěn)定和數(shù)據(jù)分析的可持續(xù)性。

場景四：公司業(yè)務較為復雜，集團性公司，下轄多個部門bu事業(yè)線，bu間業(yè)務內(nèi)容交叉不大

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

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

一個好的數(shù)倉模型分層，應該具備的要素是數(shù)據(jù)模型可復用，完善且規(guī)范的。

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

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

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

七、總結(jié)

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

另外分層架構(gòu)是需要不斷的優(yōu)化調(diào)整的，不能超前太多，也不能脫離業(yè)務。按照Inmon和Kimball吵了十幾年的經(jīng)驗上看，建議架構(gòu)設(shè)計時，按超越當前實際情況1~1.5年的設(shè)計是比較合適的。

本文由 @白程序員的自習室 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Pexels，基于CC0協(xié)議。