クラシック コンピュート構成のベストプラクティス
このページでは、クラシック コンピュート リソースの設定に関するベストプラクティスを概説しています。ほとんどの新しいワークロードでは、Databricksでは設定不要なサーバレスコンピュートを使用することをお勧めします。ワークロードがサーバレス コンピュートでサポートされていない場合（「サーバレスの制限事項」を参照）、次のベストプラクティスを使用して、従来のコンピュート リソースを構成してください。
構造化ストリーミング ワークフローには特定の構成の推奨事項があります。構造化ストリーミングについては、本番運用に関する考慮事項を参照してください。
アクセスモード
クラシック コンピュート リソースは、標準または専用のアクセスモードのいずれかに割り当てることができ、これにより、コンピュート リソースにアタッチして使用できるユーザーが決定されます。
Databricks では、ほとんどのワークロードに対して標準アクセス モードを使用することをお勧めします。標準コンピュートは、ユーザー分離とすべてのデータアクセス権限を適用した上で、複数のユーザーとグループで共有できます。これにより、ほとんどのワークロードにとって管理しやすく、コスト効率の高いオプションとなります。
ワークロードに GPU 上の 機械学習 Runtime、RDD APIs、または R などの標準コンピュートの特定の制限がある場合にのみ、専用アクセス モードを使用してください。詳細については、標準コンピュートの要件と制限を参照してください。
Unity Catalog が有効になっている場合、spark.databricks.passthrough.enabled は設定しないでください。資格情報のパススルーは、レガシーなアクセスモードであり、Unity Catalog と互換性がありません。
アクセスモードを参照してください。
Databricks Runtimeのバージョン
最新の長期サポート (LTS) Databricks Runtime バージョンを使用するLTSバージョンには、拡張セキュリティパッチとバグ修正が提供されるため、ワークロードは安定し、最新のプラットフォーム機能との互換性を維持できます。
ワークロードがGPU、分散機械学習トレーニング、またはAutoMLを使用している場合にのみ、機械学習ランタイムを選択してください。Databricks Runtime for 機械学習 は、不要な場合に独自の依存関係と競合する可能性がある多数のライブラリをインストールし、エラーや潜在的な正確性の問題を引き起こす可能性があります。AI と 機械学習 モデルをトレーニングするを参照してください。
構成の管理
これらのプラクティスにより、コンピュート構成をクリーンに保ち、ワークロードをポータブルにすることができます。
initスクリプトの使用を避ける
initスクリプトは、ワークロードを中断させ、環境の予測可能性を低下させるようなライブラリの競合など、予期しない動作を引き起こす可能性があります。代わりに、ライブラリをコンピュートポリシーに追加するか、ノートブックで%pip installを使用するか、または環境仕様で依存関係を定義してください。ポリシーへのライブラリの追加を参照してください。
Spark構成をハードコーディングしないでください
コンピュートまたはジョブ定義で、Spark 構成 (spark.executor.memory や spark.dynamicAllocation.* など) をハードコーディングすることは避けてください。ハードコードされた値は、Databricks が提供する組み込みの最適化を上書きし、多くの場合、無駄な費用やパフォーマンスの低下につながります。デフォルトを上書きする特定の理由がある場合にのみ、ノートブックスコープのセッション構成を使用します。
コンピュートローカルストレージパスの回避
コンピュートのライフサイクルを超えて永続化されないコンピュートローカルパスに、データを保存しないでください。代わりに、Unity Catalog ボリュームまたは一時ストレージを使用してください。ボリュームとはを参照してください。
DBFS マウントを避ける
DBFS マウントは適切なアクセス制御リスト（ACL）を備えていません。代わりに、Unity Catalogボリュームまたはワークスペースファイルシステム(WSFS)を使用してください。ボリュームとはを参照してください。
コンピュートスコープライブラリのインストールは避ける
コンピュートレベルでライブラリをインストールすると、ジョブ間で環境ドリフトが発生します。代わりに、ノートブックで%pip installを使用するか、環境仕様で依存関係を定義します。これにより、クラシックワークロードもサーバレスに移行しやすくなります。
パフォーマンス
Photonの恩恵を受けるかどうかを評価します
多くのワークロードがPhotonの恩恵を受けますが、大きなテーブルでの結合、集計、データスキャンなど、複雑な変換を伴うSQLワークロードやDataFrame操作に最も有益です。ディスク アクセスが頻繁なワークロード、ワイド テーブル、またはデータ処理が繰り返されるワークロードでも、パフォーマンスが向上します。
単純なバッチ ETL ジョブは、広い変換や大量のデータを必要としませんが、特にクエリが通常 2 秒以内に完了する場合は、 Photonを有効にしても影響が最小限に抑えられる可能性があります。
オートスケールを使用します
オートスケールを構成して、実行時間の長いタスクがジョブの実行中にワーカーノードを動的に追加および削除できるようにします。 オートスケールを有効にするを参照してください。
インスタンスプールを使用して起動時間を短縮する
インスタンス プールは、クラウド プロバイダーからコンピュート リソースを予約できます。プールは、新しいクラスターの開始時間を短縮し、コンピュート リソースの可用性を確保します。「プール構成リファレンス」を参照してください。
コスト最適化
コンピュート ポリシーの活用
Databricks では、コンピュート ポリシーを使用することをお勧めします。コンピュート ポリシーを使用すると、個人用コンピュート、共有コンピュート、パワー ユーザー、ジョブなど、特定の目的向けに設計された事前構成済みのコンピュート リソースを作成できます。ポリシーは、コンピュート設定を構成する際の選択肢を制限します。
ポリシーにアクセスできない場合は、ワークスペース管理者にお問い合わせください。デフォルト ポリシー およびポリシー ファミリーを参照してください。
スポットインスタンスの使用
コストを最適化するために、レイテンシー要件が緩やかなワークロード向けにスポットインスタンスを構成します。スポットインスタンスを参照してください。
アベイラビリティゾーンの構成
組織がリザーブドインスタンスを購入した場合はアベイラビリティーゾーン (AZ) を指定し、AWS が容量不足エラーを返した場合は、Auto-AZ を使用して他のアベイラビリティーゾーンで再試行します。アベイラビリティーゾーンを参照してください。
コンピュートのサイズに関する考慮事項
次の推奨事項は、制限なしのクラスター作成権限を持っていることを前提としています。 ワークスペース管理者は、この権限を上級ユーザーにのみ付与する必要があります。
コンピューティングサイズはワーカー数の観点からよく考慮されますが、他にも考慮すべき重要な要素があります。
- 総エグゼキューターコア数（コンピューティング）: すべてのエグゼキューターのコアの合計数。これにより、コンピュートの最大並列処理が決まります。
- 総エグゼキューターメモリ容量: すべてのエグゼキューターのRAMの合計容量。これにより、ディスクにスピルする前にメモリに格納できるデータの量が決まります。
- エグゼキューターローカルストレージ: ローカルディスクストレージのタイプと容量。ローカルディスクは、主にシャッフルおよびキャッシュ中にデータがスピルした場合に使用されます。
その他の考慮事項には、ワーカーインスタンスのタイプとサイズが含まれますが、これも上記の要因に影響します。コンピュートをサイジングするときは、以下を考慮してください。
- ワークロードのデータ消費量
- ワークロードの計算の複雑さはどの程度ですか?
- データの読み取り先
- 外部ストレージでのデータのパーティション方法
- 必要な並列処理量
ワーカー数とワーカーインスタンスタイプのサイズの間でバランスを取る必要があります。それぞれ16個のコアと128 GBのRAMを持つ2つのワーカーでコンピュートを構成した場合、コンピュートとメモリは、それぞれ4個のコアと32 GBのRAMを持つ8つのワーカーで構成した場合と同じになります。
コンピュートの設定例
次の例は、特定のタイプのワークロードに基づくコンピュートの推奨事項を示しています。これらの例には、避けるべき構成と、その構成がワークロードのタイプに適さない理由も含まれています。
このセクションのすべての例は、新しいコンピュートリソースを起動するよりも、サーバレスコンピュートを使用することでメリットが得られます。ワークロードがサーバレスでサポートされていない場合は、クラシックコンピュートリソースの構成に役立てるため、以下の推奨事項を使用してください。
データ分析
データアナリストは通常、複数のパーティションからのデータを必要とする処理を実行するため、多くのシャッフル操作が発生します。 大きなノードの数が少ないコンピュート リソースでは、これらのシャッフルを実行するために必要なネットワークとディスク I/O を削減できます。
大規模な VM タイプを持つ単一ノード コンピュートは、特に 1 人のアナリストにとって最適な選択肢である可能性があります。
分析ワークロードでは、同じデータを繰り返し読み取る必要がある可能性が高いため、推奨されるノードの種類は、ディスク キャッシュが有効になっているストレージ最適化、またはローカル ストレージを持つインスタンスです。
分析ワークロードに推奨されるその他の機能には以下が含まれます。
- 自動終了を有効にすると、非アクティブ状態が一定期間続いた後にコンピュートを終了させることができます。
- アナリストの一般的なワークロードに基づいてオートスケールを有効にすることを検討してください。
基本バッチ ETL
結合や集計など、幅広い変換を必要としない単純なバッチ ETL ジョブの場合は、メモリとストレージの要件が低いインスタンスを使用します。これにより、他のワーカーの種類よりもコストが削減される可能性があります。
複雑なバッチ ETL
ユニオンや複数のテーブル間での結合が必要なジョブなど、複雑な ETL ジョブの場合、Databricks では、シャッフルされるデータの量を減らすために、使用するワーカーを減らすことをお勧めします。 ワーカーの数が少ないことを補うには、インスタンスのサイズを増やします。
複雑な変換は、コンピュートを多用することがあります。 ディスクへの書き込みエラーや OOM エラーが大量に発生する場合は、インスタンスで使用可能なメモリの量を増やします。
必要に応じて、インスタンスプールを使用することで、ジョブパイプラインを実行する際のコンピュート起動時間や合計ランタイムが短縮されます。
機械学習モデルのトレーニング
トレーニングする 機械学習モデルに対して、 Databricksは パーソナル コンピュート ポリシーを使用してコンピュート リソースを作成することをお勧めします。
初期実験には、大型ノードタイプのシングルノードのコンピュートを使用してください。ノード数が少なければ、シャッフルの影響も軽減されます。
ワーカーを増やすと安定性が向上しますが、データのシャッフルのオーバーヘッドのため、ワーカーを追加しすぎないようにする必要があります。
推奨されるワーカーの種類は、ディスク キャッシュが有効になっているストレージ最適化、または同じデータを繰り返し読み取り、トレーニング データのキャッシュを有効にするためにアカウントにローカル ストレージを持つインスタンスです。
機械学習ワークロードに推奨されるその他の機能は以下のとおりです。
- 自動終了を有効にすると、非アクティブ状態が一定期間続いた後にコンピュートを終了させることができます。
- インスタンスプールを使用して、コンピュートを事前に承認されたインスタンスタイプに制限してください。
- ポリシーを使用してコンピュート構成の一貫性を確保します。