攜程是如何把大數(shù)據(jù)用于實(shí)時(shí)風(fēng)控的?

攜程作為國內(nèi)OTA領(lǐng)頭羊，每天都遭受著嚴(yán)酷的欺詐風(fēng)險(xiǎn)，個(gè)人銀行卡被盜刷、賬號被盜用、營銷活動被惡意刷單、惡意搶占資源等。

目前攜程利用自主研發(fā)的風(fēng)控系統(tǒng)有效識別、防范這些風(fēng)險(xiǎn)。攜程風(fēng)控系統(tǒng)從零起步，經(jīng)過五年的不斷探索與創(chuàng)新，已經(jīng)可以有效覆蓋事前、事中、事后各個(gè)環(huán)節(jié)。也從原來基于“簡單規(guī)則+DB”，發(fā)展到目前能夠支撐10X交易增長的智能化風(fēng)控系統(tǒng)，基于規(guī)則引擎、實(shí)時(shí)模型計(jì)算、流式處理、M/R、大數(shù)據(jù)、數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)等的風(fēng)控系統(tǒng)，擁有實(shí)時(shí)、準(zhǔn)實(shí)時(shí)的風(fēng)險(xiǎn)決策、數(shù)據(jù)分析能力。

一、Aegis系統(tǒng)體系

圖1

主要分三大模塊：風(fēng)控引擎、數(shù)據(jù)服務(wù)、數(shù)據(jù)運(yùn)算、輔助系統(tǒng)。

風(fēng)控引擎：主要處理風(fēng)控請求，有預(yù)處理、規(guī)則引擎和模型執(zhí)行服務(wù)，風(fēng)控引擎所需要的數(shù)據(jù)是由數(shù)據(jù)服務(wù)模塊提供的。

數(shù)據(jù)服務(wù)：主要有實(shí)時(shí)流量統(tǒng)計(jì)、風(fēng)險(xiǎn)畫像、行為設(shè)備數(shù)據(jù)、外部數(shù)據(jù)訪問代理，RiskGraph。數(shù)據(jù)訪問層所提供的數(shù)據(jù)都是由數(shù)據(jù)計(jì)算層提供

數(shù)據(jù)運(yùn)算：主要包括風(fēng)險(xiǎn)畫像運(yùn)算、RiskSession、設(shè)備指紋、以及實(shí)時(shí)流量、非實(shí)時(shí)運(yùn)算。

數(shù)據(jù)運(yùn)算所需的數(shù)據(jù)來源主要是：風(fēng)控Event數(shù)據(jù)(訂單數(shù)據(jù)、支付數(shù)據(jù))，各個(gè)系統(tǒng)采集來的 UBT、設(shè)備指紋、日志數(shù)據(jù)等等。

除了這些，風(fēng)控平臺還有非常完善的監(jiān)控預(yù)警系統(tǒng)，人工審核平臺以及 報(bào)表系統(tǒng)。

二、Aegis系統(tǒng)架構(gòu)

圖2

三、規(guī)則引擎

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

由于攜程的業(yè)務(wù)種類非常多，而且每種業(yè)務(wù)都有其特性，在進(jìn)入風(fēng)控系統(tǒng)(Aegis)后，為了便于整個(gè)風(fēng)控系統(tǒng)對數(shù)據(jù)進(jìn)行處理，風(fēng)控前端有一個(gè)適配器模塊，把各個(gè)業(yè)務(wù)的數(shù)據(jù)都按照風(fēng)控內(nèi)部標(biāo)準(zhǔn)化配置進(jìn)行轉(zhuǎn)換，以適合風(fēng)控系統(tǒng)使用。

在完成數(shù)據(jù)適配后。風(fēng)控系統(tǒng)要進(jìn)行數(shù)據(jù)的合并。

舉個(gè)例子，當(dāng)有一筆支付風(fēng)控校驗(yàn)，支付BU只拋過來支付信息(支付金額、支付方式、訂單號等)。但是不包含訂單信息，這個(gè)時(shí)候就必須根據(jù)支付信息快速的查找到訂單信息，并把這兩個(gè)數(shù)據(jù)進(jìn)行合并，以便規(guī)則、模型使用。大家知道，用戶從生成訂單到發(fā)起支付，其時(shí)間間隔從秒到天都有可能，當(dāng)間隔時(shí)間短的時(shí)候，就會發(fā)生要合并的數(shù)據(jù)還沒有處理完，所以訂單數(shù)據(jù)從處理到落地要非常快。第二部就是要快速查找到訂單數(shù)據(jù)，我們?yōu)橛唵涡畔⒏鶕?jù)生成 RiskGraph，可以快速精確定位到所需要的訂單明細(xì)數(shù)據(jù)。

預(yù)處理在完成數(shù)據(jù)合并后，就開始準(zhǔn)備規(guī)則、模型所需要的變量、tag數(shù)據(jù)，在準(zhǔn)備數(shù)據(jù)時(shí)，預(yù)處理模塊會依賴后面我們要講解的數(shù)據(jù)服務(wù)層。當(dāng)然，為了提高性能，我們?yōu)樽兞?、tag的數(shù)據(jù)合理安排，優(yōu)先獲取關(guān)鍵規(guī)則、模型所需要的變量、tag的數(shù)據(jù)。

大家知道，欺詐分子的特點(diǎn)就是一波一波的，風(fēng)控系統(tǒng)需要能夠及時(shí)響應(yīng)，當(dāng)發(fā)現(xiàn)欺詐行為后，能及時(shí)上規(guī)則防止后續(xù)類似的欺詐行為。所以，制定規(guī)則需要快速、準(zhǔn)確，既然這樣，那么就需要我們的規(guī)則能夠快速上線，而且規(guī)則人員自己就可以制定規(guī)則并上線。還有就是規(guī)則與執(zhí)行規(guī)則的引擎比較做到有效隔離，不能因?yàn)橐?guī)則的不合理，影響到整個(gè)引擎。那么規(guī)則引擎就必須符合這些條件。

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

這樣攜程風(fēng)控引擎 ，實(shí)現(xiàn)了 規(guī)則 上線的高效攜程風(fēng)控實(shí)時(shí)引擎 通過使用 規(guī)則引擎Drools，使其具有非常高的靈活性、可配置性，并且由于是java語法的，規(guī)則人員自己就可以制定規(guī)則并迅速上線。

由于每個(gè)風(fēng)控Event請求，都需要執(zhí)行數(shù)百個(gè)規(guī)則，以及模型，這時(shí)，風(fēng)控引擎引入了規(guī)則執(zhí)行路徑優(yōu)化方法。建立起并行+串行，依賴關(guān)系+非依賴關(guān)系的規(guī)則執(zhí)行優(yōu)化方法，然后再引入短路機(jī)制，使上千個(gè)規(guī)則的運(yùn)行時(shí)間控制在100ms。

圖3

規(guī)則的靈活性非常強(qiáng)，制定、上線非?？?，但是單個(gè)規(guī)則的覆蓋率比較低，如果要增加覆蓋率就需要非常多的規(guī)則來進(jìn)行覆蓋，這個(gè)時(shí)候規(guī)則的維護(hù)成本就會很高，那么這個(gè)時(shí)候就需要使用模型了，模型的特點(diǎn)就是覆蓋率覆蓋率可以做到比較高，其模型邏輯可以非常復(fù)雜，但是其需要對其進(jìn)行線下訓(xùn)練，所以攜程風(fēng)控系統(tǒng)利用了規(guī)則、模型的各自特點(diǎn)進(jìn)行互補(bǔ)。

在目前的風(fēng)控系統(tǒng)中主要使用了：Logistic Regression、Random Forest。兩個(gè)算法使用下來，目前情況為：LR訓(xùn)練變量區(qū)分度足夠好的情況下，加以特征工程效果比較好。RF當(dāng)變量線性區(qū)分能力較弱的時(shí)候，效率比較高。所以使用RF的比例比較多。

四、數(shù)據(jù)服務(wù)層

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

數(shù)據(jù)服務(wù)層的核心思想就是充分利用內(nèi)存(本地、Redis)

1、本地內(nèi)存(大量固定數(shù)據(jù)，如ip所在地、城市信息等)

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

由于實(shí)時(shí)數(shù)據(jù)流量服務(wù)、風(fēng)險(xiǎn)畫像數(shù)據(jù)服務(wù)的數(shù)據(jù)是直接存儲在Redis中，其性能能夠滿足規(guī)則引擎的要求，我們這里重點(diǎn)介紹一下數(shù)據(jù)訪問代理服務(wù)。

數(shù)據(jù)訪問代理服務(wù)，其最重要的思想就是該數(shù)據(jù)被規(guī)則調(diào)用前先調(diào)用第三方的服務(wù)，把數(shù)據(jù)保存到Redis中，這樣當(dāng)規(guī)則請求來請求的時(shí)候，就能夠直接從Redis中讀取，既然做到了預(yù)加載，那么其數(shù)據(jù)的新鮮度及命中率就非常重要。

我們以用戶相關(guān)維度的數(shù)據(jù)為例，風(fēng)控系統(tǒng)通過對用戶日志的分析，可以偵測到哪些用戶有登陸、瀏覽、預(yù)定的動作，這樣就可以預(yù)先把這些用戶相關(guān)的外部服務(wù)數(shù)據(jù)加載到Redis中，當(dāng)規(guī)則、模型讀取用戶維度的外部數(shù)據(jù)時(shí)，先直接在redis中讀取，如果不存在然后再訪問外部服務(wù)。

在某些場景下，我們還結(jié)合引入DB來做持久化，當(dāng)用戶某些信息發(fā)生變化的時(shí)候，公共服務(wù)會發(fā)送一個(gè)Message到Hermes，我們就訂閱該信息，當(dāng)知道該用戶的某些信息發(fā)生修改，我們就主動的去訪問外部服務(wù)獲取數(shù)據(jù)放入Redis中，由于風(fēng)控系統(tǒng)能夠知道這些數(shù)據(jù)發(fā)生變化的Message，所以這些數(shù)據(jù)被持久化到DB中也是ok的，當(dāng)然，這些數(shù)據(jù)也有一個(gè)TTL參數(shù)來保證其新鮮度。

在這種場景下，系統(tǒng)在Redis沒有命中的情況下，先到DB中查找，兩個(gè)地方都不存在滿足條件的數(shù)據(jù)時(shí)，才會訪問外部服務(wù)，這個(gè)時(shí)候，其性能、存儲空間就可以得到優(yōu)化。

五、Chloro系統(tǒng)

Chloro系統(tǒng)是數(shù)據(jù)分析服務(wù)也是整個(gè)風(fēng)控系統(tǒng)的核心，數(shù)據(jù)服務(wù)層所使用到的數(shù)據(jù)，都是由Chloro系統(tǒng)計(jì)算后提供的。

主要分析維度主要包括：用戶風(fēng)險(xiǎn)畫像，用戶社交關(guān)系網(wǎng)絡(luò)，交易風(fēng)險(xiǎn)行為特性模型，供應(yīng)商風(fēng)險(xiǎn)模型。

圖4

可以看到數(shù)據(jù)的來源主要有hermes、hadoop、以及前端拋過來的各種風(fēng)控Event數(shù)據(jù)。Listener是用來接收各類數(shù)據(jù)，然后數(shù)據(jù)就會進(jìn)入 CountServer 和 Real-Time Process系統(tǒng)，其中和RiskSession的數(shù)據(jù)就先進(jìn)入Sessionizer ，該模塊可以快速進(jìn)行歸約Session處理，根據(jù)不同的key歸約成一個(gè)session，然后再提交給 實(shí)時(shí)處理系統(tǒng)進(jìn)行處理。

當(dāng)Real Time Process 和 CountServer對數(shù)據(jù)處理好后，這個(gè)時(shí)候分成了兩部分?jǐn)?shù)據(jù)，一部分是處理的結(jié)果，還有一份是原數(shù)據(jù)，都會提交給Data Dispatcher，由它進(jìn)行Chloro系統(tǒng)內(nèi)部的數(shù)據(jù)路由，結(jié)果會直接進(jìn)入到RiskProfile提供給引擎和模型使用。而原始數(shù)據(jù)會寫入到Hadoop集群。

Batch Process就利用Hadoop集群的大數(shù)據(jù)處理能力，對離線數(shù)據(jù)進(jìn)行處理，當(dāng)Batch Process處理好后，也會把處理結(jié)果發(fā)送給Data Dispatcher，由它進(jìn)行數(shù)據(jù)路由。

Batch Process還可以做跨Rsession之間的數(shù)據(jù)分析。

圖5

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

風(fēng)控系統(tǒng)通過比較用戶信息：Uid, 手機(jī)號, 郵箱，設(shè)備信息：Fp(Fingerprint), clientId, vid, v, deviceId來判斷其是否是同一個(gè)用戶，通過其行為信息：瀏覽軌跡, 歷史軌跡來判斷其行為相似度。

比如：用戶在PC端下單、然后在手機(jī)APP里完成支付，這個(gè)對于Chloro是一個(gè)會話，這個(gè)會話我們稱之為風(fēng)控Session，通過Risksession的定義，風(fēng)控系統(tǒng)使用戶的行為可以量化，也可以刻畫。這樣Risksession實(shí)際上可以作為用戶行為的一個(gè) Container。使用RiskSession就可以做到跨平臺，更加有利于分析用戶特征。

圖6

Risk Graph 是根據(jù)攜程風(fēng)控系統(tǒng)的特點(diǎn)開發(fā)出來的，Risk Graph是一個(gè)基于HBase進(jìn)行為存儲介質(zhì)的系統(tǒng)，比如，以用戶為節(jié)點(diǎn)其值就是HBase用戶表的key，其每個(gè)列就是特性，然后根據(jù)用戶的某個(gè)特性再創(chuàng)建一個(gè)hbase表，這樣就創(chuàng)建了一個(gè)基于HBase的類Graph的架構(gòu)。

所以該系統(tǒng)的一個(gè)核心思想是先創(chuàng)建各個(gè)維度的數(shù)據(jù)索引，然后根據(jù)索引值再進(jìn)行內(nèi)容的查找。目前風(fēng)控系統(tǒng)已經(jīng)創(chuàng)建了十幾個(gè)維度的快速索引。

六、Aegis其它子系統(tǒng)

圖7

Aegis還有配置系統(tǒng)，用戶可以在上面進(jìn)行各種配置，如規(guī)則、規(guī)則運(yùn)行路徑，標(biāo)準(zhǔn)化、tag、變量定義、已經(jīng)數(shù)據(jù)清洗業(yè)務(wù)羅輯等等，當(dāng)然監(jiān)控系統(tǒng)也是非常重要的，風(fēng)控研發(fā)秉承著監(jiān)控?zé)o處不在的設(shè)計(jì)理念，使其能夠在第一時(shí)間發(fā)現(xiàn)系統(tǒng)的任何細(xì)小變化。

七、展望

攜程風(fēng)控在3.0中通過引入規(guī)則引擎、在Chloro系統(tǒng)中大量使用開源的基于大數(shù)據(jù)處理的架構(gòu)，配合模型取得了非常好的效果，在4.0中，將在機(jī)器學(xué)習(xí)、人工智能、行為特征等方向繼續(xù)發(fā)力，進(jìn)一步提高風(fēng)控系統(tǒng)識別能力，對于技術(shù)將繼續(xù)擁抱開源技術(shù)，下一步會引入Spark等提高風(fēng)控系統(tǒng)的數(shù)據(jù)處理能力。