中國建設銀行有着將近 20 年的數據倉庫建設歷史，其技術平臺的轉型和應用建設過程，既是引領國內各大銀行數據倉庫建設的標杆和榜樣，同時也可以說是國內銀行業數倉建設歷程的一個縮影。
2000 年初，建行開始啓動數據倉庫的規劃和構建，最早採用了 Teradata 一體機平臺，爲業務提供了集成、統一的數據倉庫平臺，但隨着數據量和分析應用數量的快速增長，一體機平臺成本昂貴、技術封閉等痛點開始顯現。
2012 年，建行啓動新一代架構建設，在數據線引入基於 X86 架構的 MPP 數據庫 Greenplum，取得了軟硬件解耦、降低成本的效益。但隨着應用場景的深入和數據服務需求的爆發，MPP 平臺併發能力差、擴展能力受限的問題開始凸顯。
挑戰
大數據雲平臺在建設之初選擇了對現有數倉應用進行遷移和平臺國產化作爲目標，已解決現有數據倉庫平臺迫在眉睫的成本高、效率低、可控弱的痛點。
衆所周知，舊屋改造遠比建新房要複雜的多。建行數倉歷經近20年的建設，已經形成了一個具有數十PB數據量、數十個集羣、數萬張庫表、數十萬腳本的巨無霸系統。遷移如此複雜的系統，引用行領導的一句話：“遷移難度不亞於飛機在空中更換發動機，任何風險都可能導致飛機墜毀。”
因此，在技術方案上，需要對每個技術關鍵點都能考慮周全，深入探索每個技術細節並進行充分的論證和測試；在遷移方法上，需要科學完善的實施方法論，充分考慮遷移項目的工程特點和平滑過渡目標，把遷移風險做到可識別、可分析、可預測、可防範；在實施資源上，不僅需要團隊對於新技術具有前瞻性和把控能力，更需要對原有數倉體系的盤根錯節有着深入瞭解，能夠在風險發生時從技術、方案、業務等不同層面提出應對方案，及時化解風險。
實踐
Kyligence 作爲國內大數據技術的領導者和智能數倉建設的專業廠商，依託自身在大數據研發上的深厚技術功底，以及數倉領域豐富的建設交付經驗，通過與建行合作，打磨出了一整套行之有效、經過實踐檢驗的技術方案和實施方法論。
下文將結合建行項目從方案設計、ETL 遷移、應用遷移、生產試運行四個方面對遷移項目過程中的關節環節和應對方案進行概述。
技術平臺的選型
既然是遷移，技術平臺的選擇是首先需要考慮的因素。從業內主流方案來看，傳統數倉遷移的技術選型方向通常有兩種：一是從數據庫到數據庫（簡稱 DW on MPP），二是從數據庫到大數據平臺（簡稱 DW on Hadoop，此 Hadoop 並不是狹義的 Hadoop 三駕馬車，而是指的是以 Hadoop 爲基礎的大數據技術棧，或者叫廣義 Hadoop）。
-
DW on MPP 方案因爲兩套系統都是數據庫（並且基本上都是MPP數據庫），所以雖然產品不同，但技術路線差異不大，源平臺和目標平臺的兼容性問題相對較少，技術上的風險也就相對較小。但由於 MPP 數據庫的成熟度和擴展性問題，此方案只能算是過渡方案，收益也是相對比較短期的，長期來看必然會碰到上文所提到的建行（Teradata to Greenplum）已經踩過的擴展性、穩定性的坑。而且很多時候，爲了技術可控的目標，大多數都是選擇從成熟MPP產品遷移到新興 MPP 產品，當系統體量上去之後，未知的技術風險仍然是很大的。
-
DW on Hadoop 方案因爲涉及到源平臺和目標平臺的差異較大，兼容性問題會比較多，技術風險也是相對較大的。但是 DW on Hadoop 方案本身在互聯網行業，無論是數據規模還是技術架構，都已經被證明是經得起考驗並且非常成熟的架構，技術的前瞻性、可擴展性和靈活度都要優於 DW on MPP 方案。只是金融企業的業務複雜性和歷史包袱要遠高於互聯網行業，而金融行業在大數據技術能力方面的儲備的又要弱於互聯網企業，所以即使知道目標在哪裏，但是出於對整個遷移過程的風險沒有掌控力和信心，所以此方案在金融企業一直未有成功落地的實踐。
對比兩種方案的優缺點，考慮到建行的歷史和現狀以及大數據雲平臺的長遠規劃，結合 Kyligence 自身的能力和優勢，建行最終選擇了 DW on Hadoop 方案作爲數倉遷移的目標。
當前，Hadoop 平臺分佈式架構幾乎無限的擴展能力、廉價的存儲成本、強大的計算能力已經得到普遍認可，但這只是解決了數據“進”和“存”的問題，所以業內通常也只是把 Hadoop 定位爲數據湖或者 ETL 加工平臺。
但如果要承擔數據倉庫應用，如何解決數據的“用”和“出”的問題，爲業務應用提供低延遲、高併發的數據服務能力，一直是系統建設的難點。
基於多年對 Apache Kylin 的技術調研以及和 Kyligence 的合作，建行引入了 基於 Apache Kylin 的 Kyligence 增強型分析平臺作爲大數據雲平臺之上的智能分析加速引擎，智能提升查詢時效和併發能力；再結合現有的前端 BI 工具和數據服務產品，可以在業務無感的情況下做到現有應用的平滑過渡和性能提升，提升業務部門的數據分析體驗，並且能夠進一步提供海量流水分析、自助分析等新的數據應用方式和分析能力，降低業務的用數門檻，強化科技賦能業務的能力。
遷移方案的制定
建行數倉有着多層的數據架構，數百個分析應用，上萬的數據表，幾十萬的 ETL 任務和依賴關係，如此複雜的系統，從哪裏開始切入，採用什麼樣的遷移方式，如何在工作量、風險和收益之間取得平衡，是一門科學，更是一門藝術。
一蹴而就的整體遷移聽上去很美，但稍微評估一下就知道可操作性幾乎爲零。因此，基於對建行數倉的深刻理解和需求調研，我們最終採取了“垂直解構、先急後緩、差異覆蓋”的小步快跑遷移策略。
垂直解構
既然整體遷移不可落地，那化整爲零就是唯一的選擇。但具體怎麼化整爲零，應該水平解構還是垂直解構，又是擺在項目組面前的一個難題。
水平解構就是按照數倉的數據層次進行拆解和遷移，比如先從緩衝層、模型層或者中間層開始，層層遷移。這種方式的優點是複雜度低，容易劃分遷移範圍，遷移過程的風險相對較低。但缺點也是非常明顯的，每個層次的數據加工特點是不同的，各個層次需要面對的技術挑戰也是不盡相同，逐層遷移可能每次都無法達到充分“踩坑”和“填坑”的目標，不到最後始終無法評估技術方案的風險可控度。
而且這種方式不到最後，對於項目的最終價值也無法充分體現，如果遷移後的成果沒法直接給業務端帶來明顯的體驗改善，項目的價值收益也就無可評估了。
所以，我們最終選擇了按照應用主題的方式進行垂直解構和遷移。
先急後緩
既然選擇了按照應用的方式進行垂直解構，那該怎麼選擇具體的應用？在應用選擇上，我們首先確定了先急後緩的原則，也就是先選擇現有平臺上痛點最明顯、業務部門抱怨最多的應用進行遷移，這樣既能最快的卸載現有平臺的負載，快速解決短期痛苦，又能充分體現價值。
差異覆蓋
痛點應用太多，但每次的實施時間窗口和資源都是有限的，爲了達到小步快跑的目的，每期的遷移應用不能太多才能快速見效。
所以差異覆蓋，指的就是在每期應用的選擇上，從應用模式和加工流程兩個角度，充分考慮不同應用的特點，儘量覆蓋不同類型的數據分析應用，以達到儘早踩坑和積累最佳實踐的目標。
結合以上的遷移原則和建行的應用調研結果，我們抽象出了三種應用遷移場景：
-
場景一：查詢響應慢，業務部門抱怨大，希望能夠速提升業務體驗的應用，可以直接將加工好的結果數據遷移過來，通過新平臺直接提供數據服務，提升查詢體驗；
-
場景二：ETL 加工和查詢都受到源平臺上資源不足影響，無法滿足業務數據時效性的應用，將公共訪問層的數據平移到新平臺，在大數據雲平臺上進行後續的 ETL 加工和查詢訪問；
-
場景三：ETL 時效慢，加工路徑長的應用，進行端到端的遷移，從數據源頭遷移，對數據模型進行重構，從而整體提升數據加工效率。
ETL架構和腳本遷移
ETL 是數倉的骨骼，因爲技術平臺的改變，原本 ETL 腳本應該如何改造和遷移，是遷移項目中工作量最大、難度最高的環節。
ETL 引擎的選擇並不難，Kyligence 基於自身的經驗積累和成功案例，考慮到儘量保障新老平臺的兼容性，並且結合 Hadoop 技術棧的發展趨勢和成熟度，選擇了目前最爲流行的 Spark 計算引擎作爲大數據雲平臺的 ETL 引擎，這也是衆多互聯網 DW on Hadoop 平臺的一致選擇。
但要把數十萬 ETL 腳本從 MPP 數據庫遷移到 Spark 引擎，考慮到 MPP 數據庫和 Spark 引擎在底層技術架構上的差異，數十萬腳本之間複雜的依賴關係，全靠人工來分析和遷移的話，那最終的結果就真的是血肉築成了。
爲此，我們開發了包含數據血緣分析、腳本轉換、數據覈對等一整套的智能化自動遷移工具，通過對腳本依賴關係進行提取、ETL 腳本自動轉換、ETL 數據結果核對的全過程進行自動化操作和監控，來簡化 ETL 腳本遷移和數據比對的工作量，確保 ETL 遷移這個項目實施環節中工作量最大、風險點最多的環節得到大大簡化和有效控制。
-
血緣分析：數據倉庫的依賴關係錯綜複雜，外三層裏 N 層，任何一條路徑分析錯誤可能導致整個遷移項目返工，所以需要通過數據血緣分析工具，提取出遷移目標表和作業的屬性，包括表的依賴關係、相關腳本範圍，字段血緣，作業血緣等，精確分析每條路徑的所有依賴關係，確保依賴不丟失、不冗餘、不重複；
-
腳本遷移：利用腳本自動化轉換工具，實現了自動化將ETL腳本從Greenplum平臺的 SQL 轉換成 Spark SQL ，減少遷移過程中的開發工作量，降低人工錯誤率；同時爲了規範腳本開發、簡化後續開發人員的腳本編寫難度、動態分配任務資源等，不僅將公共參數部分代碼上收（支持特殊參數），還可通過配置，動態調整任務資源預分配，做到資源精細化管理，與此同時，開發人員只需要維護自己的 SQL 語句，無需學習其他開發語言，降低平臺變化帶來的技術門檻和學習成本。
-
數據比對：遷移項目數據覈對工作量巨大，特別是異構平臺，不僅要快速遷移數據，而且還要保證數據的準確性；數據倉庫的表個數多則上萬張，少則也有幾千張，靠人爲比對，且不說比對工作量，單編寫各種指標的比對 SQL 語句都要花費很多時間，而且還是不同平臺；通過在項目中利用自動化數據覈對工具快速定位雷區，從記錄數逐步排查，可自定義關鍵指標覈對，明細採樣比對等，逐步實現自動化數據覈對，大大減少了人員工作量投入。
數據模型的優化
如果說 ETL 是數倉的骨骼，那數據模型無疑是數倉的靈魂。對於金融行業的數倉從業者來說，談到數倉遷移，通常覺得最困難的、也最關心的都是數據模型的改造。
但對於遷移類項目，模型的遷移原則卻是能少動就少動，畢竟靈魂的改造是最難的。系統遷移最大的風險在於遷移過程中的數據不一致會導致原有應用的不可用，影響現有業務，從而沒法實現平滑過渡的目標。而模型改造必然會引起後續數據加工邏輯的變化，從而以多米諾骨牌的方式影響到後續一系列數據應用的可用性。
但另一方面，從 MPP 到 Hadoop，技術平臺的改變，底層架構的巨大差異（比如數據存儲方式的差異、查詢優化機制的差異），又不可避免會需要對模型進行改動以適應新的技術特性。
所以，對於數據模型，在遷移項目的初期我們的整體原則是先做平移再做優化，拒絕一步到位的大規模改造，在系統風險最可控的情況下進行定點優化。
當然，具體到實施方法上，我們可以把數倉的模型分爲底層的數據整合模型和上層的應用集市模型兩部分，結合新老系統的技術差異，兩者的設計方法和優化策略也是不同的。
數據整合模型
因爲歷史原因，國內金融機構的數據整合模型通常都是以FS-LDM 爲基礎，建行也不例外。FS-LDM 站在企業數據架構的高度，以金融業務視角進行抽象和設計，其普適性和可操作性都得到了實踐的檢驗，有着經久不衰的生命力。
但 FS-LDM 在 MPP 平臺上進行物理化時，會優先考慮數據存儲成本和擴展靈活性，基本採用範式建模的方式。這種設計方式方便數據進入，但對於後續的數據加工和數據分析，卻帶來了巨大的關聯成本，這在 MPP 平臺上一直都不是大問題。但對於 Hadoop 架構，卻無疑是一場噩夢，平移後的不少腳本都會出現 ETL 性能下降的情況。所以在數據整合模型層面，我們對於平移後性能下降明顯的關鍵模型，會基於“邏輯模型不動，物理模型優化”的方式，對原有範式模型採取維度建模、逆範式等方式進行優化，依託 Hadoop 的存儲成本優勢，以空間換時間的方式取得 ETL 性能和靈活性之間的平衡。
應用集市模型
數倉裏應用集市模型通常都是維度建模或者大寬表，這種設計方法原本已經比較適合 Hadoop 平臺的技術特點。但如上文所述，在整體技術架構上，Hadoop 平臺增加了 Kyligence 產品作爲數據集市和前端應用之間的數據服務層，以獲得比 MPP 平臺更加極致的查詢性能體驗，並且能應對高併發的數據服務需求。數據服務層面向前端應用場景，其模型設計需要充分考慮業務人員的查詢使用模式和習慣，如何設計才能在不影響業務原有使用模式下，透明加速整個查詢體驗，是在遷移過程中對應用集市模型進行優化的主要考量點，比如：
-
庫表分區列的選擇；
-
維度的設計和Rowkey的排序；
-
維度值的編碼方式等；
考慮到建行數倉經過歷史的沉澱，每天的查詢量有幾十萬筆，如果對這些查詢語句一一進行分析，找出共性和優化的方法，再進行物理模型的設計和優化，將又是一項巨大的工程。Kyligence 產品內置的智能建模功能，可以通過批量的獲取和分析歷史查詢語句、使用頻次以及響應時間等行爲日誌，對數據服務層的多維模型、維度及度量進行智能推薦和優化，從而可以大大節省應用集市模型的優化難度。
收益
Kyligence 智能數倉方案和遷移實施方法論，通過建行一期的信用卡主題、商戶主題、對公存款等應用的落地，經受住了海量數據和大規模複雜系統的檢驗，充分證明了 DW on Hadoop 方案在金融企業數倉建設上的技術可行性，也爲建行大數據雲平臺的建設帶來了明顯的收益：
-
通過大數據分佈式架構的擴展能力，實現了建行數據的統一存儲，讓數據分析時間跨度可以從 18 個月擴展至 5 年，可以更好的滿足精準營銷、智能風控等大數據分析應用內的數據需求；
-
通過 Hadoop 強大的並行計算能力，提高 ETL 加工時效，應用遷移到新架構後，ETL 任務的加工時間提升了約 60%~80%，使得數倉的批量數據加工時效 T+1 成爲可能；
-
通過“空間換時間”和智能加速技術，遷移應用的查詢性能提升了 60~170 倍，並且併發能力提升約 5~10 倍，實現了業務人員在任何時間都可以與數據進行實時交互、隨意鑽取分析明細數據；
-
通過數據服務層的引入，基於智能建模、智能路由等功能，實現了技術架構變化對前端業務的透明，提升了原有報表、Dashboard 的使用體驗，並且進一步爲業務人員提供了多維分析、自助分析、明細查詢的能力；
-
通過自動化遷移工具的應用，實現了 90% ETL 腳本的自動化轉換，節省了 30% 的對數工作量。
結語
如前所述，系統遷移正如舊屋改造，前難度和複雜度遠遠高於新修一棟房子，而數倉系統遷移，特別是建行這麼大數據量、這麼複雜的數倉系統遷移，其複雜度和工作量已經不僅僅是舊屋改造可以比擬的了，甚至可以算的上是城市搬遷了。
Kyligence 有幸能夠參與到建行數倉轉型和大數據雲平臺的建設過程中，以上的幾個點只是我們在國內金融數倉架構轉型過程中對於最佳實踐和實施方法論的一些概要介紹，其實除了以上提到的幾個點，即使是需求調研、項目管理、人員儲備甚至是系統運維這些所有項目都存在的常規環節，都會因爲量變而引發質變，從而成爲巨大的挑戰。
後續我們會陸續發佈系列文章，對項目中的經驗和最佳實踐不斷總結，並深入解讀每部分內容，更多精彩，盡請關注我們的公衆號。
作者簡介：
吳春貴，Kyligence 交付項目總監，有十多年銀行數據倉庫項目實施經驗，曾經參與多家大型銀行數據平臺建設，對於企業架構轉型有着深刻的理解和豐富的經驗。