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

大濤學長發表於2019-10-23
案例與解決方案彙總頁： 阿里雲實時計算產品案例&解決方案彙總
對一個網際網路產品來說，典型的風控場景包括：註冊風控、登陸風控、交易風控、活動風控等，而風控的最佳效果是防患於未然，所以事前事中和事後三種實現方案中，又以事前預警和事中控制最好。
這要求風控系統一定要有實時性。
本文就介紹一種實時風控解決方案。

1.總體架構

風控是業務場景的產物，風控系統直接服務於業務系統，與之相關的還有懲罰系統和分析系統，各系統關係與角色如下：

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

  • 業務系統，通常是APP+後臺 或者 web，是網際網路業務的載體，風險從業務系統觸發；
  • 風控系統，為業務系統提供支援，根據業務系統傳來的資料或埋點資訊來判斷當前使用者或事件有無風險；
  • 懲罰系統，業務系統根據風控系統的結果來呼叫，對有風險的使用者或事件進行控制或懲罰，比如增加驗證碼、限制登陸、禁止下單等等；
  • 分析系統，該系統用以支援風控系統，根據資料來衡量風控系統的表現，比如某策略攔截率突然降低，那可能意味著該策略已經失效，又比如活動商品被強光的時間突然變短，這表面總體活動策略可能有問題等等，該系統也應支援運營/分析人員發現新策略；
其中 風控系統和 分析系統是本文討論的重點，而為了方便討論，我們假設業務場景如下：
  • 電商業務；
  • 風控範圍包括：
  • 註冊，虛假註冊；
  • 登陸，盜號登陸；
  • 交易，盜刷客戶餘額；
  • 活動，優惠活動薅羊毛；

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

2.風控系統

風控系統有 規則和 模型兩種技術路線，規則的優點是簡單直觀、可解釋性強、靈活，所以長期活躍在風控系統之中，但缺點是容易被攻破，一但被黑產猜到裡面就會失效，於是在實際的風控系統中，往往再結合上基於模型的風控環節來增加健壯性。但限於篇幅，本文中我們只重點討論一種基於規則的風控系統架構，當然如果有模型風控的訴求，該架構也完全支援。
規則就是針對事物的條件判斷，我們針對註冊、登陸、交易、活動分別假設幾條規則，比如：
  • 使用者名稱與身份證姓名不一致；
  • 某IP最近1小時註冊賬號數超過10個；
  • 某賬號最近3分鐘登陸次數大於5次；
  • 某賬號群體最近1消失購買優惠商品超過100件；
  • 某賬號最近3分鐘領券超過3張；
規則可以組合成規則組，為了簡單起見，我們這裡只討論規則。
規則其實包括三個部分：
  • 事實，即被判斷的主體和屬性，如上面規則的賬號及登陸次數、IP和註冊次數等；
  • 條件，判斷的邏輯，如某事實的某屬性大於某個指標；
  • 指標閾值，判斷的依據，比如登陸次數的臨界閾值，註冊賬號數的臨界閾值等；
規則可由運營專家憑經驗填寫，也可由資料分析師根據歷史資料發掘，但因為規則在與黑產的攻防之中會被猜中導致失效，所以無一例外都需要動態調整。
基於上邊的討論，我們設計一個風控系統方案如下：
基於Flink和規則引擎的實時風控解決方案
該系統有三條資料流向：
  • 實時風控資料流，由紅線標識，同步呼叫，為風控呼叫的核心鏈路；
  • 準實時指標資料流，由藍線標識，非同步寫入，為實時風控部分準備指標資料；
  • 準實時/離線分析資料流，由綠線標識，非同步寫入，為風控系統的表現分析提供資料；
本節先介紹前兩部分，分析系統在下一節介紹。

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倍，單獨來看是有問題的，但整體來看，可能很多人都出現了這個現象，原來是蘋果發新品了……
  • 識別某種行為的組合，單次行為是正常的，但組合是異常的，比如使用者買菜刀是正常的，買車票是正常的，買繩子也是正常的，去加油站加油也是正常的，但短時間內同時做這些事情就不是正常的。
  • 群體識別，比如通過圖分析技術，發現某個群體，然後給給這個群體的所有賬號都打上群體標籤，防止出現那種每個賬號表現都正常，但整個群體卻在集中薅羊毛的情況。
這便是分析系統的角色定位，在他的工作中有部分是確定性的，也有部分是探索性的，為了完成這種工作，該系統需要儘可能多的資料支援，如：
  • 業務系統的資料，業務的埋點資料，記錄詳細的使用者、交易或活動資料；
  • 風控攔截資料，風控系統的埋點資料，比如某個使用者在具有某些特徵的狀態下因為某條規則而被攔截，這條攔截本身就是一個事件資料；
這是一個典型的大資料分析場景，架構也比較靈活，我僅僅給出一種建議的方式。
基於Flink和規則引擎的實時風控解決方案

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

原文連結
本文為雲棲社群原創內容，未經允許不得轉載。


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69947441/viewspace-2661126/，如需轉載，請註明出處，否則將追究法律責任。

相關文章