目次
分散コンピューティングではどれが優れていますか: Spark、Dask、Ray
分散コンピューティングとは
分散コンピューティングは、集中型コンピューティングに関連するコンピューティング手法です。
コンピューティング技術の発展に伴い、アプリケーションによっては完成までに膨大なコンピューティング能力を必要とするものもあり、集中コンピューティングを使用すると完成までに長い時間がかかります。
分散コンピューティングでは、アプリケーションを多くの小さな部分に分割し、複数のコンピューターに分散して処理します。これにより、全体の計算時間が節約され、計算効率が大幅に向上します。
分散コンピューティングではどれが優れていますか: Spark、Dask、Ray
1 歴史
1.1 Apache Spark
Spark は、2009 年にカリフォルニア大学バークレー校の AMPLab の Matei Zaharia によって開始されました。このプロジェクトの主な目的は、当時 Hadoop MapReduce によって処理されていた分散ビッグ データ タスクの実行を高速化することです。MapReduce はスケーラビリティと信頼性を念頭に置いて設計されましたが、パフォーマンスと使いやすさはそれほど得意ではありませんでした。MapReduce は中間結果を常にディスクに保存する必要がありますが、これは Spark が克服すべき重要な障害です。Resilient Distributed Dataset (RDD) パラダイムを導入し、メモリ キャッシュと遅延コンピューティングを利用することにより、Spark は MapReduce と比較してレイテンシを数桁削減できます。これにより、Spark は、大規模でフォールト トレラントな並列データ処理の事実上の標準として、支配的な地位を確立することができました。このプロジェクトは、GraphX (分散グラフ処理用)、MLlib (機械学習用)、SparkSQL (構造化データおよび半構造化データ用) などの機能を追加することでさらに強化されました。Spark は Scala で書かれており、Python と R のサポートは後で追加されたため、Spark の操作は一般に Python 的とは感じられないことに注意してください。RDD パラダイムと Spark での仕組みを理解するには、少し慣れる必要がありますが、Hadoop エコシステムに精通している人にとっては、通常は問題ありません。
1.2 Dask
Dask は並列コンピューティング用のオープンソース ライブラリで、2015 年にリリースされたため、Spark と比較すると比較的新しいです。このフレームワークは元々、人気のある Anaconda Python ディストリビューションを含む他の多くのオープン ソース Python パッケージの作成者である Continuum Analytics (現在は Anaconda Inc.) によって開発されました。Dask の当初の目的は、単にNumPy を並列化して、複数の CPU とコアを備えたワークステーション コンピューターを利用できるようにすることでした。Spark とは異なり、Dask の開発で採用された当初の設計原則の 1 つは「発明なし」でした。この決定の背後にある考え方は、データ分析に Python を使用する開発者にとって Dask の使用が親しみやすく感じられるべきであり、アップグレードにかかる時間が最小限に抑えられるべきであるということです。作成者によると、Dask の設計原則は長年にわたって進化しており、現在は並列コンピューティング用の汎用ライブラリとして開発されています。
NumPy の並列化に関する元のアイデアはさらに開発され、依存関係を追跡し、大規模な多次元配列と行列の並列化をサポートできる完全で軽量のタスク スケジューラが組み込まれました。その後、Pandas DataFrames と scikit-learn 並列化のサポートが追加されました。これにより、フレームワークは、計算コストのかかるグリッド検索や、大きすぎてメモリに完全に収まらないワークフローなど、Scikit の主要な問題点の一部を軽減できます。当初の単一マシン並列化の目標は、後に分散スケジューラの導入によって達成され、これにより、Dask が複数マシン、数テラバイトの問題空間で快適に実行できるようになりました。
1.3 Ray
Ray は、「分散コンピューティングを簡素化する」という使命を持つ、カリフォルニア大学バークレー校のもう 1 つのプロジェクトです。Ray は、分散コンピューティング フレームワークである Ray Core と、Ray エコシステムという 2 つの主要な部分で構成されています。Ray エコシステムは、大まかに言えば、Ray にパッケージ化されたいくつかのタスク固有のライブラリ (分散深層学習のために RaySGD で使用されるハイパーパラメータ最適化フレームワークである Ray Tune など) 、強化学習用の RayRLib など）。
Ray は、ユーザーが複数のマシンで Python コードを並行して実行できるという点で Dask に似ています。ただし、Dask とは異なり、Ray は NumPy や Pandas の API を模倣していません。その主な設計目標は、データ サイエンス作業のドロップイン置き換えではなく、Python コード フレームの一般的な低レベルの並列化を提供することです。Ray は、あらゆるタイプの分散アプリケーションを構築および実行するために使用できる、汎用のクラスターおよび並列化フレームワークに似ています。Ray Core はその設計方法のため、フレームワークを構築するためのフレームワークとして考えられることがよくあります。また、高速化された GPU と並列コンピューティングを活用するために Ray と統合するプロジェクトの数も増えています。spaCy、Hugging Face、XGBoost は、Ray の相互運用性を導入するサードパーティ ライブラリの例です。
2 適切なフレームを選択する
ここで「最適な」フレームワークを選択する簡単な方法はありません。すべての複雑な質問と同様、答えは特定のワークフローのコンテキストやその他の多くの要素に大きく依存します。これら 3 つのフレームワークを 1 つずつ見て、それぞれの長所と短所を分析し、さまざまな一般的な使用例を考慮して選択する必要があります。
2.1 スパーク
アドバンテージ：
成熟した安定性: Spark のオリジナル バージョンは 2014 年 5 月にリリースされ、比較的成熟したテクノロジです。商用サポート: 多数の企業が商用サポート/サービスを提供しています。大規模なデータセットの操作: 大規模なデータセットに対するデータ エンジニアリング/ETL タイプのタスクに適しています。高レベルの SQL 抽象化レイヤー (Spark SQL) を提供します。短所:
新しい実行モデルと API を学習する必要があり、学習曲線が急峻です。デバッグが難しい。適切なメンテナンスにはコンピューティング パラダイムと Spark の内部動作 (メモリ割り当てなど) を理解する必要があるため、IT 部門だけでメンテナンスするのが難しい複雑なアーキテクチャ。豊富なデータ視覚化エコシステムの欠如。GPU アクセラレータは組み込まれていないため、GPU リソースにアクセスするには RAPIDS アクセラレータが必要です。
2.2 ダッシュボード
アドバンテージ：
純粋な Python フレームワークで、非常に使いやすいです。Pandas DataFrames と NumPy 配列の直接サポート。Datashader を使用すると、数十億行に対する探索的データ分析を簡単に実装できます。Dask Bag の提供 - これは PySpark RDD の Python バージョンであり、マップ、フィルター、グループバイなどの機能を備えています。Dask は、パフォーマンスを大幅に向上させることができます。2020 年 6 月、Nvidia は RAPIDS、Dask、UCX を使用して 16 台の DGX A100 システム (128 個の A100 GPU) で TPCx-BB テストを実行し、驚くべき結果を達成しました。ただし、2021 年 1 月に、TPC は結果が TPC のフェアユース ポリシーに違反したとして Nvidia に上場廃止を強制したため、注意が必要です。
短所:
商用サポートの欠如 (ただし、 Coiled や QuanSight など、いくつかの企業がこの分野での取り組みを開始しています)。内蔵 GPU サポートはなく、GPU アクセラレーションのために RAPIDS に依存します。
2.3 レイ
アドバンテージ：
最小のクラスター構成は、計算集約型のワークロードに最適です。NLP、テキスト正規化などの特定の機械学習タスクにおいて、Ray が Spark や Dask よりも優れているという証拠がすでにあります。さらに、Ray は、単一ノード上であっても、Python の標準マルチプロセッシングよりも約 10% 高速に動作します。Ray はさまざまな ML ライブラリを拡張するために使用されることが増えているため、すべての ML ライブラリをスケーラブルな並列方式で一緒に使用できます。一方、Spark では、そのエコシステムで利用できるフレームワークの数が大幅に制限されています。独自のアクターベースの抽象化により、複数のタスクが同じクラスター上で非同期的に動作し、利用率が向上します (対照的に、Spark のコンピューティング モデルは柔軟性が低く、並列タスクの同期実行に基づいています)。短所:
比較的新しい (最初にリリースされたのは 2017 年 5 月)。分散データ処理にはあまり適していません。Ray には、データを分割するためのプリミティブが組み込まれていません。このプロジェクトでは Ray Datasets が導入されたばかりですが、これはまったく新しい追加であり、まだ非常に新しく基本的なものです。GPU のサポートは、スケジュールと予約に限定されています。実際に GPU を利用するかどうかはリモート関数次第です (通常は TensorFlow や PyTorch などの外部ライブラリを介して)。これら 3 つのフレームワークの長所と短所から始めて、次の選択基準を抽出できます。
ワークロードがデータ中心で、主に ETL/前処理である場合は、Spark を使用する方が適しています。特に、組織が Spark API に関する組織的な知識を持っている場合は特にそうです。
Dask と Ray の選択はそれほど明確ではありませんが、一般的なルールとして、Ray はあらゆる種類の Python コードを高速化するように設計されているのに対し、Dask はデータ サイエンス固有のワークフローを対象としています。物事をさらに複雑にするために、Dask 分散スケジューラを使用せずに Dask ワークフローを実行できる Dask-on-Ray プロジェクトもあります。Dask-on-Ray が埋めようとしているギャップをよりよく理解するには、Dask フレームワークのコア コンポーネントに注目する必要があります。これらは、コレクション抽象化 (DataFrame、配列など)、タスク グラフ (DAG、Apache Spark DAG と同様の操作のコレクションを表す)、およびスケジューラー (Dask グラフの実行を担当) です。分散スケジューラは、Dask で使用できるスケジューラの 1 つで、複数のマシンに分散された複数のワーカー プロセスのアクションを調整する役割を果たします。このスケジューラが優れているのは、セットアップが簡単で、遅延が最小限に抑えられ、ピアツーピアのデータ共有が可能で、単純なマップリデュース チェーンよりもはるかに複雑なワークフローをサポートしているためです。一方、分散スケジューラには次のような欠点がないわけではありません。
これは単一障害点です。分散スケジューラーには高可用性メカニズムがないため、障害が発生するとクラスター全体をリセットする必要があり、進行中のタスクはすべて失われます。これは Python で書かれているため、インストールとデバッグが簡単ですが、Python に通常伴う標準的なパフォーマンスに関する考慮事項も導入されています。クライアント API はデータ サイエンティスト向けに設計されており、可用性の高い運用インフラストラクチャから呼び出すことを目的としていません (たとえば、クライアントの存続期間が長く、おそらく Jupyter セッションからクラスターを操作していると想定しています)。ステートフル実行のサポートはほとんど提供されないため、フォールト トレラント パイプラインの実装は困難です。これがボトルネックになる可能性があり、ネイティブに拡張できません。対照的に、フォールト トレランスとパフォーマンスは、Ray のスケジューラの設計に深く組み込まれている原則です。完全に分散化されており (ボトルネックがなく)、より高速なデータ共有 (Apache Plasma 経由) が提供され、個々のスケジューラはステートレス (フォールト トレラント) であり、ステートフル アクターをサポートしています。これにより、Ray クラスター上で Dask タスクを実行する魅力が非常に明白になり、これが Dask-on-Ray スケジューラーの存在理由になります。