クエリの遅さや高い計算コストは通常、いくつかの根本的な原因から生じます。クエリが必要以上に多くのデータを読み取ること、ノード間でのデータのシャッフル、悪いクエリプランの選択、変更されていないファイルの書き換えなどです。 Azure Databricksは、大規模なETL処理からアドホックでインタラクティブなクエリまでのワークロードにおいて、これらの原因の多くに自動的に対応します。 他の最適化は、特定のワークロードに合わせてオンにしたり調整した場合にのみ適用されます。
このページはほとんどのワークロードに対する推奨事項から始まり、自動で実行されるか設定が必要な最適化をグループ化し、それぞれが解決する問題について説明しています。 ほとんどのDatabricksランタイム最適化には、Azure DatabricksのテーブルのデフォルトフォーマットであるDelta Lakeが必要です。
まずはこれらのおすすめから始めましょう
これらの選択は、ほとんどのワークロードで最大のパフォーマンス向上をもたらします。 また、このページの多くの自動最適化が最大限に機能するのに役立ちます。
-
テーブルのレイアウトにはリキッド クラスタリングを使用します。リキッド クラスタリングはテーブルのパーティション分割と
ZORDERを置き換えます。 頻繁にフィルターをかけるカラムごとにデータを整理し、データのスキップや動的なファイルプルーニングを改善します。 - Unity Catalogのマネージドテーブルを使いましょう。予測最適化はマネージドテーブルを自動的に保守します。 Delta Lake と Apache Iceberg の Unity カタログマネージド テーブルを参照してください。
- Photon対応のコンピュートを使いましょう。 予測 I/O には Photon が必要であり、
MERGE、UPDATE、DELETE文での動的ファイルプルーニングにも同様に Photon が必要です。 「Photon とは」を参照してください。 - 削除ベクターを有効にしてください。 予測I/Oは、更新、削除、マージ時にファイル全体の書き換えを避けるために削除ベクターを使用し、行レベルの並行処理には削除ベクターが必要です。 Delta Lake テーブルでは、削除ベクターを明示的に有効にする必要があります。 Databricks の削除ベクトルを参照してください。
- 最新のDatabricksランタイムを使用してください。 新バージョンには最新のパフォーマンス強化が含まれています。 一部の最適化には、最低限DatabricksランタイムバージョンまたはPhoton対応のコンピュートが必要です。 各ページで要件を確認してください。
自動最適化
これらの最適化はデフォルトでオンになっています。 必ずしも有効にする必要はありませんが、Photonの使用やテーブル統計の最新状態の維持など、テーブルやコンピュートが特定の条件を満たす場合に、より大きなメリットをもたらすものもあります。
- ディスクキャッシュ:同じリモートのParquetおよびDelta Lakeのデータファイルを繰り返し読み込むクエリを高速化します。 Azure Databricksはファイルのコピーをコンピュートノードのローカルストレージにキャッシュし、後の読み取りがローカルで実行できるようにします。 Azure Databricks は、それをサポートするワーカー インスタンスの種類では自動的に有効になります。
-
動的ファイルプルーニング: Delta Lakeテーブルの結合で一致する行を含む可能性がないファイルをスキップします。
MERGE、UPDATE、DELETE文は動的ファイルプルーニングのためにPhoton対応コンピュートを必要とします。 -
ローシャッフルマージ: 各ファイルの数行を更新または削除する操作を
MERGE高速化します。 低シャッフル マージは、変更されていない行をシャッフルせずに処理し、既存のデータ レイアウトを保持します。 - 適応型クエリ実行: クエリの実行中に、実際のデータサイズに基づいてクエリ計画を再最適化します。 これにより、低速の結合戦略、多すぎる小規模タスク、誤った推定から生じるスキュー タスクが修正されます。
- 予測I/O: Photon対応のコンピュート環境でデータスキャンを高速化し、更新、削除、マージ時に書き換えるデータを削減します。
- コストベースオプティマイザ:テーブルとカラム統計を用いて効率的なクエリプランを選択し、特に複数の結合を持つクエリに対して有効です。 コストベースのオプティマイザーは統計に依存しているため、それらを収集して最新の状態に保ちましょう。
-
予測最適化: Unity Catalog のマネージド テーブル上で
OPTIMIZE、VACUUM、ANALYZEを自動的に実行するため、テーブルのメンテナンスをスケジュールする必要がありません。 また、コストベースオプティマイザーが使用する統計も最新の状態に保ちます。 アカウントで有効かどうかを確認するには、「 予測最適化が有効かどうか確認」をご覧ください。
構成した最適化
これらの最適化を有効にしたり、調整したり、テーブルの設定を変更したりする必要があります。 デフォルトでカバーされない動作が必要なワークロードのときに使います。
- アーカイブサポート:クラウドライフサイクルポリシーで古いテーブルファイルをアーカイブストレージ層に移行し、ストレージコストを削減する際に利用します。 アーカイブサポートは、Azure Databricksに指定された期間より古いファイルを無視するように指示しており、ライフサイクルポリシーが最近のデータのみを読み取るクエリに支障を与えないようにしています。 この機能はパブリック プレビュー段階にあります。
- 範囲結合: 結合で、間隔内のポイントまたは間隔の重複条件を使用する場合に使用します。 Databricks SQLはレンジの結合を自動的に最適化します。 他のコンピュートでは、範囲結合をjoin hintやセッション設定で調整します。
- 分離レベルと書き込み競合:同じテーブルへの同時書き込みが競合する場合や、ワークロードがデフォルトのWriteSerializable隔離レベルよりも厳しい保証を必要とする場合に使用されます。 シリアライズ可能なアイソレーションは 、同時書き込み時のスループットを低下させます。 行レベルの同時実行制御は、要件を満たすテーブル上の並行書き込み間の多くの競合を自動的に解決します。
-
全文検索インデックス: クエリが
searchやisearchの機能でテキスト列内のサブ文字列や単語を検索する場合に使用します。 インデックスは一致する行を含めることができないファイルはスキップします。 この機能はベータ版です。
注意
ブルームフィルターインデックスは、廃止されたデータスキップ機能です。 書き込みのオーバーヘッドが増え、調整も難しいです。 テーブルにそれらが含まれている場合は、「ブルーム フィルター インデックス (非推奨)」を参照して、それらを置き換えて削除してください。
その他のパフォーマンス機能
- 上位の関数には、一般的な Spark 演算子を持たない多くの操作に対する、組み込みの最適化されたパフォーマンスが含まれています。 高次関数はユーザー定義関数よりも優れた性能を発揮します。
- Azure Databricksには、配列、構造体、JSON文字列などの複雑なデータ型を扱うための組み込み演算子や特別な構文があります。
- Spark SQL クエリは、先に解析せずに JSON 文字列に対してクエリを実行します。
- 書き込みによって生成されるデータ ファイルのサイズを制御するには、「データ ファイルのサイズを制御する」を参照してください。
- テーブル設計およびメンテナンスの指針については、 Best practices: Delta Lakeをご覧ください。
低速または高価なワークロードを診断する
ワークロードが予想より遅い、またはコストが高い場合で、その理由がわからない場合は、設定を変更する前にSparkのUIを使ってボトルネックを見つけてください。 Spark UIを使ったコストとパフォーマンスの問題の診断を参照してください。