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

この記事では、オプションのコンピューティング構成の設定に関する推奨事項について説明します。 構成に関して決めなければならないことを減らすため、Azure Databricks では、サーバーレス コンピューティングとコンピューティング両方のポリシーを利用することをお勧めします。

• サーバーレス コンピューティングでは、コンピューティングの設定を構成する必要はありません。 サーバーレス コンピューティングは常に使用でき、ワークロードに応じてスケーリングされます。 「コンピューティングの種類」をご覧ください。

• コンピューティング ポリシーを使うと、個人用コンピューティング、共有コンピューティング、パワー ユーザー、ジョブなどの特定のユース ケース向けに設計された事前構成済みのコンピューティングを作成できます。 ポリシーにアクセスできない場合は、ワークスペース管理者に問い合わせてください。「既定のポリシーとポリシー ファミリ」をご覧ください。

独自の構成でコンピューティングを作成する場合は、以下のセクションで一般的なユース ケースに関する推奨事項を示します。

Note

この記事では、ユーザーはクラスターの作成を制限されていないものとします。 ワークスペース管理者は、この特権を上級ユーザーにのみ付与する必要があります。

コンピューティングのサイズに関する考慮事項

多くの場合、コンピューティング サイズはワーカー数の観点から検討されますが、他にも考慮すべき重要な要素があります。

• Executor の合計コア数 (コンピューティング): すべての Executor におけるコアの合計数。 これにより、コンピューティングの最大並列度が決まります。
• Executor の合計メモリ: すべての Executor における RAM の総量。 ディスクに書き込む前にメモリに保存できるデータ量を決定します。
• Executor のローカル ストレージ: ローカル ディスク ストレージの種類と量。 ローカル ディスクは、シャッフルやキャッシュ中にスピルが発生した場合に主に使用されます。

また、ワーカー インスタンスの種類とサイズも、上記の要因に影響するため、考慮する必要があります。 コンピューティングのサイズを設定する場合は、次の点を考慮します。

• ワークロードで消費されるデータ量。
• ワークロードのコンピューティングの複雑さ。
• データの読み取り元。
• 外部ストレージでのデータのパーティションの方法。
• どの程度の並列処理が必要であるか。

これらの質問に答えると、ワークロードに基づいて最適なコンピューティング構成を決定する際に役立ちます。

ワーカーの数とワーカー インスタンス タイプのサイズとの間で、バランスを維持します。 2 つのワーカー (それぞれ 40 コアと 100 GB の RAM) を持つコンピューティングを構成した場合のコンピューティングとメモリは、10 コアと 25 GB の RAM を備えたコンピューティングの構成と同じです。

コンピューティングのサイズ設定の例

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

データ分析

データ アナリストは、通常、複数のパーティションのデータを必要とする処理を行うため、多くのシャッフル操作が発生します。 ノード数が少ないコンピューティングでは、これらのシャッフルを実行するために必要なネットワークとディスク I/O を削減できます。

SQL のみを記述する場合、データ分析に最適なオプションはサーバーレス SQL ウェアハウスです。

Note

ワークスペースでサーバーレス コンピューティングのパブリック プレビューが有効になっている場合は、サーバーレス コンピューティングを使って Python または SQL での分析を実行できます。 「ノートブックのサーバーレス コンピューティング」をご覧ください。

新しいコンピューティングを構成する必要がある場合は、大きい VM の種類を使用する単一ノード コンピューティングが、おそらく最適な選択肢です (特に、アナリストが 1 人の場合)。

分析ワークロードでは、同じデータを繰り返し読み取ることが必要な可能性があるので、推奨されるノードの種類はディスク キャッシュを有効にしたストレージ最適化です。

分析ワークロードに推奨される追加機能は次のとおりです。

• 自動終了を有効にすると、非アクティブな期間の後で、コンピューティングが確実に終了されます。
• アナリストの一般的なワークロードに基づいて自動スケーリングを有効にすることを検討してください。
• プールの使用を検討します。これにより、コンピューティングを事前承認されたインスタンスの種類に制限し、一貫性のあるコンピューティング構成を保証できます。

基本的なバッチ ETL

Note

ワークスペースでワークフローのサーバーレス コンピューティングが有効になっている場合 (パブリック プレビュー)、サーバーレス コンピューティングを使ってジョブを実行できます。 「ノートブックのサーバーレス コンピューティング」をご覧ください。

結合や集約など、大規模な変換を必要としない単純なバッチ ETL ジョブでは、通常、コンピューティング最適化ワーカー タイプが有効です。

コンピューティング最適化ワーカーは、必要なメモリとストレージが少なく、他のワーカー タイプよりコストが下がる可能性があります。

複雑なバッチ ETL

Note

ワークスペースでワークフローのサーバーレス コンピューティングが有効になっている場合 (パブリック プレビュー)、サーバーレス コンピューティングを使ってジョブを実行できます。 「ノートブックのサーバーレス コンピューティング」をご覧ください。

複数のテーブル間での和集合と結合が必要なものなど、複雑な ETL ジョブでは、ワーカーの数を減らして、シャッフルされるデータの量を減らすことをお勧めします。

複雑な変換は、コンピューティング集中型になる可能性があります。 ディスクへの大量のスピルや OOM エラーが発生する場合は、ノードを追加する必要があります。

Databricks では、コンピューティング最適化ワーカー タイプをお勧めします。 コンピューティング最適化ワーカーは、必要なメモリとストレージが少なく、他のワーカー タイプよりコストが下がる可能性があります。 必要に応じて、プールを使い、ジョブ パイプラインを実行するときの、コンピューティング起動時間と総実行時間を短縮します。

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

Databricks では、機械学習モデルのトレーニングでの最初の実験には、大きなノード タイプの単一ノード コンピューティングをお勧めします。 ノード数を減らすと、シャッフルの影響が低下します。

ワーカーを追加すると、安定性に役立つ可能性がありますが、データをシャッフルするオーバーヘッドのため、ワーカーを追加し過ぎないようにする必要があります。

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

機械学習ワークロードに推奨されるその他の機能は次のとおりです。

• 自動終了を有効にすると、非アクティブな期間の後で、コンピューティングが確実に終了されます。
• プールを使用します。これにより、コンピューティングを事前承認されたインスタンスの種類に制限し、一貫性のあるコンピューティング構成を保証できます。