Ta bort oanvända datafiler med vacuum

Ta bort datafiler som inte längre refereras av en 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.

På tabeller med Iceberg-läsningar aktiverade VACUUM rensar även Iceberg-metadata för äldre tabellversioner. Se VACUUM och rensning av Iceberg-metadata.

Förutsägande optimering körs VACUUM automatiskt på hanterade Unity Catalog-tabeller. Databricks rekommenderar att du aktiverar förutsägande optimeringar för alla hanterade Unity Catalog-tabeller för att förenkla dataunderhållet och minska lagringskostnaderna. Se Förutsägande optimering för hanterade Unity Catalog-tabeller.

Varningar för vakuum

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.

VACUUM kan lämna kvar tomma kataloger efter att alla filer har tagits bort från dem. Efterföljande VACUUM åtgärder tar bort dessa tomma kataloger.

Vissa tabellfunktioner, till exempel borttagningsvektorer, använder metadatafiler för att markera data som borttagna i stället för att skriva om datafiler. Använd REORG TABLE ... APPLY (PURGE) för att bekräfta dessa borttagningar och skriva över datafiler. Se Rensa endast metadata för att tvinga omskrivning av data.

Exempelsyntax för vakuum

Om du vill ta bort filer som inte längre krävs av versioner som är äldre än standardkvarhållningsperioden kör du VACUUM utan ytterligare konfigurationer:

VACUUM table_name

Om du vill förhandsgranska listan över filer som ska tas bort utan att ta bort dem kör du VACUUM med DRY RUN:

VACUUM table_name DRY RUN

Information om Spark SQL-syntax finns i VACUUM.

Information om Scala, Java och Python syntax finns i Delta Lake API-dokumentationen.

Full vs. lite-läge

För att förbättra prestanda och minska kostnaderna genom att undvika att visa alla filer i tabellkatalogen anger du nyckelordet LITE i vakuumuttrycket för att utlösa ett alternativt läge för VACUUM. Detta är användbart för stora tabeller som kräver frekventa VACUUM åtgärder.

LITE i läget används transaktionsloggen för att identifiera datafiler som inte längre ligger inom VACUUM kvarhållningströskeln och tar bort dessa datafiler från tabellen.

Använd följande syntax för att VACUUM i LITE-läget:

VACUUM table_name LITE

FULL läge är standard för vakuum. Du kan uttryckligen köra fullständigt läge med följande kommando:

VACUUM table_name FULL

Se även VACUUM.

Requirements

LITE läge har följande krav:

• Du måste ha kört minst en lyckad VACUUM åtgärd inom det konfigurerade tröskelvärdet för kvarhållning av transaktionsloggar (30 dagar som standard).

Om det här kravet inte uppfylls visas följande felmeddelande när du försöker köra VACUUM i LITE läge. Om du vill fortsätta måste du köra VACUUM i FULL läge.

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

Rensa endast metadataborttagningar för att tvinga omskrivning av data

Med REORG TABLE kommandot med syntaxen APPLY (PURGE) kan du skriva om data för att tillämpa mjuka borttagningar. 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 även REORG TABLE.

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

• Ta bort kolumner med kolumnmappning aktiverat.
• Alla dataändringar med borttagningsvektorer 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.

Rekommendationer för klusterstorlek för vakuum

Om du vill välja rätt klusterstorlek för VACUUMbör du tänka på 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. Jobbet jämför den här listan med alla filer som för närvarande refereras i transaktionsloggen för att identifiera filer för borttagning. Drivrutinen är inaktiv under den här tiden.
2. Drivrutinen utfärdar borttagningskommandon för varje fil som identifieras för borttagning. Eftersom filborttagning är en åtgärd endast för drivrutiner sker alla åtgärder 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å minnet för att undvika out-of-memory-fel (OOM-fel).

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.

Rekommenderad vakuumfrekvens

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 ökar därmed lagringskostnaderna från molnleverantören.

Tröskelvärden för vakuum och låg kvarhållning

Det finns en säkerhetskontroll som förhindrar att du kör ett farligt VACUUM kommando. Om du är säker på att det inte finns några åtgärder som körs i den här tabellen som tar längre tid än det kvarhållningsintervall som du planerar att ange inaktiverar du den här säkerhetskontrollen genom att ställa in retentionDurationCheck Spark-konfigurationen på false:

Delta

SET spark.databricks.delta.retentionDurationCheck.enabled = false

Iceberg

SET spark.databricks.iceberg.retentionDurationCheck.enabled = false

Granskningsinformation

VACUUM infogar granskningsinformation i transaktionsloggen. Sök granskningshändelserna med hjälp av DESCRIBE HISTORY.

Som standard är granskningsloggning aktiverat på alla plattformar för hanterade Unity Catalog-tabeller. Kontrollera loggning av vakuumgranskning med Spark-konfigurationen vacuum.logging :

Delta

SET spark.databricks.delta.vacuum.logging.enabled = true

Iceberg

SET spark.databricks.iceberg.vacuum.logging.enabled = true

Om du vill tillämpa den här konfigurationen för en hel arbetsyta i alla kluster använder du en klusterprincip och lägger till följande i princip-JSON:

Delta

{
  "spark_conf.spark.databricks.delta.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Iceberg

{
  "spark_conf.spark.databricks.iceberg.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Se Skapa och hantera beräkningsprinciper.