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

阿里風控大腦關于大數據應用的探索與實踐

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

1.阿里風控大腦是什么

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

2.典型防控鏈路

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

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

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

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

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

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

3.業務安全（MTEE）架構

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

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

二、近線引擎

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

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

2.近線引擎的定位

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

3.Why Blink

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

4.近線引擎功能框架

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

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

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

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

語法轉義：將SSQL翻譯成Blink SQL。

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

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

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

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

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

6.業務效果

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

三、離線引擎

1.為何需要離線引擎

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

2.離線引擎的功能框架

語義轉譯SQL

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

仿真模擬

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

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

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

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

任務調度

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

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

一次性任務：需要對歷史數據做一次性回撈，不需要跑多次。一次性任務是利用DataWorks中的觸發式任務。觸發式任務最大的問題是只支持單個任務做調度。因為一次性任務時效性很重要，用戶做一次回撈不可能等幾個小時，所以需要對任務進行更細致的分拆，分拆完成后在離線引擎里面自己實現調度，通過周期性輪詢任務狀態，自己完成任務依賴、任務調度等工作。

四、總結

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

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