1 大数据数据格式
1.1 种类
graph TD
A[Big data] --> B[.csv]
A --> C[.json]
A --> D[Parquet]
A --> E[Orc]
A --> F[Avro]
A --> G[Thrift]
A --> H[Proto buffer]
1.2 csv
CSV文件（逗号分割不同列的值）常被使用普通文本格式的系统用作交换它们的表格数据。CSV是基于行的文件格式，这意味着文件中的每行数据都对应于表格的一行。总的来说，CSV包含一个头部行，它为数据提供列的名称。不然的话，这些文件会被认为是半结构化。起初，CSV文件不能表示层级或关系型数据。数据之间的关联基本是通过多个CSV文件来实现。一个或多个文件中都会在列中存储外键，但是CSV格式本身并不能表达这些文件之间的关系。而且，CSV格式并没有完全标准化，可以使用除逗号之外的其他分隔符，比如制表符和空格。
优点：
- CSV易于人们理解和手动编辑；
- CSV提供了简单易懂的信息格式；
- 几乎所有现存的系统都可以处理CSV；
- CSV易于实现和解析；
- CSV格式紧凑。在XML中，每行数据的每列都需要开始和结束标签。在CSV中你只需要写一次列头信息。
缺点：
- CSV只能处理扁平化的数据。复杂的数据结构需要额外处理；
- 不支持设置列的数据类型。文本类型的列和数字类型的没有任何区别；
- 没有标准方式表示二进制数据；
- CSV的导入问题（不区分NULL和“null”引用）（译者语：CSV空列在导入时会变成字符串“null”）
- 对特殊字符的支持很差
- 缺少标准
1.3 JSON
Json数据（JavaScript object notation，即JavaScript对象符号）在一个部分结构化的格式中被表示成一系列键值对。因为可以以层级格式存储数据，所以JSON常被和XML做对比。孩子数据由双亲数据负责呈现。两种格式都是自描述的，并且方便用户阅读理解，但是通常情况下JSON文档会小很多。因此，它们被越来越多的用于网络通讯，特别是伴随着基于REST网络服务的出现。
因为已经有很多数据传输在使用JSON格式，所以大多数网络语言一开始就支持JSON数据的序列化和反序列化，也有些语言是通过外部工具库来实现。因为有这样的支持，JSON被用于展示数据结构的逻辑格式，交换热数据，和存储冷数据。
很多批量和流式数据处理模块天然支持JSON的序列化和反序列化。尽管JSON文档包含的数据最终被存储在性能更优的格式中，比如Parquet或Avro。但是JSON可以作为原始数据的格式，这在重新处理数据（如果有需要）时非常重要。
优点
- JSON支持层级结构，简化了在一个文档中存储关联数据和展示复杂关系的难度；
- 大多数语言提供了简化JSON序列化的工具库，或内建支持JSON序列化/反序列化；
- JSON支持对象列表，帮助避免列表转换成关系型数据模型时的不确定性；
- JSON是一种被NoSQL数据库广泛使用的文件格式，比如MongoDB，Couchbase和Azure Cosmos DB；
- 目前大部分工具都内置支持JSON。
1.3 Parquet
Parquet于2013年面世，由Cloudera和Twitter开发，用来作为列存储的格式，对多列数据集做了优化。由于数据是按列储存，所以它可以被高度压缩（压缩算法在低信息熵的数据中表现更好，而列数据通常正是如此）而且具有良好的可拆分性。该格式的开发者声称这种存储格式是解决大数据问题的理想方案。
不像CSV和JSON，Parquet文件是二进制文件，包含描述内容的元数据。所以，不需要读取/解析文件内容，Spark仅仅依赖元数据就可以确定列的名称、压缩/编码信息、数据类型甚至一些基本的统计数据。Parquet文件列的元数据存储在文件的尾部，这样允许快速的、一次性写入。
Parquet针对“一次写入，多次读取(WORM)”特性做了优化。它写入慢，但是读取特别快，特别当你只访问全部列的一部分时。有大量读取工作时，Parquet是个好选择。对于需要对整行数据处理的场景，你需要使用类似CSV或者AVRO格式。
优点：
- Parquet是列式格式。只有被需要的列会被获取/读取，降低了磁盘I/O。这个概念被称为投影下推（译者语：原文projection pushdown）；
- Schema和数据在一起，所以数据是自描述的；
- 尽管它最初是为HDFS创建的，但是数据也可以存放在其他文件系统中，比如GlusterFs或者NFS；
- Parquet只是一些文件，这意味着很容易移动、备份和复制它；
- 在Spark中原生支持，开箱即用，能够很简单的获取和存储文件到你的存储中；
- Parquet提供优异的压缩功能，当使用类似snappy压缩格式时，压缩比高达75%；
- 实践表明，和其他文件格式相比，该格式读取速度最快；
- Parquet非常适合要对海量数据的特定列做汇总的数据仓库；
- 可以使用Avro API和Avro Schema读取和写入Parquet（这允许使用Avro格式存储原始数据，但是使用Parquet处理数据）；
- 它也支持谓词下推（译者语：原文是predicate pushdown），因此可以进一步降低磁盘I/O开销。
1.4 Avro
Apache Avro是由Hadoop工作组于2009年发布。它是基于行的格式，并且具备高度的可分拆性。它也被描述为一个类似Java序列化的数据序列化系统。它的schema存储在JSON格式中，但是数据以二进制方式存储，以求文件尺寸最小同时效率最高。通过管理新增字段、缺失字段和被修改的字段，Arvo为schema进化提供了强大的支持。这允许老系统读取新的数据，也允许新系统读取老数据--如果你的数据可能会更改，这会是非常重要的特性。
借助Avro管理schema进化的能力，我们可以在不同时间独立地更新各个组件，并且不兼容的风险很低。这让应用避免使用if-else语句处理不同的schema版本，也让开发者避免查看老代码来理解老的schema。因为所有版本的schema都存储在易于人们阅读理解的JSON头部，所以你很容易理解所拥有的全部字段。
很多不同语言都支持Avro。因为schema存储在JSON中，但是数据存储为二进制，所以Avro在持久化数据存储和数据传输中都是相当紧凑的方案。Avro是写入很多场景的首选方案，因为它可以很容易在尾部添加新行。
优点：
Avro是语言中立的数据序列化方案；
Avro在文件头部存储schema，所以数据是自描述的；
Avro格式的文件既可拆分又可压缩，因此是Hadoop生态系统中文件存储的好选择；
读Avro文件使用得schema不用和写文件所用的schema一样。这使得我们可以独立的添加新字段；
和Sequence Files（译者语：一种Hadoop的文件格式）一样，Avro文件也包含用来分隔块的Sync标识符。这使得它有高度可分拆性；
这些块可以使用类似snappy这样的压缩格式压缩。
1.5 Orc
Orc也是一个列式存储格式，产生自Apache Hive，用于降低Hadoop数据存储空间和加速Hive查询速度。
和Parquet的设计类似，也是将行分成多个组，然后组内按列存储，之后再对列进行分割。orc 的 Stripe 对应parquet的 Row Group，row Group 对应的是 parquet的 page
ORC文件是自描述的，它的元数据使用Protocol Buffers序列化
除了基本类型以外，还支持更复杂的数据结构，如LIST、STRUCT、MAP和UNION类型
1.6 Thrift
对于需求为高性能，分布式的 RPC 服务，Thrift 支持众多语言和丰富的数据类型，并对于数据字段的增删具有较强的兼容性，所以非常适合公司内部 SOA 的标准 RPC 框架
Thrift提供了完整的RPC支持，包含了Server/Client，而Protobuf只包括了stub的生成器和格式定义。
1.7 Protobuf
google 开源的一个项目，主要用于数据存储、传输协议格式等场合。也是一个二进制协议，主要用来序列化。
Protobuf 具有广泛的用户基础，空间开销小一级高解析性是其亮点，非常适合于公司内部的对性能要求高的 RPC 调用。Protobuf 提供了标准的 IDL 以及对应编译器，其 IDL 文件是参与各方的非常强的业务约束，另外，Protobuf 与传输层无关，采用 Http 具有良好的跨防火墙的访问属性。由于其解析性能好，序列化后数据量相对少，非常适合应用层对象的持久化场景。
1.需要和其它系统做消息交换的，对消息大小很敏感的。那么protobuf适合了，它语言无关，消息空间相对xml和json等节省很多。
2.小数据的场合。如果你是大数据，用它并不适合。
总体而言，protobuf还是非常好用的，被很多开源系统用于数据通信的工具，在google也是核心的基础库。
2 parquet数据格式
- 列式存储优点
把IO只给查询需要用到的数据，只加载需要被计算的列
列式的压缩效果更好，节省空间 - Parquet适配多种计算框架
Parquet是语言无关的，而且不与任何一种数据处理框架绑定在一起，适配多种语言和组件，能够与Parquet配合的组件有：
查询引擎: Hive, Impala, Pig, Presto, Drill, Tajo, HAWQ, IBM Big SQL
计算框架: MapReduce, Spark, Cascading, Crunch, Scalding, Kite
数据模型: Avro, Thrift, Protocol Buffers, POJOs
2.1 存储格式(storage format)
parquet-format项目定义了Parquet内部的数据类型、存储格式等。
2.2 对象模型转换器(object model converters)
这部分功能由parquet-mr项目来实现，主要完成外部对象模型与Parquet内部数据类型的映射。
2.3 对象模型(object models)
对象模型可以简单理解为内存中的数据表示，Avro, Thrift, Protocol Buffers, Hive SerDe, Pig Tuple, Spark SQL InternalRow等这些都是对象模型。如果你使用了这些数据格式，parquet依然是会先转换成parquet format，然后进行计算
reference
https://www.jianshu.com/p/80c1cb6ccc74
https://blog.csdn.net/worldchinalee/article/details/82781263
