Flink 在中泰證券的實踐與應用

摘要：本文整理自中泰證券大資料中心實時計算平臺架構師連序全，在 Flink Forward Asia 2022 行業案例專場的分享。本篇內容主要分為四個部分：
平臺發展歷程
架構&選型
典型應用場景
未來展望

點選檢視直播回放和演講 PPT

中泰證券股份有限公司成立於 2001 年 5 月，是全國大型綜合類上市券商，在全國 28 個省市自治區設有 45 家分公司、300 多家證券營業部，員工 9000 多人，形成了集證券、期貨、基金等為一體的綜合性證券控股集團。

目前中泰證券服務客戶超 770 萬，為企業融資近 1.5 萬億元，公司管理總資產額超過萬億，在全國各地擁有 300 多家營業部為客戶提供各種服務。可以說中泰證券在證券行業擁有著很強的綜合實力。

一、平臺發展歷程

隨著業務的不斷髮展，對資料的時效性要求也越來越高，傳統的離線計算越發步履艱難，業務驅動著我們建立一套實時計算平臺和體系。在實時計算平臺的探索過程中，效能、場景的支援度、穩定性一直是推動我們平臺不斷升級的原動力。

首先在效能方面，需要一款高效能運算引擎支撐公司的實時類業務；其次在應用場景方面，需要平臺快速響應業務需求，上線各類服務；最後在穩定性方面，證券行業的特點決定了實時計算平臺需要擁有很好的容錯性和高可用性。

基於上述建設背景，我們平臺一共經歷了四次技術變遷。

第一階段，在 2018 年初，基於 Storm 計算引擎構建第一版實時計算平臺，採用的是一種組合式的程式設計模式。
第二階段，在 2021 年 2 月，我們基於 Flink 構建了第二版實時計算平臺，採用了宣告式的程式設計模式，並上線了第一個 Flink 業務應用。
第三階段，在 2022 年 7 月，藉助雲原生的發展，推動了 Flink 與 K8s 的整合。基於 Pod 進行 Task 資源排程，並進行大規模的業務推廣。
第四個階段，從 2022 年至今，平臺一直在探索流批一體的整體解決方案，尋求新的資料處理架構。

第一版實時計算平臺基於 Storm 計算引擎構建，採用 Storm 原生的 API，Spout、Bolt 構建任務拓撲，視窗計算、狀態儲存等功能特性透過引入第三方元件實現。在資源排程上，採用 Storm Standalone 模式部署，所有的任務共享叢集的資源。此時的實時計算平臺在客戶關鍵時刻提醒 MOT、合規風控等場景開始應用起來。

然而平臺執行不久，Storm 計算引擎開始暴露出一些問題。

Storm 計算框架自身支援的能力不足，像 Exactly Once、視窗計算、狀態儲存等特性均不支援，難以應對複雜的計算場景。
開發成本太高，上線週期太長。Storm 基於組合式的開發方式，任務的拓撲關係、資料的分發方式都需要開發者自行指定，本身就存在一定的開發門檻，簡單的作業也需要開發者編寫大量的冗餘程式碼。
資源隔離粒度較差，作業執行相互影響。另外，Storm 部署架構中 Nimbus 節點負責任務的排程，資源資料的收集、分發、Jar 包等功能。當叢集作業增長到一定數量級時，Nimbus 節點將變成整個叢集的效能瓶頸。

針對 Storm 計算引擎的種種問題，我們來看一下 Flink 計算引擎是如何一一解決的。

首先在功能特性的支援上，Flink 借鑑了一篇關於分散式快照的論文，實現了只處理一次語義，同時提供了多種狀態儲存方式等等。正是這些特性的引入，為實時計算的複雜場景提供了很好的技術支撐。

其次在開發方式上，Flink 提供了 Flink SQL、Table API、Data Stream、Stream Processing 四個級別的抽象，為程式開發帶來了很大的靈活性，開發者可以針對不同的業務場景靈活選擇。

最後是資源排程上，Flink 支援 Yarn、K8s 等多種排程方式，可以對資源進行更細粒度的控制，使資源的利用率更高，作業的隔離性更好。

因此以 Flink 計算引擎為核心的實時計算平臺上線伊始，就為各業務提供了重要的支撐。截止到目前為止，實時計算平臺已經囊括的資料來源包括集中交易櫃檯、融資融券櫃檯、產品中心、資訊中心、公募基金、賬戶系統、綜合金融、資金管理等眾多核心的業務系統，同時為齊富通 APP、掌 E 通等多種終端提供服務。

二、架構&選型

上圖是我們實時計算平臺的整體架構圖，從下之上主要包括資料來源、資料的接入層、資源的排程層、實時計算平臺、資料儲存層以及資料應用層。

在資料來源，主要採集業務資料庫的變更日誌、APP 埋點資料、日誌資料、監控資料等等。資料接入層分為兩種型別：

對於結構化資料，平臺使用商業產品 HVR 和 Flink CDC 進行採集。
對於非結構化資料，平臺使用 Elastic Beats 進行資料收集。

在資源排程層面，平臺支援基於 Yarn、K8s 的資源排程，開發者可以靈活選擇需要的資源排程方式。

實時計算平臺支援多種開發方式，支援豐富的自定義元件，同時擁有全面的運維管理體系。經過實時計算平臺加工後的資料，按場景進行分類儲存，支援輸出到 Kafka 訊息中介軟體、HDFS 離線數倉、TiDB、MySQL 等關係型資料庫，和 ES 全文檢索引擎。

最後，資料應用層支援多種資料服務方式，可以透過服務訂閱將資料推送到下游業務系統；透過介面平臺將資料提供給其他系統使用。

基於實時計算平臺的整體架構圖，我們對實時計算平臺的能力域進行了彙總，主要包括以下四個部分。

開發方式。支援 Flink SQL、Table API、Data Stream API，以及正在調研使用的視覺化構建等多種開發方式，支援不同型別的開發需求。
資源排程上。開發者可以靈活選擇 K8s、Yarn、Standalone 多種排程方式。
自定義外掛。為了提升開發效率，降低開發成本，平臺針對具體的業務場景，抽象出類似資料清洗、資料去重、維表關聯等開發模型。
運維管理。穩定性、安全性一直是平臺重點關注的內容，許可權控制、監控、告警、日誌收集、安全認證等功能支撐平臺穩定安全的執行。

實時計算平臺經過長期的技術積累、業務沉澱，可以總結出以下四大特性。

敏捷的平臺。支援與 DevOps 協同，一鍵部署線上作業。
雲化的平臺。支援 K8s 資源排程，藉助其強大的能力，實現資源的彈性擴縮容。
安全的平臺。採用多租戶隔離機制，在資料儲存、計算、排程等層面保障使用者資料安全。
開放的平臺。擁抱開放的生態，開放的架構。

三、典型應用場景

實時計算平臺的應用場景非常多，本次的分享主要從提升服務效能、實時資料管道、實時風險監測三個應用場景進行展開。

在實時平臺上線之前，客戶服務的時效性不足，這裡列舉了三個案例。

使用實時計算平臺前：

新股中籤訊息 T+1 天后，才告知客戶中籤。
客戶交易後缺少相應的資訊反饋。
客戶不能及時獲知自己持倉證券的風險警示資訊，導致客戶的體驗感較差。

經過實時計算平臺的業務場景改造後：

客戶可以第一時間獲知中籤資訊。
客戶在交易後可以立即收到資訊反饋。
客戶可以實時接收到證券的風險警示資訊。

上圖是提升服務效能應用場景的資料流圖。

資料來源主要來自上游的業務資料庫，包括集中交易櫃檯、融資融券櫃檯、產品中心、資訊資料等等。透過 HVR 將資料庫變更日誌抽取到 Kafka 中，然後 Flink 進行資料消費、邏輯加工、維表關聯，將最終的加工結果輸出到 Kafka、TiDB、MySQL 等。

下游透過 MOT、KPM、綜合金融等平臺將資料傳送到客戶終端，以齊富通 APP、簡訊、微信為載體，將資訊實時展示給客戶。

上圖向大家展示了提升服務效能場景改造後的建設成果。

第一張圖展示了客戶基金定投扣款失敗的提醒，在扣款失敗時及時告知客戶失敗的原因。後面兩張圖分別展示了客戶新股中籤的訊息提醒和客戶股票的成交提醒。

實時資料管道場景主要以技術角度為出發點，有以下四種資料流向。

Kafka 資料透過 Flink SQL 同步到 Kafka，實現不同 Kafka 叢集間的訊息複製，實現叢集讀寫分離的場景。
透過 Flink SQL 將日誌資料落地到 HDFS，提供給後續審計、資料探勘等場景使用。
將監控資料實時寫入 TiDB，實現監控運維大屏。
將客戶的流水資料、交易資料寫入 Hbase，滿足客戶實時流水資料的查詢。

上圖是實時資料管道應用場景的資料流圖。資料來源仍然來自上游業務資料庫，主要包括集中交易櫃檯、融資融券櫃檯、產品中心、平臺的日誌資料、使用者行為資料等等。透過 HVR、Agent 將資料庫的變更日誌、行為資料等抽取到 Kafka 中，使用 Flink SQL 進行資料消費、邏輯加工、資料落地。最終提供給運營分析、運維管理、大屏展示等場景進行使用。

上圖向大家展示了實時資料管道場景改造後的建設成果。

透過 Flink SQL 實現了運維監控大屏，可以透過運維監控大屏排查平臺的 CPU、記憶體、網路 IO 等異常狀況。

金融業是使用資料的重點行業，對資料具有高度的依賴性，出現資料安全問題的風險性也更大。公司一直倡導“合規風控至上”的經營理念，把風險管理文化建設作為公司發展戰略的重要組成部分。實時計算平臺為高效的風險監測帶來了一種新的可能，主要涉及的風險監測場景包括實時維保比例監控、大額申報監控、頻繁高買高賣監控、漲停價、跌停價申報監控等等。

目前風險監測主要存在以下幾個痛點：

在資料的時效性上，監測頻率為分鐘級別，資料的時效性嚴重不足，難以滿足業務需求和監管部門的要求。
在資料處理架構上，風險監測大多采用批次計算的模式，透過週期性排程作業的方式實現，存在丟失重要事件的可能性。
在資料儲存上，風險監測中間結果資料並不落地，導致無法查詢歷史的時點值，無法進行重要事件回溯。

上圖是實時風險監測應用場景的資料流圖。資料來源主要來自上游的業務資料庫，包括客戶的股份資料、負債資料、委託資料、交易資料、行情資料等等。透過 HVR、Agent 將資料庫變更日誌、行情資料等抽取到 Kafka 中，實時計算平臺進行事件消費，將客戶交易資料與行情資料進行多流合併，並關聯證券客戶、資訊等維表。

在資料架構上，採用原始層、明細層、彙總層三層架構，對資料進行組織。加工後的資料儲存到 HTAP 型別的資料庫，這裡我們選擇了 TiDB。同時在特殊場景下輸出到 Redis 佇列中，供下游系統進行消費。資料落地後透過資料推送、API 服務、報表系統等方式提供使用。

上圖是以客戶實時維保比例監測為例，展示的實時風險監測場景的建設成果。

維保比例 140%是警戒線，130%是平倉線。報表平臺對維保比例跌破 130%平倉線的客戶進行了篩查，並進行後續的業務處理。同時，無論是行情變動還是客戶發生了交易行為，平臺都將相應的記錄落地，實現對歷史任意時點值的維持擔保比例查詢，並提供視覺化的方式展現其變化趨勢。

接下來為大家分享實時風險監測在實施過程中的難點。

在效能的方面，由於實時風險監測涉及到客戶的股票、債券、基金等多種標的的綜合計算，導致計算量比較大，計算邏輯複雜。雖然 Flink 支援透過橫向擴充套件的方式解決效能問題，但對於當前的應用場景，從客戶維度無法對任務繼續進行拆解，橫向擴充套件已經無法解決此類場景的問題。
在資料準確性方面，對於任務執行過程中出現的一些異常情況，比如機器當機、服務中斷等等，如何保證資料的精準無誤呢？
在資料儲存上，需要尋找一款兼具 OLTP、OLAP 場景的資料庫，一方面 Flink 寫入結果資料的 TPS 較高，另一方面需要對落地的資料進行統計、聚合分析。

針對以上三個難點我們的解決方案如下：

針對效能瓶頸方面的難點。首先需要找到作業效能的瓶頸點，我們透過 Task Manager 節點的 CPU 負載、Flink 的背壓狀態來定位具體的 Stream Operator。透過 Arthas 評估該 Stream Operator 關鍵路徑的耗時，最終定位到產生效能瓶頸的具體業務邏輯。

在定位到效能瓶頸點之後，利用 Flink State 儲存一些中間狀態，避免業務邏輯重複計算。經過改造後，關鍵路徑的耗時下降了一個數量級，最佳化的效果比較明顯。最後在資料輸出方面，合理設定 TiDB 的寫入引數，最大程度的提升寫入效率。

針對資料準確性保證方面的難點，我們做了以下嘗試。

Checkpoint 指定持久化的儲存方式，我們選擇了星環 HDFS 作為儲存底座，保證了任務在發生異常後可以恢復執行。
作業上線後會根據業務的需求隨時更新程式碼，我們需要設定 RETAIN_ON_CANCELLATION 引數，在任務版本的升級後，仍然可以恢復當前的狀態繼續執行。
當上遊系統出現異常時，操作 HVR 進行資料回放，保證資料來源的可回溯性。同時 Flink 作業按照事件的型別進行冪等處理，保證整體資料的準確性。最後透過 Queryable State 查詢作業執行過程中的狀態資料，線上排查客戶資料的異常問題。

針對資料落地方面的難點，TiDB 輸出表開啟 TiFlash 功能，TiDB 透過 raft 協議非同步複製資料到 TiFlash。對於不同的查詢場景選擇不同的儲存引擎，對於單客戶的點查場景，透過 SQL Hint 指示使用 TiKV 儲存引擎。對於聚合統計類的場景，比如我們要查詢 Top 100 的客戶，透過 SQL Hint 指示使用 TiFlash 列式儲存引擎。經過實際觀測，在此應用場景下，透過 TiFlash 引擎可以將查詢的耗時由分鐘級降低至秒級。

四、未來展望

未來我們將從以下三個方向進行探索：

首先，實時數倉的探索。Flink 強大的流批一體能力讓我們可以很方便的去構建實時數倉體系架構。業務驅動著技術的發展，本著將業務做深、做厚的理念，我們將探索更多的應用場景，同時 Flink 與資料湖結合也是未來的研究方向之一。

其次，Flink CEP 的探索。利用 Flink CEP 強大的複雜事件處理能力，升級現有的 Data Stream 技術框架，並在風控、合規等場景推廣使用。

最後，隨著雲服務向算力服務的不斷引進，Flink 與 K8s 的深度結合也是我們後續的探索方向之一。透過 K8s 的資源排程能力實現資源穩步，提升資源的利用率。