Ein Schema-Register ist ein zentraler Dienst, der die Schemata speichert, verwaltet und validiert, die zur Serialisierung und Deserialisierung von Daten verwendet werden, die über Apache Kafka ausgetauscht werden. Anstatt jeder Produzenten- und Konsumentenanwendung die Möglichkeit zu geben, Nachrichtenformate unabhängig voneinander zu definieren, bietet ein Schema-Register eine gemeinsame „Quelle der Wahrheit“ für die Strukturierung von Ereignisdaten.
In Kafka werden Ereignisse häufig mithilfe von Formaten wie Apache Avro, JSON Schema oder Protocol Buffers serialisiert, oft abgekürzt zu protobuf. Das Schema-Register speichert die Definitionen für diese Formate und weist jedem Schema eine eindeutige Kennung zu. Dies wird als Schema-ID bezeichnet.
Wenn ein Produzent eine Nachricht an ein Kafka-Topic schreibt, fügt er typischerweise die Schema-ID zusammen mit den serialisierten Daten ein, anstatt das gesamte Schema in jede Nachricht einzubetten. Die Nachrichtenempfänger rufen dann das entsprechende Schema aus dem Register ab und verwenden es, um die Daten korrekt zu deserialisieren und zu interpretieren.
Eine Schemaregistrierung ist in einem ereignisbasierten System wichtig, weil sie sicherstellt, dass sich Hersteller und Verbraucher über die Struktur der ausgetauschten Daten einig sind. Dies unterstützt die Datenqualität und die Datenintegrität.
Ohne ein zentrales Register müssten Anwendungen Nachrichtenschemata unabhängig verwalten. Dadurch erhöht sich das Risiko inkompatibler Änderungen, die dazu führen könnten, dass Ereigniskonsumenten ausfallen oder Daten falsch interpretieren.
Das Schema-Register unterstützt auch die sogenannte Schema-Evolution. Dies ermöglicht es Entwicklern, Ereignisstrukturen im Laufe der Zeit zu modifizieren und gleichzeitig die Kompatibilität mit bestehenden Anwendungen aufrechtzuerhalten.
Zum Beispiel kann oft ein neues optionales Feld hinzugefügt werden, ohne das Format zu verletzen, das bestehende Kafka-Verbraucher erwarten. Kompatibilitätsregeln helfen dabei, sichere Schemaänderungen vor deren Bereitstellung durchzusetzen.
Bleiben Sie mit dem Think-Newsletter über die wichtigsten – und faszinierendsten – Branchentrends in den Bereichen KI, Automatisierung, Daten und mehr auf dem Laufenden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
Ein weiterer wichtiger Vorteil ist eine verbesserte Data-Governance. Schemata werden in einem zentralen Repository gespeichert, sodass Unternehmen die Struktur ihrer Ereignisdaten dokumentieren, überprüfen, versionieren und auditieren können.
Dieser Ansatz erleichtert es den Entwicklungsteams:
In modernen Datenplattformen kann ein Schema-Register auch Datenverträge zwischen Kafka-Produzenten und Kafka-Konsumenten ermöglichen. Diese Verträge definieren nicht nur die Struktur der Daten, sondern auch die Erwartungen, wie sich diese Daten im Laufe der Zeit entwickeln sollten.
Durch die Validierung von Schemaänderungen vor deren Veröffentlichung kann ein Schema-Register dazu beitragen, dass fehlerhafte Änderungen nicht in die Produktion gelangen und die Zuverlässigkeit ereignisgesteuerter Architekturen verbessert wird.
Ein Schema-Register bietet einen zentralen Mechanismus zur Verwaltung von Ereignisschemata, zur Sicherstellung der Kompatibilität zwischen diesen Schemata und zur Unterstützung von Änderungen an diesen Schemata.
Ein Register ermöglicht es Entwicklern außerdem, neue Schemata auf der Grundlage älterer Schemata zu erstellen, eine strukturierte Komposition in Schemata zu schaffen und Ereignisnamen mithilfe einer Subjekt-Name-Strategie zu standardisieren.
Diese Methoden helfen Anwendungen beim Datenaustausch, wenn sich Systeme und Anforderungen ändern.
Ein Schemaregister speichert und verwaltet die Schemata, die die Struktur der zwischen Produzenten und Verbrauchern ausgetauschten Ereignisdaten definieren. Wenn ein Produzent Daten an ein Kafka-Topic sendet, serialisiert er die Nachricht gemäß einem registrierten Schema und fügt Informationen hinzu, die es ermöglichen, das entsprechende Schema zu identifizieren. Ein Konsument kann dann dieses Schema verwenden, um die Nachricht zu deserialisieren und korrekt zu interpretieren. Da sich Schemata im Laufe der Zeit ändern, kann das Register auch Kompatibilitätsprüfungen für neue Schemaversionen durchführen, bevor diese registriert werden. Dies hilft Produzenten und Konsumenten dabei, weiterhin mit sich weiterentwickelnden Datenstrukturen zu arbeiten.
Stellen Sie sich einen großen Online-Händler vor, der mehrere Systeme hat, die Daten generieren und konsumieren: eine E-Commerce-Website, eine mobile App, eine Empfehlungs-Engine, ein Bestandsmanagementsystem, eine Versandplattform und eine Kundenanalyseplattform. Jedes dieser Systeme kommuniziert, indem es Ereignisse über Apache-Kafka-Cluster mit Confluent Cloud veröffentlicht und konsumiert und diese Ereignisse in ein Data Warehouse mit Kafka Connect in seiner Datenpipeline streamt.
Jede Aktion auf der Website erzeugt mehrere Ereignisse in den Systemen des Einzelhändlers. Immer wenn ein Kunde eine Bestellung aufgibt, veröffentlicht die Website ein Ereignis
Mehrere Downstream-Anwendungen verarbeiten dasselbe Ereignis. Das Bestandssystem reserviert die gekauften Artikel, das Zahlungssystem bestätigt die Transaktion und das Lager beginnt mit der Erfüllung. Die Empfehlungs-Engine aktualisiert die Kundenpräferenzen, die Analyseplattform erfasst den Verkauf und der Kundenbenachrichtigungsdienst versendet eine E-Mail-Bestätigung.
Anfangs enthält das Ereignis
Stellen Sie sich nun vor, dass das Unternehmen Monate später beschließt, den internationalen Vertrieb zu unterstützen. Entwickler aktualisieren die Website, sodass jede Bestellung nun zwei neue Felder enthält:
Ohne ein Schema-Register gibt es keinen zentralen Mechanismus zur Koordinierung dieser Änderung. Manche Datennutzer von Ereignisdaten erwarten die neuen Felder, andere nicht. Wenn ein Entwickler versehentlich
Wie könnte dasselbe Szenario mit einer Confluent Schema Registry zur Unterstützung der Schemaverwaltung aussehen?
Bevor der aktualisierte Produzent bereitgestellt wird, registriert das Entwicklungsteam eine neue Version des Schemas
Wenn die vorgeschlagenen Änderungen diesen Kompatibilitätsregeln entsprechen, kann die neue Schema-Version registriert werden. Verstößt eine Änderung gegen die konfigurierte Kompatibilitätsrichtlinie, kann das Register sie ablehnen, bevor Anwendungen das inkompatible Schema verwenden.
Dies bedeutet, dass Entwickler eine fehlerhafte Schemaänderung während der Entwicklung und nicht erst nach der Bereitstellung entdecken können. Bestehende Kunden können mit kompatiblen Änderungen weiterhin arbeiten, während die Entwicklerteams ihre Anwendungen schrittweise aktualisieren können, um die neuen Felder zu nutzen, sobald sie bereit sind.
Die Vorteile eines Schemaregisters werden mit zunehmendem Wachstum des Unternehmens immer bedeutender. Hunderte von Anwendungen, die von Dutzenden von Ingenieurteams entwickelt wurden, könnten Daten über Tausende verschiedener Ereignistypen austauschen.
Ohne ein Schema-Register müsste jedes Team Schemaänderungen manuell koordinieren, indem es handgeschriebene Dokumentationen verwendet, Besprechungen abhält oder auf Versuch und Irrtum setzt. Dieser manuelle Prozess kann die Entwicklung verlangsamen und die Wahrscheinlichkeit erhöhen, dass inkompatible Änderungen die Produktion erreichen.
Mit einem Schemaregistrer werden Ereignisschemata zu zentral verwalteten Assets. Hersteller können Daten gemäß registrierten Schemata veröffentlichen, Verbraucher können diese Schemadefinitionen verwenden, um eingehende Ereignisse zu interpretieren, und Kompatibilitätsprüfungen können inkompatible Schemaänderungen identifizieren.
Neue Teams können auch auf bestehende Ereignisdefinitionen zurückgreifen, anstatt Nachrichtenformate per Reverse Engineering zu ermitteln. Dies erleichtert die Entwicklung neuer Anwendungen und die Integration neuer Systeme.
Wenn der Einzelhändler skaliert, bietet das Schemaregister eine zentrale Möglichkeit, sich entwickelnde Ereignisschemata für Hersteller und Verbraucher zu verwalten.
Die Schemakompatibilität bestimmt, ob Anwendungen, die unterschiedliche Versionen eines Schemas verwenden, auch bei der Weiterentwicklung von Schemata weiterhin Daten korrekt austauschen und interpretieren können. Die wichtigsten Kompatibilitätsmodi sind Rückwärtskompatibilität, Aufwärtskompatibilität und vollständige Kompatibilität.
Einige Schema-Register unterstützen auch transitive Versionen dieser Kompatibilitätsmodi. Anstatt eine neue Schema-Version nur mit der unmittelbar vorhergehenden Version zu vergleichen, vergleichen transitive Kompatibilitätsprüfungen sie mit allen relevanten früheren Versionen. Die genauen Kompatibilitätsregeln und erlaubten Schemaänderungen hängen vom Schemaformat und den Kompatibilitätseinstellungen des Registers ab.
Vorwärtskompatibilität ist dann sinnvoll, wenn ältere Produzenten fortfahren müssen, während neuere Konsumenten Daten von diesen älteren Produzenten ohne Unterbrechung verarbeiten müssen. In dieser Situation besteht die Priorität darin, sicherzustellen, dass neu eingesetzte Anwendungen mit Nachrichten kompatibel bleiben, die noch von älteren Versionen der Herstellersoftware generiert werden.
Stellen Sie sich einen landesweiten Stromversorger vor, der ein intelligentes Stromnetz betreibt. Dieses Netz besteht aus Millionen intelligenter Zähler, die in Haushalten und Unternehmen installiert sind. Jeder dieser Zähler veröffentlicht Stromverbrauchsereignisse an Apache Kafka. Diese Zähler sind jahrelang in Betrieb und können Firmware-Updates nur während der geplanten Wartung erhalten. Dies bedeutet, dass viele Zähler noch lange nach der Veröffentlichung neuerer Softwareversionen Ereignisse nach einem älteren Schema fortfahren.
Unterdessen aktualisiert das Versorgungsunternehmen regelmäßig seine zentralen Überwachungs- und Analyseanwendungen. Eine neue Version der Analyseplattform bietet Unterstützung für zusätzliche Informationen, wie z. B. Metriken zur Energiequalität und zur Erzeugung erneuerbarer Energien. Diese neuen Felder sind nützlich, sofern sie verfügbar sind, doch die Plattform muss weiterhin Daten von älteren Zählern verarbeiten, die diese nicht übermitteln.
In diesem Szenario ist Vorwärtskompatibilität wichtiger als Kompatibilität mit einer früheren Version, da zuerst die Konsumenten aktualisiert werden, während viele Produzenten weiterhin ältere Schemaversionen verwenden. Die neue Verbrauchersoftware muss in der Lage sein, Ereignisse, die mit älteren Schemas geschrieben wurden, korrekt zu lesen, auch wenn diesen Ereignissen die neu eingeführten Felder fehlen. Die Anwendung kann die fehlenden Felder als optional behandeln oder Standardwerte zuweisen, während sie weiterhin ihre primären Funktionen ausführt.
Wäre die Abwärtskompatibilität stattdessen das Hauptanliegen, würden sich die Entwickler darauf konzentrieren, sicherzustellen, dass neuere Konsumenten Daten lesen können, die mit älteren Produzentenschemata geschrieben wurden. Die unmittelbare Herausforderung für das Unternehmen besteht jedoch darin, eine langlebige Flotte älterer Geräte zu unterstützen und gleichzeitig die zentralen Verarbeitungssysteme zu modernisieren.
Durch die Verwendung eines Schema-Registers mit geeigneten Kompatibilitätsregeln kann das Versorgungsunternehmen seine Ereignisschemata weiterentwickeln, ohne dass gleichzeitige Firmware-Updates für Millionen von eingesetzten Zählern erforderlich sind. Dies ermöglicht eine schrittweise Einführung, bei der Produzenten und Konsumenten zu unterschiedlichen Zeitpunkten aktualisiert werden können, wobei die konfigurierten Kompatibilitätsanforderungen des Unternehmens stets eingehalten werden.
Ein Schema-Register kann Compliance-Bemühungen im Zusammenhang mit Datenschutzvorschriften wie der Datenschutz-Grundverordnung (DSGVO) und dem California Consumer Privacy Act (CCPA) unterstützen.
Ein Schema-Register gewährleistet zwar nicht von sich aus die Einhaltung gesetzlicher Vorschriften, kann Unternehmen aber dabei helfen, Data-Governance, Konsistenz- und Prüfverfahren zu implementieren, die zur Erfüllung regulatorischer Anforderungen erforderlich sind.
Ein Hauptvorteil ist die verbesserte Transparenz der verarbeiteten Daten.
Jedes Ereignisschema wird in einem zentralen Repository gespeichert, das die im Schema dargestellten Felder dokumentiert. Dies liefert eine Informationsquelle darüber, welche Daten existieren, welche spezifischen Felder sie repräsentieren und wie Anwendungen die von ihnen erzeugten oder verbrauchten Daten strukturieren.
Dies kann Unternehmen dabei helfen, Schemata zu identifizieren, die personenbezogene Daten (PII) wie Namen, E-Mail-Adressen oder Kontonummern enthalten.
Ein Schema-Register kann auch die Datenminimierung unterstützen, die ein Grundprinzip der DSGVO ist.
Bevor ein Schema genehmigt wird, können Entwickler und Data-Governance-Teams überprüfen, ob jedes Feld für den beabsichtigten Geschäftszweck notwendig ist. Dieser Überprüfungsprozess kann helfen, zu verhindern, dass Anwendungen unnötige persönliche Informationen sammeln oder teilen.
Schema-Validierung kann auch helfen, unautorisierte oder versehentliche Änderungen zu verhindern, die neue, sensible Daten in Produktionssysteme einführen.
Wenn ein Entwickler beispielsweise versucht, die Sozialversicherungsnummer oder die Führerscheinnummer eines Kunden zu einem bestehenden Kafka-Ereignis hinzuzufügen, kann das vorgeschlagene Schema vor der Bereitstellung überprüft werden.
Dieser Ansatz schafft neben den normalen Anwendungstests einen zusätzlichen Kontrollpunkt.
Versionierung und Schemaverlauf bieten Audit-Funktionen.
Jede Schemaänderung wird protokolliert, sodass Unternehmen feststellen können, wann Felder hinzugefügt, geändert oder entfernt wurden.
Während eines Compliance-Audits kann diese Historie zeigen, dass Datenstrukturen kontrolliert und nachverfolgbar verwaltet werden.
Ein Schema-Register kann auch die Konsistenz über mehrere Systeme hinweg verbessern.
Da Hersteller und Verbraucher auf gemeinsame Schemadefinitionen angewiesen sind, können Anwendungen Felder gemäß gängigen Strukturdefinitionen interpretieren.
Dadurch kann die uneinheitliche Datenverarbeitung zwischen verschiedenen Anwendungen reduziert werden.
Viele Unternehmen verwenden ein Schema-Register als Teil der Implementierung von Datenverträgen.
Diese Verträge definieren nicht nur die Struktur eines Ereignisses, sondern auch Metadaten zu den enthaltenen Daten.
Mithilfe einer automatisierten Validierung kann dann überprüft werden, ob neue Schemaversionen fortfahren die definierten Anforderungen erfüllen.
Schema-Register können auch in umfassendere Datenverwaltungs- und Sicherheitstools integriert werden.
Metadaten, die zusammen mit Schemata gespeichert werden, können von Systemen wie den folgenden verwendet werden:
Ein Schema-Register kann daher eine Komponente einer breiteren Governance-Architektur bilden.
In Kombination mit Verschlüsselung, Zugriffskontrollen, Datenspeicherungsrichtlinien und Protokollierung kann das Schema-Management Unternehmen dabei helfen, zu verwalten, wie personenbezogene Daten gesammelt, verarbeitet und geteilt werden.
Mehrere Plattformen bieten Schema-Register-Funktionen für Kafka und verwandte Datensysteme.
Confluent Schema Registry ist ein weit verbreitetes, Kafka-spezifisches Schema-Register.
Es ist Teil des Confluent-Systems und sowohl als selbstverwaltete Komponente der Confluent-Plattform als auch als verwaltetes System in Confluent Cloud verfügbar.
Es unterstützt Avro, Protobuf und JSON Schema und bietet Schema-Versionierung, Kompatibilitätsregeln, Validierung und Integration in Kafka-Produzenten und -Konsumenten.
Amazon Web Services stellt das AWS Glue Schema Registry bereit.
Es handelt sich um ein verwaltetes Schema-Register, das in Apache Kafka, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Kinesis, Amazon Managed Service für Apache Flink und AWS Lambda integriert ist.
Es unterstützt Avro, JSON Schema und Protobuf.
Apicurio Registry ist ein Open-Source-Schema- und API-Artefakt-Register, das mit Kafka verwendet werden kann.
Es unterstützt Formate wie Avro, JSON Schema und Protobuf und kann in Umgebungen wie Kubernetes bereitgestellt werden.
Apicurio bietet außerdem Kompatibilität mit der Confluent Schema Registry API, was die Verwendung mit Kafka-Anwendungen erleichtert, die auf den Schema-Register-Schnittstellen von Confluent basieren.
Redpanda bietet auch einen mit Schema Registry kompatiblen Dienst als Teil seiner Kafka-kompatiblen Streaming-Plattform an.
Dieser Ansatz kann nützlich sein, wenn ein Unternehmen Redpanda statt Apache Kafka direkt nutzt, da das Schema-Management als Teil der Streaming-Plattform selbst bereitgestellt werden kann.
Das Redpanda-Register ist enger in eine alternative, Kafka-kompatible Streaming-Plattform integriert.
Nein, ein Schema-Register ist nicht Teil der Kernsoftware von Apache Kafka. Kafka speichert und transportiert Aufzeichnungen. Ein Schema-Register ist ein separater Dienst, der Schemata für die in diesen Datensätzen enthaltenen Daten speichert und verwaltet. Schema-Register werden häufig zusammen mit Kafka verwendet, um Produzenten und Konsumenten dabei zu helfen, strukturierte Ereignisdaten konsistent zu interpretieren.
Eine Schema-ID ist ein Bezeichner für eine bestimmte Schemadefinition. Eine Schemaversion gibt an, wo das jeweilige Schema in der Reihenfolge der für ein bestimmtes Schema oder Thema geführten Versionen erscheint. Die genaue Implementierung variiert je nach Register. In Confluent Schema Registry beispielsweise identifiziert eine Schema-ID das Schema in dem Register eindeutig, während die Version zu einem Subjekt gehört. Dasselbe Schema kann daher dieselbe Schema-ID haben, obwohl es unter verschiedenen Themen mit unterschiedlichen Versionen verknüpft ist.
Ein Schema-Register speichert und verwaltet in erster Linie maschinenlesbare Schemata, die von Anwendungen verwendet werden, um die Struktur von Daten zu verstehen. Es kann auch Funktionen wie Schemaversionierung und Kompatibilitätsprüfungen bereitstellen.
Ein Datenkatalog konzentriert sich breiter darauf, Menschen und Systemen dabei zu helfen, Assets in einer Unternehmen zu entdecken, zu verstehen und zu steuern. Ein Katalog kann Geschäftsbeschreibungen, Eigentumsinformationen, Klassifikationen und andere Metadaten zu Datensätzen und Datensystemen enthalten. Schema-Register und Datenkataloge können sich daher ergänzen. Das Register verwaltet die von Anwendungen verwendeten Schemata, während der Katalog umfassendere Informationen über die Datenressourcen der Organisation liefert.
Ein Schema definiert die Struktur der Daten, einschließlich Elemente wie Felder und Datentypen. Ein Datenvertrag kann das Schema enthalten, aber auch breitere Erwartungen zwischen Datenproduzenten und Konsumenten definieren. Ein Schema könnte neben Integritätsbedingungen, Metadaten und Richtlinien eine Komponente eines Datenvertrags sein.
Das richtige Schema-Register hängt von den technischen Anforderungen eines Unternehmens und der bestehenden Datenarchitektur ab. Zu berücksichtigende Faktoren gehören die Schemaformate, die das Register unterstützt, seine Kompatibilitätsregeln, Integration in Apache Kafka und anderen Datensystemen, API- und Client-Unterstützung, Sicherheits- und Authentifizierungsfähigkeiten sowie ob der Dienst verwaltet oder selbstverwaltet ist.
Unternehmen könnten auch berücksichtigen, wie das Register die Entwicklung von Schemata, Data-Governance, Metadaten und Datenverträgen unterstützt sowie seine Kompatibilität mit bestehenden Produzenten, Verbrauchern und Datenpipelines. Verschiedene Register-Produkte bieten unterschiedliche Kombinationen dieser Funktionen, daher hängt die Auswahl im Allgemeinen von den Systemen und Anforderungen ab, die das Register unterstützen muss.