阿里風控大腦關于大數(shù)據(jù)應用的探索與實踐,大數(shù)據(jù)風控框架-ESG跨境

阿里風控大腦關于大數(shù)據(jù)應用的探索與實踐,大數(shù)據(jù)風控框架

阿里風控大腦關于大數(shù)據(jù)應用的探索與實踐

一、阿里風控大腦整體介紹

1.阿里風控大腦是什么

阿里的風控主要分為兩大塊。一塊是金融領域，主要業(yè)務是支付寶，另一塊是非金融領域，如新零售、高德、大文娛等，我們負責的主要是非金融領域。阿里風控大腦的含義較為豐富，可以有不同的解讀，但基本上代表了幾個方向。首先，阿里風控大腦是“大中臺小前臺”戰(zhàn)略，由于阿里風控管的風險業(yè)務很多，領域非常雜，所以允許不同的領域、不同的風控場景可以有自己獨特的交互，有自己的console，但是用到的底層引擎必須是中心化的，由風控引擎做統(tǒng)一計算和處理。第二，阿里風控大腦代表高智能，后續(xù)會有深度學習和無監(jiān)督學習模型大量上線，防控策略及防控方式都會更加智能化。如下圖所示，右側(cè)是目前阿里風控覆蓋的主要業(yè)務和防控的風控場景，如黑客攻擊、消費者保護、商家保護等。左側(cè)是阿里風控2019年雙11的部分數(shù)據(jù)，保護了約388億消費者的操作行為，同時擋住了約22億次惡意攻擊。

2.典型防控鏈路

用戶通過阿里的APP或網(wǎng)站訪問阿里的業(yè)務會產(chǎn)生大量操作。這些操作進來之后大概會經(jīng)過如下圖所示的七層防控環(huán)節(jié)。首先會是端上防控，主要在應用層，比如應用的加固，應用的代碼混淆等。然后是端上安全策略。第二層是在網(wǎng)絡層，在網(wǎng)絡層做流量清洗和流量保護。

基礎安全防控：網(wǎng)絡層之后會有人機判斷。人機部分在風控領域占比非常大，網(wǎng)絡層+人機的防控方式和下面幾層差異比較大，主要針對基礎流量做防控，不會加入具體的業(yè)務邏輯，所以稱其為基礎安全防控。

實施安全防控：人機比較復雜，一部分與流量相關，另一部分偏業(yè)務。其中偏業(yè)務的部分與下面幾層稱為業(yè)務防控范圍。人機之后，在業(yè)務防控側(cè)做白/黑判斷，主要是出于成本考慮。如果能先判定用戶行為的白/黑，后面則不需要做太多進一步判定，可以節(jié)約大量成本。然后是比較復雜的灰的判定，需要從多個維度來識別風險。

準實時聯(lián)合防控：近線是一種準實時聯(lián)合性防控，將多種流量或者多種行為放在一起監(jiān)控。

離線回撈：離線主要是一種離線回撈，針對歷史數(shù)據(jù)做大量回撈。

不是所有業(yè)務都會走近線或離線，業(yè)務按照自己需求自行選擇。

3.業(yè)務安全（MTEE）架構

如下圖所示，業(yè)務側(cè)安全防控可以分成風險識別、風險決策、風險審核、風險處置四大塊。風險識別主要是風險行為的判定，當檢測到用戶的某些行為有風險，如果業(yè)務比較簡單而且識別準確度很高，那么此行為可以直接流入風險處置做處置。如果識別出的行為沒法確定或識別準確率不太高，會將其放到風險審核通過機審或者人審做進一步判定，判定之后才進行處置。還有一些業(yè)務非常復雜，可能需要進一步的綜合判定，那么會將其放到風險決策。比如一些風險不論在一段時間內(nèi)觸犯多少次，只能對其進行一次處罰，但是它在不同環(huán)節(jié)或是不同行為可能會被識別多次，即會多次被認為有風險，需要在風險決策中對這種風險進行統(tǒng)一去重、收口。

其中最復雜的是風險識別環(huán)節(jié)。風險識別會用到前端的業(yè)務系統(tǒng)，比如淘寶APP、天貓APP傳過來的各種業(yè)務數(shù)據(jù)。但是僅僅通過這些業(yè)務數(shù)據(jù)做風險防控是遠遠不夠的，所以阿里會做很多大數(shù)據(jù)的應用，比如名單庫、關鍵詞庫、還有很多的指標以及實時圖、IP庫等。這些數(shù)據(jù)會通過元數(shù)據(jù)中心做統(tǒng)一定義和管理，最終通過統(tǒng)一數(shù)據(jù)服務來給風險識別做數(shù)據(jù)增強。另外，通過事件中心、策略工廠、模型平臺，構建了策略/模型快速實驗和上線的過程。事件中心把實時引擎或者近線引擎的數(shù)據(jù)補全完整后寫入MaxCompute，然后在策略工廠中，會和PAI打通，由策略工廠準備數(shù)據(jù)后，再通過PAI做模型訓練。最終在策略工廠里面將新的策略、新的模型部署到線上，如此便形成了快速的數(shù)據(jù)+訓練+上線的鏈路。

二、近線引擎

1.幾個實時引擎不太好處理的場景

阿里在做近線引擎之前內(nèi)部討論了很久，因為近線引擎的邊界和實時引擎比較接近，有時很難區(qū)分。很多時候在近線引擎里面做的事情在實時引擎里也可以做。那么為什么要做近線引擎阿里發(fā)現(xiàn)有很多場景雖然可以在實時引擎里做，但是需要很多定制化的開發(fā)，需要按照場景專門找開發(fā)人員去實現(xiàn)。模型大規(guī)模推廣之后，發(fā)現(xiàn)這樣的應用場景越來越多，所以希望有更好的方式解決這些問題。比如在商品新發(fā)時，需要結(jié)合商品圖片信息和商品其他信息做綜合判斷該商品是否涉黃，對于圖片信息，大部分公司可能會使用圖片識別引擎，但圖片識別引擎本身處理能力時快時慢，所以返回時間不一定。這種情況通過實時引擎等待返回是不可能去做的，所以需要做很多個性化的開發(fā)去實現(xiàn)整個鏈路的異步化。還有一些場景比如一個帖子有很多回帖，某些回帖可能是垃圾回帖或帶有欺詐行為，大部分情況下是無法通過單個消息或者回帖判斷其是否有欺詐行為，而要綜合從發(fā)帖到回帖各個環(huán)節(jié)來判斷，所以需要把時間跨度很長的很多消息放在一起來處理。這在實時引擎中也不好處理，因為實時引擎本身就是基于事件消息觸發(fā)的。還有一些非常復雜的業(yè)務場景，比如拉新場景，需要結(jié)合注冊+登陸+交易等多種行為來判斷是否有薅羊毛等黑灰產(chǎn)行為，需要將很多事件放到一起去綜合判定，在實時引擎中也不太好做。所以阿里最終決定做近線引擎來對上述問題進行更好的抽象和處理，希望有一種更好的解法來解決這些問題。

2.近線引擎的定位

基于阿里場景，要求近線引擎至少滿足三個要求，如下圖所示，第一時效性不能太差，即允許有延時，但不能太久，因為如果延時太久，沒有返回風險結(jié)果，業(yè)務側(cè)就會認為這種行為是正常的，容易造成漏防。第二要支持多事件綜合處理的能力，在流計算中稱為支持多流的join處理。并且需要非常靈活的數(shù)據(jù)處理能力，大部分算法里面會有很多非常靈活的數(shù)據(jù)加工，需要算法同學自己實現(xiàn)。第三希望近線引擎能和阿里現(xiàn)有的風控體系無縫融合，因為阿里本身原本的風控體系非常龐大，上下游環(huán)節(jié)非常多，如果近線引擎孤立在外，可能需要做很多重復造輪子的事情。

3.Why Blink

流計算的快速發(fā)展，讓阿里選擇了流計算平臺作為近線引擎的底層核心。在對比了市面上幾個比較受歡迎的流計算平臺之后，最終選擇了Blink。選擇Blink有幾點原因，如下圖所示。首先Blink是阿里內(nèi)部定制版的Flink，在公司內(nèi)部已經(jīng)搭建了性能非常好的流計算平臺，平臺開放性、擴展性非常不錯，兼容成本也非常低。另外Blink有一套完整的SQL語義支持，這一點非常重要。因為阿里希望業(yè)務方盡量使用SQL，SQL使用成本較低，上手速度也會非常快。Blink團隊會持續(xù)優(yōu)化SQL性能，使用SQL也可以持續(xù)享受到這個福利。

4.近線引擎功能框架

近線引擎的主要功能是把風控邏輯轉(zhuǎn)換成Blink能夠執(zhí)行的任務。近線引擎會把自己需要的數(shù)據(jù)需求給到事件中心，事件中心通過統(tǒng)一數(shù)據(jù)服務做數(shù)據(jù)增強之后流到Blink里面做計算。為什么要把數(shù)據(jù)補全放到前面去做因為Blink是按照任務分別計算，同一個事件或同一個流量可能會在不同的任務里面計算多次，如果把數(shù)據(jù)增強放到Blink里面做，可能會存在多次補全。另外數(shù)據(jù)補全體量非常大，成本消耗很大，如果放到Blink里面做，會對Blink造成非常大的壓力，并且不好做性能優(yōu)化。

近線引擎從功能上主要分成四個模塊。

業(yè)務組件：對風控元素進行封裝。在近線風控鏈路中有很多風控元素，比如事件中心的數(shù)據(jù)源、對應的下游風控決策或過程中需要用到的模型、算法、策略等。對這些元素進行組件封裝，從而使用戶使用近線引擎時可以快速使用這些風控元素。

SecuritySQL：語法和Blink SQL類似，Blink SQL中會要求寫具體的物理實現(xiàn)，阿里希望用戶不需要關注這些實現(xiàn)細節(jié)，而只關注業(yè)務邏輯，所以設計了SSQL。

語法轉(zhuǎn)義：將SSQL翻譯成Blink SQL。

Blink任務管理：包括任務的上下限、安全生產(chǎn)相關的，做灰度、做測試等。

5.阿里在近線引擎為同學提供的兩種模式

算法同學模式—開放式SQL：算法同學模式是開放式SQL。因為算法同學具備較強的數(shù)據(jù)能力和開發(fā)能力，并且經(jīng)常會針對一些業(yè)務場景寫個性化很強的算法，如果將其限制的太死反而不方便，所以支持完全用SSQL來寫業(yè)務邏輯。下圖所示案例是從數(shù)據(jù)源取出一個字段。左側(cè)是對過程中需要用到的業(yè)務組件的封裝，中間是SSQL。可以看到SSQL寫法跟Blink SQL完全不一樣，只需要寫event.odleventugc。event是數(shù)據(jù)源的特殊名詞，即一個系統(tǒng)保留關鍵字。用SSQL來寫根本不用關注event是怎么來的等影響研發(fā)效率的信息，因為在系統(tǒng)、業(yè)務組件里有一套約定告知event從哪里來。

運營同學模式—通用能力：運營同學可能有一定的數(shù)據(jù)能力，但沒法自己去研發(fā)算法，但運營同學也希望能用上不同的算法來實現(xiàn)自己的業(yè)務需求。算法同學會按照不同業(yè)務場景開發(fā)一些通用能力，比如音頻類，視頻類，圖片類，或文本類的，有基本的，也有具體業(yè)務的。每一個通用能力會轉(zhuǎn)換成一個Blink任務。業(yè)務同學可以通過交互式的方式配置自己的策略，其中可以引用通用能力用來做風險識別。當業(yè)務流量進來，首先進行數(shù)據(jù)預處理，然后按照引用的通用功能把流量轉(zhuǎn)發(fā)到各通用能力對應的任務作相應計算，然后將原始數(shù)據(jù)和通用數(shù)據(jù)進行合并，之后再執(zhí)行自己的策略，并最終將數(shù)據(jù)分發(fā)給下游，比如風險決策系統(tǒng)。整個處理過程拆分的比較細，主要是因為在同一個Blink任務里面，如果代碼量特別大或者是任務特別長，性能和運維會是非常大的問題。將任務拆的比較細便于管理運維，性能也會更好。

另外，任務之間基本通過兩種方式進行數(shù)據(jù)傳遞。第一種是MetaQ，上游任務會通過MetaQ分發(fā)到下游。第二種是通過HBase，因為HBase的多列加上HLog可以很方便地把多條消息整合到一條消息里面，所以數(shù)據(jù)合并基本是用HBase來做。

6.業(yè)務效果

目前近線引擎用了約2000CU資源，日均處理事件量約300億，主要覆蓋的場景有商品、內(nèi)容、直播、拉新等多個領域，風險識別在風控領域占比約10%。相信隨著模型和算法的進一步發(fā)展，產(chǎn)品的進一步完善，比重也會大幅上升。

三、離線引擎

1.為何需要離線引擎

離線引擎基本是和近線引擎同一時間考慮的，起初是發(fā)現(xiàn)有很多離線數(shù)據(jù)會批量導入到實時引擎中處理，非常不利于實時引擎的穩(wěn)定。隨著深入探索和研究，發(fā)現(xiàn)很多場景確實需要批處理能力進行風險識別。離線引擎起初是為了解決以下幾個問題。第一是新業(yè)務的接入，阿里集團規(guī)模最近幾年發(fā)展越來越快，覆蓋了非常多的業(yè)務領域。大部分新業(yè)務的安全水位很比較低，需要接入風控體系。原來會讓新業(yè)務走實時引擎做對接，對接成本較高，對接速度比較慢。新業(yè)務方和安全小二都希望有一種更方便、更快速的對接方式。第二是很多新發(fā)現(xiàn)的風險，或在當前時間點漏過的變異風險，在發(fā)現(xiàn)之后需要對歷史數(shù)據(jù)進行回撈，需求量很大。第三是很多業(yè)務同學在離線做大數(shù)據(jù)風險之后得到的一些結(jié)果，需要有渠道流入到審核或處置等后續(xù)環(huán)境。第四是業(yè)務同學會做策略變更，需要用歷史數(shù)據(jù)來驗證其實際影響，否則上線過程會變得非常慢。

2.離線引擎的功能框架

語義轉(zhuǎn)譯SQL

離線引擎底層主要依賴于MaxCompute，主要過程是將風險語義轉(zhuǎn)換成MaxCompute任務去執(zhí)行。離線引擎和近線引擎有些地方非常像，比如語義轉(zhuǎn)換和任務管理部分，區(qū)別只是近線引擎基于Blink，離線引擎基于MaxCompute。

仿真模擬

離線引擎的獨特之處是需要對歷史數(shù)據(jù)進行全面處理。一個很大的問題是新特征不能通過事件中心對歷史數(shù)據(jù)進行補全，所以做了仿真模擬，即盡可能在離線上復現(xiàn)風控在實時引擎中用到的特征。按照如何去做將仿真分為三類。

業(yè)務原始數(shù)據(jù)：業(yè)務原始數(shù)據(jù)即業(yè)務發(fā)過來的數(shù)據(jù)，按照目前策略，業(yè)務原始數(shù)據(jù)會通過事件中心全量寫到MaxCompute中。事件中心使用DataHub中間件，事件數(shù)據(jù)會通過DataHub寫到MaxCompute。這類數(shù)據(jù)默認全部都有，不需再做過多操作。

不可模擬的增強數(shù)據(jù)：第二類是不可模擬的增強數(shù)據(jù)。比如調(diào)用了一個第三方的服務，完全不清楚第三方服務的邏輯是什么，只知道第三方服務給出的數(shù)據(jù)。因為調(diào)用的第三方服務比較多，所以不可能逐一去看，這類數(shù)據(jù)基本暫時是不可模擬的。目前對于這種數(shù)據(jù)要預先配置在事件中心里面去做補全，其缺點是如果要在新的事件上做補全，已經(jīng)屬于事后的事情了，那么歷史的那部分數(shù)據(jù)是沒辦法獲取的。所以不可模擬的增強數(shù)據(jù)目前還有缺陷。

可模擬的增強數(shù)據(jù)：第三類是可模擬的增強數(shù)據(jù)，按照模擬方式的不同又分為三種。第一種數(shù)據(jù)來自MaxCompute，因為很多數(shù)據(jù)，如離線指標、IP庫原來就在MaxCompute上做計算，計算完成后同步到線上，給線上應用使用，對這種數(shù)據(jù)只需在做SQL翻譯時直接采用數(shù)據(jù)源表即可。第二種是可歸檔數(shù)據(jù)。很多數(shù)據(jù)應用是在自己或周邊團隊建設的的，如名單庫、關鍵詞庫等等，非常清楚整個數(shù)據(jù)邏輯，可以按約定做好數(shù)據(jù)歸檔。歸檔方式多種多樣，如直接回流到MaxCompute上，或?qū)⑵滢D(zhuǎn)成文件，在MaxCompute上讀取。歸檔數(shù)據(jù)體量不會特別大，數(shù)據(jù)量最多TB級。第三種基本指實時指標，線上幾千個實時特征每時每秒產(chǎn)生的數(shù)據(jù)量都非常大，這些數(shù)據(jù)全量回流到MaxCompute的成本很高。但好的地方在于，實時計算用到的原始數(shù)據(jù)基本都是實時引擎流出的，而且這些數(shù)據(jù)事件中心都會接入，所以MaxCompute上也都有這些原始數(shù)據(jù)。而且實時指標的邏輯都維護在系統(tǒng)里面，是非常清楚的，所以可以基于原始數(shù)據(jù)及指標的計算邏輯，在MaxCompute上寫一套模擬任務去模擬。阿里寫了一套盡可能仿真的仿流式計算的任務模板，結(jié)果數(shù)據(jù)和流計算基本一致，最多會有一分鐘或者更小時間窗口的誤差。通過這一整套模板，就可以在離線引擎上提供很多與線上一致或接近一致的指標供用戶使用。

任務調(diào)度

Blink無需太多任務調(diào)度，流量來了就處理，但離線批處理需要有任務調(diào)度。離線引擎的任務調(diào)度很大一部分是用DataWorks本身的調(diào)度，但也有一些場景沒辦法使用。目前離線引擎的任務分為兩種。

周期性任務：用戶需要周期性的對一些增量或者全量的歷史數(shù)據(jù)進行風險識別。周期性任務借助DataWorks的周期任務，因為它的周期任務管理已經(jīng)做得很好，首先有完善的上下游依賴和調(diào)度，其次有豐富的調(diào)度參數(shù)配置，可以通過很多參數(shù)來控制調(diào)度。DataWorks周期性任務的缺點是任務結(jié)構不建議經(jīng)常刷新，如果經(jīng)常刷新任務的上下游結(jié)構，可能導致任務調(diào)度出問題。比如昨天的任務今天還未調(diào)度，如果把調(diào)度鏈路改了，任務就可能有問題甚至報錯。但在離線引擎中，為了讓一次風控計算任務性能更好，需要將一個任務拆成多個任務，即多個DataWorks周期性任務來處理。比如會先用一個任務做預處理，然后多個任務并行做各種數(shù)據(jù)增強，之后再進行合并，最后做策略執(zhí)行，如此一來時效性會很好，執(zhí)行速度會更快。但是周期任務中這種任務鏈會在策略變更時需要經(jīng)常去刷新，為了避免刷新帶來的問題，現(xiàn)在將增強數(shù)據(jù)固定分成了幾類，比如無論這一次離線任務里是否使用名單，先將名單增強任務生成好，將任務節(jié)點永遠保留在任務鏈中，那么無論怎么刷新，最多是刷新其中的邏輯，而不刷新任務結(jié)構，從而讓離線引擎任務可以隨時更新。

一次性任務：需要對歷史數(shù)據(jù)做一次性回撈，不需要跑多次。一次性任務是利用DataWorks中的觸發(fā)式任務。觸發(fā)式任務最大的問題是只支持單個任務做調(diào)度。因為一次性任務時效性很重要，用戶做一次回撈不可能等幾個小時，所以需要對任務進行更細致的分拆，分拆完成后在離線引擎里面自己實現(xiàn)調(diào)度，通過周期性輪詢?nèi)蝿諣顟B(tài)，自己完成任務依賴、任務調(diào)度等工作。

四、總結(jié)

阿里目前有三個引擎，實時引擎、近線引擎和離線引擎，其好處是用戶能做的事情變得更多，能力變得更強，壞處是引擎增多，概念增多，用戶理解和使用成本會變得更高。所以阿里在引擎設計之初堅持的原則是用同一套元數(shù)據(jù)，即引擎的元數(shù)據(jù)都是一樣的，可以在最大層面上避免用戶對引擎理解的不一致。其次，在很長時間甚至到現(xiàn)在，一直在做的事情都是盡量讓引擎用到的是同一套數(shù)據(jù)。未來希望所有引擎有同一套風控語言，例如SSQL或比SSQL更成熟、更抽象的一種語言。這種語言可用于解釋風控場景中的各種語義。如果有這樣一套風控語言，風控用戶對風險的描述、風險場景的落地會更加直觀清楚。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內(nèi)容、版權或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。