データのスキップ
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 はサポートされています | 説明 |
|---|---|---|
| サポートされているすべての Databricks Runtime バージョン | 統計情報が収集される列の数を増減します。列の順序によって異なります。 |
| Databricks Runtime 13.3 LTS以降 | 統計情報が収集される列名のリストを指定します。 |
テーブルのプロパティは、テーブルの作成時に設定するか、 ALTER TABLE ステートメントで設定できます。「テーブルプロパティリファレンス」を参照してください。次の例では、デフォルト stats コレクションの動作をオーバーライドして、名前付き列に stats コレクションを設定します。
- Delta Lake table
- Iceberg table
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')
これらのプロパティを更新しても、既存のデータに関する統計情報は自動的に再計算されません。むしろ、テーブル内のデータを追加または更新する際の今後の統計収集の挙動に影響を与えます。現在の統計列リストに含まれていない列には、統計情報は活用されません。
Databricks Runtime 14.3 LTS以降で、テーブルプロパティを変更したか、統計のために指定された列を変更した場合、テーブルの統計の再計算を次のコマンドを使用して手動でトリガーできます。
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
長い文字列は統計情報収集時に切り捨てられます。統計収集から長い文字列の列を除外することを選択できます。特に、列がクエリのフィルター処理に頻繁に使用されない場合は。
Z-ordering とは?
Databricks では、すべての新しいテーブルにリキッドクラスタリングを使用することをお勧めします。ZORDERをリキッドクラスタリングと組み合わせて使用することはできません。「テーブルにリキッドクラスタリングを使用する」を参照してください。
Z-ordering は、関連する情報を同じファイルセットに同じ場所に配置する手法です。Databricks データスキップアルゴリズムは、この共局性を自動的に使用します。この動作は、読み取る必要があるデータの量を削減します。データを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コマンド自体の問題にすぎません。後続のクエリに悪影響を与えることはありません。