以下内容根據演講視訊以及PPT整理而成。
本次分享主要圍繞以下三個方面：
一、阿裡風控大腦整體介紹
二、近線引擎
三、離線引擎
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造成非常大的壓力，并且不好做性能優化。
近線引擎從功能上主要分成四個子產品。
業務元件：對風控元素進行封裝。在近線風控鍊路中有很多風控元素，比如事件中心的資料源、對應的下遊風控決策或過程中需要用到的模型、算法、政策等。對這些元素進行元件封裝，進而使使用者使用近線引擎時可以快速使用這些風控元素。
Security-SQL：文法和Blink SQL類似，Blink SQL中會要求寫具體的實體實作，阿裡希望使用者不需要關注這些實作細節，而隻關注業務邏輯，是以設計了S-SQL。
文法轉義：将S-SQL翻譯成Blink SQL。
Blink任務管理：包括任務的上下限、安全生産相關的，做灰階、做測試等。
5. 阿裡在近線引擎為同學提供的兩種模式
算法同學模式—開放式SQL：算法同學模式是開放式SQL。因為算法同學具備較強的資料能力和開發能力，并且經常會針對一些業務場景寫個性化很強的算法，如果将其限制的太死反而不友善，是以支援完全用S-SQL來寫業務邏輯。下圖所示案例是從資料源取出一個字段。左側是對過程中需要用到的業務元件的封裝，中間是S-SQL。可以看到S-SQL寫法跟Blink SQL完全不一樣，隻需要寫event.odl_event_ugc。event是資料源的特殊名詞，即一個系統保留關鍵字。用S-SQL來寫根本不用關注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中的觸發式任務。觸發式任務最大的問題是隻支援單個任務做排程。因為一次性任務時效性很重要，使用者做一次回撈不可能等幾個小時，是以需要對任務進行更細緻的分拆，分拆完成後在離線引擎裡面自己實作排程，通過周期性輪詢任務狀态，自己完成任務依賴、任務排程等工作。
四、總結
阿裡目前有三個引擎，實時引擎、近線引擎和離線引擎，其好處是使用者能做的事情變得更多，能力變得更強，壞處是引擎增多，概念增多，使用者了解和使用成本會變得更高。是以阿裡在引擎設計之初堅持的原則是用同一套中繼資料，即引擎的中繼資料都是一樣的，可以在最大層面上避免使用者對引擎了解的不一緻。其次，在很長時間甚至到現在，一直在做的事情都是盡量讓引擎用到的是同一套資料。未來希望所有引擎有同一套風控語言，例如S-SQL或比S-SQL更成熟、更抽象的一種語言。這種語言可用于解釋風控場景中的各種語義。如果有這樣一套風控語言，風控使用者對風險的描述、風險場景的落地會更加直覺清楚。