Was ist Parquet: Das spaltenbasierte Format erklärt

Sie sind Parquet wahrscheinlich schon einmal begegnet, ohne es zu merken. Eine Dashboard-Abfrage läuft über Dateien im Objektspeicher, die SQL-Abfrage sieht harmlos aus, und dennoch verbringt eine scheinbar einfache Aggregation die meiste Zeit damit, Daten zu lesen, die die Abfrage gar nicht benötigt. Derselbe Datensatz funktioniert in DuckDB oder Spark reibungslos, verhält sich dann aber in einer anderen Engine anders, weil ein logischer Typ, eine Statistik oder eine neuere Funktion nicht auf dieselbe Weise interpretiert wird.

Was also ist Parquet? Apache Parquet ist ein quelloffenes, spaltenorientiertes Datendateiformat, das für eine effiziente Speicherung und Abfrage entwickelt wurde, insbesondere für analytische Workloads. Es ist keine Datenbank und ersetzt kein Tabellenformat wie Iceberg oder Delta Lake. Es ist die physische Dateischicht unter vielen Data Lakes, Warehouses, analytischen Exporten und Pipelines für maschinelles Lernen.

Inhaltsverzeichnis

• Warum Parquet existiert und wo es hineinpasst

  • Wo Parquet in einen modernen Data Stack passt

• Wie Parquet entstanden ist

• Im Inneren einer Parquet-Datei

  • Zeilengruppen sind die Stockwerke

  • Spalten-Chunks sind die Regale

  • Seiten sind die kleinste praktische Lese-Einheit

• Wie Kodierung und Komprimierung zusammenarbeiten

  • Gängige Parquet-Kodierungen und -Codecs auf einen Blick

• Prädikaten-Pushdown und warum Abfragen schneller werden

  • Was der Reader prüft

• Parquet im Vergleich zu CSV, JSON und ORC

  • Parquet vs. CSV vs. JSON vs. ORC

• Interoperabilität, Sicherheit und praktische Kompromisse

  • Engine-Unterstützung ist eine Kompatibilitätsfrage

  • Die Kosten hinter der Bequemlichkeit

• Praktische Tipps für Analytics-Workloads

  • Checkliste für ein praktisches Layout

  • Überlegungen zur Governance und KI

Warum Parquet existiert und wo es hineinpasst

Ein Analyst führt Folgendes aus:

SELECT region, AVG(revenue)
FROM sales
GROUP BY region;

SELECT region, AVG(revenue)
FROM sales
GROUP BY region;

SELECT region, AVG(revenue)
FROM sales
GROUP BY region;

Bei einer großen CSV-Datei analysiert die Query-Engine typischerweise Zeilen über die gesamte Datei hinweg und prüft Felder, die für die Berechnung gar nicht benötigt werden. Speicherzugriffe und CPU-Zeit werden für nicht relevante Spalten verschwendet. Parquet gruppiert Werte nach Spalten, sodass sich der Reader stattdessen auf region und revenue konzentrieren kann.

Die Kernidee ist die physische Organisation. Eine zeilenorientierte Datei hält die Felder jedes Datensatzes zusammen, während eine spaltenorientierte Datei Werte aus derselben Spalte gruppiert. Spalten enthalten in der Regel ähnliche Datentypen und wiederholte Werte, was Kodierungs- und Komprimierungsmethoden ein vorhersehbareres Muster bietet. Apache beschreibt Parquet in seiner offiziellen Dokumentation als quelloffenes, spaltenorientiertes Datendateiformat für effiziente Speicherung und Abfrage.

Dieses Design eignet sich für mehrere gängige Workloads:

• Cloud Data Lakes: Dateien in Amazon S3 und ähnlichen Objektspeichern können abgefragt werden, ohne dass jedes einzelne Feld in eine Datenbank geladen werden muss.

• Analytische Faktentabellen: Spark, Trino und Presto können ausgewählte Spalten aus großen Ereignis- oder Transaktionsdatensätzen scannen.

• Operative Exporte: Teams können Anwendungsdaten extrahieren und eine analytische Kopie veröffentlichen, ohne ein textlastiges Austauschformat beizubehalten.

• Features für maschinelles Lernen: Trainings-Pipelines und Feature-Stores können typisierte, komprimierte Dateien austauschen, anstatt CSV oder JSON wiederholt zu parsen.

Parquet hat auch einen bestimmten Platz in einer Data-Lake-Architektur. Ein Data Lake enthält Dateien und Metadaten. Tabellenformate fügen Transaktionen, Snapshots, Partitionsverfolgung und Schema-Management hinzu. Dieser Vergleich von Data Lakes und Data Marts ordnet Parquet in diese breitere Architektur ein.

Wo Parquet in einen modernen Data Stack passt

Parquet befindet sich unter Tabellenformaten wie Iceberg und Delta Lake und stellt die physische Dateischicht bereit, anstatt Transaktionen oder Snapshots zu verwalten. Diese Trennung erklärt, warum eine Parquet-Datei mit verschiedenen Engines funktionieren kann, während das Verhalten auf Tabellenebene immer noch von den umgebenden Metadaten und dem Abfragesystem abhängt.

Das praktische mentale Modell ist einfach: Parquet macht analytische Dateiscans selektiv und wirtschaftlich. Die Vorteile hängen davon ab, wie Dateien strukturiert sind, wie Werte kodiert und komprimiert werden, wie Filter den Reader erreichen und ob die gewählte Engine die relevanten Funktionen konsistent unterstützt.

Wie Parquet entstanden ist

Parquet entstand aus einem praktischen Hadoop-Problem: Analytische Abfragen benötigten oft nur wenige Felder aus sehr breiten Datensätzen. Twitter und Cloudera entwickelten es als Open-Source-Projekt, beeinflusst von Googles Dremel-Arbeit zur spaltenorientierten Verarbeitung geschachtelter Daten. Das erste Release erschien am 13. März 2013, gefolgt von Parquet 1.0 im Juli 2013, wie in der Apache Parquet-Historie dokumentiert.

Das Entwicklungsziel war das selektive Lesen. Wenn eine Abfrage nur nach customer_id und revenue aus einem breiten Ereignis-Datensatz verlangte, konnte der Reader das Parsen nicht relevanter Felder vermeiden. Der Einfluss von Dremel führte Parquet zudem in Richtung geschachtelter analytischer Daten und nicht nur flacher, tabellenähnlicher Strukturen.

ORC wurde im Hive-Ökosystem mit ähnlichen Zielen entwickelt und bot Hadoop-Nutzern eine weitere ernstzunehmende spaltenorientierte Alternative. Die Bedeutung von Parquet wuchs, da immer mehr Tools kompatible Reader und Writer implementierten. Das Format entwickelte sich stetig weiter. Ein Beispiel ist BYTE_STREAM_SPLIT, das in der Release-Linie 2.8.0 im Jahr 2019 freigegeben wurde und eine standardisierte Funktion einführte, anstatt das Format unverändert zu lassen.

Das Projekt wurde am 27. April 2015 zu einem Top-Level-Projekt der Apache Software Foundation ernannt. Diese governance unterstützt ein Ökosystem mit vielen unabhängigen Implementierungen anstelle eines einzelnen, herstellergesteuerten Readers. Spark, Trino, Presto, Hive, ClickHouse, DuckDB, Polars, BigQuery, Snowflake, Athena und Redshift gehören zu den in der Dokumentation des Format-Ökosystems aufgeführten Engines und Services. Die Kompatibilität hängt nach wie vor davon ab, welche Funktionen die jeweilige Engine implementiert und wie sie mit Schemata, Kodierungen und Metadaten umgeht.

Das ist beim Ingestion-Prozess von Bedeutung. Eine Data-Ingestion-Pipeline kann analytische Batches als Parquet schreiben, während ein Tabellenformat Transaktionen und Snapshots hinzufügt und eine Query-Engine entscheidet, wie die Dateien gescannt werden.

Historische Lektion: Parquet war erfolgreich, weil es ein weit verbreitetes analytisches Zugriffsmuster bediente und sich auf Engines ausbreitete, die ausgewählte Spalten effizient lesen konnten.

Seine Geschichte erklärt die Aufteilung der Zuständigkeiten: Parquet kümmert sich um die physische Datei-, Kodierungs- und Komprimierungsebene, während die umgebenden Systeme das Tabellen-Management und das Abfrageverhalten bereitstellen.

Im Inneren einer Parquet-Datei

Eine Abfrage benötigt oft nur wenige Felder aus einer großen Tabelle, doch eine zeilenorientierte Datei zwingt sie dazu, jedes einzelne Feld zu lesen. Parquet vermeidet diese Verschwendung durch ein geschachteltes physisches Layout. Eine nützliche Analogie ist ein Bibliotheksgebäude: Die Parquet-Datei ist das Gebäude, eine Zeilengruppe (Row Group) ist ein Stockwerk, ein Spalten-Chunk (Column Chunk) ist ein Regal und eine Seite (Page) ist ein Bücherstapel in diesem Regal. Jede Ebene erfüllt eine bestimmte Aufgabe.

Eine Parquet-Datei beginnt mit einem 4-Byte Magic Header, PAR1. Ihre Daten sind in Zeilengruppen organisiert. Jede Zeilengruppe enthält genau einen Spalten-Chunk pro Spalte, und jeder Spalten-Chunk besteht aus einer oder mehreren Seiten. Diese Hierarchie bietet Readern die Struktur, die sie benötigen, um Spalten auszuwählen und irrelevante Daten zu überspringen, wie in Apaches Dokumentation zu Parquet-Konzepten beschrieben.

Zeilengruppen sind die Stockwerke

Eine Zeilengruppe enthält ein horizontales Segment von Tabellenzeilen. Für Spalten wie event_date, region und revenue enthält eine Zeilengruppe einen Teil von allen dreien. Ihre Zeilenbereiche bleiben aufeinander abgestimmt, sodass eine Engine dieselben Datensätze auswerten kann, während sie nur die für die Abfrage erforderlichen Spalten liest.

Writer zielen in der Regel auf Zeilengruppen im Bereich von 128 MB bis 1 GB ab. Die passende Einstellung hängt von der Engine, dem Speichersystem, dem Workload und der Anzahl der Spalten ab. Größere Gruppen können den Metadaten-Overhead reduzieren, während kleinere Gruppen ein feinkörnigeres Überspringen ermöglichen. Betrachten Sie die Größe von Zeilengruppen als eine auf den Workload abgestimmte Entscheidung und nicht als universelle Konstante.

Spalten-Chunks sind die Regale

Innerhalb einer Zeilengruppe hat jede Spalte ihren eigenen Spalten-Chunk. Der Chunk für region speichert kodierte Region-Werte, während der Chunk für revenue kodierte Umsatzwerte speichert. Eine Abfrage, die diese Felder benötigt, muss so einen nicht relevanten customer_notes-Chunk gar nicht erst lesen.

Die Fußzeile (Footer) zeichnet die Position und Metadaten jedes Chunks auf. Sie beschreibt auch das Schema und die Pfade der Spaltenmetadaten, sodass ein Reader geschachtelte Felder interpretieren und relevante Bytes lokalisieren kann, ohne die Datei von Anfang an scannen zu müssen.

Seiten sind die kleinste praktische Lese-Einheit

Spalten-Chunks sind in Seiten unterteilt, die kodierte Werte und Seiten-Metadaten enthalten. Eine typische Standard-Seitengröße beträgt 1 MB, obwohl Writer und Engines andere Einstellungen wählen können. Seiten bieten eine feine Abgrenzung für Statistiken, Komprimierung und selektive Lesevorgänge.

Die Datei endet mit einer Fußzeile (Footer), die die zum Dekodieren der Daten erforderlichen Informationen enthält, gefolgt von einer abschließenden PAR1-Markierung. Ein Reader kann zum Ende springen, die Fußzeile lesen, das Schema und die Positionen der Zeilengruppen identifizieren und dann gezielte Lesevorgänge für ausgewählte Chunks und Seiten starten. Diese Struktur macht Parquet binär, selbstbeschreibend und splittbar für die verteilte Verarbeitung.

Mentales Modell des Readers: Beginnen Sie bei der Fußzeile, identifizieren Sie nützliche Zeilengruppen und Spalten, und lesen Sie dann gezielt Chunks und Seiten.

Parquet trägt die zu seinem Lesen erforderlichen strukturellen Informationen in sich selbst, sodass kein separater Katalog erforderlich ist. Ein Katalog kann das Auffinden dennoch erleichtern. Ein starkes Metadaten-Management hilft auf Tabellenebene, insbesondere wenn viele Dateien und Schemaversionen nachverfolgt werden müssen. Die Portabilität von Dateien hängt auch davon ab, dass Reader die vom Writer verwendeten Funktionen unterstützen, und nicht nur davon, dass beide Tools sich als Parquet-kompatibel bezeichnen.

Wie Kodierung und Komprimierung zusammenarbeiten

Oft werden „Kodierung“ und „Komprimierung“ synonym verwendet. Bei Parquet handelt es sich jedoch um separate Schritte in einer Pipeline:

1. Die Kodierung formt Werte um, um Muster freizulegen.

2. Die Komprimierung reduziert den resultierenden Byte-Stream.

Nehmen wir eine Spalte country mit sich wiederholenden Strings. Die Wörterbuch-Kodierung (Dictionary Encoding) kann jedem eindeutigen Wert eine kleine Ganzzahl-ID zuweisen und diese IDs speichern, anstatt die vollständigen Strings auf der gesamten Seite zu wiederholen. Die Run-Length-Kodierung kann eine Folge identischer Werte kompakt darstellen. Die Delta-Kodierung speichert Differenzen zwischen aufeinanderfolgenden Werten, was besonders effektiv sein kann, wenn Zahlen geordnet sind oder sich nur allmählich ändern. Das Bit-Packing speichert kleine Ganzzahlen und nutzt dabei nur die tatsächlich benötigten Bits.

Diese Techniken eignen sich nicht gleichermaßen für jede Spalte. Die Wörterbuch-Kodierung ist ideal für wiederkehrende kategorische Werte, während die Delta-Kodierung ein nützliches sequenzielles Muster erfordert. Der Writer wählt eine Kodierung für die Spalte und die Seite, und die Metadaten halten diese Entscheidung fest.

Erst nach dieser Umformung komprimiert ein Codec auf Seitenebene die Bytes. Die Dokumentation von Apache beschreibt Codecs wie Snappy, GZIP, LZ4 und ZSTD, während PyArrow in seiner Parquet-Konfigurationsdokumentation auch Brotli und unkomprimierte Ausgaben unterstützt. Die Formatdokumentation erklärt, dass Seiteninhalte unverändert komprimiert werden, ohne zusätzliches Framing oder Padding, was den Dekomprimierungsprozess einfach hält.

Gängige Parquet-Kodierungen und -Codecs auf einen Blick

Kodierungs- und Codec-Einstellungen befinden sich in verschiedenen Bereichen der Datei-Metadaten. Die Wahl der Kodierung ist bei den Seiten- und Spalteninformationen hinterlegt, während der Komprimierungscodec in den Metadaten der jeweiligen Seite aufgezeichnet wird. Writer wie Apache Spark, DuckDB und PyArrow nutzen unterschiedliche Standards, weshalb zwei valide Parquet-Dateien unterschiedliche Performance-Profile aufweisen können.

Ein häufiger Optimierungsfehler besteht darin, eine aggressive Komprimierungsstufe zu wählen, ohne den tatsächlichen Workload zu messen. Wenn eine Spalte durch die Kodierung bereits hochgradig strukturiert wurde, kann eine langsamere Einstellung wie ZSTD Level 19 lediglich CPU-Kosten verursachen, ohne die Größe nennenswert zu reduzieren. Die richtige Wahl hängt davon ab, ob der Engpass im Speicher, bei der Netzwerkübertragung, bei der CPU oder bei der Latenz liegt.

Prädikaten-Pushdown und warum Abfragen schneller werden

Eine Dashboard-Abfrage filtert die Verkäufe für Januar, gruppiert die Ergebnisse nach Region und summiert den Umsatz. Ein Parquet-Reader kann diese Abfrage beantworten, ohne den Großteil der Datei dekomprimieren zu müssen. Dieser Mechanismus wird als Prädikaten-Pushdown bezeichnet – oder genauer gesagt: Filtern und Pruning auf der Speicherebene.

SELECT region, SUM(revenue)
FROM sales
WHERE event_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY region;

SELECT region, SUM(revenue)
FROM sales
WHERE event_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY region;

SELECT region, SUM(revenue)
FROM sales
WHERE event_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY region;

Die Engine prüft zunächst das minimale und maximale event_date, das für jede Zeilengruppe aufgezeichnet wurde. Wenn eine Zeilengruppe vollständig außerhalb des Januars liegt, kann der Reader sie überspringen, ohne ihre Datenseiten zu öffnen. Bei Zeilengruppen, die sich mit dem Datumsbereich überschneiden, können Statistiken auf Seitenebene Seiten ausschließen, deren Bereiche dennoch nicht passen können.

Der Reader fordert dann nur die Seiten für event_date, region und revenue an, die für die Abfrage benötigt werden. Andere Spalten teilen sich zwar dieselben Zeilen, müssen aber nicht dekodiert werden. Parquets Struktur auf Datei- und Spaltenebene stellt das Metadaten-Layout bereit, das diesen selektiven Zugriff ermöglicht.

Was der Reader prüft

Ein typischer Pruning-Ablauf umfasst:

• Zeilengruppen-Statistiken: Abgleich des Filters mit dem aufgezeichneten Bereich jedes Spalten-Chunks.

• Seiten-Statistiken: Überprüfung feinkörnigerer Minimal- und Maximalwerte innerhalb der in Frage kommenden Zeilengruppen.

• Wörterbuch-Informationen: Auflösung einiger kategorischer Filter anhand der Werte auf den Wörterbuchseiten.

• Bloom-Filter: Prüfung probabilistischer Zugehörigkeitsinformationen, sofern die Datei diese enthält und der Reader sie unterstützt.

• Spaltenauswahl: Dekodierung ausschließlich der für das Ergebnis projizierten Spalten.

Das Dateilayout bestimmt, wie viel Arbeit das Pruning einsparen kann. Wenn Werte über alle Seiten verstreut sind, überschneiden sich die Min/Max-Bereiche, und die Engine kann kaum etwas überspringen. Das Sortieren nach einer häufig gefilterten Spalte kann ähnliche Werte zusammenfassen, wobei die sinnvolle Anordnung vom Writer und dem Tabellendesign abhängt.

Pushdown ist zudem ein Verhalten der Engine und kein Versprechen, dass jedes Prädikat identisch behandelt wird. Reader schränken das Pruning bei geschachtelten Typen möglicherweise ein oder interpretieren logische Typen anders. Auch die Unterstützung von Wörterbuch- und Bloom-Filtern kann variieren. Für weiterführende Hinweise zur Optimierung von SQL-Abfragen verknüpfen Sie das Speicherverhalten mit dem Query-Plan.

Die operative Regel lautet: Parquet macht nicht jede Abfrage automatisch schnell. Es macht selektive Abfragen günstiger, wenn das Dateilayout und die Metadaten das Pruning unterstützen.

Parquet vs. CSV, JSON und ORC

Das richtige Format hängt von der Aufgabe ab. CSV und JSON eignen sich gut als Austauschformate, da Menschen sie prüfen können, Anwendungen sie leicht erzeugen und APIs sie standardmäßig akzeptieren. Wiederholte analytische Scans offenbaren jedoch ihre Grenzen: Werte werden als Text gespeichert, und Reader müssen Datensätze meist nacheinander parsen.

Parquet geht einen anderen Kompromiss ein. Es speichert typisierte Daten in einem binären, komprimierten und spaltenorientierten Layout, sodass eine Engine nur die Spalten lesen muss, die für eine Abfrage benötigt werden. Das macht es zu einem starken Standard für analytische Speicher, macht es jedoch unpraktisch, es in einem Texteditor zu öffnen oder direkt an einen Empfänger zu senden, der JSON erwartet.

Die Kodierungs-Pipeline spielt hier eine wichtige Rolle. Parquet kann ähnliche Werte zusammen kodieren, Wörterbuch- oder Run-Length-Techniken anwenden und die resultierenden Seiten anschließend komprimieren. CSV und JSON überlassen das Parsen und die Typ-Inferenz meist dem Reader. ORC folgt einem ähnlichen spaltenorientierten Modell und ist der direkteste Vergleich, insbesondere in Hive-basierten Umgebungen.

Parquet wird direkt von Tools wie Spark, Trino, Presto, Hive, ClickHouse, DuckDB, Polars, BigQuery, Snowflake, Athena und Redshift unterstützt, wie in der Apache-Formatdokumentation beschrieben. Der gemeinsame Kern verbessert die Portabilität, garantiert jedoch nicht das exakt gleiche Verhalten für jeden logischen Typ, jede geschachtelte Struktur oder jedes Metadaten-Feature.

Parquet vs. CSV vs. JSON vs. ORC

Die Schema-Evolution erfordert weiterhin Abstimmung. Parquet zeichnet Schemainformationen in jeder einzelnen Datei auf, während ein Tabellensystem oder Katalog diese Versionen normalerweise über eine Sammlung von Dateien hinweg zusammenführt. Das Hinzufügen eines Nullable-Feldes ist im Allgemeinen einfacher als das Ändern der Bedeutung oder der physischen Darstellung eines bestehenden Feldes. Logische Typen können zudem unterschiedliche Ergebnisse liefern, wenn Reader sie ungleichmäßig unterstützen.

Nutzen Sie CSV oder JSON, wenn Menschen, APIs oder einfache Ingestion-Tools die Ausgabe benötigen. Wählen Sie ORC, wenn Hive-Kompatibilität und ein ORC-zentrierter Stack das Format vorgeben. Wählen Sie Parquet für moderne analytische Lakes und den systemübergreifenden Datenaustausch und testen Sie die spezifischen Reader, Writer und logischen Typen in Ihrer Umgebung.

Interoperability, Security und praktische Kompromisse

Die weite Verbreitung von Parquet kann den falschen Eindruck erwecken, dass jede Engine jede Datei identisch liest. Spark, DuckDB, Trino, BigQuery, Athena und Polars sind sich beim grundlegenden Layout einig, können sich jedoch bei geschachtelten Typen, logischen Typen wie UUID und JSON, Dezimalpräzision, Seitenindizes und der Bedeutung von Statistiken in der Fußzeile unterscheiden.

Das führt zu einem praktischen Problem: Ein Writer erzeugt eine valide Datei, aber ein anderer Reader unterstützt die spezifisch genutzte Funktion nicht. Die Datei lässt sich in einem Tool problemlos öffnen, schlägt jedoch in einem anderen fehl, stuft einen Typ herab oder ignoriert eine Optimierung. Apaches Statusseite zur Implementierung macht diese Unterschiede deutlich. Sie zeigt unterschiedliche Feature-Sets über Implementierungen hinweg – so erreichte Parquet Java 1.16.0 im September 2025, während Arrow Rust, Hyparquet, DuckDB und Polars unterschiedliche Feature-Versionen verfolgen.

Engine-Unterstützung ist eine Kompatibilitätsfrage

Sicherheit verdient die gleiche Aufmerksamkeit wie Interoperabilität. Im April 2025 betraf die kritische Deserialisierungs-Schwachstelle CVE-2025-30065 die Bibliothek parquet-java. Sicherheitsempfehlungen rieten Teams dringend dazu, auf Parquet 1.15.1 zu aktualisieren und nicht vertrauenswürdige Dateien zu meiden, wie in den Apache-Implementierungs- und Sicherheitsrichtlinien dokumentiert.

Das ändert die Antwort auf die Frage: „Kann ich jede Parquet-Datei in jedem Tool sicher lesen?“ Nein. Behandeln Sie Dateien aus nicht vertrauenswürdigen Uploads oder von externen Parteien als potenziell schädliche Eingaben. Patchen Sie die relevanten Bibliotheken, isolieren Sie Reader wo angebracht, akzeptieren Sie Remote-Schemata nicht blind und prüfen Sie das Verhalten von optionalen Metadaten und Seitenindizes, bevor Sie aggressive Funktionen aktivieren. Ein isolierter Reader (Sandbox) kann den Schadensradius verringern, ersetzt aber kein Abhängigkeitsmanagement.

Die Kosten hinter der Bequemlichkeit

Parquet bringt auch außerhalb der Sicherheit Kompromisse mit sich:

• Häufige Updates: Unveränderliche analytische Dateien können bei häufigen Datensatzänderungen zu einer hohen Schreibverstärkung (Write Amplification) führen.

• Kleine Dateien: Viele winzige Objekte erhöhen den Overhead beim Auflisten, Öffnen und Verwalten von Metadaten im Objektspeicher.

• Breite Schemata: Footer-Metadaten können erheblich anwachsen, wenn Dateien viele Spalten und Zeilengruppen enthalten.

• Debugging: Defekte Binärdateien sind viel schwerer zu analysieren als fehlerhafte CSV-Dateien.

• Lücken in Engines: Eine Funktion, die von einer Implementierung unterstützt wird, kann von einer anderen ignoriert oder abgelehnt werden.

Teams müssen auch Anforderungen an die Datenresidenz berücksichtigen, wenn sie Speicherorte, Reader und Verarbeitungspfade auswählen. Parquet optimiert die physische Speicherung und Zugriffsmuster, löst aber nicht von sich aus Fragen der Governance, Isolation oder regulatorischen Kontrolle.

Praktische Tipps für Analytics-Workloads

Ein zuverlässiges Parquet-Setup beginnt mit dem Dateilayout und nicht mit dem Feintuning von Codecs. Für viele Cloud-Analytics-Workloads empfiehlt es sich, Zeilengruppen um 128 MB bis 256 MB und Seitengrößen nahe 1 MB anzustreben, wie in diesem Parquet-Optimierungsleitfaden gezeigt. Dies sind Richtwerte, keine Garantien. Testen Sie mit der Engine, dem Objektspeicher und den Abfrageformen, die Ihr Team nutzt.

Checkliste für ein praktisches Layout

• Wählen Sie Zeilengruppen bewusst: Wägen Sie gezielte Lesevorgänge gegen Metadaten-Overhead und das Anfrageverhalten des Objektspeichers ab.

• Halten Sie Seiten moderat: Eine Seitengröße von fast 1 MB ist eine solide Basis für Komprimierung und das Filtern auf Seitenebene.

• Sortieren Sie nützliche Filterspalten: Spalten wie event_time und user_id profitieren, wenn Abfragen selektiv filtern und sich Werte auf Seiten konzentrieren.

• Vermeiden Sie wahlloses Sortieren: Sortieren verursacht zusätzlichen Schreibaufwand. Priorisieren Sie Spalten, die in wichtigen Prädikaten vorkommen.

• Grobe Partitionierung wählen: Datums- oder Kategoriepartitionen sind oft einfacher zu verwalten als Schlüssel mit hoher Kardinalität, die zu übermäßig vielen Verzeichnissen führen.

• Kleine Dateien zusammenführen: Eine Tabelle mit vielen winzigen Parquet-Objekten kann eine schlechte Performance aufweisen, selbst wenn jede einzelne Datei optimal strukturiert ist.

Die Komprimierung sollte sich nach dem Workload richten. Snappy ist eine gute, geschwindigkeitsorientierte Wahl. ZSTD bietet sich an, wenn die Reduzierung des Speicherplatzes im Vordergrund steht und CPU-Kapazität vorhanden ist. GZIP kann für die Kompatibilität mit Altsystemen sinnvoll sein, ist aber selten die erste Wahl für interaktive Analysen, wenn schnellere Codecs unterstützt werden.

Parquet ist nicht für jeden Datensatz die beste Lösung. Eine winzige Referenztabelle von wenigen Megabytes lässt sich oft einfacher als CSV verteilen oder in einer kleinen Datenbank speichern. Das Format zahlt sich aus, wenn wiederholte analytische Scans, Spaltenauswahl, Komprimierung und verteilte Verarbeitung den Aufwand für Binär-Tools und Dateiverwaltung rechtfertigen.

Überlegungen zur Governance und KI

Erzwingen Sie Schemata beim Schreiben (Write-Time), zeichnen Sie die Versionen von Writer und Reader auf und testen Sie repräsentative Dateien mit den von Ihren Nutzern verwendeten Engines. Nutzen Sie Iceberg oder Delta Lake, wenn Sie Transaktionen auf Tabellenebene, Snapshots und ein verwaltetes Schema-Management benötigen. Parquet bleibt eine nützliche physische Austauschschicht zwischen Trainings-Pipelines und Feature-Stores, sollte aber nicht mit einem vollständigen Governance-System verwechselt werden.

Für Teams, die viele Parquet-Datensätze verwalten, sollte sich Observability auf mehr als nur die Existenz von Dateien erstrecken. Überwachen Sie Schemaänderungen, Bereitstellungszeiten, Datensatzvalidierungen und geschäftliche Kennzahlen, damit eine technisch lesbare Datei nicht analytisch unzuverlässig wird. digna bietet datenbankinterne Funktionen für Datenqualität, Timeliness, Anomalieerkennung, Validierung, Schemaverfolgung und Plattform-Observability, die direkt in der Kundenumgebung angewendet werden können.

Praxisregel: Optimieren Sie das Dateilayout für die Filter, die Ihre Nutzer ausführen, und validieren Sie das Ergebnis in jeder relevanten Engine.

Wenn Ihr Data Lake Parquet-Dateien enthält, Sie aber Schema-Drift, verspätet eintreffende Daten oder sich änderndes Datenverhalten nicht einfach nachverfolgen können, besuchen Sie digna, um zu sehen, wie datenbankinterne Observability diese Risiken direkt in Ihrer eigenen Umgebung überwachen kann. Beginnen Sie mit dem Modul, das Ihr dringendstes Zuverlässigkeitsproblem löst, und erweitern Sie es, wenn Ihre Analytics- und KI-Workloads wachsen.