ByteDance Spark Shuffle 大規模クラウドネイティブ進化の実践

ByteDance では、Spark コンピューティング エンジンが大規模データ処理や機械学習などのシナリオで広く使用されており、1 日あたり 150 万を超えるタスクが処理されています。オンライン クラスター ディスクには、SSD、HDD、ハイブリッドなどさまざまな種類があります。毎日 100PB を超えるシャッフル データが生成され、1 つのタスクのシャッフル データの量は数百 TB に達することもあります。膨大な量のシャッフル データと複雑なコンピューティング リソース環境も、Spark 操作中のシャッフル パフォーマンスに多くの課題をもたらします。この記事では、背景紹介、安定性リソースシナリオ、コロケーションリソースシナリオの観点から、ByteDance の Spark Shuffle クラウドネイティブにおける大規模な進化の実践を紹介します。

1. 背景

Spark は ByteDance 内で広く使用されているコンピューティング エンジンであり、さまざまな大規模データ処理、機械学習、ビッグ データ シナリオで広く使用されています。現在、中国でのタスク数は1日あたり150万を超え、毎日のShuffleの読み書きデータ量は500PBを超えています。同時に、一部の単一タスクのシャッフル データは数百 TB に達する場合があります。

同時に、ワークロードとシャッフル データの量は依然として増加しています。昨年と比較すると、今年の日常業務数は50万件増加し、全体のデータ量は200PB以上増加し、50％の増加に達しました。シャッフルは、ユーザージョブで頻繁にトリガーされる機能です。さまざまな ReduceByKey、groupByKey、join、sortByKey、repartition 操作はすべて Shuffle を使用します。そのため、大規模な Spark クラスターでは、Spark Shuffle がパフォーマンスと安定性のボトルネックになることがよくあります。シャッフル計算には頻繁なディスクおよびネットワーク IO 操作が伴い、主にすべてのノードのデータを再パーティション化して結合する必要があります。

1. 原則

ESS モードのコミュニティ バージョンでデフォルトで使用される Shuffle モードの基本原理では、Shuffle 計算によってデータが再パーティション化されることが説明されています。ここで、Map データはすべての Reducer で再構成されます。 M Mapper と R Reducer がある場合、M Mapper のパーティション データは、次の R Reducer のパーティションに分割されます。

シャッフル プロセスは、シャッフル書き込みとシャッフル読み取りの 2 つの段階に分けられます。

シャッフル書き込み中、マッパーは縮小パーティションに従って現在のパーティションを R 個の新しいパーティションに分割し、それらをソートしてローカル ディスクに書き込みます。生成されたマップ出力には、インデックス ファイルとパーティション別にソートされたデータ ファイルの 2 つのファイルが含まれます。

すべての Mapper がマップ出力の書き込みを完了すると、2 番目のフェーズである Shuffle Read フェーズが始まります。このとき、各 Reducer は、その Reducer パーティションを含むすべての ESS にアクセスし、対応する Reduce パーティションのデータを読み取ります。 Reducer が対応するすべての Reduce パーティションのデータを取得するまで、すべてのパーティションが配置されているすべての ESS を要求することが可能です。

シャッフル フェッチ フェーズでは、各 ESS はすべての Reducer からの要求を受信し、対応するデータを返します。これにより、M 倍の R レベルのネットワーク接続とランダム ディスク読み取りおよび書き込み IO が生成され、多数のディスク読み取りと書き込み、およびネットワーク転送が行われます。このため、Shuffle はディスクとネットワークの IO を非常に頻繁に要求します。

Shuffle には高いリソース要件と消費量があるため、CPU、ディスク、ネットワークのオーバーヘッドがフェッチの失敗や Shuffle 速度の低下のボトルネックの原因となる可能性があります。 ByteDance の大規模なシャッフル シナリオでは、同じ ESS ノードが複数の販売者に同時にサービスを提供する必要がある場合があります。これらのクラスターが IO 分離を実行しない場合、Shuffle がユーザー ジョブの失敗の主な原因および問題点になる可能性があります。

ByteDance は 2021 年初頭に Spark Shuffle のクラウド ネイティブ作業を開始し、Spark ジョブやその他のビッグ データ エコシステムが Yarn Godel から移行し始めました。 Godel は、Kubernetes をベースに ByteDance が開発したスケジューラです。また、Hadoop Yarn と完全に互換性のあるプロトコルである Hadoop クラウド移行ソリューションである Yodel (Yarn on Godel) も提供します。その目標は、すべてのビッグデータ アプリケーションを Kubernetes システムにスムーズに移行することです。

この移行では、ESS もカスタマイズ作業を実施し、従来の Yarn Node Manager モードの Yarn Auxiliary Service から Kubernetes DaemonSet デプロイメント モードへの適応を完了し、Shuffle ジョブの移行を開始しました。 2年後の2023年には、Spark アプリケーションを含むすべてのビッグデータ アプリケーションが今日のクラウドネイティブ エコシステムに正常に移行されました。

2. 課題

クラウド ネイティブへの移行中に、多くの課題に直面しました。

• まず、NM から DaemonSet への移行中、DaemonSet 上の ESS の CPU は厳しく制限されますが、以前の NM モードでは、ESS は基本的にすべての CPU リソースを使用できます。そのため、この移行の実践では、最初に設定された ESS の CPU リソースが不足することが多く、継続的に調整する必要があります。その後、一部の高優先度クラスターは ESS の CPU 使用量を直接解放するようになりました。
• 同時に、DaemonSet と Pod では Spark ジョブの CPU に対してより厳しい制限が設けられています。これにより、新しいアーキテクチャに移行した後、多くのユーザーのジョブが遅くなることも発生しました。これは、以前のモードでは CPU がある程度過剰に発行されていたため、この状況を調整する必要があるためです。移行プロセス中にユーザーがパフォーマンスの違いに気付かないように、Kubernetes および Godel アーキテクチャで CPU 共有モードを有効にしました。
• さらに、Pod には非常に厳しいメモリ制限があるため、Shuffle Read 中にアイドル ページ キャッシュ リソースを使用することができず、Shuffle Read 中のページ キャッシュ ヒット率が非常に低くなります。このプロセスによりディスク IO オーバーヘッドが増加し、全体的なパフォーマンスが低下します。ポッドがページ キャッシュを適切に使用できるようにすることで、移行後の Shuffle によるパフォーマンスへの影響を軽減するための対策を講じました。

3. メリット

移行が完了した後、すべてのオフライン リソース プールを統合し、スケジュール レベルでより使いやすいいくつかの最適化およびスケジュール戦略を実装することができ、全体的なリソース使用率が向上しました。 ESS Daemonset も、Yarn Auxilary Service と比較して多くの利点を得ました。まず、ESS DaemonSet が独立したサービスに分離され、NM と密に結合されなくなり、運用および保守コストが削減されます。さらに、Kubernetes と Pod による ESS リソースの分離により ESS の安定性も向上し、ノード上の他のジョブや他のサービスによる ESS の影響を受けなくなります。

現在、クラウドネイティブ Spark ジョブには主に 2 つのオペレーティング環境があります。

• リソース クラスタ環境を安定させます。これらの安定したリソース クラスターは、主に優先度の高いタスクや SLA タスクを処理するために使用されます。導入されたディスクは比較的性能の良いSSDディスクです。これらの安定したリソース クラスターでは、コミュニティ ベースの高度にカスタマイズされた ESS サービスが主に使用されます。 SSD ディスク、ESS 読み取りおよび書き込みを使用し、ローカルの高性能 SSD ディスクも使用できます。 Godel アーキテクチャの Daemonset モードでデプロイされます。
• コロケーション リソース クラスター環境。これらのクラスターは主に、一時的なクエリ、デバッグ、またはテストのタスクなど、中規模および低規模のジョブを処理します。これらのクラスターのリソースは主に HDD ディスク上に展開されます。それらの一部はオンライン リソースを通じて転送されるか、他のサービスと共有され、一部のリソースは他のオンライン サービスと一緒に展開されます。その結果、クラスターのリソースが排他的でなくなり、全体的なディスク パフォーマンスとストレージ環境が特に良好ではなくなります。

2. 安定した資源シナリオ

安定したクラスター環境では、優先度の高いジョブが多数存在します。主なタスクは、これらのジョブのシャッフルの安定性と実行時のジョブ期間を改善して、これらのジョブの SLA を確保することです。 Shuffle問題を解決するために、ESSの監視/管理機能の強化、ESS Shuffleの電流制限機能の追加、Shuffleオーバーフロー分割機能の追加の3つの機能がESSに深くカスタマイズされています。

1. ESSの詳細なカスタマイズ

（１）ESSの監視・ガバナンス能力の強化

監視に関しては、既存の監視では、オープンソース バージョンの使用時に発生した Shuffle の問題や現在の ESS ステータスを詳細にトラブルシューティングするには不十分であることがわかりました。これにより、どのノードがシャッフル問題を引き起こしているかをすばやく特定できるようになりますが、問題のあるノードを検出する方法はありません。そのため、監視機能にいくつかの強化を加えました。

まず、キューに入れられたチャンクやチャンク フェッチ レートなど、シャッフルの遅さとフェッチ レート機能を監視するための主要な指標をいくつか追加しました。キューに入れられたチャンクは、現在要求している ESS ノード上の要求の蓄積を監視するために使用され、チャンク フェッチ レートは、これらのノード上の要求のトラフィックを監視するために使用されます。同時に、ESS のメトリクスを ByteDance のメトリクス システムに接続し、システムが提供するアプリケーション ディメンション インジケーターを通じて ESS ノードの蓄積を迅速に特定できるようにしました。ユーザー インターフェイス (UI) に関しては、ステージの詳細ページに 2 つの新しい機能が追加され、現在のステージで各タスク シャッフルが遭遇する最も遅いノードと、ステージ統計後のすべてのタスクの中で最もシャッフル遭遇数が多い上位のノードが表示されるようになりました。これにより、ユーザーにとってクエリが便利になるだけでなく、これらの指標を使用して関連する市場インデックスを構築することも可能になります。

• 所得

これらの監視と UI の改善により、ユーザーは UI 上で Shuffle が遅いことに気づいたときに、UI を通じて対応する Shuffle 監視をオンにすることができます。これにより、ユーザーと当社のチームは、シャッフル問題の原因となっている ESS ノードをすばやく特定し、これらのノードの実際の状況を確認し、蓄積されたリクエストがどのアプリケーションからのものであるかをすばやく特定できます。

新しく追加された監視では、シャッフルの問題のトラブルシューティングを実行する際に、ESS ノード上の実際のチャンク蓄積やレイテンシなどの主要な指標も検出されます。これにより、シャッフルが遅い場合にリアルタイムのアクションをより効果的に実行できるようになります。シャッフルの問題が特定されると、状況を分析し、ガバナンスの方向性と最適化を提供できます。

ガバナンス作業は主に BatchBrain システムを通じて実行されます。 BatchBrain は、Spark ジョブ専用に設計されたインテリジェントなジョブ チューニング システムです。主にジョブデータを収集し、オフラインおよびリアルタイムの分析を実行します。収集されるデータには、Spark 独自のイベント ログ、内部で入力されたより詳細なタイムライン イベント、ESS に追加されたカスタマイズされた Shuffle インジケーターなどのさまざまなメトリック インジケーターが含まれます。

オフライン分析では、主に定期的なジョブの管理が必要になります。各ジョブの履歴特性と収集されたデータに基づいて、これらのジョブのシャッフル ステージのパフォーマンスが分析されます。複数の反復調整を経て、適切なシャッフル パラメータのセットが最終的に提供されるため、これらのジョブは再実行時に最適化されたシャッフル パラメータを使用して実行できるようになり、より優れたパフォーマンスと結果が得られます。

BatchBrain では、以前に追加された Shuffle インジケーターを使用して、リアルタイム分析部分で自動スキャンを行うこともできます。ユーザーは、BatchBrain API を通じてクラスター内のジョブの Shuffle ステータスを照会し、Shuffle の蓄積が発生したノードとジョブを効果的に特定し、アラームを通じて関係者に通知することもできます。遅いシャッフルの原因が他のジョブまたは異常なジョブであることが判明した場合、ユーザーはこれらのジョブを停止または削除するなどのガバナンスアクションを直接実行して、より優先度の高いジョブのシャッフル用にリソースを解放することもできます。

（２）シャッフル電流制限機能

シャッフルの監視と管理を通じて、ESS ノードでのシャッフルが遅い原因として、通常、特定のタスクのデータ量が多すぎることや、パラメータ設定が不適切であることがわかり、その結果、これらのシャッフル ステージで Mapper と Reducer の数が異常に多くなっています。 Mapper と Reducer の数が異常に多いと、ESS ノードに大量のリクエストが蓄積され、これらのリクエストのチャンク サイズも非常に小さくなる可能性があります。一部の異常なジョブの平均チャンク サイズは 20 KB にも達しない場合があります。これらのジョブは ESS に大量のリクエストを送信するため、ESS がすべてのリクエストをタイムリーに処理できなくなり、リクエストが蓄積され、ジョブが遅延したり、直接失敗したりする可能性があります。

これらの問題に対処するための解決策は、ESS ノード上の各アプリケーションに対するリクエストの合計数を制限することです。アプリケーションのフェッチ要求制限に達すると、ESS は、アプリケーションが既存の要求の完了を待機し終えてから新しい要求の送信を続行するまで、アプリケーションによって送信された新しいフェッチ要求を拒否します。これにより、単一のアプリケーションがノード上のリソースを過剰に占有し、ESS が他のジョブ要求を適切に処理できなくなることを防ぐことができます。また、他のジョブが失敗したり、シャッフル速度が低下したりするのを防ぐこともできます。このソリューションは、異常なまたは大規模なシャッフル ジョブがクラスター シャッフルに及ぼす悪影響を軽減できます。

シャッフル電流制限機能の特徴

• ジョブが正常に実行されている場合、電流制限機能をオンにしてもジョブに影響はありません。ノードが通常のサービスを提供できる場合は、電流制限をトリガーする必要はありません。
• ノード負荷が許容範囲を超え、Shuffle IO が設定されたしきい値を超えた場合にのみ、電流制限メカニズムがアクティブになり、異常なタスクが ESS に送信できるリクエストの数を減らして、ESS サービスへの現在の負荷を軽減します。現時点ではESSサービスの負荷容量が許容範囲を超えているため、これらのリクエストを受信して​​も正常に返すことができません。したがって、異常なタスクのリクエスト数を制限すると、これらのタスク自体のパフォーマンスが向上する可能性があります。
• 電流制限の場合は、ジョブの優先度も考慮されます。優先度の高いタスクの場合、より大きなフロー レートが許可されます。
• 電流制限が発動した際に、ESS の流量が正常に戻ったことが確認された場合、電流制限は速やかに解除されます。フローが制限されたアプリケーションは、以前のフロー レベルにすぐに戻ることができます。

電流制限の詳細なプロセス

電流制限機能は主にESSサーバー側で実行されます。レイテンシ インジケーターはノード上で 5 秒ごとにスキャンされます。レイテンシインジケータが設定されたしきい値を超えると、ノードの負荷が持続可能な負荷を超えたと判断されます。次に、ESS ノードで現在シャッフルを実行しているすべてのアプリケーションが評価され、電流制限を有効にするかどうかが決定されます。以前に追加したインジケーターを使用することで、過去 5 分間のこのノード上のフェッチ トラフィックと IO の合計をカウントできます。総トラフィックの上限に基づいて、各 ESS ノードで現在 Shuffle を実行している各アプリケーションのトラフィックを合理的に割り当て、制限することができます。トラフィックの分散もアプリケーションの優先度に基づいて調整されます。アプリケーションのシャッフルまたは現在蓄積されているチャンク フェッチ レートが割り当てられたフローを超過した場合、それらは調整され、蓄積されたリクエストが部分的に解放されるまで、新しく送信されたリクエストは拒否されます。

電流制限を割り当てるための等級分けシステムもあります。まず、現在のノードで Shuffle を実行しているアプリケーションの数に基づいてトラフィックが割り当てられます。アプリケーションの数が増えるほど、各アプリケーションに割り当てられるトラフィックは少なくなります。ノード上のアプリケーションの数が比較的少ない場合、各アプリケーションにより多くのトラフィックを割り当てることができます。電流制限レベルも、ノード上の実際の状況に基づいて 30 秒ごとに調整されます。

フロー制限の場合、ノードのレイテンシが改善されず、Shuffle の合計フローが回復しない場合は、フロー制限がアップグレードされ、すべてのアプリケーションに厳しいフロー制限が課せられます。逆に、レイテンシが改善されたり、ノード トラフィックが回復したりした場合は、フロー制御がダウングレードされるか、直接解除されることもあります。最後に、すべてのジョブの優先度に基づいてスロットルも適切に調整されます。

上の図に例があります。ジョブの数が少ない場合、優先度の高いジョブのフローが制限されます。ジョブに割り当てられたフローが高くなる可能性があります。ただし、ノードの負荷が軽減されていない場合は、フロー制限がアップグレードされます。同じ状況では、中または低優先度のジョブにはより少ないトラフィックが割り当てられます。電流制限機能を有効にすると、多くの高品質オンライン クラスターでパフォーマンスが大幅に向上することが確認されています。

まず、チャンク蓄積の問題が大幅に軽減されました。現在の制限により、異常なタスクによって発生するチャンクの蓄積が効果的に削減され、クラスター内の一部のノードでの大量のリクエストの蓄積が大幅に削減されます。

さらに、レイテンシー状況も改善されました。電流制限が有効になる前は、クラスター内のノードで高いレイテンシが発生することがよくありました。電流制限機能を有効にした後、全体的な遅延状況が大幅に緩和されました。不要で無効なリクエストを削減し、さまざまな大規模または異常なタスクによって ESS ノードに開始されるリクエストの数を制限することで、これらの異常に大きいタスクが ESS サービスの負荷に与える悪影響を回避し、他の優先度の高いタスクの動作への影響を軽減します。

（３）シャッフルオーバーフロー分割機能

いくつかの遅い Shuffle ジョブを分析したとき、別の現象も発見しました。それは、ジョブ内の各 Executor によって書き込まれる Shuffle データの量が非常に不均衡になる可能性があるというものです。 ESS は動的割り当てメカニズムを使用するため、各 Executor の実行時間と割り当てられたマップ タスクの数は異なる場合があります。その結果、ジョブ実行中に大量の Shuffle データが少数の Executor に集中し、実際には Shuffle データが少数のノードに集中することになります。

たとえば、下の図では、5 つの Executor の Shuffle 書き込み量が他の Executor の 10 倍以上であることがわかります。この場合、シャッフル要求がこれらのノードに集中し、これらの ESS ノードの負荷が非常に高くなり、間接的にフェッチ失敗の可能性が高まります。

このような状況に対して、私たちが提供する解決策は、コンテナまたはノードごとにディスクに書き込まれる Shuffle データの合計量を制御することです。この機能は 2 つの観点から実現できます。まず、Spark 自体が Executor の Shuffle Write Size を制御します。これは、Shuffle を実行するときに各 Executor によって書き込まれるデータの最大量です。各 Executor は、現在書き込んでいる Shuffle データの量を計算し、この情報を Spark ドライバーに報告します。 Spark ドライバーは、障害時に除外するメカニズムを使用して、書き込まれたデータがしきい値を超える Executor をスケジュール範囲から積極的に除外し、これらの Executor をリサイクルできます。さらに、スケジューリング戦略を改善するために Godel スケジューラも使用し、新しい Executor を他のノードにスケジュールして、単一のコンテナにシャッフル データが大量に書き込まれるのを回避します。シャッフル データの書き込みによってノードのディスクがいっぱいになったり、シャッフル フェッチ フェーズ中にデータがこれらの ESS ノードに集中したりすることがなくなります。

2. クラウドネイティブ最適化

同時に、クラウドネイティブ最適化の観点では、Executor のスケジューリングと関数の最適化も実行し、Godel スケジューラ戦略を通じて Shuffle 機能を改善しました。 Godel スケジューラによって提供されるスケジューリング戦略では、Executor をスケジュールするときに高負荷の Shuffle ノードを可能な限り回避できるため、これらのノードが後で Shuffle の問題に遭遇する可能性が減ります。さらに、スケジューラは、シャッフルを実現するために、エグゼキュータのシャッフル書き込みにさらに多くの機能を提供することもできます。たとえば、ディスク負荷が特に高いノード上の Executor を削除したり、ディスクに十分なスペースがない場合に大量の Shuffle データを書き込んだコンテナーを削除したりできます。

Executor の Shuffle を制御する Spark ドライバーとクラウドネイティブ スケジューリングを組み合わせることで、Shuffle データ全体をより多くのノードに分散し、Shuffle Fetch フェーズのデータ​​とリクエストをより均等に分散することができます。

• 効果

上記の高度にカスタマイズされたシャッフル最適化をオンラインで有効にした後、顕著な結果が観察されました。以下は、3 つの高品質クラスターからの動作データの一部です。これら 3 つの高品質クラスターのタスクの総数は 1 日あたり 30 万を超えることもありますが、Shuffle Fetch の失敗により最終的に失敗するジョブの平均数は 1 日あたり 20 ～ 30 件程度であり、失敗率は 1/10,000 未満であると言えます。次の図に示すように、これら 3 つの高品質クラスターの安定性は最適化後に大幅に向上し、ユーザーが Shuffle で遭遇する問題が大幅に減少しました。

3. コロケーションリソースのシナリオ

次に、コロケーション シナリオで実行される最適化について紹介します。まず、コロケーション クラスター シナリオでは、フェッチ障害は通常、安定したリソース環境よりもはるかに深刻であることに注意してください。 1 日あたりのフェッチ失敗の平均数は非常に高くなっています。主な理由は、これらのリソースのほとんどがアイドル状態のオンライン リソースからのものであり、そのディスク IO 機能とディスク容量が比較的限られていることです。さらに、ディスク IOPS とディスク容量が非常に限られている場合があるため、HDFS や他のサービスと混在して展開されたリソースはクラスターの Shuffle パフォーマンスに大きな影響を与え、障害が発生する可能性も高くなります。コロケーション リソース管理の主な目的は、ジョブの失敗率を減らし、ジョブの安定性を確保することです。同時に、クラスター全体のシャッフル性能を向上させ、リソースの無駄を減らす必要があります。

混合リソースを持つクラスターの場合、主なソリューションは自社開発の Cloud Shuffle Service (CSS) です。これは、リモート Shuffle サービスを提供することで、これらのジョブのローカル ディスクへの依存を軽減します。

1. CSS関数の紹介

まず、CSS はプッシュ ベースのシャッフル モードを提供します。先ほど紹介した ESS モードとは異なり、プッシュ ベースのシャッフル モードでは、異なるマッパーの同じリデューサー パーティション データが共通のリモート サービスに送信され、このサービス上でマージされ、最終的にワーカー上の 1 つ以上のファイルに書き込まれるため、リデュース ステージはシーケンシャル読み取りモードを通じてこれらのパーティション データを読み取ることができ、ランダム IO のオーバーヘッドが削減されます。

CSS は、複数のパーティション データを 1 つの Reducer パーティション グループに割り当てるために使用されるパーティション グループ機能もサポートしています。このように、Map フェーズでは、Mapper はバッチ プッシュを介してデータを送信し、対応するパーティション グループの作業ノードにバッチ データを直接転送できるため、バッチ モードでの IO オーバーヘッドが削減され、バッチ モードのパフォーマンスが向上します。

CSS は高速な二重書き込みバックアップ機能も提供します。プッシュベースのシャッフルと集約モードが使用されるため、すべてのデータは実際には 1 つのワーカーに集約されます。このワーカーのデータが失われた場合、すべてのマッパーは対応するデータを再計算する必要があります。したがって、プッシュ集約機能では、二重書き込みバックアップを使用することがより重要になります。 CSS は、デュアル書き込みインメモリ コピー モードを採用し、非同期ディスク フラッシュを実行することで書き込み速度を向上させ、Mapper がディスク フラッシュの終了を待たずに後続のデータをプッシュし続けることができるようにします。

CSS 自体にも負荷分散機能があります。 CSS は Cluster Manager を通じてすべてのサービス ノードを管理します。クラスター マネージャーは、CSS ワーカー ノードによって報告された負荷情報を定期的に収集して受信します。新しいアプリケーションが送信されると、リソースが均等に分散され、Shuffle Write と Shuffle Read がクラスター内の使用率の低いノードに優先的に割り当てられるため、クラスター内の Shuffle 負荷分散が向上します。

2. CSSの全体的なアーキテクチャ

• クラスター マネージャーは、クラスター リソースの割り当てと、クラスター ワーカーおよびアプリケーションのステータスの維持を担当します。この情報を Zookeeper またはローカル ディスク経由で保存し、高可用性サービスを実現できます。
• ワーカーは、ディスク モードと HDFS モードの 2 つの書き込みモードをサポートしています。現在はディスクモードが一般的に使用されています。データの冗長性を実現するために、各パーティションのデータは 2 つの異なるワーカー ノードに書き込まれます。
• CSS マスターは Spark ドライバー側にあり、主にクラスター マネージャーおよびアプリケーション ライフサイクルとのハートビート接続を担当します。ジョブが開始されると、クラスター マネージャーからワーカーも要求されます。シャッフル ステージ プロセスでは、シャッフル ステージのメタデータと進行状況もカウントされます。
• Shuffle Client は、Spark Shuffle API に接続するコンポーネントであり、これにより、追加の構成なしで任意の Spark ジョブが CSS を直接使用できるようになります。各 Executor は読み取りと書き込みに ShuffleClient を使用します。 Shuffle Client は書き込み時に二重書き込みを実行します。読み取り時には、データを保存している任意の Worker からデータを読み取ることができます。いずれかのワーカーが読み取りに失敗した場合、自動的に別のワーカーに切り替えて、複数の読み取りデータの重複を排除します。

CSS を記述する場合、Worker はデータを直接送信し、Mapper はデータを 2 つの Worker に同時に送信します。ワーカーは、ディスクがフラッシュされるまで待ってからデータをマッパーに返すのではなく、結果を非同期的にマッパーに返します。失敗が発生した場合、次のリクエストで Mapper に通知されます。このとき、Mapper はノードから 2 つの新しい Worker を再申請し、送信に失敗したデータを再プッシュします。読み取り時には、任意のノードからデータを読み取り、マップ ID、試行 ID、バッチ ID ごとに重複を排除できます。

3. CSSのパフォーマンスと今後の進化

1TB TPC-DS ベンチマーク パフォーマンス テストでは、クエリの 30% 以上で CSS が改善されました。

リモート シャッフル サービスとして、CSS はクラウド ネイティブに特に適しており、弾力的なデプロイメントとより多くのリモート ストレージ サービスをサポートします。 CSS は現在オープンソース化されています。興味のある方は、CSS オープンソース Web サイトにアクセスして詳細情報を確認してください。また、その後のイテレーションや最適化をコミュニティに同期させたいと考えています。クラウド ネイティブの今後の進化では、弾力的なデプロイメントのサポートやリモート ストレージ サービスのサポートなどの関連機能が必要になります。

以上が今回のシェアの内容です、皆様ありがとうございました。