Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Ligesom filsystemer og relationsdatabaser bliver data fragmenteret over tid, medmindre de administreres nøje, hvilket fører til for store beregningsomkostninger til at læse dataene. Delta Lake er ikke en undtagelse. Datafiler bør med jævne mellemrum omskrives til et optimalt layout for at reducere individuelle fildriftsomkostninger, forbedre datakomprimering og optimere læserparallelitet. Kommandoen OPTIMIZE løser denne udfordring: den grupperer små filer i en partition i beholdere, der er rettet mod en ideel filstørrelse og omskriver dem til lager. Resultatet er de samme data komprimeret til færre filer.
Komprimeringsmetoder
Microsoft Fabric tilbyder flere metoder til at opretholde optimale filstørrelser i Delta-tabeller:
OPTIMIZE kommando
Kommandoen OPTIMIZE er den grundlæggende handling til at komprimere Delta-tabeller. Den omskriver små filer til større filer for at forbedre datalayoutet i Delta-tabeller.
| Egenskab | Beskrivelse | Standardværdi | Konfiguration af session |
|---|---|---|---|
| minFileSize | Filer, der er mindre end denne grænse, grupperes sammen og omskrives som større filer. | 1073741824 (1 g) | spark.databricks.delta.optimize.minFileSize |
| maxFileSize | Målfilstørrelse produceret af kommandoen OPTIMIZE . |
1073741824 (1g) | spark.databricks.delta.optimize.maxFileSize |
Vigtigt!
Mens OPTIMIZE er en idempotent handling (hvilket betyder, at hvis du kører den to gange i træk, omskrives ingen data), kan brug af en minFileSize , der er for stor i forhold til Delta-tabelstørrelsen, medføre skriveforstærkning, hvilket gør handlingen mere beregningsmæssigt dyrere end nødvendigt. Hvis du minFileSize f.eks. er indstillet til 1 GB, og du har en fil på 900 MB i tabellen, omskrives filen på 900 MB i en rimelig størrelse, når den køres, OPTIMIZE efter at du har skrevet en lille fil på 1 KB til tabellen. Du kan finde en vejledning i, hvordan du automatisk administrerer filstørrelsen, i dokumentationen til adaptiv destinationsfilstørrelse .
OPTIMIZE med Z-Order
Når delsætningen er angivet ZORDER BY , omskrives alle aktive filer, OPTIMIZE så rækker med lignende værdier for z-orden-kolonnerne placeres i de samme filer, hvilket forbedrer effektiviteten af filspring for forespørgsler, der filtrerer på disse kolonner. Brug Z-Order, når:
- Dine forespørgsler filtrerer ofte på to eller flere kolonner sammen (f.eks. dato + customer_id), og
- Disse prædikater er selektive nok til, at spring på filniveau reducerer antallet af scannede filer.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2)
OPTIMIZE med V-Order
Klausulen VORDER resulterer i, at de filer, der er begrænset til komprimering, får V-Order-optimeringen anvendt. For mere information om V-Order, se den detaljerede dokumentation.
OPTIMIZE dbo.table_name VORDER
OPTIMIZE med væskeklynger
Væskeklynger er angivet som en tabelindstilling; Se Aktivér væskeklynger for at få flere oplysninger. Når flydende klynger er aktiveret, udføres den fysiske omskrivning, OPTIMIZE der anvender klyngepolitikken.
Vigtigt!
Data grupperes kun, når OPTIMIZE de køres på flydende grupperede aktiverede tabeller. Regelmæssige skrivehandlinger grupperer IKKE dataene. Det er vigtigt at have en komprimeringsstrategi, f.eks. ved hjælp af automatisk komprimering eller manuel planlægning af optimeringsjob, for at sikre, at fordelene ved klyngedata (dvs. forbedret Delta-filspring) kan realiseres.
Hurtig optimering
Hurtig optimering analyserer intelligent Delta-tabelfiler og springer komprimeringshandlinger over, der sandsynligvis ikke vil forbedre ydeevnen meningsfuldt.
I stedet for blindt at komprimere filer, når der findes små filer, evaluerer Fast Optimize, om hver kandidatbeholder (gruppe af små filer) opfylder konfigurerbare mål for komprimering af bedste praksis. Fast Optimize kører kun komprimering på en bakke med filer, hvis det er sandsynligt, at fletning af dem vil nå din mindste målstørrelse, eller hvis der er for mange små filer. Ellers springer den gruppen over eller reducerer, hvor mange filer den komprimerer.
Hurtig optimering kan finjusteres baseret på dine komprimeringsforventninger:
| Egenskab | Beskrivelse | Standardværdi | Konfiguration af session |
|---|---|---|---|
| minNumFiles | Antallet af små filer, der skal findes i en placering, for at optimering kan udføres, hvis placeringen ikke indeholder nok data, der er estimeret til at producere en komprimeret fil. | 50 | spark.microsoft.delta.optimize.fast.minNumFiler |
| parketKoefficient | Ganget med den mindste filstørrelse for optimering af kontekst for at bestemme den mindste mængde små fildata, der skal findes i en placering, for at placeringen kan medtages i komprimeringsomfanget. | 1.3 | spark.microsoft.delta.optimize.fast.parquetCoefficient |
Notat
Resultatet parquetCoefficient er, at målstørrelsen for en placering er større end den mindste målfilstørrelse for optimeringskonteksten. Denne koefficient tager højde for den virkelighed, at kombination af flere små parketfiler resulterer i bedre komprimering og dermed færre data end summen af små filer. Denne værdi kan øges for at være mere konservativ med hensyn til, hvor ofte hurtig optimering springer placeringer over, eller reduceres for at tillade mere tilladt overspringning af placeringer.
Sådan fungerer det
Hurtig optimering introducerer ekstra kontroller, før skraldespande komprimeres. For hver kandidatbeholder evaluerer hurtig optimering:
- Den anslåede mængde rådata i placeringen (summen af små filstørrelser)
- Om kombinationen af de små filer anslås at producere en fil, der opfylder den konfigurerede minimumsmålstørrelse
- Om placeringen mindst indeholder det konfigurerede mindste antal små filer
Hurtig optimering evaluerer hver placering med små filer og komprimerer kun de små filer, der sandsynligvis vil nå den mindste destinationsstørrelse eller overskride det mindste antal filer. Placeringer, der ikke opfylder disse tærskler, springes over eller komprimeres delvist. Hvis du springer suboptimale placeringer over, reduceres unødvendige omskrivninger, skriveforstærkning sænkes og OPTIMER-job bliver mere idempotente.
Notat
Den nøjagtige implementering kan udvikle sig over tid.
Hurtig optimering kan resultere i, at færre data omskrives i løbet af en Delta-tabels livscyklus. Som illustreret i følgende diagram, springer hurtig optimering over komprimering af suboptimale beholdere. Nettoresultatet er hurtigere og mere idempotente OPTIMIZE job og mindre skriveforstærkning.
Notat
Kun til illustrationsformål antager ovenstående diagrammer, at størrelsen af filen skrevet fra komprimering er summen af størrelsen af små filer. Det indebærer også a parquetCoefficient på 1.
Begrænsninger
- Gælder ikke for væskeklynger og Z-Order-operationer
- Hurtig optimering ændrer ikke funktionsmåden for automatisk komprimering
Komprimeringsmål på filniveau
For at undgå omskrivning af data, der tidligere blev betragtet som komprimerede (store nok) baseret på ændring af mål for komprimering af min. og maks. filstørrelse, spark.microsoft.delta.optimize.fileLevelTarget.enabled kan aktiveres for at forhindre omkomprimering af allerede komprimerede filer. Når den er aktiveret, komprimeres filer ikke, hvis de tidligere har opfyldt mindst halvdelen af målfilstørrelsen på komprimeringstidspunktet. Vedligeholdelse af mål på filniveau minimerer skriveforstærkning, da størrelsen på komprimeringsmålet ændres over tid (f.eks. fra adaptiv målfilstørrelse, der evaluerer og angiver et større mål). Hvis den er aktiveret, føjes OPTIMIZE_TARGET_SIZE koden til nye filer, når OPTIMIZE køres, eller til en skrivehandling, hvis egenskaben delta.targetFileSize eller delta.targetFileSize.adaptive tabel er angivet.
Notat
Selvom det ikke er aktiveret som standard, anbefaler Microsoft, at du aktiverer komprimeringsmål på filniveau for at begrænse potentiel skriveforstærkning.
Automatisk komprimering
Automatisk komprimering evaluerer partitionstilstanden efter hver skrivehandling. Når den registrerer overdreven filfragmentering (for mange små filer) i en partition, udløser den en synkron OPTIMIZE handling umiddelbart efter, at skrivningen er begået. Denne forfatterdrevne tilgang til filvedligeholdelse er optimal, fordi komprimering kun udføres, når det er programmatisk bestemt at være gavnligt.
Indstil på sessionsniveau for at aktivere automatisk komprimering på nye tabeller:
Angiv på tabelniveau til kun at aktivere for udvalgte tabeller:
CREATE TABLE dbo.table_name
TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Brug indstillingen DataFrameWriter til at aktivere nye tabeller:
df.write.option('delta.autoOptimize.autoCompact', 'true').saveAsTable('dbo.table_name')
Aktivér på eksisterende tabeller:
ALTER TABLE dbo.table_name
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Funktionsmåden for automatisk komprimering kan justeres via følgende Spark-sessionskonfigurationer:
| Egenskab | Beskrivelse | Standardværdi | Konfiguration af session |
|---|---|---|---|
| maxFileSize | Den maksimale målfilstørrelse i bytes for komprimerede filer. | 134217728b (128 MB) | spark.databricks.delta.autoCompact.maxFileSize |
| minFileSize | Den mindste filstørrelse i byte for en fil, der kan betragtes som komprimeret. Alt under denne tærskel tages i betragtning til komprimering og tælles med i tærsklen minNumFiles . |
Frakoblet som standard, beregnet som 1/2 af værdien maxFileSize , medmindre du eksplicit angiver en værdi. |
spark.databricks.delta.autoCompact.minFileSize |
| minNumFiles | Det mindste antal filer, der skal eksistere under tærsklen minFileSize for, at automatisk komprimering kan udløses. |
50 | spark.databricks.delta.autoCompact.minNumFiles |
Notat
Microsoft anbefaler, at du bruger automatisk komprimering i stedet for at planlægge OPTIMIZE job. Automatisk komprimering klarer sig generelt bedre end planlagte komprimeringsjob ved at maksimere læse-/skriveydeevnen og eliminerer ofte vedligeholdelsesomkostningerne ved kodning, planlægning og optimering af hyppigheden af kørsel af planlagte job. Automatisk komprimering anbefales, når mål på databehandlingstjenesteniveau tolererer, at den ekstra ventetid fra automatisk komprimering udløses, når der er behov for komprimering. Hvis kravene til dataventetid er strenge, kan det være mere effektivt at planlægge optimering til at køre på en separat Spark-pulje, så skrivehandlinger ikke oplever periodiske spidser på grund af de synkrone komprimeringshandlinger, der udløses.
Vigtigt!
Selv om komprimering er en kritisk strategi at anvende, bør den også parres på passende vis med at undgå at skrive små filer via funktioner som optimering af skrivning. Du kan finde flere oplysninger i vejledningen om optimering af skrivning.
Vedligeholdelse af lakehouse-bord
Brugere kan køre ad hoc-vedligeholdelsesoperationer som OPTIMIZE fra Lakehouse-brugergrænsefladen. For mere information, se vedligeholdelse af lakehouse-borde.
Oversigt over bedste praksis
-
Aktivér automatisk komprimering for indtagelsespipelines med hyppige små skrivninger (streaming eller mikrobatch) for at undgå manuel planlægning og holde filer komprimeret automatisk.
- For andre skrivemønstre kan det være en fordel at aktivere som en forsikring mod akkumulering af små filer, men afvej, om dine mål for databehandlingsserviceniveau tolererer periodiske spidser i behandlingstiden.
- Planlæg handlinger i fuld tabel
OPTIMIZEi stille vinduer , når du har brug for at omskrive mange partitioner eller køre Z-Order. - Aktivér hurtig optimering for at reducere skriveforstærkning og gøre
OPTIMIZEmere idempotent. - Aktivér komprimeringsmål på filniveau for at forhindre skriveforstærkning, efterhånden som tabeller vokser i størrelse og bruger større målfilstørrelser.
- Husk, at komprimering før skrivning (optimer skrivning) er billigere end komprimering efter skrivning (optimering). Se optimere skrivedokumentation for at få bedste fremgangsmåder.