巨量資料環境下該如何優雅地設計資料分層

摘要： 發個牢騷，搞巨量資料的也得建設資料倉儲吧。而且不管是傳統產業還是現在的互連網公司，都需要對資料倉儲有一定的重視，而不是談一句自己是搞巨量資料的就很厲害了。資料倉儲其他代表的是一種對資料的管理和使用的方式，它是一整套包括了etl、調度、建模在內的完整的理論體系。

發個牢騷，搞巨量資料的也得建設資料倉儲吧。而且不管是傳統產業還是現在的互連網公司，都需要對資料倉儲有一定的重視，而不是談一句自己是搞巨量資料的就很厲害了。資料倉儲其他代表的是一種對資料的管理和使用的方式，它是一整套包括了etl、調度、建模在內的完整的理論體系。現在所謂的巨量資料其他的是一種資料量級的增大和工具的上的更新。 兩者並無衝突，相反，而是一種更好的結合。

話說，單純用用阿裡雲MaxCompute、巨量資料開發套件、流計算、DataX、Hadoop、Spark、Flume處理處理資料，其實只是學會幾種新的工具，這是搞工具的，只是在資料倉儲中etl中的一部分。

當然，技術的更新往往能領到一個年齡的變革，比如Hadoop的誕生，光是深入研究一個巨量資料元件就要花很大的時間和精力。但是在熱潮冷卻之後，我們更應該考慮地是如何更好地管理和使用自己的資料。

對於資料的從業者來講，要始終重視緊跟技術的變革，但是切記資料為王，在追求技術的極致的時候，不要忘了我們是搞資料的。

本文主題

吐槽完畢，本文主要講解資料倉儲的一個重要環節：如何設計資料分層！其它關於資料倉儲的內容可參考其它的本文資料倉儲。

本文對資料階層式討論適合下面一些場景，超過該範圍場景 or 資料倉儲經驗豐富的大神就不必浪費時間看了。

·資料建設剛起步，大部分的資料經過粗暴的資料接入後就直接對接商務。

·資料建設發展到一定階段，探索資料的使用雜亂無章，各種商務都是從未經處理資料直接計算而得。

·各種重複計算，嚴重浪費了計算資源，需要優化效能。

本文結構

最初在做資料倉儲的時候遇到了很多坑，由於自身資源有限，接觸資料倉儲的時候，感覺在互連網產業裡面的資料倉儲成功經驗很少，網上很難找到比較實踐性強的資料。而那幾本經典書籍裡面又過於理論，折騰起來真是生不如死。還好現在過去了那個坎，因此多花一些時間清理自己的思路，說明其他的小夥伴少踩一些坑。

1.為什麼要分層？這個問題被好幾個同學質疑過。因此階層式價值還是要說清晰的。

2.分享一下經典的資料分層型號，以及每一層的資料的作用和如何加工得來。

3.分享兩個資料階層式設計，通過這兩個實際的例子來說明每一層該怎麼存資料。

4.給出一些建議，不是最好的，但是可以做參考。

為什麼要分層

我們對資料進行階層式一個主要原因就是希望在管理資料的時候，能對資料有一個更加清晰的掌控，詳細來講，主要有下面幾個原因：

1.清晰資料結構：每一個資料分層都有它的範圍，這樣我們在使用表的時候能更方便地尋找和理解。

2.資料血緣追蹤：簡單來講可以這樣理解，我們最終給商務誠信的是一能直接使用的張商務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地尋找到問題，並清晰它的危害範圍。

3.減少重複開發：規格資料分層，開發一些通用的中介層資料，能夠減少極大的重複計算。

4. 把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維修資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。

5.遮罩未經處理資料的異常。

6.遮罩商務的影響，不必改一次商務就需要重新接入資料。

資料體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是很規整，便於管理的。但是，最終的結果大多是第一幅圖，而非第二幅圖。

怎樣分層

理論

我們從理論上來做一個抽象，可以把資料倉儲分為下面三個層，即：資料運營層、資料倉儲層和資料產品層。

·ODS全稱是Operational Data Store，操作資料隱藏

“面向主題的”，資料運營層，也叫ODS層，是最接近資料來源中資料的一層，資料來源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的ETL之後，裝入本層。本層的資料，母體上大多是按照源頭商務系統的分類方式而分類的。

例如這一層可能包含的資料工作表為：人口表（包含每個人的社會安全號碼、姓名、住址等）、機場登機記錄（包含乘機人社會安全號碼、航班號、乘機日期、起飛城市等）、銀聯的刷卡資訊表（包含銀行卡號、刷卡地點、刷卡時間、刷卡金額等）、銀行帳戶表（包含銀行卡號、持卡人社會安全號碼等）等等一系列原始的商務資料。這裡我們可以看到，這一層面的資料還具有鮮明的商務資料庫的特徵，甚至還具有一定的關聯式資料庫中的資料範式的組織形式。

但是，這一層面的資料卻不等同於未經處理資料。在來源資料裝入這一層時，要進行諸如去噪（例如去掉明顯偏離正常水準的銀行刷卡資訊）、去重（例如銀行帳戶資訊、公安局人口資訊中均含有人的姓名，但是只保留一份即可）、提髒（例如有的人的銀行卡被盜刷，在十分鐘內同時有兩筆分別在中國和日本的刷卡資訊，這便是髒資料）、商務擷取、單位統一、砍欄位（例如用於支架前端系統工作，但是在資料採礦中不需要的欄位）、商務判別等多項工作。

·資料倉儲層(DW)，是資料倉儲的主體

在這裡，從ODS層中獲得的資料按照主題建立各種資料模型。例如以研究人的旅遊消費為主題的資料集中，便可以結合航空公司的登機出行資訊，以及銀聯系統的刷卡記錄，進行結合剖析，產生資料集。在這裡，我們需要瞭解四個概念：維（dimension）、事實（Fact）、指標（Index）和細微性（ Granularity）。

·資料產品層（APP），這一層是提供為資料產品使用的結果資料

在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在RDS等系統中供線上系統使用，也可能會存在阿裡雲MaxCompute、Hive或者Druid中供資料分析和資料採礦使用。 比如我們經常說的報表資料，或者說那種大寬表，一般就放在這裡。

技術實踐

這三層技術劃分，相對來說比較粗細微性，後面我們會專門細分一下。在此之前，先聊一下每一層的資料一般都是怎麼流向的。這裡僅僅簡單介紹幾個常用的工具，側重中開源界主流。

·資料來源層–>ODS層

這裡其實就是我們現在巨量資料技術發揮作用的一個主要戰場。 我們的資料主要會有兩個大的來源：

1. 商務庫，這裡經常會使用阿裡雲巨量資料開發套件、DataX等工具來抽取，比如我們每天定時抽取一次。在即時方面，可以考慮用SLS、DTS監聽RDS的log，即時接入即可。

2.埋點日誌，線上系統會打入各種日誌，這些日誌一般以檔案的形式儲存，我們可以選擇用flume定時抽取，也可以用用StreamCompute、spark streaming或者storm來即時接入，當然，kafka也會是一個關鍵的角色。

3.其它資料來源會比較多樣性，這和具體的商務相關，不再贅述。

注意： 在這層，理應不是簡單的資料接入，而是要考慮一定的資料清洗，比如異常欄位的處理、欄位命名正常化、時間欄位的統一等，一般這些很容易會被忽略，但是卻至關重要。特別是後期我們做各種特徵自動生成的時候，會十分有用。後續會有本文來分享。

·ODS、DW –> App層

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

1.每日定時任務型：比如我們典型的日計算任務，每天淩晨算前一天的資料，早上起來看報表。 這種任務經常使用MaxCompute 、Hive、Spark或者生擼MR程式來計算，最終結果寫入MaxCompute 、Hive、Hbase、Mysql、Es或者Redis中。

2.即時資料：這部份主要是各種即時的系統使用，比如我們的即時推薦、即時用戶畫像，一般我們會用SteamCompute、Spark Streaming、Storm或者Flink來計算，最後會落入Es、OTS、Hbase或者Redis中。

舉個例子

當初的設計總共分了6層，其中去掉中繼資料後，還有5層。下面剖析一下當初的一個設計思路。

緩衝層(buffer)

·概念：又稱為介面層（stage），用於隱藏每天的增量資料和變更資料，如阿裡雲的DTS/SLS、開源Canal接收的商務變更日誌。

·資料生成方式：直接從kafka、DataX、阿裡雲巨量資料開發套件接收來源資料，需要商務表每天生成。update,delete,inseret資料，只生成insert資料的商務表，資料直接入明細層。

·討論方案：只把canal日誌直接入緩衝層，如果其它有拉鍊資料的商務，也入緩衝層。

·日誌隱藏方式：使用阿裡雲MaxCompute表，impala外表，parquet檔案格式，方便需要MR處理的資料讀取。

·日誌移除方式：長久隱藏，可只隱藏最近幾天的資料。討論方案：直接長久隱藏。

·表schema：一般按天建立分區。

·庫與表命名。庫名：buffer,表名：初步考慮格式為：buffer_日期_商務表名,待決。

明細層（ODS, Operational Data Store,DWD: datawarehouse detail）

·概念：是資料倉儲的細節資料層，是對STAGE層資料進行沉澱，減少了抽取的複雜性，同時ODS/DWD的資訊模型組織主要遵循企業商務交易處理的形式，將各個專業資料進行暫留，明細層跟stage層的細微性一致，屬於剖析的公共資源。

·資料生成方式：部份資料直接來自kafka，部份資料為介面層資料與歷史資料結合。 SLS、canal日誌結合資料的方式待研究。

·討論方案：canal資料的結合方式為：每天把明細層的前天全量資料和昨天新資料結合一個新的資料工作表，覆寫舊表。同時使用歷史鏡像，按周/按月/按年 隱藏一個歷史鏡像到新表。

·日誌隱藏方式：使用阿裡雲MaxCompute表，直接資料使用impala外表，parquet檔案格式，canal結合資料為二次生成資料，建議使用內表，下面幾層都是從impala生成的資料，建議都用內表+靜態/動態分區。

·日誌移除方式：長久隱藏。

·表schema：一般按天建立分區，沒有時間概念的按具體商務選擇分區欄位。

·庫與表命名。庫名：ods,表名：初步考慮格式為ods_日期_商務表名,待決。

·舊資料更新方式：直接覆寫。

輕度積存層(MID或DWB, data warehouse basis)

·概念：輕度積存層資料倉儲中DWD層和DM層之間的一個過渡層次，是對DWD層的生產資料進行輕度綜合和積存統計（可以把複雜的清洗，處理包含，如根據PV日誌生成的對話資料）。輕度綜合層與DWD的主要區別在於二者的套用領域不同，DWD的資料來源於生產型系統，並未滿意一些不可預見的需求而進行沉澱；輕度綜合層則面向剖析型套用進行細細微性的統計和沉澱。

·資料生成方式：由明細層按照一定的商務需求生成輕度積存表。明細層需要複雜清洗的資料和需要MR處理的資料也經過處理後接入到輕度積存層。

·日誌隱藏方式：使用阿裡雲MaxCompute表，使用impala內表，parquet檔案格式。

·日誌移除方式：長久隱藏。

·表schema：一般按天建立分區，沒有時間概念的按具體商務選擇分區欄位。

·庫與表命名。庫名：dwb,表名：初步考慮格式為：dwb_日期_商務表名,待決。

·舊資料更新方式：直接覆寫。

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

·概念：又稱資料集市或寬表。按照商務劃分，如流量、訂單、用戶等，生成欄位比較多的寬表，用於提供後續的商務查詢，OLAP剖析，資料分發等。

·資料生成方式：由輕度積存層和明細層資料計算生成。

·日誌隱藏方式：使用阿裡雲MaxCompute表，使用impala內表，parquet檔案格式。

·日誌移除方式：長久隱藏。

·表schema：一般按天建立分區，沒有時間概念的按具體商務選擇分區欄位。

·庫與表命名。庫名：dm,表名：初步考慮格式為：dm_日期_商務表名,待決。

·舊資料更新方式：直接覆寫。

應用程式層(App)

·概念：應用程式層是根據商務需要，由前面三層資料統計而出的結果，可以直接提供查詢展現，或匯入至Mysql中使用。

·資料生成方式：由明細層、輕度積存層，資料集市層生成，一般要求資料主要來源於集市層。

·日誌隱藏方式：使用阿裡雲MaxCompute表，使用impala內表，parquet檔案格式。

·日誌移除方式：長久隱藏。

·表schema：一般按天建立分區，沒有時間概念的按具體商務選擇分區欄位。

·庫與表命名。庫名：暫訂apl，另外根據商務不同，不限定一定要一個庫。

·舊資料更新方式：直接覆寫。

如何更優雅一些

前面提到的一種設計其實相對來講已經很詳細了，但是可能層次會有一點點多，而且在區分一張表到底該存放在什麼置放的時候可能還有一點點疑惑。 我們在這一章裡再設計一套資料倉儲的分層，同時在前面的基礎上加上維表和一些暫存資料表的考慮，來讓我們的方案更優雅一些。

下圖，做了一些小的改動，我們去掉了上一節的Buffer層，把資料集市層和輕度積存層放在同一個層級上，同時硬地出來了維表和暫存資料表。

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

·DWS：輕度積存層，從ODS層中對用戶的行為做一個初步的積存，抽象出來一些通用的維度：時間、ip、id，並根據這些維度做一些統計值，比如用戶每個時間段在不同登入ip購買的商品數等。這裡做一層輕度的積存會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行為的話會快很多。我們希望80%的商務都能通過我們的DWS層計算，而不是ODS。

·DWD：這一層主要解決一些資料品質問題和資料的完整度問題。比如使用者的資料資訊來自於很多不同表，而且經常出現延遲丟資料等問題，為了方便各個使用方更好的使用資料，我們可以在這一層做一個遮罩。

·DIM：這一層比較單純，舉個例子就明白，比如國家代碼和國家名、地理位置、中文名、國旗圖片等資訊就存在DIM層中。

·TMP：每一層的計算都會有很多暫存資料表，專設一個DWTMP層來隱藏我們資料倉儲的暫存資料表。

總結

資料分層是資料倉儲非常重要的一個環節，它決定的不僅僅是一個層次的問題，還直接影響到後續的血緣剖析、特徵自動生成、中繼資料管理等一系列的建設。因此適於儘早考慮。

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

本文分享了筆者自己對資料倉儲的一些理解和想法，不一定十分準確，有什麼問題可以多交流。

初步估計在資料倉儲方面，應該還會有三個主題分享：血緣剖析、特徵自動生成、中繼資料管理。分享完成之後，資料倉儲相關的就告一段落了。

參考：
1.《資料倉儲》
2.《資料倉儲工具箱》
3. Winston、Ruby的指導

阿裡巴巴巨量資料-玩家社群 https://yq.aliyun.com/teams/6/

---阿裡巨量資料博文，問答，社群，實踐，有朋自遠方來，不亦說乎……

本文轉自51CTO

相關產品：

1. 巨量資料計算服務(MaxCompute)