我有一个看起来无害的Hive查询,该查询从一个表中获取一些数据以覆盖到另一个表中。源表和目标表都已分区。目标表也被群集。
该查询产生了4个MR作业,而最后一个在还原阶段总是花费异常大量的时间。我尝试增加 reducer 的数量,但这没有帮助。从更深的 Angular 看,我注意到指定的130个 reducer 中有1个(最初是默认的26个 reducer 中的1个)似乎总是比其余的接收更多的数据。我进一步尝试在具有良好分布的列上使用distribute子句,但这也无济于事。
有什么办法可以弄清大多数数据似乎归到一个 reducer 的原因是什么?另外,关于如何控制此数据量的任何建议都将非常有帮助。
我的代码(表名和列名已更改)。
目标分区在l和m列上
目标由user_id聚集
set hive.enforce.bucketing = true;
set mapred.reduce.tasks=130;
insert overwrite table dest_table
select
coalesce(event_guid, "<UNKNOWN>") event_guid,
coalesce(a, "<UNKNOWN>"),
coalesce(b, "<UNKNOWN>"),
coalesce(user_id, "<UNKNOWN>"),
coalesce(c, "<UNKNOWN>"),
coalesce(d, "<UNKNOWN>"),
coalesce(e, "<UNKNOWN>"),
coalesce(f, "<UNKNOWN>"),
coalesce(g, "<UNKNOWN>"),
coalesce(h, "<UNKNOWN>"),
coalesce(i, "<UNKNOWN>"),
coalesce(j, "<UNKNOWN>"),
coalesce(k, "<UNKNOWN>"),
coalesce(l, "<UNKNOWN>"),
coalesce(m, "<UNKNOWN>"),
coalesce(n, "<UNKNOWN>"),
coalesce(o, "<UNKNOWN>"),
coalesce(p, "<UNKNOWN>"),
coalesce(q, "<UNKNOWN>"),
coalesce(r, "<UNKNOWN>"),
coalesce(to_date(from_utc_timestamp(s, "PST")), "0000-00-00"),
coalesce(cast(from_utc_timestamp(s, "PST") as string), '0000-00-00 00:00:00'),
coalesce(s, '0000-00-00 00:00:00'),
coalesce(t, '0000-00-00 00:00:00'),
coalesce(u, '0000-00-00 00:00:00'),
coalesce(cast(from_utc_timestamp(t, "PST") as string), '0000-00-00 00:00:00'),
coalesce(cast(from_utc_timestamp(u, "PST") as string), '0000-00-00 00:00:00'),
coalesce(to_date(from_utc_timestamp(u, "PST")), "0000-00-00"),
coalesce(v, "<UNKNOWN>"),
coalesce(w, "<UNKNOWN>"),
coalesce(x, "<UNKNOWN>")
from
source raw
where v is not null and w is not null and x is not null
distribute by event_guid
;
最佳答案
这只是一个建议,但是您可以在 hive 中使用TRANSFORM或MAP / REDUCE关键字尝试自己的映射器和化简器脚本来控制数据。例如选择键作为给出均匀分布的列(这是您尝试使用distribution by实现的目的)
可能需要做一些HQL分析。在event_guid上运行group by count(*)。计数是否均匀分布?
关于hadoop - reducer 的数据分配不均,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27040243/