Tillämpa flytande klustring på Delta-tabeller

Liquid clustering är en flexibel strategi för dataorganisation för Delta-tabeller i Microsoft Fabric. Den ersätter statisk partitionering i Hive-stil och manuellt Z-Order-underhåll med deklarativ, ändringsvänlig klustring. Du definierar vilka kolumner som ska klustras på, och Fabric Spark Runtime hanterar den fysiska datalayouten automatiskt.

Använd den här artikeln för att:

Förstå hur flytande klustring fungerar och när du ska använda den.
Jämför flytande klustring med partitionering och Z-Order.
Konfigurera klustring på dina tabeller.
Förstå inkrementell flytande klustring (Runtime 2.0+).
Justera klustringsbeteendet med sessionskonfigurationer.

Vad är flytande klustring?

Flytande klustring organiserar data i Delta-tabellfiler så att rader med liknande värden i klustringskolumnerna samlokaliseras. Layouten möjliggör förbättrad filhoppning under frågekörning: när en fråga filtrerar på klustringskolumner läser motorn endast de filer vars värdeintervall matchar predikatet och hoppar över resten.

Till skillnad från partitionering, flytande klustring:

Skapar inte fysiska katalogstrukturer per kolumnvärde.
Kräver inte att du väljer klustringskolumner när tabellen skapas (de kan ändras senare).
Hanterar kolumner med hög kardinalitet utan att skapa potentiella problem med små filer från tusentals små partitioner.
Tillämpar layoutoptimering under OPTIMIZE, inte vid skrivtillfället.

Fördelar med partitionering och Z-order

Flytande klustring ger betydande fördelar jämfört med både Hive-partitionering och Z-Order när det gäller flexibilitet, underhåll och hantering av föränderliga datamönster.

Jämfört med Partitionering i Hive-stil

Aspect	Hive-format partitionering	Klustring av vätska
Granularitet	En katalog per distinkt värde (eller kombination)	Värdeintervall på filnivå, inga kataloger
Hög kardinalitet	Skapar tusentals små filer/kataloger	Fungerar naturligt; delar upp data i filer i rätt storlek
Kolumnändringar	Kräver fullständig tabellomskrivning	`ALTER TABLE ... CLUSTER BY` gäller vid nästa `OPTIMIZE`
Skrivväg	Partitionskolumnen måste vara känd vid skrivtillfället	Alla kolumner kan grupperas i efterhand
Problem med små filer	Vanligt med direktuppspelning eller frekventa infogningar	Hanteras av `OPTIMIZE` komprimering

Jämfört med Z-order

Aspect	Z-order	Klustring av vätska
Kolumnändringar	Måste köras `OPTIMIZE ZORDER BY (...)` igen med nya kolumner	`ALTER TABLE ... CLUSTER BY` bevarar definitionen
Inkrementellt stöd	Inget inkrementellt läge; använda `WHERE` för att begränsa omfånget manuellt	Inkrementellt läge (Runtime 2.0+) bearbetar endast nya, ändrade eller felaktiga filer automatiskt
Metadata	Ingen beständig kolumndefinition	Klustring av kolumner som lagras i tabellmetadata
Layout med flera kolumner	Z-orderkurva som tillämpas vid optimeringstidpunkt	Z-Order för en klustringskolumn; Hilbert-kurva för 2+ kolumner, vilket ger optimerad datalokalitet

Flytande klustring använder Z-Order för layouter med en kolumn och Hilbert-kurvan för 2+ kolumner – en förbättring jämfört med Z-Order, som endast tillämpar Z-Order-kurvan för flerdimensionell klustring. Flytande klustring omsluter båda algoritmerna i ett inkrementellt, metadatamedvetent ramverk som minskar den löpande underhållskostnaden.

Skapa en flytande klustertabell

Definiera klustringskolumner med hjälp av CLUSTER BY -satsen när tabellen skapas:

-- 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()

Ändra klustringskolumner

Till skillnad från partitionering kan du när som helst ändra klustringskolumner utan att skriva om data:

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

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

När du har ändrat klustringskolumner gäller den nya layouten vid nästa OPTIMIZE körning. Befintliga filer behåller sin tidigare layout tills de omklustras.

Tillämpa klustring med OPTIMIZE

Klustring tillämpas under OPTIMIZE kommandot . Du behöver inte ange kolumner i -instruktionen OPTIMIZE eftersom klustringsdefinitionen lagras i tabellmetadata:

-- 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;

Använd OPTIMIZE FULL när du ändrar klustringsnycklar och vill återskapa Z-Kuber som inte följer den aktuella klustringsstrategin. En Z-Kub är den logiska enhet som flytande klustring använder för att gruppera filer som delar samma klustringskolumner. Data grupperas i en enda Z-kub tills klusternycklarna ändras eller mängden data överskrider 100 GB.

Tips/Råd

Från och med Fabric Runtime 2.0 stöder körningsmotorn Native att utföra OPTIMIZE på flytande klustrade tabeller, vilket ger 30–50% snabbare flerdimensionella klusterprestanda. Tidigare körningsversioner återgår till vanlig icke-accelererad Spark-körning.

Så här fungerar flytande klustring

När du kör OPTIMIZE på en vätskeklustrad tabell händer följande:

Val av filer: Systemet väljer filer som behöver klustras.
- I Runtime 2.0+ (inkrementell klustringsstrategi) väljs endast olusterade, ej felfria, små filer eller borttagningsvektorfiler.
- I Runtime 1.3 väljs alla filer i varje Z-kub som är mindre än 100 GB, oavsett om de redan är väl klustrade.
Bin packing: Valda filer grupperas i binar för att uppnå en optimal utdatafilstorlek.
Ompartitionering: Data inom varje partition ompartitioneras med hjälp av en rymdfyllande kurva (Hilbert-kurva för flera kolumner, Z-ordning för en enskild kolumn).
Filskrivning: Ompartitionerade data skrivs som nya filer med snäva värdeintervall i klustringskolumner.
Metadatauppdatering: Delta-loggen registrerar filbytet och taggar nya filer med klustringsmetadata.

Resultatet är filer med icke-överlappande (eller minimalt överlappande) värdeintervall på klustringskolumner, vilket gör att motorn kan hoppa över filer som inte matchar frågepredikat.

Caution

Fabric Runtime 1.3 (Delta 3.2): Använd flytande klustring med försiktighet. I denna körning använder Liquid Clustering en strategi för fullständig omskrivning av Z-Cube – varje fil i en Z-Cube skrivs om vid varje körning. En Z-kub bevaras (hoppas över) endast när dess storlek överskrider 100 GB. För tabeller som är mindre än 100 GB innebär en fullständig omskrivning att varje körning av OPTIMIZE skriver om all tabelldata, även när data redan är väl klustrade. Detta orsakar allvarligt ökad skrivbelastning.

Använd inte automatisk komprimering med flytande klustring i Runtime 1.3. Varje trigger för automatisk komprimering kan orsaka en omskrivning av hela tabellen i stället för att bara klustra om nya eller ändrade data.
Undvik att köra OPTIMIZE efter varje skrivåtgärd. I Runtime 1.3 begränsar du klustring till strategiska, avsiktliga körningar och accepterar lägre klustrings färskhet mellan dem.

Inkrementell flytande klustring, som eliminerar den här skrivförstärkningen, är endast tillgänglig från och med Fabric Runtime 2.0.

Stegvis vätskeklustring

Från och med Fabric Runtime 2.0 (Delta 4.1) använder flytande kluster en incremental klustringsstrategi som standard. Den inkrementella strategin är en betydande förbättring jämfört med standardbeteendet för klustring.

Important

Inkrementell flytande klustring är endast tillgängligt i Fabric Runtime 2.0 och senare. I tidigare runtimeversioner använder OPTIMIZE standardbeteendet (fullständig omskrivning), där alla filer i en Z-Cube skrivs om vid varje körning.

Varför den inkrementella klustringsstrategin är viktig

Standardalgoritmen för klustring skriver om alla filer i en Z-Cube (upp till 100 GB) vid varje OPTIMIZE-körning, oavsett om de redan är välklustrade. För en tabell som tar emot små tillägg växer klustringskostnaden linjärt med tabellstorlek, inte med mängden nya data.

Inkrementellt läge löser problemet med fullständig omskrivning genom att endast välja filer som faktiskt behöver klustring:

Olustererade filer: Nyligen skrivna data utan klustringsmetadata
Små filer: Filer under tröskelvärdet för målfilstorlek
Filer med borttagningsvektorer: Filer med ackumulerade borttagningar som överskrider rensningströskeln

Filer som redan är väl grupperade och har lämplig storlek hoppas över helt.

Automatisk omklustring

Inkrementell dynamisk klustring inkluderar automatisk identifiering av överlappningar, så kallad automatisk omklustring, för att upprätthålla klustringskvaliteten över tid. När nya data kommer in kan det skapa överlappning mellan värdeintervall i filer, vilket försämrar effektiviteten i dataskippning. Automatisk återklustering identifierar överlappande värdeintervall mellan filer och selektivt reclustrar endast de berörda filerna.

Automatisk omklustring sker automatiskt som en del av OPTIMIZE när det finns nya eller ändrade data som ska klustras. Ingen manuell inblandning eller schemalagda fullständiga omklustringar krävs. Den inkrementella klustringsstrategin upprätthåller nästan optimal klustringskvalitet när data utvecklas.

Återställ till fullständigt omskrivningsläge

Om du behöver inaktivera den inkrementella klustringsstrategin och använda det fullständiga omskrivningsbeteendet anger du följande konfiguration:

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")

Du kan också använda OPTIMIZE FULL för en engångs full recluster utan att ändra sessionsinställningarna:

OPTIMIZE sales FULL;

Note

Den inkrementella klustringsstrategin tillåter avsiktligt mindre avvikelser från den teoretiskt optimala layouten för att uppnå betydande minskningar av skrivförstärkning. Att köra OPTIMIZE FULL täpper till gapet genom att bygga om Z-Cubes fullständigt till det teoretiska optimumet, men till priset av högre skrivkostnader.

Konfigurationsreferens

Följande sessionskonfigurationer styr beteendet för flytande klustring i Fabric Runtime 2.0+.

Inkrementell klustring

Configuration	Type	Default	Description
`spark.microsoft.delta.optimize.clustering.strategy.incremental`	Boolean	`true`	Huvudväxel för inkrementell klustring. När `true`bearbetar `OPTIMIZE` endast olusterade, ej felfria, små filer och borttagningsvektorfiler. När `false`skrivs alla filer för Z-Kuber under 100 GB i storlek om (standardbeteende).
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster`	Boolean	`true`	Möjliggör automatisk identifiering och omhantering av filer med överlappande dataintervall. Gäller endast när inkrementell klustring är aktiverat.

Automatisk justering av rekluster

Dessa konfigurationer styr känsligheten och omfånget för automatisk återklustering. Standardvärdena är lämpliga för de flesta arbetsbelastningar. Justera dem bara när du behöver ändra kompromissen mellan klustringskvalitet och skrivförstärkning.

Configuration	Type	Default	Description
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOffendingFiles`	Int	`4`	Minsta antal överlappande filer som krävs för att utlösa reklustering. Lägre värden omklustras tidigare (bättre frågeprestanda, högre skrivkostnad). Måste vara ≥ 2.
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOverlapThreshold`	Double	`0.75`	Tröskelvärde för klustringsdimensionens överlappningspoäng. Filpar som får ett värde över detta värde betraktas som överlappande. Måste finnas i intervallet (0,25, 1,0]. Lägre värden är mer aggressiva.

Välja klustringskolumner

För bästa resultat väljer du klustringskolumner baserat på dina vanligaste frågefiltermönster:

Välj 1 till 4 kolumner som visas ofta i WHERE satser. Fler kolumner späder ut filen per kolumn och hoppar över effektiviteten i utrymmesfyllningskurvan och ökar tiden till klusterdata.
Överväg kolumnkardinalitet. Kolumner med låg kardinalitet ger färre olika värdeintervall, vilket minskar fördelen med att kunna hoppa över filer i kombination med klusternycklar med hög kardinalitet.
Kolumnordningen påverkar inte klustring. Ordningen på de kolumner som anges efter CLUSTER BY har ingen inverkan på den resulterande flerdimensionella klustring.

Kolumntyper som stöds

Alla kolumntyper kan inte användas som klustringsnycklar. Motorn utvärderar varje kolumns datatyp för att fastställa berättigande.

Alltid berättigad (atomiska typer):

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

Villkorligt berättigad:

Note

Följande typer kan aktiveras från och med Fabric Spark Runtime 2.0 (Delta 4.1)

StructType: när spark.microsoft.delta.clusteredTable.complexTypes.enabled är aktiverat, och alla bladfält själva är giltiga typer.
ArrayType: när spark.microsoft.delta.clusteredTable.complexTypes.enabled är aktiverat och elementtypen är berättigad.
MapType: när spark.microsoft.delta.clusteredTable.complexTypes.enabled är aktiverat och både nyckel- och värdetyperna är ordnade och berättigade.

Inte berättigad:

BinaryType
BooleanType
NullType

För motsvarande giltiga typer som används i statistik på filnivå, se Hoppa över filer: Giltiga datatyper.

Interaktion med andra funktioner

Feature	Behavior
Partitionering	Inkompatibel. För att möjliggöra filöverhoppning rekommenderas liquid clustering i stället för partitionering.
Z-Order	Inkompatibel. För att hoppa över filer rekommenderas Liquid Clustering framför Z-Order.
Snabb optimering	Kompatibel med start i Runtime 2.0. I tidigare runtime-versioner har snabboptimering ingen effekt på Liquid Clustered-tabeller. Under `OPTIMIZE` hoppar klustring över när det inte finns tillräckligt många små filer eller för lite data för att skapa en utdatafil av lämplig storlek.
Anpassad målfilstorlek	Kompatibel. Målfilens storlek som anges av anpassningsbar utvärdering används som målstorlek för klustring.
Optimera skrivning	Kompatibel. Skapar konsoliderade filer vid skrivning som sedan grupperas under `OPTIMIZE`.
Automatisk komprimering	Använd inte med liquid clustering i Runtime 1.3 eller tidigare. I dessa körningsmiljöer skriver varje automatisk komprimeringsutlösare om all data i Z-Cubes som är mindre än 100 GB stora, vilket orsakar allvarlig skrivförstärkning. I Runtime 2.0+ är automatisk komprimering kompatibel: inkrementell klustring säkerställer att endast nya eller felaktiga filer skrivs om. Automatisk komprimering hanterar konsolidering av små filer. `OPTIMIZE` hanterar klustringslayouten.
Borttagningsvektorer	Filer som överskrider tröskelvärdet för borttagna rader väljs för klustring, oberoende av deras klustringsstatus.
V-order	Kompatibel. V-order och flytande klustring fungerar på olika axlar (filintern layout jämfört med värdeintervall mellan filer). Båda kan användas tillsammans.

Bästa praxis

Kör OPTIMIZE regelbundet efter batchskrivningar eller enligt ett schema för streamingtabeller – men endast i Runtime 2.0+, där den inkrementella klustringsstrategin gör frekventa körningar kostnadseffektiva. I Runtime 1.3 och tidigare skriver varje körning av OPTIMIZE om all data i Z-Cubes som är mindre än 100 GB, så körningar bör vara genomtänkta och ske sällan.
Använd OPTIMIZE FULL sparsamt. Spara den tills efter att du har ändrat klustringskolumner eller behöver en engångsåterställning av kvaliteten.
Övervaka klustringskvaliteten genom att kontrollera frågegenomsökningsmått (filer skannade jämfört med totalt antal filer) i Spark-användargränssnittet eller frågeplaner.
Kombinera med optimerad skrivning för strömningsarbetsbelastningar för att säkerställa att varje mikrobatch resulterar i ett hanterbart antal filer för klustring.

Feedback

Var den här sidan till hjälp?

Last updated on 2026-05-24