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