コンピュート構成の推奨事項

この記事には、コンピュートの構成に関連する推奨事項とベストプラクティスが含まれています。

ワークロードがサポートされている場合は、独自のコンピュートリソースを設定するのではなく Databricks 、サーバレスコンピュートを使用することをお勧めします。サーバレスコンピュートは、最もシンプルで信頼性の高いコンピュートオプションです。設定は不要で、常に利用可能で、ワークロードに応じて拡張できます。サーバレスコンピュートは、ノートブック、ジョブ、および Delta Live Tablesで使用できます。 Connect to サーバレスコンピュートを参照してください。

さらに、データアナリストはサーバレス SQLウェアハウスを使用して、 Databricksに関するデータのクエリと探索を行うことができます。サーバレス SQLウェアハウスとはを参照してください。

Use コンピュートポリシー

新しいコンピュートを一から作成する場合は、コンピュートポリシーの使用 Databricks おすすめします。コンピュートポリシーを使用すると、個人用コンピュート、共有コンピュート、パワーユーザー、ジョブなど、特定の目的向けに設計された事前構成済みのコンピュートリソースを作成できます。ポリシーコンピュート設定を構成するときに行う必要がある決定を制限します。

ポリシーにアクセスできない場合は、ワークスペース管理者にお問い合わせください。「デフォルトポリシーファミリー」および「ポリシーファミリー」を参照してください。

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

注：

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

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

総エグゼキューターコア数（コンピューティング）: すべてのエグゼキューターのコアの合計数。これにより、コンピュートの最大並列処理が決まります。
総エグゼキューターメモリ容量: すべてのエグゼキューターのRAMの合計容量。これにより、ディスクにスピルする前にメモリに格納できるデータの量が決まります。
エグゼキューターローカルストレージ: ローカルディスクストレージのタイプと容量。ローカルディスクは、主にシャッフルおよびキャッシュ中にデータがスピルした場合に使用されます。

その他の考慮事項には、ワーカーインスタンスのタイプとサイズが含まれますが、これも上記の要因に影響します。コンピュートをサイジングするときは、以下を考慮してください。

ワークロードのデータ消費量
ワークロードのコンピューティングの複雑さの度合い
データの読み取り先
外部ストレージでのデータのパーティション方法
必要な並列処理量

以上を考慮して、ワークロードに基づく最適なコンピュート構成を決定します。

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

コンピュートの設定例

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

注：

このセクションのすべての例 (機械学習トレーニングを除く) は、新しいコンピュートリソースを作成するのではなく、サーバレスコンピュートを使用する方が有益です。ワークロードがサーバレスでサポートされていない場合は、以下の推奨事項を使用してコンピュートリソースを設定してください。

データ分析

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

大規模な VM タイプを持つ単一ノードコンピュートは、特に 1 人のアナリストにとって最適な選択肢である可能性があります。

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

分析ワークロードに推奨されるその他の機能には以下が含まれます。

自動終了を有効にすると、非アクティブ状態が一定期間続いた後にコンピュートを終了させることができます。
アナリストの一般的なワークロードに基づいてオートスケーリングを有効にすることを検討してください。

基本的なバッチETL

単純なバッチ ETL ジョブで、結合や集計などの広範な変換を必要としないジョブでは、通常、Photon.そのため、Photon をサポートする汎用インスタンスを選択します。

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

複雑なバッチETL

ユニオンや複数のテーブル間での結合が必要なジョブなど、複雑な ETL ジョブの場合、Databricks では、シャッフルされるデータの量を減らすために、使用するワーカーを減らすことをお勧めします。ワーカーの数が少ないことを補うには、インスタンスのサイズを増やします。

複雑な変換は、コンピュートを多用することがあります。ディスクへの書き込みエラーや OOM エラーが大量に発生する場合は、インスタンスで使用可能なメモリの量を増やします。

必要に応じて、プールを使用することで、ジョブパイプラインを実行する際のコンピュート起動時間や合計ランタイムが短縮されます。

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

トレーニングする機械学習モデルに対して、 Databricks は Personal コンピュート ポリシーを使用してコンピュートリソースを作成することをお勧めします。

トレーニング機械学習モデルを使用した初期実験には、大きなノードタイプの単一ノードコンピュートを使用する必要があります。ノード数が少ないと、シャッフルの影響が軽減されます。

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

推奨されるワーカーの種類は、ディスクキャッシュが有効になっているストレージ最適化、または同じデータを繰り返し読み取り、トレーニングデータのキャッシュを有効にするためにアカウントにローカルストレージを持つインスタンスです。

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

自動終了を有効にすると、非アクティブ状態が一定期間続いた後にコンピュートを終了させることができます。
プールを使用すると、コンピュートを事前承認済みのインスタンスタイプに制限できます。
ポリシーを使用してコンピュート構成の一貫性を確保します。