導讀：如今大部分人工智慧應用是基於監督學習正規化開發的，即模型線上下進行訓練，然後部署到伺服器上進行線上預測，這樣的開發方式在實時響應上存在較大的侷限。隨著計算和 AI 體系逐步成熟，我們希望機器學習應用能更多地在動態環境下執行、實時響應環境中的變化，這推動了機器學習從傳統離線學習逐漸向線上學習演進。相比於傳統的離線機器學習，線上學習可以帶來更快的模型迭代速度，讓模型預測效果更貼真實情況，對於線上的波動更加敏銳。

最近兩年，國內各一線網際網路廠商分別推出自己的線上學習技術體系及相關架構。螞蟻金服從 2018 年 7 月開始，基於最新的 Ray 分散式引擎自研了金融級的線上學習系統，與傳統線上學習框架相比，在端到端延遲、穩定性、研發效率等方面都有不同程度的提高。

Ray 是伯克利大學 AMPLab 在 2017 年 12 月開源的高效能分散式計算引擎，推出至今不足兩年，在計算框架領域還是一個十足的“新生兒”，雖然業內關注度頗高，但真正將 Ray 付諸應用的企業並不多，螞蟻金服或許是國內第一個“吃螃蟹”的公司。為什麼 Ray 能夠得到螞蟻金服的青睞？它與紅透半邊天的開源計算引擎 Spark、Flink 相比有什麼獨特的優勢？在 Ray 的使用過程中可能會遇到哪些問題？螞蟻金服的踩坑經驗有何可借鑑之處？帶著這些問題，InfoQ 在近期召開的 QCon 上海 2019 大會 現場採訪了螞蟻金服資深技術專家周家英（徒離），以下為採訪問答實錄。

InfoQ：能否請您總體介紹一下螞蟻金服大資料技術架構的演進歷程，包括經歷了哪幾個階段、以及每個階段你們所做的重點工作等。

周家英： 螞蟻金服的大資料技術架構早期也是從離線計算階段發展起來的，這一階段大概是在 2011 年到 2013 年，當時還是以業界傳統的離線計算為主，也就是 Hadoop。2013 年之後，隨著分散式實時計算系統 Storm 推出，我們開始逐步將業務轉向實時計算。從 2016 年開始，團隊經過了一次比較大的轉型，希望打造一套迎接下一代大資料計算的技術體系。一開始我們先嚐試將計算引擎剝離出來，讓業務與計算平臺或中臺體系直接對接，而不是對接具體的某個引擎。在這個階段，我們經歷瞭如特徵中臺、事件中臺或者決策中臺這些概念。

從這往後，大資料引擎、整個大資料體系都發展得非常快。我們不想繼續像趕潮流一樣，圍繞一兩個引擎或者一兩種比較流行的計算模式去建立生態，我們認為應該有一套穩定的大資料計算架構設計思路，能夠覆蓋所有資料層面的問題。我們希望能逐漸沉澱出自己的一套技術體系，這套體系可以同時相容和支援業界所有比較活躍的計算引擎，所以我們從 2017 年開始提出所謂“開放架構”的概念，從針對不同計算引擎單獨建設，轉變成建設一套開放的計算架構。

首先，它是一個致力於解決大資料計算問題的整體架構，在這個架構中會包含不同的計算引擎，但是這些引擎在是以外掛化的方式存在的，這意味著，當引擎發生變化的時候，上層的業務是無感知的。基於這個架構，我們在一些關鍵能力上做了大量自研工作，比如我們現在正在做的融合計算引擎。傳統的計算模式和計算引擎是繫結的，從 Flink 到 Spark，一個是流一個是批，雖然這兩個之間可以互相轉換，但是很多的特性在轉換的時候其實沒有那麼順暢，而且在轉換的時候有一些優點會丟失。另外，像圖計算模式其實無法被包括在任何計算引擎之中，因為這些計算引擎在設計的時候已經繫結了一個模式。我們提出融合計算的概念，就是希望能夠用 Ray 這個分散式計算框架同時支援多種計算模式，並內聚地把各個計算模式融合起來。這指的是透過不同的融合手段，在研發、容災、執行幾個階段，把各個計算模式透過一個閉環組合在一起，達到效能最優、效率最佳。另外我們在圖計算、AI 以及軟硬體結合方面也有比較多的投入。這是螞蟻金服整個大資料計算的發展歷程。

InfoQ：在整個過程中，螞蟻金服有沒有學習一些國外其他企業的經驗？

周家英： 當然，我們並不是憑空或盲目地去做所謂的創新，而是會首先看到業界最先進的技術和經驗。我們會和業界一些實戰派的大型網際網路公司對標，比如 Google、Facebook、Amazon 等；同時會對標一些更偏研究性質的公司的產品或理念，比如微軟、IBM 等；另外我們也會結合自己的業務特點和之前踩過的坑綜合考慮。也就是先看業界最領先的技術從工程方面和研究方面分別有哪些，同時再看之前踩過的坑，以及自己遇到的問題，結合自己的業務場景和規模，從而才確定剛才我們說的工作重點以及未來規劃。

InfoQ：前面提到了實時資料階段和線上資料階段，二者關鍵的不同是什麼？

周家英：實時資料階段是從離線資料階段發展過來的，雖然比以前更快，但是它所面臨的問題也很直觀。比如資料計算從 T+1 變成 T+ 分鐘或 T+ 秒，這就是從離線到實時了，但是到底是秒還是分鐘，是可以在一個很大的區間裡切換的，這並不會對線上場景有什麼大的影響。如果是一個監控任務或同步任務，那麼它的時效性可以在實時和離線層面自由過渡。但是線上計算需要與線上業務的一致性對齊，比如我們的業務依賴於資料庫進行計算，只有當資料庫返回結果之後才能繼續支撐下一個業務。我們認為線上數計算更多是支援線上決策業務的大資料計算場景，而非從離線到實時的簡單轉變。

InfoQ：那麼線上資料階段對技術架構的挑戰主要體現在哪裡？

周家英： 挑戰非常多。首先，線上計算意味著一個完全不同的計算模式。比如從計算資料準備的角度來講，它是一個流計算的模型；但是如果要能把它查出來，把它依賴於線上的服務，其實又有一種比如說分散式服務的概念。如何讓查詢得到的資料越來越快、同時要準，也依賴於寫入資料與計算結果和查詢資料最後結果匹配的情況。這是一個不同的計算模式，會更多樣性一些。同時還有一個很關鍵的點，就是我們以前的所謂離線計算或者說實時計算，其實它和線上的應用是分開的，比如線上應用的 SLA、物理機房部署是單獨的一套，而大資料的機房部署又是另外一套，兩邊是相對解耦的，所以我們一般會說，當資料倉儲或資料計算產生問題的時候不會對線上業務產生影響。但是線上計算概念出來以後，就意味著我們的資料計算要和資料業務放在一起，所以整個部署架構、容災體系、SLA 標準，都需要全面改變和提升。

InfoQ：與傳統線上學習框架相比，螞蟻金服的線上學習系統在哪些方面做了最佳化？

周家英： 傳統的機器學習是離線的機器學習，它的特徵是迭代週期非常長，資料計算是以天或小時級別來進行的，傳統的線上學習主要是指把批計算變成流計算，將流計算的計算引擎和機器學習訓練的引擎連線在一起，然後兩邊做快速迭代來產生資料模型。而螞蟻的線上學習體系是在業界的基礎上，把不同計算模式由不同引擎拼接起來這樣一個架構變成一套融合的架構，即用一個引擎支援不同的計算模式。我們認為，流計算是一種計算模式、模型訓練是一種模式、分散式服務是一種模式，我們把這三種模式彙集在一套計算引擎上面，這個計算引擎就是 Ray。總結來說，我們用一個計算引擎覆蓋了線上學習的所有環節，而傳統的線上學習框架可能是用不同的引擎分別解決不同的問題，做的是拼接的工作，這是最大的區別。

InfoQ：為什麼螞蟻金服選擇基於 Ray 來自研線上學習系統？你們前期做了哪些技術調研工作？與其他分散式引擎相比，Ray 的優勢和不足分別是什麼？

周家英：我們之所以選擇 Ray 是因為除了它以外，其他的計算引擎大多已經和某一種計算模式繫結了，比如 Spark 推出的時候目標就是代替 Hadoop 做批計算，雖然它也可以跑流計算，但是 Spark 是拿批來模擬流；Flink 推出的時候是為了代替 Storm 做更好的流計算，雖然它也可以跑批計算，但是是拿流來模擬批，而在模擬的過程中都會有一定的缺陷或先天不足。因為這些計算引擎本身就是為了一種特定的計算模式設計的，它們天然做不到融合。所以我們在 16-17 年左右找到了伯克利的 AMPLab，他們提出的概念很符合我們之前對計算的想法，就是在下層有一層抽象和通用的分散式排程能力，我們可以基於這個原始層，在上面抽象出不同的計算模式，同時把通用能力沉澱到下層，最終變成兩個層級：第一層是計算模式，流、批、圖計算、機器學習都是不同的計算模式；而下面一層是分散式服務，我們認為這是一個核心層，它必須能解決排程問題、容災問題、資源恢復問題等。透過這樣的前期調研加上後期不斷嘗試並跟伯克利 AMPLab 及社群溝通，我們最終達成了一致，我們認為 Ray 是融合計算中的最佳實踐方案。

Ray 的優勢恰恰是一開始設計的時候，沒有把自己繫結成某一種場景或計算模式的解決方案， 它是一個真正的原生的分散式框架，可擴充套件性非常強。它不具備任何強封裝的特性，所以可以非常靈活地做一些改動。劣勢的話，Ray 本身是一個很新的框架。我們認為一個計算引擎在推出的前三年其實都是非常原始的狀態，它在未來可能會有比較大的變化，或者會進行比較大的改動。

但其實 Ray 的優勢和劣勢也可以看作兩個互補的特性，它既是一個剛剛推出、很多形態還沒有確定的東西，但它也更原生、更簡單、更容易改造、更容易達成融合的效果，是這樣一個相輔相成的關係。目前來看， 我們相信 Ray 是最適合做雲原生的一套計算架構。

InfoQ：現在還有其他企業也在使用 Ray 這個引擎嗎？ 

周家英： 從官方社群組織的活動或合作伙伴來看，目前阿里巴巴、Facebook、Amazon 這些大公司都有在關注及展開合作，但還處於比較早期的階段，相對來講比例非常少。很多企業可能還只是用 Ray 最原生的 API 或者原生的一些功能來解決很小一部分增強學習問題，或者做一些實驗性的使用， 像螞蟻金服這樣深度參與配合和大規模上線的可能是世界上唯一一家。

InfoQ：螞蟻金服在使用 Ray 的過程中踩過哪些坑？基於 Ray 打造線上學習系統有哪些需要注意的地方？能否分享一下你們的經驗。

周家英：坑有很多。Ray 本身是一個非常新的引擎，剛從實驗室出來和能真正到線上生產之間是有非常大的鴻溝的。比如實驗室可能經常使用一個比較小規模的測試集來測試它的效能穩定性等，但是在企業的生產環境裡，它可能需要更大規模的測試集並進行更嚴格的可靠性的保障，可能中間有許多它之前沒有的功能是我們需要再獨立開發並重新貢獻回給社群的，如可用性、效能最佳化，還有配套的生態，如調優、DevOps 工具，以及部署、排程等這樣跟上下游結合的東西。

除了上面這些工程上的坑，還有一些別的問題。比如 Ray 需要相容 TensorFlow，要實現多語言的排程、多語言的容災等，有很多額外的工作需要做，比如線上訓練過程當中的一些機器學習的特性語言，比如如何進行不同模型的訓練並且不會對其他模型造成影響，比如線上學習如何把噪聲降到最低，如何做版本回滾、如何做線上打通等。

這些都是我們認為比較大的一些特性，也是傳統機器學習體系難以保證的一些點，螞蟻金服圍繞這些點投入了大量精力並做了大量工作，目前我們有幾十個人撲在這個專案上。我們也希望後續能把這些工作回饋給社群。我們  計劃在明年 3 月的時候將線上學習的這套框架和對 Ray 所作的改動全部開源，就是不希望其他公司或使用者再去踩一遍和我們相同的坑。

InfoQ：您認為 Ray 引擎現在是否足夠成熟？什麼樣的企業或場景適合選用 Ray？為什麼？

周家英：以官方開源的 Ray 版本來講，它還是一個相對原始、沒有太多功能的原生態的計算引擎，從這個角度來看，如果其他企業想用 Ray 做 Reinforcement Learning 或者深度學習的計算可能是比較實用的。那如果對應到我們現在內部的 Mobius 版本，它包含一套線上學習的整體研發平臺，同時有流模式、線上學習模式、機器學習模式以及分散式服務等特性的支援。對於這個版本，我認為所有希望快速進行線上學習作業研發的企業都可以使用，因為它已經是一個完整的平臺，我們把業務的計算領域封裝得更好，它更適用於生產環境。

InfoQ：你們是什麼時候開始籌劃把 Ray 的內部版本開源出來的？

周家英： 開源的想法在我們開始做這個專案的時候就有了。我們不希望關起門來做一個東西，而是希望在它發展成熟到一定階段之後，把它變成一個大眾都可以去共享的專案和產品。我們既希望它可以服務於不同客戶部門、不同使用者，也希望使用者可以能貢獻更好的 Feature 進來。

我們希望透過 Ray 構建線上學習系統，讓整個業界的線上學習能力更進一步，比如端到端延遲更低、可用性更高，或者整體的計算體系更內聚，將 Ray 開源肯定會有技術方面的積極影響。如果從這個專案的影響來講，我們也希望透過開源，讓更多的 Contributer 和 Committer 加入進來，把這個專案的特性或能力做得越來越強，同時也可以讓 Ray 這個計算引擎被越來越多的人知道。

InfoQ：螞蟻金服接下來還有什麼技術上的規劃？會關注哪些新技術？

周家英： 大資料計算未來的技術規劃包括幾點，一個是開放式的計算架構；一個是融合的計算引擎，也就是 Ray；還有一體式的全圖計算，所謂大的包含圖計算的場景；然後還有硬體與計算的結合，我們有硬體團隊專門做硬體方面的最佳化使之與計算更加適配，這是我們整體的計劃。

其他新技術還有比如資料湖以及圖計算相關的，包括超大規模圖計算、快速動態圖計算、統一的圖語言等，這些領域我們也都一直在關注。

採訪嘉賓介紹

周家英（徒離），螞蟻金服資深技術專家，現負責資料技術部線上計算團隊。2011 年加入支付寶後，一直參與支付寶資料相關工作。經歷了螞蟻金服從離線資料，實時資料，到目前線上資料的不同的階段，參與過螞蟻實時資料平臺，Serverless Streaming，線上作業排程，計算後設資料，以及新一代計算引擎的建設。熟悉螞蟻資料技術架構演進歷史，對分散式環境下的線上計算場景及高可用方案有切身體會。