錢大媽基於 Flink 的實時風控實踐

ApacheFlink發表於2022-06-21

摘要：本文作者彭明德，介紹了錢大媽與阿里雲 Flink 實時計算團隊共建實時風控規則引擎，精確識別羊毛黨以防營銷預算流失。主要內容包括：

  1. 專案背景
  2. 業務架構
  3. 未規則模型
  4. 難點攻堅
  5. 回顧展望

一、專案背景

目前錢大媽基於雲原生大資料元件（DataWorks、MaxCompute、Flink、Hologres）構建了離線和實時資料一體化的全渠道資料中臺，為各業務線提供 BI 報表及資料介面支援。除了數倉的分析場景以外，錢大媽面臨著業務系統中的風控需求，例如每季度的營銷費用中被不少的羊毛黨薅走正常使用者的利益，其中羊毛黨一方面可能導致使用者的口碑下降，另一方面也會影響原有的活動運營預算迅速攀升從而導致資損。錢大媽與阿里雲 Flink 實時計算團隊共建實時風控規則引擎，精確識別羊毛黨以防營銷預算流失。

img

圖一：錢大媽實時風控流程示意圖

二、業務架構

錢大媽風控業務架構如圖二所示總共分為四個部分：事件接入、風險感知、風險應對、風險回溯。通過 Flink 線上 ETL 加工處理的實時使用者畫像標籤和銷售事實指標，除了作為線上 BI 指標和實時大屏資料展示，也為實時規則引擎的事件接入提供重要的資料支援。

  1. 事件接入。其中包括黑白灰名單庫、畫像特徵資料、行為埋點資料和中臺交易資料。
  2. 風險感知。策略調研後釋出到規則引擎，並對告警結果進行離線迴歸和多渠道觸達。
  3. 風險應對。對涉及到財務結算的規則提供再稽核、豁免機制或人工補償。
  4. 風險回溯。策略命中後進行統計和風險分類分級，預警離線回溯並對風控事件閉件。

img

圖二：錢大媽實時風控業務架構圖

三、規則模型

風控業務專員通過產品介面簡單配置即可實時動態釋出風控規則，同時對線上 Flink 作業的規則進行新增、更新以及刪除，其中風控規則模型主要分為統計型規則和序列型規則，相同模型支援子規則的巢狀，不同模型之間可以通過與、或關係進行組合。

img

圖三：錢大媽Flink作業DAG抽象圖

以下為規則組合中需要動態配置能力的配置項：

  1. 分組欄位。不同欄位分組、多欄位分組的情況在風控規則的應用中非常常見。有如下規則樣例：

    1. 以使用者 ID 分組："使用者的下單次數"；
    2. 以使用者 ID、區域 ID 作為分組："使用者同一段時間內不同區域的訂單數"。

  1. 聚合函式。聚合函式包括業務常用的聚合邏輯，規則引擎依賴 Flink 內建豐富的累加器，並在 Accumulator 介面的基礎上進行了根據需求場景的自定義實現。樣例規則如下：

    1. A 門店近 30 分鐘獨立消費使用者數小於 100；
    2. B 門店新客消費金額大於 300。

  1. 視窗週期。視窗週期也即每個視窗的大小，如業務方可能希望在持續 30 分鐘的秒殺活動週期內執行規則，或者希望重點關注異常時段。

    1. 每 30 分鐘時間視窗內，單個使用者發起超過 20 筆未支付訂單；
    2. 凌晨 1 點至 3 點，單個使用者支付訂單數超 50 筆。
  1. 視窗型別。為了面對不同的業務需求，我們將業務規則中常見的視窗型別整合到規則引擎內部。其中包括滑動視窗、累計視窗、甚至是無視窗（即時觸發）。

  1. 聚合前的過濾條件：

    1. 只對"下單事件"進行統計；
    2. 過濾門店"虛擬使用者"。

  1. 聚合後的過濾條件：

    1. 使用者 A 在 5 分鐘內下單次數 "超過 150 次"；
    2. 使用者 B 在 5 分鐘內購買金額 "超過 300 元"。

  1. 計算表示式。風控規則的欄位口徑通常是需要組合計算的，我們在表示式計算和編譯中整合了更輕便和更高效能的 Aviator 表示式引擎。規則樣例如下：

    1. 應收金額大於 150 元（應收金額 = 商品金額合計 +運費 + 優惠合計）；
    2. 通過 POS 端支付的應收金額大於 150 元。

  1. 行為序列。行為序列其實也是事件與事件之間的組合，他打破了以往風控規則只能基於單事件維度描述事實的壁壘，在事件與事件之間的事實資訊也將被規則引擎捕捉。規則樣例如下：

    1. 使用者 A 在 5 分鐘內依次做了點選、收藏、加購；
    2. 使用者 B 在 30 分鐘前領了優惠券，但是沒有下單。

img

圖四：實時風控規則配置業務邏輯簡圖

四、難點攻堅

針對規則模型的流式序列型資料，我們選擇 Flink CEP 處理事件序列匹配，由於我們整個風控作業使用 Flink 實現，並且 Flink CEP 作為 Flink 官方原生支援的 Library，整合度高無需引用額外元件即可滿足事件序列匹配的需求。作業預期是允許使用者在產品介面上熱釋出規則的，但是基於開源的 Flink CEP，實現規則動態更新能力存在以下困難點：

  1. Flink 社群的 CEP API 無法支援動態修改 Pattern 即無法滿足上層規則中臺、風控中臺的可整合性；
  2. Flink 社群的 CEP API 無法支援Pattern 定義事件之間的超時。

阿里雲 Flink 實時計算團隊和錢大媽工程師共同攻堅，在 Flink 社群發起如下兩個 FLIP 提案並且在阿里雲實時計算產品上面輸出相應功能解決此問題：

  1. FLIP-200：CEP 支援多規則和動態 Pattern 變更；
  2. FLIP-228：CEP 支援 Pattern 定義事件之間的超時。

阿里雲實時計算產品輸出的支援多規則和動態規則變更、支援 Pattern 定義事件之間的超時以及支援基於 IterativeCondition 的累加器商業化功能拓寬 Flink 在實時風控的能力，並且上述商業化功能已經在錢大媽生產環境落地實踐。其中 Flink CEP 動態更新 Pattern 機制中內部各元件的互動總覽如下：

img

<p style="text-align:center">圖五：社群Flink CEP動態Pattern機制

風控規則由產品介面作為入口，規則寫入到 Hologres 中，同時 JDBCPatternProcessorDiscover 週期性輪詢發現規則的變更。其中規則表的資料結構如下：

  1. Id：規則ID；
  2. Version：規則對應的版本號；
  3. Keyby：規則分組欄位（如需分組）；
  4. Pattern：CEP Pattern 序列化後的 Json 字串；
  5. Function：CEP 匹配後處理的 PatternProcessFunction；
  6. Relation：統計型和規則型之間的與、或關係（前提：統計型和規則型的 ID 相同）。

img

圖六：社群Flink動態CEP規則表

五、回顧展望

基於 Flink 的實時風控解決方案已接應用於錢大媽集團內部生產環境，在此解決方案裡未引入新的技術元件和程式語言，最大化複用 Flink 資源實現實時風控場景需求，極大降低新元件引入存在的潛在運維風險。另一方面也極大降低研發團隊的學習成本，高效釋放實時計算的人力資源，並且對於研發和業務應用上面帶來如下好處：

  • 解耦 Flink 作業邏輯開發和業務規則定義；
  • 業務規則儲存在 Database 中，便於檢視規則當前狀態和歷史版本；
  • 規則變更只需修改 Database 儲存的規則，Flink 自動載入更新作業中的規則列表；
  • 結合 Flink 生態能夠非常容易整合事件異構資料來源的讀取與寫入；
  • 結合 Flink 分散式能力，大規模擴充套件至數千併發度匹配執行規則。

後續錢大媽將和阿里雲實時計算產品團隊，繼續共建完善基於 Flink 的實時風控風控解決方案，其中在 Flink CEP 的未來規劃將圍繞以下三個主要方向展開：

  1. Flink CEP 能力的進一步增強；
  2. Flink CEP SQL 的動態能力；
  3. Flink + DSL 的 Native 支援

公司簡介：錢大媽是在社群生鮮連鎖中，以"不賣隔夜肉"作為品牌理念的的行業開拓者。在成立之初即從新鮮角度重新梳理傳統生鮮行業的標準，對肉菜市場進行新的定義。錢大媽已全國佈局近 30 座城市，門店總數突破 3000 多家，服務家庭超 1000 萬。

本文作者：彭明德，目前就職於錢大媽，任全渠道資料中臺大資料開發工程師。

同時也希望更多有實時風控需求，或熱愛風控場景建設的小夥伴能夠在 Flink 社群風控釘釘專群進行溝通：

img

圖七：Flink社群實時風控專群二維碼

相關文章