parquet格式_使用Spark 解释大数据文件格式

了解Avro，Parquet和ORC的工作方式

> Image Source: https://www.ellicium.com/orc-parquet-avro/

在处理大型数据集时，就查询速度和存储成本而言，使用传统的CSV或JSON格式存储数据效率极低。

> Figure 1: Shows a simple sql query performed using CSV, Parquet and ORC file formats. ORC was arou

图1演示了使用正确的文件格式查询数据的功能。 我们发现ORC格式比使用CSV快20倍！ 此处使用的数据集是来自Kaggle的滑行轨迹数据集，大小刚好超过1GB，包含大约170万条记录(可在此处获取数据集的完整详细信息)。

希望这引起了您的兴趣，以了解更多有关存储大数据的正确文件格式的信息。 本文将讨论为存储大数据集而优化的3种主要文件格式，然后在滑行轨迹数据集上使用Spark演示查询速度。 这将在Azure(使用Databricks)和Google Cloud Platform(使用Dataproc)上完成，因此您可以在自己选择的平台上进行尝试。

大数据格式

大数据世界主要具有针对存储大数据而优化的三种主要文件格式：Avro，Parquet和Optimized Row-Columnar(ORC)。 下文提到的每种格式之间都有一些相似之处和不同之处。

相似之处：

·所有这三种格式均以机器可读的二进制格式存储数据，这意味着只能由机器理解，这与人类可读的CSV和JSON格式不同。

·数据集还可以跨多张光盘拆分，从而可以进行大规模并行数据处理。 这大大提高了处理速度

·它们是自我描述的格式：Parquet文件的一个副本可以轻松转移到另一台机器上，而不会造成解释性损失。

·它们是在线格式：可以轻松地在群集中的节点之间传递数据。

差异：

·Parquet和ORC以列格式存储数据，这意味着已对数据进行了优化以实现快速检索。 对于需要大量读取的分析工作负载(即仅使用几列进行分析的查询或具有复杂聚合的查询的查询)而言，这是理想的选择。

·Avro是基于行的数据存储，这意味着已针对"大量写入"工作负载(即需要显示(写入)大部分或全部行数据的查询)进行了数据优化。

尽管不全面，但在确定哪种格式适合您的数据集时，有四个主要属性需要考虑：

· 行或列存储(R)

· 压缩度(C)

· 模式演变(E)

· 可裂性(S)

RaCES是帮助您记住它们的助记符。

行与列存储

> Table 1: Shows the top five all time point leaders in the NBA as of 1st December 2019. Data extrac

行存储逐行存储数据。 以表1中的数据集为例，基于行的存储如下所示：

卡里姆·阿卜杜勒·贾巴尔(Kareem Abdul-Jabbar)1560、57446、38387，

卡尔·马龙(1476)，54852、36928，

科比·布莱恩特(1349)，48643、33643，

勒布朗·詹姆斯(1217)、46895、33031，

迈克尔·乔丹，1072、41010、32292。

数据从左到右逐行存储。 相反，基于列的数据存储如下所示：

贾巴尔(Kareem Abdul-Jabbar)，卡尔·马龙(Karl Malone)，科比·布莱恩特，勒布朗·詹姆斯，迈克尔·乔丹

(1560，1476，1346，1217，1072，)

57446，54852，48643，46895，41010，38387，36928，33643，33031，32292。

数据按从左到右的顺序逐列存储。 该序列可以概括为图2所示。

> Figure 2: Demonstrates how data is stored in row-based vs column-based storage formats. In row based formats, data is stored row by row, from left to right. Columnar formats store data column by column, in sequence from left to right.

现在我们可以开始理解为什么基于列的存储对于分析目的是理想的，在这些分析中查询往往只在特定列而不是整个数据集(即重读)中被隔离。 这种列式存储使Parquet和ORC之类的格式能够在每个列的末尾存储元数据(包含诸如模式，列的最小值和最大值，空值等信息)，这对于基于行的存储是不可能的。 使用此信息，跳到查询所需的相关列会更快，因为元数据将通知查询该列中是否存在相关数据。

例如，假设我们有一个产品表，并且想要找出按产品ID分组的收入最高的产品。 因此，您可能需要查询产品表中的特定列(并对其进行汇总)以提取信息。 将数据存储在Parquet或ORC中后，将执行数据跳过操作以仅扫描相关列(请参见图3)。

> Figure 3: High level demonstration of how data-skipping works.

但是，如果查询需要从数据集中返回全部或大多数行，则改用基于行的存储更为有效。

例如，假设您要预订第二天的航班。 然后，您将要查看与当天可用航班相对应的大多数/所有行数据，以及大多数/所有列，因为每列都会添加更多信息，以便您决定要乘坐的确切航班。 在这种情况下，您可能需要使用基于行的格式，例如Avro，对此进行了优化。

压缩

压缩数据减少了存储，查询和传输数据所需的信息量，从而节省了时间和金钱。

以列格式存储的数据可实现更好的压缩，因为相似类型的数据彼此相邻存储。 例如，以表1中的数据集为例，所有字符串值数据(来自列1)都存储在一起，所有整数值数据(来自列2-4)都存储在一起，因此与行-相比，数据压缩效率更高。 基于数据的存储。 这将减少存储成本。

模式演变

数据集上下文中的"架构"是指列标题和类型。 随着项目的成熟，可能需要向数据集中添加/更改(新)列，从而更改其架构。 讨论的所有3种格式都支持某种程度的模式演变支持，尽管Avro在这方面比其他两种格式优越得多。

可分割性

"可拆分性"是指可以轻松地将大数据集分解为较小的独立块，以便可以由集群中运行的多个节点进行处理。 由于一台机器将没有足够的计算能力来处理整个数据集，因此可以进行大规模并行处理。 Avro，Parquet和ORC格式均经过优化以支持可拆分性。

现在让我们更详细地探讨这三种文件格式。

Avro

Avro由Hadoop团队于2009年开发，是一种基于行的存储格式，可高度拆分。 Avro(Nexla白皮书中已提到)的显着特征是其架构"随数据一起旅行"。 这是因为数据定义/架构以人类可读的JSON格式存储，而数据本身以二进制格式存储。 这样可以最大化压缩和存储效率。 此外，由于数据定义是以人类可读的格式存储的，因此在修改列类型或添加新列类型方面，架构演变极为容易。

Parquet

此格式由Twitter和Cloudera在2013年开发，是基于列的格式。 由于数据存储在列中(如前所述)，因此可以轻松对其进行压缩。 Parquet还将元数据存储在文件末尾，其中包含有用的统计信息，例如模式信息，列的最小值和最大值，压缩/编码方案等。这可以跳过数据，并允许在多台机器之间拆分数据。

ORC

> Figure 4: Shows how 'Stripes' are used to group together data and then store it in columnar format in ORC. The stripe footer contains metadata about the columns in each stripe which is used for data-skipping. Source: Nexla Whitepaper

ORC由Hortonworks在2016年开发，以列格式存储行数据，这对于压缩和存储非常有效。 这种压缩是通过ORC的"索引"系统实现的，该系统将数据存储在大约10,000行的"条带"中。 每个条带将索引(列标题)，行数据和条带页脚(包含列统计信息，架构信息等)分组到单独的列中，如图4所示。这使数据跳过作为查询跳转到 有关条带进行分析。 条带也彼此独立，这允许数据拆分，因为一个条带可以传输到另一个节点上而不会损失可解释性。

选择数据格式时要查找的四个主要属性的摘要以及它们在Avro，Parquet和ORC中的适用性在图4中列出。

> Figure 5: Summary of the 4 core properties to look for in the big data formats discussed along with their compatibility for different platforms. Source: Nexla Whitepaper.

单击此处，获取本文第2部分，该示例演示在Azure和GCP上使用这些有效文件格式实现的查询速度。

参考文献

·Nexla白皮书：大数据格式简介。

·Datanami：神秘的大数据文件格式。

(本文翻译自Akeel Ahamed的文章《Big Data File Formats Explained Using Spark Part 1》，参考：https://medium.com/analytics-vidhya/big-data-formats-explained-using-spark-on-azure-gcp-part-1-a83d153c4e66)