簡介： 2019年雙11阿里風控保護了約388億消費者的操做行爲，同時擋住了約22億次惡意攻擊。在首席技術官大數據專享會，阿里巴巴新零售技術事業羣高級數據技術專家丁明峯爲你們介紹了阿里風控大腦關於大數據應用的探索與實踐，即風控領域如何應用大數據來構建風控體系？並詳細介紹風控架構以及鏈路。前端
1、阿里風控大腦總體介紹算法
1. 阿里風控大腦是什麼?安全
阿里的風控主要分爲兩大塊。一塊是金融領域，主要業務是支付寶，另外一塊是非金融領域，如新零售、高德、大文娛等，咱們負責的主要是非金融領域。阿里風控大腦的含義較爲豐富，能夠有不一樣的解讀，但基本上表明瞭幾個方向。首先，阿里風控大腦是「大中臺小前臺」戰略，因爲阿里風控管的風險業務不少，領域很是雜，因此容許不一樣的領域、不一樣的風控場景能夠有本身獨特的交互，有本身的console，可是用到的底層引擎必須是中心化的，由風控引擎作統一計算和處理。第二，阿里風控大腦表明高智能，後續會有深度學習和無監督學習模型大量上線，防控策略及防控方式都會更加智能化。以下圖所示，右側是目前阿里風控覆蓋的主要業務和防控的風控場景，如黑客攻擊、消費者保護、商家保護等。左側是阿里風控2019年雙11的部分數據，保護了約388億消費者的操做行爲，同時擋住了約22億次惡意攻擊。性能優化
2. 典型防控鏈路網絡
用戶經過阿里的APP或網站訪問阿里的業務會產生大量操做。這些操做進來以後大概會通過以下圖所示的七層防控環節。首先會是端上防控，主要在應用層，好比應用的加固，應用的代碼混淆等。而後是端上安全策略。第二層是在網絡層，在網絡層作流量清洗和流量保護。架構
基礎安全防控：網絡層以後會有人機判斷。人機部分在風控領域佔比很是大，網絡層+人機的防控方式和下面幾層差別比較大，主要針對基礎流量作防控，不會加入具體的業務邏輯，因此稱其爲基礎安全防控。框架
實施安全防控：人機比較複雜，一部分與流量相關，另外一部分偏業務。其中偏業務的部分與下面幾層稱爲業務防控範圍。人機以後，在業務防控側作白/黑判斷，主要是出於成本考慮。若是能先斷定用戶行爲的白/黑，後面則不須要作太多進一步斷定，能夠節約大量成本。而後是比較複雜的灰的斷定，須要從多個維度來識別風險。
準實時聯合防控：近線是一種準實時聯合性防控，將多種流量或者多種行爲放在一塊兒監控。運維
離線回撈：離線主要是一種離線回撈，針對歷史數據作大量回撈。
不是全部業務都會走近線或離線，業務按照本身需求自行選擇。異步
3.業務安全（MTEE）架構性能
以下圖所示，業務側安全防控能夠分紅風險識別、風險決策、風險審覈、風險處置四大塊。風險識別主要是風險行爲的斷定，當檢測到用戶的某些行爲有風險，若是業務比較簡單並且識別準確度很高，那麼此行爲能夠直接流入風險處置作處置。若是識別出的行爲無法肯定或識別準確率不過高，會將其放到風險審覈經過機審或者人審作進一步斷定，斷定以後才進行處置。還有一些業務很是複雜，可能須要進一步的綜合斷定，那麼會將其放到風險決策。好比一些風險不論在一段時間內觸犯多少次，只能對其進行一次處罰，可是它在不一樣環節或是不一樣行爲可能會被識別屢次，即會屢次被認爲有風險，須要在風險決策中對這種風險進行統一去重、收口。
其中最複雜的是風險識別環節。風險識別會用到前端的業務系統，好比淘寶APP、天貓APP傳過來的各類業務數據。可是僅僅經過這些業務數據作風險防控是遠遠不夠的，因此阿里會作不少大數據的應用，好比名單庫、關鍵詞庫、還有不少的指標以及實時圖、IP庫等。這些數據會經過元數據中心作統必定義和管理，最終經過統一數據服務來給風險識別作數據加強。另外，經過事件中心、策略工廠、模型平臺，構建了策略/模型快速實驗和上線的過程。事件中心把實時引擎或者近線引擎的數據補全完整後寫入MaxCompute，而後在策略工廠中，會和PAI打通，由策略工廠準備數據後，再經過PAI作模型訓練。最終在策略工廠裏面將新的策略、新的模型部署到線上，如此便造成了快速的數據+訓練+上線的鏈路。
2、近線引擎
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%。相信隨着模型和算法的進一步發展，產品的進一步完善，比重也會大幅上升。
3、離線引擎
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中的觸發式任務。觸發式任務最大的問題是隻支持單個任務作調度。由於一次性任務時效性很重要，用戶作一次回撈不可能等幾個小時，因此須要對任務進行更細緻的分拆，分拆完成後在離線引擎裏面本身實現調度，經過週期性輪詢任務狀態，本身完成任務依賴、任務調度等工做。
4、總結
阿里目前有三個引擎，實時引擎、近線引擎和離線引擎，其好處是用戶能作的事情變得更多，能力變得更強，壞處是引擎增多，概念增多，用戶理解和使用成本會變得更高。因此阿里在引擎設計之初堅持的原則是用同一套元數據，即引擎的元數據都是同樣的，能夠在最大層面上避免用戶對引擎理解的不一致。其次，在很長時間甚至到如今，一直在作的事情都是儘可能讓引擎用到的是同一套數據。將來但願全部引擎有同一套風控語言，例如S-SQL或比S-SQL更成熟、更抽象的一種語言。這種語言可用於解釋風控場景中的各類語義。若是有這樣一套風控語言，風控用戶對風險的描述、風險場景的落地會更加直觀清楚。
查看更多：https://yqh.aliyun.com/detail/6608
上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/