介紹三個(gè)最主流的分布式計(jì)算框架Apache Spark、Dask和Ray的歷史、用途和優(yōu)缺點(diǎn)
以便了解如何選擇最適合特定數(shù)據(jù)科學(xué)用例的框架。
1 歷史
1.1 Apache Spark
Spark是由Matei Zaharia于2009年在加州大學(xué)伯克利分校的AMPLab啟動(dòng)的。這個(gè)項(xiàng)目的主要目的是加快分布式大數(shù)據(jù)任務(wù)的執(zhí)行，在那個(gè)時(shí)候，這些任務(wù)是由Hadoop MapReduce處理的。MapReduce在設(shè)計(jì)時(shí)考慮到了可擴(kuò)展性和可靠性，但性能和易用性一直不是它的強(qiáng)項(xiàng)。MapReduce需要不斷將中間結(jié)果存儲(chǔ)到磁盤，這是Spark要克服的關(guān)鍵障礙。Spark通過引入彈性分布式數(shù)據(jù)集（RDD）范式，并利用內(nèi)存緩存和惰性計(jì)算的優(yōu)勢，能夠比MapReduce減少幾個(gè)數(shù)量級(jí)的延遲。這使Spark確立了其作為大規(guī)模、容錯(cuò)、并行化數(shù)據(jù)處理的事實(shí)標(biāo)準(zhǔn)的主導(dǎo)地位。該項(xiàng)目通過添加GraphX（用于分布式圖形處理）、MLlib（用于機(jī)器學(xué)習(xí)）、SparkSQL（用于結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)）等功能得到進(jìn)一步加強(qiáng)。 值得注意的是，Spark是用Scala編寫的，后來又增加了對Python/ target=_blank class=infotextkey>Python和R的支持，因此與它互動(dòng)一般不會(huì)有Pythonic的感覺。理解RDD范式和Spark中的工作方式需要一點(diǎn)時(shí)間來適應(yīng)，但這對任何熟悉Hadoop生態(tài)系統(tǒng)的人來說通常不是問題。
1.2 Dask
Dask是一個(gè)用于并行計(jì)算的開源庫，它在2015年發(fā)布，所以與Spark相比，它相對較新。該框架最初是由Continuum Analytics（現(xiàn)在的Anaconda Inc.）開發(fā)的，他們是許多其他開源Python包的創(chuàng)造者，包括流行的Anaconda Python發(fā)行。Dask的最初目的只是為了將NumPy并行化，這樣它就可以利用具有多個(gè)CPU和核心的工作站計(jì)算機(jī)。與Spark不同，Dask開發(fā)中采用的最初設(shè)計(jì)原則之一是 "無發(fā)明"。這一決定背后的想法是，使用Dask的工作應(yīng)該讓使用Python進(jìn)行數(shù)據(jù)分析的開發(fā)者感到熟悉，而且升級(jí)時(shí)間應(yīng)該最小。根據(jù)其創(chuàng)造者的說法，Dask的設(shè)計(jì)原則經(jīng)過多年的發(fā)展，現(xiàn)在正被開發(fā)成一個(gè)用于并行計(jì)算的通用庫。
最初圍繞并行NumPy的想法得到進(jìn)一步發(fā)展，包括一個(gè)完整而輕量級(jí)的任務(wù)調(diào)度器，可以跟蹤依賴關(guān)系，并支持大型多維數(shù)組和矩陣的并行化。后來又增加了對Pandas DataFrames和scikit-learn并行化的支持。這使該框架能夠緩解Scikit中的一些主要痛點(diǎn)，如計(jì)算量大的網(wǎng)格搜索和太大無法完全容納在內(nèi)存中的工作流程。最初的單機(jī)并行化目標(biāo)后來被分布式調(diào)度器的引入所超越，這使Dask能夠在多機(jī)多TB的問題空間中舒適地運(yùn)行。
1.3 Ray
Ray是加州大學(xué)伯克利分校的另一個(gè)項(xiàng)目，其使命是 "簡化分布式計(jì)算"。Ray由兩個(gè)主要部分組成--Ray Core，它是一個(gè)分布式計(jì)算框架，而Ray Ecosystem，廣義上講是一些與Ray打包的特定任務(wù)庫（例如Ray Tune--一個(gè)超參數(shù)優(yōu)化框架，RaySGD用于分布式深度學(xué)習(xí)，RayRLib用于強(qiáng)化學(xué)習(xí)，等等）。
Ray與Dask類似，它讓用戶能夠以并行的方式在多臺(tái)機(jī)器上運(yùn)行Python代碼。然而，與Dask不同的是，Ray并不模仿NumPy和Pandas的API--它的主要設(shè)計(jì)目標(biāo)不是為數(shù)據(jù)科學(xué)工作做一個(gè)落地的替代品，而是為Python代碼的并行化提供一個(gè)通用的低層次框架。Ray更像是一個(gè)通用的集群和并行化框架，可以用來構(gòu)建和運(yùn)行任何類型的分布式應(yīng)用。由于Ray Core的架構(gòu)方式，它經(jīng)常被認(rèn)為是一個(gè)構(gòu)建框架的框架。也有越來越多的項(xiàng)目與Ray集成，以利用加速的GPU和并行計(jì)算。 spaCy、Hugging Face和XGBoost都是引入Ray互操作性的第三方庫的例子。
2 選擇正確的框架
這里沒有簡單明了的方法來選擇 "最佳 "框架，就像每個(gè)復(fù)雜的問題一樣，答案在很大程度上取決于我們具體工作流程中的背景和許多其他因素。我們需要逐個(gè)看看這三個(gè)框架，分析它們的優(yōu)劣勢，同時(shí)考慮到各種常見的使用情況進(jìn)行選擇。
2.1 Spark
優(yōu)點(diǎn)：
成熟穩(wěn)定：Spark 的原始版本發(fā)布于2014年5月，是比較成熟的技術(shù)。 商業(yè)支持：大量的公司提供商業(yè)支持/服務(wù)。 處理大數(shù)據(jù)集：適用于針對大型數(shù)據(jù)集進(jìn)行數(shù)據(jù)工程/ ETL 類型的任務(wù)。 提供高級(jí) SQL 抽象層（Spark SQL）。 弊端：
需要學(xué)習(xí)新的執(zhí)行模型和API，學(xué)習(xí)曲線陡峭。 調(diào)試?yán)щy。 復(fù)雜的架構(gòu)，僅靠IT部門很難維護(hù)，因?yàn)檫m當(dāng)?shù)木S護(hù)需要了解計(jì)算范式和Spark的內(nèi)部運(yùn)作（如內(nèi)存分配）。 缺少豐富的數(shù)據(jù)可視化生態(tài)系統(tǒng)。 沒有內(nèi)置的GPU加速，需要RAPIDS加速器來訪問GPU資源。
2.2 Dask
優(yōu)點(diǎn)：
純Python框架，非常容易上手。 直接支持Pandas DataFrames和NumPy數(shù)組。 通過Datashader輕松實(shí)現(xiàn)對數(shù)十億行的探索性數(shù)據(jù)分析。 提供Dask Bags--它是PySpark RDD的Python版本，具有map、filter、groupby等功能。 Dask能夠帶來令人印象深刻的性能改進(jìn)。 2020年6月，Nvidia使用RAPIDS、Dask和UCX在16個(gè)DGX A100系統(tǒng)（128個(gè)A100 GPU）上進(jìn)行TPCx-BB測試，取得了驚人的結(jié)果。但是，需要謹(jǐn)慎對待，因?yàn)?021年1月，TPC強(qiáng)制Nvidia將該結(jié)果下架，因?yàn)樗鼈冞`反了TPC的公平使用政策。 弊端：
缺乏商業(yè)支持（但有幾家公司已開始在此領(lǐng)域的工作，例如Coiled和QuanSight）。 沒有內(nèi)置的GPU支持，依賴于RAPIDS進(jìn)行GPU加速。
2.3 Ray
優(yōu)點(diǎn)：
最小的集群配置 最適合于計(jì)算密集型工作負(fù)載。已經(jīng)有證據(jù)表明，Ray在某些機(jī)器學(xué)習(xí)任務(wù)上的表現(xiàn)優(yōu)于Spark和Dask，如NLP、文本規(guī)范化和其他。此外，Ray的工作速度比Python標(biāo)準(zhǔn)多處理快10%左右，即使是在單節(jié)點(diǎn)上也是如此。 因?yàn)镽ay正被越來越多地用于擴(kuò)展不同的ML庫，所以你可以以可擴(kuò)展的、并行的方式一起使用所有的ML庫。另一方面，Spark將你限制在它的生態(tài)系統(tǒng)中可用的框架數(shù)量明顯減少。 獨(dú)特的基于actor的抽象，多個(gè)任務(wù)可以在同一個(gè)集群上異步工作，從而實(shí)現(xiàn)更好的利用率（相比之下，Spark的計(jì)算模型不太靈活，基于并行任務(wù)的同步執(zhí)行）。 弊端：
相對較新（2017年5月首次發(fā)布）。 不太適合分布式數(shù)據(jù)處理。Ray沒有用于分區(qū)數(shù)據(jù)的內(nèi)置原語。該項(xiàng)目剛剛引入了Ray Datasets，但這是一個(gè)全新的補(bǔ)充，仍然非常新且基礎(chǔ)。 對GPU的支持僅限于調(diào)度和預(yù)留。由遠(yuǎn)程函數(shù)來實(shí)際利用GPU（通常通過外部庫，如TensorFlow和PyTorch）。 從這三個(gè)框架的優(yōu)缺點(diǎn)出發(fā)，我們可以提煉出以下選擇標(biāo)準(zhǔn)：
如果工作負(fù)載是以數(shù)據(jù)為中心的，主要是ETL/預(yù)處理方面的工作，那么我們最好選擇Spark。特別是如果該組織擁有Spark API的機(jī)構(gòu)知識(shí)。 Dask/Ray的選擇并不那么明確，但一般的規(guī)則是，Ray旨在加速任何類型的Python代碼，而Dask是面向數(shù)據(jù)科學(xué)特定的工作流程。 為了讓事情變得更加復(fù)雜，還有Dask-on-Ray項(xiàng)目，它允許你在不使用Dask分布式調(diào)度器的情況下運(yùn)行Dask工作流。 為了更好地理解Dask-on-Ray試圖填補(bǔ)的空白，我們需要看一下Dask框架的核心組件。這些是集合抽象（DataFrames，數(shù)組等），任務(wù)圖（DAG，表示類似于Apache Spark DAG的操作集合），以及調(diào)度器（負(fù)責(zé)執(zhí)行Dask圖）。分布式調(diào)度器是Dask中可用的調(diào)度器之一，它負(fù)責(zé)協(xié)調(diào)分布在多臺(tái)機(jī)器上的若干工作進(jìn)程的行動(dòng)。這個(gè)調(diào)度器很好，因?yàn)樗O(shè)置簡單，保持最小的延遲，允許點(diǎn)對點(diǎn)的數(shù)據(jù)共享，并支持比簡單的map-reduce鏈復(fù)雜得多的工作流。另一方面，分布式調(diào)度程序并非沒有缺點(diǎn)，它的缺點(diǎn)包括：
它是一個(gè)單點(diǎn)故障--分布式調(diào)度器沒有高可用性機(jī)制，因此如果它發(fā)生故障，整個(gè)集群需要重置，所有正在進(jìn)行的任務(wù)都會(huì)丟失。 它是用Python編寫的，這使得它易于安裝和調(diào)試，但也會(huì)引入通常與Python搭配使用的標(biāo)準(zhǔn)性能考慮因素。 Client API是為數(shù)據(jù)科學(xué)家設(shè)計(jì)的，并不適合從高可用性的生產(chǎn)基礎(chǔ)設(shè)施中調(diào)用（例如，它假定客戶是長期存在的，可能從Jupyter會(huì)話中與集群一起工作）。 它對有狀態(tài)執(zhí)行提供的支持很少，所以很難實(shí)現(xiàn)容錯(cuò)的流水線。 它可能會(huì)成為瓶頸，并且不能本地?cái)U(kuò)展。 相比之下，容錯(cuò)和性能是深深嵌入Ray調(diào)度器設(shè)計(jì)中的原則。它是完全分散的（沒有瓶頸），提供更快的數(shù)據(jù)共享（通過Apache Plasma），各個(gè)調(diào)度器是無狀態(tài)的（容錯(cuò)），支持有狀態(tài)的Actor等。這使得在Ray集群上運(yùn)行Dask任務(wù)的吸引力非常明顯，也是Dask-on-Ray調(diào)度器存在的理由。
3 如何做出選擇
現(xiàn)在我們已經(jīng)看過了Spark、Dask和Ray的優(yōu)缺點(diǎn)--并簡要討論了Dask-on-Ray混合解決方案，很明顯這不是“一刀切”的情況。這三個(gè)框架從一開始就有不同的設(shè)計(jì)目標(biāo)，試圖把根本不同的工作流程硬塞到其中一個(gè)框架中不是最明智的選擇。更好的方法是以靈活性為基礎(chǔ)設(shè)計(jì)數(shù)據(jù)科學(xué)流程和相應(yīng)的基礎(chǔ)架構(gòu)，最好能夠讓您啟動(dòng)并使用適合工作的正確工具。一個(gè)典型的流程可能涉及在Spark中進(jìn)行一些類似ETL的數(shù)據(jù)處理，然后在Ray中執(zhí)行機(jī)器學(xué)習(xí)工作流。提供自由度以控制、容錯(cuò)和按需方式運(yùn)行兩個(gè)框架，使數(shù)據(jù)科學(xué)團(tuán)隊(duì)能夠利用兩個(gè)框架的優(yōu)勢。
從Spark（DataFrames）到Ray（分布式訓(xùn)練）再返回到Spark（Transformer）的流程的高級(jí)概述。Ray Estimator在Spark Estimator接口中封裝了這種復(fù)雜性。
混合使用框架的重要性已經(jīng)顯而易見，因?yàn)槌霈F(xiàn)了使這種跨框架通信更加簡化的集成庫。例如，Spark on Ray正是這樣做的--它 "結(jié)合了你的Spark和Ray集群，使你可以輕松地使用PySpark API進(jìn)行大規(guī)模數(shù)據(jù)處理，并無縫地使用這些數(shù)據(jù)來使用TensorFlow和PyTorch訓(xùn)練你的模型。"還有Ray on Spark項(xiàng)目，它允許我們在Apache Hadoop/YARN上運(yùn)行Ray程序。這種方法也已經(jīng)成功地在實(shí)際生產(chǎn)工作負(fù)載中得到了測試。例如，Uber的機(jī)器學(xué)習(xí)平臺(tái)Michelangelo定義了一個(gè)Ray Estimator API，該API抽象了終端用戶在Spark和Ray之間移動(dòng)的過程。Uber工程公司最近的出版物中詳細(xì)介紹了這一點(diǎn)，該出版物涵蓋了涉及Spark和XGBoost在Ray上的分布式訓(xùn)練的架構(gòu)。
4 總結(jié)
在這文中，我們介紹了三種最流行的并行計(jì)算框架。我們討論了它們的優(yōu)缺，并給出了一些關(guān)于如何為手頭的任務(wù)選擇正確框架的一般性指導(dǎo)。推薦的方法不是尋找適合所有可能的需求或用例的終極框架，而是理解它們?nèi)绾芜m合各種工作流程，并擁有一個(gè)靈活的數(shù)據(jù)科學(xué)基礎(chǔ)架構(gòu)，使該基礎(chǔ)設(shè)施允許采用混合和匹配方法。
