? ? ? ?本篇內容將通過三個部分來介紹工商銀行實時大數據平臺建設歷程及展望。

一、工行實時大數據平臺建設歷程

二、工行實時大數據平臺建設思路

三、展望

? ? ? ?一、工行實時大數據平臺建設歷程

? ? ? ?工商銀行從 2002 年開始建設數據集市，當時主要使用 Oracle 類單機版的關系型數據庫。隨著數據量不斷增加，開始引入 TD、ED 等國外高端一體機。2014 年工行正式基于 Hadoop 技術建設了大數據平臺，在其之上構建了企業級數據湖及數據倉庫。2017 年，隨著 AI 技術的興起，又開始建設機器學習平臺，2020 年開始建設數據中臺和高時效類場景。

? ? ? ?為了滿足數據時效，以及企業級大規模普惠用數的訴求，企業內部的大數據平臺需要不僅支持批量計算，還需要滿足各類用數場景全棧覆蓋的技術體系。以工行為例，大數據平臺內部除批量計算之外，包含實時計算，聯機分析、數據 API 等平臺，主要以 Flink 作為內部引擎，用于縮短數據端到端閉環時間，形成聯機高并發的訪問能力，提升數據賦能業務的時效。除此之外，還包含數據交換、數據安全等面向特定技術領域的二級平臺。在最上面一層，我們向開發人員、數據分析師、運維人員提供了可視化的支撐工具。

? ? ? ?二、工行實時大數據平臺建設思路

? ? ? ?工行實時大數據平臺建設思路，主要會圍繞時效、易用、安全可靠和降本增效來展開。

? ? ? ?在數據時效方面，上圖是描述數據流向的示意圖，原始數據從左上角的應用產生，經過藍色和粉色兩條鏈路。其中，藍色鏈路是業務視角上端到端閉壞的鏈路，應用產生的數據會寫入 MySQL 或者 Oracle 等關系型數據庫，之后通過 CDC 相關技術，將數據庫產生的日志復制到 Kafka 消息隊列中，將同一份數據的共享，避免多次讀取數據庫日志。

? ? ? ?在 Kafka 之后，是實時計算平臺。實時計算平臺除了實現對時效要求較高的計算處理場景之外，它還可以通過 Flink 結合 HUDI/IceBerg 等產品實現實時數據入湖。而且能將 Flink 的結果輸出到 HBase\ES 等聯機數據庫中。將這部分數據以服務的形式暴露，即數據中臺服務，從而提供給應用調用。

? ? ? ?粉色鏈路的數據，最終回到數據分析師那里，是藍色鏈路的衍生。各個應用產生的數據，通過 Flink 和 HUDI 的實時數據入湖，通過 Presto 或 CK 等分析型引擎，供數據分析師進行 BI 分析。通過這條鏈路，數據時效得以提升，讓分析師訪問到分鐘級延時的熱數據，更加實時、準確地做出運營決策。一般高時效的業務場景，都包含在這條技術鏈路的體系之內。

? ? ? ?在余額變動場景，客戶進行一次動賬交易，可能觸發多種通知內容，例如賬戶支出提醒、賬戶收入提醒、積分消費提醒等，造成客戶手機連續收到短信提醒，用戶體驗不佳。因此，工行基于 Flink 多流合并和會話窗口的能力，將同一時刻發生的多條消息關聯，將通知的邏輯合并在一起發送給客戶。而當一條消息出現晚到的情況，通過會話窗口的 GAP 設置能自動降級，將邏輯分為兩條消息發出去。大幅提升對用戶的友好性。

? ? ? ?每家商業銀行在每年 12 月 31 日時需要出年報，所以那天銀行需要對全年的利潤分配等指標進行試算。工行和其它商業銀行一樣早期使用 DB2 主機實現核心交易，年終時的損益、預查詢都在主機上實現。但主機是按 MIPS 收費，所以當這種預查詢多次執行時，成本很高。

? ? ? ?因此工行做了架構改造，通過 CDC 數據復制技術，將主機實時發生的數據復制到大數據平臺，通過 Flink 進行實時 ETL，數據搬運過來之后，充分利用大數據平臺海量的計算能力，大幅提升預查詢效率。原來每天跑 10 輪，現在每天可以跑 30 輪，原來每輪 30 分鐘，現在每輪只要 10 分鐘，既提升了時效又節省了成本。

? ? ? ?實時大屏場景一般都是基于日志采集或 CDC 技術實現數據的統一匯集，基于 Flink 進行實時的業務量統計。工行也是通過這種方式實現的實時大屏，并使用了 Flink 的 mini-batch 的特性。雖然 Flink 能逐條實時處理數據，但在大部分場景，它會有 1ms 和 100ms 的延時，mini-batch 的特性類似于 Spark Streaming 微批的處理方式，在增加小量數據延時的情況下，大幅提升海量數據的吞吐能力，非常適用于實時大屏的場景。

? ? ? ?在銀行業早期，大家基于 DB2 主機支撐核心業務。隨著國內去 IOE 以及自主可控轉型的浪潮，各家商業銀行都開始將主機上的業務，遷移到分布式體系上，通過服務化接口的調用，滿足不同業務系統之間的協作。業務遷移到分布式體系后，在調用多個服務化接口時，由于網絡抖動等影響，會出現交易中，部分環節失敗的情況。

? ? ? ?為了解決這個問題，工行基于 Flink 研發了業務一致性對賬中心，將服務化接口調用過程中的調用日志，統一匯集到 Kafka。基于 Flink 會話窗口的特性，判斷交易中各個環節的調用是否完整。如果發現不完整的情況，會觸發業務上的補賬 / 核對動作，及時消除對客戶賬務的影響。

? ? ? ?早期的實時計算模型都是基于 Java 等高級語言進行開發。在 Spark Dataframe 以及 Flink SQL 出現之后，開發人員可以通過 SQL 來開發實時計算模型。隨著分布式體系以及數據中臺的發展，很多實時計算模型在處理業務邏輯過程中，需要訪問外部聯機接口。

? ? ? ?工行將調用的 HTTP、Dubbo、Redis 等外部接口，抽象成一張張外部表。直接通過一句 SQL 就能將 Kafka 中的流表與 Dubbo 的維表關聯，然后將結果送到 HTTP 接口，大幅提升開發效率。

? ? ? ?接下來，給大家分享一下工行在用數支撐工具方面的實踐。在業務研發方面，通過借鑒業界 DataOps 的理念，工行打造了一條集開發、測試、版本制作及發布于一體的研發流水線。

? ? ? ?相比于早期大數據工程師基于 UltraEdit 開發的模型，這種可視化 IDE 的開發效率至少提升 10 倍以上。同時工行的開發平臺也于今年通過了中國信通院“數據開發平臺”的認證測評，信通院在 12 月 10 日通過官方公眾號公布了測評的結果。

? ? ? ?在生產運維方面，工行為運維人員提供多個用于展示平臺健康狀態的儀表盤。同時，并通過機器學習和專家規則相結合的方式，實現了面向多類場景的故障根因自動分析的能力，降低運維門檻。

? ? ? ?對于開發人員來說，他們更關心作業中斷后運維平臺能否幫助分析問題，所以在作業中斷時，為開發人員提供問題診斷能力，95% 以上的常見問題都可以自動完成分析。

? ? ? ?在 BI 平臺，工行面向業務人員提供了自助數據分析探索的能力。主要解決用數最后一公里的問題。分析結果提供了多樣化的展示儀表盤，不但支持基于拖拉拽的多維分析，而且支持數據下鉆挖掘等功能。

? ? ? ?接下來，給大家介紹工行在大數據平臺安全可靠性方面的實踐。

? ? ? ?近幾年各個行業對數據安全的重視程度都越來越高，而大數據平臺作為全集群數據的匯集地，對數據安全保障方面能力的建設就顯得更加重要。大數據平臺不但要存儲很多數據，而且要提供的各式各樣的數據訪問方式。

? ? ? ?因此工行設計了一套全生命周期用數監控審計，類似于 Ngnix 的 access.log，主要用于事后追溯審計。當用戶將數據拖回到本地時，平臺會對數據加上水印，當有些數據被非正常公開后，就可以知曉數據泄漏的來源，同時對身份證、手機號、卡號等敏感字段，在返回時動態脫敏，比如 11 號的手機號中間幾位都會變成“********”。

? ? ? ?動態控權是因為有些數據訪問權限控制粒度較細，工行實現了一套 SQL 改寫引擎，在運行時對 SQL 進行解析，根據用戶與表權限的對照關系，對 SQL 加上控制條件及脫敏函數，避免數據被越權訪問。敏感數據識別是基于專家規則或 ML 模型，自動識別海量數據中的敏感信息，并自動進行分類分級。同時，提醒管理員對敏感信息和分類分級結果進行核實確認。

? ? ? ?在大數據平臺建設的早期，大家主要將一些非關鍵的增值類業務放到大數據平臺。隨著技術的不斷成熟，很多機構開始將核心的業務部署到大數據平臺。為此工行在上海外高橋和嘉定兩個數據中心建立了雙活的大數據平臺，通過系統級復制確保兩邊基礎數據同步。對于部分關鍵業務會在兩邊同時運行，通過這種架構來確保關鍵業務的穩定。

? ? ? ?上圖是數據離線備份架構。金融機構在監管方面，對于數據存儲可靠性的要求很高，所以，我們將 NBU 磁帶備份系統和 Hadoop 以及 MPPDB 數據庫的接口做了集成，實現了類似于 Oracle RMAN 的數據存儲，增量備份的能力。

? ? ? ?根據國家監管的要求，大部分金融機構的大數據平臺一般都以私有化的部署方式為主。在早期 Hadoop 技術剛出現時，大數據平臺的設備選型以物理機 + 本地磁盤為主，盡可能實現本地計算。目前，主流的公有云大數據云服務以存算分離的架構為主。那么在建設金融機構大數據私有云時，到底應為物理機 + 本地磁盤為主，還是以存算分離架構為主呢？

? ? ? ?在公有云實現存算分離的最重要的原因就是：資源的超分配。超分配就是，假設公有云上有 10 個租戶，每個租戶分別申請了一個 10 節點的集群，但由于這 10 個租戶的資源使用都會存在錯峰的情況，因此云平臺只要準備 50 臺設備就可以滿足上述需求，并不需要實際準備 100 臺設備，這就是超分配。

? ? ? ?私有云的大數據平臺，一般會按業務線來劃分集群。每個集群可能是數百臺設備的規模，并不會出現大量的小租戶、小集群，但集群間確實會存在一定錯峰的情況。

? ? ? ?對于這種情況，工行更傾向于使用固定資源 + 彈性資源混合部署架構。如圖所示，左邊基于裸金屬的固定資源池，用于滿足日常的資源需求。右邊基于容器的彈性資源池，用于滿足特定事件發生時突增的需求。同時，這部分彈性資源池，可以在不同的集群之間，動態調配復用。

? ? ? ?三、展望

? ? ? ?我們先來講講 Flink 1.14 版本中發布的 HybridSource 能力。目前，在上線一新的實時模型時，如果涉及到歷史數據的統計指標，以金融行業為例，在一個反欺詐模型里，需要最近 7 天累計交易額的統計指標。這種情況下，我們一般會先跑 Hive，批量算出前 6 天的統計值，放進 Redis，然后基于 Flink 讀取 Kafka 中的數據，統計當天的增量數據，再進一步匯總成最近 7 天的統計值。這個過程，需要分兩個作業來實現。

? ? ? ?而通過 HybridSource 可以將 Hive 和 Kafka 中的數據抽象成一張表，通過一個作業就可以統計出最近 7 天的值，在 Flink 內部自動實現類似于 union 的功能，大幅提升研發效率。

? ? ? ?關于動態資源調整，隨著平臺規模越來越大，資源利用率的關注度就越來越高。實時計算在一定特定的場景，會出現交易量突增的情況。對于這類情況，工行目前還是采用手工擴容，或者通過業務側將批和流結合的方式解決。比如在雙十一大促之前，工行都會提前一周對交易相關的實時計算模型，進行手工擴容，大促之后再手工縮容。這個過程，總體比較復雜。

? ? ? ?因此后續希望 Flink 通過具備動態擴縮容的自適應能力，配置 min 和 max，引擎可以自動根據數據量的負載在 min-max 之間，調整使用的資源量從而提高整個平臺的資源利用率。