Databricks での最適化に関する推奨事項

低速なクエリーと高いコンピュートコストは、通常、クエリーが必要なデータ以上のデータの読み取り、ノード間のデータのシャッフル、不適切なクエリープランの選択、または変更されていないファイルの書き換えなど、いくつかの根本的な原因に起因します。Databricksは、大規模なETL処理からアドホックなインタラクティブクエリーまで、さまざまなワークロードに対して、これらの原因の多くに自動的に対処します。その他の最適化は、特定のワークロードに対して有効または調整した場合にのみ適用されます。

このページでは、ほとんどのワークロードに推奨される事項から説明します。次に、最適化が自動的にランするか、手動による設定が必要かによって最適化をグループ化し、それぞれの最適化によって解決される課題について説明します。ほとんどのDatabricks Runtime最適化には、Databricksのテーブルのdefault形式であるDelta Lakeが必要です。

まず、これらの推奨事項から始めます

これらの選択肢により、ほとんどのワークロードで最大のパフォーマンス向上が得られます。また、このページの多くの自動最適化を最大限に活用するのにも役立ちます。

• テーブルレイアウトにリキッドクラスタリングを使用します。 リキッドクラスタリングは、テーブルのパーティション分割とZORDERを置き換えます。頻繁にフィルタリングする列に基づいてデータを整理し、データスキッピングと動的ファイルプルーニングを改善します。
• Unity Catalogマネージドテーブルを使用してください。 予測的最適化はマネージドテーブルを自動的に維持します。Delta LakeとApache Iceberg用のUnity Catalogマネージドテーブルを参照してください。
• Photon対応のコンピュートを使用します。 予測I/OにはPhotonが必要であり、 MERGE、 UPDATE、および DELETE ステートメントの動的ファイルプルーニングも必要です。Photonとはを参照してください。
• 削除ベクトルを有効にする。 予測 I/O は、削除ベクトルを使用して、更新、削除、および Merge 中にファイル全体を書き換えることを回避し、行レベルのコンカレンシーにはそれらが必要となります。Delta Lake テーブルの場合は、削除ベクトルを明示的に有効にする必要があります。Databricks での削除ベクトルを参照してください。
• 最新のDatabricks Runtimeを使用してください。 新しいバージョンには、最新のパフォーマンス向上機能が含まれています。最適化の中には、最低限のDatabricks RuntimeバージョンまたはPhoton対応のコンピュートを必要とするものもあります。要件については、各ページを参照してください。

自動最適化

これらの最適化はdefaultで有効になっています。これらを有効にする必要はありませんが、Photonの使用やテーブル統計の最新化など、テーブルとコンピュートが特定の条件を満たすと、さらなる利点が得られる場合があります。

• ディスクキャッシング: 同じリモート Parquet および Delta Lake データファイルを繰り返し読み取るクエリーを高速化します。Databricks はファイルのコピーをコンピュートノードのローカルストレージにキャッシュするため、後の読み取りはローカルで実行されます。Databricks は、サポートするワーカーインスタンスタイプでこれを自動的に有効にします。
• 動的ファイルプルーニング: Delta Lake テーブルでの結合において、一致する行を含まない可能性のあるファイルをスキップします。MERGE、 UPDATE、および DELETE ステートメントで動的ファイルプルーニングを行うには、Photon対応のコンピュートが必要です。
• 低シャッフルMerge: 各ファイルの少数の行を更新または削除するMERGE操作を高速化します。低シャッフルMergeは、シャッフルなしで変更されていない行を処理し、既存のデータLayoutを保持します。
• 適応型クエリー実行: クエリーの実行中にデータの実際のサイズに基づいてクエリープランを再最適化します。これは、不正確な見積もりに起因する遅い結合戦略、多すぎる小さなタスク、および偏ったタスクを修正します。
• 予測 I/O: データスキャンを高速化し、Photon対応コンピュートでの更新、削除、およびマージ中に書き換えられるデータを削減します。
• コストベースのオプティマイザ：テーブルと列の統計を使用して効率的なクエリー計画を選択します。特に複数の結合を持つクエリーに有効です。コストベースのオプティマイザは統計に依存するため、統計を収集して最新の状態に保つようにしてください。
• 予測的最適化: Unity Catalog マネージドテーブルに対して自動的に OPTIMIZE、VACUUM、ANALYZE を実行するため、テーブルのメンテナンスをスケジュールする必要はありません。また、コストベースオプティマイザが使用する統計を最新の状態に保ちます。アカウントで有効になっているかどうかを確認するには、予測的最適化が有効になっているかどうかを確認するを参照してください。

構成する最適化

これらの最適化を利用するには、有効化、調整、またはテーブル構成の変更を行う必要があります。ワークロードでdefaultでカバーされない動作が必要な場合に使用します。

• アーカイブ サポート：クラウドのライフサイクル ポリシーによって古いテーブルファイルをアーカイブストレージ層に移動し、ストレージコストを削減する場合に使用します。アーカイブ サポートは、指定した期間より古いファイルを無視するようDatabricksに指示するため、最近のデータのみを読み取るクエリーがライフサイクルポリシーによって中断されることはありません。この機能はパブリック プレビュー段階です。

• 範囲結合：結合が間隔内のポイントまたは間隔のオーバーラップ条件を使用する場合に使用します。Databricks SQLは範囲結合を自動的に最適化します。他のコンピュートでは、結合ヒントまたはセッション構成で範囲結合を調整します。

• 分離レベルと書き込み競合: 同じテーブルに対する並列書き込みが競合する場合、またはワークロードでdefaultのWriteSerializable分離レベルよりも厳密な保証が必要な場合に使用します。シリアル化可能な分離は、並列書き込みのthroughputを低下させます。行レベルの同時実行性は、要件を満たすテーブルに対する並列書き込み間の多くの競合を自動的に解決します。

• 全文検索インデックス：クエリーで search 関数や isearch 関数を使用してテキスト列のサブ文字列や単語を検索する場合に使用します。インデックスは、一致する行が含まれていない可能性のあるファイルをスキップします。この機能はベータ版です。

注記

ブルームフィルタインデックスは、非推奨のデータスキッピング機能です。これらは書き込みのオーバーヘッドを増加させ、調整が困難です。テーブルにこれらのインデックスが含まれている場合は、ブルームフィルタインデックス（非推奨）を参照して、これらを置き換えて削除してください。

その他のパフォーマンス機能

• 高階関数は、一般的な Spark 演算子を持たない多くの操作に対して、組み込みの最適化されたパフォーマンスを提供します。高階関数は、ユーザー定義関数よりもパフォーマンスが高くなります。
• Databricksには、配列、構造体、JSON文字列などの複合データ型を操作するための組み込み演算子と特殊な構文があります。
• Spark SQLは、事前に構文解析せずにJSON文字列をクエリーします。
• 書き込みによって生成されるデータ ファイルのサイズを制御するには、「 データ ファイル サイズの制御」を参照してください。
• テーブルの設計とメンテナンスのガイダンスについては、 ベストプラクティス：Delta Lake」を参照してください。

低速または高コストなワークロードの診断

ワークロードが予想よりも遅い、または高コストで、理由がわからない場合は、構成を変更する前に Spark UIを使用してボトルネックを見つけてください。「Spark UIを使用したコストとパフォーマンスの問題の診断」を参照してください。