Wie wird das Problem der 'Small Files' in Delta Lake technisch durch Compaction und Vacuum gelöst?

Das Problem der „Small Files“ entsteht in Delta Lake primär durch Streaming-Ingestions oder häufige kleine Batch-Updates. Jede dieser Operationen erzeugt neue Parquet-Dateien. Eine hohe Anzahl kleiner Dateien führt zu einem massiven Overhead beim Auslesen der Metadaten und erhöht die Anzahl der I/O-Operationen, was die Query-Performance drastisch senkt.

Wir lösen dieses Problem technisch durch zwei komplementäre Mechanismen: Compaction (OPTIMIZE) und Vacuum.

Compaction via OPTIMIZE Der OPTIMIZE-Befehl führt die Compaction durch. Technisch gesehen liest Delta Lake die kleinen Dateien eines Verzeichnisses ein und schreibt sie in größeren, optimierten Parquet-Dateien (standardmäßig ca. 1 GB) neu. Da Delta Lake auf einem Transaction Log (Delta Log) basiert, geschieht dies atomar. Die alten kleinen Dateien werden im Log als „removed“ markiert, während die neuen großen Dateien als „added“ eingetragen werden. Bestehende Leseoperationen können weiterhin auf die alten Dateien zugreifen, bis die Transaktion abgeschlossen ist, was die Datenkonsistenz garantiert.

Bereinigung via VACUUM Compaction löscht die physischen Dateien nicht sofort, um die Time-Travel-Funktionalität (Versionierung) zu gewährleisten. Hier setzt VACUUM an. Dieser Befehl entfernt physisch alle Dateien aus dem Storage, die nicht mehr in der aktuellen Version des Transaction Logs referenziert werden und deren Alter die definierte Retention-Period (standardmäßig 7 Tage) überschreitet.

Die korrekte Orchestrierung dieser Prozesse ist Teil einer fundierten IT-Consulting & Digitale Strategie, um die Balance zwischen Abfragegeschwindigkeit und Speicherkosten zu halten.

Wir empfehlen, OPTIMIZE automatisiert in die Pipeline-Orchestrierung zu integrieren und VACUUM strikt nach dem tatsächlichen Time-Travel-Bedarf zu takten, da ein zu aggressives Vacuum die Wiederherstellung früherer Datenstände unmöglich macht.