目錄

什么是分布式計算

分布式計算哪家強：Spark、Dask、Ray

2 選擇正確的框架

2.1 Spark

2.2 Dask

2.3 Ray

---

什么是分布式計算

分布式計算是一種計算方法，和集中式計算是相對的。

隨著計算技術(shù)的發(fā)展，有些應(yīng)用需要非常巨大的計算能力才能完成，如果采用集中式計算，需要耗費相當(dāng)長的時間來完成。

分布式計算將該應(yīng)用分解成許多小的部分，分配給多臺計算機(jī)進(jìn)行處理。這樣可以節(jié)約整體計算時間，大大提高計算效率。

分布式計算哪家強：Spark、Dask、Ray

1 歷史
1.1 Apache Spark
Spark是由Matei Zaharia于2009年在加州大學(xué)伯克利分校的AMPLab啟動的。這個項目的主要目的是加快分布式大數(shù)據(jù)任務(wù)的執(zhí)行，在那個時候，這些任務(wù)是由Hadoop MapReduce處理的。MapReduce在設(shè)計時考慮到了可擴(kuò)展性和可靠性，但性能和易用性一直不是它的強項。MapReduce需要不斷將中間結(jié)果存儲到磁盤，這是Spark要克服的關(guān)鍵障礙。Spark通過引入彈性分布式數(shù)據(jù)集（RDD）范式，并利用內(nèi)存緩存和惰性計算的優(yōu)勢，能夠比MapReduce減少幾個數(shù)量級的延遲。這使Spark確立了其作為大規(guī)模、容錯、并行化數(shù)據(jù)處理的事實標(biāo)準(zhǔn)的主導(dǎo)地位。該項目通過添加GraphX（用于分布式圖形處理）、MLlib（用于機(jī)器學(xué)習(xí)）、SparkSQL（用于結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)）等功能得到進(jìn)一步加強。 值得注意的是，Spark是用Scala編寫的，后來又增加了對Python和R的支持，因此與它互動一般不會有Pythonic的感覺。理解RDD范式和Spark中的工作方式需要一點時間來適應(yīng)，但這對任何熟悉Hadoop生態(tài)系統(tǒng)的人來說通常不是問題。

1.2 Dask
Dask是一個用于并行計算的開源庫，它在2015年發(fā)布，所以與Spark相比，它相對較新。該框架最初是由Continuum Analytics（現(xiàn)在的Anaconda Inc.）開發(fā)的，他們是許多其他開源Python包的創(chuàng)造者，包括流行的Anaconda Python發(fā)行。Dask的最初目的只是為了將NumPy并行化，這樣它就可以利用具有多個CPU和核心的工作站計算機(jī)。與Spark不同，Dask開發(fā)中采用的最初設(shè)計原則之一是 "無發(fā)明"。這一決定背后的想法是，使用Dask的工作應(yīng)該讓使用Python進(jìn)行數(shù)據(jù)分析的開發(fā)者感到熟悉，而且升級時間應(yīng)該最小。根據(jù)其創(chuàng)造者的說法，Dask的設(shè)計原則經(jīng)過多年的發(fā)展，現(xiàn)在正被開發(fā)成一個用于并行計算的通用庫。

最初圍繞并行NumPy的想法得到進(jìn)一步發(fā)展，包括一個完整而輕量級的任務(wù)調(diào)度器，可以跟蹤依賴關(guān)系，并支持大型多維數(shù)組和矩陣的并行化。后來又增加了對Pandas DataFrames和scikit-learn并行化的支持。這使該框架能夠緩解Scikit中的一些主要痛點，如計算量大的網(wǎng)格搜索和太大無法完全容納在內(nèi)存中的工作流程。最初的單機(jī)并行化目標(biāo)后來被分布式調(diào)度器的引入所超越，這使Dask能夠在多機(jī)多TB的問題空間中舒適地運行。

1.3 Ray
Ray是加州大學(xué)伯克利分校的另一個項目，其使命是 "簡化分布式計算"。Ray由兩個主要部分組成--Ray Core，它是一個分布式計算框架，而Ray Ecosystem，廣義上講是一些與Ray打包的特定任務(wù)庫（例如Ray Tune--一個超參數(shù)優(yōu)化框架，RaySGD用于分布式深度學(xué)習(xí)，RayRLib用于強化學(xué)習(xí)，等等）。

Ray與Dask類似，它讓用戶能夠以并行的方式在多臺機(jī)器上運行Python代碼。然而，與Dask不同的是，Ray并不模仿NumPy和Pandas的API--它的主要設(shè)計目標(biāo)不是為數(shù)據(jù)科學(xué)工作做一個落地的替代品，而是為Python代碼的并行化提供一個通用的低層次框架。Ray更像是一個通用的集群和并行化框架，可以用來構(gòu)建和運行任何類型的分布式應(yīng)用。由于Ray Core的架構(gòu)方式，它經(jīng)常被認(rèn)為是一個構(gòu)建框架的框架。也有越來越多的項目與Ray集成，以利用加速的GPU和并行計算。 spaCy、Hugging Face和XGBoost都是引入Ray互操作性的第三方庫的例子。

2 選擇正確的框架

這里沒有簡單明了的方法來選擇 "最佳 "框架，就像每個復(fù)雜的問題一樣，答案在很大程度上取決于我們具體工作流程中的背景和許多其他因素。我們需要逐個看看這三個框架，分析它們的優(yōu)劣勢，同時考慮到各種常見的使用情況進(jìn)行選擇。

2.1 Spark

優(yōu)點：

成熟穩(wěn)定：Spark 的原始版本發(fā)布于2014年5月，是比較成熟的技術(shù)。 商業(yè)支持：大量的公司提供商業(yè)支持/服務(wù)。 處理大數(shù)據(jù)集：適用于針對大型數(shù)據(jù)集進(jìn)行數(shù)據(jù)工程/ ETL 類型的任務(wù)。 提供高級 SQL 抽象層（Spark SQL）。 弊端：

需要學(xué)習(xí)新的執(zhí)行模型和API，學(xué)習(xí)曲線陡峭。 調(diào)試?yán)щy。 復(fù)雜的架構(gòu)，僅靠IT部門很難維護(hù)，因為適當(dāng)?shù)木S護(hù)需要了解計算范式和Spark的內(nèi)部運作（如內(nèi)存分配）。 缺少豐富的數(shù)據(jù)可視化生態(tài)系統(tǒng)。 沒有內(nèi)置的GPU加速，需要RAPIDS加速器來訪問GPU資源。

2.2 Dask

優(yōu)點：

純Python框架，非常容易上手。 直接支持Pandas DataFrames和NumPy數(shù)組。 通過Datashader輕松實現(xiàn)對數(shù)十億行的探索性數(shù)據(jù)分析。 提供Dask Bags--它是PySpark RDD的Python版本，具有map、filter、groupby等功能。 Dask能夠帶來令人印象深刻的性能改進(jìn)。 2020年6月，Nvidia使用RAPIDS、Dask和UCX在16個DGX A100系統(tǒng)（128個A100 GPU）上進(jìn)行TPCx-BB測試，取得了驚人的結(jié)果。但是，需要謹(jǐn)慎對待，因為2021年1月，TPC強制Nvidia將該結(jié)果下架，因為它們違反了TPC的公平使用政策。

弊端：

缺乏商業(yè)支持（但有幾家公司已開始在此領(lǐng)域的工作，例如Coiled和QuanSight）。 沒有內(nèi)置的GPU支持，依賴于RAPIDS進(jìn)行GPU加速。

2.3 Ray

優(yōu)點：

最小的集群配置 最適合于計算密集型工作負(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é)點上也是如此。 因為Ray正被越來越多地用于擴(kuò)展不同的ML庫，所以你可以以可擴(kuò)展的、并行的方式一起使用所有的ML庫。另一方面，Spark將你限制在它的生態(tài)系統(tǒng)中可用的框架數(shù)量明顯減少。 獨特的基于actor的抽象，多個任務(wù)可以在同一個集群上異步工作，從而實現(xiàn)更好的利用率（相比之下，Spark的計算模型不太靈活，基于并行任務(wù)的同步執(zhí)行）。 弊端：

相對較新（2017年5月首次發(fā)布）。 不太適合分布式數(shù)據(jù)處理。Ray沒有用于分區(qū)數(shù)據(jù)的內(nèi)置原語。該項目剛剛引入了Ray Datasets，但這是一個全新的補充，仍然非常新且基礎(chǔ)。 對GPU的支持僅限于調(diào)度和預(yù)留。由遠(yuǎn)程函數(shù)來實際利用GPU（通常通過外部庫，如TensorFlow和PyTorch）。 從這三個框架的優(yōu)缺點出發(fā)，我們可以提煉出以下選擇標(biāo)準(zhǔn)：

如果工作負(fù)載是以數(shù)據(jù)為中心的，主要是ETL/預(yù)處理方面的工作，那么我們最好選擇Spark。特別是如果該組織擁有Spark API的機(jī)構(gòu)知識。

Dask/Ray的選擇并不那么明確，但一般的規(guī)則是，Ray旨在加速任何類型的Python代碼，而Dask是面向數(shù)據(jù)科學(xué)特定的工作流程。 為了讓事情變得更加復(fù)雜，還有Dask-on-Ray項目，它允許你在不使用Dask分布式調(diào)度器的情況下運行Dask工作流。 為了更好地理解Dask-on-Ray試圖填補的空白，我們需要看一下Dask框架的核心組件。這些是集合抽象（DataFrames，數(shù)組等），任務(wù)圖（DAG，表示類似于Apache Spark DAG的操作集合），以及調(diào)度器（負(fù)責(zé)執(zhí)行Dask圖）。分布式調(diào)度器是Dask中可用的調(diào)度器之一，它負(fù)責(zé)協(xié)調(diào)分布在多臺機(jī)器上的若干工作進(jìn)程的行動。這個調(diào)度器很好，因為它設(shè)置簡單，保持最小的延遲，允許點對點的數(shù)據(jù)共享，并支持比簡單的map-reduce鏈復(fù)雜得多的工作流。另一方面，分布式調(diào)度程序并非沒有缺點，它的缺點包括：

它是一個單點故障--分布式調(diào)度器沒有高可用性機(jī)制，因此如果它發(fā)生故障，整個集群需要重置，所有正在進(jìn)行的任務(wù)都會丟失。 它是用Python編寫的，這使得它易于安裝和調(diào)試，但也會引入通常與Python搭配使用的標(biāo)準(zhǔn)性能考慮因素。 Client API是為數(shù)據(jù)科學(xué)家設(shè)計的，并不適合從高可用性的生產(chǎn)基礎(chǔ)設(shè)施中調(diào)用（例如，它假定客戶是長期存在的，可能從Jupyter會話中與集群一起工作）。 它對有狀態(tài)執(zhí)行提供的支持很少，所以很難實現(xiàn)容錯的流水線。 它可能會成為瓶頸，并且不能本地擴(kuò)展。 相比之下，容錯和性能是深深嵌入Ray調(diào)度器設(shè)計中的原則。它是完全分散的（沒有瓶頸），提供更快的數(shù)據(jù)共享（通過Apache Plasma），各個調(diào)度器是無狀態(tài)的（容錯），支持有狀態(tài)的Actor等。這使得在Ray集群上運行Dask任務(wù)的吸引力非常明顯，也是Dask-on-Ray調(diào)度器存在的理由。

?