Serialisierungs-Frameworks mit Schema Evolution: Apache Avro
In diesem Artikel geht es um Serialisierungs-Frameworks mit Schemaunterstützung und die Evolution von Schemata unter Berücksichtigung der Kompatibilität.
Bei der Entwicklung von Schnittstellen und der Übertragung von Daten zwischen Systemen kommt man an dem Thema Serialisierung in den meisten Fällen nicht vorbei. Dabei ergeben sich häufig Fragen nach einer effizienten Datenübertragung, der Vermeidung von Verwaltungsoverhead und dem Umgang mit Schnittstellenänderungen.
Das Serialisierungs-Framework Apache Avro punktet in derartigen Fragestellungen durch ein kompaktes Binärformat und der Auslagerung von Strukturinformationen in separate Schemata. Da die Schemata nur einmal übertragen werden müssen, ist der Verwaltungsoverhead bei der Übermittlung von Nutzdaten minimal.
Die Änderungsrate von Schnittstellen sollte möglichst gering sein, da dies Auswirkungen auf die Schnittstellennutzer haben kann. Jedoch sieht es in der Realität oft anders aus und Schnittstellen müssen in unregelmäßigen Zeitabständen angepasst werden.
Da die Schnittstellennutzer in der Regel nicht unmittelbar nach der Veröffentlichung einer neuen Schnittstellenversion die jeweiligen Anwendungen entsprechend anpassen, spielt die Strategie bei Entwicklung von Schnittstellen eine entscheidende Rolle, um die Kompatibilität zwischen Schnittstellenanbieter und den Schnittstellennutzern garantieren zu können.
Schema Kompatibilität
Avro bietet in diesem Zusammenhang Unterstützung durch Schema Evolution, bei der klare Vorschriften im Bezug auf die Kompatibilität zwischen unterschiedlichen Schemaversionen gelten.
Für das Mapping zwischen den Schemata unterscheidet Avro zwischen einem Writer-Schema und einem Reader-Schema. Das Writer-Schema wird für die Serialisierung von Daten im Produzenten und das Reader-Schema wird für die Deserialisierung im Konsumenten genutzt.
Werden zwischen den einzelnen Schemaversionen ausschließlich kompatible Änderungen durchgeführt, übernimmt Avro das Mapping der Schemata und die Daten können dementsprechend im Konsumenten deserialisiert werden.
Dabei unterscheidet Avro zwischen Vorwärts- und Rückwärtskompatibilität.
Bei der Vorwärtskompatibilität können Daten, die mit einem neueren Schema serialisiert wurden mit Hilfe eines älteren Schemas deserialisiert werden.
Rückwärtskompatibilität bedeutet, dass Daten, die mit einem älteren Schema serialisiert wurden mit einem neuen Schema deserialisiert werden können.
Schemaänderungen
Werden im Rahmen einer Änderung neue Felder hinzugefügt, muss das zugehörige Schema entsprechend angepasst werden (schema_v1). Dabei ist darauf zu achten, dass ein Standardwert für das jeweilige Feld vorgesehen wird. Dies ist notwendig, damit Daten, die mit einem vorherigen Schema serialisiert wurden, mit dem neuen Schema deserialisiert werden können. In diesem Fall nutzt Avro den Standardwert um das nicht vorhandene Feld zu füllen.
{
"type": "record",
"name": "simpleRecord",
"fields": [
{
"name": "name",
"type": "string",
"default" : "trion"
},
{
"name": "descr",
"type": "string",
"default" : "foo"
} # (1)
]
}-
Angabe eines neuen Feldes mit dem Namen
descr.
Namensänderungen von Feldern sind kritisch, da Avro diese für das Mapping zwischen kompatiblen Schemata nutzt. Soll eine solche Änderung durchgeführt werden, ist neben der Namensänderung die Angabe eines Alias mit dem alten Feldnamen notwendig. Werden Daten mit dem vorherigen Schema (schema_v1) serialisiert, können diese mit Hilfe des Alias aus dem neuen Schema (schema_v2) deserialisiert werden.
{
"type": "record",
"name": "simpleRecord",
"fields": [
{
"name": "name",
"type": "string",
"default" : "trion"
},
{
"name": "info",
"type": "string",
"default" : "foo",
"aliases": [ # (1)
"descr"
]
}
]
}-
Angabe eines Alias mit der Bezeichnung
descr.
Wird ein Feld gelöscht, muss ebenfalls ein neues Schema erstellt werden.
Tritt der Fall ein, dass Daten die mit dem neuen Schema (schema_v3) serialisiert, und mit einem vorherigen Schema (schema_v2) deserialisiert werden, kommt es zu einem Konflikt, da weiterhin das zuvor gelöschte Feld info erwartet wird.
Dies ist ein weiterer Grund Standardwerte als Fallback-Maßnahme zu definieren.
{
"type": "record",
"name": "simpleRecord",
"fields": [
{
"name": "name",
"type": "string",
"default" : "trion"
}
]
}Mit Hilfe von Avro ist es möglich Daten mit einem geringen Verwaltungsoverhead zu übertragen, was das Framework zu einem interessanten Kandidaten für Streaming-Anwendungen, beipielsweise mit Kafka oder Spark und der Verarbeitung von Massendaten macht. Durch den Schema-Support bietet Avro zudem ein Konzept für die Entwicklung und Weiterentwicklung von Datenstrukturen, ohne dabei auf die Kompatibilität zu vorherigen Versionen zu verzichten.
Zu den Themen Kafka und Spark bieten wir sowohl Unterstützung als auch passende Schulungen an:
Sprechen Sie uns gerne an.