Apache Avro: Definition des zeilenbasierten Formats

Apache Avro ist ein Datenformat, das Datensätze zeilenweise als kompakte Binärdaten speichert und den zugehörigen Bauplan (das Schema, also die Feldnamen und Datentypen) getrennt davon in einer JSON-Datei ablegt. Avro wird vor allem für den Transport von Ereignis-Nachrichten in Kafka (einem verteilten Nachrichten-System) und als langlebiges Speicherformat im Umfeld von Hadoop und Lakehouse (moderne Datenplattformen) eingesetzt. Der Kern-Nutzen ist die Schema-Evolution: das Feld-Layout darf sich mit der Zeit ändern, ohne dass ältere Programme brechen.

Was ist Apache Avro?

Apache Avro besteht aus zwei Teilen. Das Wire-Format (die eigentliche binäre Darstellung auf der Leitung oder auf der Festplatte) packt einen Datensatz kompakt und zeilenweise zusammen. Das Schema (der Bauplan der Daten) liegt in einer separaten JSON-Datei und beschreibt Feldnamen, Datentypen, Standard-Werte und optionale Felder. Wer Daten schreibt, benutzt das Writer-Schema; wer sie später liest, sein eigenes Reader-Schema. Weichen die beiden voneinander ab, gleicht Avro sie automatisch ab: fehlende Felder werden mit Standard-Werten aufgefüllt, unbekannte Felder ignoriert. Diese Trennung von Bauplan und Nutzdaten ist der zentrale Unterschied zu selbstbeschreibenden Formaten wie JSON, in denen die Feldnamen in jedem einzelnen Datensatz mitgeschickt werden.

Das Projekt entstand 2009 als Teil des Hadoop-Ökosystems und wurde später ein eigenständiges Apache-Top-Level-Projekt. Der Ausgangspunkt war eine Schwäche der damaligen Hadoop-Serialisierungsformate wie SequenceFile und Thrift: statische Codegenerierung, fehlende Schema-Evolution und schlechte Interoperabilität zwischen Sprachen. Avro liefert stattdessen dynamische Reader-/Writer-Schema-Auflösung ohne verpflichtende Codegenerierung und bindet Java, Python, C, C++, C#, Go, Rust, PHP und Ruby über offizielle oder inoffizielle Bibliotheken an.

Es gibt zwei typische Einsatzformen. Für den persistenten Speicher schreibt Avro in eine .avro-Datei, die das Schema im Header trägt (Container-Format mit Sync-Markern für Split-Fähigkeit und optionaler Deflate- oder Snappy-Kompression pro Block). Für den Message-Transport, etwa auf einem Kafka-Topic, kommt das Schema nicht in jede Nachricht, sondern in eine [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html); die Payload trägt nur eine Schema-ID, den Rest holt der Consumer per Lookup. Beide Varianten sind kompatibel mit demselben Schema, unterscheiden sich aber im Overhead pro Record.

Schema-Evolution ist der Grund, warum Avro sich in Streaming-Architekturen durchgesetzt hat. Die Spec definiert drei Kompatibilitätsmodi: Backward-Compatibility erlaubt neue Consumer, alte Producer weiterzuverarbeiten (Default-Werte für neue Felder); Forward-Compatibility deckt den umgekehrten Fall ab (alte Consumer ignorieren neue Felder); Full-Compatibility fordert beides gleichzeitig. Diese Regeln sind fester Bestandteil des Formats und werden von der Schema Registry durchgesetzt, bevor ein neues Schema registriert wird.

Abgrenzung zu Parquet, JSON und Protobuf

Apache Avro wird häufig mit benachbarten Datenformaten verwechselt, weil Zeilen-/Spalten-Format, Text-/Binär-Darstellung und Schema-gebunden/schemalos oft gleichzeitig diskutiert werden.

Begriff	Verhältnis zu Apache Avro
Parquet	Spaltenorientiertes On-Disk-Format, komprimiert, für analytische Scans. Avro ist zeilenorientiert und für Write-heavy Streams und Zeilen-Lesen ausgelegt. Faustregel: Avro schreibt und transportiert, Parquet liest analytisch.
ORC	Ebenfalls spaltenorientiertes On-Disk-Format aus dem Hadoop-Ökosystem. Wie Parquet analytisch optimiert; Avro und ORC sind komplementäre Formate in derselben Pipeline.
JSON	Textbasiert und selbstbeschreibend, Feldnamen in jedem Record. Avro trennt Schema vom Payload und ist deutlich kompakter, dafür ohne Schema unlesbar.
Protobuf	Binäres, schema-gebundenes Format mit numerischen Feld-IDs. Kompatibilität arbeitet über stabile Tag-Nummern statt Schema-Resolution. In der Praxis dominiert Protobuf bei gRPC-APIs, Avro bei Kafka-Topics und im Hadoop-/Lakehouse-Ingest.
Thrift	Binäres Format mit Codegenerierung und Feld-IDs, ähnlich Protobuf. Historisch bei Facebook entwickelt; im aktuellen Data-Stack seltener anzutreffen als Avro oder Protobuf.

Der wichtigste Unterschied Avro vs. Parquet: Parquet legt jede Spalte separat und komprimiert auf Disk ab, ideal für analytische Aggregationen über wenige Spalten breiter Tabellen. Avro speichert ganze Records am Stück, was beim Schreiben eines Streams billiger ist als eine spaltenweise Zerlegung. Ein typischer Lakehouse-Pfad liest Avro-Events aus Kafka, materialisiert sie in eine Delta- oder Iceberg-Tabelle und komprimiert dort spaltenweise nach Parquet weiter.

Beispiel: Kafka-Topic mit Schema Registry und CDC-Landing-Zone

Ein häufiger Einsatz ist der Transport von Ereignissen zwischen Anwendungen und einem Lakehouse. Eine Produktions-Anwendung publiziert Bestell-Events auf ein Kafka-Topic. Der Producer serialisiert jeden Record mit einem Avro-Schema, das über die Confluent Schema Registry versioniert wird. Ein neues Feld im Schema wird nur akzeptiert, wenn es einen Default-Wert hat und die konfigurierte Kompatibilitäts-Policy (etwa Backward-Compatible) einhält. Alte Consumer lesen weiter mit dem alten Schema und ignorieren das neue Feld über Reader-/Writer-Resolution. Der Producer-Payload enthält nur eine 4-Byte-Schema-ID plus die binären Feldwerte.

Ein zweiter typischer Einsatz ist die Landing-Zone einer CDC-Pipeline. [Debezium](https://debezium.io/documentation/reference/stable/index.html) liest den Write-Ahead-Log einer PostgreSQL- oder MySQL-Instanz und schreibt jede Änderung als Avro-Event auf Kafka. Ein Databricks-Job liest die Topics inkremental und materialisiert die Events in eine Delta-Tabelle im Bronze-Layer. Die Wahl von Avro auf dieser Strecke hat einen konkreten Grund: Änderungen am Quell-Schema (neue Spalte, umbenanntes Feld) sind normal, und die Schema Registry stellt sicher, dass eine solche Änderung nicht die gesamte Pipeline bricht. Analytische Queries laufen erst auf der Delta-Tabelle, die intern auf Parquet basiert.