Confluent Plattform: Schema Registry Themen

Question

Arbeiten mit Confluent Plattform, die Plattform von den Machern von Apache Kafka angeboten, und ich habe eine Frage:

In der Dokumentation der Schema Registry API Reference, erwähnen sie die Abstraktion eines „Subject“ . Sie registrieren ein Schema unter einem "Betreff" in der Form topicName-Schlüssel oder topicName-Wert, aber es gibt keine Erklärung dafür, warum Sie (separate Schema für den Schlüssel benötigen) und Wert von Nachrichten zu einem bestimmten Thema. Es gibt auch keine direkte Aussage dahingehend, dass die Registrierung bei einem "Subjekt" das Schema notwendigerweise mit diesem Thema assoziiert, außer mnemonisch.

Weitere verwirrende Dinge, die nachfolgenden Beispiele auf dieser Seite nicht Gebrauch (und „Register, um neues Schema unter Betreff“ „Schema-Version für ein Objekt erhalten“), das Format für das Thema Namen und stattdessen nur ein Thema Namen verwenden für den "Subjekt" -Wert. Wenn jemand einen Einblick in a), warum gibt es diese zwei "Themen" pro Thema, und b) was die ordnungsgemäße Verwendung ist, würde es sehr geschätzt.

Answer 1

Confluent Schema Registry ist eigentlich ein bisschen im Widerspruch mit dem Betreff Namen :)

der Tat die KafkaAvroSerializer (für neuen Kafka 0.8.2 Produzenten) verwendet topic-key|value Muster für Probanden (link), während KafkaAvroEncoder (für alten Produzenten) verwendet schema.getName()-value Muster (link).

Der Grund, warum man zwei verschiedene Themen pro Thema (einen für Schlüssel, einen für Wert) ist ziemlich einfach haben würde:

sagen, ich habe ein Avro Schema darstellt einen Protokolleintrag, und jeder Protokolleintrag hat eine Source Informationen zu ihm angebracht:

{ 
    "type":"record", 
    "name":"LogEntry", 
    "fields":[ 
     { 
     "name":"line", 
     "type":"string" 
     }, 
     { 
     "name":"source", 
     "type":{ 
      "type":"record", 
      "name":"SourceInfo", 
      "fields":[ 
       { 
        "name":"host", 
        "type":"string" 
       }, 
       { 
        "name":"...", 
        "type":"string" 
       } 
      ] 
     } 
     } 
    ] 
} 

Ein häufigen Anwendungsfall wäre, dass ich Einträge von Quelle partitionieren möge, möchte daher zwei Themen für Thema (und Themen sind im Grunde Revisionen der Avro-Schemata) zugeordnet haben - eine für Schlüssel (das ist SourceInfo) und eins für Wert (LogEntry).

Mit diesen beiden Themen würde die Daten partitionieren und speichern, solange ich eine Schema-Registrierung läuft und meine Produzenten/Verbraucher mit ihm sprechen können. Alle Änderungen an diesen Schemas würden sich in der Schemaregistrierung widerspiegeln, und solange sie die Kompatibilitätseinstellungen erfüllen, sollte alles einfach serialisiert/deserialisiert werden, ohne dass Sie sich darum kümmern müssen.

Hinweis: alle weiteren Informationen sind nur meine persönlichen Gedanken und vielleicht nur ich noch nicht vollständig verstehen, wie das funktionieren soll, so könnte ich falsch sein.

Ich mag eigentlich mehr, wie die KafkaAvroEncoder implementiert ist, anstatt die KafkaAvroSerializer. erzwingt in keiner Weise die Verwendung eines Schemas pro Thema key \ value, während KafkaAvroSerializer dies tut. Dies kann ein Problem sein, wenn Sie planen, Daten für mehrere Avro-Schemas in einem Thema zu erstellen. In diesem Fall würde KafkaAvroSerializer versuchen, die topic-key und topic-value Themen zu aktualisieren und 99% würde brechen, wenn die Kompatibilität verletzt wird (und wenn Sie mehrere Avro-Schemas haben, sind sie fast immer unterschiedlich und inkompatibel miteinander).

Auf der anderen Seite kümmert sich KafkaAvroEncoder nur um Schemanamen und Sie können sicher Daten für mehrere Avro Schemas in einem Thema produzieren und alles sollte gut funktionieren (Sie werden so viele Themen wie Schemas haben).

Diese Inkonsistenz ist mir immer noch unklar und ich hoffe, dass konfluierende Leute das erklären können, wenn sie diese Frage/Antwort sehen.

Hoffnung, die Sie