Delta Lake のデータ スキップ

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

注

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

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

Delta統計列の指定

既定では、Delta Lake はテーブル スキーマで定義されている最初の 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 とは？

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コマンド自体の問題にすぎません。後続のクエリに悪影響を与えることはありません。