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

? ? ??一、工行實時大數(shù)據(jù)平臺建設歷程

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

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

? ? ??二、工行實時大數(shù)據(jù)平臺建設思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? ? ??三、展望

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

? ? ??而通過 HybridSource 可以將 Hive 和 Kafka 中的數(shù)據(jù)抽象成一張表，通過一個作業(yè)就可以統(tǒng)計出最近 7 天的值，在 Flink 內(nèi)部自動實現(xiàn)類似于 union 的功能，大幅提升研發(fā)效率。

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

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