攜程是如何把大數據用於實時風控的

攜程作為國內OTA領頭羊，每天都遭受著嚴酷的欺詐風險，個人銀行卡被盜刷、賬號被盜用、營銷活動被惡意刷單、惡意搶佔資源等。

目前攜程利用自主研發的風控系統有效識別、防範這些風險。攜程風控系統從零起步，經過五年的不斷探索與創新，已經可以有效覆蓋事前、事中、事後各個環節。也從原來基於「簡單規則+DB」，發展到目前能夠支撐10X交易增長的智能化風控系統，基於規則引擎、實時模型計算、流式處理、M/R、大數據、數據挖掘、機器學習等的風控系統，擁有實時、准實時的風險決策、數據分析能力。

一、Aegis系統體系

主要分三大模塊：風控引擎、數據服務、數據運算、輔助系統。

風控引擎：主要處理風控請求，有預處理、規則引擎和模型執行服務，風控引擎所需要的數據是由數據服務模塊提供的。

數據服務：主要有實時流量統計、風險畫像、行為設備數據、外部數據訪問代理，RiskGraph。數據訪問層所提供的數據都是由數據計算層提供

數據運算：主要包括風險畫像運算、RiskSession、設備指紋、以及實時流量、非實時運算。

數據運算所需的數據來源主要是：風控Event數據（訂單數據、支付數據），各個系統採集來的nUBT、設備指紋、日誌數據等等。

除了這些，風控平台還有非常完善的監控預警系統，人工審核平台以及 報表系統。

二、Aegis系統架構

三、規則引擎

規則引擎包含3大功能，首先是適配層。

由於攜程的業務種類非常多，而且每種業務都有其特性，在進入風控系統（Aegis）後，為了便於整個風控系統對數據進行處理，風控前端有一個適配器模塊，把各個業務的數據都按照風控內部標準化配置進行轉換，以適合風控系統使用。

在完成數據適配後。風控系統要進行數據的合併。

舉個例子，當有一筆支付風控校驗，支付BU只拋過來支付信息（支付金額、支付方式、訂單號等）。但是不包含訂單信息，這個時候就必須根據支付信息快速的查找到訂單信息，並把這兩個數據進行合併，以便規則、模型使用。大家知道，用戶從生成訂單到發起支付，其時間間隔從秒到天都有可能，當間隔時間短的時候，就會發生要合併的數據還沒有處理完，所以訂單數據從處理到落地要非常快。第二部就是要快速查找到訂單數據，我們為訂單信息根據生成nRiskGraph，可以快速精確定位到所需要的訂單明細數據。

預處理在完成數據合併後，就開始準備規則、模型所需要的變數、tag數據，在準備數據時，預處理模塊會依賴後面我們要講解的數據服務層。當然，為了提高性能，我們為變數、tag的數據合理安排，優先獲取關鍵規則、模型所需要的變數、tag的數據。

大家知道，欺詐分子的特點就是一波一波的，風控系統需要能夠及時響應，當發現欺詐行為後，能及時上規則防止後續類似的欺詐行為。所以，制定規則需要快速、準確，既然這樣，那麼就需要我們的規則能夠快速上線，而且規則人員自己就可以制定規則並上線。還有就是規則與執行規則的引擎比較做到有效隔離，不能因為規則的不合理，影響到整個引擎。那麼規則引擎就必須符合這些條件。

我們最後選擇了開源nDrools，第一它是開源，第二它可以使用Java語言，入門方便，第三功能夠用

這樣攜程風控引擎 ，實現了 規則n上線的高效攜程風控實時引擎 通過使用 規則引擎Drools，使其具有非常高的靈活性、可配置性，並且由於是java語法的，規則人員自己就可以制定規則並迅速上線。

由於每個風控Event請求，都需要執行數百個規則，以及模型，這時，風控引擎引入了規則執行路徑優化方法。建立起並行+串列，依賴關係+非依賴關係的規則執行優化方法，然後再引入短路機制，使上千個規則的運行時間控制在100ms。

圖3

規則的靈活性非常強，制定、上線非常快，但是單個規則的覆蓋率比較低，如果要增加覆蓋率就需要非常多的規則來進行覆蓋，這個時候規則的維護成本就會很高，那麼這個時候就需要使用模型了，模型的特點就是覆蓋率覆蓋率可以做到比較高，其模型邏輯可以非常複雜，但是其需要對其進行線下訓練，所以攜程風控系統利用了規則、模型的各自特點進行互補。

在目前的風控系統中主要使用了：Logistic Regression、Random Forest。兩個演算法使用下來，目前情況為：LR訓練變數區分度足夠好的情況下，加以特徵工程效果比較好。RF當變數線性區分能力較弱的時候，效率比較高。所以使用RF的比例比較多。

四、數據服務層

數據服務層，主要功能就是提供數據服務，我們知道在風控引擎預處理需要獲取到非常多的變數和tag，這些變數和tag的數據都是由數據訪問層來提供的。該服務層的最重要的目的就是響應快。所以在數據服務層主要使用Redis作為數據緩存區，重要、高頻數據直接使用Redis作為持久層來使用。

數據服務層的核心思想就是充分利用內存（本地、Redis）

1、本地內存（大量固定數據，如ip所在地、城市信息等）

2、充分利用Redis高性能緩存

由於實時數據流量服務、風險畫像數據服務的數據是直接存儲在Redis中，其性能能夠滿足規則引擎的要求，我們這裡重點介紹一下數據訪問代理服務。

數據訪問代理服務，其最重要的思想就是該數據被規則調用前先調用第三方的服務，把數據保存到Redis中，這樣當規則請求來請求的時候，就能夠直接從Redis中讀取，既然做到了預載入，那麼其數據的新鮮度及命中率就非常重要。我們以用戶相關維度的數據為例，風控系統通過對用戶日誌的分析，可以偵測到哪些用戶有登陸、瀏覽、預定的動作，這樣就可以預先把這些用戶相關的外部服務數據載入到Redis中，當規則、模型讀取用戶維度的外部數據時，先直接在redis中讀取，如果不存在然後再訪問外部服務。

在某些場景下，我們還結合引入DB來做持久化，當用戶某些信息發生變化的時候，公共服務會發送一個Message到Hermes，我們就訂閱該信息，當知道該用戶的某些信息發生修改，我們就主動的去訪問外部服務獲取數據放入Redis中，由於風控系統能夠知道這些數據發生變化的Message，所以這些數據被持久化到DB中也是ok的，當然，這些數據也有一個TTL參數來保證其新鮮度。在這種場景下，系統在Redis沒有命中的情況下，先到DB中查找，兩個地方都不存在滿足條件的數據時，才會訪問外部服務，這個時候，其性能、存儲空間就可以得到優化。

五、Chloro系統

Chloro系統是數據分析服務也是整個風控系統的核心，數據服務層所使用到的數據，都是由Chloro系統計算後提供的。

主要分析維度主要包括：用戶風險畫像，用戶社交關係網路，交易風險行為特性模型，供應商風險模型。

可以看到數據的來源主要有hermes、hadoop、以及前端拋過來的各種風控Event數據。Listener是用來接收各類數據，然後數據就會進入 CountServer 和 Real-Time Process系統，其中和RiskSession的數據就先進入Sessionizer ，該模塊可以快速進行歸約Session處理，根據不同的key歸約成一個session，然後再提交給 實時處理系統進行處理。當Real Time Processn和 CountServer對數據處理好後，這個時候分成了兩部分數據，一部分是處理的結果，還有一份是原數據，都會提交給Data Dispatcher，由它進行Chloro系統內部的數據路由，結果會直接進入到RiskProfile提供給引擎和模型使用。而原始數據會寫入到Hadoop集群。

Batch Process就利用Hadoop集群的大數據處理能力，對離線數據進行處理，當Batch Process處理好後，也會把處理結果發送給Data Dispatcher，由它進行數據路由。

Batch Process還可以做跨Rsession之間的數據分析。

圖5

RiskSession的定義：量化、刻畫 用戶的行為，任何人通過任何設備訪問攜程的第一個event開始，我們認為Rsession start了，到他離開的最後一個event後30分鐘之內沒有任何痕迹留下，我們認為Rsession end。

風控系統通過比較用戶信息：Uid, 手機號, 郵箱，設備信息：Fp（Fingerprint）, clientId, vid, v, deviceId來判斷其是否是同一個用戶，通過其行為信息：瀏覽軌跡, 歷史軌跡來判斷其行為相似度。

比如：用戶在PC端下單、然後在手機APP里完成支付，這個對於Chloro是一個會話，這個會話我們稱之為風控Session，通過Risksession的定義，風控系統使用戶的行為可以量化，也可以刻畫。這樣Risksession實際上可以作為用戶行為的一個nContainer。使用RiskSession就可以做到跨平台，更加有利於分析用戶特徵。

圖6

Risk Graph 是根據攜程風控系統的特點開發出來的，Risk Graph是一個基於HBase進行為存儲介質的系統，比如，以用戶為節點其值就是HBase用戶表的key，其每個列就是特性，然後根據用戶的某個特性再創建一個hbase表，這樣就創建了一個基於HBase的類Graph的架構。

所以該系統的一個核心思想是先創建各個維度的數據索引，然後根據索引值再進行內容的查找。目前風控系統已經創建了十幾個維度的快速索引。

六、Aegis其它子系統

圖7

Aegis還有配置系統，用戶可以在上面進行各種配置，如規則、規則運行路徑，標準化、tag、變數定義、已經數據清洗業務羅輯等等，當然監控系統也是非常重要的，風控研發秉承著監控無處不在的設計理念，使其能夠在第一時間發現系統的任何細小變化。

七、展望

攜程風控在3.0中通過引入規則引擎、在Chloro系統中大量使用開源的基於大數據處理的架構，配合模型取得了非常好的效果，在4.0中，將在機器學習、人工智慧、行為特徵等方向繼續發力，進一步提高風控系統識別能力，對於技術將繼續擁抱開源技術，下一步會引入Spark等提高風控系統的數據處理能力。

【作者簡介】郁偉，攜程技術中心風險控制部高級開發經理。2010加入攜程，參與了攜程結算平台、風控系統的開發，對系統架構、流式數據處理等有比較深入的研究。

想和攜程小夥伴一起工作？風控團隊現開放職位（風控研發工程師、資深模型分析師等），感興趣小夥伴砸簡歷tech@ctrip.com。

沒看夠？更多來自攜程技術人的一手乾貨，歡迎關注攜程技術中心微信公號ctriptech哦~

推薦閱讀：