Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Delta-tabellfiler blir fragmentert over tid. Fragmentering øker filoperasjonsoverhead, reduserer komprimeringseffektiviteten og kan begrense leserens parallellisme. Kompaktering omskriver mange små filer til færre filer i riktig størrelse slik at Spark kan lese og behandle data mer effektivt.
Kommandoen OPTIMIZE er den primære komprimeringsoperasjonen. Den grupperer små filer i mapper som retter seg mot en ideell filstørrelse, og skriver dem deretter om til storage.
For veiledning på tvers av arbeidsbelastninger om komprimeringsstrategier på tvers av SQL-analyseendepunkt, Power BI Direct Lake og Spark, se vedlikehold og optimalisering av tverrarbeidsbelastningstabeller.
Komprimeringsmetoder
Fabric tilbyr flere tilnærminger for å opprettholde optimale filstørrelser i Delta-tabeller:
OPTIMIZE kommando
Kommandoen OPTIMIZE er den grunnleggende operasjonen for å komprimere Delta-tabeller. Den omskriver små filer til større filer for å forbedre dataoppsettet i Delta-tabeller.
| Eiendom | Beskrivelse | Standardverdi | Konfigurasjon av økt |
|---|---|---|---|
| minFileSize | Filer som er mindre enn denne terskelen, grupperes sammen og skrives om til større filer. | 1073741824 (1 GB) | spark.databricks.delta.optimize.minFileSize |
| maxFileSize | Målfilstørrelse produsert av kommandoen OPTIMIZE . |
1073741824 (1 GB) | spark.databricks.delta.optimize.maxFileSize |
OPTIMIZE er idempotent, men en oversized minFileSize kan øke skriveforsterkningen. For eksempel, med minFileSize satt til 1 GB, kan en 900 MB-fil skrives om etter en liten ekstra skriving. For automatisk veiledning for filstørrelseshåndtering, se adaptiv målfilstørrelse.
OPTIMIZE med Z-Order
Når du bruker klausulen ZORDER BY , OPTIMIZE omskriver den aktive filer slik at rader med lignende verdier er samlokalisert i de samme filene. Det colokerte oppsettet forbedrer filhopp for selektive filtre. Bruk Z-Order når:
- Spørringene filtreres ofte på to eller flere kolonner sammen (for eksempel dato + customer_id), og
- Disse predikatene er selektive nok til at hopping på filnivå reduserer antall filer som skannes.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2)
OPTIMIZE med V-orden
Klausulen VORDER resulterer i at filene som er scoped for kompaktering får V-ordensoptimaliseringen brukt. For mer informasjon om V-order, se den detaljerte dokumentasjonen.
OPTIMIZE dbo.table_name VORDER
Du kan kombinere Z-orden og V-orden i én enkelt kommando. Spark anvender operasjonene i denne rekkefølgen: bin-kompaktering → Z-orden → V-orden.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2) VORDER
V-ordensoppførsel under OPTIMIZE avhenger av hvordan du utløser kommandoen:
| Påkallelse | Virkemåte |
|---|---|
OPTIMIZE table VORDER |
Tvinger V-rekkefølge på omskrevne filer, uavhengig av sesjons- eller tabellinnstillinger. |
OPTIMIZE table (ingen VORDER nøkkelord) |
Arver V-ordensoppførsel fra TBLPROPERTIES("delta.parquet.vorder.enabled") hvis satt, ellers faller tilbake til sesjonskonfigurasjonen spark.sql.parquet.vorder.default. |
OPTIMIZE med væskeklynger
Væskeklynger er spesifisert som et tabellalternativ; Se Aktiver væskeklynger for mer informasjon. Når flytende klynger er aktivert, OPTIMIZE utfører den fysiske omskrivingen som bruker klyngepolicyen.
Viktig!
Data grupperes bare når OPTIMIZE de kjøres på flytende grupperte aktiverte tabeller. Vanlige skriveoperasjoner grupperer IKKE dataene. Å ha en komprimeringsstrategi, for eksempel bruk av automatisk komprimering eller manuell planlegging av optimaliseringsjobber, er avgjørende for å sikre at fordelene med grupperte data (det vil si forbedret hopping av Delta-filer) kan realiseres.
OPTIMIZE FULL
Standard OPTIMIZE klynger ikke filer som allerede regnes som klyngede på nytt. Når du endrer klyngenøklene eller klyngeleverandøren, beholder eksisterende filer sitt tidligere klyngeoppsett, så nye spørringer drar ikke nytte av den oppdaterte strategien.
OPTIMIZE FULL tvinger frem en tabellomfattende omklynging. Den klynger alle filer på nytt – inkludert filer som tidligere var klynget med forskjellige nøkler eller en annen leverandør – slik at hele tabellen reflekterer den nyeste klyngestrategien.
Note
OPTIMIZE FULLer tilgjengelig fra og med Fabric Spark runtime 2.0 (Delta 4.2).
Bruk OPTIMIZE FULL når du:
- Endre kolonnene i en væskeklynget tabell.
- Migrer en tabell mellom plattformer eller klyngeleverandører.
OPTIMIZE dbo.table_name FULL
Fordi OPTIMIZE FULL kan omskrive det meste eller hele av en stor tabell, kan det være betydelig dyrere enn en vanlig inkrementell OPTIMIZE. Kjør det bevisst, vanligvis én gang etter at du har endret klyngestrategien, i stedet for som en del av rutinemessig vedlikehold.
Rask optimalisering
Rask optimalisering analyserer Delta-tabellfiler på en intelligent måte og hopper over komprimeringsoperasjoner som sannsynligvis ikke vil forbedre ytelsen på en meningsfull måte.
I stedet for å blindt komprimere filer når det finnes små filer, evaluerer rask optimalisering om hver kandidathylle (gruppe med små filer) oppfyller konfigurerbare komprimeringsmål for beste praksis. Fast Optimize kjører bare komprimering på en hylle med filer hvis sammenslåing av dem sannsynligvis vil nå minimumsmålstørrelsen, eller hvis det er for mange små filer. Ellers hopper den over den gruppen eller reduserer hvor mange filer den komprimerer.
Rask optimalisering kan finjusteres basert på dine komprimeringsforventninger:
| Eiendom | Beskrivelse | Standardverdi | Konfigurasjon av økt |
|---|---|---|---|
| minNumFiler | Antall små filer som må finnes i en hylle for at optimalisering skal utføres hvis hyllen ikke inneholder nok data som er beregnet til å produsere en komprimert fil. | 50 | spark.microsoft.delta.optimize.fast.minNumFiler |
| parkettKoeffisient | Multiplisert med minste filstørrelse for optimalisering av kontekst for å bestemme minimumsmengden små fildata som må finnes i en hylle for at hyllen skal inkluderes i komprimeringsomfanget. | 1.3 | spark.microsoft.delta.optimize.fast.parquetKoeffisient |
Note
Resultatet parquetCoefficient er at målstørrelsen for en hylle er større enn den minste målfilstørrelsen for optimaliseringskonteksten. Denne koeffisienten forklarer realiteten at kombinasjon av flere små parkettfiler resulterer i bedre komprimering, og dermed mindre data enn summen av små filer. Øk verdien for å være mer konservativ i hvor ofte du raskt optimaliserer hopp-bins, eller senk verdien for å tillate mer tillatende bin-hopping.
Slik fungerer det
Rask optimalisering introduserer ekstra kontroller før søppelkasser komprimeres. For hver kandidathylle evaluerer rask optimalisering:
- Den estimerte mengden rådata i hyllen (summen av små filstørrelser)
- Om kombinasjonen av de små filene anslås å produsere en fil som oppfyller den konfigurerte minimumsmålstørrelsen
- Om hyllen inneholder minst det konfigurerte minimumsantallet små filer
Fast Optimize evaluerer hver bin med små filer og komprimerer kun de binene som sannsynligvis vil nå minimumsmålstørrelsen eller overstige minimumsfilantall. Hyller som ikke oppfyller disse tersklene, hoppes over eller komprimeres delvis. Å hoppe over suboptimale hyller reduserer unødvendige omskrivinger, reduserer skriveforsterkning og gjør OPTIMIZE-jobber mer idempotente.
Note
Den nøyaktige implementeringen kan endres over tid.
Rask optimalisering kan redusere omskrevet data over en Delta-tabell livssyklus. Som vist i diagrammet nedenfor, hopper rask optimalisering over suboptimale bins, noe som resulterer i raskere og mer idempotente OPTIMIZE jobber med mindre skriveforsterkning.
Note
Bare for illustrasjonsformål antar diagrammene ovenfor at størrelsen på filen som skrives fra komprimering er summen av størrelsen på små filer. Det innebærer også a parquetCoefficient på 1.
Begrensninger
- Gjelder ikke for væskeklynger og Z-ordreoperasjoner
- Rask optimalisering endrer ikke virkemåten til automatisk komprimering
Komprimeringsmål på filnivå
For å unngå omskriving av data som tidligere ble ansett som komprimerte (store nok) basert på endring av mål for komprimering av min. og maks filstørrelse, spark.microsoft.delta.optimize.fileLevelTarget.enabled kan aktiveres for å forhindre omkomprimering av allerede komprimerte filer. Når den er aktivert, komprimeres ikke filer på nytt hvis de tidligere oppfylte minst halvparten av målfilstørrelsen på komprimeringstidspunktet. Å opprettholde filnivåmål minimerer skriveforsterkning ettersom kompakteringsmålstørrelsen endres over tid (for eksempel fra adaptiv målfilstørrelse, evaluere og sette et større mål). Hvis den er aktivert, legges koden OPTIMIZE_TARGET_SIZE til i nye filer når OPTIMIZE kjøres, eller for en skriveoperasjon hvis egenskapen delta.targetFileSize eller delta.targetFileSize.adaptive table er angitt.
Note
Selv om det ikke er aktivert som standard, anbefaler Microsoft å aktivere komprimeringsmål på filnivå for å begrense potensiell skriveforsterkning.
Automatisk komprimering
Automatisk komprimering evaluerer partisjonstilstanden etter hver skriveoperasjon. Når den oppdager overdreven filfragmentering (for mange små filer) i en partisjon, utløser den en synkron OPTIMIZE operasjon umiddelbart etter at skrivingen er utført. Denne forfatterdrevne tilnærmingen til filvedlikehold er optimal fordi komprimering bare utføres når det er programmatisk fastslått å være fordelaktig.
Aktiver på sesjonsnivå
Satt spark.databricks.delta.autoCompact.enabled på sesjonsnivå for å aktivere automatisk komprimering for nye tabeller opprettet i den Spark-økten:
Aktiver på tabellnivå
Sett tabellegenskap delta.autoOptimize.autoCompact for å aktivere automatisk komprimering for spesifikke tabeller:
CREATE TABLE dbo.table_name
TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Bruk DataFrameWriter-alternativet delta.autoOptimize.autoCompact for å aktivere automatisk komprimering når du oppretter en tabell:
df.write.option('delta.autoOptimize.autoCompact', 'true').saveAsTable('dbo.table_name')
Aktiver samme tabellegenskap på en eksisterende tabell:
ALTER TABLE dbo.table_name
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Reduser evalueringsoverhead
Fra og med Fabric Spark runtime 2.0 (Delta 4.1) kan du aktivere onCheckpointOnly automatisk komprimeringsmodus. Som standard evaluerer automatisk komprimering filmetadata etter hver skriveoperasjon for å avgjøre om en tabell har for mange små filer. Med , utsettes evalueringen til log-sjekkpunktoperasjoner onCheckpointOnly(vanligvis hver 10. commit). Ved sjekkpunktet er tabellbildet allerede fullstendig rekonstruert, så evalueringen leser fra metadata som allerede er i minnet i stedet for å kreve en ekstra skanning. Den utsatte evalueringen reduserer overhead per commit samtidig som tabellene blir komprimert periodisk.