阿里風(fēng)控大腦關(guān)于大數(shù)據(jù)應(yīng)用的探索與實(shí)踐,大數(shù)據(jù)風(fēng)控框架-ESG跨境

阿里風(fēng)控大腦關(guān)于大數(shù)據(jù)應(yīng)用的探索與實(shí)踐,大數(shù)據(jù)風(fēng)控框架

阿里風(fēng)控大腦關(guān)于大數(shù)據(jù)應(yīng)用的探索與實(shí)踐

一、阿里風(fēng)控大腦整體介紹

1.阿里風(fēng)控大腦是什么

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

2.典型防控鏈路

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

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

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

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

離線回?fù)疲弘x線主要是一種離線回?fù)?，針?duì)歷史數(shù)據(jù)做大量回?fù)啤?/p>

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

3.業(yè)務(wù)安全（MTEE）架構(gòu)

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

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

二、近線引擎

1.幾個(gè)實(shí)時(shí)引擎不太好處理的場(chǎng)景

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

2.近線引擎的定位

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

3.Why Blink

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

4.近線引擎功能框架

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

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

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

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

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

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

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

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

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

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

6.業(yè)務(wù)效果

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

三、離線引擎

1.為何需要離線引擎

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

2.離線引擎的功能框架

語義轉(zhuǎn)譯SQL

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

仿真模擬

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

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

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

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

任務(wù)調(diào)度

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

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

一次性任務(wù)：需要對(duì)歷史數(shù)據(jù)做一次性回?fù)?，不需要跑多次。一次性任?wù)是利用DataWorks中的觸發(fā)式任務(wù)。觸發(fā)式任務(wù)最大的問題是只支持單個(gè)任務(wù)做調(diào)度。因?yàn)橐淮涡匀蝿?wù)時(shí)效性很重要，用戶做一次回?fù)撇豢赡艿葞讉€(gè)小時(shí)，所以需要對(duì)任務(wù)進(jìn)行更細(xì)致的分拆，分拆完成后在離線引擎里面自己實(shí)現(xiàn)調(diào)度，通過周期性輪詢?nèi)蝿?wù)狀態(tài)，自己完成任務(wù)依賴、任務(wù)調(diào)度等工作。

四、總結(jié)

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

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