デルタ テーブルに液体クラスタリングを適用する

液体クラスタリングは、Microsoft Fabricの差分テーブルの柔軟なデータ レイアウト戦略です。 これは、静的な Hive スタイルのパーティション分割と手動の Z オーダー メンテナンスを、宣言型の変更に対応したクラスタリングに置き換えます。 クラスター化する列を定義し、Fabric Spark ランタイムが物理データ レイアウトを自動的に処理します。

この記事を使用して、次の操作を行います。

• 液体クラスタリングのしくみと、それを使用するタイミングについて説明します。
• 液体クラスタリングとパーティション分割と Z オーダーを比較します。
• テーブルにクラスタリングを構成します。
• インクリメンタル リキッド クラスタリングについて (ランタイム 2.0 以降)。
• セッション構成を使用してクラスタリングの動作を調整します。

液体クラスタリングとは

Liquid クラスタリングでは、デルタ テーブル ファイル内のデータが整理され、クラスタリング列に類似した値を持つ行が併置されます。 レイアウトにより、クエリの実行中に拡張 ファイルのスキップ が可能になります。クエリがクラスタリング列をフィルター処理すると、エンジンは値範囲が述語と一致するファイルのみを読み取り、残りはスキップします。

パーティション分割とは異なり、液体クラスタリング:

• 列の値ごとに物理ディレクトリ構造を作成しません。
• テーブル作成時にクラスタリング列を選択する必要はありません (後で変更できます)。
• 数千の小さなパーティションから小さなファイルの潜在的な問題を作成することなく、カーディナリティの高い列を処理します。
• 書き込み時ではなく、 OPTIMIZE中にレイアウトの最適化を適用します。

パーティション分割と Z オーダーに対する利点

液体クラスタリングは、進化するデータ パターンの柔軟性、メンテナンス、および処理の観点から、Hive スタイルのパーティション分割と Z オーダーの両方に比べて大きな利点を提供します。

Hive スタイルのパーティション分割と比較した場合

Z オーダーと比較

液体クラスタリングでは、単一列レイアウトに Z オーダーを使用し、2 つ以上の列に対してヒルベルト曲線を使用します。これは、多次元クラスタリングに Z オーダー曲線のみを適用する Z オーダーの改善です。 Liquid クラスタリングでは、両方のアルゴリズムがメタデータ対応の増分フレームワークでラップされ、継続的なメンテナンス コストが削減されます。

液体クラスター化テーブルを作成する

テーブル作成時に CLUSTER BY 句を使用してクラスタリング列を定義します。

-- Create a new clustered table
CREATE TABLE dbo.sales (
    order_id BIGINT,
    order_date DATE,
    region STRING,
    amount DECIMAL(10,2)
) CLUSTER BY (order_date, region);

-- Create from query results
CREATE TABLE dbo.sales_clustered
CLUSTER BY (order_date, region)
AS SELECT * FROM raw_sales;

-- Enable on existing table
ALTER TABLE dbo.sales_txn CLUSTER BY (order_date, region);

from delta.tables import DeltaTable

DeltaTable.create(spark) \
    .tableName("dbo.sales") \
    .addColumn("order_id", "BIGINT") \
    .addColumn("order_date", "DATE") \
    .addColumn("region", "STRING") \
    .addColumn("amount", "DECIMAL(10,2)") \
    .clusterBy("order_date", "region") \
    .execute()

import io.delta.tables.DeltaTable

DeltaTable.create(spark)
    .tableName("dbo.sales")
    .addColumn("order_id", "BIGINT")
    .addColumn("order_date", "DATE")
    .addColumn("region", "STRING")
    .addColumn("amount", "DECIMAL(10,2)")
    .clusterBy("order_date", "region")
    .execute()

クラスタリング列を変更する

パーティション分割とは異なり、データを書き換えることなく、クラスタリング列をいつでも変更できます。

-- Change clustering columns
ALTER TABLE sales CLUSTER BY (region, product_category);

-- Remove clustering (table becomes unclustered)
ALTER TABLE sales CLUSTER BY NONE;

クラスタリング列を変更した後、新しいレイアウトは次の OPTIMIZE 実行に適用されます。 既存のファイルは、再クラスター化されるまで以前のレイアウトを保持します。

OPTIMIZE を使用してクラスタリングを適用する

クラスタリングは、 OPTIMIZE コマンド中に適用されます。 クラスタリング定義はテーブル メタデータに格納されるため、 OPTIMIZE ステートメントで列を指定する必要はありません。

-- Cluster the table using the defined clustering columns
OPTIMIZE sales;

-- Recluster partial Z-Cubes and Z-Cubes with different clustering keys or clustering providers
OPTIMIZE sales FULL;

クラスタリング キーを変更し、現在のクラスタリング戦略に準拠していない Z キューブを再構築する場合は、 OPTIMIZE FULL を使用します。 Z キューブは、同じクラスタリング列を共有するファイルをグループ化するために液体クラスタリングが使用する論理ユニットです。 クラスター キーが変更されるか、データの量が 100 GB を超えるまで、データは 1 つの Z キューブにクラスター化されます。

液体クラスタリングのしくみ

液体クラスター化テーブルで OPTIMIZE を実行すると、次の処理が行われます。

1. ファイルの選択: エンジンは、クラスタリングが必要なファイルを選択します。
   • Runtime 2.0+（増分クラスタリング戦略）では、クラスタリングされていない、不健全な、小さいサイズの、または削除ベクターファイルのみが選択されます。
   • ランタイム 1.3 では、既にクラスター化されているかどうかに関係なく、100 GB 未満のすべての Z キューブ内のすべてのファイルが選択されます。
2. ビンパッキング: 選択したファイルは、最適な出力ファイルサイズをターゲットとするビンにグループ化されます。
3. 再分割: 各ビン内のデータは、スペース充填曲線 (複数列の場合はヒルベルト曲線、単一列の場合は Z オーダー) を使用して再分割されます。
4. ファイルの書き込み: 再パーティション分割されたデータは、クラスタリング列の値範囲が狭い新しいファイルとして書き込まれます。
5. メタデータの更新: Delta ログには、ファイルの置換が記録され、クラスタリング メタデータを使用して新しいファイルにタグが付けられます。

結果として、クラスタリング列で重複しない (または重複しない) 値範囲を持つファイルが生成され、エンジンはクエリ述語と一致しないファイルをスキップできます。

増分型流動クラスタリング

Fabric ランタイム 2.0 (デルタ 4.1) 以降では、液体クラスタリングでは既定で incremental クラスタリング戦略が使用されます。 増分戦略は、標準のクラスタリング動作よりも大幅に改善されています。

インクリメンタル クラスタリング戦略が重要な理由

標準クラスタリング アルゴリズムは、既にクラスター化されているかどうかに関係なく、実行ごとに Z キューブ内OPTIMIZEファイル (最大 100 GB) を書き換えます。 小さな追加を受け取るテーブルの場合、クラスタリング コストは、新しいデータの量ではなく、テーブル サイズに比例して増加します。

増分モードでは、実際にクラスタリングが必要なファイルのみを選択することで、完全書き換えの問題を解決します。

• クラスター化されていないファイル: クラスタリング メタデータなしで新しく書き込まれたデータ
• 小さいファイル: ターゲット ファイル サイズのしきい値を下回るファイル
• 削除ベクトルを含むファイル: クリーンアップしきい値を超える累積削除を含むファイル

既に適切にクラスター化された適切なサイズのファイルは、完全にスキップされます。

自動再クラスタリング

増分液体クラスタリングには、自動 再クラスター化と呼ばれる自動オーバーラップ検出が含まれています。これは、時間の経過と同時にクラスタリングの品質を維持します。 新しいデータが到着すると、ファイル値の範囲間に重複が生じ、データのスキップ効果が低下する可能性があります。 自動再クラスター化は、ファイル間で重複する値範囲を検出し、影響を受けるファイルのみを選択的に再クラスター化します。

自動再クラスター化は、クラスターに新しいデータまたは変更されたデータがある場合は常に、 OPTIMIZE の一部として自動的に実行されます。 手動による介入やスケジュールされた完全な再クラスターは必要ありません。 増分クラスタリング戦略では、データの進化に伴い、ほぼ最適なクラスタリング品質が維持されます。

完全書き換え動作に戻す

増分クラスタリング戦略を無効にし、完全書き換え動作を使用する必要がある場合は、次の構成を設定します。

SET spark.microsoft.delta.optimize.clustering.strategy.incremental = FALSE;

OPTIMIZE sales;

spark.conf.set('spark.microsoft.delta.optimize.clustering.strategy.incremental', False)

spark.conf.set("spark.microsoft.delta.optimize.clustering.strategy.incremental", "false")

または、セッション設定を変更せずに、1 回限り完全な再クラスターに対して OPTIMIZE FULL を使用します。

OPTIMIZE sales FULL;

構成参照

次のセッション構成は、Fabric Runtime 2.0 以降での液体クラスタリング動作を制御します。

増分クラスタリング

自動再クラスター調整

これらの構成は、自動再クラスター化の感度とスコープを制御します。 既定値は、ほとんどのワークロードに適しています。 クラスタリング品質と書き込み増幅のトレードオフを変更する必要がある場合にのみ調整します。

クラスタリング列の選択

最適な結果を得るには、最も一般的なクエリ フィルター パターンに基づいてクラスタリング列を選択します。

• 列数が増えるほど、空間充填曲線による列単位のファイルスキップ効果が薄れ、データのクラスタリングにかかる時間が長くなります。
• 列のカーディナリティを考慮してください。 カーディナリティの低い列では、個別の値範囲が少なくなり、カーディナリティの高いクラスタリング キーと組み合わせた場合のファイル スキップの利点が軽減されます。
• 列の順序はクラスタリングに影響しません。 CLUSTER BY後に指定された列の順序は、結果の多次元クラスタリングには影響しません。

サポートされている列の種類

すべての列の種類をクラスタリング キーとして使用できるわけではありません。 エンジンは、各列のデータ型を評価して適格性を判断します。

常に対象となる（アトミック型）:

• NumericType (ByteType、 ShortType、 IntegerType、 LongType、 FloatType、 DoubleType、 DecimalType)
• DateType
• TimestampType
• TimestampNTZType
• StringType

条件付きで対象:

• StructType: spark.microsoft.delta.clusteredTable.complexTypes.enabled が有効になっており、すべてのリーフ フィールドがそれ自体が対象となる型である場合。
• ArrayType: spark.microsoft.delta.clusteredTable.complexTypes.enabled が有効で、要素の種類が対象である場合。
• MapType: spark.microsoft.delta.clusteredTable.complexTypes.enabled が有効になっており、キーと値の両方の型が順序付け可能で適格な場合。

対象外:

• BinaryType
• BooleanType
• NullType

ファイル レベルの統計で使用される同等の対象となる型については、「 ファイルのスキップ - 対象となるデータ型」を参照してください。

他の機能との対話

ベスト プラクティス

• バッチ書き込み後、またはストリーミング テーブルのスケジュールに従ってOPTIMIZE定期的に実行しますが、ランタイム 2.0 以降でのみ実行します。この場合、増分クラスタリング戦略では頻繁に実行するコストが低くなります。 ランタイム 1.3 以前では、すべての OPTIMIZE 実行で Z キューブ内のすべてのデータが 100 GB 以下で書き換えられるため、実行は意図的で頻度の低いものにする必要があります。
• OPTIMIZE FULLは控えめに使用してください。 クラスタリング列を変更した後、または 1 回限り品質のリセットが必要な場合のために予約します。
• Spark UI またはクエリ プランでクエリ スキャン メトリック (スキャンされたファイルと合計ファイル) をチェックして、クラスタリングの品質を監視します。
• ストリーミング ワークロードの書き込みの最適化と組み合わせて、各マイクロバッチでクラスタリング用の管理可能な数のファイルが生成されるようにします。

関連するコンテンツ

• テーブル圧縮
• ファイル サイズを調整する
• Z オーダー
• パーティション分割
• ファイルをスキップ
• 同時実行制御
• V-Order
• Fabric の Apache Spark Runtime