摘要：在數據倉庫平臺建設過程中，數據的加載、卸載，各層數據模型之間的數據流轉，業務規則的實現等等數據加工過程都會以ETL任務的方式實現。
一、前言
在數據倉庫平臺建設過程中，數據的加載、卸載，各層數據模型之間的數據流轉，業務規則的實現等等數據加工過程都會以ETL任務的方式實現。 構建ETL子系統是數據倉庫系統實施的一個非常重要的環節，在倉庫平臺建設過程中搭建一個完整、標準的ETL子系統是數據倉庫平臺建設的基礎性目標之一。
ETL是Extraction（數據抽取），Transform（數據轉換）和Loading（數據加載）這三個數據處理動作的縮寫，也是早期數據倉庫建設的數據流轉處理順序，因此形成的專用術語沿用至今。但是隨着作爲數據倉庫核心的數據庫引擎技術的不斷髮展，ETL模式也在不斷髮展和改變，逐漸形成了E-L-T，E-T-L-T等不同形式。對於GaussDB DWS爲代表的MPPDB數據倉庫平臺，則多以ELT或是ETLT模式爲主來構建ETL子系統。
二、ETL子系統邏輯參考架構
ETL子系統的建設目的是將企業中的分散、零亂、標準不統一的異構數據源的業務數據整合到一起，進行必要的清洗和轉換，形成高質量的統一的數據模型，或者是便於用戶查詢，分析和探索的維度模型。
圖1 數據倉庫子系統參考架構
2.1 數據抽取(Extraction)
數據抽取是從數據倉庫的上游系統（通常是核心系統，業務系統或外部系統）進行全量或增量數據抓取的過程。而隨着企業內部信息底層架構的完善和數據平臺功能的劃分，不同平臺通常採用松耦合的方式進行關聯。傳統中下游系統直接到上游系統進行數據抽取的這種方式並不符合當前技術的發展趨勢。一方面，下游系統直接到上游系統進行數據抽取操作牽涉到權限的開放管理，增加了上游系統的數據安全風險。另一方面，本身數據抽取操作也應當在業務系統自身正常業務完成後的時間窗口進行，以避免數據抽取時對正常作業流程的資源競爭。因此數據抽取這個環節的操作，通常是上下游系統進行接口協商，由上游系統按照接口規範進行數據卸載操作。或者對於更成熟的企業，會構建統一的數據交換平臺來完成企業內部統一的數據抽取/卸載工作。
對於數據倉庫平臺來說，數據抽取的工作更多的是形成統一的接口規範。
2.2 數據轉換(Transform)
廣義上的數據轉換包括數據清洗，數據關聯加工，數據標準化處理，數據彙總聚合等操作。大部分基於業務規則和數據模型的數據轉換操作在MPPDB數據庫內實現比在數據庫外的ETL服務器上進行實現效率更高。而這種轉換操作在數據庫內通過SQL實現T過程，也比通過ETL工具實現T過程更具有標準化和開放性，適合業務人員參與T過程的開發，校驗。
2.3 數據加載(Loading)
對於數據倉庫而言，不僅僅是數據加載，還包括數據卸載，也就是Loading和Unloading過程。典型的場景就是在數據到達的高峯期進行大量的文件加載入庫的操作。而庫內數據加工完成後，及時地進行數據卸載操作，形成接口文件推送給下游系統。所以高效地批量數據加載和卸載操作是數據倉庫ETL系統要面對的主要挑戰之一。而隨着客戶對實時數據倉庫的需求越來越普遍，數據庫和消息隊列，數據流組件之間的實時數據加載和卸載的技術則是當前ETL系統構建時面臨的又一個技術挑戰。
三、ETL子系統的兩種實現架構
依託GaussDB(DWS)數據庫構建ETL系統一般有兩種實現方式：重ETL Server方案和MPPDB方案。如下圖
圖2 兩種架構示意圖
3.1 重ETL Server方案
這種方案藉助專業化的ETL軟件：Informatica, DataStage, Kettle等軟件，採用分佈式的/基於共享存儲的ETL服務器集羣方式部署ETL軟件。在執行ETL任務的時候，數據從MPPDB讀取出來，數據處理過程在ETL服務器完成，處理完結果再推送到數據庫服務器，其中有些操作可以通過SQL Push down在數據庫內完成。
這種方案的特點在於整個ETL開發和部署過程圖形化操作和腳本化操作方式結合，基於工具過程的開發也可以對ETL過程進行基於元數據的血緣分析，影響性分析；作業自動化編排，調度方面ETL工具的功能弱於專業的調度軟件。
基於ETL工具方案對於ETL開發過程來說需要專業的開發人員，要對ETL工具本身有很深入的瞭解，從這方面來說，過於專業化的工具門檻不利於企業內部的業務專家和分析人員介入ETL開發過程。而ETL方面對於軟硬件的投入成本也是需要納入考量的一個問題。
3.2 MPPDB方案
- 本方案中ETL服務器輕量化，生產環境一般提供主備服務器避免單點故障即可。主要特點如下：
- 利用MPPDB並行處理引擎，海量數據ETL處理效率更高。
- ETL過程SQL模板化，快速開發和迭代的過程代價低；
- 彙總層和集市層的ETL處理邏輯一般和業務規則強相關，SQL標準對於業務人員開發門檻低
- 與第三方ETL服務器解耦，通過工具封裝，可以避免過度依賴某一個ETL工具；
- 需要對ETL腳本模板進行定製化封裝式開發，爲運維，優化，數據治理等過程提供底層數據。
3.3簡單對比
重ETL Server方案適合基於文件的數據清洗類ETL工作：對於字符集的轉換處理；按照接口規範對接口數據的預處理（判斷文件大小，記錄行數等文件信息和屬性方面的數據質量檢查）；文件的分組，拆分，壓縮，解壓縮等；以及延伸出去的文件監控和傳輸功能。
MPPDB方案實際上就是基於SQL的實現方案，適合數據規範化處理：如業務編碼轉換，業務邏輯主鍵生成，符合業務規範的數據轉換處理；數據轉換處理：彙總，聚合，過濾，關聯，拆分，轉換等。
四、GaussDB(DWS)ETL系統實現要點
對於GaussDB(DWS)而言，大多數場合下推薦採用MPPDB方案。實現這種方案實際上要實現ETL SQL模板的封裝，把ETL開發過程與外部ETL調度系統的結合進行分層處理。通過模板方式實現與調度軟件，和操作系統的接口封裝，把SQL實現業務的模塊封裝在GSQL工具中，開放給業務人員和開發人員，令其聚焦在業務實現本身，而不用在意外部環境對於ETL過程操作的影響。
4.1 基於MPPDB的ETL環境邏輯視圖
圖3 邏輯視圖
- ETL調度
數據倉庫平臺的ETL作業系統是一種後臺非交互方式運行的批量數據處理系統。ETL作業調度是將數據倉庫系統中運行的各種後臺作業自動化，並監視和控制作業的運行。使用調度軟件實現作業調度。作業可以分佈在多個服務器平臺上，能夠設定作業定義、依賴關係、順序關係、工作組關係等，方便地對作業進行自動調度、運行和管理。
調度監管平臺可以圖形方式動態監視和控制作業的運行，對作業執行中出現的錯誤/警告提供詳細的信息。
- ETL腳本封裝
GSQL是執行SQL的工具，但是與調度軟件之間的結合還有一定的功能缺失，如參數解析，日誌解析，異常處理等，所以需要對GSQL進行必要的封裝，提高和調度軟件之間的契合度。
- gsql模板
對加工處理的etl過程進行抽象，總結，形成算法模板。
指定必要的輸入參數，設定會話啓動的公共參數，爲後續的優化和跟蹤埋點打樁。
- 調用形式
調度工具->Python或其他腳本工具模板->GSQL->{.gsql}
4.2 GSQL封裝
圖4 GSQL封裝示意圖
增加封裝的必要性:
GSQL和調度軟件解耦：調度軟件都具備調用Python/Perl/Shell腳本的能力，通過腳本封裝，把GSQL和調度軟件解耦，降低GSQL和調度軟件的適配兼容性風險；
封裝模板需要考量的功能點：
- 調度命令到GSQL運行命令的轉換：
調度命令相對簡單，和業務邏輯相關：如業務子系統代碼，算法模板代碼，數據日期等；
GSQL的運行參數不需要或不應當暴露在調度系統接口下：如登錄密碼，verbose參數等級等與業務無關的或者爲了便於運維，性能跟蹤的額外參數；
- 登錄密碼加密解密：
GSQL登錄密碼不允許明文存儲，需要密文方式保存在ETL服務器上，執行時候也需要避免出現在後臺命令行中被ps指令查看到；
- 異常處理：
GSQL腳本運行出錯後的異常處理功能：如重跑，告警通知等；
- 運行日誌解析：
GSQL的運行日誌解析：針對GSQL腳本中不同語句，不同事務的執行時間解析跟蹤，錯誤，告警代碼的解析跟蹤，爲性能分析提供最詳細的底層數據；
五、小結
本文對數據倉庫構建ETL子系統進行了初步介紹，說明了當前較爲主流的兩種ETL子系統實現架構，比對MPPDB數據庫的ETL架構進行了對比說明。最後對GaussDB(DWS)下的ETL子系統的實現要點進行了梳理，重點對etl實現的邏輯視圖以及GSQL封裝的功能要點進行了闡述。在今後的篇章，作者會對gsql的具體封裝實現的最佳實踐做個更爲詳細的介紹。
本文分享自華爲雲社區《給強大的“心臟”配上“超級流水線”- GaussDB(DWS)數據倉庫平臺ETL系統建設方案》，原文作者： babu1801 。