注
Databricks Runtime 13.3 以降では、テーブル レイアウトに液体クラスタリングを使用することをお勧めします。 クラスタリングは Z オーダーと互換性がありません。 表に液体クラスタリングを使用するを参照してください。
Delta Lake またはマネージド Apache Iceberg テーブルにデータを書き込むと、データスキッピング統計が自動的に収集されます。 Azure Databricksでは、クエリ時にファイルごとの統計 (最小値と最大値、null カウント、および合計レコード) を使用して、無関係なファイルをスキップし、クエリを高速化します。
ZORDERステートメントで使用される列の統計を収集する必要があります。 「Z オーダーとは」を参照してください。
統計列を指定する
Unity カタログ 外部テーブルの場合、既定では、テーブル スキーマで定義されている最初の 32 列で統計が収集されます。 Unity Catalog 管理のテーブルでは、予測最適化は固定された列ではなく、クエリフィルターで最も頻繁に使われる列のファイルスキップ統計を収集するため、これらのテーブルには32列の制限はありません。 予測最適化は、統計を収集するためのコマンド ANALYZE自動的に実行されます。 Databricks では、データのメンテナンスを簡素化し、ストレージ コストを削減するために、すべての Unity Catalog マネージド テーブルに対して予測最適化を有効にすることをお勧めします。 「Unity Catalog 管理テーブルの予測最適化」を参照してください。
予測最適化を使用していない場合は、次のいずれかのテーブル プロパティを設定することで、統計コレクションを 32 列に制限する動作を変更できます。
| テーブルのプロパティ | サポート対象の Databricks Runtime | Description |
|---|---|---|
dataSkippingNumIndexedCols |
サポートされているすべての Databricks ランタイム バージョン | 統計が収集される列の数を増減します。 列の順序によって異なります。 |
dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS 以降 | 統計を収集する列名のリストを指定します。
dataSkippingNumIndexedCols に置き換えられます。 |
テーブルのプロパティは、テーブルの作成時に設定することも、 ALTER 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 オーダーとは
注
Databricks では、すべての新しいテーブルに対して液体クラスタリングを使用することをお勧めします。 液体クラスタリングと組み合わせて ZORDER を使用することはできません。
表に液体クラスタリングを使用するを参照してください。
Z オーダーは、関連情報を同じファイル セットに併置する 手法 です。 Azure Databricks のデータスキップ アルゴリズムは、このコローカリティを自動的に利用します。 この動作により、読み取る必要があるデータの量が減ります。 Z オーダー データの場合は、 ZORDER BY 句で並べ替える列を指定します。
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
クエリ述語で列が一般的に使用され、その列のカーディナリティが高い (つまり、多数の個別の値) 場合は、 ZORDER BYを使用します。
ZORDER BYには複数の列をコンマ区切りリストとして指定できます。 ただし、余分な列ごとに有効性が低下します。
Databricks では、統計が収集されていない列に対して ZORDER BY を使用しないことをお勧めします。これは無効であり、不要なコンピューティング リソースを使用するためです。 データのスキップには、min、max、count などの列ローカル統計が必要です。 スキーマの列を並べ替えることで、特定の列の統計収集を構成したり、統計を収集する列の数を増やしたりできます。
注
Z オーダーは べき等ではありません が、増分操作を意図したものです。 Z オーダリングにかかる時間は、複数回実行しても必ずしも短くなるとは限りません。 ただし、Z オーダーのパーティションに新しいデータが追加されなかった場合、そのパーティションの別の Z 順序は影響しません。
Z オーダーは、タプルの数に関して均等にバランスの取れたデータ ファイルを生成することを目的としていますが、ストレージ内のデータ サイズとは限りません。 ファイル サイズとタプル数には相関がありますが、相関しない場合もあり、その結果、optimize タスクの実行時間に偏りが生じることがあります。
たとえば、
ZORDER BY日付 を設定し、最新のレコードがすべて過去のレコードよりもはるかに広い (長い配列や文字列値など) 場合、ジョブのタスク期間と結果のファイル サイズOPTIMIZE偏っている可能性があります。 ただし、これはOPTIMIZEコマンド自体の問題にすぎません。後続のクエリに悪影響を及ぼすことはありません。