去年春節期間支付寶推出的集五福的活動可謂風靡一時，每張福卡背面都有刮刮卡，裏面有來自螞蟻金服、阿里巴巴以及合作伙伴的上百種權益。集五福的活動集中在春節前的幾天，具有很強的時效性。所以如何實現權益和投放人羣的自動匹配，解決系統的冷啓動問題，優化轉化率和提升用戶體驗，就成了一個在線學習的優化問題。
之前我們搭建一個這樣的系統需要的模塊非常繁雜。我們需要日誌收集、數據聚合、樣本的拼接和採樣等流處理任務，需要對接模型訓練、模型驗證等機器學習模塊，需要有把模型實時加載的模型服務，還需要其他的配套設施等等。衆多模塊的銜接極大地增加了系統的複雜性。
由於涉及的系統比較多，我們之前的系統遇到了比較多的問題。比如大促時爲了保證高優鏈路的穩定性，上游某些數據處理的鏈路就會被降級了，但下游同學並不知情。另外一個很常見問題的是流批邏輯不一致，需要離線特徵來訓練基準模型，同時在線計算的特徵來對模型進行實時更新。這兩個模塊一個在離線一個在線，曾經出現過處理邏輯的細微差別對業務效果造成了很大的影響。
總結下來，我們曾經遇到的坑可以歸結爲三類：
- 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月份開始上線第一個場景，在支付線財富線也都取得了不錯的效果，接下來我們會推廣到螞蟻金服的其他業務線上。
基於融合計算機器學習，它是融合計算和機器學習這兩種模式的有機組合，實現優化資源共享。我們通過這兩方面的探索初步驗證了融合計算的框架，融合計算是旨在數據共享來進行計算模式的兼容，融合的本質是開放，開放的基礎是實現數據的互通，只要我們能夠方便的實現各模式之間的數據互通，並且能夠保障它們數字的實時性和端到端的一致性，就可以實現複雜場景裏面需要多種模式進行組合的計算。模塊的銜接就像搭樂高積木一樣，基本的模塊可能只有幾種，但是搭建出複雜且多變的系統。