數倉腳本遷移方法及自動化

本篇將對數據倉庫遷移方法論中最爲核心的腳本遷移過程進行深入剖析，從血緣分析、數據庫對象遷移、ETL 腳本遷移和數據驗證等具體環節詳細介紹數倉遷移過程中的落地方法以及遷移自動化的挑戰及實現，並結合某國有大行數倉遷移項目的實施過程進行解讀。

遷移挑戰

腳本（主要包括數據庫對象和 ETL 腳本）是數據倉庫的核心內容，數據倉庫的日常運行和有機生長都是依託腳本來實現的。

因此，腳本遷移方案是數據倉庫整體遷移方案的重中之重，如何保障腳本本身以及腳本所內含的數據加工邏輯能夠被正確、高效的遷移，是整個遷移項目最有挑戰的地方，其難度主要體現在幾個方面：

遷移方案

常規的數倉遷移方案有三種，分別是：自下而上、自上而下、部分到整體。下圖裏我們分別對比分析了這三種方案的優缺點：

                                 （三種遷移方案）

前一篇文章我們已經論述過，龐大的金融數據倉庫遷移，無論是系統複雜度還是項目風險，都決定了這件事是無法一蹴而就的，必須分而治之。

在某國有大行數據倉庫遷移中，爲了****控制遷移風險，保證遷移質量，經過 Kyligence 團隊和行方的多輪論證，最終確定採用 “至上而下” 和“部分到整體”相結合的遷移方案（見下圖）。

 

根據數據倉庫遷移方案，我們將具體遷移項目的實施步驟從邏輯上劃分爲以下六個步驟，並會在下文與大家重點分享前面的四個步驟的實現方式。

    （遷移實施步驟）

Step1：數據血緣分析

數據血緣分析的重要性

血緣分析，簡單的說就是數據之間的上下游來源去向關係，數據從哪裏來到哪裏去。數據血緣分析是指對數據在流動、處理、融合等實現過程的可追溯，用於對數據處理過程的全面追蹤，從而找到以某個數據對象爲起點的所有相關元數據對象以及這些元數據對象之間的關係。

在數據倉庫遷移項目中，數據血緣分析意義重大，是數據鏈路分析、影響性分析、問題定位、數據評估、指標波動等一系列分析的基礎。

  

數據血緣分析的實現

數據血緣分析通常通過元數據管理平臺來實現（如下圖所示）。元數據管理平臺不僅是 IT 人員管理數據倉庫的重要工具，對業務用戶的幫助也非常大。業務用戶通過元數據管控平臺訪問數據血緣關係，可以快速瞭解數據的來龍去脈，爲業務對數據的理解、使用提供參考，進一步拉近了數據平臺與業務之間的距離。

金融數據倉庫有數十萬的腳本，上億行的代碼，所以想通過人工對腳本進行分析是天方夜譚，但血緣性分析重複性工作比較多，所以是自動化遷移工具大顯身手的最佳機會。

在遷移項目中，數據血緣分析工作分三步，分別是：血緣關係構建、數據血緣分析、項目遷移設計。

在某國有大行數倉的初期遷移項目中，基於行裏數據倉庫的元數據管理平臺和 Kyligence 的輔助工具，我們實現了數據血緣關係構建和分析的 100% 全自動化，能夠在確定遷移目標後快速進行遷移範圍的確定和影響性分析，爲遷移項目的具體設計提供了強有力的支撐。

數據血緣分析的案例

在一個以應用 ETL 效率爲優化目標的遷移項目中，藉助數據血緣分析工具，基於血緣關係模型，從項目結果表切入，通過數據流程可視化頁面，Kyligence 遷移團隊發現超過 76.4% 的交易數據統計都需要與幾個超大表關聯。再結合調度監控發現這些處理不僅消耗大量集羣資源，而且處理時間、處理鏈路較長。

遷移團隊經過細緻分析，結合 Hadoop 平臺特性，優化數據處理流程，減少大表的訪問，降低複雜統計，增加作業併發，優化後的作業處理耗時基本都控制在 3-6 分鐘，性能提升超 60%。

Step2：數據庫對象遷移

數據庫對象遷移內容

從數據庫對象遷移技術細節來看，金融數據倉庫需要遷移的數據庫對象內容通常比較好確定，主要是 Schema、數據庫表、視圖、函數、權限等數據庫內部的對象組件。

但在做數據庫對象遷移時，通常有人會糾結是不是在遷移數據庫對象時考慮連數據一起遷移呢？

基於我們的衆多實戰經驗和最佳實踐，建議在實際數據倉庫遷移過程中，不要過早考慮數據遷移，一定要在腳本遷移完成並且數據驗證都通過之後再單獨進行歷史數據的遷移。

主要原因包括：

數據庫對象遷移實現

數據庫對象是靜態的，不同平臺之間的數據庫對象大同小異，所以遷移起來難度不大。雖說數據庫對象遷移從技術上說複雜度不高，但數據庫對象的量非常大，即使每一個對象的遷移都可以快速完成，但量變引發質變，像銀行業數倉遷移這樣數十萬數據庫對象的數倉，用手工遷移是不能被接受的，是自動化工具閃亮登場的時刻。

在通過自動化工具正式遷移之前，我們首先需要先梳理新老技術平臺數據庫對象之間的差異和遷移規範，主要的內容包括：

除了上面列出的遷移規範之外，在某國有大行項目中，由於是從 MPP 數據往 Hadoop 平臺進行遷移，除了常規的數據庫差異，還有着其他架構層面的差異需要着重考慮，比如，基於 MPP 的數據倉庫通常會設計很多拉鍊表（維度建模 SCD2 的具體實現），在遷移到 Hadoop 之後，由於技術上的差異，大部分拉鍊表會被改成分區表。

如果說字段類型轉換、函數替換通過簡單配置就能夠支持，那對於拉鍊錶轉分區表，庫表 DDL 的遷移就需要進行定製以重點解決下面幾個問題：

在某國有大行項目中，我們通過對原有自動化遷移工具的二次升級，可以通過配置的方式來實現拉鍊表到分區表的自動 DDL 轉換，實現了建行數據倉庫數據庫對象從 GP 到 Hive 的 100% 自動化遷移，大大減少了手工遷移的工作量，降低了遷移的風險。

Step 3: ETL 腳本遷移

ETL 腳本遷移方案

ETL 腳本遷移是數據倉庫遷移的核心工作，同時也是數據倉庫遷移最複雜、最費人力、最費時間的工作，遷移的腳本質量直接決定了數據倉庫遷移的成敗。 

金融數據倉庫監本遷移難度很高，儘管我們希望實現 100% 的全自動，但是因爲種種困難，總會存在一些自動化的困難，需要人工介入，比如：腳本優化。

在某國有大行的項目裏，根據對數據倉庫遷移的難點評估，遷移項目組最終做出腳本遷移工作以工具遷移與人工遷移相結合的方式遷移方案。

ETL 腳本遷移實現

由於 ETL 腳本數量非常多，所以腳本平遷的工作量非常大。但因爲新老平臺的 ETL 腳本都是以標準 SQL 作爲基礎，得益於 SQL 的廣泛流行和較高的標準化程度，近 90% 的 ETL 腳本都是可以由遷移工具自動完成的，那麼遷移工具是如何實現自動化的呢？

腳本遷移工具的核心步驟分三步：讀取腳本、生成抽象語法樹、拼裝腳本。

當然，由於 MPP 與 H adoop 的架構差異，在 ETL 的一些處理方式上仍然存在衆多差異，比如 Update 操作、拉鍊表改成分區表後 ETL 加工邏輯的變更等等。這些差異對 ETL 腳本拼裝影響比較大，而且涉及的 ETL 腳本量比較多，但是在針對這些差異的改寫方案進行深入研究之後，我們可以發現改造前後腳本都是有着一定規律可循的，因此，我們最終通過優化自動化遷移工具實現了這些關鍵加工邏輯的自動改造。

腳本優化工作大部分是需要人工參與的，雖然需要優化的腳本數不是很多，但是因爲各個腳本的差異比較大，所以人工優化的累積成本投入比較高。

在某國有大行項目裏，項目組藉助數據流程圖、作業調度對批量時效進行綜合評估，發現 80% 的時效問題集中在 20% 的腳本中。在快速鎖定需要優化的 ETL 腳本後，遷移團隊按照業務重要性和影響範圍明確優先級，再安排人工逐一優化，以達到 20% 的人力投入解決 80% 的性能問題 “二八原則”。

所有人都希望遷移過程中，老數倉是個靜態的系統，可以讓我們從容改造，就好像讓飛機停下來換髮動機。但現實裏，新需求是數據倉庫遷移過程不得不面對的問題，並且需要我們以積極的心態去面對新需求。業務之所以將新需求提給新平臺，至少說明業務對新平臺報以很大的希望。新需求的承接，不僅會增加業務對新平臺的粘性，而且是引導業務參與數據平臺遷移的一條捷徑。

對於新需求的實施，遷移團隊需要分析新需求和現有遷移項目的交集，統籌考慮實施方案，甚至會將現有遷移項目中的部分內容提高優先級，與新需求整合後同步實施，這部分內容只能是通過手工實現了。

ETL 腳本遷移案例分享

基於 MPP 架構的數據倉庫，大部分模型都是拉鍊表的設計，雖然 Hadoop 平臺不太推薦使用拉鍊表，但是又不能完全禁用拉鍊表，所以拉鍊表遷移是數據倉庫遷移 Hadoop 平臺的攔路虎。

對拉鍊表的遷移方案不僅需要考慮 Hadoop 平臺特性，而且要顧及數據特徵和數據應用場景，同時還要考慮自動遷移的難度及後續運維的成本。

**綜合考慮 Hadoop 架構特性和拉鍊算法特性，Hadoop 平臺的拉鍊表採用分區設計，分別存儲開鏈、閉鏈數據。**每次更新時，將閉鏈數據插入閉鏈分區，再全量更新開鏈數據，這樣不僅拉鍊算法穩定，適合工具批量遷移，同時還提高了數據倉庫 ETL 從拉鍊表訪問最新數據的性能。

通過以上分析可以看出，在拉鍊表遷移過程中，ETL 腳本的改造是有着明顯規律的，自動化工具可以大顯身手。由於金融數倉中，拉鍊表在所有數據庫對象的佔比非常高，通常超過 50% 甚至更多，通過自動化遷移不僅提高了拉鍊表腳本的遷移效率，而且與數據庫對象遷移無縫對接，大大降低了遷移風險。

Update 操作在 MPP 架構的數據倉庫是比較常見的，但是在 Hadoop 架構的數據倉庫下就碰壁了，如果自動遷移工具無法支持，將直接挑戰自動遷移工具的實用性的底線。

**經過我們的研究和反覆驗證，最終在自動化遷移工具中選擇藉助元數據信息，使用 Overwrite 改寫 Update 的方案。**Update 改寫屬於數據倉庫遷移中有規律可循的改寫，在對遷移工具進行優化、改進後，可以實現自動轉譯，從而實現了對腳本中 Update 語句的自動化改造。

Step 4：數據驗證

數據驗證的意義

作爲以數據爲核心的數據平臺，交付的數據質量是至關重要的，因數據質量問題導致項目被延期、否決的案例屢見不鮮。同時，我們也經常看到嚴謹的數據驗證，不僅保證了數據平臺的質量，體現了數據平臺的價值，而且有助於樹立用戶對數據平臺的信心。

數據驗證的實現

數據驗證是整個數倉腳本遷移的把關環節。數據驗證通過，才能說明前面的血緣分析、對象遷移和腳本遷移等步驟的正確性。反之，如果數據驗證沒通過，那無論前面做了多少工作，實現了多少自動化，可能都是竹籃打水一場空，還得返工重來。

所以，數據驗證是非常關鍵的環節，也是很讓人揪心的一個環節。設計科學合理的數據驗證方法，並且儘量實現數據驗證的自動化，是我們一直努力的方向。

數據倉庫遷移過程中，數據驗證工作量非常大，而且經常需要驗證好幾輪。在數據倉庫遷移項目中，我們將數據驗證工作分爲兩類：

從上圖可以看出，對於每一個遷移的數據庫表或者視圖，我們可以從記錄數、關鍵指標（客戶數、賬戶餘額、交易金額）等方面針對性的設計驗證目標。通過自動化工具來對新老系統中的同一個表進行遷移後的自動比對。

但是，不得不承認，雖然初始的數據驗證可以通過自動化工具進行，但是在實際項目中，數據驗證步驟仍然是消耗人力最多，最讓人抓狂的一個環節。以某國有大行項目的商戶應用爲例，遷移後的數據驗證工作，自動化工具大約只節約了 35% 的人力，剩餘 65% 工作量依舊需要依賴人力。

爲什麼會這樣呢？這是因爲不少數據庫表遷移後都會發現數據驗證不一致的情況。自動化工具可以發現問題，但是沒法定位和解決問題，需要人工去介入。雖然整體來說數據驗證人工介入分析的場景並不是很多，但是由於每次分析、定位的問題複雜度很高，所以消耗的人力成本反而是整個遷移步驟裏最高的地方。

這裏稍微展開談談導致數據不一致問題的原因，拋開自動化工具或者手工遷移過程中本身的錯誤不算，導致數據不一致問題的核心是數據質量問題。

歸納起來主要就下面四點，並且需要手工介入和處理的方式方法又略有不同，因此使得數據驗證的環節始終難以實現較高的自動化程度。

以某自助查詢案例爲例，該案例有一張維表 “簽約渠道”，存放着銀行簽約的渠道碼值和簽約渠道名稱。但是隨着業務的不斷髮展，簽約渠道也在不斷的調整，事實表不定期有新的渠道碼值進入，但是維表的調整卻一直比較滯後。這類問題是數據倉庫比較常見的問題，但對數據質量的影響非常大，也對數倉遷移的數據驗證帶來了很大的困擾。

由此可見，在數據倉庫或者數據集市等數據平臺建設過程中，數據質量的把關是個非常關鍵的環節，不但是數據平臺價值的保障，也能爲日後的搬家掃除潛在的隱患。

結語

數據平臺的遷移和數據平臺的建設一樣，都是系統化的工程，需要成體系的方法論和一系列配套的自動化工具。某國有大行數據倉庫遷移的應用已經順利完成和上線，我們再次驗證了金融數據倉庫遷移解決方案的優勢，打造了最佳實踐，也爲後續大規模的遷移積累了可複製的實施工藝和自動化工具。

 

但是我們並沒有停止前行的腳步，在數據血緣分析、ETL 腳本遷移、數據驗證等方面我們還有很多事情可以做，自動化工具也還有很多可以持續優化的地方，在數據高速同步等方向上我們也將深入探索。

數據將是未來每個企業的核心資產，數據平臺的持續建設和遷移也將是每個企業都需要關注的焦點。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/oFkkMbGEgbSobl9o60ilfA

猜你喜歡