Hive 压缩数据，按数据聚类和按数据排序性能

Question

我有几个关于 Hive 性能的问题。

我在网上看到压缩数据（ORC，特别是 Snappy）在读取数据方面会带来更好的性能。
此外，如果我使用 order by 将我的数据加载到 table，这将导致 1 个大文件，这可能会降低读取可用性。
因此，另一种实现与order by相同效果的方法是使用cluster by，它会创建多个小文件。

我做了一个关于压缩数据的实验，按数据聚类和按数据排序以查看它们的性能。
目前，我有 5 个数据节点和 1 个名称节点。每个 table 中加载的数据文件约为 19GB+（超过 200 万条记录）

我使用以下查询创建了我的 orc snappy 压缩 table：

CREATE EXTERNAL TABLE orc_t (....)
STORED AS ORC
LOCATION '...'
TBLPROPERTIES(orc.compress="SNAPPY")

看到每个table的表现，我很迷茫，很迷茫。我运行的查询是：

SELECT * FROM orc_t WHERE date_format(st_time, 'yyyy-MM-dd') = '2017-05-20'

压缩数据耗时 2 分钟 45 秒
按数据聚类花费了 43 秒
按数据排序 43 秒

似乎压缩数据花费的时间最长，而且按数据聚类似乎没有比按数据排序有显着的性能。

会不会是我的5个数据节点读取能力不够，解压反而降低了性能？
还是我的样本数据不够大？
我错过了什么吗？

请问有哪位高手能给我解答一下吗？

Answer 1

Why multiple small data files (size of around 256MB) does not have significant performance over a single large data file (size of around 19GB+) when I perform the sample query (SELECT * FROM t WHERE date_format(st_time, 'yyyy-MM-dd') = '2017-05-20';

您仍在扫描所有数据以查找数据中的单个值。因此必须全部解压。您还选择了所有列，因此使用 ORC 没有明显的好处。

Shouldn't the multiple small data files have some performance edge over the single large data file?

应该，但如果不是这种情况，则可能是初始输入文件能够适当地分块到 mapreduce 输入拆分中，并且磁盘 IO 不是阻塞因素。

Snappy 或 Zlib 压缩只会为您节省 space，不会优化速度。

如果您想提高速度，请根据您将经常使用的查询模式对数据进行分区

Hive 压缩数据，按数据聚类和按数据排序性能

Hive compressed data, cluster by data and order by data performance

performance

hadoop

hive

hiveql