Kafka Connect Schemas背后的原因是什么？

Question

我们正在编写一个自定义接收器连接器，用于将带有avro消息的主题内容写入CEPH存储。

为此，我们提供了SinkRecords，它具有Kafka Connect架构，它是我们的avro架构的映射版本。 由于我们要将avro写入CEPH，因此我们使用connect API方法将Connect架构转换回Avro。 为什么我们需要这样做？ 引入Kafka Connect Schema而不使用更常用的Avro Schema有什么好处？

仅供参考：我问这个是因为我们与Avro工会有一些问题。 他们与Kafka Connect Schema的映射仍存在一些问题，例如https://github.com/confluentinc/schema-registry/commit/31648f0d34b10c1b36e8ec6f4c1236ed3fe86495#diff-0a8d4f17f8d4a68f2f0d2dcd9211df84

Answer 1

Kafka Connect定义了自己的模式结构，因为该框架将连接器与Kafka中消息序列化的任何知识隔离开来。 这使得任何转换器都可以使用任何连接器。 如果没有这种分离，那么连接器会期望消息以特定形式被序列化，使得它们更难以重用。

如果您知道所有消息都使用特定的Avro架构进行序列化，则始终可以将接收器连接器配置为使用ByteArrayConverter来获取键和值，然后您的连接器可以处理序列化形式的消息。

但是，请注意，如果使用Confluents Avro序列化程序（或源连接器中的Avro Converter）序列化消息，则键和值的二进制形式将在前导字节中包含魔术字节和Avro架构标识符。 字节数组的剩余内容将是Avro序列化形式。