1.不断发展的模式
假设您最初为Employee类设计了一个如下所示的模式

{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"},
{"name":"age", "type":"int"}
}

后来你意识到年龄是多余的，并将其从模式中删除。

{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"}
}

在此架构更改之前序列化和存储的记录如何处理？如何读回这些记录？
这就是为什么avro reader/deserializer要求读取器和写入器模式。它在内部进行模式解析，也就是说，它试图将旧模式适应新模式。
转到此链接-http://avro.apache.org/docs/1.7.2/api/java/org/apache/avro/io/parsing/doc-files/parsing.html-“使用操作符号解决问题”部分
在这种情况下，它确实跳过操作，即它省略了阅读“年龄”。它还可以处理像字段从int变为long等情况。
这是一篇很好的文章，解释了模式的演变-http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
1.对于单个文件中的多个记录，架构仅存储一次。
1.大小，以非常少的字节编码。

我认为模式进化所解决的一个关键问题在任何地方都没有明确提到，这就是为什么它会给新来者带来如此多的困惑。
下面的例子可以说明这一点：
假设一家银行存储了其所有交易的审计日志。这些日志具有特定的格式，需要存储至少10年。保存这些日志的系统应该适应这10年来不断变化的格式，这也是非常可取的。
这些条目的模式不会经常更改，比如说平均一年更改两次，但是每个模式都有大量的条目。如果我们不跟踪这些模式，那么过一段时间，我们将需要参考非常旧的代码来找出当时存在的字段，并继续添加if-else语句来处理不同的格式。有了所有这些格式的模式存储，我们可以使用模式演化功能将一种格式自动转换为另一种格式（如果你提供的是旧的和新的模式，Avro会自动完成这一点）。这使得应用程序不必在代码中添加大量的if-else语句，也使它更易于管理，因为我们可以通过查看存储的模式集来了解我们拥有的所有格式（模式通常存储在单独的存储中，数据只有一个指向其模式的ID）。
架构演化的另一个优点是，新格式的生成者可以安全地生成具有新架构的对象，而无需等待下游使用者先进行更改。下游使用者可以具有内置逻辑，以便仅挂起处理，除非他们能够看到与新格式关联的新架构。这种自动挂起对于保持系统联机并使处理逻辑适应新架构非常有用。
总之，模式演进通过使用自动格式转换帮助较新的客户端读取较旧的格式，并且还帮助较旧的客户端以适当的方式暂停处理，直到它们能够理解较新的格式。

从模式演化的Angular 来看，拥有模式是一件好事，但在JSON中并不是不能做到这一点。
Avro的主要特点是它是二进制的。所以让我们假设，你的记录是：

{
  {"name": "emp_name", "type":"string"},
  {"name":"dob", "type":"string"},
  {"name":"age", "type":"int"}
}

Avro将上述数据部分存储为：《约翰福音》1990年10月20日32页
这里有一种标记来区分字段值。
因此，如果没有模式，上面的数据就毫无用处！如果没有模式，您就不知道这些值的含义。
这就是二进制格式和非二进制格式的区别。二进制格式只有值，这使得它们非常紧凑。JSON和XML等文本格式的模式会反复重复，因此它们比二进制格式大两倍多。
另一个比较：二进制格式的整数只需要32位，但JSON格式的整数是以文本格式存储的数字。

{"some_number": 43847384}

JSON中的上述数字不是像JSON中的32位整数那样存储的，它是纯文本，占用8个字符 * 8位= 64位，甚至更多，这取决于数字的长度。
所以JSON中的schema不是可选的。如果你必须使用二进制格式，它是必须的。