官网地址 : http://avro.apache.org/
GitHub：https://github.com/apache/avro/
Avro是一个数据序列化系统。提供了以下功能和特性：
- 丰富的数据结构
- 一个紧凑的，生成速度快速的二进制数据格式
- 一个容器文件，用于存储持久化数据
- 远程过程调用(RPC)
- 与动态语言的简单集成。读取或写入数据文件不需要代码生成，也不需要使用或实现RPC协议。代码生成作为一种可选的优化，只是为静态类型语言的集成而实现。
Avro在序列化时依赖模式文件(schema)，当Avro读取数据和写入数据时，都需要提供模式文件。这样Avro就可以预先知道数据的类型，不用对数据进行预先检测而可以写入每个数据，从而使序列化既快又小。由于数据及其模式是完全自描述的，因此这也便于使用动态脚本语言。
当Avro数据存储在文件中时，对应的模式文件也会随之存储，因此以后任何程序都可以处理该数据文件。如果读取数据的程序期望使用其他模式，则由于这两种模式文件的存在，因此可以轻松解决。
在Avro用于RPC时，RPC的客户端和服务端会在建立握手连接时交换模式文件(可以对其进行优化，因为对于大多数远程调用而言，实际上不需要传输任何模式文件)。建立连接后，由于客户端和服务器都拥有对方的完整模式，因此可以轻松解决相同命名字段，缺失字段，多余字段等之间的对应关系。
Avro模式是使用JSON定义的 。这有助于以已经具有JSON库的语言实现。
Avro提供的功能类似于Thrift， Protocol Buffer等系统。Avro在以下基本方面与这些系统不同。
- 动态类型：Avro不需要生成代码。数据始终伴随着一个schema，该schema允许对数据进行全面处理而无需代码生成，静态数据类型等。这有助于构建通用数据处理系统和语言。
- 未标记的数据：由于在读取数据时存在schema，因此需要用数据编码的类型信息少得多，因些序列化的内容相对比较小。
- 没有手动分配的字段ID：当模式更改时，在处理数据时，旧模式和新模式都始终存在，因此可以使用字段名称以符号方式解决差异。
补充：之所以Hadoop的创始人Doug Cutting会在已有许多现成的RPC系统的情况下，再开发Avro，个人认为原因主要如下：
- 现有的RPC系统在数据序列时必须要先生成数据的定义原件，然后再根据定义文件生成相应的代码，显得不够灵活。
- 现有的RPC系统都不是为大数据应用场景而设计的，在远程传输海量数据时的性能不能让人满意，而Avro在设计时就采用了一些例如列式存储这样的优化手段。
- 重新设计一套RPC系统，更利于与Hadoop生态圈各类框架的集成