摘要：現代的應用大都以前後端分離的模式開發，在建設銀行新一代系統中每筆交易對應三條訊息報文：前端的埋點資訊，傳送的 HTTP 請求，返回的 HTTP 響應。建設銀行在全球有大量的網點和業務員，每天產生大量的金融業務交易，包含海量的訊息報文，其中包含：運營配送，現金配送，信用卡審批等幾百種應用場景。而金融業務以複雜，穩定，要求高為特性，在銀行業尤其如此。
本篇內容整理自建信金融科技開發工程師周耀在 Flink Forward Asia 2021 行業實踐專場的演講。將根據建信金科集約化運營服務團隊，使用流計算框架 Flink 的經驗。圍繞如何引入有狀態流計算穩定，及時，高效的將埋點，請求，響應三條訊息進行業務加工，合併，向後傳遞給應用消費，最終產生業務價值。向大家展示流計算架構在銀行運營大資料中的演化過程，應對方案及走過的彎路。希望能對金融企業使用流計算提供參考和借鑑。同時希望將建信金科在建設銀行打磨出來的產品和場景進行產品化，推廣到更多的同業和行業中去。
本文將圍繞公司介紹、業務背景與挑戰、方案演進及業務效果、未來展望四個方面展開。
一、公司介紹
建信金科是中國建設銀行的金融科技子公司，由以前的建設銀行軟體開發中心整體轉制而來、公司持續致力於成為 “新金融” 體系的科技推動者和生態連線者，助力中國建設銀行集團數字化轉型，賦能 “數字中國” 建設，讓金融科技盡其所能，讓社會更美好。現在同時也在做 To B 的數字化轉型諮詢業務和數字化建設業務。
建信金科集約化運營服務團隊主要做的智慧運營產品有 4 大塊，分別是流程運營、交付管理、運營風險管控和渠道管理。本文主要分享的是 Flink 實時計算在流程運營這部分的實踐應用。
二、業務背景與挑戰
流程運營是以客戶為中心，通過流程，資料，技術驅動，實現運營旅程及資源的數字化管控，構建 “縱橫貫通，橫向融合” 的全集團智慧運營體系。
2.1 流程運營介紹
以信用卡流程為例，每個使用者都可以通過銀行的手機 APP、微信或者其他渠道申請建行的信用卡。使用者提交申請之後，申請會流轉到信用卡審批部門，審批部門會根據使用者的一些綜合情況判定額度，再將資訊流轉到髮卡制卡部門，最後到配送部門，通過郵寄的方式送到使用者的手中，使用者啟用後就可以開始使用了。其中每一個關鍵的業務節點，例如：申請，稽核，髮卡，制卡，啟用可以稱之為一個業務動作。多個業務動作串聯，就能形成一個業務視角的業務流程。
對於這樣一個信用卡申請流程，不同的角色從不同的角度，希望從這個流程當中獲取到的資訊都不一樣。
- 作為申請的客戶，想知道申請的卡是否已經稽核通過，什麼的時候能夠寄出？
- 作為線下推薦辦卡的工作人員，想知道的是今天採集的客戶資訊，有沒有材料不齊全導致流程被退回？
- 作為銀行領導，可能想實時獲取到這一天所在支行辦了多少筆信用卡申請，辦理稽核的平均時間是不是相比較以往來說變慢了？
對於信用卡這類關鍵且高頻的應用，行內有一套專門的流程系統來滿足使用者需求，但是一些相對來說低頻且資料分散，且各個系統之間的資料互相隔離的場景。例如：上門收款、ATM 現金加鈔、現金供應鏈流程、對公開戶流程等，類似的流程應用有幾百種。如果對每一個這樣的流程應用都單獨進行開發和建設，不僅成本過高，而且對每一個元件都需要進行侵入性的改造，會引入更多的不確定性。
所以我們希望建設一個系統能夠接入所有日誌資訊，把各個系統的資料打通，把分散的各個業務系統中的資訊站在業務的視角將業務流程還原出來，從而讓業務人員站在業務的全域性視角來看這些資料，就能讓資料產生更大的價值，也非常符合銀行這幾年數字化轉型的趨勢。我們智慧運營就能夠很好地滿足這個需求。
2.2 流程運營目標
為了滿足各類業務使用者，各類角色對流程分析的需求，流程運營主要負責4件事：
- 第一是把業務流程的現狀完整地呈現出來；
- 第二是對流程的問題進行診斷；
- 第三是針對流程進行監控分析；
- 第四是對業務流程進行優化。
所以，我們需要做的第一件事就是把流程還原出來。那麼由誰去定義流程？經過思考後，我們得出的結論是下放給業務使用者。在以前業務流程都是由開發者寫在程式碼裡，對於業務人員來說，信用卡審批只知道是否通過這樣的結果資料，但實際上稽核步驟可能會有一些依賴，比如步驟 A、步驟 B、步驟 C 都通過了才是真正意義上的審批流程通過。
如果把定義過程下放給業務使用者，業務使用者由於不知道系統的內部流程，起初可能也不知道 A、B、C 這三個步驟審批完成了才是真正完成，所以我們需要提供一個工具讓業務使用者去嘗試。業務人員根據直覺先定一個流程引數，流程運營系統根據真實的資料按照業務人員定的流程去執行，還原成一個真實的流程例項，來驗證看這個流程是否符合業務場景。如果符合，就用這個業務流程的引數上線，如果不符合，業務使用者可以及時針對這個場景再進行修改迭代，一點點去完善，在迭代中不斷完善業務流程。
接著，有了這些執行出來的流程之後就可以在這個流程上面建立一些流程應用，比如指標、監控預警等。還以信用卡申請業務為例，對於信用卡申請的通過率是多少，核發之後的啟用率是多少等指標，
之後，我們會做一系列的流程的監控和運維。
最後，有了這些指標資料，就可以利用這些資料去指導賦能業務，提高運轉的效率，提升服務滿意度。
希望能將建信金科在建設銀行打磨出來的產品和場景進行產品化，推廣到更多的同業和行業中去。
2.3 技術挑戰
為了達到這樣的目標，我們也會面臨一些業務的挑戰：
- 業務資料來源於多個系統。我們建行也在做資料湖，但是資料湖裡面的資料僅僅是一些資料的簡單堆砌，如果無法形成一個全域性的檢視，就很容易導致資料孤島。
- 業務靈活性高。希望能夠提供一種機制，讓業務去自主配置流程，在迭代中不停地完善流程。
- 資料的實時性要求高。要求是能夠在業務發生後實時地加工流程。
- 資料來源於多個流。橫向看資料來源於多個系統，比如稽核、髮卡、啟用，這些系統大多都是前後端分離部署，既有前端的埋點，也有後端的請求響應，我們需要將各個系統資料收集起來，把對應的埋點和請求響應實時地關聯在一起，才能得到一個業務操作。
- 業務資料龐大。日均幾百億的資料，7×24 小時不停地到達。
為了解決以上痛點，我們採取了一系列措施：
- 採用訊息佇列，通過 Kafka 把生產的業務日誌和資料處理系統隔離出來，儘可能減少對應用的侵入式改造。
- 我們定義引數，通過站點和流程進行配置和管理。
- 我們使用了 Flink，能做到實時處理並且可以橫向擴充套件。
- 我們使用了流批一體節省資源。
因為我們所有的流計算應用都是執行在建行的大資料雲平臺上的，所以我們先介紹一下大資料雲平臺。
上圖是大資料雲平臺，資料加工的架構如下：從網路卡、埋點、日誌、資料庫 CDC 等將資料接進來，再到Flink做實時資料處理，最後把處理完的結果加工儲存到儲存系統裡，比如 HBase、GP 和 Oracle，最後由上層的應用將結果進行視覺化。
三、方案演進及業務效果
在建行，資料通常來源於三個渠道，分別是客戶渠道、員工渠道和外聯渠道。
客戶渠道的交易主要是手機銀行 APP 上發起的，員工渠道的交易主要是指建行分佈在各個網點的銀行櫃員操作發起的，比如去銀行辦理一筆存款業務，櫃員就會在員工渠道發起一筆存款交易，外聯渠道是指外部系統呼叫建行的介面形成的交易。
3.1 流程分析場景
渠道發起的每一個業務動作對應資料處理系統的三條日誌報文，分別是請求、響應和埋點，它們都有全域性唯一的跟蹤號。這裡存在一個難點是對源源不斷的三條資料流提取唯一標識，並根據這個唯一標識把三條資料 join 連線起來，形成完整的一個業務動作。此外，這裡還涉及到訊息先來和後來、中間狀態儲存以及訊息延遲到達的問題。
為了解決這些問題，方案也進行了三次演化。
- 第一個方案採用滑動視窗，但是很快就出現了效率問題；
- 所以第二個方案是採用 Flink 自帶的 interval join，但是遇到了程式 oom 執行不穩定的問題。
- 接著我們使用了第三個方案，自己實現了一個 keyedProcessFunction，手動管理中心狀態，解決了效率和穩定性問題。
正式分享細節之前，先介紹一下背景。每個業務動作對應的 3 條資料 80% 的情況下會在 5 秒鐘內到達，但是由於網路的抖動或者採集的延遲，我們需要容忍一個小時左右的延遲，而且一個全域性跟蹤號只會對應一個請求、一個響應和一個埋點，也就是一個業務動作對應的三條訊息只會成功 Join 上一次。
3.1.1 滑動視窗（1.0 版本）
為了滿足上述要求，我們很快推出了 1.0 版本，使用的是滑動視窗，當請求響應到達之後，先把它分開再提取唯一業務標識，然後再做一次 keyBy。因為這裡存在一個前後到達的問題，有可能是請求先來，也有可能是響應先來。所以我們採用了一個 10 秒鐘的滑動視窗，5 秒鐘滑一次，如果請求來了，響應能夠在 5 秒之內到達就能在視窗內連線上，就可以直接進行業務操作輸出；如果 5 秒內沒有到達，就要把狀態提取出來存到 Redis 中做等待。等下一次響應來了，它就會先去 Redis 上根據業務標識去檢視有沒有請求，如果有，就拿出來再進行業務操作和業務處理。
也就是把請求和響應先做一次連線，然後把連線上的請求響應和埋點再做一次連線，相當於做了兩次實時 join，並把 Redis 作為狀態儲存，將沒有連線上的訊息存放在裡面。
但是這會導致一些缺點：
- 第一，是吞吐量低。隨著資料接入的訊息越來越多，Flink 設定的並行度就要越來越大，使用的 Redis 連線數請求也會越來越多，受限於 Redis 的吞吐量和連線數限制，達到一個閾值之後就會限制整體的吞吐量；
- 第二，Redis 運維壓力大。資料量大了之後，沒有連線上的資料就會越來越多，Redis 很快就會滿了。為了保證穩定性就需要做一些手動的清除；
- 第三，需要手動在 Flink 裡面寫一些額外的程式碼與 Redis 進行互動；
- 第四，Redis 的狀態積壓變大，會導致裡面的引數或者資料過期，或者被擠出。
所以我們演化出了第二個版本，interval join 版本。
3.1.2 Inerval join版本（2.0 版本）
interval join 是 Flink 框架自帶的特性，使用 RocksDB 做狀態儲存，相當於用它替換掉 Redis。
使用這個方案的初衷一方面是希望能夠降低運維壓力，另一方面，隨著資料量增大它可以很方便地做橫向擴充套件。
第一個優化是資料到達之後，根據配置做一些過濾，把不需要的資料提前過濾掉，使得需要處理的資料量下降很多。第二是使用 interval join，對請求響應做一次 join，然後把 join 上的資料跟埋點再做一次 join。這裡面的邏輯跟前面的 1.0 方案保持一致。同時，為了達到容忍一個小時左右資料延遲的要求，我們設定一個 30 分鐘的上下限區間。
但是執行了幾天之後，我們發現它經常出現 OOM，由於使用的是 Flink on K8s，分析起來比較複雜。後來通過閱讀原始碼，我們發現 Flink 的 interval join 會將它上下限時間區間內的資料全部保留在狀態裡面，直到資料過期才會刪除，這也導致了一些新的問題。
首先 checkpoint 體積會很大，我們通過閱讀 Flink 的 Interval join 實現的原始碼發現，Interval Join 會將 30 分鐘時間上下線內的狀態都全部儲存在 Rocks DB 狀態後端中因為它會把 30 分鐘內的資料全部保留下來，以便於處理一對多，和多對多的 join 情況。
第二，執行不穩定，它使用了 RocksDB 作為狀態儲存，RocksDB 本身是用 c++ 寫的，Flink 使用 java 去呼叫它，很容易造成 oom。並且由於一些約束條件，只能通過配置引數的方式給 RocksDB 配置足夠的空間，防止它 OOM。對於我們行業的應用來說，一旦發生了 OOM 就會導致正在實時的業務中斷，這是絕對不允許的。
其次，我們在分析了行內 Join 的場景發現：在行內的情況下請求、響應、埋點，一定是一個一對一的關係，不會像資料庫一樣存在一對多的關係。鑑於這個背景，我們考慮，這一個小時區間內，其實很多資料是不必要儲存在狀態後端裡，所以我們想自己做狀態管理，將不必要的資料從狀態後端刪除。於是演化出了第三個版本。
3.1.3 手動管理狀態（3.0 版本）
因為只會 join 上一次，所以在 3.0 的時候，自己實現了一個 keyedProcessFunction 程式碼去管理這個狀態。
資料到達以後先做一次過濾，不管它是請求/響應/埋點，統一把它 union 起來，再根據提取出來的唯一標識進行 key by 分組，分組之後，具有相同唯一標識的訊息就會落在同一個 slot 當中。每條一條訊息來了以後會去檢查響應和埋點是否已經到達，是不是符合 join 的條件，如果滿足了條件就把它輸出同時清楚狀態後端中的資料，如果不滿足輸出條件，就把訊息存在 RocksDB 的狀態後端中繼續等待。這樣就可以做到手動管理狀態，減少了 90% 的狀態儲存，帶來了很大的收益。
首先使用 RocksDB 作為狀態後端，相比於 1.0 版本，吞吐量提升了很多。
第二，它降低了開發的運維難度。第三提升了實時的處理能力，後面資料量再增多的時候可以通過增加更多的節點來進行橫向擴充套件。此外，Flink 自帶了很多 join 的方案，提供了良好的介面讓我們更方便地去實現裡面的邏輯。
3.2 流程指標場景
有了流程的基礎資料，我們在基礎資料上針對這個流程基礎資料做了一些指標計算，實時的流程指標計算也進行了 2 次方案迭代。
3.2.1 實時指標 1.0 版本
1.0 版本的實時指標使用了流計算和離線計算來同時處理，受限於對技術棧和工具的熟練度，我們做的是分鐘級別的準實時指標。首先，資料來源是 Kafka，經過 Flink 進行預聚合處理之後 sink 到 Kafka 裡，再由 Spark 週期性地調入，把資料從 Kafka 寫到 GP 庫裡。我們是以 GP 庫為核心，用 SQL 進行指標計算，將指標計算結果再寫回到 Oracle 裡面，最後再由應用去消費，這是我們使用的 1.0 版本。
3.2.2 實時指標 2.0 版本
隨著我們對 Flink 和工具的愈發熟悉，團隊也在思考如何做到秒級的真實時。2.0 版本可以直接從 Kafka 裡接資料進來，再用 Flink 進行實時指標計算，直接把資料寫到 Oracle 裡面，做到了端到端的秒級的延遲，是一個真實時的指標。
在銀行，渠道、產品和機構是三個非常重要的維度，我們對線上生產的業務流程，分別做了渠道、產品和機構的分佈統計，比如需要對每個網點統計線上線下員工渠道辦理的業務流程佔比是多少？比如流程從開始到辦結，會不會是因為中間有材料沒有準備齊全而發生回退，還有每一個環節的平均處理時長等。
所以綜合來說，Flink 的確給專案帶來了比較大的收益。
- 首先 Flink SQL 使得加工的流程變得更容易。Flink1.11 之後，SQL 的功能慢慢完善，愈發地方便開發人員使用；
- 第二，它提供了端到端的、真正秒級的實時；
- 第三，使用 Flink 能夠減少資料元件的互動，縮短整個資料鏈路，提高了資料的穩定性。
3.3 業務效果
上圖中間是建設銀行手機 APP 端的一個現金預約、上門收款的業務流程。
首先是現金入賬，然後現金清點，再是現金交接，最後業務受理完成。我們分析出來的流程和指標，除了可以在手機端的 APP 檢視，也可以在員工渠道里面檢視，比如左邊每一個綠點代表一個站點，每個站點完成之後就能串起來形成一個完整的流程。
所以對於業務人員來說，第一個得到的價值就是流程的重塑。從指標的接入到指標的視覺化到資料探勘，最終根據流程得出來指標，去優化流程，形成了一個完整的業務閉環。
有了這些基礎的資料之後，我們就可以針對業務流程進行風險的干預。比如某個客戶要辦理一個大金額的現金取款業務，系統會實時的通知網點經理對客戶進行挽留和干預。
其次，流程分析帶來了資源的優化配置。基於流程的應用可以監測業務資源的使用，比如某個流程突然申請變多，我們會考慮是不是崗位人手不夠導致的辦理時長過長，系統會及時進行預警監控，分配更多的工作人員。這樣就可以通過資源的配置，優化資源使用效能，提升服務滿意度。類似的流程場景，在行內也被推廣到很多業務線應用，廣受好評。
通過 Flink 對實時資料的加工，為建設銀行做數字化轉型提供了資料方面強有力的支撐。
四、未來展望
目前這套流程運營落地都只在我們建設銀行內部，未來我們希望將這套智慧運營流程的方法論進行產品化、平臺化，並推廣到更多的行業中去，讓更多行業得到金融級的流程運營的實踐。
更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間獲取最新技術文章和社群動態，請關注公眾號～
