Delta Lake に対するデータのスキップ
データのスキップ情報は、Delta テーブルにデータを書き込むときに自動的に収集されます。 Delta Lake on Azure Databricks では、クエリ時にこの情報 (最小値と最大値、null カウント、ファイルあたりの合計レコード数など) を利用してクエリを迅速化します。
Note
Databricks Runtime 13.3 以上での Databricks では、Delta テーブル レイアウトにクラスタリングを使用することを推奨しています。 クラスタリングは Z オーダーと互換性がありません。 詳しくは、「Delta テーブルにリキッド クラスタリングを使用する」をご覧ください。
ZORDER ステートメントで使用される列の統計を収集しておく必要があります。 「Z オーダーとは」を参照してください。
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
Note
長い文字列は、統計の収集中に切り詰められます。 特に、列がクエリのフィルター処理に頻繁に使用されない場合は、統計コレクションから長い文字列の列を除外することを選択できます。
Z オーダーとは
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 オーダーを実行しても影響はなく、リソースの無駄になります。 データ スキップには、最小、最大、カウントなどの列ローカル統計が必要であることが、その理由となります。 特定の列での統計の収集を構成するには、スキーマ内の列の順序を変更するか、統計を収集する列の数を増やします。
注意
Z オーダーは "べき等ではありません" が、増分操作を意図したものです。 Z オーダーを複数回実行しても、実行にかかる時間の短縮が保証されるわけではありません。 ただし、Z オーダーが実行されたばかりのパーティションに新しいデータが追加されていない場合、そのパーティションでもう一度 Z オーダーを実行しても影響はありません。
Z オーダーの目的は、タプルの数 (必ずしもディスク上のデータ サイズではありません) に関して、均等にバランスの取れたデータ ファイルを生成することです。 ほとんどの場合、2 つの量は相関していますが、それが該当せず、最適化タスクの時間に偏りが生じる場合があります。
たとえば、"日付" で
ZORDER BYを行っていて、最新のレコードがすべて、過去のものよりはるかに幅広い (たとえば、配列や文字列値が長い) 場合、OPTIMIZEジョブのタスク期間と結果のファイル サイズが偏る可能性があります。 ただし、これはOPTIMIZEコマンド自体に限った問題であり、後続のクエリに悪影響を及ぼすことはありません。