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

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

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

1. 分層是一種空間換時(shí)間的操作

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

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

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

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

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

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

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

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

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

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

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

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

遇到這樣的情況不知道的小白會(huì)認(rèn)為這個(gè)前輩很牛逼，能寫出這么長(zhǎng)的SQL，甚至竊認(rèn)為自己很幸運(yùn)學(xué)習(xí)到了一個(gè)這么牛逼的SQL。

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

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

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

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

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

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

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

分層的其他好處還包括，數(shù)據(jù)更加規(guī)范有條理，數(shù)據(jù)血緣更加清晰，數(shù)據(jù)表和指標(biāo)的統(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ù)動(dòng)作產(chǎn)生形成的，所以叫操作數(shù)據(jù)層。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

針對(duì)一個(gè)具體表是放在ADS層合適呢還是放在DWS層合適呢？

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

首先我們要記住一個(gè)原則：

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

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

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

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

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

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

不要為了分層而分層也不要被這個(gè)層所層層困住。

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

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

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

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