コンピューティング構成の奨励事項
この記事には、コンピューティング構成に関連する推奨事項とベスト プラクティスが記載されています。
ワークロードがサポートされている場合、Databricks では、独自のコンピューティング リソースを構成するのではなく、サーバーレス コンピューティングを使用することをお勧めします。 サーバーレス コンピューティングは、最もシンプルで信頼性の高いコンピューティング オプションです。 構成は必要なく、常に使用可能であり、ワークロードに応じてスケーリングされます。 サーバーレス コンピューティングは、ノートブック、ジョブ、Delta Live Tables で使用できます。 「サーバーレス コンピューティングに接続する」を参照してください。
さらに、データ アナリストは、サーバーレス SQL ウェアハウスを使用して、Databricks 上のデータのクエリと探索を行うことができます。 「サーバーレス SQL ウェアハウスとは」を参照してください。
コンピューティング ポリシーを使用する
新しいコンピューティングをゼロから作成する場合、Databricks ではコンピューティング ポリシーを使用することをお勧めします。 コンピューティング ポリシーを使うと、個人用コンピューティング、共有コンピューティング、パワー ユーザー、ジョブなどの特定の目的のために設計された事前構成済みのコンピューティング リソースを作成できます。 ポリシーによって、コンピューティング設定を構成するときに行う必要がある決定が制限されます。
ポリシーにアクセスできない場合は、ワークスペース管理者に問い合わせてください。「既定のポリシーとポリシー ファミリ」をご覧ください。
コンピューティングのサイズに関する考慮事項
Note
次の推奨事項では、クラスターの作成に制限がないことを前提としています。 ワークスペース管理者は、この特権を上級ユーザーにのみ付与する必要があります。
多くの場合、コンピューティング サイズはワーカー数の観点から検討されますが、他にも考慮すべき重要な要素があります。
- Executor の合計コア数 (コンピューティング): すべての Executor におけるコアの合計数。 これにより、コンピューティングの最大並列度が決まります。
- Executor の合計メモリ: すべての Executor における RAM の総量。 ディスクに書き込む前にメモリに保存できるデータ量を決定します。
- Executor のローカル ストレージ: ローカル ディスク ストレージの種類と量。 ローカル ディスクは、シャッフルやキャッシュ中にスピルが発生した場合に主に使用されます。
また、ワーカー インスタンスの種類とサイズも、上記の要因に影響するため、考慮する必要があります。 コンピューティングのサイズを設定する場合は、次の点を考慮します。
- ワークロードで消費されるデータ量。
- ワークロードのコンピューティングの複雑さ。
- データの読み取り元。
- 外部ストレージでのデータのパーティションの方法。
- どの程度の並列処理が必要であるか。
これらの質問に答えると、ワークロードに基づいて最適なコンピューティング構成を決定する際に役立ちます。
ワーカーの数とワーカー インスタンス タイプのサイズとの間で、バランスを維持します。 2 つのワーカー (それぞれ 16 コアと 128 GB の RAM) を持つコンピューティングを構成した場合のコンピューティングとメモリは、8 つワーカー (それぞれ 4 コアと 32 GB の RAM) を備えたコンピューティングの構成と同じです。
コンピューティング構成の例
次の例は、特定の種類のワークロードに基づくコンピューティングの推奨事項を示しています。 これらの例では、避けるべき構成と、これらの構成がワークロード タイプに適していない理由も示します。
Note
このセクションのすべての例 (機械学習トレーニング以外) は、新しいコンピューティング リソースをスピンアップするのではなく、サーバーレス コンピューティングを使用することでメリットを得ることができます。 ワークロードがサーバーレスでサポートされていない場合は、次の推奨事項を参考にコンピューティング リソースを構成してください。
データ分析
データ アナリストは、通常、複数のパーティションのデータを必要とする処理を行うため、多くのシャッフル操作が発生します。 ノード数が少なく且つより高スペックのノードで構成されたコンピューティング リソースの場合、これらのシャッフルを実行するために必要なネットワークおよびディスク I/O を削減できます。
新しいコンピューティングを構成する必要がある場合は、大規模な VM の種類を使用する単一ノード コンピューティングが、最適な選択肢です (特に、アナリストが 1 人の場合)。
分析ワークロードでは、同じデータを繰り返し読み取ることが必要な可能性があるので、推奨されるノードの種類は、ディスク キャッシュを有効にしたストレージ最適化したもの、またはローカル ストレージを備えたインスタンスです。
分析ワークロードに推奨される追加機能は次のとおりです。
- 自動終了を有効にすると、非アクティブな期間の後で、コンピューティングが確実に終了されます。
- アナリストの一般的なワークロードに基づいて自動スケーリングを有効にすることを検討してください。
基本的なバッチ ETL
結合や集約など、大規模な変換を必要としない単純なバッチ ETL ジョブでは、通常、Photon のメリットが得られます。 そのため、Photon をサポートする汎用インスタンスを選択してください。
メモリとストレージの要件が低いインスタンスでは、他のワーカー タイプよりコストが下がる可能性があります。
複雑なバッチ ETL
複数のテーブル間での和集合と結合が必要なものなど、複雑な ETL ジョブの場合、Databricks ではシャッフルされるデータの量を減らすために使用するワーカーの数を減らすことをお勧めします。 ワーカーの数を減らすために、インスタンスのサイズを大きくします。
複雑な変換は、コンピューティング集中型になる可能性があります。 ディスクまたは OOM エラーに重大なスピルが発生した場合は、インスタンスで使用可能なメモリ容量を増やします。
必要に応じて、プールを使い、ジョブ パイプラインを実行するときの、コンピューティング起動時間と総実行時間を短縮します。
機械学習モデルのトレーニング
機械学習モデルをトレーニングするために、Databricks では、 Personal コンピューティング ポリシーを使用してコンピューティング リソースを作成することをお勧めします。
機械学習モデルのトレーニングでの最初の実験には、大きなノード タイプの単一ノード コンピューティングを使用する必要があります。 ノード数を減らすと、シャッフルの影響が低下します。
ワーカーを追加すると、安定性に役立つ可能性がありますが、データをシャッフルするオーバーヘッドのため、ワーカーを追加し過ぎないようにする必要があります。
ディスク キャッシュを有効にして最適化されたストレージ、または同じデータの繰り返し読み取りを考慮し、トレーニング データのキャッシュを有効にするローカル ストレージを備えたインスタンスが推奨されるワーカー タイプです。
機械学習ワークロードに推奨されるその他の機能は次のとおりです。
- 自動終了を有効にすると、非アクティブな期間の後で、コンピューティングが確実に終了されます。
- プールを使用すると、コンピューティングを事前に承認されたインスタンス タイプに制限できます。
- ポリシーを使用して一貫性のあるコンピューティング構成を確保します。