發(fā)個(gè)牢騷，搞大數(shù)據(jù)的也得建設(shè)數(shù)據(jù)倉庫吧。而且不管是傳統(tǒng)行業(yè)還是現(xiàn)在的互聯(lián)網(wǎng)公司，都需要對(duì)數(shù)據(jù)倉庫有一定的重視，而不是談一句自己是搞大數(shù)據(jù)的就很厲害了。數(shù)據(jù)倉庫更多代表的是一種對(duì)數(shù)據(jù)的管理和使用的方式，它是一整套包括了etl、調(diào)度、建模在內(nèi)的完整的理論體系。現(xiàn)在所謂的大數(shù)據(jù)更多的是一種數(shù)據(jù)量級(jí)的增大和工具的上的更新。 兩者并無沖突，相反，而是一種更好的結(jié)合。

話說，單純用用Hadoop、Spark、Flume處理處理數(shù)據(jù)，其實(shí)只是學(xué)會(huì)幾種新的工具，這是搞工具的，只是在數(shù)據(jù)倉庫中etl中的一部分。

當(dāng)然，技術(shù)的更新往往能領(lǐng)到一個(gè)時(shí)代的變革，比如Hadoop的誕生，光是深入研究一個(gè)大數(shù)據(jù)組件就要花很大的時(shí)間和精力。但是在熱潮冷卻之后，我們更應(yīng)該考慮地是如何更好地管理和使用自己的數(shù)據(jù)。

對(duì)于數(shù)據(jù)的從業(yè)者來講，要始終重視緊跟技術(shù)的變革，但是切記數(shù)據(jù)為王，在追求技術(shù)的極致的時(shí)候，不要忘了我們是搞數(shù)據(jù)的。

文章主題

吐槽完畢，本文主要講解數(shù)據(jù)倉庫的一個(gè)重要環(huán)節(jié)：如何設(shè)計(jì)數(shù)據(jù)分層！其它關(guān)于數(shù)據(jù)倉庫的內(nèi)容可參考其它的文章數(shù)據(jù)倉庫。

本文對(duì)數(shù)據(jù)分層的討論適合下面一些場景，超過該范圍場景 or 數(shù)據(jù)倉庫經(jīng)驗(yàn)豐富的大神就不必浪費(fèi)時(shí)間看了。

• 數(shù)據(jù)建設(shè)剛起步，大部分的數(shù)據(jù)經(jīng)過粗暴的數(shù)據(jù)接入后就直接對(duì)接業(yè)務(wù)。
• 數(shù)據(jù)建設(shè)發(fā)展到一定階段，發(fā)現(xiàn)數(shù)據(jù)的使用雜亂無章，各種業(yè)務(wù)都是從原始數(shù)據(jù)直接計(jì)算而得。
• 各種重復(fù)計(jì)算，嚴(yán)重浪費(fèi)了計(jì)算資源，需要優(yōu)化性能。

文章結(jié)構(gòu)

最初在做數(shù)據(jù)倉庫的時(shí)候遇到了很多坑，由于自身資源有限，接觸數(shù)據(jù)倉庫的時(shí)候，感覺在互聯(lián)網(wǎng)行業(yè)里面的數(shù)據(jù)倉庫成功經(jīng)驗(yàn)很少，網(wǎng)上很難找到比較實(shí)踐性強(qiáng)的資料。而那幾本經(jīng)典書籍里面又過于理論，折騰起來真是生不如死。還好現(xiàn)在過去了那個(gè)坎，因此多花一些時(shí)間整理自己的思路，幫助其他的小伙伴少踩一些坑。

1. 為什么要分層？這個(gè)問題被好幾個(gè)同學(xué)質(zhì)疑過。因此分層的價(jià)值還是要說清楚的。
2. 分享一下經(jīng)典的數(shù)據(jù)分層模型，以及每一層的數(shù)據(jù)的作用和如何加工得來。
3. 分享兩個(gè)數(shù)據(jù)分層的設(shè)計(jì)，通過這兩個(gè)實(shí)際的例子來說明每一層該怎么存數(shù)據(jù)。
4. 給出一些建議，不是最好的，但是可以做參考。

為什么要分層

我們對(duì)數(shù)據(jù)進(jìn)行分層的一個(gè)主要原因就是希望在管理數(shù)據(jù)的時(shí)候，能對(duì)數(shù)據(jù)有一個(gè)更加清晰的掌控，詳細(xì)來講，主要有下面幾個(gè)原因：

1. 清晰數(shù)據(jù)結(jié)構(gòu)：每一個(gè)數(shù)據(jù)分層都有它的作用域，這樣我們?cè)谑褂帽淼臅r(shí)候能更方便地定位和理解。
2. 數(shù)據(jù)血緣追蹤：簡單來講可以這樣理解，我們最終給業(yè)務(wù)誠信的是一能直接使用的張業(yè)務(wù)表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準(zhǔn)確地定位到問題，并清楚它的危害范圍。
3. 減少重復(fù)開發(fā)：規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復(fù)計(jì)算。
4. 把復(fù)雜問題簡單化。講一個(gè)復(fù)雜的任務(wù)分解成多個(gè)步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護(hù)數(shù)據(jù)的準(zhǔn)確性，當(dāng)數(shù)據(jù)出現(xiàn)問題之后，可以不用修復(fù)所有的數(shù)據(jù)，只需要從有問題的步驟開始修復(fù)。
5. 屏蔽原始數(shù)據(jù)的異常。
6. 屏蔽業(yè)務(wù)的影響，不必改一次業(yè)務(wù)就需要重新接入數(shù)據(jù)。

數(shù)據(jù)體系中的各個(gè)表的依賴就像是電線的流向一樣，我們都希望它是很規(guī)整，便于管理的。但是，最終的結(jié)果大多是第一幅圖，而非第二幅圖。

 

 

[[195994]]

 

 

[[195995]]

怎樣分層

理論

我們從理論上來做一個(gè)抽象，可以把數(shù)據(jù)倉庫分為下面三個(gè)層，即：數(shù)據(jù)運(yùn)營層、數(shù)據(jù)倉庫層和數(shù)據(jù)產(chǎn)品層。

• ODS全稱是Operational Data Store，操作數(shù)據(jù)存儲(chǔ)

“面向主題的”，數(shù)據(jù)運(yùn)營層，也叫ODS層，是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，數(shù)據(jù)源中的數(shù)據(jù)，經(jīng)過抽取、洗凈、傳輸，也就說傳說中的ETL之后，裝入本層。本層的數(shù)據(jù)，總體上大多是按照源頭業(yè)務(wù)系統(tǒng)的分類方式而分類的。

例如這一層可能包含的數(shù)據(jù)表為：人口表（包含每個(gè)人的身份證號(hào)、姓名、住址等）、機(jī)場登機(jī)記錄（包含乘機(jī)人身份證號(hào)、航班號(hào)、乘機(jī)日期、起飛城市等）、銀聯(lián)的刷卡信息表（包含銀行卡號(hào)、刷卡地點(diǎn)、刷卡時(shí)間、刷卡金額等）、銀行賬戶表（包含銀行卡號(hào)、持卡人身份證號(hào)等）等等一系列原始的業(yè)務(wù)數(shù)據(jù)。這里我們可以看到，這一層面的數(shù)據(jù)還具有鮮明的業(yè)務(wù)數(shù)據(jù)庫的特征，甚至還具有一定的關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)范式的組織形式。

但是，這一層面的數(shù)據(jù)卻不等同于原始數(shù)據(jù)。在源數(shù)據(jù)裝入這一層時(shí)，要進(jìn)行諸如去噪（例如去掉明顯偏離正常水平的銀行刷卡信息）、去重（例如銀行賬戶信息、公安局人口信息中均含有人的姓名，但是只保留一份即可）、提臟（例如有的人的銀行卡被盜刷，在十分鐘內(nèi)同時(shí)有兩筆分別在中國和日本的刷卡信息，這便是臟數(shù)據(jù)）、業(yè)務(wù)提取、單位統(tǒng)一、砍字段（例如用于支撐前端系統(tǒng)工作，但是在數(shù)據(jù)挖掘中不需要的字段）、業(yè)務(wù)判別等多項(xiàng)工作。

• 數(shù)據(jù)倉庫層(DW)，是數(shù)據(jù)倉庫的主體

在這里，從ODS層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型。例如以研究人的旅游消費(fèi)為主題的數(shù)據(jù)集中，便可以結(jié)合航空公司的登機(jī)出行信息，以及銀聯(lián)系統(tǒng)的刷卡記錄，進(jìn)行結(jié)合分析，產(chǎn)生數(shù)據(jù)集。在這里，我們需要了解四個(gè)概念：維（dimension）、事實(shí)（Fact）、指標(biāo)（Index）和粒度（ Granularity）。

• 數(shù)據(jù)產(chǎn)品層（APP），這一層是提供為數(shù)據(jù)產(chǎn)品使用的結(jié)果數(shù)據(jù)

在這里，主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會(huì)存放在es、mysql等系統(tǒng)中供線上系統(tǒng)使用，也可能會(huì)存在Hive或者Druid中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用。 比如我們經(jīng)常說的報(bào)表數(shù)據(jù)，或者說那種大寬表，一般就放在這里。

技術(shù)實(shí)踐

這三層技術(shù)劃分，相對(duì)來說比較粗粒度，后面我們會(huì)專門細(xì)分一下。在此之前，先聊一下每一層的數(shù)據(jù)一般都是怎么流向的。這里僅僅簡單介紹幾個(gè)常用的工具，側(cè)重中開源界主流。

• 數(shù)據(jù)來源層–> ODS層

這里其實(shí)就是我們現(xiàn)在大數(shù)據(jù)技術(shù)發(fā)揮作用的一個(gè)主要戰(zhàn)場。 我們的數(shù)據(jù)主要會(huì)有兩個(gè)大的來源：

1. 業(yè)務(wù)庫，這里經(jīng)常會(huì)使用sqoop來抽取，比如我們每天定時(shí)抽取一次。在實(shí)時(shí)方面，可以考慮用canal監(jiān)聽mysql的binlog，實(shí)時(shí)接入即可。
2. 埋點(diǎn)日志，線上系統(tǒng)會(huì)打入各種日志，這些日志一般以文件的形式保存，我們可以選擇用flume定時(shí)抽取，也可以用用spark streaming或者storm來實(shí)時(shí)接入，當(dāng)然，kafka也會(huì)是一個(gè)關(guān)鍵的角色。
3. 其它數(shù)據(jù)源會(huì)比較多樣性，這和具體的業(yè)務(wù)相關(guān)，不再贅述。

注意： 在這層，理應(yīng)不是簡單的數(shù)據(jù)接入，而是要考慮一定的數(shù)據(jù)清洗，比如異常字段的處理、字段命名規(guī)范化、時(shí)間字段的統(tǒng)一等，一般這些很容易會(huì)被忽略，但是卻至關(guān)重要。特別是后期我們做各種特征自動(dòng)生成的時(shí)候，會(huì)十分有用。后續(xù)會(huì)有文章來分享。

• ODS、DW –> App層

這里面也主要分兩種類型：

1. 每日定時(shí)任務(wù)型：比如我們典型的日計(jì)算任務(wù)，每天凌晨算前一天的數(shù)據(jù)，早上起來看報(bào)表。 這種任務(wù)經(jīng)常使用Hive、Spark或者生擼MR程序來計(jì)算，最終結(jié)果寫入Hive、Hbase、Mysql、Es或者Redis中。
2. 實(shí)時(shí)數(shù)據(jù)：這部分主要是各種實(shí)時(shí)的系統(tǒng)使用，比如我們的實(shí)時(shí)推薦、實(shí)時(shí)用戶畫像，一般我們會(huì)用Spark Streaming、Storm或者Flink來計(jì)算，最后會(huì)落入Es、Hbase或者Redis中。

舉個(gè)例子

當(dāng)初的設(shè)計(jì)總共分了6層，其中去掉元數(shù)據(jù)后，還有5層。下面分析一下當(dāng)初的一個(gè)設(shè)計(jì)思路。

緩沖層(buffer)

• 概念：又稱為接口層（stage），用于存儲(chǔ)每天的增量數(shù)據(jù)和變更數(shù)據(jù)，如Canal接收的業(yè)務(wù)變更日志。
• 數(shù)據(jù)生成方式：直接從kafka接收源數(shù)據(jù)，需要業(yè)務(wù)表每天生成。update,delete,inseret數(shù)據(jù)，只生成insert數(shù)據(jù)的業(yè)務(wù)表，數(shù)據(jù)直接入明細(xì)層。
• 討論方案：只把canal日志直接入緩沖層，如果其它有拉鏈數(shù)據(jù)的業(yè)務(wù)，也入緩沖層。
• 日志存儲(chǔ)方式：使用impala外表，parquet文件格式，方便需要MR處理的數(shù)據(jù)讀取。
• 日志刪除方式：長久存儲(chǔ)，可只存儲(chǔ)最近幾天的數(shù)據(jù)。討論方案：直接長久存儲(chǔ)。
• 表schema：一般按天創(chuàng)建分區(qū)。
• 庫與表命名。庫名：buffer,表名：初步考慮格式為：buffer_日期_業(yè)務(wù)表名,待定。

明細(xì)層（ODS, Operational Data Store,DWD: data warehouse detail）

• 概念：是數(shù)據(jù)倉庫的細(xì)節(jié)數(shù)據(jù)層，是對(duì)STAGE層數(shù)據(jù)進(jìn)行沉淀，減少了抽取的復(fù)雜性，同時(shí)ODS/DWD的信息模型組織主要遵循企業(yè)業(yè)務(wù)事務(wù)處理的形式，將各個(gè)專業(yè)數(shù)據(jù)進(jìn)行集中，明細(xì)層跟stage層的粒度一致，屬于分析的公共資源。
• 數(shù)據(jù)生成方式：部分?jǐn)?shù)據(jù)直接來自kafka，部分?jǐn)?shù)據(jù)為接口層數(shù)據(jù)與歷史數(shù)據(jù)合成。 canal日志合成數(shù)據(jù)的方式待研究。
• 討論方案：canal數(shù)據(jù)的合成方式為：每天把明細(xì)層的前天全量數(shù)據(jù)和昨天新數(shù)據(jù)合成一個(gè)新的數(shù)據(jù)表，覆蓋舊表。同時(shí)使用歷史鏡像，按周/按月/按年 存儲(chǔ)一個(gè)歷史鏡像到新表。
• 日志存儲(chǔ)方式：直接數(shù)據(jù)使用impala外表，parquet文件格式，canal合成數(shù)據(jù)為二次生成數(shù)據(jù)，建議使用內(nèi)表，下面幾層都是從impala生成的數(shù)據(jù)，建議都用內(nèi)表+靜態(tài)/動(dòng)態(tài)分區(qū)。
• 日志刪除方式：長久存儲(chǔ)。
• 表schema：一般按天創(chuàng)建分區(qū)，沒有時(shí)間概念的按具體業(yè)務(wù)選擇分區(qū)字段。
• 庫與表命名。庫名：ods,表名：初步考慮格式為ods_日期_業(yè)務(wù)表名,待定。
• 舊數(shù)據(jù)更新方式：直接覆蓋。

輕度匯總層(MID或DWB, data warehouse basis)

• 概念：輕度匯總層數(shù)據(jù)倉庫中DWD層和DM層之間的一個(gè)過渡層次，是對(duì)DWD層的生產(chǎn)數(shù)據(jù)進(jìn)行輕度綜合和匯總統(tǒng)計(jì)（可以把復(fù)雜的清洗，處理包含，如根據(jù)PV日志生成的會(huì)話數(shù)據(jù)）。輕度綜合層與DWD的主要區(qū)別在于二者的應(yīng)用領(lǐng)域不同，DWD的數(shù)據(jù)來源于生產(chǎn)型系統(tǒng)，并未滿意一些不可預(yù)見的需求而進(jìn)行沉淀；輕度綜合層則面向分析型應(yīng)用進(jìn)行細(xì)粒度的統(tǒng)計(jì)和沉淀。
• 數(shù)據(jù)生成方式：由明細(xì)層按照一定的業(yè)務(wù)需求生成輕度匯總表。明細(xì)層需要復(fù)雜清洗的數(shù)據(jù)和需要MR處理的數(shù)據(jù)也經(jīng)過處理后接入到輕度匯總層。
• 日志存儲(chǔ)方式：內(nèi)表，parquet文件格式。
• 日志刪除方式：長久存儲(chǔ)。
• 表schema：一般按天創(chuàng)建分區(qū)，沒有時(shí)間概念的按具體業(yè)務(wù)選擇分區(qū)字段。
• 庫與表命名。庫名：dwb,表名：初步考慮格式為：dwb_日期_業(yè)務(wù)表名,待定。
• 舊數(shù)據(jù)更新方式：直接覆蓋。

主題層（DM，date market或DWS, data warehouse service）

• 概念：又稱數(shù)據(jù)集市或?qū)挶怼０凑諛I(yè)務(wù)劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務(wù)查詢，OLAP分析，數(shù)據(jù)分發(fā)等。
• 數(shù)據(jù)生成方式：由輕度匯總層和明細(xì)層數(shù)據(jù)計(jì)算生成。
• 日志存儲(chǔ)方式：使用impala內(nèi)表，parquet文件格式。
• 日志刪除方式：長久存儲(chǔ)。
• 表schema：一般按天創(chuàng)建分區(qū)，沒有時(shí)間概念的按具體業(yè)務(wù)選擇分區(qū)字段。
• 庫與表命名。庫名：dm,表名：初步考慮格式為：dm_日期_業(yè)務(wù)表名,待定。
• 舊數(shù)據(jù)更新方式：直接覆蓋。

應(yīng)用層(App)

• 概念：應(yīng)用層是根據(jù)業(yè)務(wù)需要，由前面三層數(shù)據(jù)統(tǒng)計(jì)而出的結(jié)果，可以直接提供查詢展現(xiàn)，或?qū)胫罬ysql中使用。
• 數(shù)據(jù)生成方式：由明細(xì)層、輕度匯總層，數(shù)據(jù)集市層生成，一般要求數(shù)據(jù)主要來源于集市層。
• 日志存儲(chǔ)方式：使用impala內(nèi)表，parquet文件格式。
• 日志刪除方式：長久存儲(chǔ)。
• 表schema：一般按天創(chuàng)建分區(qū)，沒有時(shí)間概念的按具體業(yè)務(wù)選擇分區(qū)字段。
• 庫與表命名。庫名：暫定apl，另外根據(jù)業(yè)務(wù)不同，不限定一定要一個(gè)庫。
• 舊數(shù)據(jù)更新方式：直接覆蓋。

如何更優(yōu)雅一些

前面提到的一種設(shè)計(jì)其實(shí)相對(duì)來講已經(jīng)很詳細(xì)了，但是可能層次會(huì)有一點(diǎn)點(diǎn)多，而且在區(qū)分一張表到底該存放在什么位置的時(shí)候可能還有一點(diǎn)點(diǎn)疑惑。 我們?cè)谶@一章里再設(shè)計(jì)一套數(shù)據(jù)倉庫的分層，同時(shí)在前面的基礎(chǔ)上加上維表和一些臨時(shí)表的考慮，來讓我們的方案更優(yōu)雅一些。

下圖，做了一些小的改動(dòng)，我們?nèi)サ袅松弦还?jié)的Buffer層，把數(shù)據(jù)集市層和輕度匯總層放在同一個(gè)層級(jí)上，同時(shí)獨(dú)立出來了維表和臨時(shí)表。

這里解釋一下DWS、DWD、DIM和TMP的作用。

• DWS：輕度匯總層，從ODS層中對(duì)用戶的行為做一個(gè)初步的匯總，抽象出來一些通用的維度：時(shí)間、ip、id，并根據(jù)這些維度做一些統(tǒng)計(jì)值，比如用戶每個(gè)時(shí)間段在不同登錄ip購買的商品數(shù)等。這里做一層輕度的匯總會(huì)讓計(jì)算更加的高效，在此基礎(chǔ)上如果計(jì)算僅7天、30天、90天的行為的話會(huì)快很多。我們希望80%的業(yè)務(wù)都能通過我們的DWS層計(jì)算，而不是ODS。
• DWD：這一層主要解決一些數(shù)據(jù)質(zhì)量問題和數(shù)據(jù)的完整度問題。比如用戶的資料信息來自于很多不同表，而且經(jīng)常出現(xiàn)延遲丟數(shù)據(jù)等問題，為了方便各個(gè)使用方更好的使用數(shù)據(jù)，我們可以在這一層做一個(gè)屏蔽。
• DIM：這一層比較單純，舉個(gè)例子就明白，比如國家代碼和國家名、地理位置、中文名、國旗圖片等信息就存在DIM層中。
• TMP：每一層的計(jì)算都會(huì)有很多臨時(shí)表，專設(shè)一個(gè)DWTMP層來存儲(chǔ)我們數(shù)據(jù)倉庫的臨時(shí)表。

總結(jié)

數(shù)據(jù)分層是數(shù)據(jù)倉庫非常重要的一個(gè)環(huán)節(jié)，它決定的不僅僅是一個(gè)層次的問題，還直接影響到后續(xù)的血緣分析、特征自動(dòng)生成、元數(shù)據(jù)管理等一系列的建設(shè)。因此適于盡早考慮。

另外，每一層的名字不必太過在意，自己按照喜好就好。

本文分享了筆者自己對(duì)數(shù)據(jù)倉庫的一些理解和想法，不一定十分準(zhǔn)確，有什么問題可以多交流。

初步估計(jì)在數(shù)據(jù)倉庫方面，應(yīng)該還會(huì)有三個(gè)主題分享：血緣分析、特征自動(dòng)生成、元數(shù)據(jù)管理。分享完成之后，數(shù)據(jù)倉庫相關(guān)的就告一段落了。

參考： 
1.《數(shù)據(jù)倉庫》 
2.《數(shù)據(jù)倉庫工具箱》 
3. Winston、Ruby的指導(dǎo)