基于Flink和規則引擎的實時風控解決方案

案例與解決方案匯總頁： 阿里云實時計算產品案例&解決方案匯總

1.總體架構

• 業務系統，通常是APP+后臺 或者 web，是互聯網業務的載體，風險從業務系統觸發；
• 風控系統，為業務系統提供支持，根據業務系統傳來的數據或埋點信息來判斷當前用戶或事件有無風險；
• 懲罰系統，業務系統根據風控系統的結果來調用，對有風險的用戶或事件進行控制或懲罰，比如增加驗證碼、限制登陸、禁止下單等等；
• 分析系統，該系統用以支持風控系統，根據數據來衡量風控系統的表現，比如某策略攔截率突然降低，那可能意味著該策略已經失效，又比如活動商品被強光的時間突然變短，這表面總體活動策略可能有問題等等，該系統也應支持運營/分析人員發現新策略；

• 電商業務；
• 風控范圍包括：
• 注冊，虛假注冊；
• 登陸，盜號登陸；
• 交易，盜刷客戶余額；
• 活動，優惠活動薅羊毛；

• 風控實現方案：事中風控，目標為攔截異常事件；

2.風控系統

• 用戶名與身份證姓名不一致；
• 某IP最近1小時注冊賬號數超過10個；
• 某賬號最近3分鐘登陸次數大于5次；
• 某賬號群體最近1消失購買優惠商品超過100件；
• 某賬號最近3分鐘領券超過3張；

• 事實，即被判斷的主體和屬性，如上面規則的賬號及登陸次數、IP和注冊次數等；
• 條件，判斷的邏輯，如某事實的某屬性大于某個指標；
• 指標閾值，判斷的依據，比如登陸次數的臨界閾值，注冊賬號數的臨界閾值等；

• 實時風控數據流，由紅線標識，同步調用，為風控調用的核心鏈路；
• 準實時指標數據流，由藍線標識，異步寫入，為實時風控部分準備指標數據；
• 準實時/離線分析數據流，由綠線標識，異步寫入，為風控系統的表現分析提供數據；

2.1 實時風控

• 場景管理，決定某個場景是否實施風控，比如活動場景，在活動結束后可以關閉該場景；
• 黑白名單，人工/程序找到系統的黑白名單，直接過濾；
• 規則管理，管理規則，包括增刪或修改，比如登陸新增IP地址判斷，比如下單新增頻率校驗等；
• 閾值管理，管理指標的閾值，比如規則為某IP最近1小時注冊賬號數不能超過10個，那1和10都屬于閾值；

2.1.1 前置過濾

2.1.2 實時數據準備

• 注冊場景，假如規則為單一IP最近1小時注冊賬號數不超過10個，那系統需要根據IP地址去redis/hbase找到該IP最近1小時注冊賬號的數目，比如15；
• 登陸場景，假如規則為單一賬號最近3分鐘登陸次數不超過5次，那系統需要根據賬號去redis/hbase找到該賬號最近3分鐘登陸的次數，比如8；

2.2.3 規則判斷

• 借助成熟的規則引擎，比如Drools，Drools和Java環境結合的非常好，本身也非常完善，支持很多特性，不過使用比較繁瑣，有較高門檻，可參考文章【1】；
• 基于Groovy等動態語言自己完成，這里不做贅述?？蓞⒖嘉恼隆?】；

2.2 準實時數據流

• 業務系統把埋點數據發送到Kafka；
• Flink訂閱Kafka， 完成原子粒度的聚合；
• 注：Flink僅完成原子粒度的聚合是和規則的動態變更邏輯相關的。舉例來說，在注冊場景中，運營同學會根據效果一會要判斷某IP最近1小時的注冊賬號數，一會要判斷最近3小時的注冊賬號數，一會又要判斷最近5小時的注冊賬號數……也就是說這個最近N小時的N是動態調整的。那Flink在計算時只應該計算1小時的賬號數，在判斷過程中根據規則來讀取最近3個1小時還是5個1小時，然后聚合后進行判斷。因為在Flink的運行機制中，作業提交后會持續運行，如果調整邏輯需要停止作業，修改代碼，然后重啟，相當麻煩；同時因為Flink中間狀態的問題，重啟還面臨著中間狀態能否復用的問題。所以假如直接由Flink完成N小時的聚合的話，每次N的變動都需要重復上面的操作，有時還需要追數據，非常繁瑣。

• Flink把匯總的指標結果寫入Redis或Hbase，供實時風控系統查詢。兩者問題都不大，根據場景選擇即可。

3.分析系統

• 判斷規則是否失效，比如攔截率的突然降低；
• 判斷規則是否多余，比如某規則從來沒攔截過任何事件；
• 判斷規則是否有漏洞，比如在舉辦某個促銷活動或發放代金券后，福利被領完了，但沒有達到預期效果；

• 發現全局規則，比如某人在電子產品的花費突然增長了100倍，單獨來看是有問題的，但整體來看，可能很多人都出現了這個現象，原來是蘋果發新品了……
• 識別某種行為的組合，單次行為是正常的，但組合是異常的，比如用戶買菜刀是正常的，買車票是正常的，買繩子也是正常的，去加油站加油也是正常的，但短時間內同時做這些事情就不是正常的。
• 群體識別，比如通過圖分析技術，發現某個群體，然后給給這個群體的所有賬號都打上群體標簽，防止出現那種每個賬號表現都正常，但整個群體卻在集中薅羊毛的情況。

• 業務系統的數據，業務的埋點數據，記錄詳細的用戶、交易或活動數據；
• 風控攔截數據，風控系統的埋點數據，比如某個用戶在具有某些特征的狀態下因為某條規則而被攔截，這條攔截本身就是一個事件數據；