Schema-Evolution mit Avro und Parquet: Reader- und Writer-Schemas, zusammengeführte Dateien und Kompatibilitätsmodi

Worum es geht

Reader müssen mit Datensätzen zurechtkommen, die unter einer anderen Schema-Version geschrieben wurden. Die Avro-Spezifikation (zitiert) gleicht das Schema des Writers, das mit den Daten mitreist, gegen das Schema des Readers ab, das die Anwendung erwartet. Datensatzfelder werden anhand des Namens zugeordnet, die Reihenfolge spielt keine Rolle; ein Writer-Feld, das beim Reader fehlt, wird ignoriert; ein Reader-Feld, das beim Writer fehlt, übernimmt den Standardwert des Readers, und ohne Standardwert wird ein Fehler gemeldet. Promotionen laufen nur in eine Richtung (int zu long, float oder double; long zu float oder double; float zu double); string und bytes sind austauschbar. Parquet kennt keinen Abgleichsschritt: Jede Datei trägt ihr eigenes Schema, und die Spark-Dokumentation (zitiert) beschreibt das Zusammenführen der Schemas von Dateien, die sich unterscheiden, aber gegenseitig kompatibel sind – standardmässig deaktiviert, da es eine relativ teure Operation ist, und pro Lesevorgang mit mergeSchema aktivierbar. Die Dokumentation der Confluent Schema Registry (zitiert) benennt die Kompatibilitätsmodi, die eine Registry erzwingen kann: backward (Consumer mit dem neuen Schema können Daten lesen, die mit dem letzten Schema erzeugt wurden), forward (alte Consumer lesen neue Daten), full (beides) sowie transitive Varianten, die gegen alle früheren Versionen geprüft werden; backward ist der Standard, weil er es Consumern erlaubt, an den Anfang eines Topics zurückzuspulen.

Warum es wichtig ist

Ein beim Producer umbenanntes Feld ist für einen Reader, dessen Schema keinen Alias für den alten Namen trägt, ein gelöschtes und ein hinzugefügtes Feld (Avro kennt Feld-Aliase, aber die Spezifikation stellt ihre Verwendung frei); ein ohne Standardwert hinzugefügtes Feld bricht jeden Consumer alter Daten; eine Typänderung von int zu string bricht den Abgleich. Diese Fehler zeigen sich erst beim Lesen, bei Consumern, die der Verfasserin oder dem Verfasser des Schemas möglicherweise nicht bekannt sind.

So wird es angewendet

• Felder als optional mit Standardwert hinzufügen (in Avro eine Union mit null, Standardwert null); nie ein Feld entfernen, das Consumer noch lesen.
• Eine Umbenennung als Hinzufügen-dann-Entfernen über zwei Releases behandeln, wobei dazwischen beide Felder geschrieben werden – ausser wenn jeder Reader Aliase berücksichtigt.
• Parquet-Spaltennamen stabil halten und sich auf Namen statt auf Positionen verlassen; das Zusammenführen von Schemas nur für Lesevorgänge aktivieren, die es benötigen, und das aktuelle Schema im Tabellenkatalog registrieren.
• Den Kompatibilitätsmodus anhand der Deployment-Reihenfolge wählen: backward, wenn Consumer zuerst deployen, forward, wenn Producer zuerst deployen, full für beide Fälle.
• Bei einer inkompatiblen Änderung ein neues Subject, Topic oder eine neue Tabellenversion anlegen und beide schreiben, solange alte Reader existieren.

Stolpersteine

Ein Avro-Standardwert muss ein für das Schema des Feldes zulässiger Wert sein; bei einer Union muss er zu einer der Varianten der Union passen. Ein dem Reader unbekanntes Enum-Symbol ist ein Fehler, es sei denn, das Enum des Readers hat einen Standardwert. Parquet-Dateien aus unterschiedlichen Werkzeugen können bei den logischen Typen (Zeitstempel, Dezimalzahlen) voneinander abweichen, selbst wenn die physischen Typen übereinstimmen.

Welcher Kompatibilitätsmodus welche Regel erzwingt

Eine Registry erzwingt nur die Richtung, die ihr Modus benennt. BACKWARD (der Confluent-Standard) prüft, ob ein neues Consumer-Schema alte Daten lesen kann; es erlaubt das Löschen von Feldern und das Hinzufügen von Feldern mit Standardwerten, weshalb es auch ein Producer-Schema registriert, das ein Feld entfernt, das alte Consumer noch lesen. FORWARD prüft, ob alte Consumer neue Daten lesen können; es erlaubt das Hinzufügen von Feldern und das Löschen nur optionaler Felder. FULL prüft beides, und die transitiven Varianten prüfen gegen jede frühere Version statt nur gegen die letzte. Der Modus wird danach gewählt, wer zuerst deployt: Consumer zuerst → BACKWARD; Producer zuerst → FORWARD; unbekannt oder viele Consumer → FULL. Die Regel „nie ein Feld entfernen, das Consumer noch lesen“ erzwingt die Registry nur unter FORWARD oder FULL.