Airwallex 基於 Flink 打造實時風控系統

摘要：本文整理自 Airwallex Risk ML Platform Team 董大凡，在 Flink Forward Asia 2022 實時風控專場的分享。本篇內容主要分為五個部分：
背景介紹
應對方案
技術挑戰與亮點
可用性保證
線上表現

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

一、背景介紹

Airwallex 是一個以“建立一個讓企業跨境運營的環境，以此助推全球的數字經濟發展。”為目標的金融科技公司。服務有 GTPN、PA、Scale。目前 Airwallex 總使用者數超過 6 萬，遍佈 20+個國家/地區，且使用者數保持穩步增長，過去一年新增使用者超過 100%；日平均交易數超過 12 萬筆；峰值交易流量超過 100 筆/秒；單個交易請求的總時延不能超過 800 毫秒（P99）。

以上就是 Airwallex 大體的服務。那麼對於我們來說，風險在哪裡呢？

平臺必須降低的一些風險：

對於 GTPN 這種轉賬服務，會有一些人想利用我們這種國際轉賬的能力去做洗錢。
對於 PA 有一些收款服務，就會涉及到欺詐和糾紛事件。比如我們的客戶是一個電商客戶，如果他賣假貨，然後利用我們對收貨時延的寬容，把錢從客戶那裡透過我們的渠道轉移到自己的賬戶上。當客戶發現收到的貨有問題提出申訴的時候，責任就會由我們來承擔。
對於 Scale 會涉及到很多個子使用者，他們之間會有很多內部的轉賬操作，也會有一些欺詐行為。

針對以上風險，我們公司成立了 RISK 團隊。公司對這個團隊的要求是，希望能夠高效識別並攔截惡意轉賬；並且決策過程可查詢，決策結果可解釋；同時確保使用者體驗不受影響。

作為 ML Platform 團隊，我們提供了一個穩定高效的 Feature 計算平臺，並對機器學習工程師提供了友好的程式設計介面，還提供了一站式模型訓練和部署解決方案。

我們的團隊成員：Xin Hao、Yusup Ashrap、Michael Liu、Tim Zhu。

二、應對方案

2.1 Airwallex 業務與產品介紹

對於應對風險，業內已經有了很多探討，可以總結為以下幾點。

傳統規則引擎，可擴充套件性有限，無法處理如此複雜多變的場景。如果想處理這種場景，會讓規則或者執行邏輯變得非常難以維護。
引入機器學習技術對風險進行探測已經成為行業發展的主流方向。
在風控領域，模型需要大量頻繁回看不同時間週期內特定賬戶行為特徵，使用傳統離線資料處理方式，無法及時產生所需資料（Feature）。
所以綜上所述，我們決定擁抱 Flink 原生流計算能力，構建流式風控平臺。

從上圖左側部分可以看到，Scale/GTPN/PA 是我們正在執行轉賬的服務。每一筆服務都會給我們的 Risk Decision Service 發一個通知，並告訴它是 Approve 還是 Reject。所以現在我們把 Risk Decision Service 當成一個黑盒看，就是這樣一個架構。

因為 Risk Decision Service 需要一些機器學習的技術或者其他技術去做計算，所以它需要相對豐富的資料。我們現在有兩個資料來源，一個是流的 Kafka 資料來源，它有個 Account Transaction Log。即每發生一筆交易，都會有一條資料實時彙總到服務裡去。另一個是批的資料來源，它是一個相對比較穩定不會變化的資料。因為我們是藉助 Google 的雲端儲存，所以它會放在 Google Cloud 上。

然後將這兩個資料 Feed 給 Risk Decision Service 供它進行計算。

接下來需要把資料計算出來。Flink Feature Calculation Engine 會同時接入流資料和批資料進行 Join，提供一個更豐富的流資料，供我們計算 Feature。同時，我們還有一個基於 Redis 的 Feature Cache System，它可以在 Inference 的時候，實時從裡面讀取資料，然後把生成的資料實時的寫入到 Redis 裡。

然後就引入了 Risk Model Inference Engine，它會呼叫一些機器學習模型或規則模型，讀取一些 Feature。然後對每一筆進入的 Transaction 進行風險評估，並返回一個結果，來告訴我們的客戶允許還是拒絕這筆 Transaction。

上面提到需要對結果做到可查，可解釋，那麼就需要把所有的結果和結果在計算中用到的 Feature 都儲存下來。所以如上圖右側所示，我們引入了 Data Persist 並在外邊接上了 Google Cloud Storage，實時把 Model Inference Result 和生成的 Feature 彙總，然後在 Google Cloud 上落盤儲存。

上圖是我們的整體架構，下層藉助了 Google Cloud 儲存和 Kafka 的能力，給上層提供一些資料。上層是 Feature Generating Job，包含 Feature Serving、Feature Persist、Flink Feature Generation Job。再往上層是 Model Inference，它跟外層進行通訊，呼叫 Model 做一些判斷，同時它也會呼叫右側的 Persistlayer 儲存這些資料。

最上層主要負責 Management 和 Control，它有 Flink Operator 用來排程下層 Flink Job 執行；Model Management 管理每一個上線 Model 當前版本和版本所需要的 Feature 列表；DSL Management Management 用來實現 Flink Feature Generation Job 的統一介面。

三、技術挑戰與亮點

3.1 挑戰與應對

我們面對的挑戰主要有左側的 3 點。

第一個是 Feature 計算需要頻繁重算曆史資料。每一個 Incoming 的 Event 都可能會觸發滑動視窗的滑動，然後就會觸發一個 Feature 重新計算，這個計算量還是比較大的。

另外，仔細想想其實還有一個場景，比如現在必須的 Feature 裡有過去一個月的總交易量，如果想重新上線一版 Feature 計算邏輯，就需要把這一個月的資料都回溯一遍才能計算出來。所以頻繁重算並不只是包含 Feature 正常執行時，一個跟隨滑動視窗的更新，也包含 Feature 計算邏輯更新時，對歷史資料的重算。

為了解決上述問題，我們直接把流本身做成一個 Process 的介質，然後把流的視窗擴大，把它當成一個批的計算，就可以做歷史資料的回溯了。

第二個是 Flink 程式設計邏輯過於複雜。因為 Feature 生成邏輯是由寫 Decision Model 的科學家決定的，他們比較擅長做一些 ML 相關的模型開發，如果讓他們學習 Flink Native 開發會比較複雜。另外我們也不用 Flink SQL，因為我們認為 Flink SQL 語言的表現力有限，一些相對複雜的跨行操作，用 SQL 開發起來會比較困難，不是非常直觀。

為了解決這個問題，我們抽象了一個 DSL for ML Engineer。讓工程師不需要接觸 Flink 那些複雜的概念，就可以寫出自己需要的 Job。

第三個是模型對 Feature 依賴關係複雜多變。在風控領域，會遇到不同的風險。每個人都會有自己 Feature 要求，而這些不同的 Feature 會有相對比較複雜的生成邏輯，這些生成邏輯都還會對應一個單獨的 Flink Job。我們該如何管理這些 Flink Job 呢？

我們有一個一體化的模型和 Feature 管理。因為我們線上做 Inference 的時候，是基於某個模型的特定版本，而每個模型會有自己的 Feature 依賴關係，每個 Feature 會有自己對應的 Feature Generating Job。如果反過來，我們只要抓住模型的核心點，反推它的 Dependency，就可以保證線上上跑的只有我們必須的 Feature Generating Job。所以只要打通模型和 Feature 的 Metadata，就可以比較高效的去做 Job 的 Schedule。

3.2 挑戰的應對細節

接下來為大家介紹剛才三個挑戰的應對細節。

第一個是 Kappa Architecture。上圖左側是一個時間軸，大概描述了我們程式的執行邏輯，時間軸上面是一個大的滑動視窗。

在新的 Feature Generating Job 上線時，需要回看兩週的資料，就會使用長時間視窗，加上 event time, 用於 Job 初始化。如果當前處理的時間和 Current Time 已經小於我們的判斷標準，就會自動切換為短時間視窗，加上 processing time 降低 latency。

基於以上兩種機制，可以讓我們的程式自動在這兩個模型之間切換。我們會透過一些標誌檔案或者共享儲存的方式把當前程式的狀態暴露出來，然後由 Flink Operator 排程完成在這兩種模式之間的自由切換。

第二個是 DSL for ML Engineer。上圖左側是 DSL 提供的所有 API，有 FlatMap、Map、Keyby、Sum、Value。

然後看地下的兩行，兩個模式都可以用上面完全同樣的介面去做開發，所以 DSL 遮蔽 Feature 生成過程中流批資料的差異，也簡化介面，隱藏下層細節邏輯。因為 Feature Generation 根本不需要相對比較複雜的概念，比如像 Watermark、Point-in-time Joins 都不需要暴露給科學家，他們的行為可以完全由 DSL 來表達。這樣科學家就能透過一些簡單的培訓，獨立開發 Feature Generation Job 了。

第三個是一體化的模型和 Feature 管理。如果想高效排程 Feature Generating Job，就必須要打通 Model 和 Filter 的 Metadata。那麼 Model Management Service 作為整個系統的管理資料中心維護如下資訊，它維護著如下幾點。

Model 對 Feature 的依賴關係。
Model 的生命週期。
Feature 的生成邏輯。

在系統執行時，透過 Model Management Service 遍歷當前使用的全部 Model，並彙總全部依賴 Feature，然後排程每一個 Feature 的生成 Job。

四、可用性保證

上圖左側是我們簡化的系統架構。像 Inference Engine 或者 Model Management 這些服務，雖然提供的內容比較新穎，但本質上就是線上服務。對線上服務做高考用，無非就是冗餘、備份、分層切換流量的操作，那麼我們如何做到 Feature Generation Job 的高考用性呢？

我們想做的就是冗餘。為了支援冗餘，我們必須實現冪等的 Feature 生成，從而實現 Feature Generation Job 的冗餘能力。在這樣一個需求下，我們引入了以下 Convention。

使用 Feature Name 作為 Feature 的唯一標識。
Feature Version 單增，並在寫入的時候自動 Merge。
Model Inference 根據註冊的 Feature 名字始終消費最新版本 Data。

這裡我們提供了一種額外要求，就是寫 Feature 的人必須保證 Feature 向後相容，如果不能向後相容，就換一個名字。在這種情況下，就可以實現冗餘的存在。

舉個例子，現線上上出現了一個 Feature Generation 的 bug，一些 Feature 無法正常生成。我們首先會修復 bug，然後 push 一個新的 DSL，然後把 Version 值加 1，重新部署新的 Feature Generation。

新的 Job 會處於 Catchup Mode，讀取歷史資料，並重新計算 Feature。它計算出來的每一個 Feature 都會實時寫入到，已經準備好的 Feature Catch 裡。

因為舊的系統並不是完全不可用，所以我們還會保證舊的版本的生成 Job 同時在這兒，提供最大的能力。直到新的 Feature Generation Mode 已經追上最新的資料，我們就可以把舊的版本下線，由新的版本去 serve。透過這種方式，我們可以確保完成我們的高可用性。

同時，Flink Operator 同步監控系統負載，動態調整系統資源。

舉了一個例子，在某一個叢集裡對應一些 Job 的數量，可以看到一些 Job 都可以在這被正確的 Schedule。我們做了這樣一個 UI，讓運維工程師可以更方便的去觀察系統的執行情況。

五、線上表現

線上表現：PA Fraud Detection Metric

上圖是我們的 PA Fraud Detection Metric，可以看到我們 P99 的 latency 大部分都在 800 毫秒以下，右側有一個 spike，是由一個 deployment 造成的。