与其他格式相比，地板格式的优缺点是什么？

Question

Apache Parquet的特点如下：

• 自描述
• 柱状格式
• 语言无关

与Avro，Sequence Files，RC文件等相比较，我想要一个关于格式的概述。我已经读过：Impala如何处理Hadoop文件格式，它提供了一些关于格式的见解，但是我想知道数据的访问和数据存储是如何在每种格式中完成的。为什么拼花比其他的更有优势？

Answer 1

我认为我可以描述的主要区别与面向记录的格式和面向列的格式有关。面向记录的格式是我们都习惯的--文本文件，分隔格式，如CSV，TSV。AVRO比那些稍微酷一点，因为它可以随着时间的推移改变模式，例如从记录中添加或删除列。其他各种格式的技巧(特别是压缩)涉及到是否可以拆分格式--也就是说，您可以从数据集中的任何地方读取记录块，并且仍然知道它的模式吗？但是这里有更多关于像Parquet这样的柱状格式的细节。

Parquet和其他柱状格式非常有效地处理常见的Hadoop情况。在设计良好的关系数据库中，表(数据集)的列比您预期的要多得多，这是很常见的-- 100或200列并不少见。这是因为我们经常将Hadoop用作从关系格式中去化数据的地方--是的，您会得到很多重复的值和许多表，它们都被压平成一个单独的值。但是，由于所有的联接都是计算出来的，所以查询起来就容易多了。还有其他一些优点，比如保留实时状态数据。因此，不管怎么说，在表中有一堆列是很常见的。

假设有132个列，其中一些是非常长的文本字段，每个列都是一个接一个，每条记录消耗了大约10K。

尽管从SQL的角度来查询这些表很容易，但是您通常只想根据这100多个列中的几个获得一些记录。例如，对于销售额超过500美元的客户，您可能需要2月和3月的所有记录。

若要以行格式执行此操作，查询将需要扫描数据集的每条记录。读取第一行，将记录解析为字段(列)，获取日期和销售列，如果满足条件，则将其包含在结果中。重复一遍。如果你有10年(120个月)的历史，你正在阅读每一个记录，只是为了找到其中的2个月。当然，这是一个在年份和月份使用分区的好机会，但即使如此，您仍在阅读和解析这两个月的每条记录/行的10K，仅仅是为了确定客户的销售额是否大于500美元。

在一种列格式中，记录的每一列(字段)都与其他类型的列(字段)一起存储，分散在磁盘上的许多不同块上--列在一起，列在客户员工手册(或其他长文本)中，所有其他使这些记录如此巨大的列都位于磁盘上各自单独的位置，当然还有用于销售的列。见鬼，日期和月份是数字，销售也是数字--它们只是几个字节。如果我们只需要读取每条记录的几个字节就可以确定哪些记录与我们的查询匹配，这不是很好吗？柱状储藏室来营救！

即使没有分区，扫描满足我们的查询所需的小字段的速度也非常快--它们都是按记录排列的，大小相同，因此磁盘查找的包含记录的数据检查要少得多。不需要阅读员工手册和其他长的文本字段--只需忽略它们。因此，通过将列彼此分组，而不是行，您几乎总是可以扫描较少的数据。赢!

但是等等，情况会好起来的。如果您的查询只需要知道这些值和更多的值(比如132列中的10列)，并且不关心员工手册列，那么一旦它选择了要返回的正确记录，它现在只需要返回它所需的10列来呈现结果，而忽略了数据集中132中的其他122列。再说一遍，我们跳过了很多阅读。

(注意:由于这个原因，在进行直接转换时，列格式是一个糟糕的选择，例如，如果将所有两个表连接到一个大(Ger)结果集中，您将其保存为一个新表，那么无论如何源都会被扫描，所以读取性能没有什么好处，而且由于列格式需要记住更多的内容，它们使用的内存比类似的行格式要多)。

专栏的另一个好处是:数据是分散的。要获得一条记录，您可以让132名工作人员从132个数据块上的132个不同位置读取(和写入)数据。并行化太好了！

现在，对于clincher来说，压缩算法在能够找到重复模式时工作得更好。您可以将AABBBBBBCCCCCCCCCCCCCCCC压缩为2A6B16C，但是ABCABCBCBCBCCCCCCCCCCCCCC不会变得那么小(实际上，在这种情况下是这样的，但是请相信我:-)。所以再一次减少阅读。还有写作。

因此，为了回答常见的查询，我们读取的数据要少得多，并行读写可能更快，而且压缩工作更好。

当输入端很大时，柱状结构很好，而输出是一个过滤的子集:从大到小都是很棒的。当输入和输出大致相同时，就没有那么有益了。

但在我们的例子中，Impala使用了我们在5、10、20或30分钟内运行的老Hive查询，并在几秒钟或一分钟内完成了大部分查询。

希望这能帮助你至少回答一部分问题！

Answer 2

Avro是Hadoop的基于行的存储格式。

Parquet是一种基于列的Hadoop存储格式。

如果您的用例通常扫描或检索每个查询中一行中的所有字段，则Avro通常是最佳选择。

如果您的dataset有许多列，而且您的用例通常涉及使用这些列的子集，而不是整个记录，那么Parquet是针对这种工作进行优化的。

来源

Answer 3

汤姆的回答非常详细和详尽，但你也可能对这个简单的研究有关Parquet vs Avro在Allstate所做的事情感兴趣，总结如下：

“总的来说，Parquet在每次测试中都显示出与Avro相似或更好的结果。这一查询--在更大的数据集上有利于Parquet的性能差异--部分原因在于压缩结果；在查询广泛的数据集时，Spark必须读取比Avro少3.5倍的Parquet数据。正如所怀疑的那样，Avro在处理整个数据集时表现不佳。”