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

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

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

行计数操作

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 那样的树（See here）。如果您的文件结构被展平，Apache ORC可能会更好。

据我所知，实木复合地板还不支持索引。 ORC附带一个轻量级索引，因为Hive 0.14还有一个额外的布隆过滤器，这可能有助于提高查询响应时间，特别是在总和操作方面。

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

时，它看起来有些阴暗

Answer 2

你看到这个是因为：

Hive有一个矢量化ORC阅读器，但没有矢量化镶木地板阅读器。
Spark有一个矢量化的镶木地板阅读器，没有矢量化的ORC阅读器。
Spark使用镶木地板效果最佳，配置单元最适合ORC。

我在使用Spark运行ORC和Parquet时看到了类似的差异。

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

（从Hive 2.0和Spark 2.1开始正确）

Answer 3

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

他们都有自己的优势。我们使用Parquet与Hive和Impala一起工作，但只是想指出ORC优于Parquet的一些优点：在长期执行查询期间，当Hive查询ORC表 GC被调用约10次时。许多项目可能没什么，但对其他项目可能至关重要。

当您需要从表中选择几列时，ORC也会花费更少的时间。其他一些查询，尤其是连接查询，由于矢量化查询执行所需的时间也较少，而Parquet不可用

此外，ORC压缩有时是随机的，而Parquet压缩更加一致。看起来ORC表有很多列数 - 它也不会压缩。它会影响zlib和snappy压缩

Answer 5

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

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

我们使用更大的拼合文件进行了基准测试，将其转换为spark Dataframe，并以实木复合地板和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.

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

Parquet vs ORC vs ORC与Snappy

5 个答案: