Flink 流處理在中信建投證券的實踐與應用

摘要：本篇內容整理自中信建投證券金融實時數倉專案負責人劉成龍、金融資訊資料研發工程師蔡躍在 Flink Forward Asia 2021 行業實踐專場的演講。主要內容包括：
中信建投證券 Flink 框架
Flink 流處理場景
金融資訊實時化改造
未來展望

點選檢視直播回放 & 演講PDF

中信建投證券公司成立於 2005 年，2016 年港交所上市，2018 年上交所主機板上市。投行業務連續 8 年保持行業前 3，託管證券規模行業第 2，主要經營指標目前均列於行業前 10。伴隨著公司的業務一路高歌猛進，技術方面也不容落後，數字化轉型正在成為我們近些年來的發展重點。

由於金融行業涉及的業務領域眾多，公司多年來積累了大量複雜的與業務高度相關的基礎資料，在發現問題、分析問題，解決問題的過程中，如何協調業務前、中、後臺以及科技部門等多方面配合來開展業務口徑的梳理與加工邏輯的開發，成為目前亟待解決的關鍵問題。

一、中信建投證券 Flink 框架

資料中臺架構如圖所示。主要分為以下幾大板塊：由 Greenplum 資料倉儲和 Hadoop 大資料平臺構成的資料中心板塊；以離線開發、實時開發、資料交換為主的資料開發板塊；以及資料門戶、資料閘道器、資料治理、運營管理等板塊構成。

其中資料開發板塊目前的任務主要以離線開發與資料交換的離線資料處理為主。但隨著業務對資料時效性的提高，基於離線批處理的 t+1 業務模式已經無法完全滿足當前市場環境下對資訊及時性的需求，這也是大力發展實時開發，力求為客戶提供更高時效性資料服務的目的。

我們以實時開發整個鏈路為例，對資料中臺各個板塊間的相互聯動進行說明。

從資料門戶統一入口進入實時開發模組，首先將集中交易、融資融券等業務資訊的實時增量資料拉取到 Kafka 訊息佇列，Flink 消費 Kafka 實時流資料並與維表資料進行資料加工。加工邏輯中涉及的維表資料量比較大時，需要離線開發與資料交換，通過離線跑批的方式完成對維表的資料準備。最後將結果資料寫入關係型資料庫或 NoSQL 資料庫。資料閘道器再通過讀取結果資料生成 API 介面，對下游的系統提供資料服務。

資料治理板塊中的資料管控模組主要管理資料中臺的資料庫表以及業務相關的資料庫表的後設資料，使用者可以在資料門戶訂閱他們所關注資料庫表的變更資訊。當訂閱的資料表發生了變化的時候，運營中心可以通過統一告警模組，多渠道通知訂閱使用者資料庫表的變更情況，以便於開發人員及時調整資料加工的任務。

Flink 實時流處理架構首先通過 Attunity 工具採集業務資料庫的 CDC 日誌，將同一系統下的資料庫表變化寫入 Kafka 的一個 topic 佇列中，這也就意味著 Kafka 的每一個 topic 中都會有多個表的資料，所以在 Flink 的 Kafka source 要先對 schema 和 tablename 這兩個欄位進行一次過濾，獲取想要拿到的資料表的 CDC 資料流，再進行後續與維表的加工邏輯。將處理後的資料寫入結果表，根據需求不同寫入不同的資料庫進行儲存。

資料庫的選型一般遵循以下原則：

資料量比較小且不要求高併發的情況下，通常選擇關係型資料庫進行儲存；
資料量較大，而且對高併發有需求的時候，通常選擇 HBase 作為儲存介質；
少量資料但要求高併發的情況下，選擇 Redis 進行快取；
涉及大量資料檢索的情況下，一般選擇 ES 作為儲存元件。

證券行業資料有兩個明顯特徵：

其中一個是開盤的時間固定，大量業務在收盤後資料量會大幅減少，甚至有一些業務在收盤後不再產生新的資料，所以為了節約資源，我們會根據實際情況對那些與開盤時間緊密相關的任務設定啟停時間；
第二個特點是金融資料的重要性，大量場景下不允許資料偏差存在，針對資料可靠性要求極高的特徵，我們對大量實時任務設定了夜間資料修正的離線任務，保證資料的正確性。

二、Flink 流處理場景

下面以幾個實際場景說明 Flink 流處理的應用情況。主要分為三個場景，零售業務實時指標統計、基金投顧實時指標統計和資金流水明細查詢。

2.1 零售業務場景

零售業務線實時指標是管理駕駛艙的重要組成部分，決策者通過分析公司運營指標，對公司的運營和發展作出合理決策。

面向零售業務設計實時數倉，需要獲得開戶統計、客戶服務、APP 運營幾個主題的統計指標，根據實時資料處理架構和資料倉儲分層的設計，面向零售業務的實時數倉可以分為以下幾個流程：

首先是構建 ODS 層資料，實時採集客戶資訊表、業務流水錶、渠道表等相關基礎表的 CDC 日誌。每個業務庫的資料表對應接入到一個 Kafka 的 topic 中建立實時數倉的 ODS 層；
其次是 DWD 層的資料建模，建立 Flink 任務消費 ODS 層的 Kafka 訊息，進行資料清洗，過濾、脫敏、關聯轉換等處理。同時以客戶賬戶粒度進行資料合流，藉助離線維表進行擴圍操作，以獲得賬戶粒度的明細表，實現 DWD 層的建立；
之後是 DWS 層的資料建模，基於 DWD 層的資料進行彙總，通過分析業務需求，將 DWD 層的資料按照主題進行劃分，彙總出渠道服務主題寬表、業務部運營主題寬表、交易產品主題寬表等公共指標寬表，建立 DWS 層；
最後根據實際業務需求，計算業務指標建立 ADS 層。對於一部分使用者賬戶粒度的業務指標，可通過 DWD 層的明細直接計算得到，部分粗粒度的業務指標比如 APP 渠道服務客戶人數、投顧產品閱讀人數等，可以通過 DWS 層計算獲得。最終計算結果接入到資料閘道器將資料統一提供給下游系統或通過 BI 系統展示。

通過對實時數倉進行分層管理，能夠帶來兩方面的好處：

首先是避免煙囪式的資料開發模式，無需所有任務都從消費 Kafka 的 ODS 層資料開始，減少了時間上的開銷，更有利於資料的恢復，並能夠支撐不同業務主題的靈活分析；
其次在資料加工出錯的情況下，更容易判斷是哪個分層的資料加工邏輯出了問題，縮短排錯時長。

2.2 基金投顧實時指標統計場景

基金業務在證券行業的重要性日益凸顯，它能實時提供基金投顧產品的銷售資訊，為基金投顧及時調整策略提供資料支援。基金投顧場景的資料有三個特點：

第一，涉及的資料規模比較小；
第二，資料在開盤時間提供給公司內部人員檢視；
第三，資料對準確性的要求特別高。

針對資料量小的特點，我們將資料指標結果輸出到 Oracle 關聯式資料庫；針對開盤時間將資料供給內部人員檢視的特點，我們開啟實時任務的啟停策略，將更多的資源留給夜間跑批的任務來使用；針對資料準確性要求很高的特點，我們通過夜間離線跑批的方式對資料進行修正，以保證資料的準確性。

原來的方案是通過頁面觸發儲存過程來讀取資料，而且讀取的資料不是源系統資料，存在分鐘級別的延遲。而實時資料加工方案通過實時推送客戶新增、追加、簽約、保有、簽約率、規模等維度的指標，讓業務部門可以更高效地掌握核心資料。

2.3 實時 ETL-資金流水場景

此場景主要滿足業務人員在開盤期間快速查詢客戶某個時間段內的交易流水明細資料。它需要解決三個問題：

第一，資金流水明細，總共幾十億的資料，資料量很大的情況下，如何做到快速查詢？
第二，開盤時間內滿足業務人員查詢，且非開盤時間內資料量較小，是否採用定時排程？
第三，資金流水一定不能出錯，如何保證資料的準確性？

針對資料量大的特點，我們最終選擇通過 Hbase 元件來儲存資料，通過合理設計 rowkey 與建立 region 分割槽，達到快速查詢指定時間段內的資金流水明細情況；針對非開盤時間內交易資料量很小的特點，開啟任務的定時啟停策略，將更多的資源留給夜間跑批任務；針對資料準確性要求高的特點，通過離線資料修正的方法來達到準確性的要求。

三、金融資訊實時化改造

在金融領域每天有著各種新聞公告等這些每個市場參與方最常閱讀和關注的資訊。我們公司對資訊的定義不僅包含上述這些傳統意義下的資訊，考慮到資料本身的龐雜多樣及收集、管理、應用等實際流轉過程，我們對資訊做了重新定義，即所有的非使用者非交易相關的資料均為金融資訊範疇。

我們中心匯聚瞭如下 4 大類金融資訊資料，最常見的就是新聞、公告、研報，此外還有交易市場相關的貨幣、股票、債券、基金、衍生品等證券市場資料和各個維度的巨集觀行業資料，最後一類是包羅永珍作為兜底的其他及衍生，涵蓋了各種基於市場原始資料進行分析的其他第三方機構分析的資料，比如公司輿情、基本面分析預測等。

如果把交易和使用者比作金融市場的骨骼和經絡的話，資訊資料就是我們金融市場的血液，產自前者貫穿全身且源源不斷。

那麼品類龐雜的資訊資料具體如何流動？很簡單，如圖所示的三層結構：最底層是我們引入的資料來源，目前大多數資訊資料已經被 Wind、同花順等資訊資料商收集整理，我們不需要花費太多的時間成本即可獲得種種基礎資料。

但隨著引入資料商的增多，問題也隨之而來。假設某個資料商出了問題導致合作不能繼續，資料服務也必定會受到影響。為了解決這個問題，我們推出了中心庫的概念，自建了一套金融資料模型，下游系統都和中心庫的資料結構對接，我們負責把資訊資料商遮蔽掉，這就是圖中的第二層。

上圖最右側還有一個小模組叫資料直髮，因為實際應用中並不是所有的下游系統都適合對接，有些依然依賴原始的資料商結構，所以這個小介面依然存在，和中心庫並行共同輸出資料服務。

最上層是服務物件，覆蓋了公司內部的各個業務線，持續為各個業務系統輸血。

在三層的整體架構下，日益增多的資料來源還有資料種類提升了我們資料服務的整體質量，有能力服務更多的客戶。同時中心庫為核心的架構，提高了整體服務的抗風險能力，防範風險是金融公司重中之重的事。

我們前期的工作主要集中在這兩點上，當這兩個功能慢慢完善且穩定後，關注點逐漸轉移到資訊資料傳輸和資訊內容優化上。市場瞬息萬變，資料在鏈路上傳播耗時越短，資訊在時間上的價值越高，傳輸速度沒有上限、越快越好，這就是資料傳輸效率。但是，資料快了而上游資料商的質量參差不齊，服務只快不準，提供給使用者的資料存在問題，那麼如何在不損失 1、2、3 點的情況下，把控資料內容質量也成了棘手問題。

為了優化 3、4 兩個點，我們以 Flink 引擎為核心進行了架構改造，選取了兩個場景進行分享。

3.1 蜻蜓點金 APP F10 新聞場景

蜻蜓點金 APP 主要提供金融資訊，資料服務給廣大的投資者瀏覽。上圖是第一版方案，主要流程為從上游的標籤系統為新聞打標，流入到 Kafka 中，進而進入剛剛所設計的中心庫，下游使用時將資料進行抽取轉化，傳輸到介面庫，最終通過 API 對外提供服務。

為了及時獲取資料庫的變化情況，我們在眾多的 CDC工具中選取了部署輕量、整合方便的 Canal 來實施。通過捕獲資料庫的變更，開發人員編寫程式實時讀取訂閱 Canal 資料，將資料解析組合為業務所需的資料格式，然後主動更新寫入到最上方的 Redis 中。下游使用者在使用相關介面時，就可以獲得最新的資訊資料，無需再等待資料被動過期。

方案一執行一段時間之後我們發現兩個問題，一是鏈路偏長，會損失時效性；二是主動寫快取過程逐漸成為整個資訊服務的重要一環。但 Canal 作為開源工具，功能還在不斷完善中，如程式監控、告警等需要單獨開發實現，此外穩定性和高可用方面也略顯不足。

為此我們引入 Flink 對資料鏈路和資料處理環節做了調整。資料處理方面，利用 Flink 高效的 ETL 能力，引入了高時效性要求的資訊資料處理場景，同時 Flink 作為流式計算引擎，天然和 Kafka 整合，可以無縫對接，具有直接輸出訊息到 Kafka 能力的系統，如新聞標籤系統。社群一直在完善各種 connector，像 CDC 方式就為 Flink ETL 能力提供更大的空間。同時 Redis sink 的支援也使得原有的快取程式、業務邏輯可以整合到 Flink 中統一實現。最終使整個資訊資料處理過程得到了集中管理，縮短鏈路，節約了傳輸時間。

強大的 ETL 能力降低了架構的複雜度，節約了原有的一系列元件。從整體來看，分散式高可用的架構貫穿了上中下游，使得資訊服務能力可以穩定高效地輸出。從長遠來看，資訊資料應用廣泛，來源和輸出多樣，Flink 不斷豐富的聯結器也可以支援資料來源和目的端的進一步擴充套件，為資訊資料可以應付更多的場景帶來可能。

3.2 多源資料交叉檢驗場景

如果能用一套架構解決所有問題那是再好不過的，為此我們在多源資料交叉檢驗的場景上做了嘗試。這個場景主要為了解決把控資料內容質量的問題。資料更快，可以通過技術手段得帶解決，但是資料更準就不是我們處在中間環節所能左右的了。

上游依賴諸多的資料商，資料商可能是爬蟲採集、人工錄入、資料接收等方式得到資料，多樣的資料種類和多樣的環節導致了我們接收到的資料質量參差不齊，而且問題還會直接傳導到下游並逐級放大。而我們由於離源頭較遠，不可能跨過資料商來提供準確的資料服務，只能退而求其次變成了提供及時的糾錯服務。

市面上的資料商競爭激烈，同一份資料你有我也有，所以我們是非常幸運的，大多數的基礎資料我們都可以得到多份，這就為資料差異的發現帶來可能，通過對多源資料進行交叉檢驗，獲取差異資料，及時提醒並糾錯。

在整個服務鏈路中，越早發現問題，它所造成的影響就越低。那麼，如何更早地發現問題？分為以下三步：

第一步是 ID 拉齊，金融市場的股票大家都瞭解，交易標準、編碼規範、一碼貫穿所有資料，但是更多的債和基並不如股票標準，資料商往往會針對金融實體設計內碼，在資料商內部區域性唯一，所以如果想做交叉檢驗，首先就要解決 ID 拉齊的問題，這是個體力活。
第二步是指標化，資料校驗的需求往往是具體的，比如校驗每日的股票收盤價這種。但是資料商針對校驗點的資料結構往往差異較大，因此通過指標化，利用 Flink SQL 編寫針對多源庫的指標生成邏輯，將異構的資料結構拉齊。
第三步，實時校驗視窗。開始想法比較簡單，執行指令碼再定期取數一比就可以了。但是隨著指標校驗需求的增多，資料量的增長，跑批的指令碼處理能力略顯乏力。所以利用 Flink 的視窗特性，我們開發了用於校驗的實時校驗視窗，聚合所需要校驗的指標，在時間和數量維度上觸發校驗視窗計算，結果輸出到 Kafka，可以支援訊息的實時推送。

Flink 中支援兩種視窗，一種是基於時間的視窗，另一種是基於數量的視窗。如果在時間和數量兩個維度上均要加以控制，使用全域性視窗加觸發器就可以實現多樣的使用者自定義視窗分配。圖中放了幾行虛擬碼，在全域性視窗上，觸發器分別在元素來的時候和定時器到的時候加以判斷。

在校驗視窗裡，利用 maxcount 判斷多元指標資料是否都已到達，到達則觸發視窗函式，並對比指標值；如果某資料傳輸出現問題，對應指標值未到達，則需要在時間維度上加以控制，定義視窗的最大持續時間，到時就不再等待，直接觸發視窗函式，並將對應的資料來源指標定義為延遲到達，最終的結果輸出如右上表格。技術和業務人員均可以依據這份校驗結果及時應對，最終實現繞路提升資料服務的準確性。差異的及時發現和處理，使得對下游的影響降到最低。

Flink 在金融行業的應用，相信還有更多的場景值得探索。搭上開源社群這班快車，讓我們券商的金融資訊服務可以得到質的提升。

四、未來展望

最後分享一些實時流處理方面的未來展望，包含正在溝通的一些場景和流批一體方向的探索。

需求溝通中的場景分為以下幾個方面：

賬戶資產，包括實時資產持倉指標統計，客戶交易盈虧、交易記錄的分析；
營銷知識，包括 mot 流失客戶提醒與召回、開戶未成功客戶提醒與跟蹤、兩融業務潛在新客戶的挖掘、電商 APP 活動的內容與內容運營；
風控，包含以客戶維度的持倉集中度指標，以公司維度的融資額度佔公司淨資本等指標的分析統計。

另一方面我們專案組正在調研 OLAP 多維分析元件，由於目前實時開發仍然採用 Lambda 架構，結果表儲存元件涉及到關係型資料庫比如 MySQL、SQL server、oracle 以及 NoSQL 資料庫比如 HBase、ES、Redis。資料孤島是目前面臨的嚴重問題，希望通過 OLAP 元件實現實時資料的與離線資料的統一寫入，實現流批一體，打破目前資料孤島的局面，希望在流批一體儲存層達到統一儲存、統一對外服務、統一分析處理的目的。