我们正在测试 Apache Impala,并注意到同时使用 GROUP BY 和 LIKE 的速度非常慢——单独的查询速度要快得多。这里有两个例子:
# 1.37s 1.08s 1.35s
SELECT * FROM hive.default.pcopy1B where
(lower("by") like '%part%' and lower("by") like '%and%' and lower("by") like '%the%')
or (lower(title) like '%part%' and lower(title) like '%and%' and lower(title) like '%the%')
or (lower(url) like '%part%' and lower(url) like '%and%' and lower(url) like '%the%')
or (lower(text) like '%part%' and lower(text) like '%and%' and lower(text) like '%the%')
limit 100;
# 156.64s 155.63s
select "by", type, ranking, count(*) from pcopy where
(lower("by") like '%part%' and lower("by") like '%and%' and lower("by") like '%the%')
or (lower(title) like '%part%' and lower(title) like '%and%' and lower(title) like '%the%')
or (lower(url) like '%part%' and lower(url) like '%and%' and lower(url) like '%the%')
or (lower(text) like '%part%' and lower(text) like '%and%' and lower(text) like '%the%')
group by "by", type, ranking
order by 4 desc limit 10;
为什么会出现此问题,是否有任何解决方法?
最佳答案
两个查询之间有一个基本的区别。
第一次查询
要点:
- 只选择了 100 行。
- 一旦流程获得满足提供的
WHERE
子句的 100 行,它就会被标记为已完成并返回 100 条记录。 - 只有 1 个映射器步骤。映射器的数量将取决于您的数据大小。
第二次查询
要点:
- 只选择了 10 行。
- 即使只选择了 10 行,该过程也需要扫描完整数据才能根据
GROUP BY
子句生成结果。 - 应该有 3 个 mapper-reducer 步骤。每一步的 mapper-reducer 数量将取决于数据大小。
- 第一个 MP 将读取数据并应用
WHERE
子句 - 第二个 MR 将用于
GROUP BY
子句。 - 第三个 MR 将用于
ORDER BY
子句。
- 第一个 MP 将读取数据并应用
所以您提供的查询可能看起来很相似,但它们完全不同,并且一起解决了不同的目的。
关于performance - 使用 Group By 和 Like 的 Impala 查询性能低下,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42169960/