Tabellstorlek på Azure Databricks

Tabellstorleken som rapporteras för Delta Lake- och Apache Iceberg-tabeller skiljer sig från den totala storleken på motsvarande filkataloger i molnobjektlagring. Dessa dataformat behåller tidigare versioner av datafiler för att möjliggöra tidsresefrågor. Datafiler tas bara bort när VACUUM körs när kvarhållningströskeln har passerat. Se Ta bort oanvända datafiler med åtgärden "vacuum".

Varför tabellstorleken skiljer sig från katalogstorleken

Tabellstorlekar som rapporteras i Azure Databricks via UIs och DESCRIBE kommandon refererar till den totala storleken på datafiler i lagringen för de filer som refereras i den aktuella versionen av tabellen. De flesta operationer som skriver till tabeller kräver att underliggande datafiler skrivs om och att gamla datafiler behålls för att möjliggöra time travel-frågor.

Beräkna lagringsmått för en tabell

Gäller för: Databricks Runtime 18.0 och senare

Om du vill förstå varför den totala lagringsstorleken skiljer sig från tabellstorleken använder du ANALYZE TABLE … COMPUTE STORAGE METRICS. Det här kommandot visar en detaljerad uppdelning av lagringsallokering som hjälper dig:

• Identifiera möjligheter till kostnadsoptimering: Se hur mycket lagringsutrymme som kan frigöras med VACUUM
• Analysera omkostnader för tidsresor: Förstå kostnaden för att behålla historiska data
• Spåra lagringsmönster: Övervaka hur tabelllagring utvecklas över tid genom att köra kommandot med jämna mellanrum
• Granska lagring mellan tabeller: Kör kommandot i en loop för att analysera hela dataegendomen

Kommandot returnerar omfattande mått, inklusive:

• Total lagringsstorlek: Fullständigt fotavtryck inklusive alla data, metadata och loggar
• Aktiva data: Storleken på den aktuella tabellversionen
• Återvinningsbara data: Utrymme som kan frigöras
• Tidsresedata: Historiska data för återskapningar

Detta är särskilt värdefullt för hanterade Unity Catalog-tabeller där Azure Databricks automatiskt hanterar lagring via förutsägande optimering.

Se ANALYZE TABLE ... BERÄKNINGSLAGRINGSMÅTT för fullständig syntax och exempel.

Använda förutsägelseoptimering för att kontrollera datastorleken

Databricks rekommenderar att du använder hanterade Unity Catalog-tabeller med förutsägande optimering aktiverat. Med hanterade tabeller och förutsägelseoptimering kör Databricks automatiskt OPTIMIZE och VACUUM kommandon för att förhindra uppbyggnad av oanvända datafiler. Förvänta dig att det alltid finns en skillnad i storlek mellan den aktuella versionen av en tabell och den totala storleken på datafiler i molnobjektlagring. Datafiler som inte refereras i den aktuella versionen krävs för att stödja frågor om tidsresor. Se Förutsägelseoptimering för hanterade Unity Catalog-tabeller.

VACUUM lagringsmått

När du rensar oanvända datafiler med VACUUM eller använder DRY RUN för att förhandsgranska filerna som angetts för borttagning, rapporterar mått antalet filer och storleken på borttagna data. Storleken och antalet filer som tas bort av VACUUM varierar drastiskt, men det är vanligt att storleken på borttagna filer överskrider den totala storleken på den aktuella versionen av tabellen.

OPTIMIZE lagringsmått

När OPTIMIZE körs på en måltabell kombinerar nya datafiler poster från existerande datafiler. Ändringar som utförs under OPTIMIZE endast påverkar dataorganisationen, och inga ändringar i det underliggande datainnehållet sker. Den totala storleken på de underliggande datafilerna för tabellen ökar efter OPTIMIZE körningar, eftersom de nya komprimerade filerna samexisterar i den innehållande katalogen med de gamla ooptimerade datafilerna.

Storleken på tabellen som rapporteras efter OPTIMIZE är vanligtvis mindre än storleken innan OPTIMIZE körs, eftersom den totala storleken på datafiler som refereras till av den aktuella tabellversionen minskar med datakomprimering. För att ta bort underliggande datafiler måste VACUUM köras efter att kvarhållningströskeln har passerats.