logo标签列表

为什么在Hive中查询Parquet文件比文本文件慢？

hadoophiveparquetmaprsnappy
7
我决定将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：使用Where子句的[仅有4个列]多行选择[已提取1000行]
  • 操作5：聚合操作[在给定列上使用Sum函数]

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

我还使用表C执行了上述操作，但结果与TextFile格式几乎相似，而后者又是两者中更快的。

请问有人能告诉我我做错了什么吗？

谢谢！

编辑

我将ORC添加到存储格式列表中，并再次运行测试。以下是详细信息。

行计数操作

Text格式累积CPU - 123.33秒

Parquet格式累积CPU - 204.92秒

ORC格式累积CPU - 119.99秒

带SNAPPY的ORC格式累积CPU - 107.05秒

列求和操作

Text格式累积CPU - 127.85秒

Parquet格式累积CPU - 255.2秒

ORC格式累积CPU - 120.48秒

带SNAPPY的ORC格式累积CPU - 98.27秒

列平均值操作

Text格式累积CPU - 128.79秒

Parquet格式累积CPU - 211.73秒

ORC格式累积CPU - 165.5秒

带SNAPPY的ORC格式累积CPU - 135.45秒

使用Where子句从给定范围选择4个列

Text格式累积CPU - 72.48秒

Parquet格式累积CPU - 136.4秒

ORC格式累积CPU - 96.63秒

带SNAPPY的ORC格式累积CPU - 82.05秒

这是否意味着ORC比Parquet更快？还是有什么我可以做来提高查询响应时间和压缩比率？

谢谢！

只出于好奇：1 你尝试选择几列而不是选择所有列了吗？柱状存储在从列碎片中重建“胖”行方面并不那么擅长 2 你是否考虑过使用ORC（带有快速条纹消除、矢量化读取等）作为可在Hive中得到更好支持的备选格式？ - Samson Scharfrichter
2
Smason，以下是我的回答。#1. 是的，我从表中提取了几列。累计CPU对于Parquet仍然更高[您可以在帖子中检查结果]。#2. 在发布问题后，我使用ORC进行了工作。它占用的空间要少得多，只有652MB，而且所需的时间也比parquet短。我将编辑我的问题并发布来自ORC表的完整结果。 - Rahul
2
只是出于好奇，我找不到一篇好的论文讨论Parquet和ORC的优劣。你有没有任何文件可以根据用例比较这两种文件格式？此外，我在这里使用的表格并不宽，只有12-15列。Parquet在这里是一个好选择吗？ - Rahul
1
丑陋的事实是，Cloudera正在推动Parquet+Impala，而HortonWorks正在推动ORC+Hive。涉及大量营销和政治...但是有一些格式无关的工具，比如Presto，例如http://www.zdnet.com/article/how-facebook-is-speeding-up-the-presto-sql-query-engine/（注意：性能可能会随着新版本和配置调整而发生巨大变化） - Samson Scharfrichter
@SamsonScharfrichter 非常有趣...我认为“酷孩子们”正在使用Spark+Parquet。 - BAR
显示剩余3条评论
1个回答
0

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

以下是一些要点：

  • 在分布式环境中测量时间并不是确定某个操作是否缓慢的方法（如果有许多查询正在运行并竞争资源，则无法测量您认为正在测量的内容）

  • 未提供实际表定义和运行对这些表的查询使得此问题无法重现

  • 未提供表的行数和其各个字段的基数也没有帮助

通常情况下，查询 Parquet 比查询文本文件快得多，因为 Parquet 采用了许多方法来使读取操作更快。其中一些方法包括：

  • 压缩
  • 运行长度编码
  • 字典编码

根据用例，可以调整这些参数中的一些参数以适应确切的用例。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接