目前攜程利用自主研發(fā)的風控系統(tǒng)有效識別、防范這些風險。攜程風控系統(tǒng)從零起步，經(jīng)過五年的不斷探索與創(chuàng)新，已經(jīng)可以有效覆蓋事前、事中、事后各個環(huán)節(jié)。也從原來基于“簡單規(guī)則 +DB”，發(fā)展到目前能夠支撐 10X 交易增長的智能化風控系統(tǒng)，基于規(guī)則引擎、實時模型計算、流式處理、M/R、大數(shù)據(jù)、數(shù)據(jù)挖掘、機器學習等的風控系統(tǒng)，擁有實時、準實時的風險決策、數(shù)據(jù)分析能力。
一、Aegis 系統(tǒng)體系
主要分三大模塊：風控引擎、數(shù)據(jù)服務、數(shù)據(jù)運算、輔助系統(tǒng)。
風控引擎：主要處理風控請求，有預處理、規(guī)則引擎和模型執(zhí)行服務，風控引擎所需要的數(shù)據(jù)是由數(shù)據(jù)服務模塊提供的。數(shù)據(jù)服務：主要有實時流量統(tǒng)計、風險畫像、行為設備數(shù)據(jù)、外部數(shù)據(jù)訪問代理，RiskGraph。數(shù)據(jù)訪問層所提供的數(shù)據(jù)都是由數(shù)據(jù)計算層提供數(shù)據(jù)運算：主要包括風險畫像運算、RiskSession、設備指紋、以及實時流量、非實時運算。
數(shù)據(jù)運算所需的數(shù)據(jù)來源主要是：風控 Event 數(shù)據(jù)（訂單數(shù)據(jù)、支付數(shù)據(jù)），各個系統(tǒng)采集來的 UBT、設備指紋、日志數(shù)據(jù)等等。
除了這些，風控平臺還有非常完善的監(jiān)控預警系統(tǒng)，人工審核平臺以及 報表系統(tǒng)。
二、Aegis 系統(tǒng)架構(gòu)
三、規(guī)則引擎
規(guī)則引擎包含 3 大功能，首先是適配層。
由于攜程的業(yè)務種類非常多，而且每種業(yè)務都有其特性，在進入風控系統(tǒng)（Aegis）后，為了便于整個風控系統(tǒng)對數(shù)據(jù)進行處理，風控前端有一個適配器模塊，把各個業(yè)務的數(shù)據(jù)都按照風控內(nèi)部標準化配置進行轉(zhuǎn)換，以適合風控系統(tǒng)使用。
在完成數(shù)據(jù)適配后。風控系統(tǒng)要進行數(shù)據(jù)的合并。
舉個例子，當有一筆支付風控校驗，支付 BU 只拋過來支付信息（支付金額、支付方式、訂單號等）。但是不包含訂單信息，這個時候就必須根據(jù)支付信息快速的查找到訂單信息，并把這兩個數(shù)據(jù)進行合并，以便規(guī)則、模型使用。大家知道，用戶從生成訂單到發(fā)起支付，其時間間隔從秒到天都有可能，當間隔時間短的時候，就會發(fā)生要合并的數(shù)據(jù)還沒有處理完，所以訂單數(shù)據(jù)從處理到落地要非常快。第二部就是要快速查找到訂單數(shù)據(jù)，我們?yōu)橛唵涡畔⒏鶕?jù)生成 RiskGraph，可以快速精確定位到所需要的訂單明細數(shù)據(jù)。
預處理在完成數(shù)據(jù)合并后，就開始準備規(guī)則、模型所需要的變量、tag 數(shù)據(jù)，在準備數(shù)據(jù)時，預處理模塊會依賴后面我們要講解的數(shù)據(jù)服務層。當然，為了提高性能，我們?yōu)樽兞俊ag 的數(shù)據(jù)合理安排，優(yōu)先獲取關(guān)鍵規(guī)則、模型所需要的變量、tag 的數(shù)據(jù)。
大家知道，欺詐分子的特點就是一波一波的，風控系統(tǒng)需要能夠及時響應，當發(fā)現(xiàn)欺詐行為后，能及時上規(guī)則防止后續(xù)類似的欺詐行為。所以，制定規(guī)則需要快速、準確，既然這樣，那么就需要我們的規(guī)則能夠快速上線，而且規(guī)則人員自己就可以制定規(guī)則并上線。還有就是規(guī)則與執(zhí)行規(guī)則的引擎比較做到有效隔離，不能因為規(guī)則的不合理，影響到整個引擎。那么規(guī)則引擎就必須符合這些條件。
我們最后選擇了開源 Drools，第一它是開源，第二它可以使用 JAVA 語言，入門方便，第三功能夠用。
這樣攜程風控引擎 ，實現(xiàn)了 規(guī)則上線的高效攜程風控實時引擎 通過使用 規(guī)則引擎 Drools，使其具有非常高的靈活性、可配置性，并且由于是 java 語法的，規(guī)則人員自己就可以制定規(guī)則并迅速上線。
由于每個風控 Event 請求，都需要執(zhí)行數(shù)百個規(guī)則，以及模型，這時，風控引擎引入了規(guī)則執(zhí)行路徑優(yōu)化方法。建立起并行 + 串行，依賴關(guān)系 + 非依賴關(guān)系的規(guī)則執(zhí)行優(yōu)化方法，然后再引入短路機制，使上千個規(guī)則的運行時間控制在 100ms。
規(guī)則的靈活性非常強，制定、上線非常快，但是單個規(guī)則的覆蓋率比較低，如果要增加覆蓋率就需要非常多的規(guī)則來進行覆蓋，這個時候規(guī)則的維護成本就會很高，那么這個時候就需要使用模型了，模型的特點就是覆蓋率覆蓋率可以做到比較高，其模型邏輯可以非常復雜，但是其需要對其進行線下訓練，所以攜程風控系統(tǒng)利用了規(guī)則、模型的各自特點進行互補。
在目前的風控系統(tǒng)中主要使用了：Logistic Regression、Random Forest。兩個算法使用下來，目前情況為：LR 訓練變量區(qū)分度足夠好的情況下，加以特征工程效果比較好。RF 當變量線性區(qū)分能力較弱的時候，效率比較高。所以使用 RF 的比例比較多。
四、數(shù)據(jù)服務層
數(shù)據(jù)服務層，主要功能就是提供數(shù)據(jù)服務，我們知道在風控引擎預處理需要獲取到非常多的變量和 tag，這些變量和 tag 的數(shù)據(jù)都是由數(shù)據(jù)訪問層來提供的。該服務層的最重要的目的就是響應快。所以在數(shù)據(jù)服務層主要使用 redis 作為數(shù)據(jù)緩存區(qū)，重要、高頻數(shù)據(jù)直接使用 Redis 作為持久層來使用。
數(shù)據(jù)服務層的核心思想就是充分利用內(nèi)存（本地、Redis）1、本地內(nèi)存（大量固定數(shù)據(jù)，如 ip 所在地、城市信息等）2、充分利用 Redis 高性能緩存
由于實時數(shù)據(jù)流量服務、風險畫像數(shù)據(jù)服務的數(shù)據(jù)是直接存儲在 Redis 中，其性能能夠滿足規(guī)則引擎的要求，我們這里重點介紹一下數(shù)據(jù)訪問代理服務。
數(shù)據(jù)訪問代理服務，其最重要的思想就是該數(shù)據(jù)被規(guī)則調(diào)用前先調(diào)用第三方的服務，把數(shù)據(jù)保存到 Redis 中，這樣當規(guī)則請求來請求的時候，就能夠直接從 Redis 中讀取，既然做到了預加載，那么其數(shù)據(jù)的新鮮度及命中率就非常重要。我們以用戶相關(guān)維度的數(shù)據(jù)為例，風控系統(tǒng)通過對用戶日志的分析，可以偵測到哪些用戶有登陸、瀏覽、預定的動作，這樣就可以預先把這些用戶相關(guān)的外部服務數(shù)據(jù)加載到 Redis 中，當規(guī)則、模型讀取用戶維度的外部數(shù)據(jù)時，先直接在 redis 中讀取，如果不存在然后再訪問外部服務。
在某些場景下，我們還結(jié)合引入 DB 來做持久化，當用戶某些信息發(fā)生變化的時候，公共服務會發(fā)送一個 Message 到 Hermes，我們就訂閱該信息，當知道該用戶的某些信息發(fā)生修改，我們就主動的去訪問外部服務獲取數(shù)據(jù)放入 Redis 中，由于風控系統(tǒng)能夠知道這些數(shù)據(jù)發(fā)生變化的 Message，所以這些數(shù)據(jù)被持久化到 DB 中也是 ok 的，當然，這些數(shù)據(jù)也有一個 TTL 參數(shù)來保證其新鮮度。在這種場景下，系統(tǒng)在 Redis 沒有命中的情況下，先到 DB 中查找，兩個地方都不存在滿足條件的數(shù)據(jù)時，才會訪問外部服務，這個時候，其性能、存儲空間就可以得到優(yōu)化。
五、Chloro 系統(tǒng)
Chloro 系統(tǒng)是數(shù)據(jù)分析服務也是整個風控系統(tǒng)的核心，數(shù)據(jù)服務層所使用到的數(shù)據(jù)，都是由 Chloro 系統(tǒng)計算后提供的。
主要分析維度主要包括：用戶風險畫像，用戶社交關(guān)系網(wǎng)絡，交易風險行為特性模型，供應商風險模型。
可以看到數(shù)據(jù)的來源主要有 hermes、hadoop、以及前端拋過來的各種風控 Event 數(shù)據(jù)。Listener 是用來接收各類數(shù)據(jù)，然后數(shù)據(jù)就會進入 CountServer 和 Real-Time Process 系統(tǒng)，其中和 RiskSession 的數(shù)據(jù)就先進入 Sessionizer ，該模塊可以快速進行歸約 Session 處理，根據(jù)不同的 key 歸約成一個 session，然后再提交給 實時處理系統(tǒng)進行處理。當 Real Time Process 和 CountServer 對數(shù)據(jù)處理好后，這個時候分成了兩部分數(shù)據(jù)，一部分是處理的結(jié)果，還有一份是原數(shù)據(jù)，都會提交給 Data Dispatcher，由它進行 Chloro 系統(tǒng)內(nèi)部的數(shù)據(jù)路由，結(jié)果會直接進入到 RiskProfile 提供給引擎和模型使用。而原始數(shù)據(jù)會寫入到 Hadoop 集群。
Batch Process 就利用 Hadoop 集群的大數(shù)據(jù)處理能力，對離線數(shù)據(jù)進行處理，當 Batch Process 處理好后，也會把處理結(jié)果發(fā)送給 Data Dispatcher，由它進行數(shù)據(jù)路由。
Batch Process 還可以做跨 Rsession 之間的數(shù)據(jù)分析。
RiskSession 的定義：量化、刻畫 用戶的行為，任何人通過任何設備訪問攜程的第一個 event 開始，我們認為 Rsession start 了，到他離開的最后一個 event 后 30 分鐘之內(nèi)沒有任何痕跡留下，我們認為 Rsession end。
風控系統(tǒng)通過比較用戶信息：Uid, 手機號, 郵箱，設備信息：
Fp（Fingerprint）, clientId, vid, v, deviceId 來判斷其是否是同一個用戶，通過其行為信息：瀏覽軌跡, 歷史軌跡來判斷其行為相似度。
比如：用戶在 PC 端下單、然后在手機 App 里完成支付，這個對于 Chloro 是一個會話，這個會話我們稱之為風控 Session，通過 Risksession 的定義，風控系統(tǒng)使用戶的行為可以量化，也可以刻畫。這樣 Risksession 實際上可以作為用戶行為的一個 Container。使用 RiskSession 就可以做到跨平臺，更加有利于分析用戶特征。
Risk Graph 是根據(jù)攜程風控系統(tǒng)的特點開發(fā)出來的，Risk Graph 是一個基于 HBase 進行為存儲介質(zhì)的系統(tǒng)，比如，以用戶為節(jié)點其值就是 HBase 用戶表的 key，其每個列就是特性，然后根據(jù)用戶的某個特性再創(chuàng)建一個 hbase 表，這樣就創(chuàng)建了一個基于 HBase 的類 Graph 的架構(gòu)。
所以該系統(tǒng)的一個核心思想是先創(chuàng)建各個維度的數(shù)據(jù)索引，然后根據(jù)索引值再進行內(nèi)容的查找。目前風控系統(tǒng)已經(jīng)創(chuàng)建了十幾個維度的快速索引。
六、Aegis 其它子系統(tǒng)
Aegis 還有配置系統(tǒng)，用戶可以在上面進行各種配置，如規(guī)則、規(guī)則運行路徑，標準化、tag、變量定義、已經(jīng)數(shù)據(jù)清洗業(yè)務羅輯等等，當然監(jiān)控系統(tǒng)也是非常重要的，風控研發(fā)秉承著監(jiān)控無處不在的設計理念，使其能夠在第一時間發(fā)現(xiàn)系統(tǒng)的任何細小變化。
