帶你去看，攜程如何利用大資料實時風控
目前攜程利用自主研發的風控系統有效識別、防範這些風險。攜程風控系統從零起步，經過五年的不斷探索與創新，已經可以有效覆蓋事前、事中、事後各個環節。也從原來基於“簡單規則 +DB”，發展到目前能夠支撐 10X 交易增長的智慧化風控系統，基於規則引擎、實時模型計算、流式處理、M/R、大資料、資料探勘、機器學習等的風控系統，擁有實時、準實時的風險決策、資料分析能力。
一、Aegis 系統體系
主要分三大模組：風控引擎、資料服務、資料運算、輔助系統。
風控引擎：主要處理風控請求，有預處理、規則引擎和模型執行服務，風控引擎所需要的資料是由資料服務模組提供的。資料服務：主要有實時流量統計、風險畫像、行為裝置資料、外部資料訪問代理，RiskGraph。資料訪問層所提供的資料都是由資料計算層提供資料運算：主要包括風險畫像運算、RiskSession、裝置指紋、以及實時流量、非實時運算。
資料運算所需的資料來源主要是：風控 Event 資料（訂單資料、支付資料），各個系統採集來的 UBT、裝置指紋、日誌資料等等。
除了這些，風控平臺還有非常完善的監控預警系統，人工稽核平臺以及 報表系統。
二、Aegis 系統架構
三、規則引擎
規則引擎包含 3 大功能，首先是適配層。
由於攜程的業務種類非常多，而且每種業務都有其特性，在進入風控系統（Aegis）後，為了便於整個風控系統對資料進行處理，風控前端有一個介面卡模組，把各個業務的資料都按照風控內部標準化配置進行轉換，以適合風控系統使用。
在完成資料適配後。風控系統要進行資料的合併。
舉個例子，當有一筆支付風控校驗，支付 BU 只拋過來支付資訊（支付金額、支付方式、訂單號等）。但是不包含訂單資訊，這個時候就必須根據支付資訊快速的查詢到訂單資訊，並把這兩個資料進行合併，以便規則、模型使用。大家知道，使用者從生成訂單到發起支付，其時間間隔從秒到天都有可能，當間隔時間短的時候，就會發生要合併的資料還沒有處理完，所以訂單資料從處理到落地要非常快。第二部就是要快速查詢到訂單資料，我們為訂單資訊根據生成 RiskGraph，可以快速精確定位到所需要的訂單明細資料。
預處理在完成資料合併後，就開始準備規則、模型所需要的變數、tag 資料，在準備資料時，預處理模組會依賴後面我們要講解的資料服務層。當然，為了提高效能，我們為變數、tag 的資料合理安排，優先獲取關鍵規則、模型所需要的變數、tag 的資料。
大家知道，欺詐分子的特點就是一波一波的，風控系統需要能夠及時響應，當發現欺詐行為後，能及時上規則防止後續類似的欺詐行為。所以，制定規則需要快速、準確，既然這樣，那麼就需要我們的規則能夠快速上線，而且規則人員自己就可以制定規則並上線。還有就是規則與執行規則的引擎比較做到有效隔離，不能因為規則的不合理，影響到整個引擎。那麼規則引擎就必須符合這些條件。
我們最後選擇了開源 Drools，第一它是開源，第二它可以使用 Java 語言，入門方便，第三功能夠用。
這樣攜程風控引擎 ，實現了 規則上線的高效攜程風控實時引擎 透過使用 規則引擎 Drools，使其具有非常高的靈活性、可配置性，並且由於是 java 語法的，規則人員自己就可以制定規則並迅速上線。
由於每個風控 Event 請求，都需要執行數百個規則，以及模型，這時，風控引擎引入了規則執行路徑最佳化方法。建立起並行 + 序列，依賴關係 + 非依賴關係的規則執行最佳化方法，然後再引入短路機制，使上千個規則的執行時間控制在 100ms。
規則的靈活性非常強，制定、上線非常快，但是單個規則的覆蓋率比較低，如果要增加覆蓋率就需要非常多的規則來進行覆蓋，這個時候規則的維護成本就會很高，那麼這個時候就需要使用模型了，模型的特點就是覆蓋率覆蓋率可以做到比較高，其模型邏輯可以非常複雜，但是其需要對其進行線下訓練，所以攜程風控系統利用了規則、模型的各自特點進行互補。
在目前的風控系統中主要使用了：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 Process 和 CountServer 對資料處理好後，這個時候分成了兩部分資料，一部分是處理的結果，還有一份是原資料，都會提交給 Data Dispatcher，由它進行 Chloro 系統內部的資料路由，結果會直接進入到 RiskProfile 提供給引擎和模型使用。而原始資料會寫入到 Hadoop 叢集。
Batch Process 就利用 Hadoop 叢集的大資料處理能力，對離線資料進行處理，當 Batch Process 處理好後，也會把處理結果傳送給 Data Dispatcher，由它進行資料路由。
Batch Process 還可以做跨 Rsession 之間的資料分析。
RiskSession 的定義：量化、刻畫 使用者的行為，任何人透過任何裝置訪問攜程的第一個 event 開始，我們認為 Rsession start 了，到他離開的最後一個 event 後 30 分鐘之內沒有任何痕跡留下，我們認為 Rsession end。
風控系統透過比較使用者資訊：Uid， 手機號， 郵箱，裝置資訊：
Fp（Fingerprint）， clientId， vid， v， deviceId 來判斷其是否是同一個使用者，透過其行為資訊：瀏覽軌跡， 歷史軌跡來判斷其行為相似度。
比如：使用者在 PC 端下單、然後在手機 APP 裡完成支付，這個對於 Chloro 是一個會話，這個會話我們稱之為風控 Session，透過 Risksession 的定義，風控系統使使用者的行為可以量化，也可以刻畫。這樣 Risksession 實際上可以作為使用者行為的一個 Container。使用 RiskSession 就可以做到跨平臺，更加有利於分析使用者特徵。
Risk Graph 是根據攜程風控系統的特點開發出來的，Risk Graph 是一個基於 HBase 進行為儲存介質的系統，比如，以使用者為節點其值就是 HBase 使用者表的 key，其每個列就是特性，然後根據使用者的某個特性再建立一個 hbase 表，這樣就建立了一個基於 HBase 的類 Graph 的架構。
所以該系統的一個核心思想是先建立各個維度的資料索引，然後根據索引值再進行內容的查詢。目前風控系統已經建立了十幾個維度的快速索引。
六、Aegis 其它子系統
Aegis 還有配置系統，使用者可以在上面進行各種配置，如規則、規則執行路徑，標準化、tag、變數定義、已經資料清洗業務羅輯等等，當然監控系統也是非常重要的，風控研發秉承著監控無處不在的設計理念，使其能夠在第一時間發現系統的任何細小變化。
