數據倉庫的建模及ETL實踐技巧是怎么樣的

今天就跟大家聊聊有關數據倉庫的建模及ETL實踐技巧是怎么樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

如何搭建數據倉庫，在這個過程中都應該遵循哪些方法和原則，項目實踐中有哪些技巧。

一、數據倉庫的“心臟”

首先來談談數據模型。模型是現實世界特征的模擬和抽象，比如地圖、建筑設計沙盤，飛機模型等等。

而數據模型DataModel是現實世界數據特征的抽象。

在數據倉庫項目建設中，數據模型的建立具有重要的意義，客戶的業務場景，流程規則，行業知識都體現在通過數據模型表現出來，在業務人員和技術人員之間搭建起來了一個溝通的橋梁，所以在國外一些數據倉庫的文獻中，把數據模型稱之為數據倉庫的心臟“TheHeartoftheDataWarehouse”。

數據模型設計的好壞直接影響數據的

• 穩定性

• 易用性

• 訪問效率

• 存儲容量

• 維護成本

二、數據倉庫中數據模型，數據分層和ETL程序

2.1概述

數據倉庫是一種通過(準)實時/批量的方式把各種外部數據源集成起來后，采用多種方式提供給最終用戶進行數據消費的信息系統。

面對繁多的上游業務系統而言，數據倉庫的一個重要任務就是進行數據清洗和集成，形成一個標準化的規范化的數據結構，為后續的一致性的數據分析提供可信的數據基礎。

另一方面數據倉庫里面的數據要發揮價值就需要通過多種形式表現，有用于了解企業生產狀況的固定報表，有用于向管理層匯報的KPI駕駛艙，有用于大屏展示的實時數據推送，有用于部門應用的數據集市，也有用于分析師的數據實驗室...對于不同的數據消費途徑，數據需要從高度一致性的基礎模型轉向便于數據展現和數據分析的維度模型。不同階段的數據因此需要使用不同架構特點的數據模型與之相匹配，這也就是數據在數據倉庫里面進行數據分層的原因。

數據在各層數據中間的流轉，就是從一種數據模型轉向另外一種數據模型，這種轉換的過程需要借助的就是ETL算法。打個比方，數據就是數據倉庫中的原材料，而數據模型是不同產品形態的模子，不同的數據層就是倉庫的各個“車間”，數據在各個“車間”的形成流水線式的傳動就是依靠調度工具這個流程自動化軟件，執行SQL的客戶端工具是流水線上的機械臂，而ETL程序就是驅動機械臂進行產品加工的算法核心。

上圖是數據倉庫工具箱-維度建模權威指南一書中的數據倉庫混合輻射架構

2.2金融行業中的分層模型

金融行業中的數據倉庫是對模型建設要求最高也是最為成熟的一個行業，在多年的金融行業數據倉庫項目建設過程中，基本上都形成了緩沖層，基礎模型層，匯總層（共性加工層），以及集市層。不同的客戶會依托這四層模型做不同的演化，可能經過合并形成三層，也可能經過細分，形成5層或者6層。本文簡單介紹最常見的四層模型：

緩沖層：有的項目也稱為ODS層，簡單說這一層數據的模型就是貼源的，對于倉庫的用戶就是在倉庫里面形成一個上游系統的落地緩沖帶，原汁原味的生產數據在這一層得以保存和體現，所以這一層數據保留時間周期較短，常見的是7~15天，最大的用途是直接提供基于源系統結構的簡單原貌訪問，如審計等。

基礎層：也稱為核心層，基礎模型層，PDM層等等。數據按照主題域進行劃分整合后，較長周期地保存詳細數據。這一層數據高度整合，是整個數據倉庫的核心區域，是所有后面數據層的基礎。這一層保存的保存的數據最少13個月，常見的是2~5年。

集市層：先跳到最后一層。集市層的數據模型具備強烈的業務意義，便于業務人員理解和使用，是為了滿足部門用戶，業務用戶，關鍵管理用戶的訪問和查詢所使用的，而往往對接前段門戶的數據查詢，報表工具的訪問，以及數據挖掘分析工具的探索。

匯總層：匯總層其實并不是一開始就建立起來的。往往是基礎層和集市層建立起來后，發現眾多的集市層數據進行匯總，統計，加工的時候存在對基礎層數據的反復查詢和掃描，而不同部門的數據集市的統計算法實際上是有共性的，所以主鍵的在兩層之間，把具有共性的匯總結果形成一個獨立的數據層次，承上啟下，節省整個系統計算資源。

2.3數據倉庫常見ETL算法

雖然數據倉庫里面數據模型對于不同行業，不同業務場景有著千差萬別，但從本質上從緩沖層到基礎層的數據加工就是對于增/全量數據如何能夠高效地追加到基礎層的數據表中，并形成合理的數據歷史變化信息鏈條；而從基礎層到匯總層進而到集市層，則是如何通過關聯，匯總，聚合，分組這幾種手段進行數據處理。所以長期積累下來，對于數據層次之間的數據轉換算法實際上也能形成固定的ETL算法，這也是市面上很多數據倉庫代碼生成工具能夠自動化地智能化地形成無編碼方式開發數據倉庫ETL腳本的原因所在。這里由于篇幅關系，只簡單列舉一下緩沖層到基礎層常見的幾種ETL算法，具體的算法對應的SQL腳本可以找時間另起篇幅詳細地介紹。

1.全表覆蓋A1
算法說明：刪除目標表全部數據，再插入當前數據
來源數據量：全量數據
適用場景：無需保留歷史軌跡，只使用最新狀態數據

2.更新插入(Upsert)A2
算法說明：本日數據按照主鍵比對后更新數據，新增的數據采用插入的方式增加數據
來源數據量：增量或全量數據
適用場景：無需保留歷史軌跡，只使用最新狀態數據

3.歷史拉鏈（Historychain）A3
算法說明：數據按照主鍵與上日數據進行比對，對更新數據進行當日的關鏈和當日開鏈操作，對新增數據增加當日開鏈的記錄
來源數據：增量或全量數據
適用場景：需要保留歷史變化軌跡的數據，這部分數據會忽略刪除信息，例如客戶表、賬戶表等

4.全量拉鏈（FullHistorychain）A4
算法說明：本日全量數據與拉鏈表中上日數據進行全字段比對，比對結果中不存在的數據進行當日關鏈操作，對更新數據進行當日關鏈和當日開鏈操作，對新增數據增加當日開鏈的記錄
來源數據量：全量數據
適用場景：需要保留歷史變化軌跡的數據，這部分數據會由數據比對出刪除信息進行關鏈

5.帶刪除增量拉鏈(Fx:DeltaHistoryChain)A5
算法說明：本日增量數據根據增量中變更標志對刪除數據進行當日關鏈操作，對更新和新增數據與上日按主鍵比對后根據需要進行當日關鏈和當日開鏈操作，對新增數據增加當日開鏈的記錄
來源數據量：增量數據
適用場景：需要保留歷史變化軌跡的數據，這部分數據會根據CHG_CODE來判斷刪除信息

6.追加算法（Append）A6
算法說明：刪除當日/月的增量數據，插入本日/月的增量數據
來源數據量：增量數據
適用場景：流水類或事件類數據

三、GaussDB(DWS)和數據倉庫

華為的GaussDB(DWS)是一種基于公有云基礎架構的分布式MPP數據庫。其主要面向海量數據分析場景。MPP數據庫是業界實現數據倉庫系統最主流的數據庫架構，這種架構的主要特點就是Shared-nothing分布式架構，由眾多擁有獨立且互不共享的CPU、內存、存儲等系統資源的邏輯節點（也就是DN節點）組成。

在這樣的系統架構中，業務數據被分散存儲在多個節點上，SQL被推送到數據所在位置就近執行，并行地完成大規模的數據處理工作，實現對數據處理的快速響應。基于Shared-Nothing無共享分布式架構，也能夠保證隨著集群規模地擴展，業務處理能力得到線性增長。

看完上述內容，你們對數據倉庫的建模及ETL實踐技巧是怎么樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。