Parquet vs ORC vs ORC with Snappy

Question

我正在对Hive可用的存储格式进行一些测试，并使用Parquet和ORC作为主要选项。我在默认压缩中包含一次ORC，在Snappy中包含一次。

我读过很多文档，说Parquet在时间/空间复杂性方面比ORC更好，但我的测试结果与我读过的文档相反。

跟随我的数据的一些细节。

Table A- Text File Format- 2.5GB
Table B - ORC - 652MB
Table C - ORC with Snappy - 802MB
Table D - Parquet - 1.9 GB

对于我的表来说，Parquet是最糟糕的压缩。

我对上述表格的测试得到了以下结果:

行计数操作

Text Format Cumulative CPU - 123.33 sec
Parquet Format Cumulative CPU - 204.92 sec
ORC Format Cumulative CPU - 119.99 sec 
ORC with SNAPPY Cumulative CPU - 107.05 sec

列操作和

Text Format Cumulative CPU - 127.85 sec   
Parquet Format Cumulative CPU - 255.2 sec   
ORC Format Cumulative CPU - 120.48 sec   
ORC with SNAPPY Cumulative CPU - 98.27 sec

列操作的平均值

Text Format Cumulative CPU - 128.79 sec
Parquet Format Cumulative CPU - 211.73 sec    
ORC Format Cumulative CPU - 165.5 sec   
ORC with SNAPPY Cumulative CPU - 135.45 sec 

使用where子句

从给定范围中选择4列

Text Format Cumulative CPU -  72.48 sec 
Parquet Format Cumulative CPU - 136.4 sec       
ORC Format Cumulative CPU - 96.63 sec 
ORC with SNAPPY Cumulative CPU - 82.05 sec 

这是否意味着ORC比Parquet更快?或者我可以做些什么使它在查询响应时间和压缩比方面工作得更好?

谢谢!

Answer 1

我想说，这两种格式都有自己的优点。

如果你有高度嵌套的数据，

Parquet可能更好，因为它像Google Dremel那样以树的形式存储元素(见这里)。如果你的文件结构是扁平的，Apache ORC可能会更好。

据我所知，parquet还不支持索引。ORC提供了一个轻量级的索引，并且自Hive 0.14以来增加了一个额外的Bloom Filter，这可能有助于更好的查询响应时间，特别是在涉及求和操作时。

Parquet默认压缩是SNAPPY。表A - B - C和D持有相同的数据集吗?如果是的话，当它只压缩到1.9 GB

Answer 2

你看到这个是因为:

• Hive有一个矢量化的ORC阅读器，但是没有矢量化的拼花阅读器。

• Spark有一个矢量化的拼花阅读器，没有矢量化的ORC阅读器。

• Spark使用parquet效果最好，hive使用ORC效果最好。

在Spark上运行ORC和Parquet时，我也看到了类似的差异。

向量化意味着行被批量解码，极大地提高了内存局部性和缓存利用率。

(正确于Hive 2.0和Spark 2.1)

Answer 3

Parquet和ORC都有各自的优缺点。但我只是尝试遵循一个简单的经验法则- "你的数据是如何嵌套的，有多少列"。如果你遵循谷歌Dremel你可以找到拼花是如何设计的。它们使用分层的树状结构来存储数据。巢越深，树越深。

但是ORC是为扁平文件存储而设计的。因此，如果您的数据是扁平的，列更少，您可以使用ORC，否则，拼花就可以了。压缩扁平数据在ORC中工作得很好。

我们对一个较大的扁平文件进行了基准测试，将其转换为spark Dataframe，并将其以parquet和ORC格式存储在S3中，并使用**Redshift-Spectrum **进行查询。

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

很快，我们将对嵌套数据做一些基准测试，并在这里更新结果。

Answer 4

我们在不同的用例中比较了不同的文件格式(Avro, JSON, ORC和Parquet)。

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

数据都是公开的，基准代码都是开源的:

https://github.com/apache/orc/tree/branch-1.4/java/bench

Answer 5

两者各有优势。我们将Parquet与Hive和Impala一起使用，但只是想指出ORC相对于Parquet的一些优势:在长时间执行的查询中，当Hive查询ORC表时，调用GC的频率大约少10倍。可能对许多项目来说没什么，但对其他项目来说可能是至关重要的。

当您只需要从表中选择几个列时，

ORC也花费更少的时间。其他一些查询，特别是连接查询，也花费更少的时间，因为矢量化查询执行，这对于Parquet

是不可用的。

此外，ORC压缩有时有点随机，而Parquet压缩则更加一致。看起来，当ORC表有很多数字列时，它不会压缩。它同时影响zlib和snappy压缩

Answer 6

Spark默认文件格式为parquet, Hive默认文件格式为orc。据我所知(也许我错了)，使用zlib的压缩比使用snappy要高，但它需要更多的CPU。另一方面，Snappy是一个伟大的"体面的"人。

当你不希望太多的CPU消耗。

我没有尝试过parquet API来写/读文件，但我有一些使用ORC的经验。ORC格式很好，但是当您试图在同一JVM进程的不同线程中同时写入文件时，它似乎会成为瓶颈。它也有一些记忆问题。我必须对类做一些小改动

org.apache.hadoop.hive.ql.io.orc.MemoryManagerorg.apache.hadoop.hive.ql.io.orc.WriterImpl

为了使它更好更快地工作(HDP 2.6.4.0)。

正如前面的人所说，这完全取决于你的数据结构，你用来读取数据的API或框架，以及你想用这些数据做什么。

ORC文件具有不同级别(文件，条纹和行)的统计信息，例如，当您过滤数据时，这些统计信息可以大大提高性能。

ORC在写列为空值或相同的值经常重复时也有一些改进。

当你真正想做的事情与基准测试的内容无关时，基准测试就没有那么有用了。