コンピュート構成の推奨事項
この記事には、コンピュートの構成に関連する推奨事項とベスト プラクティスが含まれています。
ワークロードがサポートされている場合は Databricks 、独自のコンピュート リソースを設定するのではなく、サーバレス コンピュートを使用することをお勧めします。 サーバレス コンピュートは、最もシンプルで信頼性の高いコンピュート オプションです。 構成は不要で、常に利用可能で、ワークロードに応じてスケーリングされます。サーバレス コンピュートは、ノートブック、ジョブ、および LakeFlow Declarative パイプラインのコンピュートオプションです。 サーバレス コンピュートに接続を参照してください。
さらに、データアナリストはサーバレス SQLウェアハウスを使用して、 Databricksに関するデータのクエリと探索を行うことができます。 サーバレス SQLウェアハウスとはを参照してください。
適切なアクセスモードを選択する
クラシック万能とジョブコンピュートには、コンピュートリソースに添付して使用できるユーザーを決定するアクセスモード設定があります。 Unity Catalogでは、コンピュートは標準または専用アクセスモードのいずれかを使用する必要があります。
標準コンピュートは、ユーザーの分離とすべてのユーザーおよびグループレベルのデータアクセス許可を適用しながら、複数のユーザーおよびグループで共有できます。 これにより、ほとんどのワークロード、特にきめ細かなアクセス制御を強制するワークロードにとって、管理が容易でコスト効率の高いオプションになります。
専用コンピュートは、 RDD APIs、GPU インスタンス、R、 Databricks Container サービスなど、標準コンピュートでは利用できない機能にアクセスする必要がある場合に推奨されます。 詳細については、 情報 「標準コンピュートの要件と制限」を参照してください。
コンピュート ポリシーの活用
一から新しいコンピュートを作成する場合は、コンピュート ポリシーを活用することをおすすめします。 コンピュート ポリシーを使用すると、個人用コンピュート、共有コンピュート、パワー ユーザー、ジョブなど、特定の目的向けに設計された事前構成済みのコンピュート リソースを作成できます。 ポリシーは、コンピュート設定を構成する際の選択肢を制限します。
ポリシーにアクセスできない場合は、ワークスペース管理者にお問い合わせください。デフォルト ポリシー およびポリシー ファミリーを参照してください。
Photonの恩恵を受けるかどうかを評価します
多くのワークロードがPhotonの恩恵を受けますが、大きなテーブルでの結合、集計、データスキャンなど、複雑な変換を伴うSQLワークロードやDataFrame操作に最も有益です。ディスク アクセスが頻繁なワークロード、ワイド テーブル、またはデータ処理が繰り返されるワークロードでも、パフォーマンスが向上します。
単純なバッチ ETL ジョブは、広い変換や大量のデータを必要としませんが、特にクエリが通常 2 秒以内に完了する場合は、 Photonを有効にしても影響が最小限に抑えられる可能性があります。
コンピュートのサイズに関する考慮事項
次の推奨事項は、制限なしのクラスター作成権限を持っていることを前提としています。 ワークスペース管理者は、この権限を上級ユーザーにのみ付与する必要があります。
コンピューティングサイズはワーカー数の観点からよく考慮されますが、他にも考慮すべき重要な要素があります。
- 総エグゼキューターコア数（コンピューティング）: すべてのエグゼキューターのコアの合計数。これにより、コンピュートの最大並列処理が決まります。
- 総エグゼキューターメモリ容量: すべてのエグゼキューターのRAMの合計容量。これにより、ディスクにスピルする前にメモリに格納できるデータの量が決まります。
- エグゼキューターローカルストレージ: ローカルディスクストレージのタイプと容量。ローカルディスクは、主にシャッフルおよびキャッシュ中にデータがスピルした場合に使用されます。
その他の考慮事項には、ワーカーインスタンスのタイプとサイズが含まれますが、これも上記の要因に影響します。コンピュートをサイジングするときは、以下を考慮してください。
- ワークロードのデータ消費量
- ワークロードの計算の複雑さはどの程度ですか?
- データの読み取り先
- 外部ストレージでのデータのパーティション方法
- 必要な並列処理量
以上を考慮して、ワークロードに基づく最適なコンピュート構成を決定します。
ワーカーの数とワーカーインスタンスタイプのサイズとの間にはバランスを取る必要があります。 2 人のワーカー (それぞれ 16 コアと 128 GB の RAM) でコンピュートを構成すると、コンピュートとメモリは、8 人のワーカー (それぞれ 4 コアと 32 GB の RAM を持つ) でコンピュートを構成するのと同じになります。
コンピュートの設定例
次の例は、特定のタイプのワークロードに基づくコンピュートの推奨事項を示しています。これらの例には、避けるべき構成と、その構成がワークロードのタイプに適さない理由も含まれています。
このセクションのすべての例 (機械学習トレーニングを除く) は、新しいコンピュート リソースを作成するのではなく、サーバレス コンピュートを使用する方が有益です。 ワークロードがサーバレスでサポートされていない場合は、以下の推奨事項を使用してコンピュート リソースを設定してください。
データ分析
データアナリストは通常、複数のパーティションからのデータを必要とする処理を実行するため、多くのシャッフル操作が発生します。 大きなノードの数が少ないコンピュート リソースでは、これらのシャッフルを実行するために必要なネットワークとディスク I/O を削減できます。
大規模な VM タイプを持つ単一ノード コンピュートは、特に 1 人のアナリストにとって最適な選択肢である可能性があります。
分析ワークロードでは、同じデータを繰り返し読み取る必要がある可能性が高いため、推奨されるノードの種類は、ディスク キャッシュが有効になっているストレージ最適化、またはローカル ストレージを持つインスタンスです。
分析ワークロードに推奨されるその他の機能には以下が含まれます。
- 自動終了を有効にすると、非アクティブ状態が一定期間続いた後にコンピュートを終了させることができます。
- アナリストの一般的なワークロードに基づいてオートスケールを有効にすることを検討してください。
基本バッチ ETL
結合や集計など、幅広い変換を必要としない単純なバッチ ETL ジョブの場合は、メモリとストレージの要件が低いインスタンスを使用します。これにより、他のワーカーの種類よりもコストが削減される可能性があります。
複雑なバッチ ETL
ユニオンや複数のテーブル間での結合が必要なジョブなど、複雑な ETL ジョブの場合、Databricks では、シャッフルされるデータの量を減らすために、使用するワーカーを減らすことをお勧めします。 ワーカーの数が少ないことを補うには、インスタンスのサイズを増やします。
複雑な変換は、コンピュートを多用することがあります。 ディスクへの書き込みエラーや OOM エラーが大量に発生する場合は、インスタンスで使用可能なメモリの量を増やします。
必要に応じて、プールを使用することで、ジョブパイプラインを実行する際のコンピュート起動時間や合計ランタイムが短縮されます。
機械学習モデルのトレーニング
トレーニングする 機械学習モデルに対して、 Databricksは パーソナル コンピュート ポリシーを使用してコンピュート リソースを作成することをお勧めします。
トレーニング 機械学習モデルを使用した初期実験には、大きなノード タイプの単一ノード コンピュートを使用する必要があります。 ノード数が少ないと、シャッフルの影響が軽減されます。
ワーカーを増やすと安定性が向上しますが、データのシャッフルのオーバーヘッドのため、ワーカーを追加しすぎないようにする必要があります。
推奨されるワーカーの種類は、ディスク キャッシュが有効になっているストレージ最適化、または同じデータを繰り返し読み取り、トレーニング データのキャッシュを有効にするためにアカウントにローカル ストレージを持つインスタンスです。
機械学習ワークロードに推奨されるその他の機能は以下のとおりです。
- 自動終了を有効にすると、非アクティブ状態が一定期間続いた後にコンピュートを終了させることができます。
- プールを使用すると、コンピュートを事前承認済みのインスタンスタイプに制限できます。
- ポリシーを使用してコンピュート構成の一貫性を確保します。