メインコンテンツまでスキップ

Delta Lake のデータのスキップ

注記

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

Data skiping 情報 は、 Delta テーブルにデータを書き込むときに自動的に収集されます。 Databricks 上の Delta Lake は、クエリ時にこの情報 (最小値と最大値、null カウント、ファイルごとの合計レコード数) を利用して、クエリを高速化します。

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

Delta 統計列の指定​

デフォルトでは、Delta Lake はテーブルスキーマで定義された最初の 32 列の統計を収集します。 予測的最適化が有効な場合、ファイルスキップ統計はインテリジェントに選択され、最初の 32 列に限定されません。 予測的最適化 統計を収集するためのコマンドである ANALYZE を Unity Catalog マネージドテーブルで自動的に実行します。 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 テーブル プロパティ リファレンス」を参照してください。次の例では、デフォルト stats コレクションの動作をオーバーライドして、名前付き列に stats コレクションを設定します。

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

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

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

SQL
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
注記

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

Z-Orderingとは?​

注記

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

Z-Ordering は、関連する情報を同じファイルセットに併置する 手法 です。 このコローカリティは、Databricks データスキップ アルゴリズムで Delta Lake によって自動的に使用されます。 この動作により、Databricks 上の Delta Lake が読み取る必要のあるデータ量が大幅に減少します。 データを 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コマンド自体の問題にすぎません。後続のクエリに悪影響を与えることはありません。

に最終更新