Event-Sourcing-Schema auf Kafka erzwingen

Question

Um klar zu sein, ich versuche nicht, Kafka als Datenspeicher für Event-Sourcing zu verwenden, nur um Ereignisse zu replizieren.

Die Confluent Schema Registry für Kafka scheint sehr interessant, da sie das Schema für Nachrichten von Herstellern zu einem Thema validieren kann. Nach meinem Verständnis behandelt es jedes Thema wie eine Containerdatei - ein Schema pro Thema.

Diese Einschränkung funktioniert nicht für eine Ereignisquelle Strom, wo für ein einzelnes Aggregat wie File Sie mehrere Nachrichtenschemata haben: FileCreated, FileMoved, FileCopied, FileDeleted. Jedes dieser Themen in einem separaten Thema zu behandeln, wäre kompliziert und fehleranfällig.

Gibt es ein Tool wie Schema Registry, das mehrere Schemas für dasselbe Thema unterstützt?

aktualisieren

zu klären, jede der Nachrichten oben würde ein anderes Schema. Zum Beispiel:

FileCreated:

{ 
    type: "record", 
    name: "FileCreated", 
    fields: [ 
    { name: "id", type: "string" }, 
    { name: "name", type: "string" }, 
    { name: "path", type: "string" }, 
    { name: "size", type: "string" }, 
    { name: "mimeType", type": "string" }, 
    { name: "user", type: "string" }, 
    { name: "date", type: "long" } 
    ] 
} 

FileMoved:

{ 
    type: "record", 
    name: "FileMoved", 
    fields: [ 
    { name: "id", type: "string" }, 
    { name: "from", type: "string" }, 
    { name: "to", type: "string" }, 
    { name: "date", type: "long" }, 
    { naem: "user", type: "string" } 
    ] 
} 

FileDeleted:

{ 
    type: "record", 
    name: "FileDeleted", 
    fields: [ 
    { name: "id", type: "string" }, 
    { name: "date", type: "long" }, 
    { name: "user", type: "string" } 
    ] 
} 

Answer 1

Confluent Schema Registry in der Tat unterstützen mehrere Schemata für das gleiche Thema.

Die empfohlene Vorgehensweise besteht darin, das gleiche Thema nicht für unterschiedliche Datentypen zu verwenden. Beispielsweise sollten Sie normalerweise keine Seitenaufrufereignisse und Benutzerprofilaktualisierungen in dasselbe Thema schreiben.

Ein häufiges Beispiel für die Verwendung mehrerer Schemas für das gleiche Thema ist die Ermöglichung der Schemaevolution, z. Beginnen Sie mit einem Basisschema für Benutzerprofile (z. B. nur Benutzername und Alter), das anschließend zu einem vollständigeren Schema für Benutzerprofile erweitert wird (Benutzername, Alter, Geo-Region, bevorzugte Sprache, Datum des letzten Besuchs,. ..).

Ob Sie wollen FileMovedFileCreated, speichern, FileCopied, FileDeleted in demselben Thema ist bis zu Ihnen. In beiden Fällen können Sie mit der Konfluenten-Schema-Registrierung die entsprechenden Schemas verwalten (see docs).

Speziellere docs Zeiger:

• Register a new schema. Um neue/mehrere Schemata unter demselben Thema zu registrieren, müssen Sie sie einfach über den entsprechenden API-Aufruf registrieren. Beachten Sie, dass das Registrieren eines neuen Schemas (d. H. Wenn ein initiales Schema bereits bei einem Subjekt registriert war) in Abhängigkeit von Avro-Kompatibilitätseinstellungen fehlschlagen kann, siehe nächsten Punkt.
• (global oder für Schemas, die für dasselbe Thema/Thema registriert sind) Siehe z.B. GET /config/(string: subject), die das Kompatibilitätsniveau (Avro-Schema) für ein Subjekt zurückgibt.

Zitiert:

Ein Schema soll (wenn es welche gibt) gemäß dem konfigurierten Kompatibilitätsgrad mit den zuvor registrierten Schemata kompatibel sein. Der konfigurierte Kompatibilitätsgrad kann durch Ausgabe einer GET /config/(string: subject) erreicht werden. Wenn das null zurückgibt, dann GET /config.

Auch valid (Avro schema) compatibility settings sind: NONE, FULL, FORWARD, BACKWARD. Wenn Sie beispielsweise völlig unterschiedliche Datentypen im selben Kafka-Thema speichern möchten, sollten Sie (a) die Avro-Schema-Kompatibilität für das entsprechende Thema/Thema auf NONE setzen und (b) die relevanten Avro-Schemata registrieren. für jeden Datentyp unter diesem Thema/Thema.