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

語言: CN / TW / HK

▼ 關注「 Apache Flink 」,獲取更多技術乾貨 

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

  1. 專案背景

  2. 業務架構

  3. 未規則模型

  4. 難點攻堅

  5. 回顧展望

Tips: 點選 「閱讀原文」 進入 Flink 中文學習網~

一、專案背景

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

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

二、業務架構

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

  1. 事件接入 。其中包括黑白灰名單庫、畫像特徵資料、行為埋點資料和中臺交易資料。

  2. 風險感知 。策略調研後釋出到規則引擎,並對告警結果進行離線迴歸和多渠道觸達。

  3. 風險應對 。對涉及到財務結算的規則提供再稽核、豁免機制或人工補償。

  4. 風險回溯 。策略命中後進行統計和風險分類分級,預警離線回溯並對風控事件閉件。

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

三、規則模型

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

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

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

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

    1. 以使用者 ID 分組:"使用者的下單次數";

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

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

    1. A 門店近 30 分鐘獨立消費使用者數小於 100;

    2. B 門店新客消費金額大於 300。

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

    1. 每 30 分鐘時間視窗內,單個使用者發起超過 20 筆未支付訂單;

    2. 凌晨 1 點至 3 點,單個使用者支付訂單數超 50 筆。

  4. 視窗型別 。為了面對不同的業務需求,我們將業務規則中常見的視窗型別整合到規則引擎內部。其中包括滑動視窗、累計視窗、甚至是無視窗(即時觸發)。

  5. 聚合前的過濾條件

    1. 只對"下單事件"進行統計;

    2. 過濾門店"虛擬使用者"。

  6. 聚合後的過濾條件

    1. 使用者 A 在 5 分鐘內下單次數 "超過 150 次";

    2. 使用者 B 在 5 分鐘內購買金額 "超過 300 元"。

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

    1. 應收金額大於 150 元(應收金額 = 商品金額合計 +運費 + 優惠合計);

    2. 通過 POS 端支付的應收金額大於 150 元。

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

    1. 使用者 A 在 5 分鐘內依次做了點選、收藏、加購;

    2. 使用者 B 在 30 分鐘前領了優惠券,但是沒有下單。

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

四、難點攻堅

針對規則模型的流式序列型資料,我們選擇 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 [1] :CEP 支援多規則和動態 Pattern 變更;

  2. FLIP-228  [2] :CEP 支援 Pattern 定義事件之間的超時。

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

圖五:社群Flink CEP動態Pattern機制

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

  1. Id :規則ID;

  2. Version :規則對應的版本號;

  3. Keyby :規則分組欄位(如需分組);

  4. Pattern :CEP Pattern 序列化後的 Json 字串;

  5. Function :CEP 匹配後處理的 PatternProcessFunction;

  6. Relation :統計型和規則型之間的與、或關係(前提:統計型和規則型的 ID 相同)。

圖六:社群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 社群風控釘釘專群進行溝通:

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

[1] FLIP-200: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=195730308

[2] FLIP-228: https://cwiki.apache.org/confluence/display/FLINK/FLIP-228%3A+Support+Within+between+events+in+CEP+Pattern

往期精選

▼ 關注「 Apache Flink 」,獲取更多技術乾貨 

更多 Flink 相關技術問題,可掃碼加入社群釘釘交流群~

點選「閱 讀原文 」,進入 Flink 中文學習網~