Parquet hat sich in modernen Data-Lake- und Analytics-Architekturen als quasi-Standard etabliert. Das spaltenorientierte Dateiformat ist aus Big-Data-Stacks mit Hadoop, Spark, Cloud-DWHs und Data-Lakehouses kaum noch wegzudenken. Dieser Artikel erklärt, was Parquet ist, wie es technisch funktioniert, wofür es sich eignet – und welche Weiterbildungen den Einstieg in die Praxis erleichtern.

Begriffserklärung & Einleitung

Parquet ist ein offenes, spaltenorientiertes Dateiformat für die effiziente Speicherung und Analyse großer Datenmengen. Es wurde ursprünglich im Umfeld von Twitter und Cloudera entwickelt und wird heute als Top-Level-Projekt der Apache Software Foundation weitergeführt.

Im Unterschied zu klassischen Zeilenformaten wie CSV oder JSON organisiert Parquet Daten spaltenweise („columnar storage“). Das bedeutet, dass alle Werte einer Spalte physisch zusammenhängend gespeichert werden. Dadurch lassen sich analytische Abfragen, bei denen typischerweise nur wenige Spalten gelesen werden, deutlich beschleunigen und die Daten durch spaltenspezifische Kompressionsverfahren stark verkleinern.

Im Big-Data-Umfeld – von Apache-Hadoop-Ökosystemen über Apache-Spark-Cluster bis zu Cloud-Diensten wie Data Warehouses und Serverless-Query-Engines – ist Parquet heute eines der wichtigsten Speicherformate für Analytics-Workloads.

Funktionsweise & technische Hintergründe

Spaltenorientierte Speicherung

Konzeptionell kann man sich Parquet wie eine Tabelle vorstellen, die intern in mehrere Ebenen unterteilt ist:

• Row Groups: horizontale Blöcke der Tabelle (z. B. einige hundert MB).
• Column Chunks: innerhalb jeder Row Group die Daten einer Spalte.
• Pages: kleinste Einheiten innerhalb eines Column Chunks, optimiert für I/O.

Wenn eine Abfrage nur bestimmte Spalten benötigt, müssen nur die entsprechenden Column Chunks der relevanten Row Groups gelesen werden – nicht die vollständigen Zeilen. Das reduziert I/O und CPU-Kosten massiv, insbesondere bei großen Tabellen.

Schema und Metadaten

Parquet-Dateien enthalten ein explizites Schema (Datentypen, Feldnamen, Verschachtelungen) sowie umfangreiche Metadaten:

• Datentyp je Spalte (z. B. INT64, BYTE_ARRAY, BOOLEAN)
• Statistiken pro Page/Row Group (Min, Max, Null-Count)
• Informationen zur Kompression und zum Encoding

Diese Metadaten ermöglichen Predicate Pushdown und Data Skipping: Query-Engines können anhand von Min/Max-Werten ganze Row Groups überspringen, in denen ein Filterkriterium niemals erfüllt sein kann (z. B. WHERE event_date >= '2026-01-01').

Kompression und Encoding

Da Parquet spaltenbasiert speichert, sind die Werte in einer Spalte meist ähnlicher Natur als in einer gesamten Zeile. Das ermöglicht effizientere Kompression und spezialisierte Encodings, etwa:

• Dictionary Encoding: häufig wiederkehrende Werte werden durch kurze Schlüssel ersetzt.
• Run-Length Encoding (RLE): lange Sequenzen identischer Werte werden kompakt gespeichert.
• Bit-Packing: kleine Ganzzahlen werden platzsparend in wenigen Bits abgelegt.

Parquet unterstützt verschiedene Kompressionscodecs wie Snappy, gzip, zstd, Brotli oder LZ4. Je nach Datencharakteristik können so sowohl Speicherbedarf als auch Lesezeiten deutlich reduziert werden.

Ökosystem und Implementierungen

Parquet ist sprach- und plattformunabhängig. Referenzimplementierungen existieren u. a. in Java, C++ und Rust; Bibliotheken stehen für Python, Go, R und weitere Sprachen bereit.

Typische Integrationen:

• Big-Data-Frameworks: Spark, Hive, Trino/Presto, Flink
• Analyse-Datenbanken: Snowflake, BigQuery, DuckDB
• Cloud-Speicher: Amazon S3, Azure Data Lake Storage, Google Cloud Storage

Kurzes Python-Beispiel

import pandas as pd

# Parquet-Datei einlesen
df = pd.read_parquet("events.parquet")

# Filter anwenden
df_filtered = df[df["event_type"] == "CLICK"]

# Ergebnis wieder als Parquet speichern
df_filtered.to_parquet("events_filtered.parquet", compression="snappy")

Hier profitieren Sie automatisch von spaltenorientierter Kompression und effizientem I/O, ohne sich um die Details im Dateiformat kümmern zu müssen.

Anwendungsbeispiele in der Praxis

Data Lakes und Lakehouses

In modernen Data Lakes auf S3, ADLS oder GCS sind Parquet-Dateien häufig das physische Speicherformat, während Formate wie Apache Iceberg, Delta Lake oder Apache Hudi als „Table Format“ einen Metadatenlayer für Transaktionen, Time Travel und Schema-Evolution darüber legen.

Typische Szenarien:

• Historisierte Fact- und Event-Tabellen im Data Warehouse-/Lakehouse-Kontext
• Log- und Clickstream-Analysen
• Speicherung von Feature-Sets für Machine-Learning-Modelle

Batch- und Streaming-Pipelines

In ETL- oder ELT-Pipelines werden Rohdaten (z. B. JSON, CSV, Avro) oft in Parquet überführt, um sie für analytische Workloads zu optimieren. Das gilt für klassische Batch-Jobs ebenso wie für Streaming-Verarbeitung mit Kafka/Spark/Flink, bei der Mikrobatches regelmäßig als Parquet-Dateien im Data Lake landen.

On-Premises, Cloud, Hybrid

• On-Premises: Parquet als Standardformat in Hadoop-/Spark-Clustern für BI und Data Science.
• Cloud: Serverless-Abfragen auf Parquet-Dateien mit Diensten wie Athena, BigQuery oder Snowflake-External-Tables.
• Hybrid: Datenhaltung im Cloud-Data-Lake (Parquet), Verarbeitung aber teilweise On-Premises (z. B. mit Spark oder DuckDB).
  
  

Vorteile und Herausforderungen

Zentrale Vorteile von Parquet

Technische und organisatorische Vorteile:

• Performance für Analytics
  Optimiert für leselastige Workloads, bei denen nur ein Teil der Spalten benötigt wird. Weniger I/O, bessere Cache-Ausnutzung, schnelleres Scannen großer Tabellen.
• Hohe Kompressionsraten
  Durch spaltenbasierte Kompression und spezialisierte Encodings werden Speicherbedarf und Cloud-Kosten deutlich reduziert – oft um Größenordnungen im Vergleich zu CSV.
• Skalierbarkeit
  Parquet ist verteilt verarbeitbar und fügt sich nahtlos in Cluster-Architekturen und Data Lakes ein. Es ist damit prädestiniert für Terabyte- bis Petabyte-Szenarien.
• Flexibilität und Interoperabilität
  Offenes Format, breite Tool-Unterstützung, multiple Sprachen und Plattformen. Parquet-Dateien können von unterschiedlichen Engines gelesen und geschrieben werden, ohne Vendor-Lock-in auf Dateiformat-Ebene.
• Unterstützung komplexer Datentypen
  Verschachtelte Strukturen (Listen, Strukturen, Maps) lassen sich effizient abbilden, was insbesondere bei semi-strukturierten Daten (Events, Logs) hilfreich ist.
  
  

Herausforderungen und typische Stolpersteine

• Schreib-Performance und Latenz
  Das spaltenorientierte Layout und die Kompression machen Schreibvorgänge komplexer und teilweise langsamer als bei einfachen Zeilenformaten – für reine OLTP-Workloads ist Parquet ungeeignet.
• Small-File-Problem
  Viele sehr kleine Parquet-Dateien (z. B. aus Microbatch-Streaming) führen zu Metadaten-Overhead und schlechter Performance. Regelmäßige Kompaktierung („Compaction“) ist daher Best Practice.
• Schema-Evolution und Governance
  Parquet unterstützt Schema-Evolution nur begrenzt. Komplexere Anforderungen werden oft an das überlagerte Table-Format (Iceberg, Delta, Hudi) delegiert, was Architektur und Governance anspruchsvoller macht.
• Komplexität im Betrieb
  Effiziente Partitionierungsstrategien, sinnvolle Row-Group-Größen, Wahl des richtigen Codecs – all das erfordert Erfahrung im Data Engineering.
  
  

Alternative Lösungen

Parquet ist nicht das einzige Speicherformat im Datenumfeld:

• CSV/TSV
  Sehr einfach und weit verbreitet, aber ohne Schema, ohne effiziente Kompression und mit schwacher Performance bei großen Datenmengen.
• JSON/NDJSON
  Gut für semi-strukturierte Daten und APIs, aber ineffizient für analytische Abfragen und stark speicherintensiv.
• Avro
  Zeilenorientiertes, schemabasiertes Format, beliebt für Messaging und Streaming (Kafka), weniger optimal für analytische Scans großer Datasets.
• ORC
  Ebenfalls spaltenorientiert, mit ähnlichen Zielen wie Parquet, insbesondere stark im klassischen Hadoop-/Hive-Umfeld.
• Table-Formate mit Parquet als Backend
  Apache Iceberg, Delta Lake und Apache Hudi adressieren Themen wie ACID-Transaktionen, Time Travel und komplexe Schema-Evolution – häufig auf Basis von Parquet-Dateien als physischem Speicherformat.

Welche Alternative sinnvoll ist, hängt stark vom Einsatzzweck (Streaming vs. Analytics, OLTP vs. OLAP, Governance-Anforderungen) ab.

Fazit mit kritischer Bewertung

Parquet ist heute eines der wichtigsten Dateiformate für analytische Workloads und Data Lakes. Wer große Datenmengen performant speichern und auswerten möchte, kommt in modernen Datenplattformen um Parquet kaum herum.

Für Architekt:innen ist Parquet ein zentrales Bauelement in Data-Lake- und Lakehouse-Designs, das in Kombination mit Table-Formaten und Cloud-Services betrachtet werden muss. Data Engineers und Admins profitieren von den Performance- und Kostenvorteilen, müssen aber Themen wie Partitionierung, Dateigrößen und Schema-Evolution im Griff behalten. Entscheider:innen sollten Parquet als strategisches Fundament für offene, interoperable Datenplattformen verstehen – kein Produkt, sondern ein Standardbaustein, der Vendor-Lock-in reduziert und langfristig Investitionssicherheit bietet.

Im Vergleich zu Alternativen überzeugt Parquet insbesondere in Analytics-Szenarien durch starke Kompression, hohe Scan-Performance und breite Tool-Unterstützung. Für hochtransaktionale Systeme oder ultra-niedrige Latenzen bleibt jedoch der Einsatz spezialisierter Datenbanken sinnvoll; Parquet ist hier das Format der Wahl für Reporting, Self-Service-BI und Data-Science-Workloads – nicht für OLTP.

Parquet Schulungen & Weiterbildungsempfehlungen

Wenn Sie Parquet in der Praxis gezielt einsetzen möchten, empfehlen wir Ihnen unsere Trainings bei www.IT-Schulungen.com.
Wir bieten sowohl offene Schulungen in unseren Schulungszentren oder online als auch maßgeschneiderte Firmenseminare mit individuell abgestimmten Inhalten und Terminen.
Ausgewählte Seminare zu diesem Thema sind u. a.:

• Data Engineering mit Python – Skalierbare Big-Data-Verarbeitung mit Dask, PySpark & Parquet (2 Tage)
  In dieser praxisorientierten Schulung lernen Sie, wie Sie mit Python, Dask und PySpark skalierbare Data-Engineering-Pipelines aufbauen und dabei Parquet gezielt für performante Verarbeitung großer Datenmengen nutzen. Sie gewinnen ein tiefes Verständnis dafür, wann Sie welche Engine (Pandas, Dask, PySpark) und welches Datenlayout einsetzen, um robuste und effiziente Datenprozesse in Ihrem Unternehmen umzusetzen.

Autor

Michael Deinhard

Artikel erstellt: 02.02.2026
Artikel aktualisiert: 02.02.2026

zurück zur Übersicht