基於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 前置過濾

業務系統在特定事件（如註冊、登錄、下單、參加活動等）被觸發後同步調用風控系統，附帶相關上下文，好比IP地址，事件標識等，規則判斷部分會根據管理後臺的配置決定是否進行判斷，若是是，接着進行黑白名單過濾，都經過後進入下一個環節。

這部分邏輯很是簡單。

2.1.2 實時數據準備

在進行判斷以前，系統必需要準備一些事實數據，好比：

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

redis/hbase的數據產出咱們會在第2.2節準實時數據流中進行介紹。

2.2.3 規則判斷

在獲得事實數據以後，系統會根據規則和閾值進行判斷，而後返回結果，整個過程便結束了。

整個過程邏輯上是清晰的，咱們常說的規則引擎主要在這部分起做用，通常來講這個過程有兩種實現方式：

• 藉助成熟的規則引擎，好比Drools，Drools和Java環境結合的很是好，自己也很是完善，支持不少特性，不過使用比較繁瑣，有較高門檻，可參考文章【1】；
• 基於Groovy等動態語言本身完成，這裏不作贅述。可參考文章【2】；

這兩種方案都支持規則的動態更新。

2.2 準實時數據流

這部分屬於後臺邏輯，爲風控系統服務，準備事實數據。

把數據準備與邏輯判斷拆分，是出於系統的性能/可擴展性的角度考慮的。

前邊提到，作規則判斷須要事實的相關指標，好比最近一小時登錄次數，最近一小時註冊帳號數等等，這些指標一般有一段時間跨度，是某種狀態或聚合，很難在實時風控過程當中根據原始數據進行計算，由於風控的規則引擎每每是無狀態的，不會記錄前面的結果。

同時，這部分原始數據量很大，由於用戶活動的原始數據都要傳過來進行計算，因此這部分每每由一個流式大數據系統來完成。在這裏咱們選擇Flink，Flink是當今流計算領域無可爭議的No.1，不論是性能仍是功能，都能很好的完成這部分工做。

這部分數據流很是簡單：

• 業務系統把埋點數據發送到Kafka；

• Flink訂閱Kafka，完成原子粒度的聚合；

  • 注：Flink僅完成原子粒度的聚合是和規則的動態變動邏輯相關的。舉例來講，在註冊場景中，運營同窗會根據效果一會要判斷某IP最近1小時的註冊帳號數，一會要判斷最近3小時的註冊帳號數，一會又要判斷最近5小時的註冊帳號數……也就是說這個最近N小時的N是動態調整的。那Flink在計算時只應該計算1小時的帳號數，在判斷過程當中根據規則來讀取最近3個1小時仍是5個1小時，而後聚合後進行判斷。由於在Flink的運行機制中，做業提交後會持續運行，若是調整邏輯須要中止做業，修改代碼，而後重啓，至關麻煩；同時由於Flink中間狀態的問題，重啓還面臨着中間狀態可否複用的問題。因此假如直接由Flink完成N小時的聚合的話，每次N的變更都須要重複上面的操做，有時還須要追數據，很是繁瑣。

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

經過把數據計算和邏輯判斷拆分開來並引入Flink，咱們的風控系統能夠應對極大的用戶規模。

3.分析系統

前面的東西靜態來看是一個完整的風控系統，但動態來看就有缺失了，這種缺失不體如今功能性上，而是體如今演進上。即若是從動態的角度來看一個風控系統的話，咱們至少還須要兩部分，一是衡量系統的總體效果，一是爲系統提供規則/邏輯升級的依據。

在衡量總體效果方面，咱們須要：

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

在爲系統提供規則/邏輯升級依據方面，咱們須要：

• 發現全局規則，好比某人在電子產品的花費忽然增加了100倍，單獨來看是有問題的，但總體來看，可能不少人都出現了這個現象，原來是蘋果發新品了……
• 識別某種行爲的組合，單次行爲是正常的，但組合是異常的，好比用戶買菜刀是正常的，買車票是正常的，買繩子也是正常的，去加油站加油也是正常的，但短期內同時作這些事情就不是正常的。
• 羣體識別，好比經過圖分析技術，發現某個羣體，而後給給這個羣體的全部帳號都打上羣體標籤，防止出現那種每一個帳號表現都正常，但整個羣體卻在集中薅羊毛的狀況。

這即是分析系統的角色定位，在他的工做中有部分是肯定性的，也有部分是探索性的，爲了完成這種工做，該系統須要儘量多的數據支持，如：

• 業務系統的數據，業務的埋點數據，記錄詳細的用戶、交易或活動數據；
• 風控攔截數據，風控系統的埋點數據，好比某個用戶在具備某些特徵的狀態下由於某條規則而被攔截，這條攔截自己就是一個事件數據；

這是一個典型的大數據分析場景，架構也比較靈活，我僅僅給出一種建議的方式。

相對來講這個系統是最開放的，既有固定的指標分析，也可使用機器學習/數據分析技術發現更多新的規則或模式，限於篇幅，這裏就不詳細展開了。

4.參考資料

1.從 Drools 規則引擎到風控反洗錢 
2.基於Groovy的規則腳本引擎實戰
3.基於規則的風控系統
4.網易嚴選風控實踐
5.網易考拉規則引擎平臺架構設計與實踐
6.一個開源java風控系統

---

本文做者：付空

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。