查找每个键的最小值，从而导致效率问题

Question

我有一个非常大的表CLAIMS，包含以下列:

p_key
c_key
claim_type

每一行由p_key, c_key唯一定义。通常每个p_key对应多个c_key。这个表看起来像这样:

p_key  c_key  claim_type
1      1      A
1      2      A
2      3      B
2      5      C
3      1      B 

我想找到每个p_key的最小c_key值。这是我的查询:

SELECT p_key, 
min(c_key) as min_ckey
from CLAIMS
GROUP BY p_key

问题是，当我通过HIVE CLI(0.13)将其作为mapreduce作业运行时，reduce部分甚至需要30分钟才能完成5%。我不完全确定是什么原因导致一个简单的查询要花这么长时间。这个查询给出了相同的问题:

SELECT p_key, 
row_number() OVER(PARTITION BY p_key ORDER BY c_key) as RowNum
from CLAIMS

所以我的问题是为什么一个看似简单的mapreduce任务的reduce部分要花这么长时间?任何关于如何调查/改进查询的建议也将受到赞赏。

Answer 1

你知道数据是否不平衡吗?如果有一个p_key的c_key值与平均情况相比非常多，那么处理该p_key的reducer将花费非常长的时间。

或者，一般情况下p_key值是否很少?由于您按p_key分组，这将限制执行有用工作的reducer的数量。

Answer 2

reduce阶段分为三个阶段。当<=33%为shuffle, 33% ~ 66%为sort，>= 67%为reduce阶段。

你的工作听起来像是在reduce阶段的shuffle部分被挂断了。我猜你的数据是分散的，这部分是IO绑定的。

你可以试着把你的数据存储起来:

create table claim_bucket (p_key string, c_key string, claim_type string) 
 clustered by (p_key) into 6 buckets 
 row format delimited fields terminated by ",";

您可能需要更多或更少的桶，这将需要hive最初的一些繁重的工作，但应该加快随后对使用p_key的表的查询。

当然，你在这里没有留下太多其他的东西。如果你编辑并提供更多信息，你可能会得到更好的答案。好运。