大数据常见格式和pyspark

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]

image.png

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