クラスタリング戦略を設計して実装する

ディスク上でデータを物理的に整理する方法を最適化すると、 クエリのパフォーマンス と ストレージの効率に直接影響します。 Delta Lake テーブルのクラスタリング戦略を設計するときは、クエリ エンジンが関連データを検索して取得する方法を決定します。 適切なアプローチにより、クエリ中にスキャンされるデータの量を大幅に減らし、応答時間とコンピューティング コストの両方を削減できます。

Azure Databricks には、データ編成のためのいくつかの補完的な手法が用意されています。 液体クラスタリング、Z オーダー、または削除ベクトルを適用するタイミングを理解することは、パフォーマンス、メンテナンス作業、および既存のテーブルとの互換性のバランスを取る決定を下すのに役立ちます。

データスキップの基礎を理解する

特定のクラスタリング手法を調べる前に、それらがすべて活用する基になるメカニズム ( データ スキップ) を理解することが重要です。 Delta Lake は、最小値と最大値、null カウント、各列のレコード数など、各データ ファイルの統計情報を自動的に収集します。 フィルター条件を使用してクエリを実行すると、クエリ エンジンは最初にこれらの統計をチェックし、一致するレコードを含めることができない可能性があるファイルをスキップします。

たとえば、2026 年 1 月の売上データに対してクエリを実行し、特定のファイルの統計情報に 2026 年 3 月のレコードのみが含まれていることが示されている場合、エンジンはその内容を読み取らずにそのファイルを完全にスキップします。 この最適化は自動的に行われますが、その有効性は、データがどれだけ適切に編成されているかによって異なります。

関連するレコードが同じファイルに まとめて格納されると、 データのスキップが強力になります。 各月のレコードがすべてのファイルにランダムに分散されている場合、各ファイルには毎月のレコードが含まれているため、エンジンはファイルをスキップできません。 この問題を正確に解決するためのクラスタリング手法が存在します。

新しいテーブルの液体クラスタリングを実装する

Liquid クラスタリングは、新しい Delta Lake テーブルでデータを整理するための 推奨されるアプローチ であり、Unity カタログ (Databricks Runtime 16.4 LTS 以降) のマネージド Apache Iceberg テーブルのパブリック プレビューでも使用できます。 従来のパーティション分割とは異なり、液体クラスタリングを使用すると、 既存のデータを書き換えることなくクラスタリング戦略を変更できます。 この柔軟性は、クエリ パターンが進化する場合や、どの列が最も頻繁にフィルター処理されるかが不明な場合に重要です。

液体クラスタリングを有効にするには、テーブルの作成時に CLUSTER BY 句を使用します。

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

最大 4 つのクラスタリング キーを指定できます。 クエリ フィルターに頻繁に表示される列を選択します。 液体クラスタリングは指定されたすべてのキーに対して同時に最適化されるため、クラスタリング キーの順序は適切な列を選択するよりも重要ではありません。

クラスター化テーブルを作成した後、 OPTIMIZE コマンドを実行して、データにクラスタリングを適用します。

OPTIMIZE sales.transactions;

液体クラスタリングは 増分です。 各 OPTIMIZE は、再編成が必要なデータのみをクラスターで実行し、定期的なメンテナンスを効率的にします。 Databricks では、頻繁に挿入または更新が行われるテーブルに対して、 OPTIMIZE ジョブを 1 時間または 2 時間ごとにスケジュールすることをお勧めします。

必要に応じてクラスタリング キーを変更する

パーティション分割よりも液体クラスタリングの大きな利点の 1 つは、クラスタリング戦略を変更できることです。 クエリ パターンが変更された場合は、 ALTER TABLE ステートメントを使用してクラスタリング キーを更新します。

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

後続の OPTIMIZE 操作では、新しいクラスタリング アプローチが使用されます。 以前に書き込まれたデータは自動的に書き換えられません。 既存のすべてのデータに新しいクラスタリングを適用するには、次のコマンドを実行します。

OPTIMIZE sales.transactions FULL;

自動クラスタリング キーの選択を有効にする

Azure Databricks では、実際のクエリ パターンに基づいてクラスタリング キーをインテリジェントに選択できます。 自動液体クラスタリングは、ワークロード履歴を分析し、最大のデータ スキップの利点を提供する列を選択します。

CREATE TABLE sales.orders CLUSTER BY AUTO;

既存のテーブルで自動クラスタリングを有効にすることができます。

ALTER TABLE sales.transactions CLUSTER BY AUTO;

自動液体クラスタリングでは、予測最適化を有効にする必要があります。 Azure Databricks は、異なるクラスタリング キーによってパフォーマンスが向上するかどうかを定期的に評価し、それに応じて戦略を調整します。

Z オーダーから液体クラスタリングへの移行

Z オーダーは、同じファイル内の関連情報を併置するためにデータを整理する従来の手法です。 新しいテーブルにはリキッド クラスタリングをお勧めしますが、Z オーダーを使用する既存のテーブルがあり、両方の方法を理解する必要があります。

Z オーダリングでは、OPTIMIZE コマンドをZORDER BY 句とともに使用します。

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

Z オーダーは、いくつかの重要な点で液体クラスタリングとは異なります。

Z 順テーブルを継承する場合、2 つのオプションがあります。 一貫性のために Z オーダーを引き続き使用するか、柔軟性を向上させるために液体クラスタリングに移行します。 移行するには、まず、既存のパーティション分割されていないテーブルで液体クラスタリングを有効にします。

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

次に、完全な最適化を実行して、既存のすべてのデータを再構成します。

OPTIMIZE sales.legacy_transactions FULL;

効率的な更新のために削除ベクトルを管理する

削除ベクトルは、変更または削除されたレコードを Delta Lake が処理する方法という、データ編成のさまざまな側面に対応します。 既定では、Parquet ファイル内の 1 つの行を更新または削除する場合、Delta Lake は ファイル全体を書き換える必要があります。 頻繁に変更が行われるテーブルの場合、オーバーヘッドが大きくなります。

削除ベクトルを有効にすると、Delta Lake は、Parquet ファイルを直ちに書き換えるのではなく、変更された行を別のメタデータ ファイルで 削除済みとしてマーク します。 後続の読み取りでは、これらの削除が即座に適用され、元のファイルと削除ベクターが組み合わせて正確な結果が返されます。

削除ベクトルは、Databricks Runtime 14.1 以降で作成された新しいテーブルに対して既定で有効になっています。 既存のテーブルで明示的に有効にすることができます。

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

削除ベクトルは、データ ファイルが次の書き換え中に物理的に適用されます。

• OPTIMIZE コマンド
• 自動圧縮トリガー
• REORG TABLE ... APPLY (PURGE)操作

削除されたデータが 物理的に削除されるようにする必要があるコンプライアンス シナリオの場合は、 REORG 操作を実行し、その後に次の VACUUMを実行します。

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

削除ベクトルを使用すると 、行レベルのコンカレンシーも可能になり、複数の同時実行トランザクションで同じテーブル内の異なる行を競合なしで変更できます。 この機能は、更新プログラムの量が多いテーブルに特に価値があります。