データのスキップ

注記

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

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

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

統計列を指定する

Unity Catalog外部テーブルの場合、デフォルトではテーブルスキーマで定義されている最初の 32 列の統計が収集されます。Unity Catalogマネージドテーブルの場合、ファイルスキップ統計は予測的最適化を使用してインテリジェントに選択され、32 列の制限はありません。予測的最適化は自動的に実行ANALYZE 、統計を収集するためのコマンドです。 Databricks 、データのメンテナンスを簡素化し、ストレージコストを削減するために、すべてのUnity Catalogマネージドテーブルに対して予測的最適化を有効にすることをお勧めします。 Unity Catalogマネージドテーブルについては、「予測的最適化」を参照してください。

予測的最適化を使用していない場合は、次のいずれかのテーブル・プロパティを設定することにより、統計コレクションを 32 列に制限する動作を変更できます。

テーブルプロパティ	Databricks Runtime がサポートされています	説明
`dataSkippingNumIndexedCols`	サポートされているすべての Databricks Runtime バージョン	統計が収集される列の数を増減します。列の順序によって異なります。
`dataSkippingStatsColumns`	Databricks Runtime 13.3 LTS 以降	統計を収集する列名のリストを指定します。`dataSkippingNumIndexedCols`に取って代わります。

テーブルプロパティは、テーブルの作成時またはALTER TABLEステートメントで設定できます。表プロパティリファレンスを参照してください。次の例では、デフォルトの統計収集動作をオーバーライドして、名前付き列で統計収集を設定します。

SQL
-- For Delta tables
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')

-- For Iceberg tables
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')

これらのプロパティを更新しても、既存のデータの統計は自動的に再計算されません。むしろ、テーブルにデータを追加または更新するときの将来の統計収集の動作に影響します。現在の統計列のリストに含まれていない列では、統計は活用されません。

Databricks Runtime 14.3 LTS 以降では、テーブルプロパティを変更した場合、または統計の指定された列を変更した場合は、次のコマンドを使用して、テーブルの統計の再計算を手動でトリガーできます。

SQL
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

注記

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

Z-Orderingとは?

注記

Databricks 、すべての新しいテーブルにリキッドクラスタリングを使用することをお勧めします。 ZORDERリキッドクラスタリングと組み合わせて使用することはできません。「テーブルにリキッドクラスタリングを使用する」を参照してください。

Z-Ordering関連する情報を同じファイルセット内に共存させる手法です。 Databricks のデータスキッピングアルゴリズムは、この共局所性を自動的に使用します。この動作により、読み取る必要があるデータの量が削減されます。データをZ-Orderするには、 ZORDER BY句で順序付けする列を指定します。

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

統計列を指定する​

Z-Orderingとは?​

統計列を指定する

Z-Orderingとは?