与其他格式相比，镶木地板格式有哪些优点和缺点？
Apache Parquet的特点是：
- 自描述
- 列格式
- 与语言无关
与Avro，序列文件，RC文件等相比，我想要一个格式的概述。 我已经阅读： Impala如何与Hadoop文件格式一起工作 ，它提供了关于格式的一些见解，但是我想知道如何以这些格式来访问数据和存储数据。 木条地板如何比其他地方有优势？
我认为我可以描述的主要区别涉及面向logging和面向列的格式。 面向logging的格式是我们都习惯的格式 – 文本文件，CSV，TSV等分隔格式。 AVRO比那些稍冷，因为它可以改变架构随着时间的推移，例如添加或删除logging中的列。 各种格式的其他技巧（尤其是包括压缩）涉及到是否可以拆分格式 – 也就是说，是否可以从数据集中的任何位置读取一个logging块并且仍然知道它的模式？ 但是这里更详细的像Parquet这样的柱状格式。
Parquet和其他列式格式非常有效地处理常见的Hadoop情况。 在一个精心devise的关系数据库中，表格（数据集）的列数比你想象的要多得多 – 一般有一百二百列。 这是因为我们经常使用Hadoop作为从关系格式数据非规范化的地方 – 是的，你得到了很多重复的值，许多表都拼凑成一个。 但是由于所有连接都已经完成，所以查询就变得容易了。 还有其他一些优点，例如保留数据的状态。 所以无论如何，在桌子上放置一大堆柱子是很常见的。
假设有132列，其中一些是真正的长文本字段，每个不同的列一个接一个，用完每个logging10K。
从SQL的angular度来看，查询这些表格非常容易，但是通常只需要基于几百个以上的列来获取一些logging。 例如，对于销售额> 500美元的客户，您可能需要2月和3月的所有logging。
要以行格式执行此操作，查询将需要扫描数据集的每个logging。 阅读第一行，将loggingparsing为字段（列）并获取date和销售列，如果满足条件，则将其包含在结果中。 重复。 如果你有10年（120个月）的历史，你正在阅读每一个单一的logging，只是为了find2个月。 当然，这是一个在每年和每个月使用一个分区的好机会，但即便如此，为了查明客户的销售是否超过500美元，您仍然在阅读和parsing这两个月每个logging/行的10K。
以列状格式，logging的每一列（字段）都与其他types的logging一起存储，分布在磁盘上的许多不同的块上 – 一年一列，一月份一列，客户员工手册列（或其他长文本），以及其他所有使这些logging非常庞大的文件，所有这些文件都在磁盘上的独立位置，当然还有一起销售的专栏。 哎呀，date和月份是数字，销售也是如此 – 它们只是几个字节。 如果我们只需要读取每个logging的几个字节来确定哪些logging与我们的查询相匹配，那不是很好吗？ 柱状储存救援！
即使没有分区，为了满足我们的查询需要扫描小字段也是非常快的 – 它们都是按照logging顺序排列的，所有的大小都是一样的，所以磁盘对包含的logging进行less得多的数据检查。 无需阅读该员工手册和其他长文本字段 – 只是忽略它们。 因此，通过将列彼此分组，而不是行，几乎总是可以扫描更less的数据。 赢得！
但是，等一下，它会好起来的。 如果你的查询只需要知道这些值和一些（比如说132列中的10）并且不关心那个员工手册栏，那么一旦它select了正确的logging返回，现在只需要去回到需要渲染结果的10列，忽略了我们数据集中其他的122个。 再一次，我们跳过了很多的阅读。
（注意：因为这个原因，在进行直接转换时，柱状格式是一个糟糕的select，例如，如果将两个表中的所有表合并成一个保存为新表的大（ger）结果集，则源无论如何都会被完全扫描，所以在读取性能方面没有太多的好处，因为列式格式需要记住更多的东西是什么，他们使用更多的内存比相似的行格式）。
柱状数据的另一个好处就是传播。 要获得单个logging，您可以让132名工作人员分别从132个数据块的132个不同位置读取（并写入）数据。 是的并行化！
而现在的紧凑：压缩algorithm可以find重复的模式，更好地工作。 你可以将AABBBBBBCCCCCCCCCCCCCCCC压缩为2A6B16C但ABCABCBCBCBCCCCCCCCCCCCCC不会变小（实际上，在这种情况下，它会的，但相信我:-)）。 所以再次less阅读。 也写。
因此，我们读取的数据less得多，以回答常见的查询，并行读取和写入可能会更快，并且压缩往往会更好。
当你的input端很大时，柱形是很好的，你的输出是一个被过滤的子集：从大到小是很好的。 当input和输出大致相同时不那么有利。
但在我们的例子中，Impala拿走了5,10,20或30分钟的老蜂房查询，几秒钟或一分钟就完成了。
希望这有助于回答至less你的问题的一部分！
Avro是Hadoop的基于行的存储格式。
Parquet是Hadoop的一个基于列的存储格式。
如果您的用例通常扫描或检索每个查询中的所有行中的字段，Avro通常是最佳select。
如果你的数据集有很多列，而你的用例通常涉及到这些列的一个子集而不是整个logging，Parquet是针对这种工作进行优化的。
资源
汤姆的答案是非常详细和详尽的，但你可能也有兴趣在这里简单的研究 Parquet vs Avro在Allstate保险公司完成，总结在这里：
“总的来说，Parquet在每个testing中都显示出类似或者更好的结果（与Avro相比）Parquet支持的较大数据集的查询性能差异部分归因于压缩结果;当查询宽数据集时，Spark必须读取3.5倍Parquet的数据比Avroless，Avro在处理整个数据集的时候performance不佳。
