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

一、數(shù)倉為什么要分層

數(shù)倉分層的原因也即是分層的好處體現(xiàn)在下面幾個方面:

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

我們知道數(shù)倉一般都是用來保存大量的歷史數(shù)據(jù)的，這些數(shù)據(jù)可能是業(yè)務(wù)數(shù)據(jù)也可能是日志數(shù)據(jù)。

由于數(shù)據(jù)量級很大，如果直接查詢數(shù)倉中的原始數(shù)據(jù)需要訪問的表的數(shù)量和底層文件的數(shù)量都較多，體現(xiàn)在我們?nèi)粘９ぷ髦芯褪?span id="vvjhvh3" class="candidate-entity-word" data-gid="4317979">SQL異常復(fù)雜，甚至join和union加一起都不夠用，造成的直接后果就是SQL運行很慢，甚至跑不出來結(jié)果或者報錯。

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

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

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

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

2. 分層有利于減少重復(fù)開發(fā)

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

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

這樣不僅減少了重復(fù)開發(fā)而且做到了數(shù)據(jù)和指標的統(tǒng)一。

3. 分層可以把復(fù)雜的問題簡單化

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

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

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

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

這就是所謂的把復(fù)雜的問題簡單化。

4. 分層帶來更高的數(shù)據(jù)安全

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

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

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

分層的其他好處還包括，數(shù)據(jù)更加規(guī)范有條理，數(shù)據(jù)血緣更加清晰，數(shù)據(jù)表和指標的統(tǒng)一等等。

二、常用的數(shù)倉分層模型

我們以阿里的數(shù)倉架構(gòu)圖為例來說明數(shù)倉常用的分層模型。

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

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

前者是站在與數(shù)據(jù)源的關(guān)系層面來說的，也就是說這一層的數(shù)據(jù)是跟數(shù)據(jù)源的數(shù)據(jù)是一致的，所以稱其為貼源數(shù)據(jù)層。

后者是站在數(shù)據(jù)產(chǎn)生的層面來說的，也就是說這一層的數(shù)據(jù)是公司發(fā)生的一系列業(yè)務(wù)動作產(chǎn)生形成的，所以叫操作數(shù)據(jù)層。

我們可以看到不論是哪一種叫法都體現(xiàn)了與源數(shù)據(jù)的一致性。

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

這一層是最基礎(chǔ)也是最重要的一層，就像大廈的地基一樣，地基不牢，越是高層越是不穩(wěn)定。

DWD（Data Warehouse Detail），中文稱之為明細數(shù)據(jù)層。

這一層在與原表保持同一粒度的基礎(chǔ)上根據(jù)業(yè)務(wù)過程對ODS的數(shù)據(jù)進行去除臟數(shù)據(jù)，按照業(yè)務(wù)過程對表進行歸類和關(guān)聯(lián)，經(jīng)過ETL得到與業(yè)務(wù)過程相對應(yīng)的事實表。

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

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

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

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

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

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

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

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

ADS（Application Data Service），直譯應(yīng)用數(shù)據(jù)服務(wù)層，也就是我們通常說的應(yīng)用層或者指標層。

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

這一層的數(shù)據(jù)也是聚合后的數(shù)據(jù)。

那么它與DWS層的區(qū)別是什么呢？

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

舉一個不是特別恰當?shù)呛苣苷f明問題的栗子，DWD的10條數(shù)據(jù)可能在DWS中聚合成了5條，但是在ADS中可能被聚合成了1條，所以二者的聚合度是不一致的。

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

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

清洗處理層，也就是對原始數(shù)據(jù)經(jīng)過各種操作后形成的數(shù)據(jù)。

面向應(yīng)用層，也就是說是針對單個特定的數(shù)據(jù)需求清洗而形成的數(shù)據(jù)。

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

三、你的數(shù)倉該怎么分層

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

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

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

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

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

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

分層的目的是讓數(shù)據(jù)更規(guī)范、清晰更易用而不是為了讓層次更多。

兩點要牢記的是越是往上層數(shù)據(jù)的粒度就越粗，所表達的內(nèi)容就越有限，所以不是層級越多越好。

本層的表一般只允許依賴他緊鄰的上一層，應(yīng)嚴格避免同層依賴，否則極易產(chǎn)生循環(huán)依賴。

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

如果業(yè)務(wù)場景和過程比較復(fù)雜，指標口徑需要很多表關(guān)聯(lián)才能計算的話建議四層或者更多的層。

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

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

作者：數(shù)據(jù)倉庫@唐剛，“數(shù)據(jù)人創(chuàng)作者聯(lián)盟”成員。

本文由@一個數(shù)據(jù)人的自留地 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

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