智能風控系統設計與實踐

導讀

在主流互聯網產品中，比如搜索和推薦的系統，為了挖掘用戶潛在購買需求，縮短用戶到商品或信息的距離，提高用戶的使用體驗，都需要使用大量的特徵來刻畫用戶的行為。在信息安全領域，建立在人工智能技術之上的策略引擎已經深入到了風控產品功能的方方面面，相應的，每一個策略系統都離不開大量的特徵，來支撐模型算法或人工規則對請求的精準響應，因此特徵系統成為了支持線上風控引擎的重要支柱。

本文以智能風控在線特徵系統為原型，重點從線上數據從生產到特徵物料提取、計算、存取角度介紹一些實踐中的通用技術點，以解決在線特徵系統在高併發情形下面臨的問題和挑戰。

特徵系統的基本概念

1. 特徵定義

什麼是特徵？特徵是一個客體或一組客體特性的抽象結果。特徵是用來描述概念的。任一客體或一組客體都具有眾多特性，我們根據客體所共有的特性抽象出某一概念，該概念便成為了特徵。因此我們可以理解特徵是觀察事物的一個角度，它可以是“橫看成嶺側成峰”。特徵它是一個抽象概念， 為了使抽象的概念可落地、可存儲、可量化，結合了我們的業務特性對特徵進行了又一次定義：

特徵 = 維度+ 時間窗口 + 計算函數。

舉個例子 ：“過去15分鐘同用戶多iP的數量”，那麼最終的實際計算結果為特徵值，過去15分鐘為時間窗口，用戶標識為維度，計算函數是針對iP進行去重計算的邏輯。

2. 時間窗口類型

在信息安全領域，黑產為了追求收益，一定會最大程度的將成本最小化。為了保證成本的可控，黑產在攻擊時採取的策略是能簡單決不復雜，能機器絕不人工，總之就一個目標，完成利益的收割，因此他們一定會利用僅有的資源做一些高頻的動作。那麼以什麼樣的週期或者時間窗口來統計這些高頻率動作更能反應出實際問題呢？我們在長期的風控治理中結合業界的劃分標準歸納了以下四種：

a) 自然窗口期：時間窗口的起點是固定的，但終止時間點一直在向前滾動，比如用戶當天累計發帖數量或者消耗類特徵的存儲。

b) 固定窗口期：時間窗口的起止時間點是固定的，比如每天的某一時間段用戶發送消息數量，主要針對特定時間用戶的處罰、灌水的限制等。

c) 滑動窗口期：時間窗口的長度是固定的，但起止時間點一直在向前滾動，主要針對風控事中檢測，常用來判讀信息准入，例如風控發帖時間點前15分鐘的計數。

d）Session窗口期：以第一個事件開始，依次向後滾動計算，直到超出一個session窗口期時間重新開始，主要針對控頻，UV統計等。

圖1

如圖1所示，相同的維度，相同的計算函數，不同的時間窗口類型得到的特徵值及其反應的業務含義都會有一定的差別。

3. 計算函數類型

特徵的計算有繁有簡，複雜多變。回到業務需求，我們的目的是通過特徵生產系統來簡化開發工作量，而非完全取代特徵開發。因此我們選擇一部分常見的函數計算類型，實現自動化生產。對於更復雜的特徵計算，提供了特徵更新接口支持第三方應用的對接。總結常見的計算類型主要有以下幾種。

a) 求和（SUM），對窗口期內的數據進行求和；

b) 計數（COUNT），對窗口期內的數據進行計數統計；

c) 去重計數（COUNT_DISTINCT），對窗口期內的指定字段去除重複量後統計；

d) 明細（LIST），返回窗口期內最新的前5000條明細數據；

e) 最大值（MAX），計算出窗口期內的最大值；

f）最小值（MIN），計算出窗口期內的最小值；

g) 平均數（AVG），對窗口期內的數進行均值計算。

早期特徵系統技術實現方案

早期特徵系統主要以離線的方式為主，在數據倉庫中特徵表主要依靠數據分析師、算法工程師以及策略運營等同學建立特徵需求由數據工程師排期開發，同時數據工程師還需要開發ETL調度任務，每天定時將數據同步到相應的Hbase表中，通過統一的服務接口為線上風控策略提供支持。

圖2

早期技術架構如圖2所示，但是隨著業務量的不斷擴張，現有的技術架構已不能滿足日益增長的業務需求，主要體現在以下兩點：

a) 無論是業務的創新速度還是對數據需求變化的速度都要遠遠超過數據工程師對特徵開發的速度；

b) 因為風控存在對抗性，因此用戶近幾分鐘、近幾秒的行為信息往往比很多離線特徵更具有價值，在線實時特徵必然會在策略系統中發揮越來越重要的作用。

在線實時特徵系統設計與實踐，對從整體功能上來講，在線實時特徵系統的設計主要考慮以下幾個方面：

a) 數據大，風控系統每天產生日誌量3TB左右，同時特徵系統還會接入發佈、瀏覽、登錄、註冊、聊天等數據。很多情況下同一份數據需要提取不同維度、不同指標的特徵，待處理的數量還會倍增。因此每天需要解析及計算的數量巨大。

b) 時效性高，面對龐大的數據量級，數據的處理實效性要求是秒級別，同時不能產生數據堆積的情況。

c) 併發大，風控策略系統面向用戶端，服務端峰值QPS超過35萬，每日調用量超過200億次。

d) 延遲低，面對用戶的請求，風控系統為了保持良好的用戶體驗，更快的完成對用戶准入條件的判斷，要求特徵系統接口的延遲在50ms以內。

實現一個簡化版本特徵系統可能只需要幾人日就可以完成，但是帶著以上幾個問題的同時還需要考慮在複雜的業務場景中應用，兼顧用戶的靈活配置、穩定的提供服務等情況下，卻需要一個團隊長期的業務積累和技術沉澱。

圖3

圖3為在線實時特徵系統的概貌，自底向上為數據流動的方向，各部分的功能如下：

a) 數據源：線上系統產生的數據，經過加工採集離線部分流入到離線數據倉庫（Hive）,實時數據源主要會推送到Kafka。

b) 物料提取：根據中控臺配置對原始數據進行解析，相應的維度提取，數據流削峰後流入計算層。

c) 特徵計算：該部分主要提供計算框架，生產特徵。

d) 特徵存儲：該部分提供在線特徵存、取能力，直接為上層應用提供統一的服務接口。

e) 特徵應用：線上風控、預警等，線下模型訓練樣本向量化。

特徵生產的生命週期可以抽象為提、算、存、用四個步驟，作為在線特徵系統的一體化解決方案。下文主要圍繞特徵系統的核心功能在開發過程中遇到的問題及解決辦法和一些通用的實踐經驗等展開介紹，如數據字典建設、分佈式系統設計、在線特徵計算框架、低延遲計算等主題會在下面文章中做詳細介紹。

1. 可靈活配置的特徵系統

構建在線的實時特徵系統的主要目的之一就是“提效”，因此至少90%以上的特徵計算由日常運營配置產出。那麼讓運營人員在日常工作中產生的特徵可配置的難點在於處理消息隊列中的實時數據無法獲取元數據及字段說明，在運營人員對日誌又不是十分了解的情況下手動錄入字段出錯率很高。

為了解決消息隊列數據無法獲取元數據問題，我們基於離線數據倉庫構建了“數據字典”，主要方案是定義了日誌打印標準，統一使用Json記錄日誌。日誌採集統一到Kafka中，其中Kafka有一個數據倉庫的消費者，將數據寫入數據倉庫中。當數據導入數據倉庫時，我們記錄了下字段名稱、字段更新時間，是否在擴展字段，通過Hive還可以獲取到字段的備註內容等。

另外還有一些字段需要二次解析、變形、轉置之後才能使用，但是又不能每次需要解析時而進行重新發版上線，因此這裡使用Groovy通過閉包的方式，把一些需要變換的邏輯抽象成一個一個的解析函數。

圖4

如圖4所示，在線上的應用場景中，同一個數據源一定也會生產出多個特徵，那麼這些特徵也會使用各種Groovy解析函數。在使用這些解析函數時，可以把這些待處理的特徵按照Groovy解析函數來排序，相同的解析函數直接使用上次解析的結果，從而避免重複加載而降低Cpu的資源開銷。

2. 大規模數據特徵提取

大規模數據直接會導致系統的併發量上升，同時也會對系統的吞吐量有較高的要求。當我們在解決高併發、高吞吐量時最直接有效的辦法就是增加機器資源，沒有之一。

圖5

關於特徵提取，正如圖5所示，針對同一個Topic的每個分區，我們都會有一個對應的節點來消費，這樣可以達到最大的並行處理速度。但是面對業務的增長，一個重度使用的數據源可能會慢慢的積累幾百個特徵配置，那麼這個數據源的每條數據也需要重複處理幾百次，因此這個數據源的Topic分區對應消費者節點的Cpu使用率也跟著直線上升，當Cpu使用率達到100%時就會消費延遲，分區數據積壓現象。

在排查分析原因是，根據一個節點會同時消費多個topic的其中一個分區，找了一個滿載節點粗略算了一下，數量大約在2W/s，當前這個數據源配置了600個特徵，那麼當前節點每秒需要處理1200W個特徵物料，因此結論就是數據太大機器負載過高，在單位時間內處理不完了。

我們都知道，Kafka Topic的分區數量決定了消費者並行度，因此最容易想到的解決方法就是擴分區，要不就是增大單節點內核。但是這裡會出現一個問題，業務會增長導致特徵數量也一定會再增長，而分區和內核數量卻都有上限，因此這種方案只是換湯不換藥。

針對以上問題解決辦法主要引進了分佈式設計的思路，將節點劃分為數據拉取節點（Spout）和數據處理節點（Worker），Spout會消費Kafka中的數據然後將數據序列化後發送到Worker。這麼做的目的是可以讓同一個分區的數據分散到不同的Worker節點處理，通過支持橫向擴展的方式使服務的整體可靠性和擴展性的到了提升。

圖6

使用了分佈式系統設計就需要考慮它的容錯機制，Kafka和使用的SCF框架本身具備容錯機制，但是以下兩點需要格外注意：

a) 在網絡繁忙或Worker節點負載過高時可能會導致Spout發送數據失敗，這時需要Spout具備故障自動轉移和負載輪詢功能。

b) 當數據到達Worker節點，Worker節點處理數據可能會失敗，也可能宕機。這時Spout會封裝Offset、iP、md5check為一個Tuple，Spout首先會將Tuple推送到延遲隊列，延遲時間為特徵配置的Timeout，然後向Worker節點發送序列化的Tuple。數據在Worker節點處理完成後會通過RPC調用Spout的ack方法，Spout會將當前消息從延遲隊列移除，否則延遲隊列會將消息發送回Spout讓其重新向Worker發送數據。

3. 在線特徵計算框架

我們前面提到過特徵的定義，那麼計算特徵值其實就是計算當前維度下單位時間內按照指定計算函數計算出來的值，因此相同維度的指標計算只需要考慮時間窗口和計算函數。我們在框架的設計上也考慮到了不同時間窗口的實現方式應該儘量跟計算函數解耦，可以抽象出各自的處理方式。根據現有的窗口類型和計算函數的組合，一共可以支持以下28種常見的特徵計算。

對於在線特徵計算框架核心計算邏輯主要由以下幾種算子實現：

a) 累加器：在Redis中維護最新的計算值，當產生新數據時進行累加操作，同時重置過期時間。過期時間可以根據窗口類型與當前時間準運算出Redis Key的到期時間。

b) 對比器：和累加器類似，區別在新產生的值和最大小值對比，在Redis中始終維護最大值和最小值。

c) 延遲隊列：遲隊列的作用是可以將數據延遲指定時間後重新發送回計算框架，當產生新數據時，會使用累加器加和到特徵值，同時將明細數據發送到延遲隊列。當計算框架收到延遲隊列返回的數據時，會使用累加器加和對應的負值。

d) 順序隊列：在隊列中維護一份明細數據， 隊列的原則是先進者先出，不允許插隊。

當產生新數據需要入隊時會有三個步驟：1）將當前數據放到隊列尾部，同時用時間戳作為當前數據的下標；2）檢查隊列頭部過期數據讓其出隊；3）計算隊列中的數據。

e) 集合：顧名思義，就是在Redis中維護一個集合，當有新數據產生時存入集合中後計算特徵值。

f) 列表：實現了一個緩存功能，將產生的數據原封不動的存儲在一個列表中，返回的值類型是一個List，其他算子返回的是一個dobule類型值。

在線特徵計算框架如果採用統一的工具暴力計算會耗費大量的存儲計算等資源，因此在計算框架的算子開發過程中，我們也按照不同的邏輯選擇了不同的開發工具，比如使用MapReduce解決天級別以上的高吞吐量計算，使用Spark Streaming做實時計算。想必我們的開發者對Spark Streaming的計算窗口、滑動步長等概念和它的一些其他特性都非常瞭解，開發起來也比較順手。但是針對在線的實時計算框架除了使用Spark Streaming之外還自己開發了一個計算模塊（TitanCounter簡稱TC），TC主要實現了文中提到的累加器、延遲隊列、順序隊列等計算功能。

圖7

為什麼還要自己開發一個計算模塊呢？如圖7所示，這裡有個時間軸，我的計算窗口是1小時，滑動步長是15分鐘，那麼使用SaprkStreaming將會每隔15分鐘計算1次最近1小時的值。如果有一個特徵查詢時間點是10:10，那麼我們當前系統只存儲了10:00的特徵值，10:15特徵值還沒有計算出來。因此對時間特別敏感的特徵應該採用TC的方式計算，圖8為TC設計的核心流程。

圖8

4. 低延時存儲設計

a) 資源隔離

考慮到特徵的存取延時要求極低，因此底層使用Redis分片集群。同時業務上有大有小、有核心業務也有一般業務，所以在分片集群上構建了一個資源隔離層，目的就是讓不同的場景特徵可以互不影響，同時還可以解決當Redis分片達到上限時仍然可以通過場景的方式擴容。

b) 鏡像快照

在資源隔離層下還構建了一個快照場景，快照場景主要是將Redis中的特徵值鏡像到快照場景中，快照場景底層使用Hbase存儲。當有離線模型需要訓練時，快照場景可以為歷史樣本提供秒級特徵補全，這樣可以對已完成人工審核的樣本數據重複利用而避免浪費人力重複審核樣本。

c) 極限存儲

海量數據不斷的加載到線上系統並在系統間流轉，對內存、網絡帶寬等資源都是不小的開銷。比如一個特徵是“最近12小時同用戶不同帖子內容數”，帖子內容本身可以很大，恰巧如果有用戶在瘋狂灌水，會導致隊列浪費大量資源。因此字符長度在超過固定長度後將會使用字符的md5值參與存儲和運算。還有一點就是針對隊列設定上限，如果當前風控策略設置不同帖子數量大於10將會對其做出處罰，那麼當前特徵計算的值達到11時就已經完成了它的使命。因此為了節省線上寶貴的存儲資源，隊列的裁剪不能完全依靠過期時間，還需要設定上限。

總結和規劃

本文主要以智能風控在線特徵系統為原型，提出了在線特徵系統的一些設計思路。其中特徵工程系統的邊界並不限於特徵的解析、計算、存取等。我們也經常會遇到像計算“截止到當前時刻最近n天用戶累計發送消息數量”等類似的特徵，顯著這個特徵最佳辦法是使用兩個特徵組合（離線計算n天、實時的自然窗口期特徵）更能夠有效的利用資源、還有諸如跟據特徵值的結果做一個（類似A、B、C、D）等級劃分等，像特徵的組合、變形、調度等都可看作為特徵系統的一部分延伸和擴展。同時我們的特徵系統也在需求與挑戰中不斷演進，也在試圖去構建特徵工程與知識譜的融合。因為在信息安全領域，挖掘用戶關係的關聯性是未來的趨勢，只有構建多元話信息集成才能將潛在風險識別出去。

作者簡介：

李文學：2017年3月加入58， 資深數據開發工程師， 目前擔任信息安全部數據方向負責人，專注於大數據應用架構。