--- title: "Apache Avro: der Vertrag zwischen Modulen" url: "https://hurukan.com/de/blog/apache-avro-der-vertrag-zwischen-modulen" description: "Jedes Ereignis zwischen Modulen ist ein Vertrag. Avro schreibt ihn in die Daten; eine Schemaänderung wird zum Vorschlag, freigegeben und aufgezeichnet." --- # Apache Avro: der Vertrag zwischen Modulen 2\. September 2026·4 Min. Lesezeit·Redaktion Zwei Ingenieure von hinten an einem gemeinsamen Tisch in einem ruhigen Büro, zwischen ihnen ein großer Wandbildschirm mit einem abstrakten blau-grauen Diagramm eines Formulars und seiner Versionen, ein gedrucktes Blatt unter einer Hand, ein einzelnes blaues Statuslicht am Bildschirmrahmen Das Vertriebsteam fügt dem Auftrag einen Rabattprozentsatz hinzu. Es ist eine kleine Änderung, in einem Meeting vereinbart, und das Modul, das Aufträge anlegt, beginnt noch am selben Nachmittag, ihn zu senden. Das Finanzmodul, das seit zwei Jahren Aufträge liest, kennt das Feld nicht und nimmt die Nachricht nicht mehr an. Niemand wollte einen Vertrag ändern. Es gab einen Vertrag, er stand nur nirgends geschrieben außer in zwei Stücken Code, die früher übereinstimmten. In einem System aus Modulen, die Ereignisse austauschen, ist jedes Ereignis eine Vereinbarung. Apache Avro ist eines der Formate, die diese Vereinbarung in die Daten selbst schreiben, und der Grund, warum es im Entwurf von Hurukans [Datenschicht](https://hurukan.com/de/system/daten) steht, die im Aufbau ist, hat weniger mit Bytes zu tun als damit, was geschieht, wenn die Vereinbarung sich ändern muss. ## Das Schema reist mit den Daten Ein Avro-Datensatz ist eine kompakte binäre Zeile. Für sich allein ist er nicht lesbar: Die Feldnamen, Typen und die Reihenfolge stehen nicht in den Bytes. Sie stehen im Schema, geschrieben in JSON, und die [Spezifikation](https://avro.apache.org/docs/1.12.0/specification/) definiert einen kleinen Satz von Typen dafür: null, boolean, int, long, float, double, bytes, string sowie die zusammengesetzten record, enum, array, map, union und fixed. Ein Feld kann einen Standardwert tragen, und dieser Standardwert ist es, der Veränderung später überlebbar macht. Die aktuelle Version ist 1.12.2 ([Projektblog](https://avro.apache.org/blog/), geprüft am 21. Oktober 2026). Das Schema erreicht den Leser auf einem von zwei Wegen. In einer Datei legt das Format Object Container File das Schema in den Kopf, gefolgt von Blöcken von Datensätzen, getrennt durch eine Synchronisationsmarke, sodass eine Jahre später gefundene Datei sich noch selbst erklärt. Auf einem Nachrichtenbus, wo das Schema mit jedem Ereignis zu senden Verschwendung wäre, setzt die Single-Object-Kodierung der Spezifikation eine Zwei-Byte-Marke und einen Acht-Byte-Fingerabdruck des Schemas vor jeden Datensatz; eine Registry bewahrt das Schema unter diesem Fingerabdruck. Die verbreitete Confluent-Registry macht dasselbe mit eigener Rahmung, einem Magic Byte und einer Vier-Byte-Schemakennung vor den Avro-Bytes ([Confluent-Dokumentation](https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/index.html)). So oder so rät der Leser nie. Er hat das Schema des Schreibers und sein eigenes, und der Rest sind Regeln. ## Auflösung: wie ein Leser einem Schreiber begegnet, den er nie gesehen hat Die Spezifikation legt fest, was geschieht, wenn sich das Schema des Schreibers und das des Lesers unterscheiden. Felder werden nach Namen zugeordnet. Ein Feld, das der Schreiber gesendet hat und der Leser nicht kennt, wird ignoriert. Ein Feld, das der Leser erwartet und der Schreiber nicht gesendet hat, wird aus dem Standardwert des Lesers gefüllt, und gibt es keinen Standardwert, schlägt das Lesen mit klarem Grund fehl. Manche Typen dürfen unterwegs angehoben werden: Ein int darf als long gelesen werden, ein long als float oder double, ein float als double, und string und bytes dürfen gegenseitig gelesen werden. Eine union wird dem ersten kompatiblen Zweig auf Leserseite zugeordnet. Ausgeschrieben sind diese Regeln die ganze Disziplin des Rabattfeldes. Fügen Sie es mit einem Standardwert hinzu, und das Finanzmodul liest weiter und ignoriert das Feld, bis es gelernt hat, es zu nutzen. Fügen Sie es ohne Standardwert hinzu und entfernen in derselben Änderung ein altes Feld, und der älteste Leser im Unternehmen bleibt stehen. Die Regeln sind kein Ratschlag; sie entscheiden, welche Version des Morgens Sie bekommen. ## Eine Schemaänderung als Vorschlag In Hurukan sieht der Entwurf vor, dass ein Ereignisschema ein Objekt der Ontologie ist wie jedes andere: Es hat einen Verantwortlichen, Versionen und einen Platz in der Aufzeichnung. Das macht aus dem Rabattfeld statt einer nachmittäglichen Codeänderung einen kurzen, aufgezeichneten Weg. **Ein Agent schlägt vor.** Das Vertriebsmodul braucht ein neues Feld; ein Agent entwirft die Schemaänderung mit Standardwert, Typ und Grund und benennt die Module, die dieses Ereignis lesen. **Die Registry prüft.** Die vorgeschlagene Version wird nach den obigen Auflösungsregeln gegen die Schemata der Leser getestet. Eine Änderung, die einen bestehenden Leser anhalten würde, wird abgelehnt, bevor jemand sie sieht, mit Nennung des Lesers. **Der Verantwortliche gibt frei.** Eine kompatible Änderung ist trotzdem eine Änderung an einer Vereinbarung zwischen Modulen. Der Verantwortliche für das Ereignis, eine Person, gibt sie frei, und erst dann beginnen die Produzenten, die neue Version zu schreiben. **Die Aufzeichnung behält sie.** Freigabe, Version und Zeitpunkt werden in die Aufzeichnung geschrieben, sodass ein Jahr später die Frage „wann tauchten Rabatte auf Aufträgen auf, und wer hat das erlaubt” eine Antwort hat. Das ist derselbe Weg, den jede Änderung im System nimmt: Ein Agent schlägt vor, ein Mensch entscheidet, das System zeichnet auf. Der größere Gedanke steht in [Laufender Zustand und Aufzeichnung](https://hurukan.com/de/blog/laufender-zustand-und-aufzeichnung-zwei-gedaechtnisse). ## Wofür Avro nicht da ist Avro trägt Ereignisse gut und liest ganze Datensätze gut. Es ist eine schlechte Anordnung für die Frage, die Superintelligenz am häufigsten stellt, wenige Felder über eine Million Zeilen, weil jedes Feld jedem anderen im Weg liegt. Deshalb werden im Entwurf Ereignisse in Avro zu Spalten gestapelt, sobald sie angenommen wurden. Welche Form wohin gehört, steht in [Parquet und Avro: das Ereignis und die Aufzeichnung](https://hurukan.com/de/blog/parquet-und-avro-ereignis-und-aufzeichnung). Avro taucht auch an einer Stelle auf, an die wenige schauen: Das Tabellenformat Apache Iceberg schreibt seine Manifeste, die Listen der Datendateien, die eine Tabelle bilden, als Avro-Dateien ([Iceberg-Spezifikation](https://iceberg.apache.org/spec/)). Das Zeilenformat, das Ereignisse zwischen Modulen trägt, trägt auch die Buchführung der Aufzeichnung. ## Was bei den Menschen bleibt Ein Agent kann ein Schema entwerfen, die Kompatibilitätsprüfung laufen lassen und die Leser benennen. Er kann nicht entscheiden, dass ein Feld, auf das sich das Finanzmodul verlassen hat, wegfallen darf, dass ein Standardwert von null eine wahre Aussage über alte Aufträge ist oder dass ein Leser scheitern darf. Das sind Entscheidungen über die Bedeutung des Geschäfts, und in Hurukan trifft sie der Verantwortliche für das Ereignis, schriftlich. ## Ein Test, den Sie heute machen können Wählen Sie eine Nachricht, die zwischen zwei Ihrer Systeme wandert. Finden Sie heraus, wo ihre Felder definiert sind. Lautet die Antwort „im sendenden Code” und „im empfangenden Code”, haben Sie zwei Definitionen und keinen Vertrag. Fragen Sie dann, wer das Hinzufügen eines Feldes freigeben würde, namentlich. Gibt es keinen Namen, wird das nächste Feld von dem hinzugefügt, der es zuerst braucht, und von dem entdeckt, bei dem es bricht. Die Seite zur [Datenschicht](https://hurukan.com/de/system/daten) beschreibt, wo dieser Vertrag in Hurukan liegen soll; die [Übersicht](https://hurukan.com/de) zeigt die Module darum herum. - Apache Avro - Schema-Registry - Ereignisverträge - Schemaevolution - Datenschicht ## Weiterlesen - [Eine Identität für Menschen und Agenten: wer was tun darf](https://hurukan.com/de/blog/eine-identitaet-fuer-menschen-und-agenten) - [Laufender Zustand und Aufzeichnung: die zwei Gedächtnisse eines Unternehmensbetriebssystems](https://hurukan.com/de/blog/laufender-zustand-und-aufzeichnung-zwei-gedaechtnisse)