Question

我有一些关于Hive性能的问题。

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

我做了一个关于压缩数据的实验，按数据聚类，按数据排序，看他们的表现目前，我有5个数据节点和1个名称节点。加载到每个表中的数据文件大约是19GB +（200万+记录）

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

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

当我看到每张桌子的表现时，我非常迷茫和迷茫。我跑的查询是：

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

压缩数据耗时2m 45秒
按数据分组需要43秒
按数据排序43秒

似乎压缩数据花费的时间最长，数据群集似乎没有比数据排序显着的性能。

可能是我的5个数据节点有足够的读取能力，解压缩实际上会降低性能吗？或者我的样本数据不够大？
我错过了什么吗？

有没有专家请赐教我上面的内容？

Answer 1

当我执行示例查询时，为什么多个小数据文件（大小约为256MB）在单个大型数据文件（大小约为19GB +）上没有显着的性能（SELECT * FROM t WHERE date_format（st_time，＆＃39） ; yyyy-MM-dd＆＃39;）=＆＃39; 2017-05-20＆＃39;;

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

多个小型数据文件不应该比单个大型数据文件具有一些性能优势吗？

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

Snappy或Zlib压缩只会节省空间，而不是为了速度而优化。

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

Hive压缩数据，按数据分组并按数据性能排序

1 个答案: