RISELab 分布式應用框架Ray項目介紹

Ray 簡介

Ray是UC Berkeley大學 RISE lab（前AMP lab） 2017年12月 開源的新一代分布式應用框架（剛發布的時候定位是高性能分布式計算框架，20年中修改定位為分布式應用框架），通過一套引擎解決復雜場景問題，通過動態計算及狀態共享提高效率，實現研發、運行時、容災一體化

Ray的歷史

Google的三駕馬車（2003年，GFS,BigTable,MapReduce）為分布式系統指明了方向，分布式計算框架也是從MapReduce開始的， Mapreduce提供了一個極簡的編程模型，加上GFS的開源實現HDFS，構成了Hadoop 1.0的架構（2005年，Hadoop 1.0的架構比較簡單，基本是按論文中的框架實現，Hadoop1.0 = Mapreduce + HDFS），在第一階段分布式計算主要以離線計算為主；隨著2010年分布式實時計算系統Storm的推出，分布式計算開始向實時計算演進，但是Storm對流式數據的處理，做到了低延時，卻犧牲了一致性和吞吐量。實際大數據處理業務中，系統需要同時提供低延時和準確性，單靠Storm無法滿足要求，于是誕生了Lamda架構，將hadoop的批能力和Storm的流能力結合，系統整體輸出低延遲并且最終一致的結果。 Spark 2009年誕生于AMPLab， 通過引入彈性分布式數據集RDD的理念，在內存中完成大數據處理，大大加快了處理速度，成為hadoop的實際繼承者， 由于Spark在批處理領域的成功，人們希望把這一成功的設計復制到流處理領域，于是誕生了Spark Streaming, Spark Streaming的思想很簡單，將數據流按時間窗口切分，用批模擬流，在處理有序數據流時，spark streaming可以提供強一致性保證，同時由于批處理的先天優勢，spark streaming可以實現高吞吐量, Spark Streaming 的缺陷在于由于使用微批模擬流，實時性不如真正的流處理，數據延遲通常在秒級甚至分鐘級，同時流量控制方面當系統出現反壓時，會導致大量批次排隊等待，這也是后續的Apache Flink能夠獲取成功的原因。Ray剛推出時，主要是為了解決AI場景下的計算性能和開發效率問題。

Ray要解決的問題

傳統的計算模式和計算引擎是綁定的，從 Flink 到 Spark，一個是流一個是批，二者可以互相轉換，但是很多的特性在轉換的時不順暢，并且有一些優點會丟失（Spark 推出的時候目標就是代替Hadoop做批計算，雖然也可以跑流計算，但是Spark是用批來模擬流；Flink推出的時候是為了代替Storm做更好的流計算，雖然它也可以跑批計算，但是是用流來模擬批，模擬過程中都會有一定的缺陷和先天不足）。同時，圖計算模式其實無法被包括在任何計算引擎之中，因為這些計算引擎在設計的時候已經綁定了一個模式。

Ray的定位為下一代分布式應用框架，所以期望解決的核心問題主要是，提供更簡單的編程模型，更高的吞吐量和更快的響應速度

Ray 架構

Ray的核心設計思路

Ray的架構設計思路是下層有一層抽象和通用的分布式調度能力，可以基于這個原始層，在上面抽象出不同的計算模式，同時把通用能力沉淀到下層，最終變成兩個層級：第一層是計算模式，流、批、圖計算、機器學習都是不同的計算模式；而下面一層是分布式服務，這是一個核心層用來解決調度問題、容災問題、資源恢復等核心問題

Ray在整體技術棧中的位置：

Ray的上下文：

Ray的邏輯架構

Ray 的節點需要運行兩個進程，一個是 RayLet 進程，一個是 Plasma Store（對應圖中的 Object Store）進程。其中 RayLet 進程中維護著一個 Node Manager，和一個 Object Manager。Ray 提供了 Python 的 API，而 RayLet 是用 C++ 實現的。其中的 Node Manager 充當了論文中 Local Scheduler 的角色，主要負責管理 Node 下的 Worker，調度在 Node 上的任務，管理任務間的依賴順序等。而其中的 Object Manager，主要提供了從其他的 Object Manager Pull/Push Object 的能力。

Plasma Store 進程，是一個共享內存的對象存儲進程。原本 Plasma 是 Ray 下的，而目前已經是 Apache Arrow 的一部分了。之前介紹 Ray 在執行帶有 remote 注解的函數時并不會立刻運行，而是會將其作為任務分發，而返回也會被存入 Object Store 中。這里的 Object Store 就是 Plasma。

論文中的 Control State，在實現中被叫做 GCS，是基于 Redis 的存儲。而 GCS 是運行在一類特殊的節點上的。這類特殊的節點被稱作 Head Node。它不僅會運行 GCS，還會運行對其他節點的 Monitor 進程等。

Ray 提交任務的方式與 Spark 非常類似，需要利用 Driver 來提交任務，而任務會在 Worker 上進行執行。Ray 支持的任務分為兩類，分別是任務（Task）和 Actor 方法（ActorMethod）。其中任務就是之前的例子中的被打上了 remote 注解的函數。而 Actor 方法是被打上了 remote 注解的類（或叫做 Actor）的成員方法和構造方法。兩者的區別在于任務都是無狀態的，而 Actor 會保有自己的狀態，因此所有的 Actor 方法需要在 Actor 所在的節點才能執行

Ray的核心優勢和實現

Ray 的優勢是一開始設計的時候，沒有把自己綁定成某一種場景或計算模式的解決方案，它是一個真正的原生的分布式框架，可擴展性非常強。它不具備任何強封裝的特性，所以可以非常靈活地做一些改動。

高效的數據存儲和傳輸：每個節點通過共享內存，維護一個局部的對象存儲（多進程共享使用），同時使用優化的Apache arrow進行節點間的數據交換。

全局的狀態維護：Ray通過全局的狀態存儲服務（Global Control State GCD）來存儲和管理各類任務控制和狀態信息，包括任務拓撲結構信息，數據和任務的生產關系信息，函數之間的調用關系拓撲結構信息。同時將這些狀態信息剝離出來統一管理，可以讓調度器本身成為一個無狀態的服務，從而具備了實現任務遷移、擴展和信息共享的能力

去中心化的高效調度：Ray使用自下而上的層級調度，減少了任務通過全局調度器的中轉開銷。同時通過全局的狀態維護，讓本地調度器也具備獲取全局系統信息的能力，和HA的能力。

actor 模型：為了能和各種需要維護狀態的任務進行交互，比如所模擬的目標系統的狀態變遷，以及其它各種第三方有狀態任務或接口邏輯的封裝（比如通過TensorFlow訓練一個神經網絡模型的任務，這些第三方系統可能無法將內部狀態信息暴露出來交給Ray來管理），Ray也定義了名為Actor的抽象封裝。在Ray中，Actor是一種有狀態的任務，通過暴露特定的方法接口供外部進行遠程調用。而對于Actor的調用歷史，也可以轉化成一種自依賴關系拓撲圖，保存在GCS中。從而將促成Actor內部狀態變遷的調用過程也通過任務圖的方式記錄了下來，從而系統也就具備了Actor狀態重建的能力。

遠程調用：Ray讓用戶通過顯示的定義，如@ray.remote的裝飾器的形式來告知系統需要允許遠程調用的函數。當一個遠程調用函數被定義以后，它就會被推送到所有的工作節點上，已備后續調用。相關的函數代碼也會被存儲到GCS中。這樣后續的任務調度，容錯恢復等過程都能夠更簡單的實現。

Ray的落地場景

Ray在螞蟻金服的若干場景已落地：

動態圖推導，流+圖計算，性能上可以1秒內完成6層迭代查詢，用于實時反套現、欺詐識別；

金融在線決策，流+分布式查詢+在線服務，性能上數據生產到分布式查詢一秒內，用于金融網絡監控、機構渠道路由等；

在線機器學習，流+分布式機器學習，性能上實現秒級數據樣本到模型更新，用于智能營銷、實時推薦、流控等。

金融數據智能的差異化需求：

實時性要求高，實時數據以兩倍以上的速度增長，在線決策越來越多，不再是把數據離線做決策再部署到線上；

計算場景復雜多樣，以前可能是一個簡單的聚合，逐漸進化到用規則做決策，基于圖、基于機器學習等決策，整個計算的形式越來越多樣化；

數據鏈路長，研發調試效率低，當你要做全鏈路數據研發的時候，從頭到尾會經歷十幾個系統，對整體的數據研發提出了很大的挑戰；

計算及存儲高可用，包括跨城市的容災，高可靠的計算服務；

數據安全、監管合規、風險防控，需要做嚴格的數據安全和隱私保護，特別在監管層面要合規。

參考

文檔：http://ray.readthedocs.io/en/latest/index.html

代碼：https://github.com/ray-project/ray

論文：Ray: A Distributed Framework for Emerging AI Applications (https://arxiv.org/pdf/1712.05889.pdf)

RLLib：https://arxiv.org/abs/1712.09381

https://www.jianshu.com/p/a5f8665d84ff

螞蟻金服 https://juejin.cn/post/6844903969718796295

https://www.infoq.cn/article/ualtzk5owdb1crvhg7c1

http://gaocegege.com/Blog/why-do-i-like-ray

spark 分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。