注
Databricks Runtime 13.3 以降では、Databricks では、Delta テーブル レイアウトに液体クラスタリングを使用することをお勧めします。 クラスタリングは Z オーダーと互換性がありません。 表に液体クラスタリングを使用するを参照してください。
データスキップ情報は、Delta テーブルにデータを書き込むと自動的に収集されます。 Delta Lake on Azure Databricks では、クエリ時にこの情報 (最小値と最大値、ファイルあたりの null カウント、および合計レコード数) を利用して、より高速なクエリを提供します。
ZORDERステートメントで使用される列の統計を収集する必要があります。 「Z オーダーとは」を参照してください。
差分統計列の指定
既定では、Delta Lake はテーブル スキーマで定義されている最初の 32 列の統計を収集します。 予測最適化が有効になっている場合、ファイルスキップ統計はインテリジェントに選択され、最初の 32 列に限定されません。 予測最適化は、統計を収集するためのコマンド ANALYZE Unity カタログのマネージド テーブルで自動的に実行されます。 Databricks では、データのメンテナンスを簡素化し、ストレージ コストを削減するために、すべての Unity Catalog マネージド テーブルに対して予測最適化を有効にすることをお勧めします。 「Unity Catalog 管理テーブルの予測最適化」を参照してください。
予測最適化を使用していない場合は、次の表のプロパティのいずれかを設定することで、統計コレクションを 32 列に制限する動作を変更できます。
| テーブルのプロパティ | サポートされている Databricks Runtime | 説明 |
|---|---|---|
delta.dataSkippingNumIndexedCols |
すべてのサポートされている Databricks Runtime バージョン | Delta が統計を収集する列の数を増減します。 列の順序によって異なります。 |
delta.dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS 以降 | Delta Lake が統計を収集する列名の一覧を指定します。
dataSkippingNumIndexedCols に置き換えられます。 |
テーブルのプロパティは、テーブルの作成時に設定することも、 ALTER TABLE ステートメントを使用して設定することもできます。 「Delta テーブル プロパティのリファレンス」を参照してください。 次の例では、既定の統計コレクションの動作をオーバーライドして、名前付き列に統計コレクションを設定します。
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')
これらのプロパティを更新しても、既存のデータの統計が自動的に再計算されることはありません。 代わりに、テーブル内のデータを追加または更新するときの将来の統計収集の動作に影響します。 Delta Lake では、統計列の現在のリストに含まれていない列の統計は利用されません。
Databricks Runtime 14.3 LTS 以降では、テーブルのプロパティを変更した場合、または統計の指定された列を変更した場合は、次のコマンドを使用して Delta テーブルの統計の再計算を手動でトリガーできます。
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
注
長い文字列は、統計の収集中に切り詰められます。 列がクエリのフィルター処理に頻繁に使用されない場合は特に、長い文字列列を統計コレクションから除外することもできます。
Z オーダーとは
注
Databricks では、すべての新しい Delta テーブルに対してリキッド クラスタリングの使用をお勧めしています。
ZORDER をリキッド クラスタリングと組み合わせて使用することはできません。
表に液体クラスタリングを使用するを参照してください。
Z オーダーは、関連情報を同じファイル セットに併置する 手法 です。 この併置は、Delta Lake on Azure Databricks のデータのスキップ アルゴリズムで自動的に使用されます。 この動作により、Delta Lake on Azure Databricks が読み取る必要があるデータの量が大幅に削減されます。 データを Z オーダーするには、 ZORDER BY 句で並べ替える列を指定します。
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
クエリ述語で列が一般的に使用され、その列のカーディナリティが高い (つまり、多数の個別の値) 場合は、 ZORDER BYを使用します。
ZORDER BYには複数の列をコンマ区切りリストとして指定できます。 ただし、局所性の有効性は、追加の列ごとに低下します。 統計が収集されていない列の Z オーダーは効果がなく、リソースの無駄になります。 これは、データのスキップには、min、max、count などの列ローカル統計が必要であるためです。 スキーマの列を並べ替えることで、特定の列の統計収集を構成したり、統計を収集する列の数を増やしたりできます。
注
Z オーダーは "べき等ではありません" が、増分操作を意図したものです。 Z オーダーを複数回実行しても、実行にかかる時間の短縮が保証されるわけではありません。 ただし、Z オーダーのパーティションに新しいデータが追加されなかった場合、そのパーティションの別の Z 順序は影響を受けなくなります。
Z オーダーの目的は、タプルの数 (必ずしもディスク上のデータ サイズではありません) に関して、均等にバランスの取れたデータ ファイルを生成することです。 ほとんどの場合、2 つの量は相関していますが、それが該当せず、最適化タスクの時間に偏りが生じる場合があります。
たとえば、
ZORDER BY日付 を設定し、最新のレコードがすべて過去のレコードよりもはるかに広い (たとえば、配列や文字列値が長い) 場合、OPTIMIZEジョブのタスク期間と結果のファイル サイズが偏ることが予想されます。 ただし、これはOPTIMIZEコマンド自体に限った問題であり、後続のクエリに悪影響を及ぼすことはありません。