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

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

以前咱們搭建一個這樣的系統須要的模塊很是繁雜。咱們須要日誌收集、數據聚合、樣本的拼接和採樣等流處理任務，須要對接模型訓練、模型驗證等機器學習模塊，須要有把模型實時加載的模型服務，還須要其餘的配套設施等等。衆多模塊的銜接極大地增長了系統的複雜性。

因爲涉及的系統比較多，咱們以前的系統遇到了比較多的問題。好比大促時爲了保證高優鏈路的穩定性，上游某些數據處理的鏈路就會被降級了，但下游同窗並不知情。另一個很常見問題的是流批邏輯不一致，須要離線特徵來訓練基準模型，同時在線計算的特徵來對模型進行實時更新。這兩個模塊一個在離線一個在線，曾經出現過處理邏輯的細微差異對業務效果形成了很大的影響。

總結下來，咱們曾經遇到的坑能夠歸結爲三類：

• 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%的提高
• 幾十分鐘模型延遲到四、5分鐘，而且能夠根據業務的需求進一步下降
• 機器使用下降了60%

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

基於融合計算機器學習，它是融合計算和機器學習這兩種模式的有機組合，實現優化資源共享。咱們經過這兩方面的探索初步驗證了融合計算的框架，融合計算是旨在數據共享來進行計算模式的兼容，融合的本質是開放，開放的基礎是實現數據的互通，只要咱們可以方便的實現各模式之間的數據互通，而且可以保障它們數字的實時性和端到端的一致性，就能夠實現複雜場景裏面須要多種模式進行組合的計算。模塊的銜接就像搭樂高積木同樣，基本的模塊可能只有幾種，可是搭建出複雜且多變的系統。