Deletion Vectors: Warum gelöschte Daten noch im Storage liegen
Deletion Vectors markieren gelöschte Zeilen zunächst nur in einer komprimierten Bitmap: die Parquet-Dateien bleiben bis zum nächsten Wartungslauf unverändert im Storage liegen.
Die Kernaussagen auf einen Blick.
- Deletion Vectors kennzeichnen gelöschte oder geänderte Zeilen in einer komprimierten Bitmap, während die Parquet-Dateien zunächst unverändert im Storage liegen bleiben.
- Dadurch lassen sich DELETE-, UPDATE- und MERGE-Operationen auf großen Tabellen schneller ausführen; die Daten werden jedoch erst in einem nachgelagerten Schritt physisch entfernt.
- Für DSGVO-Löschanfragen ist daher entscheidend, wann die betroffenen Dateien tatsächlich neu geschrieben und entfernt wurden.
- Empfehlenswert ist, den zweistufigen Löschprozess mit klaren Fristen und Verantwortlichkeiten zu dokumentieren und seine Ausführung im Betrieb fest zu verankern.
Inhaltsverzeichnis
Die Zeile ist gelöscht, der physische Nachweis fehlt jedoch
Eine Löschanfrage nach Artikel 17 DSGVO kommt herein. Das DELETE auf der Kundentabelle läuft in Sekunden durch, die Zeile verschwindet aus jedem Bericht und jeder Abfrage. Intern wird die Löschanfrage damit zunächst als abgeschlossen betrachtet. Später verlangt der Datenschutz einen Nachweis darüber, wann die Daten tatsächlich aus dem Speicher entfernt wurden. Das Team kann diesen Zeitpunkt jedoch nicht eindeutig benennen, denn die Tabelle nutzt Deletion Vectors, und die waren beim Anlegen automatisch aktiv.
Diese Situation kann in Databricks-Umgebungen auftreten, in denen Deletion Vectors standardmäßig aktiviert sind. Die Fragen dahinter klingen dann so:
Ist die Zeile nach dem DELETE physisch entfernt oder lediglich für Abfragen ausgeblendet? Seit wann sind Deletion Vectors bei uns überhaupt aktiv? Welcher Zeitpunkt gilt gegenüber Datenschutz und Audit als tatsächliches Löschdatum? Welcher technische Prozess stellt sicher, dass die Daten bis zu diesem Zeitpunkt physisch entfernt werden?
Deletion Vectors trennen das Ausblenden einer Zeile vom späteren physischen Entfernen. Die Schreiboperation wird dadurch schneller, die physische Löschung erfolgt jedoch erst im nachgelagerten Wartungsprozess.
Was sind Deletion Vectors?
Deletion Vectors sind eine Funktion des Delta-Lake-Formats für effiziente Änderungen und Löschungen: Bei DELETE, UPDATE und MERGE werden betroffene Zeilen in einer komprimierten Bitmap (im RoaringBitmap-Format) neben der Parquet-Datei gekennzeichnet. Beim Lesen werden diese Zeilen automatisch aus dem Ergebnis ausgeschlossen; dieses Prinzip heißt Merge-on-Read. Das Delta-Projekt dokumentiert das Verfahren als Soft-Deletes auf Basis komprimierter Bitmaps, dadurch lässt sich der sichtbare Tabellenstand ändern, ohne die zugrunde liegenden Parquet-Dateien sofort neu zu schreiben. Ohne Deletion Vectors wird üblicherweise nach dem Copy-on-Write-Prinzip gearbeitet: Dabei kann bereits die Änderung einer einzelnen Zeile das Neuschreiben der gesamten betroffenen Datei erforderlich machen.
Die Funktion beeinflusst sowohl die Kosten kleiner Änderungen als auch den Zeitpunkt der physischen Löschung. Das physische Entfernen wird dabei gezielt in einen späteren Wartungsschritt verlagert; bis zu diesem Wartungsschritt bleiben die Daten in den ursprünglichen Parquet-Dateien und in älteren Tabellenversionen gespeichert. Wie das Transaktionslog Änderungen als Versionen festhält und welche Stellhebel das Format daneben mitbringt, zeigen wir im Überblick zu Delta Lake.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was ändert sich beim Schreiben und Lesen?
Beim Schreiben reduziert sich insbesondere der Aufwand für das Neuschreiben großer Dateien. Beim Copy-on-Write-Prinzip müssen auch bei kleinen Änderungen ganze Dateien neu geschrieben werden: Ein MERGE mit wenigen geänderten Zeilen kann dadurch große Datenmengen neu schreiben. Mit Deletion Vectors wird stattdessen nur eine kleine Markierungsdatei ergänzt und die geänderten Zeilen als neue Daten abgelegt. Lösch- und Änderungsprozesse können dadurch deutlich weniger Compute und I/O benötigen, besonders bei häufigen kleinen Änderungen aus CDC-Strecken oder Korrektur-Läufen.
Beim Lesen entsteht im Gegenzug zusätzlicher Aufwand. Abfragen müssen zusätzlich die Deletion Vectors auswerten und markierte Zeilen ausfiltern. Der zusätzliche Leseaufwand kann mit der Anzahl der Markierungen zunehmen; ein Wartungslauf kann die Markierungen später materialisieren und die Dateien neu schreiben. Bei häufig gelesenen Tabellen sollte deshalb ein regelmäßiger Wartungsrhythmus festgelegt werden.
| Achse | Copy-on-Write | Deletion Vectors |
|---|---|---|
| Schreibkosten kleiner Änderungen | hoch, ganze Dateien werden neu geschrieben | niedrig, nur Bitmap und geänderte Zeilen |
| Lesekosten | unverändert | leichte Mehrarbeit, wächst bis zur Kompaktierung |
| Physisches Löschen | mit dem Schreibvorgang selbst | erst durch OPTIMIZE/REORG plus VACUUM |
| Wartungsbedarf | Kompaktierung gegen kleine Dateien | zusätzlich Materialisierung der Markierungen |
Die Gegenüberstellung zeigt den grundlegenden Zielkonflikt: Schnellere Schreibvorgänge gehen mit einer späteren physischen Löschung und zusätzlichem Wartungsbedarf einher.
Nach dem DELETE ist die Zeile zunächst nur logisch entfernt
Nach dem DELETE wird die Zeile nicht mehr angezeigt, bleibt aber zunächst gespeichert: in der ursprünglichen Parquet-Datei, die nur als überschrieben markiert wurde, und zusätzlich in allen älteren Tabellenversionen, die das Format für die Versionshistorie aufbewahrt. Der logische Löschzeitpunkt unterscheidet sich damit vom physischen Entfernen; wie lange dieser Zeitraum dauert, hängt vom festgelegten Wartungs- und Aufbewahrungsprozess ab.
Welche Anforderungen an die physische Löschung nach dem Recht auf Vergessenwerden gelten, muss gemeinsam mit Datenschutz und Audit festgelegt werden; die Plattform muss den tatsächlichen Löschzeitpunkt technisch nachvollziehbar machen. Databricks dokumentiert dafür einen Lösch-Prozess für DSGVO- und CCPA-Anfragen, der das logische Löschen ausdrücklich um einen physischen Aufräumschritt ergänzt. Der Zeitraum zwischen logischem DELETE und physischer Entfernung sollte deshalb Bestandteil des Löschkonzepts sein. Die Mechanik ist dokumentiert und beherrschbar; ohne geplante Wartungsprozesse wird die Frist jedoch nicht automatisch eingehalten.
Der technische Ablauf einer Löschanfrage besteht aus drei Schritten:
Tag 0, DELETE
Die Zeile verschwindet aus allen Abfragen. Physisch liegt sie in der alten Parquet-Datei und in der Versionshistorie.
Wartungslauf, OPTIMIZE oder REORG mit PURGE
Die betroffenen Dateien werden ohne die markierten Zeilen neu geschrieben. Die alten Dateien bleiben für die Versionshistorie zunächst erhalten.
VACUUM nach Ablauf der Aufbewahrungsfrist
Die alten Dateien werden aus dem Storage entfernt. Ab jetzt sind die Daten physisch weg und ältere Versionen mit der Zeile sind nicht mehr erreichbar.
| Zustand | Sichtbar in Abfragen? | Physisch im Storage? | Über ältere Versionen erreichbar? |
|---|---|---|---|
| Nach DELETE | nein | ja | ja |
| Nach OPTIMIZE/REORG mit PURGE | nein | ja, in alten Dateien | ja |
| Nach VACUUM | nein | nein | nein |
Erst nach VACUUM sind die betroffenen Daten physisch aus dem Speicher entfernt.
Wie werden markierte Zeilen physisch gelöscht?
Die physische Löschung erfolgt in zwei Schritten. Im ersten Schritt werden die betroffenen Dateien ohne die markierten Zeilen neu geschrieben. OPTIMIZE oder die automatische Kompaktierung können dies teilweise übernehmen, erfassen jedoch nicht zwingend alle betroffenen Dateien: Microsoft dokumentiert dafür eine Schwelle von fünf Prozent markierter Zeilen pro Datei, und Dateien, die nicht neu geschrieben werden, können weiterhin Deletion Vectors enthalten. Für eine gezielte vollständige Materialisierung eignet sich REORG TABLE … APPLY (PURGE): Der Befehl schreibt alle betroffenen Dateien ohne die gelöschten Zeilen neu, unabhängig von Schwellwerten.
Im zweiten Schritt werden die alten Dateien aus dem Speicher entfernt. Nach dem Neuschreiben bleiben die ursprünglichen Dateien mit den gelöschten Zeilen zunächst für die Versionshistorie erhalten. Databricks dokumentiert für VACUUM eine Standard-Aufbewahrungsfrist von sieben Tagen, nach deren Ablauf der Befehl diese Dateien physisch aus dem Storage entfernt. Für eine vollständige Löschung ist der zeitliche Ablauf entscheidend: Die VACUUM-Frist sollte sich am Abschluss des PURGE-Laufs orientieren, andernfalls können alte Dateien mit den gelöschten Daten weiterhin gespeichert bleiben. Die tatsächliche Löschfrist ergibt sich aus der Zeit bis zum nächsten PURGE-Lauf und der anschließenden VACUUM-Aufbewahrungsfrist.
Diese Aufbewahrungsfrist bestimmt zugleich, wie lange ältere Tabellenstände verfügbar bleiben. Solange die alten Dateien liegen, enthält jede ältere Tabellenversion die gelöschte Zeile weiterhin; erst VACUUM kappt diesen Zugriff. Warum ältere Versionen für Audits wertvoll sind und wie die Aufbewahrungsfrist die Historie begrenzt, erklären wir in Time Travel. Wie der Wartungs-Rhythmus, die Frequenzen und die Kosten dieses Aufräumens geplant werden, führen wir in Optimize & Vacuum aus.
Wann sind Deletion Vectors die richtige Wahl?
Auf Databricks sind Deletion Vectors bei neuen Tabellen häufig bereits aktiviert; zu prüfen ist daher meist, ob die Funktion für das jeweilige Workload-Profil geeignet ist. Microsoft dokumentiert, dass neue Tabellen ab Databricks Runtime 14.0 automatisch aktiviert angelegt werden; die Voreinstellung lässt sich pro Workspace steuern, und Ausnahmen gelten unter anderem für materialisierte Views und Streaming-Tabellen im Hive Metastore. In der Open-Source-Variante von Delta Lake schaltet erst die Tabellen-Eigenschaft delta.enableDeletionVectors die Funktion frei, und die Schreib-Unterstützung kam dort schrittweise mit den Versionen 2.4 bis 3.1.
Deletion Vectors aktivieren, wenn
- Tabellen häufige, aber mengenmäßig kleine Änderungen bekommen, etwa aus CDC-Pipelines oder regelmäßigen MERGE-Operationen
- Regelmäßige Korrekturläufe auf großen Beständen laufen
- Löschpflichten viele einzelne Zeilen statt ganzer Partitionen betreffen
Copy-on-Write bevorzugen, wenn
- Tabellen fast ausschließlich Daten anhängen
- Löschungen über vollständige Partitionen laufen, die das Format ohnehin durch Verwerfen kompletter Dateien abwickelt
- Tabellen selten geändert, aber sehr oft gelesen werden
Zusätzlich muss die Kompatibilität mit externen Engines berücksichtigt werden. Durch die Aktivierung steigen die Reader- und Writer-Anforderungen der Tabelle, und Databricks dokumentiert die Funktion als Table Feature mit eigener Reader- und Writer-Anforderung: Alle lesenden Systeme müssen Deletion Vectors unterstützen. Aktuelle Versionen von Spark, Trino, Snowflake, BigQuery und Microsoft Fabric lesen solche Tabellen; einige externe Bibliotheken wie die Rust-Bibliothek delta-rs können solche Tabellen zwar lesen, schreiben Änderungen aber weiterhin nach dem Copy-on-Write-Prinzip. Auch das Abschalten führt über diese Mechanik: erst ein PURGE-Lauf, der alle Markierungen materialisiert, danach das Entfernen des Table Features.
Die Aktivierung ist daher neben der Performance auch eine Betriebs- und Kompatibilitätsfrage: Die Schreib-Beschleunigung mitnehmen und gleichzeitig festlegen, wie das Aufräumen läuft und wie es mit den lesenden Systemen abgestimmt ist.
Was Deletion Vectors nicht regeln
Deletion Vectors regeln die Markierung betroffener Zeilen und deren Ausblendung beim Lesen. Mehrere angrenzende Betriebsfragen müssen jedoch separat gelöst werden und gehören in die Nachbar-Themen der Delta-Lake-Gruppe:
- Das Wartungsmodell mit Rhythmus, Aufbewahrungsfristen und Kosten entscheidet darüber, wie lange es bis zur physischen Entfernung der Daten dauert; das Betriebsmodell dazu steht in Optimize & Vacuum.
- Nachgelagerte Systeme erhalten Löschinformationen nur über zusätzliche Änderungs- oder Synchronisationsprozesse; wie zeilengenaue Änderungen downstream ankommen, zeigen wir im Change Data Feed.
- Die Einordnung der Mechanik in das Format selbst, vom Transaktionslog bis zur Format-Entscheidung gegenüber Apache Iceberg, trägt der Überblick zu Delta Lake.
Deletion Vectors, Wartungsprozesse und Change Data Feed ergänzen sich innerhalb des Löschprozesses: Deletion Vectors kennzeichnen die zu entfernenden Zeilen; der Wartungsprozess bestimmt, wann diese Daten physisch entfernt werden.
Grenzen
Deletion Vectors reduzieren den Schreibaufwand bei kleinen Änderungen auf großen Tabellen. Für Lösch- und Compliance-Anforderungen ist jedoch zusätzlich ein dokumentierter Wartungsprozess erforderlich.
Die Schreibvorgänge werden schneller, die physische Bereinigung muss weiterhin geplant werden.
Markierte Zeilen liegen bis zum Wartungslauf im Speicher, und die Speicherkosten sinken erst nach VACUUM. Ohne regelmäßige Wartung können sich Deletion Vectors und nicht mehr benötigte Dateien ansammeln.
Beim Lesen müssen die Markierungen bis zur Materialisierung berücksichtigt werden.
Bis zur Kompaktierung prüft jede Abfrage die Bitmaps. Bei stark genutzten Tabellen kann sich der zusätzliche Leseaufwand ohne regelmäßige Kompaktierung erhöhen.
Nicht kompatible Reader können nach der Aktivierung möglicherweise nicht mehr auf die Tabelle zugreifen.
Die Aktivierung hebt die Protokoll-Version dauerhaft an. Jede lesende Engine im Stack muss die Funktion beherrschen, und einzelne Schreib-Pfade außerhalb von Spark arbeiten weiterhin nach dem Copy-on-Write-Prinzip.
Ein verbindlicher Löschzeitpunkt kann erst durch den vollständigen PURGE- und VACUUM-Prozess zugesagt werden.
Ein DELETE dokumentiert lediglich die logische Löschung. Die Frist ergibt sich aus PURGE-Lauf plus Aufbewahrungsfrist, und für ihre Einhaltung und Dokumentation muss eine klare Verantwortung bestehen.
Die konkrete rechtliche Löschfrist wird nicht durch die technische Funktion vorgegeben.
Welche Frist eine Löschpflicht konkret verlangt, legt die Mechanik nirgends fest. Sie liefert die Werkzeuge für einen belegbaren Prozess; die Anforderung definieren Datenschutz und Audit.
Die Funktion sollte deshalb gemeinsam mit Wartung, Governance und Löschkonzept geplant werden: aktiv lassen, wo das Workload-Profil passt, und von Anfang an mit dem Wartungsmodell und einer dokumentierten Lösch-Frist verbinden. Sobald Löschpflichten oder Audit-Anforderungen auf den Tabellen liegen, sollte der Prozess festgelegt sein, bevor produktive Tabellen mit Löschanforderungen betrieben werden.
Fazit
Eine Löschung sollte erst dann als vollständig gelten, wenn der physische Löschzeitpunkt technisch nachweisbar ist.
Deletion Vectors sind bei neuen Databricks-Tabellen häufig standardmäßig aktiviert, und für Workloads mit häufigen kleinen Änderungen ist diese Voreinstellung in der Regel sinnvoll: Kleine Änderungen werden günstiger, MERGE-lastige Ladeprozesse schneller, und Löschungen auf großen Tabellen lassen sich dadurch effizienter verarbeiten. Voraussetzung ist jedoch ein Wartungsmodell, das markierte Zeilen materialisiert und alte Dateien fristgerecht entfernt.
Typische Situationen, in denen ein klar geregelter Löschprozess besonders wichtig ist:
- DSGVO-Löschanfragen, bei denen der tatsächliche physische Löschzeitpunkt bislang nicht nachgewiesen werden kann
- MERGE- und Korrektur-Jobs, die für wenige Zeilen ganze Dateien neu schreiben
- Tabellen, bei denen gelöschte Daten weiterhin Speicher belegen und die Kosten dadurch steigen
Bei Tabellen, die fast nur Daten anhängen und selten ändern, bringt die Mechanik wenig; in diesen Fällen besteht kein unmittelbarer Handlungsbedarf. Kritisch wird es, sobald verbindliche Löschfristen gelten, aber PURGE und VACUUM nicht geregelt sind.
Mein Vorschlag: Deletion Vectors können aktiviert bleiben, sofern der zugehörige Wartungsprozess festgelegt ist: welcher Lauf materialisiert, wann VACUUM räumt, wer beides verantwortet.
FAQ
Deletion Vectors sind eine Schreib-Mechanik des Delta-Formats. DELETE, UPDATE und MERGE markieren betroffene Zeilen in einer komprimierten Bitmap-Datei neben der Parquet-Datei; Abfragen blenden die markierten Zeilen beim Lesen aus. Die Datendateien bleiben dabei zunächst unverändert liegen. Das macht kleine Änderungen auf großen Tabellen deutlich schneller als das frühere Neuschreiben ganzer Dateien.
