Partitionering (partitioning)

Wat is partitionering?

Partitionering splitst een grote tabel op in stukken op basis van de waarde van een kolom. Je kiest een kolom, bijvoorbeeld de maand of de regio, en de data wordt fysiek uit elkaar getrokken: alle rijen van maart bij elkaar, alle rijen van april apart. Elk stuk heet een partitie.

Het punt is niet de opslag zelf, maar wat een query daarna nog moet lezen. Vraag je enkel de omzet van maart 2026, dan opent de engine alleen de partitie van maart en laat hij de rest dicht. Dat overslaan van niet-relevante partities heet partition pruning, en het is de hele reden waarom je partitioneert.

Vergelijk het met een klassementkast met een lade per jaar: zoek je een factuur van 2023, dan trek je die ene lade open in plaats van elke map na te kijken.

Hoe ziet een partitie eruit op schijf?

Bij bestandsformaten zoals Parquet is een partitie letterlijk een map. De engine maakt een submap per partitiewaarde en zet de kolomnaam in het pad. Een verkooptabel gepartitioneerd op maand ziet er zo uit:

• verkoop/maand=2026-01/

• verkoop/maand=2026-02/

• verkoop/maand=2026-03/

Apache Spark, Hive en de meeste lake-engines herkennen dat patroon automatisch: uit het pad maand=2026-03 leiden ze af dat elke rij in die map bij maart 2026 hoort. Filter je op maand, dan weet de engine meteen welke mappen hij mag overslaan. Een Delta Lake-tabel bewaart de data ook in Parquet-mappen, maar leest uit zijn transactielog welke bestanden bij welke partitie horen.

Wat partitionering oplevert

Drie dingen worden beter zodra de partitiesleutel bij je vragen past.

Snellere queries
Minder data lezen betekent minder werk. Een rapport over één maand hoeft niet door vijf jaar historiek te ploegen.

Goedkopere scans
Op cloud storage betaal je per gescande byte. Engines zoals BigQuery en Athena rekenen af op de data die een query aanraakt, dus wie maar één van de zestig partities leest, betaalt een fractie.

Eenvoudiger opruimen
Data ouder dan twee jaar weggooien wordt één partitie droppen in plaats van miljoenen rijen zoeken en verwijderen. Bij partitionering per datum is dat een operatie op de metadata, zonder dat er één rij gescand wordt.

Voorbeeld: een verkooptabel per maand

Partitioneren op datum is in een data warehouse al lang de klassieke aanpak. Stel, je bewaart vijf jaar kassaverkopen, samen zo'n 300 miljoen rijen, en je partitioneert op verkoopmaand. Dat geeft zestig partities. De meeste rapporten kijken naar een recente periode en filteren op datum, waardoor ze hooguit een handvol partities aanraken: in plaats van 300 miljoen rijen leest de engine er een paar miljoen.

De keerzijde toont zich zodra iemand een vraag stelt die de sleutel negeert, zoals de totale omzet per productcategorie over alle jaren. Dat filter zegt niets over de maand, dus moeten alle zestig partities open en levert de indeling niets op.

Partitionering versus clustering en Z-ordering

Partitionering is een grove indeling: één map per waarde van de sleutel. Clustering en Z-ordering werken fijner. Zij verplaatsen geen data naar aparte mappen. In plaats daarvan ordenen ze de rijen binnen de bestanden zo dat waarden die vaak samen opgevraagd worden ook dicht bij elkaar op schijf staan. De engine slaat dan hele blokken over op basis van min- en max-statistieken, zonder mappenstructuur.

Het verschil zit in cardinaliteit, het aantal unieke waarden van een kolom. Partitionering werkt goed voor kolommen met weinig of voorspelbaar veel waarden: een datum, een regio, een land. Voor kolommen met heel veel unieke waarden, zoals een klant-ID of een exacte tijdstempel, is clustering de betere keuze. Databricks raadt op zijn platform voor de meeste tabellen zelfs liquid clustering aan in plaats van partitionering.

Een goede partitiesleutel kiezen

De sleutel staat of valt bij één vraag: waarop filteren je queries meestal? Een partitie levert alleen iets op als je queries er ook echt op filteren. Twee vuistregels helpen:

• Kies een kolom waarop vaak gefilterd wordt en houd de cardinaliteit laag of voorspelbaar. Voor de meeste feitentabellen is dat een datum: verkoopdag, boekingsmaand of factuurjaar. Per seconde of per klant-ID geeft veel te veel partities.

• Mik op partities van behoorlijke omvang. Databricks noemt als richtlijn minstens 1 GB per partitie, en merkt op dat minder maar grotere partities beter presteren dan veel kleine.

Zo raakt partitionering aan granulariteit: hoe fijner je per rij bewaart, hoe meer rijen per partitie en hoe belangrijker de sleutelkeuze wordt.

Waar moet je op letten bij het gebruik van partitionering

Te fijn partitioneren
Elke partitie is minstens één bestand. Partitioneer je op een kolom met duizenden waarden, dan krijg je duizenden mapjes met elk een handvol rijen. Al die kleine bestanden openen en samenvoegen kost meer tijd dan het scannen dat je wou vermijden. Dit is het klassieke probleem van te kleine bestanden.

Een sleutel waarop niemand filtert
Partitioneren op een kolom die in de rapporten nooit als filter terugkomt, versnelt niets: de engine moet dan toch elke partitie openen. Kies de sleutel op basis van hoe er gevraagd wordt, niet op wat logisch lijkt in het bronsysteem.

Partitioneren terwijl je tabel te klein is
Onder een bepaalde omvang levert partitionering meer overhead op dan winst. Databricks stelt zelfs dat je tabellen onder ongeveer 1 TB beter helemaal niet partitioneert. De indeling betaalt zich pas terug op echt grote volumes.

De sleutel is moeilijk te wijzigen
Een tabel anders partitioneren betekent bijna altijd alle data herschrijven, en op grote tabellen is dat traag en duur. Kies de sleutel dus goed vóór je de tabel op volume laat komen.