Spark、Day、Ray：歷史概要
Apache Spark
Spark由加州大學伯克利分校AMPLab的Matei Zaharia於2009年創建。這個項目的主要目的是爲了加快分佈式大數據任務的執行速度，而當時的分佈式大數據任務是由Hadoop MapReduce處理的。MapReduce在設計時考慮到了可伸縮性和可靠性，但性能或易用性卻不是它的強項。MapReduce不斷需要將中間結果存儲到磁盤，這是Spark要克服的關鍵障礙。通過引入彈性分佈式數據集(RDD)範式，並利用內存緩存和延遲計算，與MapReduce相比Spark能夠將延遲降低幾個數量級。這使得Spark成爲大規模、容錯和並行數據處理事實上的標準。GraphX（用於分佈式圖形處理），MLLIB（用於機器學習），SparkSQL（用於結構化和半結構化數據）等組件的加入進一步增強了該項目。
值得注意的是，Spark是用Scala編寫的，隨後添加了Python和R支持，因此與它交互通常感覺不夠Pythonic。理解RDD範式以及如何在Spark中完成工作需要一些時間，但對於熟悉Hadoop生態系統的人來說，這通常不是問題。
Dask
Dask是發佈於2015年的一個用於並行計算的開源庫，所以與Spark相比它比較新。這個框架原本是ContinuumAnalytics（現Anaconda公司）開發的，這個公司是很多Python開源包的創造者，包括Anaconda Python發行版。Dask最初的目的只是將NumPy並行化，這樣它就可以利用具有多個cpu和核的工作站計算機。與Spark不同，在Dask開發中採用的最初設計原則之一是“什麼都不發明”。這一決定背後的想法是，與Dask一起使用Python進行數據分析應該讓開發人員感到熟悉，並且知識升級時間應該很短。根據其創建者的說法，Dask的設計原則經過了多年的發展，現在它正在被開發成一個用於並行計算的通用庫。
圍繞平行numpy的初始想法，進一步發展到包括一個完全成熟的、輕量級的任務調度器，它可以跟蹤依賴關係並支持大型多維數組和矩陣的並行化。後來，並行化的Pandas DataFrames和scikit-learn得到了進一步的支持。這使得該框架能夠緩解Scikit的一些主要痛點，比如計算量大的網格搜索和太大而無法完全放入內存的工作流。最初的單機並行化目標後來被引入的分佈式調度超越了，該計劃現在使Dask能夠在多機多TB問題空間中舒適地運行。
Ray
Ray是加州大學伯克利分校的另一個項目，其使命是“簡化分佈式計算”。Ray由兩個主要組件組成——Ray Core(一個分佈式計算框架)和Ray Ecosystem(廣義上說，Ray Ecosystem是與Ray打包的一系列特定於任務的庫)(例如，Ray Tune——一個超參數優化框架，用於分佈式深度學習的RaySGD，用於強化學習的RayRLib等等)。
Ray類似於Dask，因爲它允許用戶在多臺機器上以並行的方式運行Python代碼。然而，與Dask不同的是，Ray並沒有試圖模擬NumPy和Pandas 接口——它的主要設計目標不是臨時替代Data Science的工作負載，而是提供一個通用的底層框架來並行化Python代碼。這使得它更像一個通用的集羣和並行框架，可以用來構建和運行任何類型的分佈式應用程序。由於Ray Core的架構方式，它經常被認爲是一個用於構建框架的框架。還有越來越多的項目與Ray集成，以利用加速GPU和並行計算。spaCy、hugs Face和XGBoost都是引入Ray互操作性的第三方庫的例子。
選擇合適的框架
不幸的是，沒有簡單直接的方法來選擇“最好的”框架。每個複雜的問題都是如此，答案很大程度上取決於環境和在我們特定工作流程中發揮作用的許多其他因素。讓我們看看這三個框架，並考慮它們的優點和缺點，同時考慮各種常見的用例。
Spark
-
優勢
- 技術成熟(2014年5月發佈)
- 大量公司提供商業服務支持
- 針對大型數據集的數據工程 / ETL任務類型的理想選擇。
- 提供高層SQL抽象（Spark SQL）
-
劣勢
- 涉及新的執行模型和API的陡峭學習曲線。
- 調試困難
- 複雜的體系結構使得IT很難單獨維護，因爲適當的維護需要了解SPARK的計算範式和內部工作（例如，內存分配）
- 缺乏豐富的數據可視化生態
- 沒有內建GPU加速，需要 RAPIDS Accelerator（激流加速器）來訪問GPU資源
Dask
- 優勢
- 純Python框架-非常容易學習和切換
- 對Pandas DataFrames和NumPy 數組有開箱即用的支持
- 通過Datashader可以很容易對數十億行數據進行探索性分析
- 提供Dask Bags ：一個Pythonic版本的PySpark RDD，帶有map、filter、groupby等函數功能
- Dask可以帶來令人印象深刻的性能改進。2020年6月，英偉達公佈了在16個DGX A100系統(128個A100 gpu)上使用RAPIDS、Dask和UCX進行TPCx-BB測試的驚人結果 results on the TPCx-BB 。然而，對此我們還是持保留態度。2021年1月，TPC迫使英偉達將這些結果撤下，因爲它們違反了TPC的合理使用政策
- 劣勢
- 目前還沒有太多的商業支持(但有幾家公司已經開始在這個領域開展工作，例如Coiled和QuanSight)。
- 沒有內置的GPU支持。依靠RAPIDS 來加速GPU
Ray
- 優勢
- 最小集羣配置
- 最適合計算繁重的工作負載。已經有研究表明，Ray在某些機器學習任務(如NLP、文本規範化等)上的表現優於Spark和Dask。最重要的是，即使在單個節點上也是如此，Ray的工作速度似乎比Python標準多進程快10%左右
- 因爲Ray越來越多地被用於擴展不同的ML庫，所以您可以以一種可擴展的、並行的方式將它們一起使用。另一方面，Spark將您限制在其生態系統中可用的框架數量少得多
- 獨特的基於Actor的抽象，多個任務可以異步地在同一個集羣上工作，從而獲得更好的利用率(相比之下，Spark的計算模型沒有那麼靈活，而是基於並行任務的同步執行)。
- 劣勢
- 相對較新(首次發佈於2017年5月)
- 並不是針對分佈式數據處理量身定製的。Ray沒有用於分區數據的內置原語。該項目只是剛剛引入 Ray Datasets，但這是一個全新的添加，仍然是相當新只有一個簡單的骨架。
- GPU支持僅限於調度和預訂。實際怎樣使用GPU取決於遠程功能（通常是通過TensorFlow和Pytorch等外部庫）
通過分析這三個框架的優缺點，我們可以總結出以下選擇標準：
- 如果工作負載以數據爲中心，並且更多地圍繞ETL/預處理，那麼我們最好的選擇就是Spark。特別是如果組織對Spark API有系統化認知
- Dask/Ray選擇並不是那麼明確，但一般規則是Ray旨在加快任何類型的Python代碼，Dask適合於數據科學特定的工作流程
讓事情更復雜的是，還有一個Dask-on- Ray項目，它允許你運行Dask工作流而不使用Dask分佈式調度器。爲了更好地理解Dask-on- Ray試圖填補的空白，我們需要看看Dask框架的核心組件。其中包含集合抽象(DataFrames、數組等)、任務圖(一個DAG，它代表了一組類似於Apache Spark DAG的操作)和調度器(負責執行Dask圖)。分佈式調度器是Dask中可用的調度器之一，它負責協調分佈在多臺機器上的多個工作進程的操作。這個調度器非常棒，因爲它易於設置、保持最小的延遲、允許點對點數據共享，並支持比簡單的map-reduce鏈複雜得多的工作流。另一方面，分佈式調度器也不是沒有缺陷。它的一些缺點包括：
- 它是一個單點 - 分佈式調度程序沒有高可用性機制，因此，如果失敗，則需要重置整個羣集，並且所有過程中的任務都會丟失。
- 它是用Python編寫的，這使得它易於安裝和調試，但它也引入了通常與Python一起使用的標準性能考慮因素。
- Client API在設計時考慮到了數據科學家，並沒有針對來自高可用性生產基礎設施的調用進行定製(例如，它假設客戶端是長期存在的，可能通過Jupyter會話在集羣上操作)
- 它對有狀態執行提供了最低限度的支持，因此很難實現容錯管道。
- 它可能會成爲瓶頸，而且無法自行擴展
相比之下，容錯和性能是深深嵌入在Ray調度器設計中的原則。它是完全去中心化的(沒有瓶頸)、提供更快的數據共享(通過Apache Plasma)、單個調度器是無狀態的(容錯)、支持有狀態的參與者等等。這使得在Ray集羣上運行Dask任務具有很大吸引力是非常可以理解的，這也是être搞Dask-on-Ray調度器的原因。對Dask -on- Ray項目的深入研究超出了這篇博文的範圍，但是如果你有興趣更深入地比較兩者的性能，請隨意查看Anyscale所做的內存管理和性能基準測試。
如何做出自己的選擇？（提示：你真的需要嗎？）
現在我們已經看了Spark、Dask和Ray的優缺點，在簡要討論了Dask-on-Ray的混合方案後，很明顯這不是“一刀切”的情況。這三個框架從一開始就有不同的設計目標，試圖將根本上不同的工作流程塞到一個框架中可能不是最明智的選擇。一種更好的方法是在設計數據科學流程和配套基礎設施時考慮到靈活性，理想情況下使您能夠使用正確的工具完成工作。典型的流程管道可能涉及在Spark中執行一些類似etl的數據處理，然後在Ray中執行機器學習工作流。如果平臺能夠以可控、容錯和隨需應變的方式自由運行，那麼數據科學團隊就能夠利用這兩種框架的優點。
從Spark（DataFrames）到Ray（分佈式訓練）再到Spark（轉換）的高層概述。Ray評估器將這種複雜性封裝在Spark評估器接口中。圖片來源：https://eng.uber.com/elastic-xgboost-ray/
混合框架的重要性已經通過集成庫的出現得到了明顯體現，這些集成庫使框架間的通信更加精簡流線化。比如，Spark on Ray 正是這樣做的——它“結合你的Spark和Ray集羣，使用PySpark API輕鬆地進行大規模數據處理，並使用TensorFlow和PyTorch無縫地使用這些數據來訓練你的模型“。還有 Ray on Spark 項目它使我們能夠在Apache Hadoop/Yarn上運行Ray程序。這種方法已經在實際的生產工作負載中成功地測試過了。例如，Uber的機器學習平臺 Michelangelo定義了Ray Extiator API，該API爲終端用戶抽象了在Spark和Ray之間移動的過程。Uber Engineering最近發佈的一篇文章詳細介紹了這一點，其中介紹了一種涉及Spark和XGBoost on Ray的分佈式培訓架構。
總結
本文介紹了三個最流行的並行計算框架。討論了它們的優點和缺點，並就如何爲手頭的任務選擇正確的框架給出了一些一般性的指導。推薦的方法不是尋找適合所有可能的需求或用例的最終框架，而是理解它們如何適應各種工作流，並擁有足夠靈活的數據科學基礎設施，以允許混合匹配方法。