Deletion Vectors: Definition und Delta-Lake-Mechanik

Deletion Vectors sind ein Mechanismus im Delta-Lake-Tabellenformat, der gelöschte oder geänderte Zeilen einer Tabelle in einer kleinen Markierungsdatei (einer sogenannten Bitmap) neben der eigentlichen Datendatei vermerkt, statt die Datendatei sofort neu zu schreiben. Beim Lesen blendet das System die markierten Zeilen aus dem Ergebnis aus. Physisch aus dem Speicher entfernt werden die Zeilen erst später, durch einen geplanten Aufräumlauf (OPTIMIZE oder REORG mit der Option PURGE) und den nachfolgenden Löschbefehl VACUUM.

Was sind Deletion Vectors?

Deletion Vectors sind eine zuschaltbare Funktion des offenen Delta-Lake-Tabellenformats (ein Standard, um große Tabellen zuverlässig auf Cloud-Speicher abzulegen). Aktiviert wird sie über die Tabellen-Eigenschaft delta.enableDeletionVectors. Auf Databricks ist die Funktion für neu angelegte Tabellen ab der Plattform-Version 14.0 automatisch eingeschaltet; in der frei verfügbaren Delta-Lake-Ausgabe (Open Source) ist sie ab den Versionen 2.4 bis 3.1 vorhanden und muss dort ausdrücklich gesetzt werden. Das Einschalten hebt die interne Format-Version der Tabelle dauerhaft an: alle Werkzeuge (Abfrage- und Verarbeitungssysteme), die die Tabelle lesen wollen, müssen Deletion Vectors verstehen.

Der Vektor selbst ist eine kleine Bitmap im RoaringBitmap-Format, in der pro Parquet-Datei ein Bit je Zeile geführt wird. Bei DELETE, UPDATE und MERGE ergänzt Delta Lake die Bitmap um die betroffenen Zeilen; die eigentliche Parquet-Datei bleibt zunächst unverändert. Neu geschriebene Zeilen (etwa der update_postimage-Teil einer Update-Operation) werden separat als neue Datendateien abgelegt. Beim Lesen kombiniert die Engine Parquet-Datei und zugehörigen Deletion Vector: Zeilen mit gesetztem Bit werden aus dem Ergebnis gefiltert.

Der Ansatz existiert, weil das klassische Copy-on-Write-Verhalten bereits bei kleinen Änderungen auf großen Tabellen unverhältnismäßig teuer wird. Ein MERGE mit wenigen geänderten Zeilen konnte bislang das Neuschreiben mehrerer Gigabyte an Parquet-Dateien auslösen. Deletion Vectors trennen die logische Änderung (Bitmap-Ergänzung, sofort) von der physischen Bereinigung (nachgelagerter Wartungslauf). Damit sinken I/O- und Compute-Kosten bei häufigen kleinen Änderungen, während der Lese-Pfad geringfügig aufwendiger wird, bis ein Wartungslauf die Markierungen materialisiert.

Abgrenzung: Copy-on-Write, Iceberg Delete Files, Change Data Feed und Time Travel

Deletion Vectors werden häufig mit angrenzenden Verfahren vermischt, die entweder eine andere Schreib-Strategie oder eine andere Blickrichtung auf denselben Delta-Log-Verlauf verfolgen.

Begriff	Verhältnis zu Deletion Vectors
Copy-on-Write (Delta ohne Deletion Vectors)	Schreibt bei jeder Änderung die betroffene Parquet-Datei ohne die gelöschten Zeilen neu. Physisch sofort weg (bis auf ältere Versionen), aber teuer bei kleinen Änderungen. Deletion Vectors sind der Merge-on-Read-Gegenentwurf innerhalb desselben Formats.
Iceberg Delete Files (Position/Equality)	Gleicher konzeptioneller Ansatz (Delete-Marker statt Rewrite), aber im Apache-Iceberg-Format über eigene Delete-File-Formate umgesetzt: Position Deletes referenzieren Datei plus Row-ID, Equality Deletes formulieren ein Predikat. Nicht kompatibel mit Delta-Deletion-Vectors.
Change Data Feed	Liefert zeilengenaue Änderungssätze für Downstream-Konsumenten. Deletion Vectors bestimmen dagegen, wie die Änderung physisch im Storage abgelegt wird. Beide Mechanismen ergänzen sich innerhalb einer Pipeline.
Time Travel	Deletion Vectors kennzeichnen den aktuellen Tabellenstand; Time Travel greift auf ältere Tabellenversionen zu, in denen die markierten Zeilen weiterhin sichtbar sind. Erst VACUUM entfernt die alten Dateien und damit die historische Sichtbarkeit.

Die wichtigste Abgrenzung ist die zwischen Deletion Vectors und Copy-on-Write, weil sie den Zeitpunkt der physischen Löschung verschiebt. Ein DELETE mit Deletion Vectors ist logisch abgeschlossen, sobald die Bitmap ergänzt und der Commit geschrieben ist; die betroffenen Zeilen liegen physisch aber weiter in der ursprünglichen Parquet-Datei und in allen älteren Tabellenversionen. Erst ein Rewrite-Lauf (OPTIMIZE mit Materialisierung oder REORG TABLE … APPLY (PURGE)) plus anschließender VACUUM nach Ablauf der Aufbewahrungsfrist entfernt die Daten endgültig.

Beispiel: MERGE aus einer CDC-Strecke ohne Datei-Rewrite

Eine CDC-Pipeline aus einer OLTP-Quelle merged stündlich einige tausend geänderte Kundendatensätze in eine 500 GB große Silver-Tabelle. Auf dem klassischen Copy-on-Write-Pfad muss jeder MERGE die betroffenen Parquet-Dateien vollständig neu schreiben, häufig mehrere Gigabyte pro Lauf, obwohl nur wenige tausend Zeilen tatsächlich geändert werden.

Mit aktivierten Deletion Vectors ergänzt Delta Lake bei jedem MERGE die Bitmap der betroffenen Parquet-Dateien um die zu löschenden Zeilen (der update_preimage-Teil) und schreibt die neuen Zeilen (update_postimage) als kompakte Datendatei daneben. Der Commit ist in Sekunden abgeschlossen, das Schreibvolumen sinkt um Größenordnungen. Ein nächtlicher REORG TABLE silver.customers APPLY (PURGE)-Lauf schreibt die betroffenen Dateien anschließend ohne die markierten Zeilen neu, und ein VACUUM nach Ablauf der Aufbewahrungsfrist entfernt die alten Dateien aus dem Storage. Alternativ übernimmt Predictive Optimization diese Wartungsschritte automatisch auf Unity-Catalog-verwalteten Tabellen.