1. 基于 Flink 構建風控系統
2. 阿里風控實戰
3. 大規模風控技術難點

目前 Flink 基本服務于集團的所有 BU ，在雙十一峰值的計算能力達到 40 億條每秒，計算任務達到了 3 萬多個，總共使用 100 萬+ Core ；幾乎涵蓋了集團內的所有具體業務，比如：數據中臺、AI 中臺、風控中臺、實時運維、搜索推薦等。

01基于 Flink 構建風控系統

風控是一個很大的話題，涉及到規則引擎、NoSQL DB、CEP 等等，本章主要講一些風控的基本概念。在大數據側，我們把風控劃分成 3 × 2 的關系：

• 2 代表風控要么是基于規則的，要么是基于算法或模型的；
• 3 代表包括三種風控類型：事先風控、事中風控和事后風控。

1.1 三種風控業務

對于事中風控和事后風控來講，端上的感知是異步的，對于事先風控來講，端上的感知是同步的。

對于事先風控這里稍做一些解釋，事先風控是把已經訓練好的模型或者把已經計算好的數據存在 Redis 、MongoDB 等數據庫中；

• 一種方式是端上有類似 Sidden 、Groovy 、Drools 這樣的規則引擎直接去 Redis 、MongoDB 取數據來返回結果；
• 另外一種方式是基于 Kubeflow KFserving ，端上請求過來之后基于訓練好的算法和模型返回結果。

整體來講這兩種方式的時延都在 200 毫秒左右，可以作為一個同步的 RPC 或 HTTP 請求。

對于 Flink 相關的大數據場景是一個異步的風控請求，它的異步時效性非常低，通常是一秒或者兩秒。如果追求超低時延，則可以認為它是一種事中的風控，風控決策過程可以由機器介入處理。

很常見的一種類型是用 Flink SQL 做指標閾值的統計、用 Flink CEP 做行為序列規則分析，還有一種是用 Tensorflow on Flink ，在 Tensorflow 中進行算法描述，然后用 Flink 來執行 Tensorflow 規則的計算。

1.2 Flink 是規則風控最佳選擇

目前 Flink 是阿里集團內的風控最佳選擇，主要有三個原因：

• 事件驅動
• 毫秒級的延遲
• 流批一體

1.3 規則風控三要素

在規則風控里面有三個要素，后面講的所有內容都是圍繞這三者展開的：

• 事實 Facts：是指風控事件，可能來自業務方或者日志埋點，是整個風控系統的輸入；
• 規則 Rules：往往是由業務側來定義，即這個規則要滿足什么樣的業務目標；
• 閾值 Threshold：規則所對應描述的嚴重程度。

1.4 Flink 規則表達增強

對于 Flink 來說，可以分成無狀態規則和有狀態規則兩類，其中有狀態規則是 Flink 風控的核心：

• 無狀態規則：主要是做數據的 ETL，一種場景是當某個事件的一個字值段大于 X 就觸發當前的風控行為；另一種場景是 Flink 任務的下游是一個基于模型或算法的風控，在 Flink 側不需要做規則判斷，只是把數據向量化、歸一化，例如多流關聯、Case When 判斷等把數據變成 0/1 的向量，然后推送到下游的 TensorFlow 做預測。
• 有狀態規則：

• 統計型規則：基于統計分析的計算規則，比如 5 分鐘以內訪問次數大于 100 次，則認為觸發了風控；
• 序列型規則：事件序列中，某事件對前序后序事件有影響，比如點擊、加入購物車、刪掉三個事件，這種連續的行為序列是一個特殊行為，可能認為這個行為在惡意降低商家商品的評價分數，但這三個事件獨立來看并不是一個風控事件；阿里云實時計算 Flink 完善了基于序列的規則能力，為云上和集團內的電商交易場景提供技術護航；
• 混合型規則：統計型和序列性兩者組合。

02阿里風控實戰

本章主要介紹阿里在工程上是如何滿足上面提到的風控三要素。

從整體的技術來看，目前分成感知、處置和洞察三個模塊：

• 感知：目的是感知所有的異常以及提前發現問題，比如捕捉一些與常見數據分布不同的數據類型，并輸出這種異常的列表；又比如說某年因為騎行政策的調整頭盔銷售量升高，連帶著就會出現相關產品的點擊率、轉化率上升，這種情況需要及時被感知捕捉到，因為它是一個正常的行為而非作弊；
• 處置：即如何做規則的執行，現在有小時、實時、離線三道防線，相比于之前單條策略的匹配，關聯和集成之后的準確性會更高，比如就關聯最近一段時間內某些用戶的持續行為來進行綜合研判；
• 洞察：為了發現一些當前沒有感知，同時也沒有辦法直接用規則描述的風控行為，比如風控需要對樣本進行高度抽象來進行表示，要先投影到合適的子空間，然后再結合時間維度在高維里面發現一些特征來做新異常的識別。

2.1 階段一：SQL 實時關聯 & 實時統計

在這個階段有一個基于 SQL 評價風控系統，用簡單的 SQL 做一些實時的關聯、統計，比如用 SQL 進行聚合操作 SUM(amount) > 50 ，其中規則就是 SUM(amount)，規則對應的閾值是 50；假設現在有 10、20、50、100 這 4 種規則同時在線上運行，因為單Flink SQL作業只能執行一種規則，那么就需要為這4個閾值分別申請 4 個 Flink Job。優點是開發邏輯簡單，作業隔離性高，但缺點是極大浪費計算資源。

2.2 階段二：Broadcast Stream

階段一的風控規則主要問題是規則和閾值不可變，在 Flink 社區目前會有一些解決方案，比如基于 BroadcastStream 來實現，在下面的圖中 Transaction Source 負責事件的接入，Rule Source 則是一個BroadcastStream，當有新的閾值時可以通過 BroadcastStream 廣播到各個算子。

舉個例子，判斷在一分鐘以內連續訪問超過 10 次的風控對象，但是在 618 或雙 11 可能要把它變成 20 或 30 次，才會被風控系統下游的在線系統感知到。

如果在第一階段的話，只有兩種選擇：第一種是所有的作業全量在線上跑；第二種是在某一刻停止掉一個Flink作業，新拉起一個基于新指標的作業。

如果是基于 BroadcastStream 就可以實現規則指標閾值的下發，直接修改線上指標閾值而不需要作業重啟。

2.3 階段三：Dynamic CEP

階段二的主要問題是只能做到指標閾值的更新，雖然它極大的方便了個業務系統，但實際上很難滿足上層業務。訴求主要有兩個：結合 CEP 以實現行為序列的感知；結合 CEP 后依然能做到動態修改閾值甚至是規則本身。

階段三，阿里云 Flink 做了 CEP 相關的高度抽象，解耦了 CEP 規則和 CEP 執行節點，也就是說規則可以存在 RDS、Hologres 等外部第三方存儲里，CEP 作業發布上去之后，就可以加載數據庫中的 CEP 規則來做到動態替換，因此作業的表達能力會增強。

其次是作業的靈活性會增強，比如想看到某一個 APP 下面的一些行為并對這個行為的指標閾值做更新，可以通過第三方存儲更新 CEP 規則而非 Flink 本身。

這樣做還有一個優勢是可以把規則給暴露給上層業務方，來讓業務真真正正的撰寫風控規則，我們成為一個真正的規則中臺，這就是動態 CEP 能力所帶來的好處。在阿里云的服務中，動態 CEP 能力已經被集成在最新版本中，阿里云全托管 Flink 服務極大的簡化了風控場景的開發周期。

2.4 階段四：Shared Computing

在階段三的基礎上再往前一步，阿里云實踐出 "共享計算" 的解決方案。這套共享計算的方案中，CEP 規則完全可以被建模平臺來描述，暴露給上層客戶或業務方一個非常友好的規則描述平臺，可以通過類似拖拉拽或者其他的方式進行耦合，然后在調度引擎上選擇事件接入源來運行規則。比如現在兩個建模都是服務于淘寶 APP，完全可以落到同一個 Fact 的 Flink CEP 作業上，這樣就可以把業務方、執行層和引擎層完全解耦。當前阿里云共享計算的解決方案已經非常成熟，有豐富的客戶落地實踐。

2.5 階段五：業務開發和平臺建設分離

在引擎側、平臺側和業務側三方之間，階段四可以做到引擎側和平臺側之間的解耦，但是對業務側來講依然是高度綁定的。兩者的工作模式依然是甲方和乙方的協同關系，即 業務側掌握著業務規則，平臺側接受業務團隊的風控需求，從而進行風控規則的開發。但平臺團隊通常人員優先，而業務團隊隨著業務發展會越來越壯大。

這個時候業務側本身可以抽象出來一些基本概念，沉淀出一些業務共性的規范，并組裝成一個比較友好的 DSL ，然后通過阿里云完全解耦的 Open API 實現作業的提交。

由于要同時支持集團內接近 100 個 BU，沒有辦法為每一個 BU 都做定制化的支持，只能把引擎的能力盡可能的開放出去，然后業務側通過 DSL 的封裝提交到平臺上，真正做到了只暴露一個中臺給客戶。

03大規模風控技術難點

本章主要介紹一些大規模風控的技術難點，以及阿里云在全托管 Flink 商業化產品中如何突破這些技術難點。

3.1 細粒度資源調整

在流計算系統中，數據源往往不是阻塞的節點。上游的數據讀取節點由于沒有計算邏輯不存在性能問題，下游的數據處理節點才是整個任務的性能瓶頸。

由于 Flink 的作業是以 Slot 來做資源劃分的，默認 Source 節點和工作節點具有相同的并發度。在這種情況下我們希望可以單獨調整 Source 節點和 CEP 工作節點的并發度，比如在下圖中可以看到某個作業的 CEP 工作節點并發度可以達到 2000，而 Source 節點則只需要 2 個并行度，這樣可以極大的提升 CEP 節點的工作性能。

另外是對 CEP 工作節點所在的 TM 內存、CPU 資源的劃分，在開源 Flink 中 TM 整體同構的，也就是說 Source 節點和工作節點是完全相同的規格。從節省資源的角度考慮，真實生產環境下 Source 節點并不需要 CEP 節點一樣多的內存、CPU 資源， Source 節點只需要較小的 CPU 和內存就已經能夠滿足數據抓取。

阿里云全托管 Flink 可以實現讓 Source 節點和 CEP 節點運行在異構的 TM 上，即 CEP 工作節點 TM 資源顯著大于 Source 節點 TM 資源，CEP 工作執行效率會變得更高。考慮細粒度資源調整帶來的優化，云上全托管服務相比自建 IDC Flink 可節約 20% 成本。

3.2 流批一體 & 自適應 Batch Scheduler

流引擎和批引擎如果沒有采用相同一套執行模式往往會遇到數據口徑不一致的情況，出現這種問題的原因是流規則在批規則下很難真正的完全描述出來；比如在 Flink 中有一個特殊的 UDF，但是在 Spark 引擎中卻并沒有對應的 UDF。當這種數據口徑不一致的時候，選擇哪一方面的數據口徑就成為了一個非常重要的問題。

在 Flink 流批一體的基礎上，用流模式描述的 CEP 規則，完全可以在批模式下以相同的口徑再跑一次并得到一樣的結果，這樣就不需要再去開發批模式相關的 CEP 作業。

在此之上，阿里實現了自適應的 Batch Scheduler。其實 CEP 規則每天的效果產出并不一定是均衡的，比如說今天的行為序列中并沒有任何異常行為，下游只有很少的數據輸入，此時會為批分析預留一個彈性的集群；當 CEP 的結果很少時，下游的批分析只需要很小的資源，甚至每個批分析工作節點的并行度都不需要在一開始的時候就指定，工作節點可以根據上游數據的輸出以及任務負載來自動調整批模式下的并行度，真正做到了彈性批分析，這是阿里云 Flink 流批一體 Batch Scheduler 的獨特優勢。

3.3 合并讀取降低公共層壓力

這是在實踐中遇到的問題，當前的開發模式基本都是基于數據中臺的，比如實時數倉。在實時數倉的場景下，數據源可能不會很多，但是中間層 DWD 會變得很多，中間層可能會被演化成很多 DWS 層，甚至也會演變成很多數據集市給到各個部門來使用，這種情況下單表的讀取壓力會很大。

通常多個源表彼此關聯（打寬）從而形成一個 DWD 層 ，從單個源表的視角看，它會被多個 DWD 表依賴。DWD 層也會被多個不同業務域的作業消費形成 DWS。基于這種情況阿里實現了基于 Source 的合并，只需要讀一次 DWD 在 Flink 側會幫你加工成多張業務域的 DWS 表，可以非常大的減緩對公共層的執行壓力。

3.4 KV 分離設計的狀態后端

CEP 節點在執行的時候，會涉及到非常大規模的本地數據讀取，尤其是在行為序列的計算模式下，因為需要緩存前面所有的數據或者是一定時間內的行為序列。

在這種情況下，比較大的一個問題是對后端狀態存儲（比如：RocksDB）有非常大的性能開銷，進而會影響 CEP 節點的性能。目前阿里實現了 KV 分離設計的狀態后端，阿里云 Flink 默認使用 Gemini 作為狀態后段，CEP 場景下實測性能至少有 100% 的提升。

3.5 維度數據分區加載

風控在很多情況下是要基于歷史行為來做分析的，歷史的行為數據一般都會存在 Hive 或 ODPS 表里，這個表的規模可能是 TB 級別的。開源的 Flink 默認需要在每一個維表節點上加載這個超級大的維度表，這種方式實際上是不現實的。阿里云實現了基于 Shuffle 來做內存數據的分割，維表節點只會加載屬于當前這個 Shuffle 分區的數據。