Ongebruikte gegevensbestanden verwijderen met vacuum
U kunt gegevensbestanden verwijderen waarnaar niet meer wordt verwezen door een Delta-tabel die ouder is dan de drempelwaarde voor bewaren 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.
De standaardretentiedrempel voor gegevensbestanden na uitvoering VACUUM
is 7 dagen. Zie Gegevensretentie configureren voor query's voor tijdreizen om dit gedrag te wijzigen.
Databricks raadt aan om voorspellende optimalisatie te gebruiken om automatisch te worden uitgevoerd VACUUM
voor Delta-tabellen. Zie Voorspellende optimalisatie voor Delta Lake.
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
verschillen semantiek voor ondiepe klonen met beheerde Unity Catalog-tabellen van andere Delta-tabellen. Bekijk ondiepe kloonnen van Vacuum en Unity Catalog. VACUUM
verwijdert alle bestanden uit mappen die niet worden beheerd door Delta Lake, waarbij mappen worden genegeerd die beginnen met_
of.
. Als u aanvullende metagegevens zoals Structured Streaming-controlepunten opslaat in een Delta-tabelmap, gebruikt u een mapnaam zoals_checkpoints
.- Gegevens voor wijzigingsgegevensfeed worden beheerd door Delta Lake in de
_change_data
map en verwijderd metVACUUM
. Zie Delta Lake-wijzigingsgegevensfeed gebruiken in Azure Databricks. - Bloeifilterindexen maken gebruik van de
_delta_index
map die wordt beheerd door Delta Lake.VACUUM
Hiermee worden bestanden in deze map opgeschoond. Zie Bloom-filterindexen.
- Gegevens voor wijzigingsgegevensfeed worden beheerd door Delta Lake in de
- De mogelijkheid om een query uit te voeren op tabelversies die ouder zijn dan de bewaarperiode, gaat verloren nadat deze is uitgevoerd
VACUUM
. - Logboekbestanden worden automatisch en asynchroon verwijderd na controlepuntbewerkingen en vallen niet onder
VACUUM
. Hoewel de standaardretentieperiode van logboekbestanden 30 dagen is,VACUUM
worden 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 eventsTable -- vacuum files not required by versions older than the default retention period
VACUUM '/data/events' -- vacuum files in path-based table
VACUUM delta.`/data/events/`
VACUUM delta.`/data/events/` RETAIN 100 HOURS -- vacuum files not required by versions more than 100 hours old
VACUUM eventsTable DRY RUN -- do dry run to get the list of files to be deleted
Zie VACUUM voor details van de 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 VACUUM
opdracht gebruikt deze drempelwaarde om terug te kijken naar de opgegeven tijdsduur en om 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.
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 waarvoor kolomtoewijzing is 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:
- 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. - 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 OPTIMIZE
opdracht, 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 wilt VACUUM
selecteren, is het handig om te begrijpen dat de bewerking in twee fasen plaatsvindt:
- 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.
- 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 vacuüm uit op een cluster met een set voor automatisch schalen voor 1-4 werkrollen, waarbij elke werkrol 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 regelmatig aan om alle tabellen uit te voeren VACUUM
om de overtollige cloudkosten voor gegevensopslag te verminderen. 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 worden opgeschoond, kunnen gelijktijdige lezers mislukken of slechter, kunnen tabellen beschadigd raken wanneer VACUUM
bestanden worden verwijderd die nog niet zijn doorgevoerd. U moet een interval kiezen die langer is dan de langst durende gelijktijdige transactie en de langste periode dat een 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 spark.databricks.delta.retentionDurationCheck.enabled
in te stellen op false
.
Controlegegevens
VACUUM
doorvoeringen in het Delta-transactielogboek bevatten controlegegevens. U kunt query's uitvoeren op de controlegebeurtenissen met behulp van DESCRIBE HISTORY
.