Ray – 面向增強學習場景的分散式計算框架

Ray – 面向增強學習場景的分散式計算框架
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

如果關注這個領域的同學可能知道,Ray其實在去年就已經在開源社群正式釋出了,只不過後來就一直沒有什麼太大動靜,前段時間也是因為機緣巧合,我又回頭學習瞭解了一下,順便總結如下:

Ray是什麼?

Ray 是RISELab實驗室(前身也就是開發Spark/Mesos等的AMPLab實驗室)針對機器學習領域開發的一種新的分散式計算框架。按照官方的定義:“Ray is a flexible, high-performance distributed execution framework”。看起來很明確的定義對吧,不過所謂的:“靈活的高效能的分散式執行框架”,這句話無論是哪個分散式計算框架,大概都會往自己身上套。那麼Ray的不同之處在哪裡呢?當Spark/Flink/TensorFlow等一眾計算框架在機器學習領域中不斷開疆擴土,風頭正勁的時候,為什麼RISELab的同學們又要另起爐灶,再發明一個新的輪子呢?

這個問題的答案和其他發明輪子的同學的說法也很類似:因為既有的系統不滿足某種需求。那麼這種需求是真需求還是偽需求,如果是真需求,既有的系統不能滿足的原因是暫時的,可以改進的,不關本質的具體實現問題,還是由於根源上的架構和方案的侷限性所決定的呢?下面就讓我來現學現賣,分析討論一下。

目標問題

Ray的目標問題,主要是在類似增強學習這樣的場景中所遇到的工程問題。那麼增強學習的場景和普通的機器學習,深度學習的場景又有什麼不同呢?簡單來說,就是對整個處理鏈路流程的時效性和靈活性有更高的要求。

增強學習的場景,按照原理定義,因為沒有預先可用的靜態標籤資訊,所以通常需要引入實際的目標系統(為了加快訓練,往往是目標系統的模擬環境)來獲取反饋資訊,用做損失/收益判斷,進而完成整個訓練過程的閉環反饋。典型的步驟是通過觀察特定目標系統的狀態,收集反饋資訊,判斷收益,用這些資訊來調整引數,訓練模型,並根據新的訓練結果產出可用於調整目標系統的行為Action,輸出到目標系統,進而影響目標系統狀態變化,完成閉環,如此反覆迭代,最終目標是追求某種收益的最大化(比如對AlphoGo來說,收益是贏得一盤圍棋的比賽)。

在這個過程中,一方面,模擬目標系統,收集狀態和反饋資訊,判斷收益,訓練引數,生成Action等等行為可能涉及大量的任務和計算(為了選擇最佳Action,可能要併發模擬眾多可能的行為)。而這些行為本身可能也是千差萬別的異構的任務,任務執行的時間也可能長短不一,執行過程有些可能要求同步,也有些可能更適合非同步。

另一方面,整個任務流程的DAG圖也可能是動態變化的,系統往往可能需要根據前一個環節的結果,調整下一個環節的行為引數或者流程。這種調整,可能是目標系統的需要(比如在自動駕駛過程中遇到行人了,那麼我們可能需要模擬計算剎車的距離來判斷該採取的行動是剎車還是拐彎,而平時可能不需要這個環節),也可能是增強學習特定訓練演算法的需要(比如根據多個並行訓練的模型的當前收益,調整模型超引數,替換模型等等)。

此外,由於所涉及到的目標系統可能是具體的,現實物理世界中的系統,所以對時效性也可能是有強要求的。舉個例子,比如你想要實現的系統是用來控制機器人行走,或者是用來打視訊遊戲的。那麼整個閉環反饋流程就需要在特定的時間限制內完成(比如毫秒級別)。

總結來說,就是增強學習的場景,對分散式計算框架的任務排程延遲,吞吐量和動態修改DAG圖的能力都可能有很高的要求。按照官方的設計目標,Ray需要支援異構計算任務,動態計算鏈路,毫秒級別延遲和每秒排程百萬級別任務的能力。

那麼現有的框架,真的不能滿足這種場景的需求麼?

從上面提到的目標問題來看,需求在對應的場景下是真需求應該問題不大。但現有的框架,通過適當的改進,真的滿足不了這些需求麼?以下我們主要結合Spark/Flink/TensorFlow等常見的當紅分散式計算框架來討論一下這些問題,也算是為Ray的方案選擇再做一下理論和背景鋪墊。

海量任務排程能力

首先來看每秒百萬級別任務排程的能力,上述三種計算框架,基本採用的是中心集中式的任務排程機制,在作業任務排程的角色集中在單箇中心節點的情況下,單個作業要實現每秒百萬級別任務的排程能力,的確是不太現實的。

但問題未必只有一種解決方式,如果不能實現百萬級別的任務排程能力,那麼想辦法降低需要排程的任務的數量就好了。比如像Flink這類以流式計算模型為基礎的框架,往往可以將任務的排程問題轉化為資料和指令的傳輸問題。所以在很多場景下,換一種處理模型,在同樣的場景下,可能就不需要發起大量的任務排程了。

而對於Spark這樣的批處理型框架來說,要提高任務排程的吞吐率,也可以有多種改進方案。比如通過任務樹拆分,批量統一預排程等來分散排程負載,提高排程效率。當然這些框架如果要引入類似的改進,從工程實現的角度來看,需要一定的時間。但是本質上來說,是完全可以實現的,和他們的整體框架的核心思想本身並沒有絕對的衝突。而Spark 2.3的版本中引入的continuous computation的概念,實際上也是用另一種方式,引入預排程的思想,通過建立long run的任務,簡化多個Epoc批次的任務的排程流程,客觀上減少了需要排程的任務的數量,同時,更重要的是對端到端的計算延遲也有顯著改進。

另外,比如各種改進的PS引數伺服器模型,引入各種PS端UDF或儲存過程的實現,實際上從某種意義上來說,也是將一些子任務派發到PS節點去執行,減少了由於框架限制帶來的資料和任務分發問題,客觀上也能降低需要中心節點統一規劃處理的任務的數量和負載。

毫秒級別的延遲

延遲其實有兩個概念,一個是任務排程自身的延遲,另一個是整體資料計算的延遲。當然,前者是後者的基礎,對後者是強相關影響的。對於基於流式計算模型的框架來說,當任務拓撲邏輯確定以後,通常不涉及更多的後續任務排程,所以整體的計算延遲,從流程上來說,只受資料流轉效率的影響。在排除了計算的代價開銷後,基本上就取決於資料傳輸批次Buffer的長度選擇。追求吞吐率就使用較大的buffer來緩衝資料,追求端到端延遲則採用較小的buffer加快流轉,比如Flink就允許使用者定義相關引數。而此外,如前所述,Spark等框架也引入了連續計算模型來規避流式計算場景下的超短週期任務排程問題,從而改進端到端的計算延遲

異構任務的支援

這裡說的異構任務,不光指的是不同型別的任務,還包括同型別的一批任務,由於環境,資料,引數的差異和變化,可能導致的計算時間上的傾斜問題。不管什麼原因,概括起來就是在High level的一次訓練迭代過程中,不同的任務的執行時間可能有很大的差異。

那麼不同的任務,執行時間有差異,會給分散式計算框架的設計帶來什麼影響或者要求嗎?

這裡,主要的問題是,當前多數系統的排程邏輯,容錯策略和執行效能是與同一批次的任務執行時間接近的假設相關的。比如分批次的任務排程,各批次之間的同步可能受最慢的Lagger任務的影響,資源的分配,慢任務的處理策略,往往也基於同批次任務執行時間應該接近的前提假設來設計,當這個前提假設不成立的時候,基本的流程策略的合理性和效能的好壞也就可能會受到比較大的影響。

如果是流式計算框架,鏈路上各計算步驟環節的運算元,往往沒有明確的任務劃分的概念,所以從模型上來說,其實不太涉及異構任務的問題。當然,從資料處理的業務流程上來說,流式計算框架也還是有批次和同步的概念的,比如快照,window,跨流join等環節,就往往需要在各個運算元乃至同一個運算元的多個處理節點之間,達成一定的同步。但這種同步在具體框架的實現中,未必是通過時間域上的所有運算元的絕對同步來實現,也未必涉及框架的排程效能等問題,所以和Ray的目標問題的定義還是有一些區別的,但這就要具體問題具體分析了。

任務拓撲圖動態修改的能力

什麼是動態修改任務拓撲圖的能力呢?其實簡單來說,就是你在編寫程式,或者計算框架在開始啟動任務時,並不能完全確定具體的任務執行流程,需要根據程式執行的中間結果來判斷任務流程或者調整任務的拓撲結構。

所以,對於預先定義好計算邏輯,然後手動定義任務拓撲邏輯或者由框架優化執行計劃並自動生成排程或任務拓撲邏輯的系統來說,不論Spark,Flink,storm還是Tensorflow,在任務執行的過程中,當任務拓撲邏輯已經生成的情況下,確實都不太具備嚴格意義上的動態修改任務拓撲圖的能力。

但是不是一旦使用這些計算框架,就完全不能根據中途的計算結果和狀態變化來調整程式的執行邏輯了呢?顯然不是。

對於批處理型的任務,你完全可以根據上一步的結算結果,走不同的流程,選擇生成下一步邏輯所需的任務拓撲結構。比如Hive任務就可以根據前一個Stage的執行結果,對下一步執行計劃進行篩選,是執行本地Map Join還是走MR任務做Shuffle等。當然,這種修改拓撲圖的能力是在更粗的粒度意義上的,有一定的侷限性。

而對於流式計算框架,你也可以通過傳輸指令,或者狀態變化觸發的方式,在原有的任務拓撲邏輯結構內調整程式的執行邏輯。如果你能預先把所有可能的任務執行邏輯都部署好,通過指令或狀態選擇執行具體的邏輯路徑,一定程度上也能滿足動態修改任務流程的需要。當然,這對拓撲邏輯規劃和具體程式設計也提出了更高的要求。

把上述問題結合起來完整的來看

如前所訴,上述問題需求如果分開來看,現有的框架或多或少都能通過這樣或那樣的方式在一定程度上滿足需求,又或者可以通過別的手段來規避問題,迂迴解決。但是在一個場景下,同時滿足所有的需求,相對來說就比較困難了。

這其中,海量任務的排程能力和毫秒級別的延遲這兩個需求的組合同時滿足是難度之一,現有的框架往往很難同時兼顧,或者只能在特定的約束條件下部分滿足。而對於異構任務的處理和任務拓撲圖的動態修改能力這兩點要求,從靈活性和效能考量方面來看,現有的框架也有很大的侷限性,具體實現時,往往需要使用者在應用邏輯層面自行規劃,實現代價也可能比較高。

總之,好比CAP理論,這些問題要妥善的解決,至少現階段,並沒有面面俱到的完美方案。當前已有的方案,實際上也沒有對錯之分,只是各種計算框架的側重點和取捨不同,那麼Ray是如何進行取捨的呢。

Ray的基本架構設計思路

從任務排程的吞吐率和響應速度這兩方面需求的角度來說,Ray的方案就是分而治之,概括來說,Ray沒有采用中心任務排程的方案,而是採用了類似層級(hierarchy)排程的方案,除了一個全域性的中心排程服務節點(實際上這個中心排程節點也是可以水平拓展的),任務的排程也可以在具體的執行任務的工作節點上,由本地排程服務來管理和執行。

與傳統的層級排程方案,至上而下分配排程任務的方式不同的是,Ray採用了至下而上的排程策略。也就是說,任務排程的發起,並不是先提交給全域性的中心排程器統籌規劃以後再分發給次級排程器的。而是由任務執行節點直接提交給本地的排程器,本地的排程器如果能滿足該任務的排程需求就直接完成排程請求,在無法滿足的情況下,才會提交給全域性排程器,由全域性排程器協調轉發給有能力滿足需求的另外一個節點上的本地排程器去排程執行。

這麼做的好處,一方面減少了跨節點的RPC開銷,另一方面也能規避中心節點的瓶頸問題。當然缺點也不是沒有,由於缺乏全域性的任務檢視,無法進行全域性規劃,因此任務的拓撲邏輯結構也就未必是最優的了。

從支援動態任務拓撲圖和異構任務的角度來說,Ray的思路基本就是別在程式設計模型上做太多假定和約束限制,怎麼靈活怎麼來。問題是這要如何實現呢?

如果在單機上,其實後面兩點要求很簡單。所謂的動態拓撲邏輯,就是各種程式執行分支唄,各種函式呼叫和程式判斷邏輯,天然就是根據當前程式的狀態選擇後續的執行路徑,至於異構任務,不外乎就是不同路徑觸發不同的函式而已,如果需要並行處理,那麼引入多執行緒,非同步呼叫等等機制就好了,對於單機程式來說,這些都是再普通不過的標準實踐,靈活性顯然不是問題。

而Ray的基本設計思想,就是在分散式計算的環境下,實現類似單機執行程式的能力。讓使用者能在函式級別隨意呼叫而不用操心這個函式具體執行的位置,不論從呼叫者的角度還是被呼叫者的角度,結合巢狀呼叫和本地任務排程的能力,整體上的執行流程也就不存在需要預先在中心節點進行規劃部署的問題。

所以Ray的理想的實現,相當於把單機程式的執行能力在不做大的程式設計模型改造的前提下,適配到分散式計算的多節點環境中。如果能做到這一點,顯然前面提到的任務拓撲的動態性和靈活性問題也就不是問題了。

Ray的具體實現

要實現上述思想,從工程的角度來說,有幾個重要的問題需要解決。

首先來看至下而上分而治之的層級排程的實現問題。

本地排程器要能發揮最大的作用,就需要儘量減少任務通過全域性排程器中轉的必要性,因此本地排程器需要具備儘可能完備的獲取系統全域性資訊的能力。此外,在分散式環境下,為了增強系統的魯棒性,工作節點崩潰以後,該節點上本地排程器所管理任務的遷移能力,顯然也是必備的。再有,對於全域性排程器來說,也要具備HA的能力,而全域性排程器的水平拓展能力則是進一步拓展任務排程吞吐率的基本要求。

為了應對這些需求,Ray將任務排程的執行邏輯和任務排程的狀態資訊進行了分離處理。通過全域性的狀態儲存服務(Global Control State GCS)來儲存和管理各類任務控制和狀態資訊,包括任務拓撲結構資訊,資料和任務的生產關係資訊,函式(任務)之間的呼叫關係拓撲結構資訊等等。將這些狀態資訊剝離出來統一管理以後,排程器本身就成為了一個無狀態的服務,因此也就具備了實現前面所說的任務遷移,擴充套件和資訊共享的能力。

此外為了能和各種需要維護狀態的任務進行互動,比如所模擬的目標系統的狀態變遷,以及其它各種第三方有狀態任務或介面邏輯的封裝(比如通過TensorFlow訓練一個神經網路模型的任務,這些第三方系統可能無法將內部狀態資訊暴露出來交給Ray來管理),Ray也定義了名為Actor的抽象封裝。在Ray中,Actor是一種有狀態的任務,通過暴露特定的方法介面供外部進行遠端呼叫。而對於Actor的呼叫歷史,也可以轉化成一種自依賴關係拓撲圖,儲存在GCS中。從而將促成Actor內部狀態變遷的呼叫過程也通過任務圖的方式記錄了下來,從而系統也就具備了Actor狀態重建的能力。

其次,是實現函式能在任何節點上進行遠端呼叫的問題。

Ray讓使用者通過顯示的定義,比如@ray.remote的註解的形式來告知系統需要允許遠端呼叫的函式。當一個遠端呼叫函式被定義以後,它就會被推送到所有的工作節點上,已備後續呼叫。相關的函式程式碼也會被儲存到GCS中。這樣後續的任務排程,容錯恢復等過程都能夠更簡單的實現,

@ray.remote
def f(x):
return x   1

不過由於遠端函式是在定義以後就立刻被推送到工作節點上去的,所以在遠端函式中並不能引用後面的程式碼中所定義的函式/變數(大概是因為需要對閉包進行序列化的原因,而在執行時,無法執行編譯時傳統的二次掃描過程,只能或許截止目前已有的資訊),這個問題,個人感覺對於寫程式碼的同學來說應該是個很大的限制,不排除後續可以有更好的解決辦法。

要使函式能在任意節點上遠端執行,程式碼分發部署的問題解決以後,剩下的就是資料讀寫的問題。被遠端呼叫的函式顯然需要能夠獲取它所需要處理的資料。與程式碼的全域性分發部署不同,資料顯然無法也不適合提前在所有節點上都同步一份。Ray是通過在GCS中儲存一份全域性資料物件列表的方式,來管理各個工作節點上的本地資料。如果一個函式需要處理的資料物件不在工作節點本地,那麼該工作節點上的物件儲存服務(object Store)就會去GCS尋找該物件所在的節點對映資訊,然後從對應節點的Object Store中拷貝一份資料到本地供函式執行時所用。而函式產出的資料物件也會由本地Object Store管理和儲存,並將相關對映資訊登記到GCS中供後續函式呼叫查詢。

這麼做,整體上看起來是把資料往程式碼處移動,和現代大資料環境下,典型的程式碼往資料移動的思想正好相反,貌似又走回到更早期的網格計算的舊路上去了。但實際計算過程中,如果上下游相關的遠端函式呼叫最終被本地排程器排程到同一個工作節點上執行的話,資料實際上是在本地節點的。由於Object Store實現了資料零拷貝的本地共享能力,所以在任務排程合理的情況下,這種方案實際產生的資料拷貝動作的代價可能未必很高。加上高速網路的應用推廣,資料拷貝成為瓶頸的可能性也大大降低,當然,對計算流程的latency還是有一些影響的。此外,因為實際的資料拷貝是在object Store之間直接點對點進行的,所以也不存在資料中轉瓶頸的擔憂。最後,其實這種資料向程式碼移動的設計,我理解和後面要解決的另一個問題:異構任務和任務執行時間傾斜問題的解決方案也是相關的。所以它其實是各種因素綜合考慮以後取捨的結果。

最後來看一下計算框架流程上另一個重要的問題,就是對於異構任務和任務執行時間可能存在傾斜的問題處理。

Ray對於這個問題的解決方案是全面引入Future的概念,任務的執行不僅僅是Lazy的,結果資料的處理更是非同步的。遠端函式的呼叫,會立即返回一個結果資料的Future物件,這個Future物件可以進一步傳遞給下一個遠端函式呼叫,當真正需要讀取資料的時候,才會Block等待資料的真正計算完成。

這麼做的結果,自然就是無法(或者不適合)提前根據資料的位置來確定程式碼執行的位置,因此,客觀的也就導致了資料往程式碼移動,而不是程式碼往資料移動的計算模型。

那麼使用Future的好處是什麼呢?一方面當然是為了儘可能提升並行效率。流程上執行快慢進度不一的任務之間,也不需要互相等待,降低各個任務之間非必要的進度同步的代價。另一方面,在分散式任務執行場景下,具體的演算法策略也可以根據部分任務的執行結果來提前結束一次迭代或著調整計算流程,進而提高程式整體流轉效率。比如,多個子模型同時訓練的時候,根據最先完成的部分模型的結果來決策下一步的行動,使用部分計算結果先行調整模型引數等等。

這種打破全域性批量同步(BSP)模型的應用場景在其它一些機器學習計算框架的實現中也有類似的例子,比如騰訊的Angel引數伺服器所支援的SSP,ASP等處理模型。不過Angel提供的是框架自身定義好的,固定的同步邏輯實現,而Ray的核心框架層,則是通過Future和wait原語的方式將基礎的語義暴露給使用者,讓使用者自己來構建實現所需要的模型邏輯,相對來說更加靈活一些,當然,具體場景的實現代價也就稍微更高一些了。

和當前主流熱門計算框架整體上再比較一下

分散式計算模型的發展歷程就是一個在易用性,靈活性和效率效能之間進行平衡的過程。早期,MapReduce模型通過極度簡化程式設計模型,大大降低了分散式程式設計的難度,但是為了提高程式設計效率,提供更加靈活的應用模型,社群在上層又開發了Hive/Pig等業務語義更加豐富的模型,但限於底層MR模型的約束,在效能上就受到了一定的限制,因此反過來,又促成了比如Tez等模型的發展,出現了Hive on Tez之類的實現。

Spark/Flink/TensorFlow等框架,從各自不同的角度重新定義或著放寬了程式設計模型的約束,增加了系統的靈活性,但本身核心的程式設計模型的使用和實現難度也就更高,開發過程中,需要開發人員對穩定性,效能進行的考慮也往往更多,這就要求這些框架的上層API可以通過封裝和抽象,進一步簡化和降低開發代價,又或者需要應用開發人員投入更多的精力和知識儲備去針對性的解決問題。

Ray的整體設計思想,僅從核心框架的角度來對比的話,可以看到最突出的優勢還是動態構建任務拓撲邏輯圖的能力。因此更加適合一些任務流程複雜,需要按需調整的場景,典型的也就是前文提到的增強學習的場景。而其它的計算框架由於整體程式設計模型約束相對更強,所以要實現複雜的流程場景會更加困難一些,比如需要自行定製一些分散式的處理邏輯,對一些流程進行粘合等。所以,個人認為,Ray的成敗關鍵,就在於在這類應用場景下,能替使用者降低多少開發成本,能讓使用者多大程度上在保留靈活性的同時,減少開發和維護的成本。簡單來說,易用性的好壞或許決定了Ray最終的價值。

比如遠端函式一方面給了使用者靈活切割程式碼邏輯,便於複用邏輯的好處。另一方面,它也需要使用者明確的定義函式的邊界,要求使用者能夠清晰的理順自己程式的分散式執行邏輯,如何切分程式碼邏輯,不同的切分方案對效能是否有影響,函式之間的併發如何設定,如何互動,哪些邏輯適合用無狀態的模式實現,哪些需要構建有狀態的Actor等等,都需要使用者自己來考慮,隨之而來的問題就是應用構建的難度可能更高。如果要降低開發代價,就需要更智慧的解決這個問題,需要上層API層/應用層提供不同層次的抽象,來降低特定場景的應用構建門檻。

用同類系統做個類比,比如,Spark的核心程式設計模型是RDD,它的基本思想就是構建RDD物件,然後按RDD間的依賴關係切分作業任務,遞推執行,這個思想本身很聰明,但如果Spark只是單純提供這個核心思想的基本實現框架的話,顯然不可能成為一個熱門的計算框架,因為使用者的學習成本和開發成本太高了。所以,Spark在上層提供了各類基本運算元,抽象簡化了常見計算流程的開發模式,讓使用者一定程度上無需太多關心RDD的概念細節,而是關注在運算元邏輯的串聯和應用上。但僅僅如此還不夠,RDD為程式設計介面的模型對於多數使用者來說還是門檻太高,所以Spark進一步抽象封裝了包括Stream/SQL/Graph/ML/DataFrame/Dataset在內的各個層級的高層語義或演算法邏輯來進一步降低開發成本,應該說,這些上層API的完善,才是Spark計算框架能夠更好的推廣應用的關鍵所在。

Flink和TensorFlow也不例外,核心的程式設計模型(TensowFlow的核心思想再簡單不過了,資料用Tensor表達,在節點間傳遞Tensor,具體運算元適配和遮蔽底層硬體細節)本身並不是決定他們成敗的關鍵,有太多的類似思想的系統實現,關鍵的是至下而上整體各個層面的具體實現的好壞,完整性和易用性,包括業務表達層的設計,決定了大量同類思想系統的最終命運。

現狀

Ray從一年多前釋出到現在,現狀是API層以上的部分還比較薄弱,Core模組核心邏輯估計也需要時間打磨。這僅從專案的程式碼量大致就可以看出來了,目標如此巨集偉的系統,主要模組目前一共也就兩百多個python檔案和不到一百個C 檔案。

國內目前除了螞蟻金服和RISELab有針對性的合作以外(據說是投入了不少資源的重點專案),關注程度還很低,更沒有什麼實際的應用例項看到,整體來說還處於比較早期的框架構建階段。

當然,Ray在核心Core模組以上,也開始構建類似Ray RLLib這樣的針對增強學習訓練演算法的上層Library。不過目前看來這些library也是非常基本的概念實現,程式碼量都不大。當然,也有可能是Core模組足夠強大,上層演算法策略並不需要寫太多程式碼。不過,不管怎麼說,這塊顯然也是處於早期階段,需要實踐檢驗和打磨,畢竟,能用和好用,中間還有很長的路。類比Spark中圖計算框架的實現,用於實現pregel的幾行程式碼顯然和後面的graphx沒法同日而語。

至於其它的ML/SQL/Stream/Graph之類的實現,暫時沒有看到,理論上Ray目標定位的“靈活的”程式設計模型,也是可以用來實現這些更高層的程式設計語義模型的。但實際上,目前現狀一方面的原因可能是為時尚早,Ray還沒有來得及拓展到這些領域,另一方面,相對於其它計算框架,Ray在這些領域可能也未必有優勢。相反的由於Ray的分層排程模型和資料向程式碼移動的計算模型所帶來的全域性任務的優化難度,在任務拓撲邏輯圖相對固定的場景下,Ray的整體計算效能效率很可能長遠來說,也並不如當前這些主流的計算框架。

所以Ray能否成長成為一個足夠通用的計算框架,目前我覺得還無法判斷,但如果你需要標準化,模式化的解決大量類似增強學習的這種流程複雜的大規模分散式計算問題,那麼Ray至少是一種有益的補充,可能值得關注一下,將它和TensorFlow等框架進行區域性的結合,讓Ray來關注和整合計算處理流程,讓其它系統解決各自擅長的問題,可能也是短期內可行的應用方式,Ray自己目前貌似也是朝著這個所謂的混合計算的方向前進的。

相關文件


常按掃描下面的二維碼,關注“大資料務虛雜談”,務虛,我是認真的 ;)

程式語言 最新文章