Parquet-bestanden beheersen: structuur, use cases en belangrijkste voordelen
Een Parquet-bestand slaat gegevens op per kolom in plaats van per rij. Het Apache Parquet-project beschrijft het als "een open-source, kolomgeoriënteerd gegevensbestandsformaat ontworpen voor efficiënte gegevensopslag en -opvraging." Die ene ontwerpkeuze verklaart waarom het kleiner is, sneller te bevragen en moeilijker te openen door te dubbelklikken.
Wat is een Parquet-bestand?
Parquet is een bestandsformaat voor tabulaire gegevens, onderhouden als een Apache-project. De officiële documentatie stelt dat het "hoogwaardige compressie- en coderingsschema's biedt om complexe gegevens in bulk te verwerken." Er wordt aan toegevoegd dat het formaat "wordt ondersteund in veel programmeertalen en analysetools."
De bepalende eigenschap is de oriëntatie. Een CSV schrijft één rij per keer: elk veld van record één, daarna elk veld van record twee. Parquet schrijft één kolom per keer: elke waarde van de eerste kolom, daarna elke waarde van de tweede.
Dat klinkt als een detail, maar het heeft twee grote gevolgen. Waarden in een enkele kolom lijken meestal op elkaar, waardoor ze veel beter comprimeren dan een gemengde rij. En een query die drie van de negentig kolommen nodig heeft, kan alleen die drie lezen, in plaats van elke rij te scannen om het grootste deel ervan weg te gooien.
Het formaat is formeel gespecificeerd. De Apache-documentatie merkt op dat "de parquet-format-repository de officiële specificatie van het Parquet-bestandsformaat host, die definieert hoe gegevens worden gestructureerd en opgeslagen."
Hoe een Parquet-bestand is gestructureerd
De envelop
Elk Parquet-bestand opent en sluit met dezelfde vier bytes. De specificatie toont een "magisch getal van 4 bytes 'PAR1'" aan het begin, en hetzelfde magische getal aan het allerlaatste einde.
Daartussen bevinden zich de gegevens en, tegen het einde, de metadata. Vlak voor het afsluitende magische getal bevindt zich een "lengte van 4 bytes in bytes van bestandsmetadata (little endian)." Die waarde vertelt een lezer hoe ver deze moet terugspringen om het metadatablok te vinden.
Rijgroepen en kolomchunks
Binnen de envelop worden gegevens tweemaal opgedeeld. De specificatie beschrijft een bestand met "N kolommen in deze tabel, opgesplitst in M rijgroepen."
Een rijgroep is een horizontale doorsnede — een batch rijen. Binnen elke rijgroep worden de waarden van elke kolom samen opgeslagen als een kolomchunk. Dus een bestand met 90 kolommen en 10 rijgroepen bevat 900 kolomchunks, elk een aaneengesloten reeks waarden uit een enkele kolom.
Deze dubbele opdeling is wat selectief lezen mogelijk maakt. Een query kan volledige rijgroepen overslaan die geen overeenkomende rijen kunnen bevatten, en vervolgens alleen de kolomchunks lezen die hij nodig heeft uit de resterende groepen.
Waarom de metadata aan het einde staat
Dit verrast mensen die een header verwachten. De Apache-documentatie legt de reden direct uit: "bestandsmetadata wordt na de gegevens geschreven om schrijven in één doorgang (single pass writing) mogelijk te maken."
Een schrijver die een grote dataset streamt, kent de uiteindelijke byteposities van elke chunk pas als deze zijn weggeschreven. Door metadata als laatste te plaatsen, hoeft de schrijver nooit terug te gaan om een header aan te passen.
Het leespatroon vloeit hieruit voort. Volgens de documentatie bevat de bestandsmetadata "de locaties van alle startposities van de kolomchunks." Er wordt aan toegevoegd dat "van lezers wordt verwacht dat ze eerst de bestandsmetadata lezen om alle kolomchunks te vinden waarin ze geïnteresseerd zijn."
Waar Parquet voor wordt gebruikt
U zult een .parquet-bestand doorgaans in een van de volgende vier situaties tegenkomen.
Exports uit datawarehouses. Wanneer iemand een grote tabel exporteert uit een modern warehouse, is dit vaak de standaard, omdat het bestand beheersbaar blijft.
Opslag in datalakes. Bestanden in cloud-objectopslag maken er vaak gebruik van, juist omdat engines een subset van kolommen kunnen lezen zonder alles te hoeven downloaden.
Overdrachten tussen teams. Een data-engineer die u een jaar aan transacties stuurt, zal hier vaak naar grijpen in plaats van naar een CSV die een paar keer groter zou zijn.
Uitwisseling tussen analysetools. Omdat het formaat in veel talen en tools wordt ondersteund, reist het tussen systemen zonder dat er een conversiestap tussen zit.
De rode draad is de grootte. Het wordt de logische keuze op het moment dat een CSV niet meer comfortabel te verplaatsen is.
Parquet vs CSV
| Parquet | CSV | |
|---|---|---|
| Oriëntatie | Kolomgeoriënteerd | Rijgeoriënteerd |
| Leesbaar in een teksteditor | Nee, het is binair | Ja |
| Typische bestandsgrootte | Kleiner, door kolomcompressie | Groter voor dezelfde gegevens |
| Enkele kolommen lezen | Leest alleen die kolomchunks | Leest het hele bestand |
| Datatypes | Meegenomen in de bestandsmetadata | Afgeleid door wat het ook opent |
| Opent door te dubbelklikken | Over het algemeen niet | Opent meestal in een spreadsheet |
| Beste voor | Grote tabellen, herhaaldelijk bevragen | Kleine tabellen, snelle inspectie, universeel delen |
Het gedrag van types verdient een opmerking. Een CSV heeft geen idee of 00123 een getal of een string is, wat de reden is waarom voorloopnullen en datums bij het importeren verminkt raken. Parquet legt types vast in zijn metadata, dus de waarde die u hebt geschreven is de waarde die u terugleest.
Voor de rijgeoriënteerde kant van deze vergelijking behandelt de CSV-uitleg hetzelfde onderwerp vanuit de andere richting. De TSV-analyse behandelt de tab-gescheiden variant.
Belangrijkste voordelen
Compressie die elkaar echt versterkt. Door vergelijkbare waarden naast elkaar op te slaan, krijgt de encoder veel meer om mee te werken. De Apache-documentatie schrijft dit toe aan "hoogwaardige compressie- en coderingsschema's."
Kolomselectie (column pruning). Het lezen van drie van de negentig kolommen kost ruwweg drie kolommen aan I/O in plaats van negentig.
Rijgroepen overslaan. Omdat metadata vastlegt wat er in elke rijgroep staat, kan een lezer hele delen weggooien voordat hij ze aanraakt.
Types overleven de reis. Datums blijven datums en identificatoren behouden hun voorloopnullen, omdat het schema in het bestand meereist.
Schrijven in één doorgang (single-pass writing). Metadata aan het einde betekent dat zeer grote bestanden als een stream kunnen worden geschreven.
Brede ondersteuning. De documentatie maakt melding van ondersteuning in "veel programmeertalen en analysetools," dus het is zelden een doodlopend spoor.
Waar Parquet ophoudt met helpen
Parquet lost opslag en opvraging op. Het lost geen van de vragen op die u heeft over wat er daadwerkelijk in het bestand staat.
Het is binair, dus u kunt er niet snel een blik op werpen. Een CSV openen om te controleren of de omzetkolom bruto of netto is, duurt vijf seconden. Een binair bestand heeft een tool nodig voordat u überhaupt iets kunt zien.
Het is ook slecht geschikt voor kleine hoeveelheden gegevens. Voor een opzoektabel met 200 rijen wegen de metadata-overhead en de vereiste tools niet op tegen de voordelen van compressie. Een CSV is daar het betere formaat, en daar eerlijk over zijn hoort bij het goed gebruiken van Parquet.
En het zegt niets over kwaliteit. Het bestand kan perfect getypeerde, efficiënt gecomprimeerde onzin bevatten. Gedupliceerde records, een valutakolom die twee valuta's mengt, een klant-ID waarvan het schema in maart is gewijzigd. Het formaat garandeert getrouwheid, geen juistheid.
Hoe te werken met een Parquet-bestand als u geen engineer bent
Dit is de praktische kloof. De meeste zakelijke tools gaan uit van een spreadsheet, en een .parquet-bestand opent niet op dezelfde manier als een CSV.
De pragmatische route is een conversiestap. Vraag degene die het bestand heeft gemaakt om een CSV- of Excel-extract van de kolommen die u daadwerkelijk nodig heeft, of converteer het zelf met een tool die Parquet ondersteunt. U verliest het compressievoordeel, maar dat maakt niet uit zodra de gegevens op uw machine staan en zijn ingeperkt.
Vanaf daar is het werk gewone analyse. De prijzenpagina van Powerdrill Bloom vermeldt uploads voor Excel, CSV, PDF, en documenten, dus een geconverteerd extract kan er direct in. Vragen worden gesteld in natuurlijke taal in plaats van geschreven als queries. De CSV AI-assistent dekt dat pad, en dataconnectoren dekken de gevallen waarin de gegevens beter kunnen worden opgehaald dan geëxporteerd.
Het onderscheid dat de moeite waarde is om te onthouden, is dat Parquet een opslagbeslissing is die stroomopwaarts van u is genomen. Het is geen analysetool, en het converteren ervan zodra het bestand uw bureau bereikt, is normaal en geen noodoplossing.
Conclusie
Parquet is kolomgeoriënteerde opslag met het schema en de index aan het einde van het bestand. Dat ontwerp levert compressie, selectief lezen en betrouwbare datatypes op, en dat is de reden waarom het de standaard is geworden voor alles wat groot is.
What it does not buy is visibility. The moment the file reaches someone who needs answers rather than storage, the useful next step is usually a scoped extract and a question.
Als dat is waar u zich bevindt, probeer dan Powerdrill Bloom met het geconverteerde bestand en begin met het omzetten ervan in een grafiek.
Veelgestelde vragen
Waar wordt een Parquet-bestand voor gebruikt?
Parquet wordt gebruikt om grote tabulaire datasets efficiënt op te slaan. Het is gebruikelijk voor exports uit datawarehouses, opslag in datalakes, overdrachten tussen teams en uitwisseling tussen analysetools. De reden is dat het goed comprimeert en het lezen van alleen geselecteerde kolommen ondersteunt.
Is Parquet beter dan CSV?
Voor grote tabellen die herhaaldelijk worden bevraagd wel: het is kleiner, bevat datatypes en ondersteunt kolomselectie (column pruning). Voor kleine tabellen die u moet inspecteren of breed moet delen, is CSV eenvoudiger omdat het tekst is en overal opent.
Kan ik een Parquet-bestand openen in Excel?
Niet door erop te dubbelklikken, aangezien Parquet een binair formaat is in plaats van tekst. De gebruikelijke aanpak is om het eerst naar CSV of Excel te converteren, of een tool te gebruiken die Parquet rechtstreeks leest.
Waarom wordt de metadata van Parquet aan het einde van het bestand opgeslagen?
De Apache-documentatie legt uit dat metadata na de gegevens wordt geschreven "om schrijven in één doorgang (single pass writing) mogelijk te maken." Een schrijver die een grote dataset streamt, kent de uiteindelijke chunkposities niet van tevoren, dus door metadata als laatste te schrijven, wordt voorkomen dat een header opnieuw moet worden bezocht.
Wat zijn rijgroepen (row groups) in Parquet?
Een rijgroep is een horizontale doorsnede van de tabel. De specificatie beschrijft de kolommen van een bestand als "opgesplitst in M rijgroepen," waarbij elke kolom als een afzonderlijke chunk binnen elke groep wordt opgeslagen. Die lay-out stelt lezers in staat om zowel groepen als kolommen die ze niet nodig hebben over te slaan.