Parquet

Wat is Parquet?

Apache Parquet is een open bestandsformaat voor gestructureerde data, geoptimaliseerd voor analytische queries. In plaats van rijen na elkaar op te slaan (zoals CSV of JSON), slaat Parquet de waarden per kolom samen op. Dat lijkt een detail, maar het levert op grote datasets orden van grootte snellere queries en veel kleinere bestanden op.

Parquet werd in 2013 gelanceerd door Twitter en Cloudera en is intussen de de facto standaard in het Hadoop- en lakehouse-ecosysteem. Het zit als onderliggende laag in Microsoft Fabric, Databricks, Snowflake (bij externe tabellen), Amazon S3, Azure Data Lake en zowat elke data-engineer-toolkit.

Je kan Parquet vergelijken met het verschil tussen een papieren klassement en een kolommenboek. Wil je alle salarissen optellen, dan hoef je in een kolommenboek enkel de salariskolom van boven naar onder te lopen. In een rij-gebaseerd systeem moet je elke dossiermap openslaan en de juiste pagina zoeken.

Waarom kolomgeoriënteerde opslag?

Analytische queries vragen meestal weinig kolommen tegen veel rijen: som van de omzet per maand, aantal klanten per regio. Bij rij-gebaseerde opslag moet je voor elke rij de hele record inlezen, ook de kolommen die je niet gebruikt. Bij kolomgeoriënteerde opslag lees je enkel de kolommen die je nodig hebt.

Drie voordelen vloeien daaruit voort:

I/O-besparing
Een query die enkel drie van de zeventig kolommen gebruikt, leest effectief maar een fractie van de data van de schijf of uit blob storage. Op cloud storage waar je per byte betaalt, scheelt dat direct op je factuur.

Betere compressie
Waarden binnen één kolom lijken op elkaar (zelfde datatype, vaak zelfde schaal). Compressie-algoritmes als Snappy, Zstd of GZIP halen daar veel meer uit dan uit gemengde rij-data. Parquet-bestanden zijn typisch twee tot tien keer kleiner dan een CSV met dezelfde inhoud.

Vectorized execution
Moderne query-engines verwerken kolomwaarden in batches op CPU- of GPU-niveau. Dat is veel sneller dan rij per rij interpreteren.

Hoe is een Parquet-bestand opgebouwd?

Een Parquet-bestand is geen simpele platte lijst. Het bestaat uit meerdere lagen die samen efficiënt zoeken mogelijk maken.

Row groups
Een bestand wordt opgedeeld in blokken van typisch 128 MB, elk een row group. Per row group wordt elke kolom apart opgeslagen. Dat maakt parallelle verwerking per row group mogelijk.

Column chunks en pages
Binnen een row group zijn de waarden per kolom gegroepeerd in column chunks, die op hun beurt uit pages bestaan. Op page-niveau gebeurt de compressie.

Statistieken en indexen
Per column chunk bewaart Parquet min- en max-waarden, aantal nulls en soms een bloom filter. Query-engines gebruiken die om hele chunks over te slaan als de gevraagde waarde er niet in kan zitten. Dat heet predicate pushdown en zorgt voor dramatische versnellingen.

Schema in de voet
Aan het eind van het bestand zit een footer met het volledige schema, datatypes, codering en statistieken. Daardoor kan elke lezer een Parquet-bestand zonder extra metadata interpreteren.

Parquet versus CSV, JSON en ORC

Parquet versus CSV
CSV is rij-gebaseerd, tekst, zonder schema. Prima voor kleine uitwisseling tussen systemen. Voor alles wat groter wordt dan een paar miljoen rijen is Parquet sneller, kleiner en veiliger (want getypeerd).

Parquet versus JSON
JSON is flexibel voor geneste structuren maar verspilt ruimte met herhaalde sleutelnamen. Parquet ondersteunt ook geneste structuren (lists, maps, structs) en doet dat veel efficiënter.

Parquet versus ORC
ORC is een vergelijkbaar kolomgeoriënteerd formaat uit het Hive-ecosysteem. Technisch nauw verwant, maar Parquet heeft in de praktijk gewonnen omdat het beter ondersteund wordt buiten Hadoop, onder meer door Python, Spark en alle lakehouse-spelers.

Parquet als basis van Delta en Iceberg

Delta Lake, Apache Iceberg en Apache Hudi slaan hun gegevens allemaal op als Parquet-bestanden onder de motorkap. Wat die formaten toevoegen is een transactielog en metadata, niet een ander opslagformaat. Een lakehouse-tabel is dus in essentie een map met Parquet-bestanden plus een log die beschrijft welke bestanden bij welke versie horen.

Dat is precies de reden waarom open formaten zo belangrijk zijn: je data zit niet vast in een propriëtaire binary. Elk tool dat Parquet kan lezen (Python, Spark, Trino, DuckDB) kan ook rechtstreeks met je lakehouse aan de slag, zij het zonder transactionele garanties.

Valkuilen

Te kleine bestanden
Parquet is gemaakt voor grote bestanden. Als je ETL elke minuut een nieuw Parquet-bestand van 2 MB schrijft, verlies je de kolom-voordelen en krijg je trage queries. Plan een compactie of gebruik een formaat met ingebouwde optimalisatie zoals Delta.

Verkeerde row group-grootte
Standaard ligt die op 128 MB. Voor heel smalle tabellen (enkele kolommen) of heel brede tabellen (honderden kolommen) is aanpassen zinvol.

Wijzigen is duur
Parquet is immutable. Om één rij te updaten moet je het hele bestand herschrijven. Daarom leunen ETL/ELT-pipelines op append of op Delta/Iceberg voor updates.

Geen schema-garantie op mapniveau
Elk Parquet-bestand bewaart zijn eigen schema. Wanneer verschillende runs een ander schema schrijven, krijg je een map met onverenigbare bestanden. Schema-afdwinging moet van een laag erboven komen, bijvoorbeeld Delta of Iceberg.