爲什麼要對數據倉庫進行分層
自從大數據平臺hadoop及其技術火起來之後，無論是政企、民企還是各類金融機構，都掀起了一股大數據技術轉型、數據倉庫重構、智能數據分析、AI等一系列黑科技且高大上的熱潮。其實，是否轉型大數據技術以後，產品營銷、風險管控、數據分析、管理決策等企業核心訴求都可以應有盡有呢？企業的數據管理核心——數據倉庫又應該以何種形態來建設？要回答上述問題，必須要從理解數據倉庫的本質與架構開始。
數據倉庫，由數據倉庫之父Bill Inmon在1991年出版的“Building the Data Warehouse”定義且被廣泛接受的——面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用於支持管理決策。從定義上來看，數據倉庫的關鍵詞爲面向主題、集成、穩定、反映歷史變化、支持管理決策，而這些關鍵詞的實現就體現在分層架構內。
實現好分層架構，有以下好處：
1）清晰數據結構：每一個數據分層都有對應的作用域，在使用數據的時候能更方便的定位和理解。
2）數據血緣追蹤：提供給業務人員或下游系統的數據服務時都是目標數據，目標數據的數據來源一般都來自於多張表數據。若出現目標數據異常時，清晰的血緣關係可以快速定位問題所在。而且，血緣管理也是元數據管理重要的一部分。
3）減少重複開發：數據的逐層加工原則，下層包含了上層數據加工所需要的全量數據，這樣的加工方式避免了每個數據開發人員都重新從源系統抽取數據進行加工。
4）數據關係條理化：源系統間存在複雜的數據關係，比如客戶信息同時存在於核心系統、信貸系統、理財系統、資金系統，取數時該如何決策呢？數據倉庫會對相同主題的數據進行統一建模，把複雜的數據關係梳理成條理清晰的數據模型，使用時就可避免上述問題了。
5）屏蔽原始數據的影響：數據的逐層加工原則，上層的數據都由下一層的數據加工獲取，不允許跳級取數。而原始數據位於數倉的最底層，離應用層數據還有多層的數據加工，所以加工應用層數據的過程中就會把原始數據的變更消除掉，保持應用層的穩定性。
瞭解了分層架構的好處，關鍵是該如何進行規劃與建設。
數據倉庫核心分層
目前市場上主流的分層方式眼花繚亂，不過看事情不能只看表面，還要看到內在的規律。從繁多的分層方式中，可以提煉出以下共性：
1）具備源系統數據歸集到數倉的緩衝層，或稱爲貼源層。
2）具備數據標準化及合併全量數據的標準層。
3）具備主題劃分及明細數據整合的主題層。
4）具備提供數據服務給下游系統使用的集市層，或稱爲應用層。
5）除上述核心分層，其他分層是從核心分層上細分得到的。
所以，數據倉庫的核心分層爲ODM貼源層、SDM標準層、FDM主題層、ADM應用層，如下圖所示：
ODM（Origin Data Manager）貼源層
主要用於源系統提供的T-1增量文本數據按源系統一致的數據結構入庫到數據庫。爲什麼要把源系統數據（簡稱源數據）入庫到數據庫，而不是直接合併到全量數據呢？存在以下原因：
1）直接處理文本數據的話，要先把文本數據加載到內存上，要是數據大小超過GB級別，對服務器內存壓力可不小。所以該處理方式對服務器硬件要求高，假如把文本數據先通過數據庫落地到磁盤上，可以減輕後續處理的硬件壓力。另外，文本數據本身是沒有結構的，直接處理時還得虛擬成二維表才容易處理，但是文本數據加載到數據庫後自動形成二維表，便於後續處理。
目前有部分關係型數據庫，支持建立外部表，使用二維表的方式讀取文本數據，比如greenplum，但是該方式的讀取效率還是比不上把數據存放在數據庫內。
2）由於ODM位於數倉的最底層，一旦源數據入庫出錯，可從最底層隔斷後續的數據加工流程，避免把錯誤的源數據入庫到標準層引發連環生產問題。
3）當發現上層數據異常時，可通過ODM排查根因是否出現在源數據上。
ODM的建設分爲源數據抽取及源數據入庫兩部分。源數據抽取的處理方式有兩種，一種是由源系統的技術團隊按照數倉要求的接口格式，抽取數據推送到數倉來實現，另一種是由專門的ETL團隊負責源數據抽取及源數據入庫的實現。部分企業會選擇第一種實現方式，這是因爲缺乏專門的ETL團隊承擔，或者不希望ETL團隊多接活（接鍋）。事實上，爲了從根本上保證數倉的數據質量，還是用第二種方式實現纔是最好的，這也是企業建設數倉時會忽略的一點。
ODM看似是數倉裏的最底層，也是最容易實現的層級，因爲數據結構與源系統一致，保證數據正常入庫即可。但是保證數據正常入庫，真的是那麼容易實現嗎？大家是否遇到過以下問題：
-
源數據抽取到數倉，沒有任何保證數據完整性的措施，過段時間後才發現數倉漏數了，又得從源系統進行數據初始化；
-
一旦源數據抽取出現異常，缺乏預警通知機制，只有在數倉加載數據時才發現數據尚未推送過來，影響後續數據加工；
-
源系統出現數據模型的新增或變更後，沒有及時通知數倉，到數倉加載數據出現報錯時才發現，逼着數倉進行緊急變更。
上述問題的出現，就是因爲沒有把握到ODM建設的核心，構建一條完善的數據抽取——數據入庫的ETL路線。ODM建設的核心有以下方面：
1）建立數據抽取——數據入庫的全流程校驗機制。進行數據抽取時，把落地的文本數據記錄數與源系統抽取記錄數進行匹對，即可完成數據抽取的完整性校驗。進行數據入庫時，把入庫的記錄數與文本數據的記錄數進行匹對，即可完成數據入庫的完整性校驗。
2）使用元數據管理工具，定時同步源系統的數據結構到數倉進行比對，當發現差異時及時預警。
3）由於數據抽取及數據入庫的處理流程都是固定的，可固化爲一套程序，未來源系統出現新增或者變更需求時，只需處理好映射關係即可，無須重複開發處理流程。
4）建設預警機制，筆者比較推薦使用短信預警通知，這樣無論是否在公司，都可以實時瞭解到ETL作業的執行情況，及時對異常進行處理。當然，由於生產環境的操作權限在運維團隊手上，預警機制還需要運維團隊配合一起實現。
SDM（Standard Data Manager）標準層
SDM的數據處理主要分爲兩部分，一部分是源數據清洗及標準化，另一部分是合併全量數據。
由於源數據的質量參差不齊，爲了使數倉內的數據是標準規範的，所以對源數據要按照數據標準，進行數據清洗和標準化轉換（PS：由於源數據已入庫到ODM，所以數據清洗及標準化轉換都是在數據庫層面進行，再次體現ODM建設的必要性）。數據標準由數據管理團隊負責制定的，所以數倉建設團隊也要與數據管理團隊深度合作才能做好數據標準化的動作。
這裏可能有個疑問，數據清洗與標準化的動作能否放在ODM完成呢？答案是不能，因爲ODM目標是要求入倉數據與源數據完全一致。若ODM已對源數據進行了清洗與標準化動作，未來排查數據異常時就不能根據ODM來排查根因是否出於源數據了。
合併全量數據的方式有三種，分別爲全量更新、增量變更及增量流水。
全量更新，數據抽取時把源系統表的數據全量抽取過來，該更新方式只需把SDM對應表的數據先清空，在入庫標準化後的數據即可。
增量變更及增量流水，數據抽取時把源系統表內變化的數據抽取過來。兩者區別是，增量變更的數據除了包含新增數據外，還包含對歷史數據有變更的數據，而增量流水的數據只包含新增數據。
增量流水的數據處理方法相對簡單，直接把增量數據入庫到表內即可。增量變更的數據一般採用拉鍊模型來處理，這樣既保證可以查詢到任意時刻的歷史全量快照，也可以減少數倉的存儲空間。拉鍊模型，顧名思義，就是把歷史變化的數據一環扣一環，就像鏈子一樣串聯起來。當查詢數據時，按照釦環上的時間標識進行查詢即可。具體實現方式爲第一次入庫的全量數據，把開始時間記錄爲入庫日期，結束時間記錄爲永久日期（比如2999-12-31）。後續入庫增量的數據涉及歷史數據變更時，把出現變更的舊數據的結束時間記錄爲當前入庫的日期，再把新數據的開始時間記錄爲當前入庫的日期，結束時間記錄爲永久日期，並寫入到表裏。這樣，要查詢歷史時點數據，根據開始日期和結束日期的範圍查詢即可。
然而，拉鍊模型有兩個明顯的缺陷，一個是當發現拉鍊表內某一扣環的數據異常時，拉鍊表應如何恢復準確性與完整性，另一個是隨着數據不斷增加，拉鍊表會越來越大，每日拉鍊操作的效率會越來越低，該如何優化數據存儲方式來避免該問題，未來會展開新的文章說明。
FDM（Finance Data Manager）金融主題層
爲了讓複雜的源數據變得容易理解及使用，必須按照相同的金融主題把數據整合到同一套模型中，對SDM數據進行明細級的數據整合彙總。主題設計的數量不宜太多，否則整個FDM就達不到簡化的作用。FDM是數倉模型設計的關鍵，ODM與SDM的數據結構都與源系統數據結構一致（SDM的數據結構會多一層標準化），模型設計難度不大，但是FDM要化繁爲簡，非常考驗建模師對業務的理解及建模經驗。FDM是後續數據分析及數據集市加工的基礎，核心是數據關係的簡化及複用，設計不好反而會成爲整個數倉的累贅，食之無味棄之可惜。由於文章篇幅關係，FDM的金融主題劃分與建模思路未來會展開新的文章進行討論。
可能會有疑問，能否不建設FDM，集市數據及數據分析直接從SDM進行呢？答案是能，但是後續維護的代價非常大，主要有以下原因：
1）FDM的核心之一是數據複用，缺乏FDM的話，相同數據加工都必須編寫重複的處理邏輯實現，技術團隊的開發量會大大增加；
2）FDM的核心之二是數據關係簡化，缺乏FDM的話，每個數據開發工程師都要理解各個源系統之間的數據關係，開發門檻極高，最終導致技術團隊實施成本過高；
3）假如ADM是從SDM加工獲得，源系統發生任意變更，都會影響到ADM，這時ADM的穩定性就無從談起。筆者的公司曾經試過信審系統重構從而新信審系統的數據模型變化極大，而當時數倉缺乏共性整合的FDM，導致本次變更對依賴數倉的數據應用造成難以估量的影響。而且由於需求分析階段沒有識別到這個風險點，最終導致信審系統重構項目被迫延遲2個月才能上線，而數倉爲了減少對數據應用的影響，把源系統的變更放在SDM內實現，這就是FDM的重要性。有FDM的話，所有源系統的變更都可以在SDM加工到FDM的過程進行屏蔽，這樣數倉會更加適應源系統引發的變更。
另外，爲什麼FDM是明細級數據的加工呢？這是爲了建設數據自助分析平臺做準備的。假如是高度彙總的指標數據，業務人員一旦對指標口徑發生變更，技術人員就會疲於奔命的變更指標的邏輯代碼來滿足業務人員的需求。而明細級數據可以爲業務人員提供自由組合的業務邏輯，技術人員只需要不斷擴展FDM就可以滿足業務人員頻繁變動的需求了。
ADM（Application Data Manager）應用層
應用層就是以特定業務場景爲目標而高度彙總的數據，一般以數據集市的形態呈現，比如大家常說的營銷集市、風險集市、績效集市。由於數據集市的建設對應的是特定且獨立的業務場景，幾無共性可言，所以必須對每類集市進行單獨說明。
小結
想要了解數據倉庫的建設，必須要瞭解數據倉庫的分層架構。然而僅瞭解分層架構的內容，對數倉的建設仍只停留在形而上學的階段。知其然也知其所以然，真正瞭解分層架構劃分原理及建設思路，纔會對分層架構融會貫通，未來面對千變萬化的業務形態及數據形態，仍有共性的手段來處理。
建設數據倉庫猶如創造一條新的生命，分層架構只是這條生命的邏輯骨架而已。想要在骨架上長出血肉，就必須進行合適的數據建模，數據倉庫的強壯還是孱弱，健美還是醜陋，就取決於建模的結果。
如果想要這條生命正常發揮力量，還需要搭配合適的技術平臺，才能把力量發揮到點上，而不是有力使不出。最後，要想這條生命茁壯生長的話，還必須作息規律（流程規範）、瞭解自己（元數據管理）、做好身體檢查（數據質量管理）及學會防身術（數據安全管理）。