Delen via

Ongebruikte gegevensbestanden verwijderen met vacuüm

Voorspellende optimalisatie voert automatisch VACUUM uit op beheerde tabellen van Unity Catalog. Databricks raadt aan voorspellende optimalisaties in te schakelen voor alle beheerde Tabellen in Unity Catalog om het onderhoud van gegevens te vereenvoudigen en de opslagkosten te verlagen. Zie Voorspellende optimalisatie voor beheerde tabellen in Unity Catalog.

Verwijder gegevensbestanden waarnaar niet meer wordt verwezen door een tabel die ouder is dan de bewaardrempel door de VACUUM opdracht in de tabel uit te voeren. Regelmatig uitvoeren VACUUM is belangrijk voor kosten en naleving vanwege de volgende overwegingen:

  • Het verwijderen van ongebruikte gegevensbestanden vermindert de kosten voor cloudopslag.
  • Gegevensbestanden die zijn verwijderd door VACUUM , kunnen records bevatten die zijn gewijzigd of verwijderd. Als u deze bestanden permanent verwijdert uit de cloudopslag, zorgt u ervoor dat deze records niet meer toegankelijk zijn.

Kanttekeningen voor vacuüm

De standaardretentiedrempel voor gegevensbestanden na uitvoering VACUUM is 7 dagen. Zie Gegevensretentie configureren voor query's voor tijdreizen om dit gedrag te wijzigen.

VACUUM kan lege mappen achterblijven nadat alle bestanden erin zijn verwijderd. Volgende VACUUM bewerkingen verwijderen deze lege mappen.

Databricks raadt aan voorspellende optimalisatie te gebruiken om VACUUM automatisch voor tabellen uit te voeren. Zie Voorspellende optimalisatie voor beheerde tabellen in Unity Catalog.

Sommige tabelfuncties gebruiken metagegevensbestanden om gegevens te markeren als verwijderd in plaats van gegevensbestanden opnieuw te schrijven. Gebruik REORG TABLE ... APPLY (PURGE) dit om deze verwijderingen vast te leggen en gegevensbestanden opnieuw te schrijven. Zie Alleen verwijderen van metagegevens opschonen om het herschrijven van gegevens af te dwingen.

Belangrijk

  • In Databricks Runtime 13.3 LTS en hoger VACUUM verschillen semantiek voor ondiepe klonen met beheerde Unity Catalog-tabellen van andere tabellen. Zie Vacuum en Unity Catalog ondiepe klonen.
  • VACUUM verwijdert alle bestanden uit mappen die niet worden beheerd door Azure Databricks, waarbij directory's worden genegeerd die beginnen met _ of .. Als u extra metagegevens, zoals Structured Streaming-controlepunten in een tabelmap, opslaat, gebruikt u een mapnaam zoals _checkpoints.
  • De mogelijkheid om een query uit te voeren op tabelversies die ouder zijn dan de bewaarperiode, gaat verloren nadat VACUUMis uitgevoerd.
  • Logboekbestanden worden automatisch en asynchroon verwijderd na controlepuntbewerkingen en vallen niet onder VACUUM. Hoewel de standaardretentieperiode van logboekbestanden 30 dagen is, worden met VACUUM in een tabel de gegevensbestanden verwijderd die nodig zijn voor tijdreizen.

Notitie

Wanneer schijfcaching is ingeschakeld, kan een cluster gegevens bevatten uit Parquet-bestanden die zijn verwijderd met VACUUM. Daarom is het mogelijk om query's uit te voeren op de gegevens van eerdere tabelversies waarvan de bestanden zijn verwijderd. Als u het cluster opnieuw opstart, worden de gegevens in de cache verwijderd. Zie De schijfcache configureren.

Voorbeeldsyntaxis voor vacuüm

VACUUM table_name   -- vacuum files not required by versions older than the default retention period

VACUUM table_name DRY RUN    -- do dry run to get the list of files to be deleted

Zie VACUUMvoor details van spark SQL-syntaxis.

Zie de Documentatie voor de Delta Lake-API voor de syntaxis van Scala, Java en Python.

Notitie

Gebruik in Databricks Runtime 18.0 en hoger de tabeleigenschap om de deletedFileRetentionDuration retentie te beheren. Voor beheerde tabellen van Unity Catalog is dit van toepassing op Databricks Runtime 12.2 en hoger.

Zie Gegevensretentie configureren voor query's voor tijdreizen.

Volledige versus lichte modus

Belangrijk

Deze functie bevindt zich in openbare preview in Databricks Runtime 16.1 en hoger.

U kunt het LITE trefwoord opgeven in uw vacuüminstructie om een alternatve-modus van VACUUM te activeren, waardoor niet alle bestanden in de tabelmap worden weergegeven.

LITE in de modus wordt het transactielogboek gebruikt om gegevensbestanden te identificeren die zich niet meer binnen de VACUUM retentiedrempel bevinden en worden deze gegevensbestanden uit de tabel verwijderd. LITE-modus is met name handig voor grote tabellen waarvoor frequente VACUUM bewerkingen nodig zijn, omdat niet alle bestanden moeten worden vermeld om deze gegevensbestanden te identificeren die moeten worden verwijderd.

Notitie

Als u VACUUM uitvoert in LITE modus, worden geen bestanden verwijderd waarnaar niet in het transactielogboek wordt verwezen. Bijvoorbeeld bestanden die zijn gemaakt door een afgebroken transactie.

Gebruik de volgende syntaxis voor VACUUM in de modus LITE:

VACUUM table_name LITE

LITE modus heeft de volgende vereiste:

  • U moet ten minste één geslaagde VACUUM bewerking hebben uitgevoerd binnen de geconfigureerde bewaardrempel voor transactielogboeken (standaard 30 dagen).

Als niet aan deze vereiste wordt voldaan, wordt het volgende foutbericht weergegeven wanneer u probeert uit te voeren VACUUM in LITE de modus. Als u wilt doorgaan, moet u VACUUM uitvoeren in FULL modus.

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the log. Please run VACUUM FULL.

FULL is de standaardmodus voor vacuüm. U kunt de volledige modus expliciet uitvoeren met de volgende opdracht:

VACUUM table_name FULL

Zie VACUUM.

Verwijderen van metagegevens die alleen worden verwijderd om het herschrijven van gegevens af te dwingen

De REORG TABLE opdracht biedt de syntaxis voor het APPLY (PURGE) herschrijven van gegevens om voorlopig verwijderen toe te passen. Met voorlopig verwijderen worden geen gegevens herschreven of gegevensbestanden verwijderd, maar worden metagegevensbestanden gebruikt om aan te geven dat sommige gegevenswaarden zijn gewijzigd. Zie REORG TABLE.

Bewerkingen die zachte verwijderingen uitvoeren, zijn de volgende:

  • Kolommen verwijderen met kolomtoewijzing ingeschakeld.
  • Alle gegevenswijzigingen waarvoor verwijderingsvectoren zijn ingeschakeld.

Als voorlopig verwijderen is ingeschakeld, blijven oude gegevens mogelijk fysiek aanwezig in de huidige bestanden van de tabel, zelfs nadat de gegevens zijn verwijderd of bijgewerkt. Voer de volgende stappen uit om deze gegevens fysiek uit de tabel te verwijderen:

  1. Voer REORG TABLE ... APPLY (PURGE) uit. Hierna zijn de oude gegevens niet meer aanwezig in de huidige bestanden van de tabel, maar deze zijn nog steeds aanwezig in de oudere bestanden die worden gebruikt voor tijdreizen.
  2. Voer uit VACUUM om deze oudere bestanden te verwijderen.

REORG TABLE maakt een nieuwe versie van de tabel wanneer de bewerking is voltooid. Alle tabelversies in de geschiedenis vóór deze transactie verwijzen naar oudere gegevensbestanden. Conceptueel gezien is dit vergelijkbaar met de opdracht OPTIMIZE, waarbij gegevensbestanden opnieuw worden geschreven, ook al blijven gegevens in de huidige tabelversie consistent.

Belangrijk

Gegevensbestanden worden alleen verwijderd wanneer de bestanden zijn verlopen volgens de VACUUM bewaarperiode. Dit betekent dat het VACUUM moet worden gedaan met een vertraging nadat de REORG oudere bestanden zijn verlopen. De bewaarperiode kan worden beperkt tot het verkorten van VACUUM de vereiste wachttijd, ten koste van het verminderen van de maximale geschiedenis die wordt bewaard.

Welke grootte cluster heeft vacuüm nodig?

Als u de juiste clustergrootte voor VACUUMwilt selecteren, is het handig om te begrijpen dat de bewerking in twee fasen plaatsvindt:

  1. De taak begint met het gebruik van alle beschikbare uitvoerknooppunten om bestanden in de bronmap parallel weer te geven. Deze lijst wordt vergeleken met alle bestanden waarnaar momenteel wordt verwezen in het transactielogboek om bestanden te identificeren die moeten worden verwijderd. De bestuurder zit inactief gedurende deze tijd.
  2. Het stuurprogramma geeft vervolgens verwijderingsopdrachten uit voor elk bestand dat moet worden verwijderd. Het verwijderen van bestanden is een bewerking die alleen voor stuurprogramma's geldt, wat betekent dat alle bewerkingen plaatsvinden in één knooppunt terwijl de werkrolknooppunten inactief zijn.

Om kosten en prestaties te optimaliseren, raadt Databricks het volgende aan, met name voor langdurige vacuümtaken:

  • Voer de vacuumfunctie uit op een cluster met auto-scaling ingesteld op 1-4 werknodes, waarbij elke werknode 8 kernen heeft.
  • Selecteer een stuurprogramma met tussen 8 en 32 kernen. Vergroot de grootte van het stuurprogramma om geheugenfouten (OOM) te voorkomen.

Als VACUUM bewerkingen regelmatig meer dan 10 duizend bestanden verwijderen of meer dan 30 minuten verwerkingstijd in beslag nemen, kunt u de grootte van het stuurprogramma of het aantal werknemers verhogen.

Als u merkt dat de vertraging optreedt tijdens het identificeren van bestanden die moeten worden verwijderd, voegt u meer werkknooppunten toe. Als de vertraging optreedt tijdens het uitvoeren van verwijderopdrachten, kunt u proberen de grootte van het stuurprogramma te vergroten.

Hoe vaak moet u vacuüm uitvoeren?

Databricks raadt aan regelmatig VACUUM uit te voeren op alle tabellen om overtollige cloudgegevensopslagkosten te verlagen. De standaardretentiedrempel voor vacuüm is 7 dagen. Als u een hogere drempelwaarde instelt, krijgt u toegang tot een grotere geschiedenis voor uw tabel, maar wordt het aantal opgeslagen gegevensbestanden verhoogd en worden hierdoor meer opslagkosten van uw cloudprovider in rekening gebracht.

Waarom kunt u een tabel met een lage retentiedrempel niet leegmaken?

Waarschuwing

Het is raadzaam om een bewaarinterval in te stellen op ten minste 7 dagen, omdat oude momentopnamen en niet-verzonden bestanden nog steeds in gebruik kunnen zijn door gelijktijdige lezers of schrijvers aan de tabel. Als VACUUM actieve bestanden opschoont, kunnen gelijktijdige lezers mislukken of, erger, tabellen beschadigd raken wanneer VACUUM bestanden verwijdert die nog niet zijn doorgevoerd. U moet een interval kiezen dat langer is dan de langstlopende gelijktijdige transactie en de langste periode die elke stream achter kan blijven bij de meest recente update van de tabel.

Er is een veiligheidscontrole om te voorkomen dat u een gevaarlijke VACUUM opdracht uitvoert. Als u zeker weet dat er geen bewerkingen worden uitgevoerd in deze tabel die langer duren dan het retentieinterval dat u wilt opgeven, schakelt u deze veiligheidscontrole uit door de Spark-configuratie-eigenschap spark.databricks.delta.retentionDurationCheck.enabled (Delta) of spark.databricks.iceberg.retentionDurationCheck.enabled (Iceberg) in te stellen op false.

Controlegegevens

VACUUM commits in het transactielogboek bevatten auditinformatie. Voer een query uit op de controlegebeurtenissen met behulp van DESCRIBE HISTORY.

  • Last updated on