为什么查询 Parquet 文件比 Hive 中的文本文件慢？答案

【问题标题】：Why is querying Parquet files is slower than text files in Hive?为什么查询 Parquet 文件比 Hive 中的文本文件慢？
【发布时间】：2015-11-27 19:33:14
【问题描述】：

我决定使用 Parquet 作为 hive 表的存储格式，在我在集群中实际实现它之前，我决定运行一些测试。令人惊讶的是，Parquet 在我的测试中速度较慢，而一般认为它比纯文本文件更快。

请注意，我在 MapR 上使用 Hive-0.13

----------------------------------------------------------
|             | Table A | Table B | Table C |            |
----------------------------------------------------------
| Format      | Text    | Parquet | Parquet |            |
| Size[Gb]    | 2.5     | 1.9     | 1.9     |            |
| Comrepssion | N/A     | N/A     | Snappy  |            |
| CPU [sec]   | 123.33  | 204.92  | N/A     | Operation1 |
| Time [sec]  | 59.057  | 50.33   | N/A     | Operation1 |
| CPU [sec]   | 51.18   | 117.08  | N/A     | Operation2 |
| Time [sec]  | 25.296  | 27.448  | N/A     | Operation2 |
| CPU [sec]   | 57.55   | 113.97  | N/A     | Operation3 |
| Time [sec]  | 20.254  | 27.678  | N/A     | Operation3 |
| CPU [sec]   | 57.55   | 113.97  | N/A     | Operation4 |
| Time [sec]  | 20.254  | 27.678  | N/A     | Operation4 |
| CPU [sec]   | 127.85  | 255.2   | N/A     | Operation5 |
| Time [sec]  | 29.68   | 41.025  | N/A     | Operation5 |

操作 1：行计数操作
操作 2：单行选择
操作 3：使用 Where 子句进行多行选择 [提取了 1000 行]
操作 4：多行选择 [只有 4 列] 使用 Where 子句 [提取了 1000 行]
操作 5：聚合操作 [在给定列上使用 sum 函数]

您可以看到，在我对两个表应用的几乎所有操作中，Parquet 在执行查询所需的时间方面都落后了，但行计数操作除外。

我也使用表 C 来执行上述操作，但结果几乎在相似的行上，TextFile 格式再次是两者中更快的。

谁能告诉我我做错了什么？

谢谢！

编辑

我将 ORC 添加到存储格式列表中并再次运行测试。关注细节。

行计数操作

文本格式累积 CPU - 123.33 秒

Parquet 格式累积 CPU - 204.92 秒

ORC 格式累积 CPU - 119.99 秒

具有 SNAPPY 累积 CPU 的 ORC - 107.05 秒

一列运算之和

文本格式累积 CPU - 127.85 秒

Parquet 格式累积 CPU - 255.2 秒

ORC 格式累积 CPU - 120.48 秒

具有 SNAPPY 累积 CPU 的 ORC - 98.27 秒

一列操作的平均值

文本格式累积 CPU - 128.79 秒

Parquet 格式累积 CPU - 211.73 秒

ORC 格式累积 CPU - 165.5 秒

使用 SNAPPY 累积 CPU 的 ORC - 135.45 秒

使用 where 子句从给定范围中选择 4 列

文本格式累积 CPU - 72.48 秒

Parquet 格式累积 CPU - 136.4 秒

ORC 格式累积 CPU - 96.63 秒

具有 SNAPPY 累积 CPU 的 ORC - 82.05 秒

这是否意味着 ORC 比 Parquet 更快？或者我可以做些什么来使其更好地处理查询响应时间和压缩率？

谢谢！

【问题讨论】：

只是出于好奇：1 您是否尝试选择几列而不是全选？列式存储并不擅长从列碎片中重建“胖”行2您是否考虑过 ORC（带快速条带消除、矢量化读取等）作为 Hive 中更好支持的替代格式?
Smason，请关注我对您的询问的回复。 #1。是的。我确实从表中提取了几列。 Parquet 的累积 CPU 仍然更高[您可以查看帖子中发布的结果]。 #2。在这里发布我的问题后，我在 ORC 工作。它占用的空间要少得多，652MB，也比镶木地板占用更少的时间。我将编辑我的问题并从 ORC 表中获取完整的结果。
只是出于好奇，我没能找到一篇很好的论文来讨论 Parquet 和 ORC 并驾齐驱。您是否有任何文档可以根据用例比较这两种文件格式？另外，我在这里使用的表格不是那么宽，有 12-15 列。镶木地板是一个不错的选择吗？
丑陋的事实是，Cloudera 正在推动 Parquet+Impala，而 HortonWorks 正在推动 ORC+Hive。涉及很多营销和政治......但是有一些与格式无关的工具，例如 Presto，例如zdnet.com/article/…（警告：性能可能会随着新版本和配置调整而发生巨大变化）
令我惊讶的是它花费了你的时间。你用的是什么硬件？并始终发布基准代码。

标签： hadoop hive parquet mapr snappy

【解决方案1】：

首先我想指出的是，用给定的细节来回答你的问题几乎是不可能的。

几点：

在分布式环境中测量时间并不是确定某事是否缓慢的方法（如果您有许多查询正在运行并竞争资源，那么您就没有衡量您认为您正在测量的内容）
不提供实际的表定义和针对这些表运行的查询使得这个问题无法重现
不提供表格的行数及其各个字段的基数也无济于事

一般来说，查询 Parquet 比查询文本文件要快得多，因为 Parquet 使用了很多东西来使读取操作更快。这些东西很少：

压缩
游程编码
字典编码

根据用例，某些参数可以调整到确切的用例。

【讨论】：