Z-ordering (data clustering)

Wat is Z-ordering?

Z-ordering is een techniek die rijen met gelijkaardige waarden samen in dezelfde bestanden zet, en dat over meerdere kolommen tegelijk. Bij een gewone tabel liggen je records verspreid over veel Parquet-bestanden zonder enige ordening. Z-ordering herschikt ze zodat records die je vaak samen opvraagt, ook fysiek bij elkaar terechtkomen.

Het idee komt uit de wereld van Delta Lake en lakehouse-tabellen, waar je data als losse bestanden op goedkope opslag staat. Vergelijk het met een magazijn: zet je de dozen zo dat bestellingen van dezelfde klant en regio bij elkaar staan, dan volstaat het om een paar rekken te bekijken in plaats van de hele hal. Z-ordering zorgt ervoor dat de meeste bestanden op voorhand overgeslagen worden.

Hoe werkt data skipping?

Z-ordering leunt volledig op data skipping. Delta bewaart per bestand de kleinste en grootste waarde van elke kolom, plus het aantal rijen en lege velden. Bij een query kijkt de engine naar die min- en max-waarden en slaat elk bestand over waarvan zeker is dat de gezochte waarde er niet in zit.

Dat overslaan werkt alleen als elk bestand een smalle reeks waarden bevat. Ligt de klant-id in elk bestand ergens tussen 1 en 999.999, dan helpt de min-max-truc niks. Z-ordering knijpt die reeksen samen, zodat een bestand enkel klanten 4000 tot 4200 uit regio Antwerpen bevat. Filter je op klant en regio tegelijk met ZORDER BY klant_id, regio, dan liggen de rijen voor die combinatie in enkele bestanden en leest dezelfde query nog maar een fractie van de data.

Z-ordering versus partitionering

De vraag die altijd terugkomt: wat is het verschil met partitionering? Beide verminderen hoeveel data een query leest, maar ze werken op een ander niveau. Partitionering splitst je tabel op in aparte mappen op een kolom met weinig verschillende waarden, zoals een map per jaar of per land. Dat werkt goed zolang je bijna altijd op die kolom filtert. Kies je een kolom met veel verschillende waarden, zoals een timestamp of een klant-id, dan krijg je duizenden minuscule mappen met piepkleine bestanden, en net dat maakt queries traag.

Z-ordering werkt fijner, binnen de bestanden zelf, en net op die hoog-cardinale kolommen waar partitionering faalt. Je legt geen mappenstructuur op, je herschikt de inhoud, en je kan op meerdere kolommen tegelijk ordenen. Vuistregel: partitioneer op grove assen zoals datum, en gebruik Z-ordering voor de kolommen met veel unieke waarden waarop je vaak filtert.

Hoe pas je Z-ordering toe?

In Delta Lake gebeurt dat met het OPTIMIZE-commando, gevolgd door de kolommen waarop je wil ordenen:

OPTIMIZE verkoop ZORDER BY (klant_id, regio)

• Hou het aantal kolommen beperkt. De winst zakt met elke extra kolom. Twee tot drie kolommen waarop je echt vaak samen filtert, is doorgaans het maximum dat nog iets oplevert.

• De kolommen hebben statistieken nodig. Data skipping steunt op de min-max-statistieken per bestand. Z-orderen op een kolom zonder die statistieken levert niks op.

• Het is geen eenmalige actie. Z-ordering is niet idempotent: telkens je nieuwe data toevoegt, moet je OPTIMIZE opnieuw draaien om de ordening te herstellen. Plan het als terugkerend onderhoud.

Liquid clustering als opvolger

Voor nieuwe tabellen raadt Databricks intussen liquid clustering aan in plaats van ZORDER. Die aanpak wil zowel partitionering als Z-ordering vervangen. Je definieert clustersleutels met CLUSTER BY en de engine houdt de ordening zelf bij. Het grote voordeel: je kan die sleutels achteraf aanpassen zonder de bestaande data te herschrijven, en het werkt voor zowel lage als hoge cardinaliteit.

Je kan ZORDER en liquid clustering niet samen op dezelfde tabel gebruiken. Draai je op bestaande Delta-tabellen die al met OPTIMIZE ZORDER werken, dan blijft die aanpak prima. Voor een verse tabel is liquid clustering vaak de eenvoudiger keuze.

Wanneer is Z-ordering de moeite?

Z-ordering loont bij grote tabellen waarop queries steeds op dezelfde paar hoog-cardinale kolommen filteren, denk aan een verkooptabel van miljoenen rijen die je bijna altijd per klant of per artikel bevraagt. Voor kleine tabellen is het de moeite niet: leest een query toch alles in een keer, dan valt er niks over te slaan. En OPTIMIZE kost zelf rekentijd en dus geld, dus orden enkel waar het telt.