Hadoop 为什么在配置单元中查询拼花文件比查询文本文件慢？

我决定使用拼花地板作为配置单元表的存储格式，在我在集群中实际实现它之前，我决定运行一些测试。令人惊讶的是，在我的测试中，拼花地板的速度比普通文本文件的速度要慢

请注意，我在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子句[获取1000行]进行多行选择[仅4列]
• 操作5:聚合操作[对给定列使用求和函数]

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

我也使用表C来执行上述操作，但结果几乎与TextFile格式的行相似，这两种格式中又一种更为简洁

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

谢谢

编辑

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

行计数操作

文本格式累积CPU-123.33秒

拼花地板格式累积CPU-204.92秒

ORC格式累积CPU-119.99秒

具有快速累积CPU的ORC-107.05秒

列操作的和

文本格式累积CPU-127.85秒

拼花地板格式累积CPU-255.2秒

ORC格式累积CPU-120.48秒

具有快速累积CPU的ORC-98.27秒

列操作的平均值

文本格式累积CPU-128.79秒

拼花地板格式累积CPU-211.73秒

ORC格式累积CPU-165.5秒

具有快速累积CPU的ORC-135.45秒

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

文本格式累积CPU-72.48秒

拼花地板格式累积CPU-136.4秒

ORC格式累积CPU-96.63秒

具有快速累积CPU的ORC-82.05秒

这是否意味着兽人比拼花地板更快？或者我可以做些什么，让它在查询响应时间和压缩比方面工作得更好

---

谢谢

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

几点：

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

• 如果不提供实际的表定义和针对这些表运行的查询，则无法重现此问题

• 不提供表的行数及其各个字段的基数也无济于事

一般来说，查询拼花要比查询文本文件快得多，因为拼花使用了很多东西来加快读取操作。以下几点：

• 压缩
• 游程编码
• 字典编码

---

根据用例的不同，某些东西的参数可以根据具体的用例进行调整。

只是出于好奇：1您是否尝试选择了几列而不是全部选择？柱状存储不擅长重建柱状碎片中的“FAT”行2。您认为ORC（W/FAST条形消除、矢量化读取等）作为一种可供选择的格式，在HIVE SMASON中有更好的支持，请遵循我对您的查询的响应。1.对我确实从表中提取了几列。拼花地板的累积CPU仍然更高[你可以查看张贴在帖子中的结果]#2.我在这里发布了我的问题后，在ORC工作。它比拼花地板占用更少的空间，652MB，占用更少的时间。我将编辑我的问题，并将从兽人表中获得完整的结果。只是出于好奇，我找不到一篇讨论拼花地板和兽人并驾齐驱的好论文。您是否有任何文档可以根据用例比较这两种文件格式？另外，我在这里使用的表没有那么宽，有12-15列。拼花地板是一个好的选择吗？丑陋的事实是Cloudera正在推动拼花+黑斑羚，而HortonWorks正在推动兽人+蜂巢。大量的市场营销和政治参与。。。但是也有一些与格式无关的工具，比如Presto（注意：perf可能会随着新版本和配置调整而发生巨大变化），令我惊讶的是它花费了您这么多时间。你用的是什么硬件？并且总是为基准发布代码。