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

この記事では、オプションのコンピュート構成を設定するための推奨事項について説明します。 構成の決定を減らすために、 Databricks 、サーバーレス コンピュートとコンピュート ポリシーの両方を活用することを推奨しています。

  • サーバレス コンピュートではコンピュート設定を構成する必要はありません。 サーバレス コンピュートは常に利用可能であり、ワークロードに応じて拡張されます。 コンピュートの種類を参照してください。

  • コンピュート ポリシーを使用すると、個人用コンピュート、共有コンピュート、パワー ユーザー、ジョブなどの特定のユース ケース向けに設計された、事前構成済みのコンピュートを作成できます。 ポリシーにアクセスできない場合は、ワークスペース管理者に問い合わせてください。 デフォルト ポリシーおよびポリシー ファミリを参照してください。

独自の構成でコンピュートを作成する場合は、以下のセクションで一般的な使用例に関する推奨事項を示します。

注：

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

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

コンピュートの規模は労働者の数で決まると考える人が多いですが、他にも考慮すべき重要な要素があります。

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

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

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

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

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

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

  • データの読み取り先

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

  • 必要な並列処理量

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

ワーカーの数とワーカーインスタンスタイプのサイズの間でバランスを取る必要があります。 それぞれ 16 コアと 128 GB の RAM を持つ 2 つの ワーカー でコンピュート を構成すると、それぞれ 4 コアと 32 GB の RAM を持つ 8 つの ワーカー でコンピュート を構成する場合と同じコンピュートとメモリになります。

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

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

データ解析

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

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

注：

ワークスペースで serverless コンピュート パブリック プレビューが有効になっている場合は、serverless コンピュート を使用してPythonまたはSQLで分析を実行できます。 「サーバーレス コンピュートへの接続」を参照してください。

新しいインスタンスを構成する必要がある場合、特に単一のインスタンスの場合は、大規模な VM タイプを備えた単一ノードのインスタンスが最適な選択肢になる可能性があります。

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

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

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

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

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

基本的なバッチETL

注：

ワークスペースで serverless コンピュート for ワークフロー (パブリック プレビュー) が有効になっている場合は、serverless コンピュートを使用してジョブを実行できます。 ワークフローについては、「サーバーレス コンピュートを使用してDatabricksジョブを実行する」を参照してください。

結合や集計などの広範な変換を必要としない単純なバッチETLジョブは、通常、コンピュートに最適化されたワーカー型の恩恵を受けます。

コンピュート最適化されたワーカーは、メモリとストレージの要件が低く、他のワーカー タイプよりもコストを節約できる可能性があります。

複雑なバッチETL

注：

ワークスペースで serverless コンピュート for ワークフロー (パブリック プレビュー) が有効になっている場合は、serverless コンピュートを使用してジョブを実行できます。 ワークフローについては、「サーバーレス コンピュートを使用してDatabricksジョブを実行する」を参照してください。

複数のテーブルにわたる結合や結合を必要とするような複雑な ETL ジョブの場合、Databricks では、シャッフルされるデータの量を減らすためにワーカーの数を減らすことを推奨しています。

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

Databricks 、コンピュートに最適化されたワーカー型を推奨しています。 コンピュート最適化されたワーカーは、メモリとストレージの要件が低く、他のワーカー タイプよりもコストを節約できる可能性があります。 オプションで、プールを使用してコンピュートの起動時間を短縮し、ジョブ パイプラインを実行するときの合計を減らします。

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

Databricks 、トレーニング 機械学習 モデルの初期実験には、大規模ノード タイプを備えた単一ノード コンピュート を推奨しています。 ノード数が少ないほど、シャッフルの影響が軽減されます。

ワーカーを追加すると安定性が向上しますが、データのシャッフルによるオーバーヘッドが発生するため、ワーカーを追加しすぎるのは避けてください。

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

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

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

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