Schema Registry

Wat is een schema registry?

Een schema registry is een centrale dienst die de schemas bewaart van de berichten die over een streaming-platform lopen. Een schema legt vast welke velden een bericht heeft, welk type elk veld draagt en welke velden verplicht zijn. In plaats van dat elke applicatie zelf een kopie van die afspraak bijhoudt, staat er één versie op één plek, netjes voorzien van een versienummer.

Het idee ontstond rond streaming met Kafka. Een producer stuurt daar continu berichten die door tientallen consumers gelezen worden. De registry zorgt dat zender en ontvanger dezelfde vorm van die berichten kennen, ook als de teams achter beide kanten los van elkaar werken.

Je kan het vergelijken met een centraal register van formulieren bij een gemeente. Wie een aanvraag indient en wie ze verwerkt, gebruikt hetzelfde formulier in dezelfde versie. Verandert het formulier, dan krijgt het een nieuw versienummer en weet iedereen meteen waar hij aan toe is.

Waarom een schema registry?

Op een streaming-platform draaien producer en consumer als aparte applicaties, elk met een eigen release-ritme. Het team dat de berichten produceert, kan een veld hernoemen of een datatype veranderen zonder dat het team aan de andere kant dat weet.

Bij een nachtelijke batch merk je zo'n breuk de volgende ochtend. Bij streaming data lopen de berichten continu door naar elke consument tegelijk, dus een verkeerde wijziging valt meteen en overal stil. Rapporten lopen leeg, een zoekindex krijgt lege velden, een verwerkingsstap crasht.

Een schema registry vangt dit op door elke nieuwe schemaversie te controleren op het moment dat je ze registreert, dus nog voor ze in productie draait. Breekt de wijziging de afspraak, dan weigert de registry de registratie en blijft de oude versie geldig.

Hoe werkt een schema registry?

De werking draait rond een paar vaste begrippen.

Subject
Een subject is de naam waaronder een reeks schemaversies leeft. Meestal is dat de naam van de Kafka-topic met een achtervoegsel, bijvoorbeeld facturen-value. Elk subject houdt zijn versies in volgorde bij en heeft een eigen compatibiliteitsinstelling.

Versie en schema-id
Elke keer dat je een nieuw schema registreert, krijgt het een versienummer binnen het subject en een globaal uniek schema-id. Dat id is het scharnier van het hele systeem.

Producer en consumer
De serializer bij de producer registreert het schema en plakt enkel het teruggekregen id voor elk bericht, niet het volledige schema. Dat scheelt bytes. De consumer leest het id, haalt het schema op bij de registry en houdt het lokaal bij, zodat dat niet voor elk bericht opnieuw hoeft.

Een schema registry werkt met drie serialisatieformaten: Avro, Protobuf en JSON Schema. Avro is het populairst in de Kafka-wereld, omdat het compact is en schema-evolutie ingebouwd heeft via standaardwaarden en aliassen.

Compatibiliteitsmodi

Een compatibiliteitsmodus is de regel waartegen de registry elke nieuwe versie aftoetst. Je kiest ze per subject.

Backward (de standaard) betekent dat een consumer met het nieuwe schema nog altijd data kan lezen die met de vorige versie geschreven is. Toegelaten: een optioneel veld met standaardwaarde toevoegen, of een veld verwijderen.

Forward betekent het omgekeerde. Data die met het nieuwe schema geschreven is, blijft leesbaar voor een consumer op de vorige versie. Toegelaten: een veld toevoegen, of een optioneel veld verwijderen.

Full combineert beide: de wijziging moet backward en forward compatibel zijn. In de praktijk komt dat neer op enkel velden met een standaardwaarde toevoegen of verwijderen.

None zet de controle uit. Dan mag elke wijziging door, maar moet je producer en consumers samen upgraden om breuken te vermijden.

Een brekende versus een niet-brekende wijziging

Stel dat je een topic hebt met klantgebeurtenissen. Versie 1 van het schema heeft vier velden: klant_id (verplicht), naam (verplicht), email (verplicht) en telefoon (optioneel). Het subject staat op backward, de standaard.

Een niet-brekende wijziging is een veld voorkeurstaal toevoegen met standaardwaarde nl. Een consumer op de nieuwe versie leest een oud bericht zonder dat veld gewoon in en vult de standaardwaarde aan. De registry aanvaardt de nieuwe versie.

Een brekende wijziging is een verplicht veld postcode toevoegen zonder standaardwaarde. Een consumer op de nieuwe versie zou een oud bericht niet meer kunnen lezen, want de postcode ontbreekt daar. Ook het type van email van tekst naar getal veranderen is een breuk. In beide gevallen weigert de registry de registratie en zie je de fout voor er iets in productie staat.

Schema registry versus data contract

Een data contract is de bredere afspraak tussen de producent en de consumenten van een dataset: het schema, maar ook de kwaliteitseisen, de frequentie, de eigenaar en de procedure voor wijzigingen. Een schema registry dekt daar één stuk van af, namelijk het schema en de compatibiliteit ervan, en dwingt dat stuk automatisch af op berichtniveau.

Anders gezegd: het contract beschrijft wat er afgesproken is, de registry geeft die afspraak tanden op je streaming-platform. Voor een stroom die via Change Data Capture en Kafka binnenkomt, is de registry vaak de plek waar je de schema-afspraak afdwingt. Voor batchbestanden zoals Parquet of een tabel in je warehouse gebeurt die handhaving eerder in je transformatietool of je kwaliteitstests.

De bekende implementaties

Confluent Schema Registry is de referentie. Deze REST-dienst hoort bij Confluent Platform en Confluent Cloud en introduceerde de begrippen subject, versie en compatibiliteit die de rest overnam.

AWS Glue Schema Registry is de serverloze variant van Amazon. Ze werkt samen met Amazon MSK, Kinesis Data Streams, Managed Service for Apache Flink en Lambda, en ondersteunt Avro, JSON Schema en Protobuf.

Azure Event Hubs Schema Registry zit ingebouwd in een Event Hubs-namespace, groepeert schemas in schema groups en ondersteunt onder meer Avro en JSON Schema.