提效降本：螞蟻金服如何用融合計算改造線上機器學習

去年春節期間支付寶推出的集五福的活動可謂風靡一時，每張福卡背面都有刮刮卡，裡面有來自螞蟻金服、阿里巴巴以及合作伙伴的上百種權益。集五福的活動集中在春節前的幾天，具有很強的時效性。所以如何實現權益和投放人群的自動匹配，解決系統的冷啟動問題，最佳化轉化率和提升使用者體驗，就成了一個線上學習的最佳化問題。

之前我們搭建一個這樣的系統需要的模組非常繁雜。我們需要日誌收集、資料聚合、樣本的拼接和取樣等流處理任務，需要對接模型訓練、模型驗證等機器學習模組，需要有把模型實時載入的模型服務，還需要其他的配套設施等等。眾多模組的銜接極大地增加了系統的複雜性。

由於涉及的系統比較多，我們之前的系統遇到了比較多的問題。比如大促時為了保證高優鏈路的穩定性，上游某些資料處理的鏈路就會被降級了，但下游同學並不知情。另外一個很常見問題的是流批邏輯不一致，需要離線特徵來訓練基準模型，同時線上計算的特徵來對模型進行實時更新。這兩個模組一個在離線一個線上，曾經出現過處理邏輯的細微差別對業務效果造成了很大的影響。

總結下來，我們曾經遇到的坑可以歸結為三類：

• SLA ：整個鏈路的SLA會受到每個模組的SLA的影響，並隨著模組的增多而放大，穩定性成為制約業務發展的重要因素。
• 系統效率 ：模組之間的銜接多數是透過資料的落盤來進行，模組間的排程透過系統排程來實現，造成不必要的I/O、計算和網路開銷。
• 開發和運維的成本 ：各個模組風格迥異，開發模式、計算框架、甚至程式碼風格都不一致，開發和運維對接時需要花很多時間去熟悉系統，降低業務開放的效率。

一個理想的系統應該提供什麼樣的能力呢？可以從“穩快簡”三個方面來講：首先從資料來講它需要保證資料和計算一致性，實現整個鏈路端到端的SLA，資料一致性和鏈路的穩定是保障業務穩定的基礎。第二是我們需要去最佳化系統效率，我們希望把這十幾個系統的銜接轉換成系統內部的銜接，希望把這些作業排程轉換成任務的排程，透過這樣轉化我們希望把計算與計算之間協同排程，從而提高系統效率和降低網路頻寬使用的目的。一個融合的系統也可以對開發和運維提供非常大的便利，以前需要對接十幾個系統，現在只要對接一個系統就可以了。以前我們在應急的時候需要回溯好幾個業務來發現問題，現在融合在一起的系統除錯也會更加容易。

線上機器學習最外層需要透出資料處理、模型訓練、模型服務三個能力。這三個能力反映到對計算引擎框架上的需求是敏捷的呼叫機制、比較靈活的資源管控，以及比較完善的容錯機制。上層的系統往往是透過不同程式語言來實現的，因此還需要有多語言介面。透過對底層需求的考量以及現在各框架的特點，最後我們選擇了Ray為融合計算的底座。

Ray是由伯克利大學RiseLab實驗室發起，螞蟻金服共同參與的一個開源分散式計算框架，它提出的初衷在於讓分散式系統的開發和應用能夠更加簡單。Ray作為計算框架可以幫我們實現上面“穩快簡”三個目標。Ray作為計算框架具有敏捷的排程機制，用它可以一秒鐘進行上百萬次任務排程，它也可以根據計算對資源使用的需求實現異構排程。

在目前比較流行的分散式框架，都有三個比較基礎的分散式原語，分散式任務、物件和服務。而我們常用的程式導向的程式語言中，也剛好有三個基本概念，函式、變數和類。這三個程式設計語基本概念剛好可以和分散式框架的原語對應起來。在Ray系統中，可以透過簡單的改動，實現他們之間的轉換。

左邊是一個簡單的例子，在這個函式前面需要加入一個“@remote”修飾符，就可以把一個函式轉換成為分散式任務。任務透過“.remote”呼叫執行，返回值是一個變數，又可以參與到其他計算中。

右邊是另一個例子，透過加“@remote”修飾符的方式可以把一個類轉變成服務。類中的方法可以透過“.remote”呼叫變成一個分散式任務，和函式的使用非常相似。透過這種方式可以實現從單機程式到分散式任務的轉變，把本地的任務排程到遠端的機器上進行執行。

Ray上應該做怎麼樣的排程，衡量指標就是系統的效率問題，系統的效率很多時候取決於計算和資料的組織方式，比如說我們要計算Add(a,b)，首先這個函式在本地會被自動註冊並且提供給本地排程器。之後透過全劇排程器和第二個節點的本地排程器一起協同工作，把A備份到第二個節點執行Add這個操作。它還可以根據A和B的資料大小來進行進一步的排程和控制最佳化，A和B可以是簡單資料型別，也可以是比較複雜的變數或者矩陣。

Ray上面提供多語言API介面。由於歷史原因，在螞蟻金服內部流式計算使用最多的語言是Java，而機器學習建模比較普遍使用的語言是Python。我先希望重用Java語言實現的流處理運算元，同時保留Python進行機器學習建模的便捷性。Ray上面提供這樣的多元化支援就非常方便我們做這個事情，使用者在上層開發的時候可以可以方便地使用Java和Python分別進行流處理和機器學習模型的開發

對於線上機器學習來說，它最核心需要解決的問題是要打通流計算和模型訓練，那我們需要使用一個介質，這個介質能夠比較方便的將兩者銜接在一起。之前我們介紹Ray的幾個特點，如提供多語言的介面、靈活的調動機制，這是因為這兩個特點在Ray上可以比較方便做這個事情，Ray可以起到銜接的作用。資料處理的最後一個節點是流計算的輸出，worker節點消費資料，是模型訓練的輸入。Ray就可以透過排程機制把這兩個計算排程在一個節點上，實現資料共享從而實現兩個模式的打通。透過這種方式不僅可以相容流計算和機器學習，也可以將其他模式進行銜接。

計算中DAG概念最開始是為了解決多階段分散式計算的效率而提出的，主要思想是透過排程減少計算時的IO。但是以前的計算DAG，在任務執行的時候它就已經確定了，但我們在機器學習的任務裡面，很多時候我們會需要設計新的模型，或者對模型的超參進行除錯，我們希望看到這些模型能被載入到鏈路上，看到業務效果的同時又不想線上已經有的模型的訓練和服務被中斷。在Ray系統內部，計算的過程中可以動態的生成另外一個節點，我們可以利用這個特性來增點和變，從而動態的對DAG進行區域性修正。

線上系統和離線系統之間比較大的區別，在於如果一個離線系統裡的任務掛了，一般來說可以透過重啟機器的方式來解決，但對線上系統來說，出於時效性的考慮，我們不能簡單的透過重啟機群回溯資料的方式來解決。因此就需要有比較完善的容錯機制。我們在模型訓練的時候可以利用Ray的Actor來拉起模型訓練的worker和server節點。如果worker或者server節點處於不健康狀態，我們就可以利用Actor的容錯特性透過血緣關係來對資料和計算進行恢復，從而實現容錯的訓練。

我們比較追求鏈路的時效性，模型能夠儘快的擬合實時資料裡。但是追求時效性的同時也要保證整個鏈路的穩定性，在敏捷和敏感之間達到平衡。我們從三個方面，系統穩定性、模型穩定性、機制穩定性來保障整個鏈路的穩定性。

 

• 系統穩定性 ，裡面包括資料實時性和強一致性保障。
• 模型穩定性 ，我們希望設計的模型能夠擬合實時資料流，但同時要防止線上學習鏈路在各種不確定性因素下，如資料噪音，造成的效果退化。因此我們需要考慮線上特徵和離線特徵的組合，在模型設計上需要考慮到深層模型和淺層模型對資料的敏感性和噪音的容忍度。
• 機制穩定性 ，賽馬機制、快速回滾策略。

 

除了之前用Ray來實現融合以及它帶來的好處，我們也做了非常多的模組建設，TF融合、穩定性保障、樣本回流、延遲樣本修正、資料共享、流批一體、端到端強一致、模型增量匯出。我們把這個平臺上線了支付寶的幾個場景，從下面的幾個數字可以一探效果：

• 99.9%的全鏈路SLA
• 業務指標有2%到40%的提升
• 幾十分鐘模型延遲到4、5分鐘，並且可以根據業務的需求進一步降低
• 機器使用降低了60%

 

我們從去年8月份開始建設，今年2月份開始上線第一個場景，在支付線財富線也都取得了不錯的效果，接下來我們會推廣到螞蟻金服的其他業務線上。

基於融合計算機器學習，它是融合計算和機器學習這兩種模式的有機組合，實現最佳化資源共享。我們透過這兩方面的探索初步驗證了融合計算的框架，融合計算是旨在資料共享來進行計算模式的相容，融合的本質是開放，開放的基礎是實現資料的互通，只要我們能夠方便的實現各模式之間的資料互通，並且能夠保障它們數字的實時性和端到端的一致性，就可以實