当使用Java并在使用者中进行深度复制以将GenericRecord类解析为从AVRO模式生成的特定类时,我目前正在研究针对特定的AVRO模式演变方案的意外行为的解决方案。
为了解释正在发生的事情,我将使用一个简化的模式示例:
{
"name":"SimpleEvent",
"type":"record",
"namespace":"com.simple.schemas",
"fields":[
{
"name":"firstfield",
"type":"string",
"default":""
},
{
"name":"secondfield",
"type":"string",
"default":""
},
{
"name":"thirdfield",
"type":"string",
"default":""
}
]
}
这只是具有三个字符串字段的简单架构,所有字段均为可选,因为它们具有默认值。假设在某个时候我想添加另一个字符串字段,并删除一个字段,因为不再需要它,结果就是这样:
{
"name":"SimpleEvent",
"type":"record",
"namespace":"com.simple.schemas",
"fields":[
{
"name":"firstfield",
"type":"string",
"default":""
},
{
"name":"secondfield",
"type":"string",
"default":""
},
{
"name":"newfield",
"type":"string",
"default":""
}
]
}
这不应根据架构演变规则破坏更改。但是,当生产者开始使用较新的架构生成事件时,下游的消费者就会发生奇怪的事情。
结果证明生成的Java类(我使用Gradle avro插件生成了该类,但是maven插件和avro工具命令行代码生成产生相同的输出)仅查看字段顺序,而不要不会根据字段名称映射字段。
这意味着字段“ newfield”的值被使用旧版本架构读取数据的下游使用者映射到“ thirdfield”。
我发现了一些根据名称执行manual mapping的工作,但是,这不适用于嵌套对象。
通过一些本地实验,我还发现了另一种确实可以解决架构差异的方法:
Schema readerSchema = SimpleEvent.getClassSchema();
Schema writerSchema = request.getSchema();
if (readerSchema.equals(writerSchema)){
return (SimpleEvent)SpecificData.get().deepCopy(writerSchema, request);
}
DatumWriter<GenericRecord> writer = new SpecificDatumWriter<>(writerSchema);
BinaryEncoder encoder = null;
ByteArrayOutputStream stream = new ByteArrayOutputStream();
encoder = EncoderFactory.get().binaryEncoder(stream, encoder);
writer.write(request, encoder);
encoder.flush();
byte[] recordBytes = stream.toByteArray();
Decoder decoder = DecoderFactory.get().binaryDecoder(recordBytes, null);
SpecificDatumReader<SimpleEvent> specificDatumReader = new SpecificDatumReader(writerSchema, readerSchema);
SimpleEvent result = specificDatumReader.read(null, decoder);
return result;
但是,这似乎是一种相当浪费/模糊的方法,因为您首先必须将GenericRecord转换为byteArray,然后使用SpecificDatumReader再次读取它。
Deepcopy类与datumreader类之间的区别在于,datumReader类似乎适用于编写器架构与读取器架构不同的方案。
我认为应该/可以有一种更好,更优雅的方式来处理此问题。我真的很感谢到达那里的任何帮助/提示。
预先感谢:)
奥斯卡
答案 0 :(得分:0)
在进一步挖掘并查看了我们先前在侦听器中使用的KafkaAvroDeserializer之后,我注意到AbstractKafkaAvroDeserializer具有反序列化可以在阅读器模式中传递的位置的功能。看起来不错,但确实有效!
package com.oskar.generic.consumer.demo;
import com.simple.schemas;
import io.confluent.kafka.serializers.AbstractKafkaAvroDeserializer;
import io.confluent.kafka.serializers.KafkaAvroDeserializerConfig;
import org.apache.kafka.common.serialization.Deserializer;
import java.util.Map;
public class SimpleEventDeserializer extends AbstractKafkaAvroDeserializer implements Deserializer<Object> {
private boolean isKey;
@Override
public void configure(Map<String, ?> configs, boolean isKey) {
this.isKey = isKey;
configure(new KafkaAvroDeserializerConfig(configs));
}
@Override
public Object deserialize(String s, byte[] bytes) {
return super.deserialize(bytes, SimpleEvent.getClassSchema());
}
@Override
public void close() {
}
}
然后将其用于消费工厂,如下所示:
@Bean
public ConsumerFactory<String, GenericRecord> consumerFactory() {
Map<String, Object> props = new HashMap<>();
props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:29095");
props.put(AbstractKafkaAvroSerDeConfig.SCHEMA_REGISTRY_URL_CONFIG, "http://localhost:8081");
props.put(ConsumerConfig.GROUP_ID_CONFIG, "one");
props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, SimpleEventDeserializer.class);
return new DefaultKafkaConsumerFactory<>(props);
}
监听器代码本身如下所示:
@KafkaListener(topics = "my-topic")
public GenericRecord listen(@Payload GenericRecord request, @Headers MessageHeaders headers) throws IOException {
SimpleEvent event = (SimpleEvent) SpecificData.get().deepCopy(request.getSchema(), request);
return request;
}