Liquid Clustering: Wann sich der Wechsel des Daten-Layouts lohnt
Die Kernaussagen auf einen Blick.
- Liquid Clustering ist ein Daten-Layout-Verfahren für Delta-Tabellen, das Clustering-Schlüssel per am Tabellen-Schema festlegt und nachträglich änderbar macht.
- Es löst ein zentrales Problem klassischer Layouts: Einmal gewählte Partitions- und Z-Order-Schlüssel lassen sich nur mit hohem Aufwand ändern.
- Vor der Umstellung sollten drei Punkte geprüft werden: der Runtime-Stand der Plattform, die Kompatibilität externer Leser und der Umbau der Wartungs-Jobs.
- Empfehlenswert ist, Liquid Clustering für neue Tabellen als Standard zu prüfen und bestehende Tabellen nur dann einzeln zu migrieren, wenn der erwartete Nutzen den Aufwand rechtfertigt.
Inhaltsverzeichnis
Wenn das bestehende Datenlayout nicht mehr zu den aktuellen Abfragen passt
Eine Event-Tabelle wurde beim Aufbau der Plattform nach Datum partitioniert und nach Kunden-ID Z-geordnet. Zwei Jahre später haben sich die Abfragemuster verändert: Heute wird vor allem nach Produktlinie und Region gefiltert. Dadurch müssen die Abfragen große Teile der Tabelle lesen, die nächtlichen Sortier-Läufe werden teurer, und eine Anpassung wäre aufwendig: die Tabelle vollständig neu schreiben und dafür nachgelagerte Jobs anhalten.
Diese Situation tritt häufig bei Delta-Plattformen auf, die bereits seit mehreren Jahren betrieben werden. Die ursprüngliche Partitionierung passte zu den damaligen Anforderungen. Inzwischen haben sich die wichtigsten Zugriffsmuster verändert, und das Layout lässt sich ohne Neuaufbau der Tabelle nicht anpassen. Liquid Clustering ermöglicht es, das Layout später an veränderte Abfragemuster anzupassen; Databricks positioniert es als Nachfolger von Partitionierung und Z-Ordering.
Bietet Liquid Clustering einen messbaren Vorteil gegenüber dem bestehenden Layout? Was passiert mit Tabellen, die auch außerhalb von Databricks gelesen werden? Sollten auch bestehende Tabellen migriert werden oder reicht der Einsatz bei neuen Tabellen?
Die Wahl des Datenlayouts sollte deshalb durch klare Standards und einen schrittweisen Migrationsplan geregelt werden: Liquid Clustering macht Clustering-Schlüssel änderbar und reduziert die langfristigen Folgen einer frühen und später möglicherweise unpassenden Layoutentscheidung; Voraussetzung sind jedoch eine Prüfung der Runtime-Versionen und der Kompatibilität aller zugreifenden Systeme.
Was ist Liquid Clustering?
Liquid Clustering ist ein Verfahren zur physischen Organisation von Daten in Delta-Tabellen: Bis zu vier Clustering-Spalten werden per CLUSTER BY direkt am Tabellen-Schema definiert, und regelmäßige OPTIMIZE-Läufe ordnen die Daten anhand dieser Spalten. Abfragen, die auf diese Schlüssel filtern, überspringen dadurch ganze Dateien (Data Skipping). Die Clustering-Schlüssel werden als Eigenschaft der Tabelle verwaltet und nicht dauerhaft im Verzeichnisaufbau festgeschrieben. Entwickelt wurde das Verfahren bei Databricks; das Delta-Projekt dokumentiert die allgemeine Verfügbarkeit im Open-Source-Format seit Delta Lake 3.2.
Dadurch wird die Wahl des Layouts deutlich flexibler: Die Clustering-Schlüssel können später per ALTER TABLE an neue Abfragemuster angepasst werden; ein vollständiger Neuaufbau der Tabelle ist dafür nicht zwingend erforderlich. Geeignete Schlüssel, ein sinnvolles Datenmodell und regelmäßige Wartung müssen weiterhin vom verantwortlichen Team festgelegt werden.
Wie das Transaktionslog, die Wartungs-Kommandos und die übrigen Format-Komponenten zusammenspielen, 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.
früh festgelegte Schlüssel
Bei Hive-Partitionierung und Z-Ordering müssen zentrale Layoutentscheidungen häufig getroffen werden, bevor die späteren Abfragemuster bekannt sind. Partitionsschlüssel werden bei der Tabellen-Anlage festgelegt, zu einem Zeitpunkt, an dem die langfristigen Zugriffsmuster oft noch nicht absehbar sind. Z-Order-Schlüssel lassen sich zwar pro Lauf wählen, ein OPTIMIZE ZORDER BY-Lauf kann dafür große Teile des Datenbestands neu schreiben und wird mit wachsender Tabelle teurer.
Klassische Partitionierung bringt zusätzlich zwei typische Probleme mit sich. Spalten mit vielen Ausprägungen, etwa Kunden-IDs, können sehr viele kleine Partitionen und Dateien erzeugen (das bekannte Small-Files-Problem). Bei ungleich verteilten Daten entstehen dagegen wenige sehr große Partitionen; Abfragen auf diese Bereiche können dadurch deutlich langsamer werden.
Eine grundlegende Korrektur erfordert im klassischen Modell meist einen Neuaufbau oder ein vollständiges Neuschreiben der Tabelle. Der hohe Aufwand führt häufig dazu, dass ungeeignete Schlüssel über lange Zeit beibehalten werden: Die Migration ist aufwendig und die Verantwortung dafür häufig nicht eindeutig geregelt, gleichzeitig steigen Abfragelaufzeiten und Compute-Kosten schrittweise. Damit wird eine technische Layoutentscheidung langfristig auch zu einer Kosten- und Governance-Frage.
| Achse | Hive-Partitionierung + Z-Ordering | Liquid Clustering |
|---|---|---|
| Schlüssel-Festlegung | bei Tabellen-Anlage, im Verzeichnis-Layout | am Tabellen-Schema per |
| Änderbarkeit | Korrektur erfordert Neuschreiben der Tabelle | Schlüssel-Wechsel per |
| Wartungslauf | schreibt den Bestand neu | arbeitet inkrementell |
| Eignung für Spalten mit vielen Ausprägungen | schwach (Small-Files-Problem) | geeignet |
| Verfügbarkeit | alle Delta-Versionen | Databricks Runtime ab 13.3 LTS, Delta OSS ab 3.2 |
Wie arbeitet Liquid Clustering?
Liquid Clustering ordnet die Daten schrittweise neu. Ein OPTIMIZE-Lauf auf einer geclusterten Tabelle verarbeitet vor allem neue oder noch nicht passend angeordnete Daten; bereits optimierte Dateien müssen dabei nicht erneut vollständig verarbeitet werden. Regelmäßige vollständige Z-Order-Läufe können dadurch häufig vermieden werden; zugleich sinkt das Konfliktrisiko zwischen Ladeprozessen und Wartungsläufen. Welche Rolle OPTIMIZE und VACUUM im laufenden Betrieb spielen und wie ein Wartungsplan je Tabellen-Klasse aussieht, führen wir unter Optimize & Vacuum aus.
Ein weiterer Vorteil ist die nachträgliche Änderung der Clustering-Schlüssel. Eine Änderung per ALTER TABLE ... CLUSTER BY ordnet bestehende Daten nicht sofort vollständig neu: Die neuen Schlüssel gelten für künftige Schreibvorgänge und Wartungs-Läufe, bestehende Daten werden bei späteren Wartungsläufen schrittweise in das neue Layout überführt. Soll der gesamte Bestand sofort neu angeordnet werden, ist dafür ein einmaliger OPTIMIZE FULL-Lauf erforderlich. Das Team kann damit selbst entscheiden, wann der vollständige Umbau wirtschaftlich und betrieblich sinnvoll ist, und ihn in ein Wartungsfenster legen.
Für die Einführung sind insbesondere drei Runtime-Stände relevant. Databricks dokumentiert die Empfehlung für alle neuen Delta-Tabellen samt Versions-Voraussetzungen in drei Stufen:
Runtime 13.3 LTS
Schreiben und Lesen von geclusterten Tabellen erstmals möglich.
Runtime 15.2
Liquid Clustering erreicht allgemeine Verfügbarkeit (GA).
Runtime 15.4 LTS
Automatische Schlüsselwahl per CLUSTER BY AUTO verfügbar.
Diese Funktionen und Empfehlungen beziehen sich auf die Databricks Runtime; in Delta Lake OSS stehen nicht alle Automatisierungsfunktionen der Databricks-Plattform zur Verfügung.
Zusätzlich kann die Auswahl und Wartung der Schlüssel automatisiert werden. Mit CLUSTER BY AUTO wählt die Plattform Clustering-Schlüssel anhand der tatsächlichen Abfrage-Historie und passt sie an, sofern dies einen ausreichenden Vorteil bietet. Databricks beschreibt mit Predictive Optimization zusätzlich einen Dienst, der OPTIMIZE, VACUUM und ANALYZE für verwaltete Unity-Catalog-Tabellen automatisch plant und ausführt. Diese Automatisierungsfunktionen setzen Unity Catalog voraus und sind spezifisch für die Databricks-Plattform; der Verfügbarkeits-Stand je Cloud gehört vor der Einführung geprüft.
Wann lohnt sich der Wechsel auf Liquid Clustering?
Für neue Tabellen sollte Liquid Clustering grundsätzlich geprüft werden, sobald die Runtime-Voraussetzungen erfüllt sind. Die gewählten Schlüssel lassen sich später mit geringerem Aufwand anpassen; damit sinkt das Risiko, langfristig an ungeeignete frühe Layoutentscheidungen gebunden zu sein. Bei bestehenden Tabellen sollte der konkrete Optimierungsbedarf entscheidend sein: Priorität haben Tabellen mit ungeeigneten Schlüsseln, hohen Optimierungskosten oder deutlich veränderten Abfragemustern; stabile Tabellen ohne messbare Probleme müssen nicht migriert werden.
| Ausgangslage | Layout-Empfehlung | Begründung | Voraussetzung |
|---|---|---|---|
| Neue Tabelle | Liquid Clustering als Standard prüfen | Schlüssel bleiben änderbar, Wartung läuft inkrementell | Runtime-Stand passt, alle Leser unterstützen das Tabellen-Protokoll |
| Bestehende Tabelle mit messbaren Performance- oder Kostenproblemen | einzeln migrieren, nach erwartetem wirtschaftlichem Nutzen priorisieren | unpassende Schlüssel und teure Sortier-Läufe verursachen laufende Compute-Kosten | Neuaufbau und Job-Umbau einplanen, Migrationsfenster abstimmen |
| Bestands-Tabelle stabil | beim klassischen Layout bleiben | eine Migration ohne konkretes Problem verursacht Aufwand, ohne zwingend einen messbaren Vorteil zu liefern | bestehende Wartungs-Läufe weiter betreiben |
Zwei Tabellentypen sollten bei der Migrationsplanung besonders berücksichtigt werden. Erstens Tabellen, deren wichtigste Filter-Spalten viele Ausprägungen haben und sich aufgrund ihrer hohen Kardinalität nur schlecht für klassische Partitionierung eignen. Zweitens Tabellen mit häufigen kleinen Schreibvorgängen, bei denen Optimierungs- und Ladeprozesse regelmäßig zeitlich oder technisch miteinander in Konflikt geraten.
Auf der anderen Seite stehen Profile, bei denen das klassische Layout weiterhin ausreichend sein kann, etwa Tabellen mit stabilen Abfragemustern oder Workloads, die stark von reinen Partitions-Operationen leben. Wann das klassische Mehrspalten-Layout die bessere Wahl bleibt und woran du das erkennst, klären wir im Überblick zu Z-Ordering.
der Weg und seine Prüfpunkte
Das geeignete Migrationsverfahren hängt von der bestehenden Tabellenstruktur und der eingesetzten Runtime-Version ab. Eine unpartitionierte Delta-Tabelle lässt sich per ALTER TABLE ... CLUSTER BY direkt umstellen; die vorhandenen Daten werden dabei nicht sofort neu geschrieben; sie werden über die folgenden Wartungs-Läufe in das neue Layout gebracht. Für partitionierte Tabellen dokumentiert Databricks ab Runtime 18.1 die direkte Konvertierung per REPLACE PARTITIONED BY WITH CLUSTER BY, die Lese- und Schreib-Unterbrechungen klein hält und sich über die Versionshistorie zurückrollen lässt. Bei älteren Runtime-Versionen ist weiterhin ein Neuaufbau der Tabelle erforderlich: neue Tabelle mit CLUSTER BY anlegen, Daten per CREATE TABLE AS SELECT überführen, umbenennen, alte Tabelle aufräumen. Ein ausführlicher Erfahrungsbericht zur Migration von hunderten partitionierten Tabellen zeigt, dass auch eine technisch einfache Umstellung zahlreiche abhängige Arbeiten auslösen kann.
Für die Schlüsselwahl beim Umstieg empfiehlt die Databricks-Doku, die bisherigen Partitions- und Z-Order-Spalten zunächst als Clustering-Schlüssel weiterzuverwenden. Deutlich veränderte Schlüssel können beim ersten Optimierungslauf einen umfangreichen Neuaufbau des Datenlayouts verursachen; eine spätere Anpassung an neue Abfragemuster bleibt danach jederzeit möglich.
Drei Prüfbereiche sind für eine erfolgreiche Migration besonders wichtig, sie bestimmen zugleich die Reihenfolge der Migration:
Leser-Kompatibilität prüfen
Alle Systeme und Clients erfassen, die auf die Tabelle zugreifen. Mit der Aktivierung steigt das Tabellen-Protokoll, ältere Engines verlieren sonst den Zugriff.
Wartungs-Jobs anpassen
Bestehende OPTIMIZE-Jobs mit ZORDER BY-Klauseln oder Partitions-Filtern vor der Migration umbauen, sonst schlagen sie auf geclusterten Tabellen fehl.
Abhängige Kopien und Klone aktualisieren
Klone und Prozesse, die das bisherige Partitionslayout voraussetzen, überprüfen und bei Bedarf neu erstellen.
Migration ausführen
Je nach Tabellenstruktur und Runtime-Version per ALTER TABLE, REPLACE PARTITIONED BY WITH CLUSTER BY oder Neuaufbau der Tabelle.
Bei größeren Plattformen ist eine schrittweise Migration über einen längeren Zeitraum üblich.
Grenzen
Liquid Clustering ermöglicht es, das Datenlayout später mit geringerem Aufwand anzupassen, und senkt die laufenden Wartungskosten aktiver Tabellen. Einige grundlegende Probleme liegen jedoch außerhalb des Verfahrens; diese Grenzen sollten bei der Bewertung des erwarteten Nutzens berücksichtigt werden.
Kein Ersatz für ein sauberes Datenmodell
Unklare Strukturen und ungeeignete Tabellenmodelle bleiben auch nach der Umstellung bestehen. Das Verfahren kann Abfragen nur dann wirksam optimieren, wenn die zugrunde liegende Tabellenstruktur sinnvoll ist.
Begrenzte Anzahl an Clustering-Schlüsseln
Maximal vier Clustering-Spalten sind möglich, und sie müssen zu den Spalten gehören, für die Delta Statistiken führt (standardmäßig die ersten 32 Spalten einer Tabelle).
Mehr Schlüssel können einzelne Abfragen verlangsamen
Auf kleineren Tabellen kann eine Abfrage, die nur auf eine einzige Spalte filtert, mit vier Schlüsseln langsamer laufen als mit einem oder zwei.
Metadatenbasierte Partitionsabfragen werden aufwendiger
Abfragen, die bisher allein aus den Partitions-Metadaten beantwortet wurden, etwa das Auflisten vorhandener Zeiträume, können auf geclusterten Tabellen zusätzlichen Datenzugriff erfordern.
Funktionsumfang unterscheidet sich zwischen Runtime und OSS
Automatische Schlüsselwahl und automatisierte Wartung gehören zur Databricks-Plattform. Tabellen außerhalb davon müssen hinsichtlich Protokollversion und Funktionsumfang separat geprüft werden.
Diese Einschränkungen zeigen den geeigneten Einsatzbereich des Verfahrens: Liquid Clustering ist die Layout-Komponente innerhalb des Delta-Formats, getragen von denselben Wartungs-Kommandos und demselben Transaktionslog wie der Rest der Plattform. Die Layoutentscheidung wird flexibler; die Auswahl geeigneter Schlüssel und der laufende Betrieb bleiben jedoch eine Aufgabe des verantwortlichen Teams.
Fazit
Liquid Clustering ist besonders sinnvoll, wenn sich Abfragemuster regelmäßig verändern und das bestehende Layout nicht flexibel angepasst werden kann.
Besonders geeignet ist das Verfahren für Plattformen, deren wichtigste Tabellen über Filter-Spalten mit vielen Ausprägungen abgefragt werden, bei denen regelmäßige Optimierungsläufe einen relevanten Anteil der Compute-Kosten verursachen oder deren Partitionsschlüssel nicht mehr zu den aktuellen Nutzungsmustern passen.
Typische Ausgangssituationen sind:
- Partitionsschlüssel, die zu den heutigen Abfragen nicht mehr passen, deren Anpassung aufgrund des hohen Aufwands wiederholt verschoben wird
- nächtliche Sortier-Läufe, die länger laufen und mehr kosten, je größer die Tabellen werden
- Lade-Jobs, die regelmäßig mit der Tabellen-Wartung kollidieren
- neue Tabellen, bei denen die langfristigen Abfragemuster zum Zeitpunkt der Erstellung noch nicht bekannt sind
Bestehende Tabellen mit guten Laufzeiten und stabilen Zugriffsmustern müssen dagegen nicht migriert werden; in diesen Fällen kann der Migrationsaufwand den erwarteten Nutzen übersteigen. Dasselbe gilt für Tabellen, deren Leser das nötige Tabellen-Protokoll noch nicht unterstützen.
Mein Vorschlag: Liquid Clustering für neue Tabellen als bevorzugte Option prüfen und gegebenenfalls als Standard festlegen, sobald Runtime-Stand und Leser-Landschaft das tragen, und parallel bestehende Tabellen nach Performanceproblemen, Wartungskosten und Migrationsaufwand priorisieren. Als erste Kandidaten eignen sich die Tabellen mit den höchsten Optimierungskosten und längsten Abfragelaufzeiten; weitere Tabellen können anschließend nach erwartetem Nutzen migriert oder bewusst im bestehenden Layout belassen werden. Dadurch lässt sich die Umstellung schrittweise und mit messbaren Ergebnissen pro Tabelle durchführen.
Liquid Clustering für neue Tabellen als bevorzugte Option prüfen und bestehende Tabellen zuerst nach den höchsten Optimierungskosten und längsten Abfragelaufzeiten priorisieren.
FAQ
Die Tabelle organisiert ihre Daten anhand von Clustering-Schlüsseln, die per am Tabellen-Schema definiert sind. Reguläre -Läufe ordnen neue Daten inkrementell in dieses Layout ein. Die Schlüssel lassen sich später per ändern, ohne die Tabelle neu aufzubauen. Mit der Aktivierung steigt zugleich die Protokoll-Version der Tabelle, was ältere Leser ausschließen kann.
