Z-Ordering in Delta Lake: Was das klassische Layout noch leistet
Z-Ordering erklärt: wie OPTIMIZE ZORDER BY Abfragen über Data Skipping beschleunigt, was die Läufe kosten und wann der Wechsel auf Liquid Clustering ansteht.
Die Kernaussagen auf einen Blick.
- Z-Ordering ist ein etabliertes Verfahren, um Delta-Tabellen entlang mehrerer Spalten zu organisieren: sortiert die Daten so, dass Abfragen über Data Skipping weniger Dateien lesen.
- Das Verfahren ist zuverlässig, erfordert jedoch regelmäßige und teilweise aufwendige Optimierungsläufe, deren Wirkung durch neue Schreibvorgänge schrittweise nachlässt.
- Bei bestehenden Tabellen sollten drei Aspekte bewertet werden: die Stabilität der Abfragemuster, die Passung der gewählten Schlüssel und die Entwicklung der Lauf-Kosten.
- Empfehlenswert ist, stabile Z-geordnete Tabellen mit geplanten Wartungsläufen weiterzubetreiben und bei Tabellen mit veränderten Abfragemustern oder steigenden Wartungskosten einen Wechsel zu Liquid Clustering zu prüfen.
Inhaltsverzeichnis
Wenn der nächtliche OPTIMIZE-Lauf nicht mehr in das Wartungsfenster passt
Eine Bestell-Tabelle ist nach Datum partitioniert und wird seit Jahren per OPTIMIZE ZORDER BY nach Kunden-ID und Filiale sortiert. Der nächtliche Lauf dauerte anfangs zwanzig Minuten und benötigt inzwischen mehrere Stunden. Ein neues Dashboard filtert überwiegend nach Produktkategorie, die bisher nicht als ZORDER-Spalte berücksichtigt wird. Und die ursprüngliche Auswahl von Kunden-ID und Filiale ist im Team nicht mehr nachvollziehbar dokumentiert.
Diese Situation tritt häufig in Delta-Plattformen auf, die bereits mehrere Jahre betrieben werden: Das Layout wurde zu Beginn festgelegt, danach aber nicht mehr regelmäßig überprüft. Gleichzeitig haben sich Datenvolumen und Abfragemuster verändert. Dazu kommt die Empfehlung von Databricks, für neue Tabellen Liquid Clustering einzusetzen; dadurch stellt sich die Frage, welche bestehenden Tabellen tatsächlich migriert werden sollten.
Unterstützt das bestehende Layout die aktuellen Abfragen noch ausreichend, oder optimieren wir weiterhin für Zugriffsmuster, die heute kaum noch relevant sind? Wird Z-Ordering weiterhin unterstützt? Was gilt für Tabellen, die von Engines außerhalb von Databricks gelesen werden? Ist eine Migration auch bei Tabellen sinnvoll, die aktuell keine messbaren Probleme verursachen?
Bestehende Z-geordnete Tabellen sollten einzeln anhand ihrer Nutzung und Kosten bewertet werden: weiterbetreiben, wo Schlüssel und Abfragemuster zusammenpassen; den Wechsel prüfen, wo sich Abfragemuster deutlich verändert haben oder die Wartungskosten steigen.
Was ist Z-Ordering in Delta Lake?
Z-Ordering ist ein Verfahren zur physischen Anordnung von Delta-Daten anhand mehrerer Spalten: Mit dem Kommando OPTIMIZE <tabelle> ZORDER BY (spalte1, spalte2) werden Zeilen mit ähnlichen Werten in den gewählten Spalten möglichst in denselben Dateien abgelegt. Mathematisch beruht das auf der Z-Order-Kurve, auch Morton-Order genannt: eine raumfüllende Kurve, die mehrere Dimensionen auf eine einzige Sortierreihenfolge abbildet und dabei räumlich oder logisch ähnliche Werte möglichst nahe beieinander anordnet. Das Verfahren gehört zum Open-Source-Projekt Delta Lake und steht damit auch außerhalb der Databricks-Plattform zur Verfügung.
Z-Ordering kann die Anzahl der Dateien reduzieren, die eine Abfrage lesen muss. Filtert eine Abfrage auf den ZORDER-Spalten, kann die Engine nicht relevante Dateien vollständig überspringen (Data Skipping); dadurch wird häufig nur ein Teil des Datenbestands gelesen, was Laufzeit und Compute-Verbrauch deutlich reduzieren kann. Filter auf Spalten außerhalb der gewählten Schlüssel, das Datenmodell und die Pflege kleiner Dateien werden durch das Verfahren nicht verbessert.
Wie das Transaktionslog, die Datei-Statistiken 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.
Wie beschleunigt Z-Ordering Abfragen?
Die Beschleunigung basiert auf den Statistiken der einzelnen Datendateien. Delta Lake führt im Transaktionslog je Datei Minimal- und Maximalwerte; Microsoft Learn dokumentiert, dass diese Statistiken standardmäßig für die ersten 32 Spalten einer Tabelle erfasst werden. Bei einer gefilterten Abfrage vergleicht die Engine den Filterwert mit diesen Bereichen; jede Datei, deren Wertebereich den gesuchten Wert nicht enthalten kann, wird ausgelassen. Z-Ordering verbessert die Wirksamkeit dieses Data Skipping: Da ähnliche Werte in denselben Dateien gebündelt werden, werden die Minimal- und Maximalwerte pro Datei präziser abgegrenzt, und der Anteil übersprungener Dateien steigt deutlich.
Im Zusammenspiel mit der Partitionierung ergibt sich das klassische Muster: Die Partitionierung grenzt größere Datenbereiche ab, während Z-Ordering die Daten innerhalb dieser Bereiche feiner organisiert. Eine Spalte mit wenigen Ausprägungen, etwa das Datum, teilt die Tabelle in Partitionen, die bei passenden Filtern vollständig übersprungen werden können (Partition Pruning, der Beschnitt ganzer Partitionen). Innerhalb dieser Partitionen ordnet Z-Ordering die Daten nach häufig verwendeten Filterspalten mit vielen Ausprägungen, etwa Kunden-IDs. Das Delta-Projekt beschreibt dieses Zusammenspiel samt Faustregeln zur Layout-Wahl je Tabellengröße: Tabellen unter rund einem Terabyte im Regelfall gar nicht partitionieren, und jede Partition sollte mindestens ein Gigabyte Daten tragen. Zwei Einschränkungen sollten bei der Planung berücksichtigt werden: Die Sortierung wirkt nur innerhalb einer Partition, und die Partitions-Spalten selbst können in keinem ZORDER-Schlüssel stehen.
Mit jeder zusätzlichen ZORDER-Spalte verteilt sich der Optimierungseffekt auf mehr Dimensionen. In der Praxis gelten drei bis vier ZORDER-Spalten häufig als sinnvolle Obergrenze. Spalten, die nicht regelmäßig in Filtern verwendet werden, erhöhen den Optimierungsaufwand ohne entsprechenden Nutzen, und Spalten außerhalb der erfassten Statistiken verbessern das Data Skipping nicht. An der Bestell-Tabelle aus dem Einstieg zeigt sich beides: Die Abfragen nach Kunden-ID laufen schnell, das neue Dashboard auf der Produktkategorie muss weiterhin große Teile des Tagesbestands lesen.
Was verlangt Z-Ordering im Betrieb?
OPTIMIZE ZORDER BY schreibt die betroffenen Datenbereiche weitgehend neu: Enthält eine Partition neue Daten, wird ihr Inhalt beim nächsten Lauf erneut sortiert und geschrieben; bereits sortierte Partitionen ohne neue Daten bleiben unangetastet. Bei häufig aktualisierten Tabellen sind dadurch regelmäßig viele Partitionen betroffen, und neue Daten werden zunächst nicht vollständig in die bestehende Sortierung eingeordnet. Daraus ergibt sich der Bedarf an regelmäßigen Wartungsläufen in einem Wartungsfenster, deren Laufzeiten und Compute-Kosten mit dem Datenvolumen steigen können. Der Lauf der Bestell-Tabelle ist deshalb von zwanzig Minuten auf Stunden angewachsen, auch wenn der Prozess technisch korrekt konfiguriert ist.
Ein weiterer betrieblicher Aufwand entsteht durch die Auswahl und Pflege der ZORDER-Spalten. Die Spalten lassen sich zwar bei jedem Lauf neu angeben, eine geänderte Spaltenwahl wirkt aber erst vollständig, nachdem die betroffenen Daten erneut optimiert wurden. Verschieben sich die Abfragemuster, entsteht damit jedes Mal erneut erheblicher Schreib- und Compute-Aufwand. Die Auswahl der ZORDER-Spalten hat direkte Auswirkungen auf Wartungskosten und Laufzeiten, und sie gehört dokumentiert: Ohne regelmäßige Überprüfung kann eine Tabelle dauerhaft für veraltete Zugriffsmuster optimiert werden.
Zusätzlich müssen die durch OPTIMIZE entstehenden alten Dateien regelmäßig bereinigt werden. Jeder Lauf erzeugt neue Dateien und lässt die alten als veraltete Versionen zurück, der Speicherverbrauch steigt vorübergehend deutlich. Die Databricks-Knowledge-Base empfiehlt deshalb, OPTIMIZE-Läufe mit VACUUM nach Ablauf der Aufbewahrungsfrist zu koppeln, damit nicht mehr benötigte Dateien nach Ablauf der Aufbewahrungsfrist entfernt werden. Wie ein Wartungsplan aus Kompaktierung und Aufräum-Läufen je Tabellen-Klasse aussieht, führen wir unter Optimize & Vacuum aus.
vier Kriterien für den Bestand
Neben der Bestell-Tabelle aus dem Einstieg steht in derselben Plattform eine Abrechnungs-Tabelle: gleiche Filter seit Jahren, Schlüssel dokumentiert, der Lauf bleibt im Wartungsfenster und im Budget. Für diese Tabelle besteht derzeit kein konkreter Änderungsbedarf, und solche stabilen Tabellen bilden in bestehenden Plattformen häufig einen großen Teil des Bestands. Z-Ordering auf Databricks und in Delta Lake OSS (der Open-Source-Variante des Formats) ist weiterhin ein etabliertes und gut dokumentiertes Verfahren; für Umgebungen, die auf älteren Runtime-Ständen laufen oder von Engines außerhalb der Plattform gelesen werden, bietet es häufig die größte Kompatibilität.
| Kriterium | Weiterbetreiben | Wechsel prüfen |
|---|---|---|
| Abfragemuster | stabil, Filter treffen die ZORDER-Spalten | neue Abfragen filtern an den Schlüsseln vorbei |
| Schlüssel-Passung | Spaltenwahl ist dokumentiert und begründbar | die Spaltenwahl ist nicht mehr dokumentiert oder fachlich begründbar |
| OPTIMIZE-Läufe | Dauer und Kosten bleiben planbar im Wartungsfenster | Laufzeiten und Kosten steigen ohne erkennbaren Performancegewinn |
| Umgebung | Delta Lake OSS, ältere Runtime-Stände, externe Leser | aktuelle Databricks Runtime ohne Kompatibilitäts-Zwänge |
Die Bewertung sollte für jede Tabelle separat erfolgen: Dieselbe Plattform kann stabile Z-geordnete Tabellen und klare Wechsel-Kandidaten enthalten. Stabile Tabellen können planmäßig weiterbetrieben werden, während problematische Tabellen gezielt priorisiert werden.
Wann steht der Wechsel auf Liquid Clustering an?
Drei Merkmale sprechen dafür, einen Wechsel zu Liquid Clustering zu prüfen.
Abfragemuster haben sich verändert
Die häufigsten Filter verwenden die vorhandenen ZORDER-Spalten nur noch selten: Das Dashboard auf der Produktkategorie ist das typische Beispiel.
Spalten-Anpassung wird aufgeschoben
Die ZORDER-Spalten müssten angepasst werden, doch die Anpassung wird aufgrund des hohen Umschreibungsaufwands wiederholt verschoben.
Wartungskosten laufen aus dem Ruder
Laufzeit und Compute-Kosten der Wartung steigen deutlich: Das Wartungsfenster reicht nicht mehr, und die Kosten stehen zunehmend nicht mehr im Verhältnis zum erzielten Performancegewinn.
Für neue Tabellen empfiehlt Databricks inzwischen Liquid Clustering: Databricks dokumentiert die Empfehlung, das Verfahren für alle neuen Tabellen einzusetzen; Liquid Clustering ersetzt dort Partitionierung und ZORDER und ist für Delta-Tabellen seit Runtime 15.2 allgemein verfügbar. Diese Empfehlung gilt für die Databricks Runtime und für die Neuanlage; das bedeutet jedoch nicht, dass bestehendes Z-Ordering nicht mehr unterstützt wird. Im Open-Source-Projekt Delta Lake bleibt Z-Ordering regulär verfügbar, während Liquid Clustering dort seit Version 3.2 mit kleinerem Funktionsumfang enthalten ist.
Eine Tabelle kann nicht gleichzeitig Z-Ordering und Liquid Clustering verwenden: Eine Delta-Tabelle nutzt entweder das klassische Layout aus Partitionierung und Z-Ordering oder Liquid Clustering. Der Umstieg muss deshalb für jede Tabelle einzeln geplant werden; dabei müssen Tabellenprotokoll, Wartungsjobs und externe Leser geprüft und angepasst werden. Wie dieser Umstieg abläuft und wann er sich rechnet, klären wir im Überblick zu Liquid Clustering.
| Achse | Z-Ordering | Liquid Clustering |
|---|---|---|
| Festlegung | je Lauf als Klausel im OPTIMIZE-Kommando | per am Tabellen-Schema |
| Lauf-Art | Voll-Lauf über den betroffenen Bestand | inkrementelle -Läufe |
| Schlüssel-Änderung | erneutes Umschreiben des Bestands | , Bestand folgt schrittweise |
| Verfügbarkeit | Delta Lake OSS und alle Runtime-Stände | Databricks Runtime ab 13.3 LTS, Delta OSS ab 3.2 |
| Typischer Einsatz | Bestands-Tabellen mit stabilen Abfragemustern | neue Tabellen, wechselnde Abfragemuster |
Grenzen
Z-Ordering verbessert vor allem Abfragen, die auf den ausgewählten Spalten filtern, und macht große Tabellen für stabile Workloads planbar schnell. Für eine vollständige Performance-Strategie sind darüber hinaus Datenmodell, Statistiken und Wartung erforderlich.
Nur ausgewählte Spalten profitieren
Abfragen auf andere Spalten lesen weiter den vollen Bestand. Verschieben sich die Abfragemuster, nimmt der Nutzen des Layouts schrittweise ab, ohne dass ein technischer Fehler auftritt: Die Abfragen werden einfach langsamer und teurer.
Kein Ersatz für Datenmodellierung
Eine ungeeignete Tabellenstruktur wird durch Sortierung nicht verbessert. Die Sortierung beschleunigt Zugriffe auf ein tragfähiges Modell. Fehlende Modellierung und wild gewachsene Strukturen muss das Team vorher lösen.
Abhängig von Dateistatistiken
Data Skipping greift über die Min/Max-Statistiken, die Delta standardmäßig für die ersten 32 Spalten führt. ZORDER-Spalten außerhalb dieser Abdeckung verursachen Optimierungsaufwand, ohne das Data Skipping zu verbessern. Der Default lässt sich über Tabellen-Eigenschaften anpassen.
Layout verschleißt mit jedem Schreibvorgang
Neue Daten kommen zunächst unsortiert an. Ohne wiederkehrende, budgetierte Läufe kehrt das Small-Files-Problem zurück, und der Nutzen einer einmaligen Optimierung nimmt deutlich ab.
Wartung bleibt Team-Verantwortung
Das Verfahren regelt Wartungsrhythmus, Kostenkontrolle und Monitoring nicht von selbst. Ohne klaren Wartungsplan entstehen Wartungsläufe, deren Zweck und Konfiguration nach einiger Zeit nicht mehr nachvollziehbar sind.
Diese Einschränkungen zeigen, für welche Tabellen Z-Ordering geeignet ist: Es ist die Layout-Komponente des klassischen Delta-Betriebs, getragen von OPTIMIZE, VACUUM und dem Transaktionslog, und bleibt eine verlässliche Wahl für stabile Bestände. Voraussetzung ist ein klar definierter und regelmäßig überprüfter Wartungsprozess.
Sobald Wartungskosten deutlich steigen oder die wichtigsten Abfragen nicht mehr von den ZORDER-Spalten profitieren, beginnt die Wechsel-Prüfung; für den übrigen Bestand ist ein dokumentierter Wartungsplan mit budgetierten Läufen die wichtigste Maßnahme.
Fazit
Z-Ordering bleibt sinnvoll, solange die gewählten Spalten zu den tatsächlichen Abfragen passen und die Wartungskosten planbar bleiben.
Besonders geeignet ist das Verfahren für bestehende Tabellen mit langfristig stabilen Filtermustern, für Umgebungen auf Delta Lake OSS oder älteren Runtime-Ständen und für Tabellen, die von Engines außerhalb der Plattform gelesen werden.
Typische Merkmale sinnvoll optimierter Tabellen sind:
- Abfragen, die dauerhaft auf denselben dokumentierten Spalten filtern
- OPTIMIZE-Läufe, die im Wartungsfenster und im Compute-Budget bleiben
- Leser außerhalb von Databricks, die auf das klassische Tabellen-Protokoll angewiesen sind
Ein Wechsel sollte dagegen bei problematischen Tabellen geprüft werden: Tabellen mit veränderten Abfragemustern, unerklärbaren Schlüsseln oder Optimierungsläufen, deren Kosten stärker steigen als der erzielte Performancegewinn. Bei stabilen Tabellen kann eine Migration mehr Aufwand als Nutzen verursachen.
Mein Vorschlag: den bestehenden ZORDER-Bestand systematisch erfassen und bewerten. Für jede Tabelle die ZORDER-Spalten mit den realen Abfragemustern vergleichen, zusätzlich Laufzeiten und Compute-Kosten der OPTIMIZE-Läufe aus den letzten Monaten auswerten und daraus zwei Listen bilden: Stabile Tabellen erhalten einen dokumentierten Wartungsplan mit planbaren Kosten, problematische Tabellen werden priorisiert auf eine Migration zu Liquid Clustering geprüft. So bleibt Z-Ordering eine bewusst betriebene Layoutentscheidung und kein ungeprüfter Prozess mit dauerhaftem Compute-Verbrauch.
Den bestehenden ZORDER-Bestand systematisch erfassen: ZORDER-Spalten mit den realen Abfragemustern abgleichen und Laufzeiten sowie Compute-Kosten der letzten Monate auswerten.
FAQ
Z-Ordering ist ein Daten-Layout-Verfahren für Delta-Tabellen, das Daten entlang mehrerer Spalten sortiert. Das Kommando legt Zeilen mit ähnlichen Werten in dieselben Dateien, sodass Abfragen mit Filtern auf diesen Spalten über Data Skipping ganze Dateien überspringen. Das Verfahren gehört zum Open-Source-Projekt Delta Lake und steht auf Databricks wie in eigenständigen Delta-Umgebungen zur Verfügung.
