編輯導語：數倉是我們用來保存大量歷史數據的重要工具。那么，數倉為什么要分層？又該怎么進行分層？本文從數倉分層的原因、常見的數倉分層模型、數倉分層的做法三個方面，來詳細地介紹數倉分層。快來閱讀一下吧。

一、數倉為什么要分層

數倉分層的原因也即是分層的好處體現在下面幾個方面:

1. 分層是一種空間換時間的操作

我們知道數倉一般都是用來保存大量的歷史數據的，這些數據可能是業務數據也可能是日志數據。

由于數據量級很大，如果直接查詢數倉中的原始數據需要訪問的表的數量和底層文件的數量都較多，體現在我們日常工作中就是SQL異常復雜，甚至join和union加一起都不夠用，造成的直接后果就是SQL運行很慢，甚至跑不出來結果或者報錯。

而分層要做的就是對原始數據重新做歸納整理，在不同層級對數據或者指標做不同粒度的抽象。

經過分層后，同一個指標可能在不同層的數據中都有體現，似乎是“重復”了，但這種重復是一種“不完全”的重復，因為每個層級中指標的粒度是不完全一致的。

這種不是完全重復的重復給我們帶來的直接好處就是SQL寫起來大大簡化了，SQL計算耗時大大降低了。

有人可能會質疑這樣會造成存儲成本的提高，但是相比帶來的直接收益，這一點成本是可接受的，畢竟誰也不想被老板一遍又一遍的dis：我要的數怎么還沒有跑出來？

2. 分層有利于減少重復開發

分層把大部分常用的、通用的數據模型和指標進行抽象和匯總，經過這樣的處理后生成可滿足大部分業務場景使用的數據表和指標。

這些表和指標就類似于程序開發中的公共模塊和接口，下游的使用方在使用的時候就不需要再從頭開發了，直接拿來用即可。

這樣不僅減少了重復開發而且做到了數據和指標的統一。

3. 分層可以把復雜的問題簡單化

舉個例子，大多數分析師剛到一個新公司的時候常常會被迫接手一個甚至是幾個長達上千行的祖傳SQL代碼，里面join、uoion數不過來，一層又一層嵌套的子查詢更是剪不斷、理還亂。

遇到這樣的情況不知道的小白會認為這個前輩很牛逼，能寫出這么長的SQL，甚至竊認為自己很幸運學習到了一個這么牛逼的SQL。

但實際情況往往是數倉分層不合理或者剛開始的時候沒有數倉，所有的邏輯都要從最底層的表中來計算，這個時候不復雜都難。

而數倉分層要做的一部分工作就是把這個又臭又長的SQL進行拆解和預處理，一方面就是上面提到的把通用的數據和指標進行歸類和預計算，另外一方面就是把JOIN和UNION這些復雜的操作拆解放在數倉的ETL中來處理。

這就是所謂的把復雜的問題簡單化。

4. 分層帶來更高的數據安全

數據經過分層以后，每層的表的寬度和指標的粒度都不同，這樣就可以針對不同的使用的對象開放不同層級的數據。

不需要關心明細數據的對方直接開放聚合度高的數據即可，這樣就避免了底層明細、敏感數據的泄漏。

另外在分層處理的時候也可以對一些敏感的字段做刪除、脫敏加密的處理，避免因安全控制精細化不夠帶來的數據使用權限大于申請的權限。

分層的其他好處還包括，數據更加規范有條理，數據血緣更加清晰，數據表和指標的統一等等。

二、常用的數倉分層模型

我們以阿里的數倉架構圖為例來說明數倉常用的分層模型。

阿里整體數據分了5層，分別是ODS,DWD, DIM,DWS,ADS，下面我們分別介紹一下。

ODS(Operation Data Store)層，中文通常有兩種叫法，分別是貼源數據層和操作數據層。

前者是站在與數據源的關系層面來說的，也就是說這一層的數據是跟數據源的數據是一致的，所以稱其為貼源數據層。

后者是站在數據產生的層面來說的，也就是說這一層的數據是公司發生的一系列業務動作產生形成的，所以叫操作數據層。

我們可以看到不論是哪一種叫法都體現了與源數據的一致性。

所以這一層的數據一般來說是與業務庫中中的數據保持一致的，也即是說這一層的數據來源于業務mysql、oracle等庫中或者日志中，在同步的過程中不對數據做任何處理，保證與源數據的一致。

這一層是最基礎也是最重要的一層，就像大廈的地基一樣，地基不牢，越是高層越是不穩定。

DWD（Data Warehouse Detail），中文稱之為明細數據層。

這一層在與原表保持同一粒度的基礎上根據業務過程對ODS的數據進行去除臟數據，按照業務過程對表進行歸類和關聯，經過ETL得到與業務過程相對應的事實表。

通常是實際業務中按照維度建模的方式把一些常用的維度也會冗余的到這一層的表中以降低數據查詢的成本。

需要特別提醒的是這一層的數據在粒度上仍然是明細數據，是沒有進行聚合的，只是表變得更寬了些。

DIM(Dimension)，中文稱之為維度數據層。

這一層其實是與DWD平行的一個層級，是對業務中常用維度的建模和抽象，例如常見的地域維度，日期維度，商品品類SKU等維度。所謂的維度也即是我們看數據和分析數據的一種習慣和視角。

這一層通常存儲的是完整的維度key和維度的名稱，而事實表中通常存儲的是維度key的字段。

DWS（Data Warehouse Service），直譯為數據服務層，我們通常稱其為匯總數據層。

這一層的數據來源基本上都是DWD和DIM，通常是把DWD中的事實表的key和DIM中的維度key關聯，然后對事實按照更高的維度進行上卷的聚合操作，得到在某一維度或者多個維度上的匯總數據或指標。

需要提醒的是數據在這一層發生了粒度變化，不再是明細的數據，而是聚合后的數據，這也是這一層別稱之為匯總數據層的原因。

ADS（Application Data Service），直譯應用數據服務層，也就是我們通常說的應用層或者指標層。

這一層的數據來源可以是DWD層，也可以是DWS層，或者是二者的混合計算。

這一層的數據也是聚合后的數據。

那么它與DWS層的區別是什么呢？

DWS通常是對明細數據按照常用的維度所做的較低維度的聚合匯總，而ADS層通常是面向具體應用（報表、接口等）的較高維度的數據指標的聚合匯總。

舉一個不是特別恰當但是很能說明問題的栗子，DWD的10條數據可能在DWS中聚合成了5條，但是在ADS中可能被聚合成了1條，所以二者的聚合度是不一致的。

不過也可能存在二者的聚合度一致，但此時ADS層的表中的字段更多或者更少，這也是體現了其面向具體應用的含義。

以上是阿里數倉的主要分層，拋開具體的層次名稱，一般意義上數倉可分為三個大的層次，分別是原始數據層，也就是數倉中數據的來源。

清洗處理層，也就是對原始數據經過各種操作后形成的數據。

面向應用層，也就是說是針對單個特定的數據需求清洗而形成的數據。

明白了這層含義，我也就不用再解釋其他一些諸如DWM,FACT,DW,DM等的寫法和叫法了，這些都只是表象，核心還是上面說的三層的本質。

三、你的數倉該怎么分層

好多同學可能看了上面的分層介紹后覺得分層不就是那么回事嗎？

可是一到實際的場景中就犯了難，ODS中還好說，可是后面要分幾層，每一層的原則和依賴怎么定義？

針對一個具體表是放在ADS層合適呢還是放在DWS層合適呢？

下面就來跟大家說說如何對你的數倉分層。

首先我們要記住一個原則：

不要為了分層而去分層，盲目的分層不但會造成數倉中表的混亂而且造成很大的資源浪費更是給后面的數據治理留下的無窮的隱患。

分層的目的是讓數據更規范、清晰更易用而不是為了讓層次更多。

兩點要牢記的是越是往上層數據的粒度就越粗，所表達的內容就越有限，所以不是層級越多越好。

本層的表一般只允許依賴他緊鄰的上一層，應嚴格避免同層依賴，否則極易產生循環依賴。

知道了上面的原則和要點，我的建議是如果業務場景比較簡單且數據表也不是很多，三層就足夠了。

如果業務場景和過程比較復雜，指標口徑需要很多表關聯才能計算的話建議四層或者更多的層。

不要為了分層而分層也不要被這個層所層層困住。

一千個讀者可能有一千種分層的想法，一千個公司可能也有一千種分層的方法，適合自己的就是最好的。

作者：數據倉庫@唐剛，“數據人創作者聯盟”成員。

本文由@一個數據人的自留地 原創發布于人人都是產品經理，未經許可，禁止轉載。

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