Apache Arrow: Definition des spaltenorientierten Formats

Apache Arrow ist ein einheitliches Format für Tabellen im Arbeitsspeicher (RAM), das für Auswertungen großer Datenmengen gebaut ist. Statt jede Zeile mit allen Feldern hintereinander abzulegen, speichert Arrow die Werte einer Spalte am Stück; das nennt man spaltenorientiert. Weil das Format offen und in vielen Programmiersprachen (C++, Java, Python, Rust) verfügbar ist, können Systeme wie Spark, Pandas, Polars oder DuckDB dieselben Daten direkt lesen, ohne sie vorher in ein anderes Format umzuwandeln (also ohne Serialisierung) und ohne eine Kopie anzulegen.

Was ist Apache Arrow?

Apache Arrow legt fest, wie eine Tabelle im Arbeitsspeicher liegt: Jede Spalte steht als zusammenhängender Werteblock (englisch: Buffer oder Puffer) mit einheitlichem Datentyp im RAM, dazu kommt eine kleine Zusatzinformation, die vermerkt, in welchen Zeilen ein Wert fehlt (die Null-Bitmap). Für Texte und Listen speichert Arrow zusätzlich sogenannte Offset-Puffer, die angeben, wo im Werteblock jeder einzelne Eintrag beginnt und endet. Diese Anordnung erlaubt dem Prozessor (CPU), ganze Blöcke einer Spalte in einem Rutsch zu verarbeiten. Möglich wird das durch sogenannte Vektor-Instruktionen (SIMD, „Single Instruction, Multiple Data": ein Rechenschritt auf viele Werte gleichzeitig), statt Zeile für Zeile durch gemischte Datentypen zu springen. Zwei Programme, die dasselbe Arrow-Layout kennen, können Daten über gemeinsam genutzten Arbeitsspeicher (Shared Memory) oder das Arrow-Netzwerkprotokoll (Arrow IPC, „Inter-Process Communication") teilen, ohne sie zu konvertieren oder zu kopieren. Das ist die Grundlage der oft genannten Zero-Copy-Interoperabilität, also des Datenaustauschs ohne Umkopieren.

Das Projekt entstand 2016 als Apache-Top-Level-Projekt und geht auf eine Beobachtung mehrerer OSS-Contributoren zurück: Jede analytische Engine hatte damals ihr eigenes In-Memory-Layout, und der Datenaustausch zwischen Spark, Pandas, Impala, Drill und weiteren Systemen kostete typischerweise mehr Rechenzeit als die eigentliche Verarbeitung. Arrow löst das, indem es genau eine spaltenorientierte Repräsentation standardisiert und die Referenz-Implementierungen als Open Source pflegt.

Zum Ecosystem gehört mehr als das reine Format. Die Bibliotheken (pyarrow, arrow-cpp, arrow-rs, arrow-java, nanoarrow) implementieren Reader und Writer für Parquet, ORC, CSV und JSON, stellen Compute-Kernels für Filter, Joins und Aggregationen bereit und integrieren sich in Pandas, Polars, DuckDB, DataFusion und Ray. Arrow Flight ist ein separates gRPC-basiertes RPC-Framework, das Arrow-Batches über Netzwerk transportiert; Flight SQL setzt darauf eine SQL-Schnittstelle. Beide sind eigenständige Komponenten und nicht mit dem Format selbst zu verwechseln.

Abgrenzung zu Parquet, Iceberg und Arrow Flight

Arrow wird häufig mit benachbarten Formaten und Frameworks vermischt, weil On-Disk-Format, Tabellenformat und Transportprotokoll in derselben Datenpipeline auftauchen.

Begriff	Schicht	Verhältnis zu Arrow
Parquet	On-Disk-Format (komprimiert, spaltenorientiert)	Persistente Speicherform; Parquet-Dateien werden gelesen und in Arrow-Puffer dekodiert. Beide sind spaltenorientiert, aber Arrow zielt auf RAM, Parquet auf Disk.
ORC	On-Disk-Format (komprimiert, spaltenorientiert)	Wie Parquet: On-Disk-Container. Der Reader liefert Arrow-Batches an die Engine.
Iceberg / Delta Lake	Tabellenformat (Metadaten, Transaktionen, Schema-Evolution)	Verwaltet Sammlungen von Parquet-Dateien; nutzt Arrow als In-Memory-Layer beim Lesen und Schreiben. Andere Schicht der Datenpipeline.
Arrow Flight / Flight SQL	RPC-Framework auf Arrow-Basis	Baut auf dem Arrow-Format auf und transportiert Batches über Netzwerk. Das Format ohne Flight funktioniert weiter.
pandas DataFrame	In-Memory-Repräsentation in Python	Historisch zeilenweise und Typ-heterogen; die Arrow-Backend-Option in Pandas 2.x nutzt das Arrow-Layout intern.

Der zentrale Unterschied Arrow vs. Parquet: Parquet ist ein Datei-Container, der Daten komprimiert und dauerhaft ablegt. Arrow ist ein RAM-Layout ohne Kompression, dafür mit direktem CPU-Zugriff. Ein typischer Analyse-Job liest Parquet-Dateien und materialisiert die Spalten als Arrow-Puffer im Arbeitsspeicher der Engine.

Beispiel: Spark, Pandas und Arrow-Result-Transfer

Ein häufiger Einsatz ist die Beschleunigung des Datenaustauschs zwischen JVM-basierten Engines und Python-Prozessen. Ohne Arrow serialisiert PySpark einen DataFrame beim Aufruf von toPandas() zeilenweise über Pickle, überträgt die Bytes über einen Python-Worker-Prozess und deserialisiert sie in einen Pandas-DataFrame. Bei aktivierter Arrow-Integration (spark.sql.execution.arrow.pyspark.enabled=true) exportiert Spark die Daten als Arrow-Batches, die der Python-Prozess ohne erneute Konvertierung in einen pandas- oder pyarrow-DataFrame lädt. Für breite, numerisch dominierte DataFrames sinkt die Transferzeit typischerweise um den Faktor zehn bis hundert; für schmale DataFrames mit vielen komplexen Objekten bleibt der Effekt kleiner.

Ein zweiter typischer Einsatz ist der Ergebnis-Transfer von Query-Engines an Clients. BigQuery Storage Read API, Snowflake Arrow Result Format und die Databricks SQL Statement API liefern Query-Ergebnisse als Arrow-Batches statt als zeilenbasiertes JSON. Der Client liest den Buffer direkt in pyarrow, pandas oder polars ein, ohne pro Zeile Text zu parsen. Bei Ergebnismengen im Bereich hunderttausender Zeilen dominiert nach der Umstellung die Netzwerklatenz die Gesamt-Antwortzeit; die Deserialisierung fällt als Engpass weg.