Delta Lake に対するデータのスキップ
Note
Databricks Runtime 13.3 以上において、Databricks では Delta テーブル レイアウトにリキッド クラスタリングを使用することが推奨されています。 クラスタリングは Z オーダーと互換性がありません。 詳しくは、「Delta テーブルにリキッド クラスタリングを使用する」をご覧ください。
データのスキップ情報は、Delta テーブルにデータを書き込むときに自動的に収集されます。 Delta Lake on Azure Databricks では、クエリ時にこの情報 (最小値と最大値、null カウント、ファイルあたりの合計レコード数など) を利用してクエリを迅速化します。
ZORDER ステートメントで使用される列の統計を収集しておく必要があります。 「Z オーダーとは」を参照してください。
Delta 統計の列を指定する
既定では、Delta Lake はテーブル スキーマで定義されている最初の 32 列の統計を収集します。 予測最適化が有効になっている場合、ファイルスキップ統計はインテリジェントに選択され、最初の 32 列に限定されません。 予測最適化は、統計を収集するためのコマンド ANALYZE Unity カタログのマネージド テーブルで自動的に実行されます。 Databricks では、データのメンテナンスを簡素化し、ストレージ コストを削減するために、すべての Unity Catalog マネージド テーブルに対して予測最適化を有効にすることをお勧めします。 「Unity Catalog 管理テーブルの予測最適化」を参照してください。
重要
ANALYZEを使用した予測最適化はパブリック プレビュー段階です。 これには、書き込み中のインテリジェントな統計収集が含まれます。 このフォーム 使用して パブリック プレビューにサインアップします。
予測最適化を使用していない場合は、次の表のプロパティのいずれかを設定することで、統計コレクションを 32 列に制限する動作を変更できます。
| テーブルのプロパティ | サポートされている Databricks Runtime | 説明 |
|---|---|---|
delta.dataSkippingNumIndexedCols |
すべてのサポートされている Databricks Runtime バージョン | Delta が統計を収集する列の数を増減します。 列の順序によって異なります。 |
delta.dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS 以降 | Delta Lake が統計を収集する列名のリストを指定します。 dataSkippingNumIndexedCols に置き換えられます。 |
テーブルのプロパティは、テーブルの作成時または ALTER TABLE ステートメントを使用して設定することができます。 「Delta テーブル プロパティのリファレンス」を参照してください。
これらのプロパティを更新しても、既存のデータの統計が自動的に再計算されることはありません。 むしろ、テーブル内のデータを追加または更新するときの今後の統計収集の動作に影響します。 Delta Lake では、統計列の現在のリストに含まれていない列の統計は活用されません。
Databricks Runtime 14.3 LTS 以降では、テーブルのプロパティを変更した場合、または統計の指定された列を変更した場合は、次のコマンドを使用して Delta テーブルの統計の再計算を手動でトリガーできます。
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
Note
長い文字列は、統計の収集中に切り詰められます。 特に、列がクエリのフィルター処理に頻繁に使用されない場合は、統計コレクションから長い文字列の列を除外することを選択できます。
Z オーダーとは
Note
Databricks では、すべての新しい Delta テーブルに対して、リキッド クラスタリングを使用することをお勧めします。 ZORDER をリキッド クラスタリングと組み合わせて使用することはできません。
Z オーダーは、関連情報を同じファイル セットに併置する手法です。 この併置は、Delta Lake on Azure Databricks のデータのスキップ アルゴリズムで自動的に使用されます。 この動作により、Delta Lake on Azure Databricks が読み取る必要があるデータの量が大幅に削減されます。 Z オーダー データには、順序付けする列を ZORDER BY 句で指定します。
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
クエリ述語で列が一般的に使用されている場合に、その列のカーディナリティが高い (つまり、個別の値が多数ある) 場合は、ZORDER BY を使用します。
ZORDER BY には、複数の列をコンマ区切りのリストとして指定できます。 ただし、併置の有効性は、列を追加するごとに低下します。 統計が収集されない列で Z オーダーを実行しても影響はなく、リソースの無駄になります。 データ スキップには、最小、最大、カウントなどの列ローカル統計が必要であることが、その理由となります。 特定の列での統計の収集を構成するには、スキーマ内の列の順序を変更するか、統計を収集する列の数を増やします。
注意
Z オーダーは "べき等ではありません" が、増分操作を意図したものです。 Z オーダーを複数回実行しても、実行にかかる時間の短縮が保証されるわけではありません。 ただし、Z オーダーが実行されたばかりのパーティションに新しいデータが追加されていない場合、そのパーティションでもう一度 Z オーダーを実行しても影響はありません。
Z オーダーの目的は、タプルの数 (必ずしもディスク上のデータ サイズではありません) に関して、均等にバランスの取れたデータ ファイルを生成することです。 ほとんどの場合、2 つの量は相関していますが、それが該当せず、最適化タスクの時間に偏りが生じる場合があります。
たとえば、"日付" で
ZORDER BYを行っていて、最新のレコードがすべて、過去のものよりはるかに幅広い (たとえば、配列や文字列値が長い) 場合、OPTIMIZEジョブのタスク期間と結果のファイル サイズが偏る可能性があります。 ただし、これはOPTIMIZEコマンド自体に限った問題であり、後続のクエリに悪影響を及ぼすことはありません。