Tabelgrootte in Azure Databricks

De tabelgrootte die is gerapporteerd voor Delta Lake- en Apache Iceberg-tabellen verschilt van de totale grootte van de bijbehorende bestandsmappen in cloudobjectopslag. Deze gegevensindelingen behouden eerdere versies van gegevensbestanden om query's voor tijdreizen mogelijk te maken. Gegevensbestanden worden alleen verwijderd wanneer deze worden uitgevoerd nadat VACUUM de retentiedrempel is verstreken. Zie Ongebruikte gegevensbestanden verwijderen met vacuüm.

Waarom tabelgrootte verschilt van mapgrootte

Tabelgrootten die zijn gerapporteerd in Azure Databricks via UIS's en DESCRIBE opdrachten verwijzen naar de totale grootte van gegevensbestanden in opslag voor die bestanden waarnaar wordt verwezen in de huidige versie van de tabel. De meeste bewerkingen die naar tabellen schrijven, vereisen het herschrijven van onderliggende gegevensbestanden en het behouden van oude gegevensbestanden om query's voor tijdreizen mogelijk te maken.

Notitie

Als u records in tabellen regelmatig verwijdert of bijwerkt, kunnen verwijderingsvectoren query's versnellen en de totale grootte van gegevensbestanden verminderen. Zie Verwijderingsvectoren in Databricks.

Metrische gegevens voor opslag berekenen voor een tabel

Van toepassing op: Databricks Runtime 18.0 en hoger

Als u wilt weten waarom de totale opslaggrootte verschilt van de tabelgrootte, gebruikt u ANALYZE TABLE … COMPUTE STORAGE METRICS. Met deze opdracht wordt een gedetailleerde uitsplitsing van de opslagtoewijzing weergegeven, zodat u het volgende kunt doen:

• Mogelijkheden voor kostenoptimalisatie identificeren: Bekijk met hoeveel opslagruimte kan worden vrijgemaakt VACUUM
• Overhead van tijdreizen analyseren: inzicht in de kosten voor het behouden van historische gegevens
• Opslagpatronen bijhouden: Bewaken hoe tabelopslag zich in de loop van de tijd ontwikkelt door de opdracht periodiek uit te voeren
• Opslag in tabellen controleren: voer de opdracht in een lus uit om uw hele gegevensomgeving te analyseren

De opdracht retourneert uitgebreide metrische gegevens, waaronder:

• Totale opslaggrootte: Volledige footprint, inclusief alle gegevens, metagegevens en logboeken
• Actieve gegevens: Grootte van de huidige tabelversie
• Vacuümbare gegevens: ruimte die kan worden vrijgemaakt
• Tijdreisgegevens: Historische gegevens voor terugdraaiacties

Dit is met name waardevol voor door Unity Catalog beheerde tabellen, waarbij Azure Databricks automatisch opslag beheert via voorspellende optimalisatie.

Zie ANALYZE TABLE ... BEREKENING VAN OPSLAGMETRIEKEN voor de volledige syntaxis en voorbeelden.

Voorspellende optimalisatie gebruiken om de gegevensgrootte te beheren

Databricks raadt aan beheerde tabellen van Unity Catalog te gebruiken waarvoor predictive optimization is ingeschakeld. Met beheerde tabellen en voorspellende optimalisatie voert Databricks automatisch OPTIMIZE en VACUUM opdrachten uit om te voorkomen dat ongebruikte gegevensbestanden worden opgebouwd. Verwacht dat er altijd een verschil in grootte is tussen de huidige versie van een tabel en de totale grootte van gegevensbestanden in de cloudobjectopslag. Gegevensbestanden waarnaar in de huidige versie niet wordt verwezen, zijn vereist om query's voor tijdreizen te ondersteunen. Zie Voorspellende optimalisatie voor beheerde tabellen van Unity Catalog.

VACUUM metrische opslaggegevens

Wanneer u ongebruikte gegevensbestanden opschoont met VACUUM of DRY RUN gebruikt om een voorbeeld te bekijken van de bestanden die zijn ingesteld voor verwijdering, rapporteren metrische gegevens het aantal bestanden en de grootte van de gegevens die zijn verwijderd. De grootte en het aantal bestanden dat is verwijderd VACUUM , varieert drastisch, maar het is gebruikelijk dat de grootte van verwijderde bestanden groter is dan de totale grootte van de huidige versie van de tabel.

OPTIMIZE metrische opslaggegevens

Wanneer OPTIMIZE wordt uitgevoerd op een doeltabel, combineren nieuwe gegevensbestanden records uit bestaande gegevensbestanden. Wijzigingen die tijdens OPTIMIZE worden doorgevoerd, hebben alleen invloed op de organisatie van de gegevens en er vinden geen wijzigingen plaats in de inhoud van de onderliggende gegevens. De totale grootte van de onderliggende gegevensbestanden voor de tabel neemt na OPTIMIZE uitvoeringen toe, omdat de nieuwe gecomprimeerde bestanden naast elkaar bestaan in de map met de oude niet-geoptimaliseerde gegevensbestanden.

De grootte van de tabel die wordt gerapporteerd na OPTIMIZE is over het algemeen kleiner dan de grootte voordat OPTIMIZE wordt uitgevoerd, omdat de totale grootte van gegevensbestanden waarnaar wordt verwezen door de huidige tabelversie afneemt met gegevenscompressie. Als u de onderliggende gegevensbestanden wilt verwijderen, moet VACUUM worden uitgevoerd nadat de bewaartermijn is verstreken.

Notitie

Mogelijk ziet u vergelijkbare metrische gegevens voor bewerkingen zoals REORG TABLE of DROP FEATURE. Alle bewerkingen waarvoor het herschrijven van gegevensbestanden is vereist, vergroten de totale grootte van gegevens in de map met mappen totdat VACUUM gegevensbestanden verwijdert waarnaar niet meer wordt verwezen in de huidige tabelversie.