企業級資料倉儲遷移工藝和方法論總結
2023年年初,曾壟斷半個銀行業資料倉儲的TERADATA突然宣佈退出中國,各大銀行紛紛發起資料倉儲的替代專案,但是一個企業級的資料倉儲建成並非一朝一夕,通常內含成千上萬個指令碼、表、依賴關係等,任何一個環節出差錯均會導致牽一髮而動全身。而當前市面上又沒有一款數倉產品或數倉遷移方案得到充分證實,所以行業內針對TERADATA平替或資料倉儲遷移整體的方案五花八門。以TERADATA為代表的相關國外資料庫技術,長期壟斷國內市場,各家同業也在相關技術上積累了較多歷史資料包袱,去化工作十分困難。
上海農商銀行在2022年研判了相關形勢,在年中透過了對TERADATA數倉遷移的決策,決定將其搬遷到開源的HADOOP生態體系下。專案於2022年3季度啟動,並在2023年10月完成了全部作業的切換工作,已徹底擺脫對國外相關技術依賴,為後續全面信創打下基礎。本文透過上海農商銀行企業級資料倉儲遷移的實踐,總結了一套資料倉儲遷移的工藝和方法論,希望能為行業提供些許思路。
找準核心矛盾,制定合理目標
在我行專案開立初期,行內技術專家經過分析認為:一是作為一個企業級資料倉儲遷移專案,核心目標就是將其內容搬到一個異構資料庫內,所以這是一個科技含量較高、業務含量較低的工作,註定很難得到業務部門的支撐(如業務測試驗證),業務部門更關心業務連續性、資料準確性;二是資料倉儲系統往往需要頻繁承接上下游變動需求,所以也很難有一個需求封版的長時間視窗來支援資料遷移,做到後期需要雙線作戰。所以我行得出結論,制定一個合理的遷移範圍,不要發散,速戰速決尤為關鍵,整個工期一年內為佳。總結如下。
首先,透過資料服務或者卸數介面來倒推資料倉儲的整體範圍,並框定遷移內容,制定方針為“異構搬遷,資料不變”。
其次,在遷移前期(遷移專案開始前3~6個月為佳)針對數倉下游系統,如報表、預警系統等進行清理工作。將長期無人使用報表、過期報表、過期預警進行下線,減輕數倉整體負擔。
最後,切記不要在遷移專案內進行模型最佳化(即使當下模型在新的資料庫或平臺上並不適用),因為這會將遷移專案帶到非常不確定的一個處境,導致專案無法收尾。
定製遷移生命週期,確定遷移順序
我行將資料倉儲作業遷移工作劃分如下幾個階段:程式碼移植、資料遷移、測試驗證、生產並行、供數切換、持續並行、老版本下線。同時遷移工作會拆分成許多個模組逐步開展,所以在每個模組的遷移過程都要面向上述7個階段的一個遷移週期管理工作,後續我們要結合下文的分層遷移思路,可以制定一個整體遷移計劃。
圖1 一個標準的數倉遷移過程和各工具對應能力
我行企業級資料倉儲按主流分層式設計,總的分為四層,包括貼源層、明細層、彙總層、介面層。我們在制定遷移方案時第一個問題就是確定遷移順序,在專案初期我們共設想過三種方案。
一是自下而上逐層遷移。從貼源層到模型層再到介面層逐步遷移,優勢是順序遷移,更貼合“先打地基後造房子”的建設思路,穩定性強,可以做到遷移一層、核對一層;劣勢是新老數倉雙線維護時間較長,成本偏高。
二是自上而下逐層遷移。與上述方案相反,先遷移介面層,模型層資料透過老數倉供給,後續逐層類推。如此遷移完一層即可將其下線一層,新老數倉雙線維護時間短,降低維護成本;劣勢是容錯性較低,一旦下層遷移後無法適配上層資料就涉及下層程式碼調整,反過來會影響上層已遷移完的作業跟隨調整。
三是垂直遷移。以業務條線分批次全流程遷移,優勢是以業務為導向的遷移能讓業務測試人員更好地介入進行測試,也能實現分條線封版;劣勢是實施風險較大,在不同的條線間有較多交叉訪問或共享底層資料的情況下,要完整切割一條業務線不容易實現;相較於前兩個方案,遷移範圍會較為混亂。
所以綜上所述,我行遷移最後使用方案1。方案1雖然在工作量上有所增加,但是邏輯清晰、邊界明確、風險可控,在雙線維護工作上我們可以依靠一些工具減少複雜度。結合本章開頭提到的遷移生命週期和自下而上逐層遷移方法我們可以制定一個比較詳全的遷移總體計劃(如表所示)。
表 遷移計劃甘特圖
善用工具,不搞人海戰
在遷移實際實踐中,我行在前期制定了“多靠工具,少靠人”的方針,根據遷移週期規劃了若干工具,並在後續專案中不斷迭代,最終形成了遷移核心方法論。方法論可以歸納為六大工具,分別為:自動建表、資料同步、指令碼轉化、排程轉化、資料核驗、自動化版本比對。這6大工具是貫穿整體遷移週期的管理及開發手段,我們建議在第一個遷移模組(如貼源層或介面層)的週期內多預留一點時間打磨工具。由於各家銀行遷移的情況不盡相同,市面上很少有現成工具適配這6個功能,所謂磨刀不誤砍柴工,自主研發工具並多花一點時間留在打磨非常重要。不建議在工具沒有成熟的情況下靠人海戰(如手工翻譯的方法)去盲目開工,首先人工量巨大,臨時組建一支穩定高素質的資料團隊對一箇中等規模的銀行來說是比較困難的;其次工具移植往往錯誤比較容易跟蹤定位,手工翻譯會由於專案組內手勢不同,導致有些錯誤將比較隱晦難暴露。下文將逐一介紹6大工具的功能定位。
1.自動建表工具。將原資料倉儲內的DDL語句逐層匯出,並批次翻譯為目標資料庫的DDL語句,此工具所需技術相對較為簡單,DDL的格式也較為固定,唯一難點是需要提前考慮2個資料庫中部分欄位型別的轉換,比如關係型資料庫中Char和Vachar型別在大資料中往往都是透過String來儲存的,這需要遷移專案組提前對資料型別轉化進行規劃。
2.資料同步工具。將原資料倉儲內的資料同步至新的資料倉儲,在遷移時一般用作同步歷史資料,此工具可以在原資料庫的官網獲取其原生遷移工具,並進行一些二次開發來實現。比如我行需要將TD資料庫的內容遷移到大資料叢集,TD官網就提供給我們TDCH這樣一個工具,我們結合自身情況再將工具進行了包裝,實現了可以引數化配置的一鍵遷移功能、遷移後自動校驗功能、動態調整執行緒的功能。值得一提的是,這個工具會伴隨我們整個遷移生命週期,因為後期新數倉的紕漏都可能導致資料有誤,需要透過同步老數倉資料來覆蓋錯誤資料,所以可引數化配置的一鍵同步可以簡化後續修數的複雜度。
3.指令碼轉化工具。將原資料倉儲內的資料作業指令碼轉化為新資料倉儲的指令碼,同時翻譯新老資料庫的SQL語句,此工具重點難點在SQL語句的轉化上,網上有些現成的轉化工具,但是我們試用下來都不是特別順手(一些熱門的資料庫互相轉換工具可能會較成熟)。我們行使用抽象語法樹(AST)的方式將SQL語句中的每個元素進行識別再一一轉化,這個工具需要打磨的時間較長,建議隨專案進度迭代升級工具,目前看來SQL自動化轉換依然需要人工介入,依照我們行的遷移經驗在專案初期轉化失敗率基本在30%左右,到了專案後期迭代至10%。這個過程中需要注意的點比較多,比如新資料庫缺失函式、隱式轉換、隨機取數等等問題,需要逐一排查、逐一改進。
4.排程轉換工具。將原資料倉儲的排程程式轉化為新資料倉儲的排程程式,此工具在實現難度上不大,但是對原資料倉儲依賴關係的完整度要求較高。通常由於新老資料庫算力不同會導致很多作業批次時序發生變化,部分缺失的依賴在原資料倉儲內沒有暴露,導致新資料倉儲批次時序錯誤,且錯誤通常隱蔽不易發現,需要依靠生產並行期資料對比發現。
5.資料核驗工具。逐層對比新老資料倉儲的資料,主要用作測試和生產並行對比使用。跨庫對比工具較多,實現方式這邊不做贅述,主要提示對比工具使用上不建議抽樣對比,尤其是生產並行期。資料倉儲一般夜間進行批次,白天有充足的時間視窗可以用作對比資料,目標還是充分發現問題,縮短並行週期。
6.自動化版本比對工具。此工具主要在新老數倉並行期對比新老數倉的投產包,確保兩邊投產版本內容一致,保證資料的可比性,主要對比內容為建表語句、作業版本、排程配置、資料修改項等。除了工具外,嚴格的專案紀律和版本管理也需要在這個過程中配套定製。
管好並行期,專案成敗重點
上文提到整個數倉遷移工作會存在一個較長的並行期,且沒有一個需求封板的視窗期,雙線作戰會極大加劇遷移隱形成本。若並行期管理不當會導致版本錯亂,資料對錯無從考證,極大程度上加大了專案的不確定性。而且專案並行期是一個暴露問題的黃金時期,遇到的情況會比測試更加全面,所以一套完善的並行期問題管理方法及優秀嚴格的專案經理尤為關鍵。專案管理和問題管理方法本文不做贅述,主要介紹下我行在並行期的問題發現方式。
圖2 並行期對比方案
總體來說並行期的問題發現還是透過新老資料倉儲資料逐層、逐表、逐行、逐欄位對比來暴露。我行的方式是將老資料倉儲的資料每日批次後透過資料同步工具同步到新資料倉儲,在新資料倉儲完成資料對比,對比差異將記錄在問題清單內進行具體分析。當然這個同步及對比工作也需要講究一些策略,所以上文提及的同步和對比工具都需要具備引數配置的功能來支援我們的對比範圍變動。
在策略方面我們配套逐層遷移的思路採用了逐層比對方式,這樣更契合專案進度,我們定義一個完整的並行期即滿足以下兩個條件:此表在新老數倉並行執行超過兩個月;此表在並行期新老對比一致率超過99.5%。唯有同時滿足這兩個條件的表即不再進行每日同步對比,視為已透過驗收。在實踐過程中,即使上層資料透過驗收不再對比,而下層對比發現問題,透過具體分析穿透仍然有可能發現上層資料問題,即下層業務邏輯進一步驗證上層的資料質量。
另外,有種比較棘手的情況是資料核對不上但也無法快速定位修復問題,這裡分兩類來應對:一是若問題發生在比較上層,錯誤資料會波及較多其他作業的情形,建議在該作業後新增一個臨時資料同步,透過使用老數倉同步資料的方式堵住問題資料的蔓延;二是若問題發生在較下層,波及面不大的情況下,可以先定位問題,再修復指令碼後一次性同步老數倉資料覆蓋錯誤資料。
以上是我行在歷時一年數倉遷移工作後的一些工作方法總結和歸納。資料倉儲遷移專案是一個典型的說起來容易、做起來難的工作,每項任務都環環相扣,需要一定前瞻性和統籌性。希望透過我們的經驗給予正在遷移和即將遷移的同業一些建設性思考,助力整體行業早日脫困於國外技術依賴。
文 / 上海農商銀行金融科技部總經理助理 查曉雋
上海農商銀行金融科技部 程功 焦鬱
來自 “ 金融電子化 ”, 原文作者:金融電子化;原文連結:https://mp.weixin.qq.com/s/9H3gBDN5CA2m6kBCTmDWxw,如有侵權,請聯絡管理員刪除。
相關文章
- 資料倉儲建模方法論
- 華為雲企業級資料倉儲DWS
- 談談工業企業如何將資料編織與傳統資料倉儲結合
- Spark+ClickHouse企業級資料倉儲實戰Spark
- Harbor企業級倉庫錯誤總結
- SaaS模式雲資料倉儲MaxCompute企業級安全能力升級模式
- 儲存所有歷史提交資料下遷移git倉庫Git
- geoserver資料儲存遷移Server
- 1.1資料庫物件結構遷移方法資料庫物件
- Grafana的版本升級和資料遷移Grafana
- Mysql資料遷移方法MySql
- 企業為什麼要建資料倉儲?
- GBASE助力山東移動大資料平臺PB級資料主倉業務跨機房無感知遷移大資料
- 銀行業生產系統儲存資料遷移方法及實踐行業
- Oracle資料庫升級或資料遷移的方法探討Oracle資料庫
- 金倉資料庫資料遷移實戰:從MySQL到KES的順利遷移資料庫MySql
- 企業資訊系統在遷移過程中,資料遷移要注意什麼?
- 結合S/4HANA和雲遷移:企業如何受益
- iOS CoreData (二) 版本升級和資料庫遷移iOS資料庫
- 資料遷移(1)——通過資料泵表結構批量遷移
- 伺服器資料遷移的方法-硬體不同如何遷移資料伺服器
- 國產資料庫人大金倉Kingbase資料遷移工具資料庫
- 用prebuild mv 方法遷移資料Rebuild
- 企業郵箱託管服務遷移方法
- Mysql百萬級資料遷移,怎麼遷移?實戰過沒?MySql
- datagrip2019.1.4-升級資料遷移
- oracle RAC 更換儲存遷移資料Oracle
- 淺談資料倉儲和大資料大資料
- 談談資料湖和資料倉儲
- cassandra百億級資料庫遷移實踐資料庫
- 【ASM】ASM資料檔案和OS檔案(FILESYSTEM)轉移方法總結ASM
- 大資料和資料倉儲解決方案大資料
- gitlab的遷移和升級Gitlab
- 太強了!分散式Elasticsearch叢集資料遷移企業案例分散式Elasticsearch
- SVN倉庫備份和遷移基本操作
- mysql 備份與遷移 資料同步方法MySql
- Kubernetes 遷移節點 Kubelet 資料儲存目錄
- Elasticsearch 基於物件儲存使用快照資料遷移Elasticsearch物件