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

lon*_*uro 3 avro apache-kafka apache-kafka-connect confluent-schema-registry

我们正在编写一个自定义接收器连接器,用于将带有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

Ran*_*uch 7

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

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

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