錢大媽基于 Flink 的實時風控實踐
?摘要：本文作者彭明德，介紹了錢大媽與阿里云 Flink 實時計算團隊共建實時風控規則引擎，精確識別羊毛黨以防營銷預算流失。主要內容包括：
- 項目背景
- 業務架構
- 未規則模型
- 難點攻堅
- 回顧展望
一、項目背景
目前錢大媽基于云原生大數據組件（DataWorks、MaxCompute、Flink、Hologres）構建了離線和實時數據一體化的全渠道數據中臺，為各業務線提供 BI 報表及數據接口支持。除了數倉的分析場景以外，錢大媽面臨著業務系統中的風控需求，例如每季度的營銷費用中被不少的羊毛黨薅走正常用戶的利益，其中羊毛黨一方面可能導致用戶的口碑下降，另一方面也會影響原有的活動運營預算迅速攀升從而導致資損。錢大媽與阿里云 Flink 實時計算團隊共建實時風控規則引擎，精確識別羊毛黨以防營銷預算流失。
圖一：錢大媽實時風控流程示意圖
二、業務架構
錢大媽風控業務架構如圖二所示總共分為四個部分：事件接入、風險感知、風險應對、風險回溯。通過 Flink 在線 ETL 加工處理的實時用戶畫像標簽和銷售事實指標，除了作為線上 BI 指標和實時大屏數據展示，也為實時規則引擎的事件接入提供重要的數據支持。
- 事件接入。其中包括黑白灰名單庫、畫像特征數據、行為埋點數據和中臺交易數據。
- 風險感知。策略調研后發布到規則引擎，并對告警結果進行離線回歸和多渠道觸達。
- 風險應對。對涉及到財務結算的規則提供再審核、豁免機制或人工補償。
- 風險回溯。策略命中后進行統計和風險分類分級，預警離線回溯并對風控事件閉件。
圖二：錢大媽實時風控業務架構圖
三、規則模型
風控業務專員通過產品界面簡單配置即可實時動態發布風控規則，同時對在線 Flink 作業的規則進行新增、更新以及刪除，其中風控規則模型主要分為統計型規則和序列型規則，相同模型支持子規則的嵌套，不同模型之間可以通過與、或關系進行組合。
圖三：錢大媽Flink作業DAG抽象圖
以下為規則組合中需要動態配置能力的配置項：
1）分組字段。不同字段分組、多字段分組的情況在風控規則的應用中非常常見。有如下規則樣例：
- 以用戶 ID 分組："用戶的下單次數"；
- 以用戶 ID、區域 ID 作為分組："用戶同一段時間內不同區域的訂單數"。
2）聚合函數。聚合函數包括業務常用的聚合邏輯，規則引擎依賴 Flink 內置豐富的累加器，并在 Accumulator 接口的基礎上進行了根據需求場景的自定義實現。樣例規則如下：
- A 門店近 30 分鐘獨立消費用戶數小于 100；
- B 門店新客消費金額大于 300。
3）窗口周期。窗口周期也即每個窗口的大小，如業務方可能希望在持續 30 分鐘的秒殺活動周期內運行規則，或者希望重點關注異常時段。
- 每 30 分鐘時間窗口內，單個用戶發起超過 20 筆未支付訂單；
- 凌晨 1 點至 3 點，單個用戶支付訂單數超 50 筆。
4）窗口類型。為了面對不同的業務需求，我們將業務規則中常見的窗口類型集成到規則引擎內部。其中包括滑動窗口、累計窗口、甚至是無窗口（即時觸發）。
5）聚合前的過濾條件：
- 只對"下單事件"進行統計；
- 過濾門店"虛擬用戶"。
6）聚合后的過濾條件：
- 用戶 A 在 5 分鐘內下單次數 "超過 150 次"；
- 用戶 B 在 5 分鐘內購買金額 "超過 300 元"。
7）計算表達式。風控規則的字段口徑通常是需要組合計算的，我們在表達式計算和編譯中集成了更輕便和更高性能的 Aviator 表達式引擎。規則樣例如下：
- 應收金額大于 150 元（應收金額 = 商品金額合計 +運費 + 優惠合計）；
- 通過 POS 端支付的應收金額大于 150 元。
8）行為序列。行為序列其實也是事件與事件之間的組合，他打破了以往風控規則只能基于單事件維度描述事實的壁壘，在事件與事件之間的事實信息也將被規則引擎捕捉。規則樣例如下：
- 用戶 A 在 5 分鐘內依次做了點擊、收藏、加購；
- 用戶 B 在 30 分鐘前領了優惠券，但是沒有下單。
圖四：實時風控規則配置業務邏輯簡圖
四、難點攻堅
針對規則模型的流式序列型數據，我們選擇 Flink CEP 處理事件序列匹配，由于我們整個風控作業使用 Flink 實現，并且 Flink CEP 作為 Flink 官方原生支持的 Library，集成度高無需引用額外組件即可滿足事件序列匹配的需求。作業預期是允許用戶在產品界面上熱發布規則的，但是基于開源的 Flink CEP，實現規則動態更新能力存在以下困難點：
- Flink 社區的 CEP API 無法支持動態修改 Pattern 即無法滿足上層規則中臺、風控中臺的可集成性；
- Flink 社區的 CEP API 無法支持Pattern 定義事件之間的超時。
阿里云 Flink 實時計算團隊和錢大媽工程師共同攻堅，在 Flink 社區發起如下兩個 FLIP 提案并且在阿里云實時計算產品上面輸出相應功能解決此問題：
- FLIP-200 [1]：CEP 支持多規則和動態 Pattern 變更；
- FLIP-228 [2]：CEP 支持 Pattern 定義事件之間的超時。
阿里云實時計算產品輸出的支持多規則和動態規則變更、支持 Pattern 定義事件之間的超時以及支持基于 IterativeCondition 的累加器功能拓寬 Flink 在實時風控的能力，并且上述功能已經在錢大媽生產環境落地實踐。其中 Flink CEP 動態更新 Pattern 機制中內部各組件的交互總覽如下：
圖五：社區Flink CEP動態Pattern機制
風控規則由產品界面作為入口，規則寫入到 Hologres 中，同時 JDBCPatternProcessorDiscover 周期性輪詢發現規則的變更。其中規則表的數據結構如下：
- Id：規則ID；
- Version：規則對應的版本號；
- Keyby：規則分組字段（如需分組）；
- Pattern：CEP Pattern 序列化后的 Json 字符串；
- Function：CEP 匹配后處理的 PatternProcessFunction；
- Relation：統計型和規則型之間的與、或關系（前提：統計型和規則型的 ID 相同）。
圖六：社區Flink動態CEP規則表
五、回顧展望
基于 Flink 的實時風控解決方案已接應用于錢大媽集團內部生產環境，在此解決方案里未引入新的技術組件和編程語言，最大化復用 Flink 資源實現實時風控場景需求，極大降低新組件引入存在的潛在運維風險。另一方面也極大降低研發團隊的學習成本，高效釋放實時計算的人力資源，并且對于研發和業務應用上面帶來如下好處：
- 解耦 Flink 作業邏輯開發和業務規則定義；
- 業務規則存儲在 Database 中，便于查看規則當前狀態和歷史版本；
- 規則變更只需修改 Database 存儲的規則，Flink 自動加載更新作業中的規則列表；
- 結合 Flink 生態能夠非常容易集成事件異構數據源的讀取與寫入；
- 結合 Flink 分布式能力，大規模擴展至數千并發度匹配運行規則。
后續錢大媽將和阿里云實時計算產品團隊，繼續共建完善基于 Flink 的實時風控風控解決方案，其中在 Flink CEP 的未來規劃將圍繞以下三個主要方向展開：
- Flink CEP 能力的進一步增強；
- Flink CEP SQL 的動態能力；
- Flink + DSL 的 Native 支持。
