运行 HIVE 连接查询时，减速器在 66.68% 处停止工作答案

【问题标题】：Reducers stopped working at 66.68% while running HIVE Join query运行 HIVE 连接查询时，减速器在 66.68% 处停止工作
【发布时间】：2013-05-02 16:01:09
【问题描述】：

尝试连接 6 个表，每个表中大约有 500 万行。尝试加入在所有表格上按升序排序的帐号。 Map 任务成功完成，reducers 停止工作的比例为 66.68%。尝试了增加减速器数量等选项，还尝试了其他选项 set hive.auto.convert.join = true;并设置 hive.hashtable.max.memory.usage = 0.9;并设置 hive.smalltable.filesize = 25000000L;但结果是一样的。尝试使用少量记录（如 5000 行），查询效果非常好。

请建议在这里可以做些什么来使它发挥作用。

【问题讨论】：

您是否有任何帐号在表中具有不成比例的大量记录。表是否在连接之前排序 - 这样您就可以利用 map-side 连接？）。其中一个表是否比其他表大很多（连接中最后列出的那个大表？）

标签： join hadoop mapreduce hive

【解决方案1】：

66% 的 reducer 开始执行实际的 reduce（0-33% 是 shuffle，33-66% 是 sort）。在与 hive 的连接中，reducer 在两个数据集之间执行笛卡尔积。

我猜测至少有一个外键经常出现在所有数据集中。注意 NULL 和默认值。

例如，在连接中，假设键“abc”在六个表中的每个表中出现十次 (10^6)。那是那个键的一百万条输出记录。如果“abc”在一个表中出现 1000 次，在另一个表中出现 1000 次，在另一个表中出现 1000 次，然后在其他三个表中出现两次，您将获得 80 亿条记录 (1000^3 * 2^3)。你可以看到这是如何失控的。我猜至少有一个键会导致大量的输出记录。

这也是在 Hive 之外的 RDBMS 中避免的一般良好做法。在多对多关系之间进行多个内部连接会给您带来很多麻烦。

【讨论】：

【解决方案2】：

为了现在和将来的调试，您可以使用 JobTracker 来查找和检查有问题的 Reducer 的日志。然后，您可以检测 reduce 操作以更好地处理正在发生的事情。小心你当然不要用伐木把它炸毁！例如，尝试查看输入到 reduce 操作的记录数。

【讨论】：

感谢大家的快速回复。无论如何知道连接只发生在地图一侧吗？来自日志或任何其他方式？
我们将连接分成 2 个单独的连接（连接第 3 个和最后 3 个表），输出在第 3 个连接中连接。效果很好！！！
对于地图侧连接：作业日志通常会显示它是否自动执行此操作。我认为它需要较小的数据集——几千条记录——因为它将通过分布式缓存将数据分发给任务。