Entfernen nicht verwendeter Datendateien mit VACUUM

  • Artikel

Sie können Datendateien entfernen, auf die nicht mehr von einer Delta-Tabelle verwiesen wird und älter als der Aufbewahrungsschwellenwert sind, indem Sie den Befehl VACUUM für die Tabelle ausführen. Die regelmäßige Ausführung von VACUUM ist aus Kosten- und Compliancegründen wichtig aufgrund der folgenden Überlegungen:

  • Das Löschen nicht verwendeter Datendateien reduziert die Cloudspeicherkosten.
  • Durch VACUUM entfernte Datendateien können Datensätze enthalten, die geändert oder gelöscht wurden. Durch das dauerhafte Entfernen dieser Dateien aus dem Cloudspeicher wird sichergestellt, dass auf diese Datensätze nicht mehr zugegriffen werden kann.

Der Standardaufbewahrungsschwellenwert für Datendateien nach Ausführung von VACUUM beträgt 7 Tage. Informationen zum Ändern dieses Verhaltens finden Sie unter Konfigurieren der Datenaufbewahrung für Zeitreisen.

Databricks empfiehlt die Verwendung der prädiktiven Optimierung, um VACUUM automatisch für Deltatabellen auszuführen. Weitere Informationen finden Sie unter Prädiktive Optimierung für Delta Lake.

Einige Delta Lake-Features verwenden Metadatendateien, um Daten als gelöscht zu markieren, anstatt Datendateien neu zu schreiben. Sie können REORG TABLE ... APPLY (PURGE) verwenden, um diese Löschvorgänge zu committen und Datendateien neu zu schreiben. Weitere Informationen finden Sie unter Bereinigen von Nur-Metadaten-Löschvorgängen, um das Neuschreiben von Daten zu erzwingen.

Wichtig

  • In Databricks Runtime 13.2 und höher unterscheidet sich die VACUUM-Semantik für flache Klone mit verwalteten Unity Catalog-Tabellen von anderen Deltatabellen. Einzelheiten finden Sie unter Vacuum und flache Klone für Unity Catalog.
  • VACUUM entfernt alle Dateien aus Verzeichnissen, die nicht von Delta Lake verwaltet werden, und ignoriert dabei Verzeichnisse, die mit _ oder . beginnen. Wenn Sie zusätzliche Metadaten wie Structured Streaming-Prüfpunkte innerhalb eines Delta-Tabellenverzeichnisses speichern, verwenden Sie einen Verzeichnisnamen wie _checkpoints.
  • Die Möglichkeit, Tabellenversionen abzufragen, die älter als der Aufbewahrungszeitraum sind, geht nach der Ausführung von VACUUM verloren.
  • Protokolldateien werden nach Prüfpunktvorgängen automatisch und asynchron gelöscht und werden nicht durch VACUUM gesteuert. Während der Standardaufbewahrungszeitraum von Protokolldateien 30 Tage beträgt, werden bei der Ausführung von VACUUM bei einer Tabelle die für Zeitreisen erforderlichen Datendateien entfernt.

Hinweis

Wenn Datenträgercaching aktiviert ist, könnte ein Cluster Daten aus Parquet-Dateien enthalten, die mit VACUUM gelöscht wurden. Deshalb kann es möglich sein, die Daten früherer Tabellenversionen abzufragen, deren Dateien gelöscht wurden. Durch einen Neustart des Clusters werden die zwischengespeicherten Daten entfernt. Siehe Konfigurieren des Datenträgercaches.

Beispielsyntax für VACUUM

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

Details zur Spark SQL-Syntax finden Sie unter VACUUM.

Details zur Syntax von Scala, Java und Python finden Sie in der Dokumentation zur Delta Lake-API.

Hinweis

Verwenden Sie das RETAIN Schlüsselwort, um den Schwellenwert anzugeben, der verwendet wird, um zu bestimmen, ob eine Datendatei entfernt werden soll. Der VACUUM Befehl verwendet diesen Schwellenwert, um die angegebene Zeitspanne zurückzublicken und die aktuellste Tabellenversion zu diesem Zeitpunkt zu identifizieren. Delta behält alle Datendateien bei, die zum Abfragen dieser Tabellenversion und aller neueren Tabellenversionen erforderlich sind. Diese Einstellung interagiert mit anderen Tabelleneigenschaften. Weitere Informationen finden Sie unter Konfigurieren der Datenaufbewahrung für Zeitreiseabfragen.

Bereinigen von Nur-Metadaten-Löschvorgängen, um das Neuschreiben von Daten zu erzwingen

Der REORG TABLE-Befehl stellt die APPLY (PURGE)-Syntax zum Neuschreiben von Daten bereit, um vorläufige Löschvorgänge anzuwenden. Vorläufige Löschvorgänge schreiben keine Daten neu oder löschen keine Datendateien, sondern verwenden Metadatendateien, um anzugeben, dass sich einige Datenwerte geändert haben. Weitere Informationen finden Sie unter REORG TABLE.

Zu den Vorgängen, die vorläufige Löschvorgänge in Delta Lake erstellen, gehören folgende:

  • Ablegen von Spalten mit aktivierter Spaltenzuordnung.
  • Löschen von Zeilen mit aktivierten Löschvektoren.
  • Alle Datenänderungen in Photon-fähigen Clustern, wenn Löschvektoren aktiviert sind.

Wenn vorläufiges Löschen aktiviert ist, bleiben alte Daten möglicherweise physisch in den aktuellen Dateien der Tabelle vorhanden, auch nachdem die Daten gelöscht oder aktualisiert wurden. Führen Sie die folgenden Schritte aus, um diese Daten physisch aus der Tabelle zu entfernen:

  1. Führen Sie REORG TABLE ... APPLY (PURGE)aus. Danach sind die alten Daten nicht mehr in den aktuellen Dateien der Tabelle vorhanden, aber sie sind weiterhin in den älteren Dateien vorhanden, die für die Zeitreise verwendet werden.
  2. Führen Sie VACUUM aus, um diese älteren Dateien zu löschen.

REORG TABLE erstellt nach Abschluss des Vorgangs eine neue Version der Tabelle. Alle Tabellenversionen im Verlauf vor dieser Transaktion beziehen sich auf ältere Datendateien. Konzeptionell ähnelt dies dem OPTIMIZE-Befehl, bei dem Datendateien neu geschrieben werden, obwohl die Daten in der aktuellen Tabellenversion konsistent bleiben.

Wichtig

Datendateien werden nur gelöscht, wenn die Dateien gemäß dem VACUUM-Aufbewahrungszeitraum abgelaufen sind. Dies bedeutet, dass der VACUUM-Befehl mit einer Verzögerung nach dem REORG-Befehl erfolgen muss, damit die älteren Dateien abgelaufen sind. Der Aufbewahrungszeitraum von VACUUM kann reduziert werden, um die erforderliche Wartezeit zu verkürzen, was jedoch mit einer Verkürzung des maximalen aufbewahrten Zeitreiseverlaufs einhergeht.

Welche Clustergröße benötigt VACUUM?

Um die richtige Clustergröße für VACUUM auszuwählen, hilft es, zu verstehen, dass der Vorgang in zwei Phasen erfolgt:

  1. Der Auftrag beginnt mit der Verwendung aller verfügbaren Executorknoten, um Dateien im Quellverzeichnis parallel aufzulisten. Diese Liste wird mit allen Dateien verglichen, auf die derzeit im Delta-Transaktionsprotokoll verwiesen wird, um zu löschende Dateien zu identifizieren. Der Treiber befindet sich in dieser Zeit im Leerlauf.
  2. Der Treiber gibt dann Löschbefehle für jede Datei aus, die gelöscht werden soll. Das Löschen von Dateien ist ein nur treiberbasierter Vorgang, was bedeutet, dass alle Vorgänge in einem einzelnen Knoten ausgeführt werden, während sich die Workerknoten im Leerlauf befinden.

Um Kosten und Leistung zu optimieren, empfiehlt Databricks Folgendes, insbesondere bei zeitintensiven VACUUM-Aufträgen:

  • Führen Sie VACUUM auf einem Cluster aus, für den die automatische Skalierung für 1 bis 4 Worker festgelegt ist und jeder Worker über 8 Kerne verfügt.
  • Wählen Sie einen Treiber mit 8 bis 32 Kernen aus. Erhöhen Sie die Größe des Treibers, um OOM (Out-of-Memory)-Fehler zu vermeiden.

Wenn VACUUM-Vorgänge regelmäßig mehr als 10 000 Dateien löschen oder mehr als 30 Minuten Verarbeitungszeit in Anspruch nehmen, sollten Sie entweder die Größe des Treibers oder die Anzahl der Worker erhöhen.

Wenn Sie feststellen, dass die Verlangsamung während dem Identifizieren der zu entfernenden Dateien auftritt, fügen Sie weitere Workerknoten hinzu. Wenn die Verlangsamung auftritt, während Löschbefehle ausgeführt werden, versuchen Sie, die Größe des Treibers zu erhöhen.

Wie häufig sollte VACUUM ausgeführt werden?

Databricks empfiehlt, VACUUM regelmäßig für alle Tabellen auszuführen, um die Kosten für Clouddatenspeicher zu reduzieren. Der Standardschwellenwert für die Aufbewahrung beträgt 7 Tage. Wenn Sie einen höheren Schwellenwert festlegen, erhalten Sie Zugriff auf einen längeren Verlauf für Ihre Tabelle, dies erhöht jedoch die Anzahl gespeicherter Datendateien und somit die Speicherkosten bei Ihrem Cloudanbieter.

Warum kann VACUUM nicht für eine Delta-Tabelle mit einem niedrigen Aufbewahrungsschwellenwert ausgeführt werden?

Warnung

Es wird empfohlen, ein Aufbewahrungsintervall von mindestens 7 Tagen festzulegen, da alte Momentaufnahmen und nicht übergebene Dateien von gleichzeitigen Lesern oder Schreibern für die Tabelle weiterhin verwendet werden können. Wenn VACUUM aktive Dateien bereinigt, können gleichzeitige Reader fehlschlagen oder – noch schlimmer – Tabellen beschädigt werden, wenn VACUUM Dateien löscht, die noch nicht committet wurden. Sie müssen ein Intervall auswählen, das länger ist als die am längsten ausgeführte gleichzeitige Transaktion und der längste Zeitraum, den ein Stream hinter dem neuesten Update der Tabelle zurückbleiben kann.

Bei Delta Lake gibt es eine Sicherheitsüberprüfung, um zu verhindern, dass Sie einen gefährlichen VACUUM-Befehl ausführen. Wenn Sie sicher sind, dass bei dieser Tabelle keine Vorgänge ausgeführt werden, die länger dauern als das Aufbewahrungsintervall, das Sie angeben möchten, können Sie diese Sicherheitsüberprüfung deaktivieren, indem Sie die Spark-Konfigurationseigenschaft spark.databricks.delta.retentionDurationCheck.enabled auf false festlegen.

Überwachungsinformationen

VACUUM-Commits zum Delta-Transaktionsprotokoll enthalten Überwachungsinformationen. Sie können die Überwachungsereignisse mit DESCRIBE HISTORY abfragen.