Parquet vs ORC vs ORC with Snappy

Posted 2023-02-15

【中文标题】Parquet vs ORC vs ORC with Snappy

【英文标题】：

【发布时间】：2015-11-29 03:50:54

【问题描述】：

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

谢谢！

【问题讨论】：

你能分享一个用来做那个实验的通用算法吗？但是，有必要使用相同的数据。但是分享其他所有内容以使用不同的数据集完成相同的结果可能非常有用，可以为您提供更好的答案或证明您的观点非常好并永远改变世界。

你有使用 orc vs parquet 的 spark vs tez 结果吗？据我所见，使用 orc 格式时，tez 似乎更快（快 3 倍）。

+ 1 为您提供出色的基准测试概述。无论如何，由于幕后的某些技术方面发生了变化（例如@jonathanChap 的回答中所讨论的），您是否有机会提供更新版本？

【参考方案1】：

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

如果您有高度嵌套的数据，Parquet 可能会更好，因为它像 Google Dremel 那样将其元素存储为树 (See here)。 如果你的文件结构是扁平的，Apache ORC 可能会更好。

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

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

【讨论】：

表 A - 文本文件格式 - 无压缩............ 表 B - 使用 ZLIB 压缩的 ORC 文件格式............ 表 C - 使用 Snappy 的 ORC ....... Table D - Parquet with Snappy ..... 我在另一个大约 150 列和大约 160 GB 大小的表上工作，以检查文件格式在那里的执行情况。 Parquet 需要 35 GB 来存储 160GB 数据，而带有 snappy 的 ORC 需要 39GB ......与发布的测试相比，Parquet 的压缩看起来要好得多，但性能再次出现在类似的线路上.. ORC 在这里甚至闪耀性能优于 ORC+SNAPPY 组合。

我的用例的数据结构更扁平，没有任何嵌套。我同意您对 Parquet vs ORC 的索引评论，这确实有所作为。从两者的性能比较中，您有什么结果可以分享吗？这可能有助于让我的良心平静下来，我正在正确地实施这些格式。 :)

我从未在 Parquet 上测试过我的数据集，因为索引是必要的要求，而且我们还有一个没有嵌套信息的平面数据结构。我发现，根据您存储文件的位置，您需要不同的条带和文件大小才能获得最佳结果。当您将文件永久存储在 HDFS 上时，最好有更大的文件和条带。 “set mapred.max.split.size=4096000000”是我用来影响文件大小的参数，并将条带大小保留为其默认值。有了这个设置，它给了我大约 94% 的查询和压缩提升。

如果您想将文件存储在 Amazon S3 上作为冷存储，较小的文件和条带大小给了我更好的结果。我使用的文件大小为 40-60MB，包含单个 Stripe。

【参考方案2】：

你看到这个是因为：

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

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

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

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

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

（自 Hive 2.0 和 Spark 2.1 起正确）

【讨论】：

从 2.3.0 开始，spark 确实有一个矢量化 ORC 阅读器：issues.apache.org/jira/browse/SPARK-16060

Hive 2.3.0 具有矢量化 Parquet 阅读器 - issues.apache.org/jira/browse/HIVE-14815

从 Spark 2.3 开始，Spark 支持矢量化 ORC 阅读器spark.apache.org/docs/latest/sql-data-sources-orc.html

【参考方案3】：

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.

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

【参考方案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

【讨论】：

这个确实很有用，但是应该有一个免责声明，@Owen 为 Horton Works 工作，该公司最初开发了 ORC 文件格式

谢谢！但是第二个链接坏了。你能从你的答案中修复或删除它吗？

【参考方案5】：

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

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

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