Wann würdest du Parquet statt Avro einsetzen, und warum?

Parquet ist spaltenorientiert, komprimiert also gut und erlaubt einer Query, nur die benötigten Spalten zu lesen, was es für analytische Reads richtig macht. Avro ist zeilenorientiert mit kompakter Binärkodierung und starker Unterstützung für Schema Evolution, was es für schreiblastige Pfade und Message-Payloads richtig macht, bei denen du ganze Records konsumierst. Kurz: Avro für Transport und Landing, Parquet für die analytischen Tabellen, die du abfragst.

Der Unterschied ist das physische Layout. Parquet speichert Werte Spalte für Spalte, also liegen alle Timestamps beieinander und komprimieren stark, und eine Query, die drei von vierzig Spalten auswählt, liest tatsächlich nur Bytes im Umfang von drei Spalten. Zusätzlich hält es Min- und Max-Statistiken pro Row Group, sodass Predicate Pushdown ganze Blöcke überspringen kann. Avro ist zeilenorientiert, ein Record liegt also zusammenhängend, und genau das willst du, wenn du Events anhängst oder ganze Messages von einem Topic liest. In der letzten Pipeline, die ich gebaut habe, waren die Kafka-Payloads Avro mit Schema Registry, wir haben sie als Avro in der Raw Zone gelandet und dann in Parquet im Curated Layer verdichtet. Das gab uns günstige Writes am Rand und günstige analytische Reads weiter hinten. Beide beherrschen Schema Evolution, aber Avros Regeln zum Hinzufügen eines Felds mit Default sind nachsichtiger für Producer und Consumer, die zu unterschiedlichen Zeitpunkten deployen, weshalb es auf der Transportseite meist gewinnt.