Parquet vs ORC vs Snappy的ORC

我正在对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

就我桌子的压缩而言，实木复合地板最糟糕。

我对以上表格的测试得出以下结果。

行计数操作

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更快？还是我可以做些什么来使其在查询响应时间和压缩率上更好地工作？

谢谢！

我要说的是，这两种格式都有自己的优势。

如果您具有高度嵌套的数据，则Parquet可能会更好，因为它像Google Dremel一样将其元素存储为树（请参阅此处）。
如果将文件结构展平，则Apache ORC可能会更好。

据我所知，镶木地板尚不支持索引。ORC带有轻量级索引，并且自Hive 0.14起提供了额外的Bloom Filter，这可能有助于改善查询响应时间，尤其是在求和操作时。

Parquet的默认压缩为SNAPPY。表A-B-C和D是否拥有相同的数据集？如果是，当它仅压缩到1.9 GB时，看起来好像有一些阴影

您看到此消息是因为：

• Hive具有矢量化的ORC读取器，但没有矢量化的实木复合地板读取器。

• Spark具有矢量化实木复合地板读取器，而没有矢量化ORC读取器。

• Spark在镶木地板上表现最佳，蜂巢在ORC上表现最佳。

当运行带有Spark的ORC和Parquet时，我已经看到了类似的差异。

向量化意味着对行进行批量解码，从而显着提高了内存局部性和缓存利用率。

（自Hive 2.0和Spark 2.1起正确）

Parquet和ORC都有各自的优点和缺点。但我只是尝试遵循一个简单的经验法则- “您的数据嵌套多少，其中有多少列”。如果您遵循Google Dremel，则可以找到镶木地板的设计方式。他们使用分层的树状结构来存储数据。嵌套越深，树越深。

但是ORC是为扁平化文件存储设计的。因此，如果使用较少的列将数据展平，则可以使用ORC，否则，镶木地板将很适合您。在ORC中，对扁平化数据的压缩效果惊人。

我们使用更大的扁平化文件进行了一些基准测试，将其转换为spark Dataframe并将其存储为S3中的镶木地板和ORC格式，并使用** 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.

不久我们将对嵌套数据进行一些基准测试，并在此处更新结果。

我们做了一些基准测试，比较了不同用例中的不同文件格式（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

他们两个都有自己的优势。我们将Parquet与Hive和Impala一起使用，但只想指出ORC相对于Parquet的一些优势：在长时间执行的查询中，当Hive查询ORC表时，GC的调用频率降低了大约10倍。对于许多项目而言可能无济于事，但对其他项目可能至关重要。

当您只需要从表中选择几列时，ORC所花费的时间也少得多。由于矢量化查询的执行，某些其他查询（尤其是带有联接的查询）所花费的时间也更少，这不适用于Parquet

而且，ORC压缩有时会有点随机，而Parquet压缩则更加一致。看起来当ORC表具有许多数字列时-它也不会压缩。它会影响zlib和snappy压缩