Ta bort oanvända datafiler med vacuum

  • Artikel

Du kan ta bort datafiler som inte längre refereras till av en Delta-tabell som är äldre än kvarhållningströskeln genom att köra VACUUM kommandot i tabellen. Att köra VACUUM regelbundet är viktigt för kostnader och efterlevnad på grund av följande överväganden:

  • Om du tar bort oanvända datafiler minskar kostnaderna för molnlagring.
  • Datafiler som tas bort av VACUUM kan innehålla poster som har ändrats eller tagits bort. Om du tar bort dessa filer permanent från molnlagringen ser du till att dessa poster inte längre är tillgängliga.

Standardtröskelvärdet för kvarhållning för datafiler efter körning VACUUM är 7 dagar. Information om hur du ändrar det här beteendet finns i Konfigurera datakvarhållning för frågor om tidsresor.

Databricks rekommenderar att du använder förutsägelseoptimering för att automatiskt köra VACUUM för Delta-tabeller. Se Förutsägande optimering för Delta Lake.

Vissa Delta Lake-funktioner använder metadatafiler för att markera data som borttagna i stället för att skriva om datafiler. Du kan använda REORG TABLE ... APPLY (PURGE) för att checka in dessa borttagningar och skriva om datafiler. Se Rensa endast metadataborttagningar för att tvinga omskrivning av data.

Viktigt!

  • I Databricks Runtime 13.2 och senare VACUUM skiljer sig semantiken för grunda kloner med hanterade Unity Catalog-tabeller från andra Delta-tabeller. Se Vakuum- och Unity Catalog-grunda kloner.
  • VACUUM tar bort alla filer från kataloger som inte hanteras av Delta Lake och ignorerar kataloger som börjar med _ eller .. Om du lagrar ytterligare metadata som kontrollpunkter för strukturerad direktuppspelning i en Delta-tabellkatalog använder du ett katalognamn som _checkpoints.
  • Möjligheten att köra frågor mot tabellversioner som är äldre än kvarhållningsperioden går förlorad när du har kört VACUUM.
  • Loggfiler tas bort automatiskt och asynkront efter kontrollpunktsåtgärder och styrs inte av VACUUM. Standardkvarhållningsperioden för loggfiler är 30 dagar, men om du kör VACUUM i en tabell tas de datafiler som behövs för tidsresor bort.

Kommentar

När diskcachelagring är aktiverat kan ett kluster innehålla data från Parquet-filer som har tagits bort med VACUUM. Därför kan det vara möjligt att köra frågor mot data från tidigare tabellversioner vars filer har tagits bort. Om du startar om klustret tas cachelagrade data bort. Se Konfigurera diskcachen.

Exempelsyntax för vakuum

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

Information om Spark SQL-syntax finns i VACUUM.

Se Delta Lake API-dokumentationen för Scala-, Java- och Python-syntaxinformation.

Kommentar

Använd nyckelordet RETAIN för att ange det tröskelvärde som används för att avgöra om en datafil ska tas bort. Kommandot VACUUM använder det här tröskelvärdet för att se tillbaka i tiden den angivna tiden och identifiera den senaste tabellversionen just då. Delta behåller alla datafiler som krävs för att köra frågor mot tabellversionen och alla nyare tabellversioner. Den här inställningen interagerar med andra tabellegenskaper. Se Konfigurera datakvarhållning för frågor om tidsresor.

Rensa endast metadataborttagningar för att tvinga omskrivning av data

Kommandot REORG TABLE innehåller syntaxen APPLY (PURGE) för att skriva om data för att tillämpa mjuk borttagning. Mjuk borttagning skriver inte om data eller tar bort datafiler, utan använder metadatafiler för att indikera att vissa datavärden har ändrats. Se REORG-TABELL.

Åtgärder som skapar mjuka borttagningar i Delta Lake omfattar följande:

  • Ta bort kolumner med kolumnmappning aktiverat.
  • Ta bort rader med borttagningsvektorer aktiverade.
  • Alla dataändringar i Photon-aktiverade kluster när borttagningsvektorer är aktiverade.

När mjuk borttagning är aktiverad kan gamla data finnas kvar fysiskt i tabellens aktuella filer även efter att data har tagits bort eller uppdaterats. Utför följande steg för att ta bort dessa data fysiskt från tabellen:

  1. Kör REORG TABLE ... APPLY (PURGE). När du har gjort det finns inte längre gamla data i tabellens aktuella filer, men de finns fortfarande i de äldre filerna som används för tidsresor.
  2. Kör VACUUM för att ta bort dessa äldre filer.

REORG TABLE skapar en ny version av tabellen när åtgärden slutförs. Alla tabellversioner i historiken före den här transaktionen refererar till äldre datafiler. Konceptuellt liknar OPTIMIZE detta kommandot, där datafiler skrivs om även om data i den aktuella tabellversionen förblir konsekventa.

Viktigt!

Datafiler tas bara bort när filerna har upphört att gälla enligt VACUUM kvarhållningsperioden. Det innebär att VACUUM måste göras med en fördröjning efter REORG så att de äldre filerna har upphört att gälla. Kvarhållningsperioden VACUUM för kan minskas för att förkorta den nödvändiga väntetiden, på bekostnad av att minska den maximala historik som behålls.

Vilket storlekskluster behöver vakuum?

Om du vill välja rätt klusterstorlek för VACUUMhjälper det dig att förstå att åtgärden sker i två faser:

  1. Jobbet börjar med att använda alla tillgängliga körnoder för att visa filer i källkatalogen parallellt. Den här listan jämförs med alla filer som för närvarande refereras i Delta-transaktionsloggen för att identifiera filer som ska tas bort. Drivrutinen är inaktiv under den här tiden.
  2. Drivrutinen utfärdar sedan borttagningskommandon för varje fil som ska tas bort. Filborttagning är en endast drivrutinsåtgärd, vilket innebär att alla åtgärder utförs i en enda nod medan arbetsnoderna är inaktiva.

För att optimera kostnader och prestanda rekommenderar Databricks följande, särskilt för långvariga vakuumjobb:

  • Kör vakuum på ett kluster med automatisk skalningsuppsättning för 1–4 arbetare, där varje arbetare har 8 kärnor.
  • Välj en drivrutin med mellan 8 och 32 kärnor. Öka storleken på drivrutinen för att undvika OOM-fel (out-of-memory).

Om VACUUM åtgärder regelbundet tar bort mer än 10 000 filer eller tar över 30 minuters bearbetningstid kanske du vill öka drivrutinens storlek eller antalet arbetare.

Om du upptäcker att fördröjningen inträffar när du identifierar filer som ska tas bort lägger du till fler arbetsnoder. Om fördröjningen inträffar när borttagningskommandona körs kan du försöka öka drivrutinsstorleken.

Hur ofta ska du köra vakuum?

Databricks rekommenderar att du regelbundet kör VACUUM på alla tabeller för att minska kostnaderna för molnbaserad datalagring. Standardtröskelvärdet för kvarhållning för vakuum är 7 dagar. Om du anger ett högre tröskelvärde får du tillgång till en större historik för tabellen, men ökar antalet lagrade datafiler och medför därmed större lagringskostnader från molnleverantören.

Varför kan du inte dammsuga en Delta-tabell med ett lågt tröskelvärde för kvarhållning?

Varning

Vi rekommenderar att du anger ett kvarhållningsintervall på minst 7 dagar, eftersom gamla ögonblicksbilder och ogenomförda filer fortfarande kan användas av samtidiga läsare eller skrivare i tabellen. Om VACUUM du rensar aktiva filer kan samtidiga läsare misslyckas eller ännu värre, tabeller kan skadas när VACUUM filer som ännu inte har checkats in tas bort. Du måste välja ett intervall som är längre än den längsta samtidiga transaktionen som körs och den längsta perioden som någon ström kan släpa efter den senaste uppdateringen av tabellen.

Delta Lake har en säkerhetskontroll för att förhindra att du kör ett farligt VACUUM kommando. Om du är säker på att det inte utförs några åtgärder i den här tabellen som tar längre tid än det kvarhållningsintervall som du planerar att ange, kan du inaktivera den här säkerhetskontrollen genom att ställa in spark-konfigurationsegenskapen spark.databricks.delta.retentionDurationCheck.enabled på false.

Granskningsinformation

VACUUM incheckningar till Delta-transaktionsloggen innehåller granskningsinformation. Du kan köra frågor mot granskningshändelserna med hjälp av DESCRIBE HISTORY.