Liquid Clustering

Liquid Clustering ist eine Sortier-Technik für Delta-Tabellen (das Tabellen-Format des Databricks-Lakehouse), die Datenzeilen mit ähnlichen Werten physisch in denselben Dateien ablegt. Die Sortier-Spalten (Cluster-Keys, definiert per CLUSTER BY) sind zum Beispiel customer_id oder event_date. Delta merkt sich pro Datei die Wertebereiche dieser Spalten (File-Skipping-Statistiken, also Min- und Max-Werte je Datei); Abfragen lesen dadurch nur die wenigen Dateien, deren Wertebereiche zur Filter-Bedingung passen. Neue Daten werden inkrementell einsortiert, ein manueller OPTIMIZE-Lauf oder der automatische Databricks-Dienst Predictive Optimization übernimmt die Nach-Sortierung, ohne die Tabelle in feste Ordner (Partitionen) zerlegen zu müssen.

Was ist Liquid Clustering?

Liquid Clustering ersetzt in Delta-Tabellen die frühere Kombination aus Partitionierung (feste Ordnerstruktur je Wert, etwa ein Ordner pro Datum) und Z-Ordering (Nach-Sortierung per OPTIMIZE ... ZORDER BY, die alle betroffenen Dateien komplett neu schreibt). Die Cluster-Keys werden bei der Tabellenerstellung über CLUSTER BY (col1, col2, ...) definiert; bis zu vier Spalten sind pro Tabelle zulässig. Nachträglich lassen sich die Keys per ALTER TABLE ... CLUSTER BY (...) ändern, ohne die Daten zu kopieren oder die Ordnerstruktur im Cloud-Speicher (Objektspeicher wie AWS S3, Azure Data Lake Storage, Google Cloud Storage) anzupassen. Bestehende Dateien werden erst durch den nächsten OPTIMIZE-Lauf oder Predictive Optimization nach dem neuen Schema sortiert.

Beim Schreiben schreibt Delta Zeilen zunächst in neue Parquet-Dateien und aktualisiert das Transaction Log mit File-Skipping-Statistiken (Min- und Max-Werte pro Cluster-Key, pro Datei). Ein späterer OPTIMIZE-Lauf führt die neuen Dateien mit älteren Dateien zusammen, sodass Zeilen mit ähnlichen Key-Werten physisch in denselben Dateien landen. Das Zielverhalten ist Multi-Column-Data-Skipping: eine Query mit WHERE customer_id = 42 AND event_date >= '2026-01-01' liest nur die Dateien, deren Statistiken beide Predikate abdecken.

Die Voraussetzungen sind Delta-Reader-Protokoll-Version 3 und Writer-Protokoll-Version 7 plus das Table-Feature-Flag liquid. In der OSS-Version ist Liquid Clustering seit Delta Lake 3.2 verfügbar. Auf Databricks ist die Funktion ab Runtime 15.2 für neue Tabellen allgemein verfügbar; die automatische Auswahl der Cluster-Keys (Automatic Liquid Clustering) ergänzt die manuelle Definition ab späteren Runtime-Versionen und wird über Predictive Optimization ausgeführt.

Abgrenzung zu Z-Ordering, Partitioning, Predictive Optimization und Clustering (ML)

Liquid Clustering wird häufig mit verwandten Begriffen vermischt, die entweder ähnliche Zwecke erfüllen oder denselben Namen tragen.

Der zentrale Unterschied zu Z-Ordering liegt in der Inkrementalität. Ein OPTIMIZE ... ZORDER BY-Lauf schreibt alle betroffenen Dateien neu, unabhängig davon, wie viele Zeilen sich seit dem letzten Lauf geändert haben. Liquid Clustering merkt sich das Cluster-Layout in den Tabellen-Metadaten und bearbeitet bei jedem OPTIMIZE nur die Dateien, deren Statistiken vom Ziel-Layout abweichen. Das reduziert Compute-Verbrauch und Laufzeit deutlich, besonders bei Tabellen mit gleichmäßigem Schreib-Volumen.

Gegenüber Partitioning entfällt die harte Entscheidung für eine einzige Partitions-Achse. Cluster-Keys lassen sich ändern; Partitionen dagegen sind Teil des Ordner-Layouts im Objektspeicher und ein Wechsel erzwingt einen Full-Table-Rewrite. Liquid Clustering behandelt bis zu vier Cluster-Keys gleichwertig, was das häufige Zugriffs-Muster „ein Datums-Filter plus ein Business-Key" abdeckt, ohne das Small-File-Problem hoher Partitions-Kardinalitäten auszulösen.

Beispiel: Liquid Clustering auf einer Faktentabelle im Gold-Layer

Eine Faktentabelle im Gold-Layer wird häufig nach customer_id und event_date gefiltert. Statt einer festen Datums-Partition und eines nächtlichen OPTIMIZE ... ZORDER BY (customer_id)-Laufs wird die Tabelle wie folgt angelegt:

CREATE TABLE gold.customer_events (
    customer_id BIGINT,
    event_date DATE,
    event_type STRING,
    payload STRING
)
USING DELTA
CLUSTER BY (customer_id, event_date);

Neue Schreibvorgänge landen zunächst in unclustered-Dateien. Ein nachgelagerter OPTIMIZE gold.customer_events-Lauf führt Zeilen mit ähnlichen customer_id- und event_date-Werten in denselben Dateien zusammen und aktualisiert die File-Skipping-Statistiken. Auf einer UC-Managed-Table übernimmt Predictive Optimization diesen Lauf automatisch, sobald der erwartete Nutzen den Compute-Verbrauch rechtfertigt.

Ändert sich der Filter-Schwerpunkt später auf region_code, genügt ein einzelner Statement-Wechsel: ALTER TABLE gold.customer_events CLUSTER BY (region_code, event_date);. Der nächste OPTIMIZE-Lauf clustert die Tabelle inkrementell nach dem neuen Schema; die Ingest-Pipeline bleibt unverändert, weil kein Ordner-Layout im Objektspeicher betroffen ist.