如果字段顺序更改，Avro 模式不兼容

Posted 2023-03-08

【中文标题】如果字段顺序更改，Avro 模式不兼容

【英文标题】：Avro schemas not compatible if field order changes

【发布时间】：2018-02-01 19:44:09

【问题描述】：

场景 - 客户端使用 Avro Reflect Datum Writer 序列化 POJO，并将 GenericRecord 写入文件。 通过反射得到的schema是这样的（注意顺序A、B、D、C）——

"namespace": "storage.management.example.schema",

"type": "record",
"doc": "Example schema for testing",
"name": "Event",
"fields": [
     ....
     ....
     "name": "A", "type":  "string"  ,
     "name": "B", "type":  "string"  ,
     "name": "D", "type": "string" ,
     "name": "C", "type":  "string"  ,
     ....
     ....
]
 

代理读取文件并使用默认模式（注意排序 - A、B、C、D）来反序列化记录的子集（保证客户端具有这些字段）

"namespace": "storage.management.example.schema",
"type": "record",
"doc": "Example schema for testing",
"name": "Event",
"fields": [
     "name": "A", "type":  "string"  ,
     "name": "B", "type":  "string"  ,
     "name": "C", "type": "string" ,
     "name": "D", "type":  "string"  
]

问题： 使用上述子集模式进行反序列化会导致以下异常 -

Caused by: java.io.IOException: Invalid int encoding
at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:145)
at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259)
at org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201)
at org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:430)
at org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:422)
at org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:180)
at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:152)
at org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:240)
at org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:230)

但是，如果子模式还按 A、B、D、C 的顺序指定字段，则反序列化成功。（与客户端模式相同）

这是预期的行为吗？我虽然 Avro 只依赖于字段名称来构建记录而不是排序。

对此有任何修复吗？不同的客户端可能有不同的顺序，我无法强制执行顺序，因为架构是通过反射生成的。

【问题讨论】：

您使用的是 BinaryDecoder 吗？如果是这样，请尝试使用 DataFileReader。 import org.apache.avro.file.DataFileReader

【参考方案1】：

这是预期的行为吗？

文档说“A record is encoded by encoding the values of its fields in the order that they are declared.”

所以，我认为这是正确的行为。

【参考方案2】：

这不一定是预期的行为。当我开始使用 Avro 时，您可能会犯同样的错误。

Avro 能够拥有不同版本的模式（例如，用一个写入但读入另一个）但很容易错过的一件事（至少我自己）是您必须具有编写消息的确切模式尝试阅读时。

您阅读的有关 Avro 的文档和信息，至少在表面上，并没有说得很清楚。通常他们专注于“向后兼容”。公平地说，从某种意义上说，但通常当人们看到这个短语时，他们认为它的意思有点不同。通常我们认为这意味着您可以使用新架构处理旧消息，而不是使用新架构和旧消息架构处理旧消息。

作为一个例子，看看这个伪代码

Schema myUnsortedSchema has C B A order
Schema myAlphabeticalSchema has A B C order

Writer writer uses myUnsortedSchema
Reader badReader uses myAlphabeticalSchema only

writer writes message
badReader reads message

错误！不确定错误消息到底会说什么，但问题是badReader 不仅尝试读入myAlphabeticalSchema，而且还读取消息，就好像它是由myAlphabeticalSchema 编写的一样。解决方案是有一种方法可以同时提供两种模式，一种是编写消息的模式，另一种是要读取的模式（如何取决于语言）。

Reader goodReader reads messages written with myUnsortedSchema into myAlphabeticalSchema

goodReader reads message

没有错误！这是正确的用法。

如果您使用goodReader 之类的方法，则此行为是意外的，但如果您使用badReader 之类的方法，则此行为是预期的。

---

像 Schema Registry 这样的一些服务通过将一些元数据附加到消息字节的前面来帮助解决这个问题，以确定哪个模式编写了消息（当然，在阅读之前将它们剥离）。它超出了问题的范围，但可以帮助解决此类问题。

【参考方案3】：

字段的顺序可能不同：字段按名称匹配。 https://avro.apache.org/docs/1.8.1/spec.html ....在您的第一个架构中，还有其他字段您没有显示