Delen via

Ongebruikte gegevensbestanden verwijderen met vacuüm

  • Artikel

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 van Unity Catalog.

U kunt gegevensbestanden verwijderen waarnaar niet meer wordt verwezen door een Delta-tabel die ouder is dan de drempelwaarde voor bewaren door de opdracht VACUUM 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 automatisch VACUUM uit te voeren voor Delta-tabellen. Zie Voorspellende optimalisatie voor beheerde tabellen van Unity Catalog.

Sommige Delta Lake-functies gebruiken metagegevensbestanden om gegevens te markeren als verwijderd in plaats van gegevensbestanden te herschrijven. U kunt REORG TABLE ... APPLY (PURGE) deze verwijderingen doorvoeren en gegevensbestanden herschrijven. Zie Alleen verwijderen van metagegevens opschonen om het herschrijven van gegevens af te dwingen.

Belangrijk

  • In Databricks Runtime 13.3 LTS en hoger VACUUM semantiek voor ondiepe klonen met beheerde tabellen van Unity Catalog verschillen van andere Delta-tabellen. Zie Vacuum en Unity Catalog ondiepe klonen.
  • VACUUM verwijdert alle bestanden uit mappen die niet worden beheerd door Delta Lake, waarbij mappen worden genegeerd die beginnen met _ of .. Als u extra metagegevens zoals Structured Streaming-controlepunten opslaat in een Delta-tabelmap, 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 RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

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 het RETAIN trefwoord om de drempelwaarde op te geven die wordt gebruikt om te bepalen of een gegevensbestand moet worden verwijderd. De opdracht VACUUM gebruikt deze drempelwaarde om terug te kijken naar de opgegeven tijdsduur en de meest recente tabelversie op dat moment te identificeren. Delta behoudt alle gegevensbestanden die nodig zijn om een query uit te voeren op die tabelversie en alle nieuwere tabelversies. Deze instelling communiceert met andere tabeleigenschappen. 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 modus maakt gebruik van het Delta-transactielogboek 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 VACUUM uit te voeren in LITE 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 Delta 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 voorlopig verwijderen maken in Delta Lake zijn onder andere:

  • Kolommen verwijderen met kolomtoewijzing ingeschakeld.
  • Rijen verwijderen waarvoor verwijderingsvectoren zijn ingeschakeld.
  • Alle gegevenswijzigingen in clusters met Photon-functionaliteit wanneer 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 Delta-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 een vacuum uit op een cluster met automatisch schalen ingesteld voor 1-4 processen, waarbij elk proces 8 processorcores 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 Delta-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.

Delta Lake heeft 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, kunt u deze veiligheidscontrole uitschakelen door de Spark-configuratie-eigenschap in te stellen spark.databricks.delta.retentionDurationCheck.enabled op false.

Controlegegevens

VACUUM doorvoeringen in het Delta-transactielogboek bevatten controlegegevens. U kunt query's uitvoeren op de controlegebeurtenissen met behulp van DESCRIBE HISTORY.