91

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

谢谢！

4

5 回答 5

53

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

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

据我所知，镶木地板还不支持索引。ORC 带有一个轻量级的索引，并且从 Hive 0.14 开始，一个额外的 Bloom Filter 可能有助于更好的查询响应时间，尤其是在求和操作方面。

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

于 2015-09-07T22:02:09.107 回答
49

你看到这个是因为：

  • Hive 有一个矢量化 ORC 阅读器，但没有矢量化 parquet 阅读器。

  • Spark 有一个矢量化 parquet 阅读器，但没有矢量化 ORC 阅读器。

  • Spark 在 parquet 上表现最好，hive 在 ORC 上表现最好。

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

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

（自 Hive 2.0 和 Spark 2.1 起正确）

于 2017-05-05T13:06:04.257 回答
11

Parquet 和 ORC 都有各自的优缺点。但我只是尝试遵循一个简单的经验法则 - “您的数据的嵌套程度以及有多少列”。如果您关注Google 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.

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

于 2019-01-23T20:47:14.387 回答
6

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

于 2017-12-03T17:31:02.763 回答
3

两者都有自己的优势。我们将 Parquet 与 Hive 和 Impala 一起使用，但只想指出 ORC 相对于 Parquet 的一些优势：在长时间执行的查询期间，当 Hive 查询 ORC 表时，GC 的调用频率降低了大约 10 倍。对许多项目来说可能没什么，但对其他项目可能很重要。

当您只需要从表中选择几列时，ORC 所需的时间也少得多。其他一些查询，尤其是连接查询，也因为矢量化查询执行而花费更少的时间，这对 Parquet 不可用

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

于 2018-01-09T18:44:48.863 回答