コンピュート構成のベスト プラクティス

Databricks では、コンピュートを作成および構成するときに、最小限のコストで最高のパフォーマンスを得るために役立つ多くのオプションを提供します。 ただし、この柔軟性は、ワークロードに最適な構成を決定しようとするときに課題を生み出す可能性があります。 ユーザーがコンピュートをどのように利用するかを慎重に考慮することは、新しいコンピュートを作成するとき、または既存のコンピュートを構成するときに構成オプションを決定するのに役立ちます。 構成オプションを決定する際に考慮すべき事項には、次のようなものがあります。

  • コンピュートはどのようなユーザーが利用するのでしょうか? データサイエンティストは、データエンジニアやデータアナリストとは異なる要件を持つ異なる種類のジョブを実行している場合があります。

  • ユーザーはコンピュートでどのような種類のワークロードを実行しますか? たとえば、バッチ抽出、変換、ロード (ETL) ジョブには、分析ワークロードとは異なる要件がある可能性があります。

  • 満たす必要のあるサービスレベルアグリーメント(SLA)のレベル

  • 予算の制約

この記事では、これらの考慮事項に基づいて、さまざまなシナリオに対するコンピュート構成の推奨事項を提供します。 この記事では、Databricks コンピュートの特定の機能と、それらの機能について留意すべき考慮事項についても説明します。

構成の決定には、コストとパフォーマンスのトレードオフが必要です。 コンピュートの主なコストには、コンピュートによって消費される Databricks ユニット (DBU) と、コンピュートの実行に必要な基盤となるリソースのコストが含まれます。 明らかではないかもしれないのは、SLA を満たさないことによるビジネスへのコスト、従業員の効率の低下、または不十分な管理によるリソースの無駄の可能性などの二次的なコストです。

コンピュートの起動失敗を防ぐためにリソース クォータを確認する

Databricks ワークスペースでコンピュートを正常に起動するには、Google クラウド プロジェクトに十分な Google クラウド リソース割り当てが必要です。 プロジェクトに十分なクォータがない場合は、クォータの引き上げをリクエストできます。 「ワークスペースの Google Cloud リソース割り当ての確認と設定」を参照してください。

コンピュートの特徴

より詳細なコンピュート構成シナリオについて説明する前に、Databricks コンピュートのいくつかの機能と、それらの機能の最適な使用方法を理解することが重要です。

汎用コンピュートとジョブコンピュート

コンピュートを作成するときは、コンピュートのタイプ (汎用コンピュートまたはジョブ コンピュート) を選択します。 汎用コンピュートは複数のユーザーで共有でき、アドホック分析、データ探索、開発の実行に最適です。 処理の実装が完了し、コードを運用する準備ができたら、ジョブ コンピュートでの実行に切り替えます。 ジョブ コンピュートはジョブが終了すると終了するため、リソースの使用量とコストが削減されます。

シングルノードとマルチノードのコンピュート

コンピュート作成 UI の上部で、コンピュートをマルチノードにするか単一ノードにするかを選択できます。

単一ノード コンピュートは、単一ノードの機械学習ライブラリなど、少量のデータまたは非分散ワークロードを使用するジョブを対象としています。 マルチノード コンピュートは、ワークロードが分散された大規模なジョブに適しています。

オートスケーリング

注:

コンピュートの自動スケーリングには、構造化ストリーミング ワークロードのクラスター サイズをスケールダウンする制限があります。 Databricks 、ストリーミング ワークロードに拡張オートスケールを備えたDelta Live Tablesを使用することをお勧めします。 「拡張オートスケールDelta Live Tables Pipeline のクラスター使用率を最適化する」を参照してください。

オートスケールを使用すると、ワークロードに基づいてコンピュートのサイズを自動的に変更できます。 オートスケールはコストとパフォーマンスの両方の観点から多くのユースケースやシナリオにメリットをもたらしますが、オートスケールをいつどのように使用するかを理解するのは難しい場合があります。 オートスケールを使用するかどうか、および最大限のメリットを得る方法を決定するための考慮事項を以下に示します。

  • オートスケールは通常、固定サイズのコンピュートと比較してコストを削減します。

  • オートスケール ワークロードは、プロビジョニングが不十分な固定サイズのコンピュートと比較して高速に実行できます。

  • Spark-submit ジョブや一部の Python パッケージなど、一部のワークロードはオートスケール コンピュートと互換性がありません。

  • シングルユーザーの多目的コンピュートでは、ワーカーの最小数の設定が低すぎると、ユーザーはオートスケールによる開発や分析の速度が遅くなることがあります。 これは、実行されているコマンドやクエリが数分離れていることが多く、コンピュートがアイドル状態になる時間があり、コストを節約するためにスケールダウンされる可能性があるためです。 次のコマンドが実行されると、コンピュート マネージャーはスケールアップを試み、クラウド プロバイダーからインスタンスを取得するまでに数分かかります。 この間、リソースが不足した状態でジョブが実行される可能性があり、結果を取得する時間が遅くなります。 ワーカーの最小数を増やすと効果的ですが、コストも増加します。 これも、コストとパフォーマンスのバランスを取る必要がある例です。

  • ディスク キャッシュが使用されている場合は、ノードが終了すると、ノード上のキャッシュされたデータが失われることを覚えておくことが重要です。キャッシュされたデータを保持することがワークロードにとって重要な場合は、固定サイズのコンピュートの使用を検討してください。

  • ETL ワークロードを実行するジョブ コンピュートがある場合、ジョブが変更される可能性が低いことがわかっている場合は、チューニング時にコンピュートのサイズを適切に設定できることがあります。 ただし、オートスケールを使用すると、データ サイズが増加した場合でも柔軟に対応できます。 また、コンピュートが十分に活用されていない、または別のプロセスからの結果を待っている期間が長い場合、最適化されたオートスケールにより、長時間実行されるジョブの費用を削減できることにも注目してください。 ただし、コンピュートが適切にスケールアップしようとするため、ジョブにわずかな遅延が発生する可能性があります。 ジョブの SLA が厳しい場合は、固定サイズのコンピュートを選択するか、Databricksプールの使用を検討してコンピュートの開始時間を短縮することを検討してください。

プール

プール構成リファレンスは、利用可能なすぐに使用できるインスタンスのセットを維持することで、コンピュートの開始時間とスケールアップ時間を短縮します。 Databricks では、コストを最小限に抑えながら処理時間を短縮するために、プールを利用することをお勧めします。

Databricks Runtimeのバージョン

Databricks では、汎用コンピュートのために最新の Databricks Runtime バージョンを使用することをお勧めします。 最新バージョンを使用すると、コードとプリロードされたパッケージの間に最新の最適化と最新の互換性が確保されます。

運用ワークロードを実行するジョブ コンピュートの場合は、長期サポート (LTS) Databricks Runtimeバージョンの使用を検討してください。 LTS バージョンを使用すると、互換性の問題が発生することがなくなり、アップグレード前にワークロードを徹底的にテストできます。 機械学習に関する高度なユースケースがある場合は、特化した Databricks Runtime バージョンを検討してください。

コンピュートポリシー

Databricks コンピュート ポリシーを使用すると、管理者はコンピュートの作成と構成に対する制御を強制できます。 Databricks では、このガイドで説明されている推奨事項を適用するためにコンピュート ポリシーを使用することをお勧めします。

自動終了

多くのユーザーは、コンピュートを使い終わっても、コンピュートを終了しようとは思わないでしょう。 幸いなことに、コンピュートは設定された期間 (デフォルトは 120 分) が経過すると自動的に終了します。

管理者は、コンピュート ポリシーを作成するときに、このデフォルト設定を変更できます。 この設定を減らすと、コンピュートがアイドル状態になる時間が短縮され、コストが削減されます。 コンピュートが終了すると、すべての変数、一時テーブル、キャッシュ、関数、オブジェクトなどを含むすべての状態が失われることに留意することが重要です。 コンピュートを再度開始するときは、この状態をすべて復元する必要があります。 開発者が 30 分間の昼休みに外出した場合、ノートブックを以前と同じ状態に戻すのに同じ時間を費やすのは無駄です。

重要

アイドル コンピュートは、終了前の非アクティブ期間中に DBU とクラウド インスタンスの料金を蓄積し続けます。

ガベージコレクション

この記事で説明する他の考慮事項ほど明確ではないかもしれませんが、ガベージ コレクションに注意を払うことは、コンピュートのジョブ パフォーマンスを最適化するのに役立ちます。 大量の RAM を提供すると、ジョブの実行効率が向上しますが、ガベージ コレクション中に遅延が発生する可能性もあります。

長時間のガベージ コレクション スイープの影響を最小限に抑えるには、インスタンスごとに大量の RAM が構成されたコンピュートのデプロイを避けてください。 エグゼキューターに割り当てられる RAM が増えると、ガベージ コレクション時間が長くなります。 代わりに、より小さい RAM サイズでインスタンスを構成し、ジョブにさらに多くのメモリが必要な場合は、より多くのインスタンスをデプロイします。 ただし、 「コンピュートのサイジングに関する考慮事項」で説明したように、多くのシャッフルを必要とするワークロードなど、より少ないノードとより多くの RAM が推奨される場合があります。

コンピュートのアクセス制御

2 種類のコンピュート権限を設定できます。

  • 無制限のクラスター作成権限は、ユーザーがコンピュートを作成できるかどうかを制御します。

  • コンピュート レベルの権限は、特定のコンピュートを使用および変更する機能を制御します。

コンピュート権限の構成の詳細については、 「コンピュート アクセス制御」を参照してください。

コンピュート作成権限があるか、ポリシーの仕様内で任意のコンピュートを作成できるコンピュート ポリシーへのアクセス権を持っている場合、コンピュートを作成できます。 コンピュートの作成者は所有者であり、CAN MANAGE 権限を持っているため、コンピュートのデータ アクセス権限の制約内で他のユーザーとコンピュートを共有できます。

一般的なシナリオのコンピュート構成を決定する場合、コンピュート権限とコンピュート ポリシーを理解することが重要です。

コンピュートのタグ

コンピュート タグを使用すると、組織内のさまざまなグループが使用するクラウド リソースのコストを簡単に監視できます。 コンピュートの作成時にタグをキーと値の文字列として指定でき、Databricks はこれらのタグをクラウド リソースに適用します。 タグの適用の詳細については、「ポリシーによるタグの適用」を参照してください。

コンピュートのサイジングに関する考慮事項

Databricks はワーカー ノードごとに 1 つのエグゼキューターを実行します。 したがって、Databricks アーキテクチャのコンテキストでは、エグゼキューターとワーカーという用語は同じ意味で使用されます。 コンピュートのサイズをワーカー数の観点から考えることがよくありますが、考慮すべき重要な要素は他にもあります。

  • Total エグゼキューター コア (コンピュート): すべてのエグゼキューターにわたるコアの合計数。 これにより、コンピュートの最大並列処理が決まります。

  • 総エグゼキューターメモリ容量: すべてのエグゼキューターのRAMの合計容量。これにより、ディスクにスピルする前にメモリに格納できるデータの量が決まります。

  • エグゼキューターローカルストレージ: ローカルディスクストレージのタイプと容量。ローカルディスクは、主にシャッフルおよびキャッシュ中にデータがスピルした場合に使用されます。

追加の考慮事項には、ワーカー インスタンスのタイプとサイズが含まれており、これらも上記の要素に影響します。 コンピュートのサイズを決めるときは、次の点を考慮してください。

  • ワークロードのデータ消費量

  • ワークロードのコンピューティングの複雑さの度合い

  • データの読み取り先

  • 外部ストレージでのデータのパーティション方法

  • 必要な並列処理量

これらの質問に答えると、ワークロードに基づいて最適なコンピュート構成を決定するのに役立ちます。 ナロー変換 (各入力パーティションが 1 つの出力パーティションのみに寄与する変換) のみを使用する単純な ETL スタイルのワークロードの場合は、コンピュートに最適化された構成に焦点を当てます。 大量のシャッフルが予想される場合は、データ流出に備えてアカウントへのストレージだけでなく、メモリの量も重要です。 大きなインスタンスの数が少ないと、シャッフル負荷の高いワークロード中にマシン間でデータを転送するときのネットワーク I/O を削減できます。

ワーカーの数とワーカー インスタンス タイプのサイズの間にはバランスをとる必要があります。 それぞれ 40 コアと 100 GB の RAM を備えた 2 つのワーカーを備えたコンピュートは、10 コアと 25 GB の RAM を備えた 8 つのワーカー コンピュートと同じコンピュートとメモリを備えています。

同じデータの再読み取りが何度も発生することが予想される場合は、ワークロードがキャッシュの恩恵を受ける可能性があります。 ディスク キャッシュを使用したストレージ最適化構成を検討してください。

コンピュートのサイジング例

次の例は、特定の種類のワークロードに基づいたコンピュートの推奨事項を示しています。 これらの例には、避けるべき構成と、それらの構成がワークロードの種類に適していない理由も含まれています。

データ解析

データアナリストは通常、複数のパーティションからのデータを必要とする処理を実行するため、多くのシャッフル操作が行われます。 ノード数が少ないコンピュートでは、これらのシャッフルの実行に必要なネットワークとディスク I/O を削減できます。 次の図のコンピュート A は、特に 1 人のアナリストをサポートするコンピュートの場合、おそらく最良の選択です。

クラスターDは、ノード数の多さとメモリおよびストレージ容量の少なさから、処理の完了にデータのシャッフルをより多く必要とするため、パフォーマンスが最悪になる可能性があります。

データ分析コンピュートサイジング

分析ワークロードでは同じデータを繰り返し読み取る必要がある可能性が高いため、推奨されるワーカー タイプは、ディスク キャッシュを有効にしてストレージを最適化したものです。

分析ワークロードに推奨されるその他の機能には、次のものがあります。

  • 自動終了を有効にすると、一定期間非アクティブな状態が続いた後にコンピュートが確実に終了します。

  • アナリストの一般的なワークロードに基づいてオートスケーリングを有効にすることを検討してください。

  • プールの使用を検討してください。これにより、コンピュートを事前に承認されたインスタンス タイプに制限し、一貫したコンピュート構成を確保できます。

以下の機能は不要である可能性があります。

  • ストレージのオートスケーリング(このユーザーは大量のデータを生成しない可能性があるため)。

  • このコンピュートは単一ユーザー用であるため、共有コンピュート。

基本的なバッチETL

結合や集計など、広範な変換を必要としない単純なバッチ ETL ジョブでは、通常、コンピュートに最適化されたコンピュートのメリットが得られます。 このような種類のワークロードの場合、次の図のいずれかのコンピュートが受け入れられる可能性があります。

基本的なバッチ ETL コンピュートのサイジング

より安価で、大容量のメモリやストレージを必要としないワークロードであるという理由から、コンピューティング最適化ワーカータイプが推奨されます。

プールを使用すると、コンピュートの起動時間が短縮され、ジョブ パイプライン実行時の合計ランタイムが短縮されるため、単純な ETL ジョブをサポートするコンピュートに利点が得られる可能性があります。 ただし、これらのタイプのワークロードは通常、コンピュートがジョブを完了するのに十分な時間だけ実行されるスケジュールされたジョブとして実行されるため、プールの使用は最良の選択肢ではない可能性があります。

以下の機能は不要である可能性があります。

  • データの再読み取りは想定されていないため、ディスク キャッシュ。

  • 自動終了(スケジュールされたジョブである可能性が高いため、おそらく不要)。

  • オートスケーリング(コンピューティングとストレージはユースケースに合わせて事前に構成する必要があるため、非推奨)。

  • 共有コンピュートはマルチユーザーを対象としており、単一のジョブを実行するコンピュートにはメリットがありません。

複雑なバッチETL

複数のテーブルにわたるユニオンや結合を必要とする処理など、より複雑な ETL ジョブは、シャッフルされるデータの量を最小限に抑えることができれば、おそらく最適に機能します。 コンピュート内のワーカーの数を減らすとシャッフルを最小限に抑えることができるため、クラスター D のような大規模なコンピュートよりも、次の図のクラスター A のような小規模なコンピュートを検討する必要があります。

複雑な ETL コンピュートのサイジング

複雑な変換はコンピュートに負荷がかかる可能性があるため、一部のワークロードでは最適なコア数に達するには、コンピュートにノードを追加する必要がある場合があります。

単純な ETL ジョブと同様に、コンピュートに最適化されたワーカー タイプが推奨されます。これらはより安価であり、これらのワークロードは大量のメモリやストレージを必要としない可能性があります。 また、単純な ETL ジョブと同様に、考慮すべき主なコンピュート機能は、コンピュートの起動時間を短縮し、ジョブ パイプラインの実行時の合計ランタイムを削減するためのプールです。

以下の機能は不要である可能性があります。

  • データの再読み取りは想定されていないため、ディスク キャッシュ。

  • 自動終了(スケジュールされたジョブである可能性が高いため、おそらく不要)。

  • オートスケーリング(コンピューティングとストレージはユースケースに合わせて事前に構成する必要があるため、非推奨)。

  • 共有コンピュートはマルチユーザーを対象としており、単一のジョブを実行するコンピュートにはメリットがありません。

機械学習モデルのトレーニング

機械学習モデルのトレーニングの最初の繰り返しは実験的なことが多いため、クラスター A などの小規模なコンピュートが適しています。 コンピュートを小さくすると、シャッフルの影響も軽減されます。

安定性が懸念される場合、またはより高度なステージの場合は、クラスター B や C などのより大きなコンピュートが良い選択になる可能性があります。

ノード間でデータをシャッフルするオーバーヘッドのため、クラスター D のような大規模なコンピュートは推奨されません。

機械学習コンピュートのサイジング

推奨されるワーカー タイプは、同じデータの繰り返し読み取り用にアカウントを作成し、トレーニング データのキャッシュを有効にするディスク キャッシュを有効にしてストレージを最適化したものです。 ストレージ最適化ノードによって提供されるコンピュートとストレージ オプションが十分でない場合は、GPU 最適化ノードを検討してください。 考えられる欠点は、これらのノードでディスク キャッシュがサポートされないことです。

機械学習ワークロードに推奨されるその他の機能には、次のものがあります。

  • 自動終了を有効にすると、一定期間非アクティブな状態が続いた後にコンピュートが確実に終了します。

  • プールを使用すると、コンピュートを事前に承認されたインスタンス タイプに制限し、一貫したコンピュート構成を確保できます。

以下の機能は不要である可能性があります。

  • オートスケール。コンピュートのスケールダウンに伴ってノードが削除されると、キャッシュされたデータが失われる可能性があるためです。 さらに、一般的な機械学習ジョブは、利用可能なすべてのノードを消費することがよくあり、その場合、オートスケールは何のメリットももたらしません。

  • ストレージのオートスケーリング(このユーザーは大量のデータを生成しない可能性があるため)。

  • このコンピュートは単一ユーザー用であるため、共有コンピュート。

一般的なシナリオ

次のセクションでは、一般的なコンピュートの使用パターンに合わせてコンピュートを構成するための追加の推奨事項を示します。

  • データ分析とアドホック処理を実行する複数のユーザー。

  • 機械学習などの特殊なユースケース。

  • スケジュールされたバッチジョブのサポート。

マルチユーザーコンピュート

シナリオ

データ分析とアドホック クエリを実行するために、複数のユーザーにデータへのアクセス権を提供する必要があります。 コンピュートの使用量は時間の経過とともに変動する可能性があり、ほとんどのジョブはそれほどリソースを消費しません。 ユーザーは、ほとんどの場合、データへの読み取り専用アクセスを必要とし、シンプルなユーザー インターフェイスを使用して分析を実行したり、ダッシュボードを作成したりしたいと考えています。

コンピュート プロビジョニングに推奨されるアプローチは、コンピュートでのノード プロビジョニングとオートスケールのハイブリッド アプローチです。 ハイブリッド アプローチには、コンピュートのオンデマンド インスタンスとプリエンプティブル インスタンスの数を定義し、インスタンスの最小数と最大数の間でオートスケールを有効にすることが含まれます。

マルチユーザー シナリオ

このコンピュートは、デフォルトで常に利用可能であり、グループに属するユーザーによって共有されます。 オートスケールを有効にすると、負荷に応じてコンピュートをスケールアップおよびスケールダウンできます。

ユーザーにはコンピュートを開始/停止するためのアクセス権はありませんが、最初のオンデマンド インスタンスはすぐにユーザーのクエリに応答できるようになります。 ユーザー クエリにより多くの容量が必要な場合、オートスケールはワークロードに対応するためにより多くのノード (主にスポット インスタンス) を自動的にプロビジョニングします。

Databricks には、マルチテナントのユース ケースをさらに改善するためのその他の機能があります。

このアプローチにより、次の方法で全体的なコストが抑えられます。

  • 共有コンピュートモデルを使用します。

  • オンデマンドインスタンスとスポットインスタンスを組み合わせて使用する。

  • オートスケールを使用して、十分に活用されていないコンピュートへの支払いを回避します。

特殊なワークロード

シナリオ

複雑なデータ探索や機械学習アルゴリズムを実行するデータサイエンティストなど、組織内の特殊なユースケースやチームにコンピュートを提供する必要があります。 典型的なパターンは、ユーザーが分析を実行するために短期間コンピュートを必要とすることです。

この種のワークロードに対する最適なアプローチは、デフォルト、固定、および設定範囲の事前定義された構成を使用してコンピュート ポリシーを作成することです。 これらの設定には、インスタンスの数、インスタンス タイプ、スポット インスタンスとオンデマンド インスタンス、ロール、インストールされるライブラリなどが含まれる場合があります。 コンピュート ポリシーを使用すると、より高度な要件を持つユーザーがコンピュートを迅速に起動して、ユースケースの必要に応じて構成し、ポリシーによるコストとコンプライアンスを強制できるようになります。

特殊なワークロード

このアプローチでは、コンピュート構成を事前に定義することでコストを制御できる機能を維持しながら、ユーザーがより詳細に制御できるようになります。 これにより、さまざまなデータ セットにアクセスする権限を持つさまざまなユーザー グループに対してコンピュートを構成することもできます。

このアプローチの欠点の 1 つは、構成やインストールされたライブラリなどのコンピュートへの変更について、ユーザーが管理者と協力しなければならないことです。

バッチ ワークロード

シナリオ

データ準備を実行する本番運用 ETL ジョブなど、スケジュールされたバッチ ジョブに対してコンピュートを提供する必要があります。 推奨されるベスト プラクティスは、ジョブの実行ごとに新しいコンピュートを起動することです。 新しいコンピュートで各ジョブを実行すると、共有コンピュートで実行されている他のワークロードによって引き起こされる障害や SLA の逸失を回避できます。 ジョブの重要度のレベルに応じて、すべてのオンデマンド インスタンスを使用して SLA を満たすことも、スポット インスタンスとオンデマンド インスタンスのバランスをとってコストを節約することもできます。

スケジュールされたバッチ ワークロード