Delta Lake のデータスキップ

注

Databricks Runtime 13.3 以降では、 Databricks Deltaテーブルレイアウトにリキッドクラスタリングを使用することを推奨しています。クラスタリングはZ-Orderingと互換性がありません。 Deltaテーブルについては、「リキッドクラスタリングを使用する」を参照してください。

データスキップ情報は、Delta テーブルにデータを書き込むときに自動的に収集されます。 Delta Lake on Databricks は、クエリ時にこの情報 (最小値と最大値、null 数、ファイルあたりの合計レコード数) を利用して、クエリを高速化します。

ZORDER ステートメントで使用される列の統計を収集しておく必要があります。「Z-Orderingとは」を参照してください。

Delta 統計列の指定

デフォルトでは、Delta Lake はテーブルスキーマで定義された最初の 32 列の統計を収集します。予測的最適化が有効な場合、ファイルスキップ統計はインテリジェントに選択され、最初の 32 列に限定されません。予測的最適化統計を収集するためのコマンドである ANALYZE を Unity Catalog マネージドテーブルで自動的に実行します。 Databricks では、すべての Unity Catalog マネージドテーブルに対して予測的最適化を有効にして、データのメンテナンスを簡素化し、ストレージコストを削減することをお勧めします。予測的最適化 for 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

注

長い文字列は、統計収集中に切り捨てられます。長い文字列列を統計収集から除外することを選択できます (特に、列がクエリのフィルター処理に頻繁に使用されない場合)。

Z-ordering とは？

注

Databricks 、すべての新しいDeltaテーブルにリキッドクラスタを使用することを推奨しています。 ZORDERリキッドクラスタリングと組み合わせて使用することはできません。

Z-order は、関連する情報を同じファイルセットに同じ場所に配置する手法です。この共局性は、Delta Lake on Databricksデータスキップアルゴリズムによって自動的に使用されます。この動作により、Databricks上のDelta Lakeが読み取る必要があるデータの量が大幅に減少します。データを Z-order 並べるには、ZORDER BY句で順序付けする列を指定します：

OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

列がクエリ述語で一般的に使用されることが予想され、その列のカーディナリティが高い（つまり、多数の個別の値がある）場合は、ZORDER BYを使用します。

ZORDER BYにはカンマ区切りで複数の列を指定できます。しかし、列が増えるごとにローカリティの効果は低下します。統計が収集されていない列の Z-ordering は効果がなく、リソースの無駄遣いです。データをスキップするには、min、max、countといった列ローカルの統計が必要だからです。スキーマの列の順序を変更することで、特定の列に対する統計情報収集を設定したり、統計情報を収集する列の数を増やしたりすることができます。

注

Z-ordering はべき等ではありませんが、インクリメンタル演算を目指しています。Z-ordering 化にかかる時間は、複数回の実行で短縮されることは保証されません。ただし、Z-ordering のみのパーティションに新しいデータが追加されなかった場合、そのパーティションの別のZ-ordered は効果がありません。
Z-ordering は、タプルの数に関して均等なバランスのデータファイルを生成することを目的としていますが、必ずしもディスク上のデータサイズに関してはそうではありません。ほとんどの場合、2つの測定値は相関関係にありますが、そうでない状況もあり、タスク時間の最適化に偏りが生じます。

例えば、ZORDER BYの日付で、最新のレコードが過去のレコードよりはるかに広い（例えば、より長い配列や文字列値）場合、OPTIMIZEジョブのタスク時間が歪み、結果としてファイルサイズも歪むことが予想されます。ただし、これはOPTIMIZEコマンド自体の問題にすぎません。後続のクエリに悪影響を与えることはありません。