Anvend væskeklyngedannelse på Delta-tabeller

Liquid clustering er en fleksibel datalayoutstrategi for Delta-tabeller i Microsoft Fabric. Den erstatter statisk Hive-stil opdeling og manuel Z-Order-vedligeholdelse med deklarativ, ændringsvenlig klyngedannelse. Du definerer, hvilke kolonner der skal klynges på, og Fabric Spark Runtime håndterer automatisk det fysiske datalayout.

Brug denne artikel til at:

Forstå, hvordan væskeklyngedannelse fungerer, og hvornår du skal bruge det.
Sammenlign væskeklyngedannelse med partitionering og Z-orden.
Konfigurer klyngedannelse på dine tabeller.
Forstå inkrementel væskeklyngedannelse (Runtime 2.0+).
Juster klyngeadfærden med sessionskonfigurationer.

Hvad er væskeklyngedannelse?

Flydende klyngedannelse organiserer data i Delta-tabelfiler, så rækker med lignende værdier i klyngekolonnerne er samlokaliseret. Layoutet muliggør forbedret filspring under forespørgselskørsel: når en forespørgsel filtrerer på klyngende kolonner, læser motoren kun de filer, hvis værdiintervaller matcher prædikatet, og springer resten over.

I modsætning til partitionering er væskeklyngedannelse:

Opretter ikke fysiske mappestrukturer pr. kolonneværdi.
Det kræver ikke, at du vælger klyngekolonner ved tabeloprettelsen (de kan ændres senere).
Håndterer kolonner med høj kardinalitet uden at skabe potentielle små filproblemer fra tusindvis af små partitioner.
Anvender layoutoptimering under OPTIMIZE, ikke ved skrivetid.

Fordele over partitionering og Z-Order

Væskeklyngedannelse giver betydelige fordele i forhold til både Hive-stil opdeling og Z-Order med hensyn til fleksibilitet, vedligeholdelse og håndtering af udviklende datamønstre.

Sammenlignet med Hive-stil opdeling

Aspekt	Hive-stil opdeling	Væske-klustring
Granulering	Én mappe pr. særskilt værdi (eller kombination)	Filniveau-værdiintervaller, ingen mapper
Høj kardinalitet	Opretter tusindvis af små filer/mapper	Håndterer naturligt; Arkiverer data i filer i den rette størrelse
Kolonneændringer	Kræver fuld tabelomskrivning	`ALTER TABLE ... CLUSTER BY` gælder på næste `OPTIMIZE`
Skrivesti	Partitionskolonnen skal være kendt ved skrivetidspunktet	Enhver kolonne kan klynges bagefter
Lille fil-problem	Almindeligt med streaming eller hyppige indsæt	Styret ved `OPTIMIZE` kompaktering

Sammenlignet med Z-orden

Aspekt	Z-orden	Væske-klustring
Kolonneændringer	Skal genafgives `OPTIMIZE ZORDER BY (...)` med nye kolonner	`ALTER TABLE ... CLUSTER BY` Definitionen fastholdes
Inkrementel støtte	Ingen inkrementel tilstand; Brug `WHERE` til at begrænse omfanget manuelt	Inkrementel tilstand (Runtime 2.0+) behandler kun nye, ændrede eller usunde filer automatisk
Metadata	Ingen vedvarende kolonnedefinition	Klynge kolonner lagret i tabelmetadata
Multi-kolonne layout	Z-ordens kurve anvendt ved optimeringstid	Z-orden for én klyngekolonne; Hilbert-kurve for 2+ kolonner, hvilket giver optimeret datalokalitet

Flydende klyngedannelse bruger Z-orden til enkeltkolonne-layouts og Hilbert-kurven til 2+ kolonner – en forbedring i forhold til Z-orden, som kun gælder Z-ordenskurven for multidimensionel klyngedannelse. Flydende klyngedannelse indkapsler begge algoritmer i en inkrementel, metadata-bevidst ramme, der reducerer løbende vedligeholdelsesomkostninger.

Opret en flydende klyngetabel

Definér klynge kolonner ved hjælp af klausulen CLUSTER BY ved tabeloprettelse:

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

Skift klyngekolonner

I modsætning til partitionering kan du ændre klyngekolonner når som helst uden at omskrive data:

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

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

Efter at have ændret kolonnerne i clustering, gælder det nye layout ved næste OPTIMIZE gennemspilning. Eksisterende filer bevarer deres tidligere layout, indtil de bliver gengrupperet.

Anvend klyngedannelse med OPTIMIZE

Klyngedannelse anvendes under kommandoen OPTIMIZE . Der er ikke behov for at specificere kolonner i sætningen OPTIMIZE , da klyngedefinitionen gemmes i tabelmetadata:

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

Brug OPTIMIZE FULL den, når du ændrer klyngenøgler og vil genopbygge Z-Cubes, der ikke følger den nuværende klyngestrategi. En Z-Cube er den logiske enhed, som væskeklyngedannelse bruger til at gruppere filer, der deler de samme klyngekolonner. Data klynges i en enkelt Z-Cube, indtil klyngenøglerne ændres, eller datamængden overstiger 100 GB.

Tip

Fra Fabric Runtime 2.0 understøtter Native eksekveringsmotoren udførelse af OPTIMIZE på flydende klyngetabeller og leverer 30–50% hurtigere multidimensionel klyngeydelse. Tidligere kørselstider falder tilbage til almindelig ikke-accelereret Spark-eksekvering.

Hvordan væskeklyngedannelse fungerer

Når du kører OPTIMIZE på et flydende cluster-bord, sker følgende:

Filvalg: Motoren vælger filer, der skal klynges.
- I Runtime 2.0+ (inkrementel klyngestrategi) vælges kun uklustede, usunde, små eller slettevektorfiler.
- I Runtime 1.3 vælges alle filer i hver Z-Cube mindre end 100 GB, uanset om de allerede er vel-klyngede eller ej.
Bin packing: Udvalgte filer grupperes i bins med henblik på en optimal outputfilstørrelse.
Repartitionering: Data inden for hver bin ompartitioneres ved hjælp af en rumfyldende kurve (Hilbert-kurve for flerkolonne, Z-orden for enkeltkolonne).
Filskrivning: Repartitionerede data skrives som nye filer med stramme værdiintervaller på klyngekolonner.
Metadata-opdatering: Delta-loggen registrerer filudskiftningen og tagger nye filer med klyngemetadata.

Resultatet er filer med ikke-overlappende (eller minimalt overlappende) værdiintervaller på klyngekolonner, hvilket gør det muligt for motoren at springe filer over, der ikke matcher forespørgselsprædikater.

Forsigtigt

Fabric Runtime 1.3 (Delta 3.2): brug flydende klyngedannelse med forsigtighed. I denne runtime bruger væskeklyngedannelse en fuld Z-Cube-omskrivningsstrategi—hver fil i en Z-Cube omskrives ved hver kørsel. En Z-Cube bevares (springes over) kun, når dens størrelse overstiger 100 GB. For tabeller mindre end 100 GB betyder den fulde omskrivning, at hver OPTIMIZE kørsel omskriver alle tabeldata, selv når dataene allerede er godt klynget. Dette forårsager alvorlig skriveforstærkning.

Brug ikke automatisk komprimering med væskeklyngedannelse i Runtime 1.3. Hver automatisk komprimeringsudløser kan forårsage en fuld tabelomskrivning i stedet for bare at samle de nye/ændrede data i grupper.
Undgå at køre OPTIMIZE efter hver skriveoperation. I Runtime 1.3 skal du begrænse clustering til strategiske, intentionelle runs, og acceptere lavere clustering freshness mellem dem.

Inkrementel væskeklyngedannelse, som eliminerer denne skriveforstærkning, er kun tilgængelig fra Fabric Runtime 2.0.

Inkrementel væskeklyngedannelse

Fra og med Fabric Runtime 2.0 (Delta 4.1) bruger liquid clustering som standard en inkrementlig klyngestrategi. Den inkrementelle strategi er en betydelig forbedring i forhold til den standard klyngeadfærd.

Vigtigt!

Inkrementel væskeklyngedannelse er kun tilgængelig i Fabric Runtime 2.0 og nyere. I tidligere runtimes OPTIMIZE bruger den standard (fuld omskrivning) adfærd, hvor alle filer i en Z-Cube omskrives ved hver kørsel.

Hvorfor den inkrementelle klyngestrategi er vigtig

Den standard klyngealgoritme omskriver alle filer inden for en Z-Cube (op til 100 GB) ved hver OPTIMIZE kørsel, uanset om de allerede er vel-klyngede eller ej. For en tabel, der modtager små tilføjelser, vokser klyngeomkostningerne lineært med tabelstørrelsen, ikke med mængden af nye data.

Inkrementel tilstand løser problemet med fuld omskrivning ved kun at vælge filer, der faktisk har brug for klyngedannelse:

Uklustrede filer: Nyligt skrevne data uden klynge-metadata
Små filer: Filer under målfilstørrelsesgrænsen
Filer med sletningsvektorer: Filer med akkumulerede sletninger, der overstiger oprydningsgrænsen

Allerede velplacerede, passende filer springes helt over.

Automatisk genklyngedannelse

Inkrementel væskeklyngedannelse inkluderer automatisk overlapsdetektion, kendt som automatisk genklyngedannelse, for at opretholde klyngekvaliteten over tid. Når nye data ankommer, kan det skabe overlap mellem filværdiintervaller, hvilket forringer effektiviteten af dataspring. Automatisk genklynge registrerer overlappende værdiområder på tværs af filer og genklynger selektivt kun de berørte filer.

Automatisk genklyngedannelse kører automatisk som en del af OPTIMIZE hver gang der er nye eller ændrede data at klynge. Ingen manuel indgriben eller planlagte fulde genklynge er nødvendige. Den inkrementelle klyngestrategi opretholder næsten optimal klyngekvalitet, efterhånden som data udvikler sig.

Gå tilbage til fuld omskrivningsadfærd

Hvis du skal deaktivere den inkrementelle klyngestrategi og bruge fuld-omskrivningsadfærden, skal du sætte følgende 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")

Alternativt kan du bruge OPTIMIZE FULL den til en engangs fuld recluster uden at ændre sessionsindstillinger:

OPTIMIZE sales FULL;

Bemærkning

Den inkrementel klyngestrategi tillader bevidst mindre afvigelse fra det teoretisk optimale layout for at opnå betydelige reduktioner i skriveforstærkning. Kørsel OPTIMIZE FULL lukker det hul ved fuldt ud at genopbygge Z-Cubes til det teoretiske optimale, men til en højere skriveomkostning.

Konfigurationsreference

Følgende sessionskonfigurationer styrer væskeklyngeadfærd i Fabric Runtime 2.0+.

Inkrementel klyngedannelse

Konfiguration	Type	Standardindstilling	Beskrivelse
`spark.microsoft.delta.optimize.clustering.strategy.incremental`	Boolean	`true`	Masterswitch til inkrementel klyngedannelse. Når `true`, behandler kun `OPTIMIZE` uklustrede, usunde, små og slettevektorfiler. Når `false`, omskrives alle filer for Z-Cubes under 100 GB (standardadfærd).
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster`	Boolean	`true`	Muliggør automatisk detektion og genklynstring af filer med overlappende dataområder. Gælder kun, når inkrementel klyngedannelse er aktiveret.

Auto rekluster-tuning

Disse konfigurationer styrer følsomheden og omfanget af automatisk reclustering. Standardindstillingerne er egnede til de fleste arbejdsbelastninger. Justér dem kun, når du skal ændre afvejningen mellem klyngekvalitet og skriveforstærkning.

Konfiguration	Type	Standardindstilling	Beskrivelse
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOffendingFiles`	Int	`4`	Minimum antal overlappende filer kræves for at udløse reclustering. Lavere værdier genklynger hurtigere (bedre forespørgselsydelse, højere skriveomkostninger). Det må være ≥ 2.
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOverlapThreshold`	Dobbelt	`0.75`	Threshold for klyngedimensionel overlapningsscore. Filpar, der scorer over denne værdi, betragtes som overlappende. Skal være inden for intervallet (0,25, 1,0]. Lavere værdier er mere aggressive.

Valg af klyngekolonner

For bedste resultater vælger du clustering columns baseret på dine mest almindelige forespørgselsfiltermønstre:

Vælg 1 til 4 kolonner , der ofte optræder i WHERE klausuler. Flere kolonner fortynder effektiviteten af pladsfyldningskurven for filspring pr. kolonne og øger tiden til at klynge data.
Overvej kolonnekardinalitet. Kolonner med lav kardinalitet producerer færre forskellige værdiintervaller, hvilket reducerer fordelen ved filspring, når de kombineres med klyngelyder med høj kardinalitet.
Kolonnerækkefølgen har ingen indflydelse på klyngedannelse. Rækkefølgen af kolonnerne, der angives bagefter CLUSTER BY , har ingen indflydelse på den resulterende multidimensionale klyngedannelse.

Understøttede kolonnetyper

Ikke alle kolonnetyper kan bruges som klyngenøgler. Motoren evaluerer hver kolonnes datatype for at afgøre berettigelse.

Altid berettiget (atomare typer):

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

Betinget berettiget:

Bemærkning

Følgende typer kan aktiveres fra og med Fabric Spark Runtime 2.0 (Delta 4.1)

StructType: når spark.microsoft.delta.clusteredTable.complexTypes.enabled er aktiveret, og alle bladfelter er selv berettigede typer.
ArrayType: når spark.microsoft.delta.clusteredTable.complexTypes.enabled er aktiveret, og elementtypen er berettiget.
MapType: når spark.microsoft.delta.clusteredTable.complexTypes.enabled er aktiveret, og både nøgle- og værdityperne er ordnbare og berettigede.

Ikke berettiget:

BinaryType
BooleanType
NullType

For de tilsvarende kvalificerede typer, der bruges i filniveau-statistik, se File skipping—Eligible data types.

Interaktion med andre funktioner

Funktion	Adfærd
Partitionering	Inkompatibel. Til filspring-formål anbefales flydende klyngedannelse frem for partitionering.
Z-orden	Inkompatibel. Til filspring-formål anbefales væskeklyngedannelse frem for Z-Order.
Hurtig optimering	Kompatibel fra Runtime 2.0. I tidligere kørselstider har hurtig optimering ingen effekt på flydende clusterede tabeller. Under `OPTIMIZE`springer klyngedannelse over, når der ikke er nok små filer eller utilstrækkelige data til at producere en sund størrelse outputfil.
Adaptiv målfilstørrelse	Kompatibelt. Den målfilstørrelse, der er fastsat ved adaptiv evaluering, bruges som målstørrelse for klyngedannelse.
Optimer skrivning til disk	Kompatibelt. Producerer konsoliderede filer ved skrivning, som derefter klynges under `OPTIMIZE`.
Automatisk komprimering	Brug ikke med væske-clustering i Runtime 1.3 eller tidligere. I disse runtimes omskriver hver automatisk komprimeringstrigger alle data i Z-kuber mindre end 100 GB, hvilket forårsager alvorlig skriveforstærkning. I Runtime 2.0+ er automatisk komprimering kompatibel: inkrementel klyngedannelse sikrer, at kun nye eller usunde filer omskrives. Automatisk komprimering håndterer konsolidering af små filer; `OPTIMIZE` Håndterer klyngelayout.
Deletionsvektorer	Filer, der overstiger tærsklen for slettede rækker, vælges til klyngedannelse, uafhængigt af deres klyngestatus.
V-rækkefølge	Kompatibelt. V-Order og væskeklyngedannelse opererer på forskellige akser (fil-internt layout vs. krydsfil-værdiintervaller). Begge kan anvendes sammen.

Bedste praksis

Kør OPTIMIZE regelmæssigt efter batchskrivninger eller efter en tidsplan for streamingtabeller – men kun i Runtime 2.0+, hvor den inkrementelle klyngestrategi gør hyppige kørsler billige. I Runtime 1.3 og tidligere omskriver hver OPTIMIZE kørsel alle data i Z-Cubes under 100 GB, så kørsler bør være tilsigtede og sjældne.
Brug OPTIMIZE FULL det med måde. Reserver det til efter du har ændret klyngekolonner eller brug for en engangs kvalitetsnulstilling.
Overvåg klyngekvaliteten ved at tjekke forespørgselsscanningsmålinger (filer scannet vs. samlede filer) i Spark UI eller forespørgselsplaner.
Kombiner med at optimere skrivning til streaming-arbejdsbelastninger for at sikre, at hver mikrobatch producerer et håndterbart antal filer til klyngedannelse.

Feedback

Var denne side nyttig?

Last updated on 2026-05-26