Was sind die Gründe für Kafka Connect Schemas?

Question

Wir schreiben einen benutzerdefinierten Sink-Connector zum Schreiben von Inhalt eines Themas mit Avro-Nachrichten in einen CEPH-Speicher.

Um dies zu tun, wir mit SinkRecords versehen sind, die ein Kafka Connect-Schema hat, die eine zugeordnete Version unseres Avro-Schemas ist. Da wir Avro in CEPH schreiben wollen, verwenden wir die Connect-API-Methoden, um das Connect-Schema zurück in Avro zu konvertieren. Warum müssen wir das tun? Was sind die Vorteile der Einführung von Kafka Connect Schema und nicht die Verwendung des häufiger angepassten Avro Schemas?

FYI: Ich frage das, weil wir einige Probleme mit Avro Gewerkschaften haben. Ihre Zuordnungen zu dem Kafka-Connect-Schema haben immer noch einige Probleme, z.B. https://github.com/confluentinc/schema-registry/commit/31648f0d34b10c1b36e8ec6f4c1236ed3fe86495#diff-0a8d4f17f8d4a68f2f0d2dcd9211df84

Answer 1

Kafka Connect definiert seine eigene Schemastruktur, da das Framework die Verbindung von jedem Wissen über die Serialisierung der Nachrichten in Kafka isoliert. Dies ermöglicht die Verwendung eines beliebigen Konnektors mit jedem Konnektor. Ohne diese Trennung würden Connectors erwarten, dass die Nachrichten in einer bestimmten Form serialisiert werden, was eine Wiederverwendung erschwert.

Wenn Sie wissen, dass alle Nachrichten mit einem bestimmten Avro-Schema serialisiert werden, können Sie Ihren Sink-Connector immer so konfigurieren, dass der Schlüssel ByteArrayConverter für Schlüssel und Werte verwendet wird und Ihr Connector die Nachrichten in serialisierter Form verarbeiten kann. Beachten Sie jedoch, dass bei der Serialisierung der Nachrichten mit Confluents Avro Serializer (oder Avro Converter in einem Quell-Connector) die Binärform der Schlüssel und Werte das magische Byte und die Avro-Schema-ID im führenden Byte enthält (s). Der verbleibende Inhalt der Byte-Arrays ist das Avro-Serialisierungsformular.