ORC-Format: Definition des spaltenorientierten Speichers

ORC (Optimized Row Columnar) ist ein Dateiformat zum Speichern großer Tabellen auf der Festplatte. Statt eine Tabelle Zeile für Zeile abzulegen, speichert ORC jede Spalte in einem eigenen Block und komprimiert die Werte. Das Format stammt aus dem Hadoop-Umfeld (einem Open-Source-Baukasten für die Verarbeitung großer Datenmengen) und wird vor allem in Analyse-Datenbanken eingesetzt, wenn Abfragen nur wenige Spalten aus sehr breiten Tabellen brauchen.

Was ist ORC?

Eine ORC-Datei ist eine binäre Datei (ein maschinelles Format, das Programme direkt einlesen). Sie zerlegt eine große Tabelle in mehrere Pakete, sogenannte Stripes (Standardgröße 64 bis 256 Megabyte pro Paket). Jeder Stripe enthält drei Teile: einen Index mit kleinen Kennzahlen pro Spalte (kleinster und größter Wert, optionale Filter-Hinweise, sogenannte Bloom-Filter), die eigentlichen Spaltenwerte und einen kurzen Steuerblock mit Angaben zur Kompression. Am Ende der Datei steht ein Verzeichnis mit dem Aufbau der gesamten Tabelle. Dieser Aufbau erlaubt Predicate Pushdown: die Abfrage-Engine (die Software, die SQL-Abfragen ausführt) liest zuerst die Kennzahlen und überspringt komplette Stripes, deren Werte für die aktuelle WHERE-Bedingung nicht in Frage kommen.

Innerhalb einer Spalte kommen typenbewusste Encodings zum Einsatz. Ganzzahlen werden mit Run-Length-Encoding und Delta-Kodierung komprimiert, Strings über Dictionary-Encoding wenn die Kardinalität niedrig ist, Booleans als Bit-Streams. Auf das Encoding-Ergebnis wird optional eine allgemeine Kompression (Snappy, Zlib, ZSTD, LZO) angewendet. Der Reader dekodiert nur die tatsächlich abgefragten Spalten; breite Tabellen mit hundert Spalten kosten daher bei Aggregationen über wenige Spalten nicht das gesamte Zeilenvolumen.

Das Projekt startete 2013 bei Hortonworks als Nachfolger von RCFile im [Apache-Hive](https://hive.apache.org/)-Kontext. Ziel war bessere Kompression und höhere Scan-Geschwindigkeit ohne einen Wechsel der Query-Engine (Hive konnte den ORC-Reader direkt einbinden). 2015 wurde ORC ein eigenständiges Apache-Top-Level-Projekt. Historisch trugen Hortonworks, Cloudera, Microsoft und Uber die meisten Commits.

In [Apache Hive 3+](https://cwiki.apache.org/confluence/display/Hive/Hive+Transactions) ist ORC das einzige Format mit voller ACID-Semantik: transaktionale Tabellen schreiben Änderungen als Delta-Files pro Bucket, ein periodischer Compaction-Job faltet diese in Base-Files zurück. Damit lassen sich Updates und Deletes auf einem klassischen Hive-Warehouse ausführen, ohne ein separates Tabellenformat wie Delta Lake oder Iceberg einzuführen.

Abgrenzung zu Parquet, Avro und Arrow

ORC wird häufig mit benachbarten Datenformaten verwechselt, weil On-Disk-Format, Zeilen-/Spalten-Layout und In-Memory-Repräsentation in derselben Pipeline auftauchen.

Begriff	Schicht	Verhältnis zu ORC
Parquet	On-Disk-Format (komprimiert, spaltenorientiert)	Direktes Pendant. Struktur ähnlich (Row Groups statt Stripes, Column Chunks, Page-Statistiken). Vergleichbare Kompression und Query-Geschwindigkeit; die Wahl folgt heute meist dem Ökosystem: Parquet dominiert bei Delta Lake, Iceberg und Databricks; ORC bei klassischen Hive-Warehouses.
Avro	On-Disk-Format (binär, zeilenorientiert)	Zeilenorientiert und auf Schema-Evolution ausgelegt; typisch für Kafka-Streams und CDC-Landing-Zones. Avro schreibt und transportiert, ORC liest analytisch; beide Formate treten oft nacheinander in derselben Pipeline auf.
Arrow	In-Memory-Format (unkomprimiert, spaltenorientiert)	RAM-Layout, kein persistenter Speicher. ORC-Reader dekodieren die Stripes in Arrow-Buffers, auf denen die Engine dann vektorisiert rechnet.
Delta Lake / Iceberg	Tabellenformat (Metadaten, Transaktionen, Schema-Evolution)	Verwaltet Sammlungen von Datendateien (meist Parquet, technisch aber auch ORC-fähig) mit Transaktions-Log. Eine andere Schicht als ORC selbst; kein Ersatz.
RCFile	On-Disk-Format (spaltenorientiert, Hive-Vorgänger)	Historischer Vorgänger im Hive-Kontext. ORC bringt Predicate Pushdown, bessere Kompression und Typ-Awareness; RCFile ist im aktuellen Stack faktisch abgelöst.

Der wichtigste Unterschied ORC vs. Parquet: technisch trennen die beiden Formate wenige Details (Stripe- vs. Row-Group-Größe, Encoding-Katalog, Bloom-Filter-Handling), praktisch entscheidet das umgebende Ökosystem. Neue Lakehouse-Projekte auf Databricks, Snowflake oder mit Iceberg landen in Parquet; Bestands-Warehouses auf Hive, Trino und HDFS bleiben in ORC.

Beispiel: Hive-Warehouse mit transaktionalen Tabellen und Spark-Analyse

Ein häufiger Einsatz ist ein Hive-3-Warehouse auf HDFS oder Object Store. Faktentabellen liegen als ORC-Dateien mit ZSTD-Kompression, stripe.size=128MB und Bloom-Filtern auf den Join-Spalten. Die Tabellen sind mit transactional=true angelegt, sodass INSERT-, UPDATE- und DELETE-Statements gültig sind. Änderungen landen als Delta-Files pro Bucket; ein periodischer Major-Compaction-Job faltet sie in neue Base-Files zurück. Hive- und Trino-Queries nutzen Predicate Pushdown auf die Stripe- und Row-Index-Statistiken und lesen nur die relevanten Stripes und Spalten aus dem Object Store.

Ein zweiter typischer Einsatz ist der Spark-Zugriff auf einen bestehenden ORC-Bestand. Ein Databricks- oder On-Prem-Spark-Cluster liest existierende ORC-Tabellen über spark.read.orc(...) oder über den [Hive-Metastore](https://cwiki.apache.org/confluence/display/hive/design). Der [ORC-Reader](https://docs.databricks.com/aws/en/query/formats/orc) in Spark 3+ ist vektorisiert und liefert Arrow-kompatible Batches an die Engine. Für neue Tabellen wählen die meisten Databricks-Teams heute Delta Lake auf Parquet; bestehende ORC-Tabellen bleiben aber ohne Konvertierung les- und schreibbar und können im Unity Catalog als externe Tabelle registriert werden.