解析四种大数据文件格式

待我称王封你为后i 2023-06-15 07:22 18阅读 0赞

众所周知，Apache Spark支持许多种不同的数据格式，其中包括：无处不在的CSV格式、对于Web友好的JSON格式、以及常被用于大数据分析的Apache Parquet和Apache Avro。

![format_png][]

在本文中，我们将通过Apache Spark，来向您介绍上述四种大数据文件格式的各种属性，及其优缺点比较。

1、CSV

CSV(Comma-Separated Values，逗号分隔值)文件，通常被用于在使用纯文本的系统之间，交换表格类型的数据。CSV是一种基于行的文件格式。也就是说，此类文件中的每一行都对应到数据表中的具体某一行。通常，CSV文件里包含有一个标题行，该标题行提供了数据的列名。如果没有标题行的话，该文件将被视为已部分完成了结构化工作。

单个CSV文件往往无法显示层次化的结构、或数据关系。而具体的数据连接关系往往需要通常多个CSV文件进行组织。各种外键(Foreign key)一般被存储在一个或多个文件的多个列中。不过这些文件之间的链接并非由其格式本身来表示。此外，由于并未完全标准化，因此在CSV格式文件中，您可以使用逗号以外的界定符，例如：制表符(tabs)或空格。

CSV文件的另一个特性是：只有处于未压缩的原始文件状态、或是运用诸如bzip2(https://en.wikipedia.org/wiki/Bzip2)或lzo(https://ru.wikipedia.org/wiki/LZO)之类的解压缩工具时，CSV文件才能够被拆分(注意：lzo需要进行索引之后，方可执行拆分)。

**优点：**

CSV易于人工阅读，也易于手动编辑。

CSV提供了一种简单明了的信息模式(schema)。

几乎所有现有的应用程序都能够处理CSV文件。

CSV文件比较易于实现和解析。

对于XML而言，您需要在每一行的每一列中分别添加开始与结束标签;而CSV比较简约，您只需一次性写入列标题即可。

**缺点：**

由于处置的是平面数据，因此需要事先对复杂的数据结构进行格式上的转换。

由于不支持列的类型，因此在文本列和数字列之间并无区别。

并无表示二进制数据的标准方法。

由于NULL和引号之间并无区别，因此导入CSV时可能会出现问题。

对于特殊字符的支持性较差。

缺乏通用的标准。

尽管存在着一定的局限性，但CSV文件仍然是数据共享领域的上乘之选。它经常被广泛地用于各类业务应用、消费者行业、以及科学分析程序中。当前，大多数批处理和流数据处理模块(如Spark和Hadoop)，都能够支持CSV文件的序列化与反序列化。它们在读取时提供了添加schema的方法。如果你对大数据挖掘感兴趣，想系统学习大数据的话，可以加入大数据技术学习交流扣扣群：458数字345数字782，欢迎添加，了解课程介绍，获取学习资源

2、JSON格式

JSON数据(JavaScript object notation，对象表示法)是以部分结构化的格式，表示各种键值(key-value)对。与XML不同，JSON通常可以按照分层的格式存储数据，即：子数据可以由父数据来显示。而与XML相同的是，它们在格式上都具有自我描述性(self-describing)，可以被用户直接读取。不过，JSON文档通常要小得多。随着基于REST的Web服务的大量出现，JSON文档被频繁地使用在网络通信中。

由于许多类型的数据传输都已经用到了JSON格式，因此目前大多数的Web编程语言都能够支持JSON，或者通过使用外部库，来对JSON数据进行序列化和反序列化。正是有了这种支持，JSON能够通过显示数据结构，帮助用户实现热数据(hot data)的格式转换、以及冷数据(cold data)存储所涉及到的各种逻辑格式。

目前，许多批处理与流数据处理模块，都能够原生地支持JSON的序列化和反序列化。JSON文档中包含的数据，不但最终能够以性能更为优化的格式(如Parquet或Avro)予以存储，而且JSON所提供的原始数据类型，对于按需进行数据重新处理的任务也是非常重要的。

**JSON文件具有如下优点：**

JSON支持分层式结构，简化了文档中有关数据的存储，以及复杂关系的表示问题。

大多数编程语言都能够提供简化的JSON序列化库，并且能够对JSON序列化/反序列化提供内置的支持。

JSON支持对象列表，能够有助于避免将对象列表错误地转换为关系型数据模型。

诸如MongoDB、Couchbase和Azure Cosmos DB等NoSQL数据库，都能够支持JSON文件格式。

目前大多数工具都内置了对于JSON的支持。

3、Parquet

Cloudera和Twitter于2013年开发出了Parquet。它可以被用作基于列的存储格式，并针对多列数据集进行了适当地优化。由于其数据是按列进行存储的，因此它可以对数据进行高度压缩(其压缩算法对于那些包含在列中的、信息熵值较低的数据，效果会更好)，以及拆分操作。Parquet的开发者号称：此类存储格式非常适合于处理大数据的相关问题。

与CSV和JSON不同，Parquet是一种二进制文件，其中包含了各种针对其内容的元数据(metadata)。因此，在无需读取与解析文件内容的情况下，Spark可以仅依靠元数据来确定文件中的列名称、压缩/编码方式、数据类型、乃至一些基本的统计类信息。另外，由于Parquet文件的列相关元数据通常被存储在文件的末尾，因此方便了用户一次性快速地写入信息。同时，Parquet针对WORM(Write Once Read Many，一次写入多次读取，请参见)的范例也进行了优化。虽然在写入文件其速度较慢，但是用户在读取时，尤其是仅访问某个列的子集时，速度却快得惊人。可见，对于那些需要大量进行读取操作的工作负载而言，Parquet是一种不错的选择。而对于需要操作整行数据的用例而言，用户则应当使用CSV或AVRO之类的格式。

**Parquet在数据存储方面的优点包括：**

由于是一种柱状结构的形式，因此Parquet只会读取所需的列信息，进而减少了对于磁盘I/O的消耗。这个概念被称为投影下推(projection pushdown)。

由于schema是随着数据一起移动的，因此数据能够自我描述(self-describing)。

虽然主要是为HDFS而创建的，但是其数据完全可以被存储在GlusterFs或NFS之类的其他文件系统中。

作为一个文件，您可以轻松地对Parquet进行移动、备份、复制、以及使用。

能够对Spark提供开箱即用式的原生支持，能够对于用户存储中的文件直接进行读取与保存。

当采用诸如snappy之类的压缩格式时，Parquet可以达到75%的高压缩比。

在实际运用中，与同类其他文件格式相比，该格式读取工作流的速度最快。

Parquet非常适合于那些需要对大量数据进行列汇总的数据仓库类应用。

可以通过Avro API和Avro Schema来读取和写入Parquet。

通过提供谓词下推(predicate pushdown)，Parquet可以进一步降低磁盘I/O的成本。

**谓词下推/过滤下推**

谓词下推的基本思想是：将查询的某些部分(如：谓词)“推送”到数据的存储位置。例如，当我们提供一些过滤条件时，数据存储将会以过滤记录的方式，再从磁盘中读取数据。

谓词下推的优点：由于不再需要将整个数据读入内存并进行过滤，因此它并不需要大量的内存，也不会产生过多的磁盘I/O。显然整体性能得到了显著提升。

可见，此类方法可以通过较早地过滤掉无关数据的方式，来大幅减少查询与处理的时间。根据处理框架的不同，谓词下推可以通过执行不同的操作来优化查询。例如：在通过网络传输之前便过滤数据，在将数据加载到内存之前过滤数据，或是跳过读取整个文件(文件块)等操作。

目前，大多数RDBMS，包括Parquet和ORC等大数据存储格式，都能够遵循谓词下推的相关概念。

**投影下推**

![format_png 1][]

投影下推的基本思想是：在对存储进行数据查询与读取时，并非读取所有字段，而只是读取那些必需的列。通常，Parquets和ORC之类的列格式都能够通过遵循此概念，以产生更好的I/O性能。

4、Avro

由Hadoop工作组于2009年发布的Apache Avro，是一种基于行的、可高度拆分的数据格式。Avro能够支持多种编程语言。通常，它也被描述为类似于Java序列化的数据序列化系统。为了最大程度地减小文件大小、并提高效率，它将schema存储为JSON格式，而将数据存储为二进制格式。

Avro通过管理各种添加、丢失、以及已更改的字段，来为schema的演化提供强大的支持。这使得旧的软件可以读取新的数据，而新的软件也可以读取那些旧的数据。而这对于那些经常发生变更的数据而言，是非常重要的。

Avro通过schema架构的管理能力，可以在不同的时段独立地更新不同的组件，从而降低了不兼容性所带来的风险。同时，开发人员既不必在应用程序中编写if-else语句，来应对不同的架构版本，也不必通过查看旧的代码，来理解那些旧的架构。而且，所有版本的schema都存储在可读的JSON标头中，以方便开发人员理解所有可用的字段。

如前文所述，由于schema是以JSON格式存储的，而数据是以二进制形式存储的，因此Avro是持久性数据存储和电传(wire transfer)的简约之选。另外，由于用户能够轻松地向Avro附加新的数据行，因此它通常是那些大量写入工作负载的首选格式。

**优点：**

Avro是一种与语言无关的数据序列化。

Avro将schema存储在文件的标题中，因此数据具有自描述性。

Avro格式的文件既可以被拆分、又可以被压缩，因此非常适合于在Hadoop生态系统中进行数据的存储。

由于Avro文件将负责读取的schema与负责写入的schema区分开来，因此它可以独立地添加新的字段。

与序列文件(Sequence Files)相同，为了实现高度可拆分性，Avro文件也包含了用于分隔不同块(block)的同步标记。

可以使用诸如snappy之类的压缩格式，来压缩不同的目标块。

总结

下表是上述四种文件格式的综合比较。

![format_png 2][]

上表中的\*号为：当作为CSV被压缩时，JSON具有可拆分性方面的类似问题。也就是说：当“wholeFile”选项被设置为true时(请参阅SPARK-18352)，JSON是不可拆分的。

CSV有着最快的写入速度;JSON方便了人工阅读和理解;Parquet在读取列的子集方面速度最快;而Avro在一次性读取所有列方面速度最快。

JSON是Web通信方面的标准。通过定义良好的schema，各种API和网站可以持续使用JSON进行通信。

针对大数据的需求，Parquet和Avro进行了可拆分性方面的优化，可支持各种压缩，以及复杂数据结构。不过，它们的可读性和写入速度非常差。

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy84NjY2OTkwLTdhOWExNjEyNTNiNTZkNzg?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy84NjY2OTkwLWQ0YzZhNWEwMTI1YWUwZTI?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy84NjY2OTkwLTQ3MDhkNzdlY2NhODNhOTg?x-oss-process=image/format,png