Bruk væskeklynging på Delta-tabeller

Flytende klynging er en fleksibel strategi for dataoppsett for Delta-tabeller i Microsoft Fabric. Den erstatter statisk Hive-lignende partisjonering og manuell Z-Order-vedlikehold med deklarativ, endringsvennlig klynging. Du definerer hvilke kolonner som skal klynges på, og Fabric Spark Runtime håndterer automatisk det fysiske dataoppsettet.

Bruk denne artikkelen til å:

Forstå hvordan væskeklyngedannelse fungerer og når du skal bruke det.
Sammenlign væskeklynging med partisjonering og Z-orden.
Konfigurer klynging på tabellene dine.
Forstå inkrementell væskeklynging (Runtime 2.0+).
Vurder kvaliteten på klynging.
Juster klyngeoppførsel med sesjonskonfigurasjoner.

Hva er væskeklyngedannelse?

Flytende klynging organiserer data i Delta-tabellfiler slik at rader med lignende verdier i klyngekolonnene er samlokalisert. Oppsettet muliggjør forbedret filhopp under spørringskjøring: når en spørring filtrerer på klyngende kolonner, leser motoren kun filer hvis verdiområder samsvarer med predikatet, og hopper over resten.

I motsetning til partisjonering, væskeklynging:

Lager ikke fysiske katalogstrukturer per kolonneverdi.
Det krever ikke at du velger klyngekolonner ved tabellopprettelse (de kan endres senere).
Håndterer kolonner med høy kardinalitet uten å skape potensielle små filproblemer fra tusenvis av små partisjoner.
Anvender layoutoptimalisering under OPTIMIZE, ikke ved skrivetid.

Fordeler sammenlignet med partisjonering og Z-orden

Væskeklynging gir betydelige fordeler sammenlignet med både Hive-stil partisjonering og Z-Order når det gjelder fleksibilitet, vedlikehold og håndtering av utviklende datamønstre.

Sammenlignet med Hive-stil partisjonering

Aspekt	Hive-stil partisjonering	Væskesamling
Detaljnivå	Én katalog per distinkt verdi (eller kombinasjon)	Verdiområder på filnivå, ingen kataloger
Høy kardinalitet	Lager tusenvis av små filer/kataloger	Håndterer naturlig; Arkiverer data i filer i riktig størrelse
Kolonneendringer	Krever full omskriving av tabellen	`ALTER TABLE ... CLUSTER BY` gjelder på neste `OPTIMIZE`
Skrivesti	Partisjonskolonnen må være kjent ved skrivetid	Enhver kolonne kan klynges i etterkant
Problemet med små filer	Felles med strømming eller hyppige innsettinger	Styrt ved `OPTIMIZE` kompaktering

Sammenlignet med Z-ordenen

Aspekt	Z-orden	Væskesamling
Kolonneendringer	Må kjøres `OPTIMIZE ZORDER BY (...)` på nytt med nye kolonner	`ALTER TABLE ... CLUSTER BY` Definisjonen opprettholder
Inkrementell støtte	Ingen inkrementell modus; Bruk `WHERE` for å begrense omfanget manuelt	Inkrementell modus (Runtime 2.0+) behandler kun nye, endrede eller usunne filer automatisk
Metadata	Ingen definisjon av vedvarende kolonne	Klyngekolonner lagret i tabellmetadata
Flerkolonneoppsett	Z-ordenskurve anvendt ved optimaliseringstid	Z-orden for én klyngekolonne; Hilbert-kurve for 2+ kolonner, som gir optimalisert datalokalitet

Væskeklynging bruker Z-orden for enkeltkolonneoppsett og Hilbert-kurven for 2+ kolonner—en forbedring over Z-orden, som kun gjelder Z-ordenskurven for flerdimensjonal klynging. Flytende klynging pakker begge algoritmene inn i et inkrementell, metadata-bevisst rammeverk som reduserer løpende vedlikeholdskostnader.

Lag en flytende klynget tabell

Definer klyngekolonner ved bruk av klausulen CLUSTER BY ved tabellopprettelse:

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

Endringsklyngekolonner

I motsetning til partisjonering kan du endre klyngekolonner når som helst uten å omskrive data:

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

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

Etter å ha endret klyngekolonnene, gjelder det nye oppsettet ved neste OPTIMIZE kjøring. Eksisterende filer beholder sitt tidligere oppsett til de klynges på nytt.

Bruk klyngedannelse med OPTIMIZE

Klynging utføres under kommandoen OPTIMIZE . Det er ikke nødvendig å spesifisere kolonner i setningen OPTIMIZE siden klyngedefinisjonen lagres 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;

OPTIMIZE FULL Bruk når du endrer klyngenøkler og vil bygge opp Z-kuber på nytt som ikke følger dagens klyngestrategi. En Z-Kube er den logiske enheten væskeklynging bruker for å gruppere filer som deler de samme klyngekolonnene. Data samles i en enkelt Z-Kube inntil klyngenøklene endres eller datamengden overstiger 100 GB.

Tips

Fra og med Fabric Runtime 2.0 støtter Native kjøringsmotor å utføre OPTIMIZE på flytende klyngede tabeller, og leverer 30–50% raskere flerdimensjonal klyngeytelse. Tidligere kjøretider faller tilbake til vanlig ikke-akselerert Spark-utførelse.

Hvordan væskeklynging fungerer

Når du kjører OPTIMIZE på en væskeklynget tabell, skjer følgende:

Filvalg: Motoren velger filer som trenger klynging.
- I Runtime 2.0+ (inkrementell klyngestrategi) velges kun uklyngede, usunne, små eller slettevektorfiler.
- I Runtime 1.3 velges alle filer i hver Z-Cube mindre enn 100 GB, uavhengig av om de allerede er godt klynget eller ikke.
Bin packing: Utvalgte filer grupperes i bokser med mål om optimal utdatafilstørrelse.
Repartisjonering: Data innenfor hver bin omstruktureres ved hjelp av en romutfyllende kurve (Hilbert-kurve for flerkolonne, Z-orden for enkeltkolonne).
Filskriving: Repartisjonerte data skrives som nye filer med stramme verdiintervaller på klyngende kolonner.
Metadata-oppdatering: Delta-loggen registrerer filutskiftingen, og merker nye filer med klyngemetadata.

Resultatet er filer med ikke-overlappende (eller minimalt overlappende) verdiområder på klyngende kolonner, noe som gjør at motoren kan hoppe over filer som ikke matcher spørringspredikater.

Forsiktig!

Fabric Runtime 1.3 (Delta 3.2): bruk væskeklynging med forsiktighet. I denne kjøretiden bruker væskeklynging en full Z-Cube-omskrivingsstrategi—hver fil i en Z-Cube skrives om ved hver kjøring. En Z-Cube bevares (hoppes over) kun når størrelsen overstiger 100 GB. For tabeller mindre enn 100 GB betyr full omskriving at hver OPTIMIZE kjøring omskriver all tabelldata, selv når dataene allerede er godt klynget. Dette fører til kraftig skriveforsterkning.

Ikke bruk automatisk komprimering med væskeklynging i Runtime 1.3. Hver automatisk komprimeringsutløser kan føre til en fullstendig tabellomskriving i stedet for bare å klynge de nye/endrede dataene.
Unngå å kjøre OPTIMIZE etter hver skriveoperasjon. I Runtime 1.3, begrens klynging til strategiske, intensjonelle kjøringer, og aksepter lavere klynging ferskhet mellom dem.

Inkrementell væskeklynging, som eliminerer denne skriveforsterkningen, er kun tilgjengelig fra og med Fabric Runtime 2.0.

Inkrementell væskeklynging

Fra og med Fabric Runtime 2.0 (Delta 4.1) bruker væskeklynging som standard en inkrementell klyngestrategi. Den inkrementelle strategien er en betydelig forbedring sammenlignet med standard klyngingsoppførsel.

Important

Inkrementell væskeklynging er kun tilgjengelig i Fabric Runtime 2.0 og nyere. I tidligere kjøretider OPTIMIZE brukes standard (full omskriving) oppførsel hvor alle filer i en Z-Kube omskrives ved hver kjøring.

Hvorfor den inkrementell klyngingsstrategien er viktig

Standard klyngealgoritme omskriver alle filer i en Z-Cube (opptil 100 GB) ved hver OPTIMIZE kjøring, uavhengig av om de allerede er godt klynget eller ikke. For en tabell som mottar små appender, vokser klyngekostnaden lineært med tabellstørrelsen, ikke med mengden ny data.

Inkrementell modus løser problemet med full omskriving ved å velge kun filer som faktisk trenger klynging:

Uklyngede filer: Nylig skrevne data uten klyngemetadata
Små filer: Filer under mål-filstørrelsesterskelen
Filer med slettingsvektorer: Filer med akkumulerte slettinger som overstiger opprydningsgrensen

Allerede godt klyngede, passende store filer hoppes helt over.

Automatisk reklustering

Inkrementell væskeklynging inkluderer automatisk overlappsdeteksjon, kjent som automatisk reklustering, for å opprettholde klyngekvaliteten over tid. Når nye data ankommer, kan det skape overlapp mellom filverdiområder, noe som reduserer effektiviteten av datahopp. Automatisk reklustering oppdager overlappende verdiområder på tvers av filer og selektivt kun klynger om de berørte filene.

Automatisk reklustering kjører automatisk når OPTIMIZE det kommer nye eller endrede data til klyngen. Ingen manuell inngripen eller planlagte fullstendige reklusteringer er nødvendig. Den inkrementelle klyngestrategien opprettholder nær optimal klyngekvalitet etter hvert som dataene utvikler seg.

Gå tilbake til full omskrivingsoppførsel

Hvis du må deaktivere den inkrementell klyngestrategien og bruke full-omskrivingsoppførsel, sett følgende konfigurasjon:

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, bruk OPTIMIZE FULL for en engangs full recluster uten å endre sesjonsinnstillinger:

OPTIMIZE sales FULL;

Notat

Den inkrementell klyngingsstrategien tillater bevisst mindre avvik fra det teoretisk optimale oppsettet for å oppnå betydelige reduksjoner i skriveforsterkning. Kjøring OPTIMIZE FULL lukker dette gapet ved å fullstendig bygge om Z-Cubes til det teoretiske optimale, men til høyere skrivekostnad.

Evaluer klyngekvaliteten

Fra og med Fabric Runtime 2.0, bruk Scala-metoden clusteringQuality() for å evaluere det fysiske oppsettet av en flyteklynget Delta-tabell. Metoden returnerer en DataFrame med én rad for hver klyngekolonne.

Important

Metoden clusteringQuality() er ikke tilgjengelig i Fabric Runtimes før 2.0.

import io.delta.tables.DeltaTable

val deltaTable = DeltaTable.forName(spark, "dbo.clustered_table")
val quality_df = deltaTable.clusteringQuality()
display(quality_df)

Resultatet inneholder følgende måleparametere:

Metric	Beskrivelse	Foretrukket retning
`column_name`	Klyngekolonne evaluert av metoden.	Gjelder ikke.
`status`	Evalueringsstatus. `ok` betyr at måleparametere ble beregnet. `no_stats` betyr at kolonnen ikke har brukbare filstatistikker.	`ok`.
`num_files`	Totalt antall filer i tabellbildet.	Gjelder ikke.
`num_files_with_stats`	Antall filer med brukbare statistikker for kolonnen. Filer uten statistikk kan ikke hoppes over ved filhopping.	Nær `num_files`.
`avg_coverage_pct`	Gjennomsnittlig prosentandel av kolonnens verdiområde dekkes av hver fil.	Lavere verdier er bedre.
`avg_depth`	Gjennomsnittlig antall filer som et punktssøk berører.	`1.0` er ideelt.
`max_depth`	Maksimalt antall filer som et punktsøk berører.	Lavere verdier er bedre.
`overlap_ratio`	Normalisert overlapp mellom filverdiområder.	`0` betyr ingen overlapp og er ideell.
`skipping_effectiveness`	Estimert andel filer som en punktspørring kan hoppe over.	`1` betyr at 100% alle ikke-matchende filer kan hoppes over. Etter hvert som antallet valgte klyngekolonner øker, reduseres det maksimale mulige `skipping_effectiveness` .

Sammenlign disse målingene før og etter OPTIMIZE for å vurdere om klynging forbedret oppsettet. Tolk resultatene med tabellens datafordeling og spørringspredikater. Målingene estimerer potensialet for filhopping fra filstatistikk; De måler ikke ytelsen til en spesifikk forespørsel.

Konfigurasjonsreferanse

Følgende sesjonskonfigurasjoner styrer væskeklyngeoppførsel i Fabric Runtime 2.0+.

Inkrementell klynging

Konfigurasjon	Type:	Forhåndsinnstilt	Beskrivelse
`spark.microsoft.delta.optimize.clustering.strategy.incremental`	boolsk	`true`	Hovedbryter for inkrementell klynging. Når `true`, behandler kun `OPTIMIZE` uklyngede, usunne, små og slettevektor-filer. Når `false`, skrives alle filer for Z-Cubes under 100 GB om (standard oppførsel).
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster`	boolsk	`true`	Muliggjør automatisk deteksjon og omklynging av filer med overlappende dataområder. Gjelder kun når inkrementell klynging er aktivert.

Automatisk rekluster-tuning

Disse konfigurasjonene styrer følsomheten og omfanget av automatisk reklustering. Standardinnstillingene passer for de fleste arbeidsbelastninger. Juster dem bare når du må endre avveiningen mellom klyngekvalitet og skriveforsterkning.

Konfigurasjon	Type:	Forhåndsinnstilt	Beskrivelse
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOffendingFiles`	Int	`4`	Minimum antall overlappende filer kreves for å utløse re-clustering. Lavere verdier klynger seg raskere (bedre spørringsytelse, høyere skrivekostnad). Må være ≥ 2.
`spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOverlapThreshold`	Dobbel	`0.75`	Terskel for overlappende poeng for klyngingsdimensjoner. Filpar som scorer over denne verdien regnes som overlappende. Må være innenfor området (0,25, 1,0]. Lavere verdier er mer aggressive.

Valg av klyngekolonner

For best resultat, velg klyngende kolonner basert på dine vanligste spørringsfiltermønstre:

Velg 1 til 4 kolonner som ofte forekommer i WHERE klausuler. Flere kolonner utvanner effektiviteten til å hoppe over filer per kolonne for plassutfyllingskurven og øker tiden til å klynge data.
Vurder kolonnekardinalitet. Kolonner med lav kardinalitet gir færre distinkte verdiområder, noe som reduserer fordelen med filhopp når de kombineres med klyngelykler med høy kardinalitet.
Kolonnerekkefølgen har ingen innvirkning på klynging. Rekkefølgen på kolonnene som er spesifisert etter CLUSTER BY har ingen innvirkning på den resulterende flerdimensjonale klyngingen.

Kolonnetyper som støttes

Ikke alle kolonnetyper kan brukes som klyngenøkler. Maskinen evaluerer hver kolonnes datatype for å avgjøre om den er kvalifisert.

Alltid kvalifisert (atomtyper):

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

Betinget kvalifisert: