尝试连接 6 个表，每个表中大约有 500 万行。尝试加入在所有表格上按升序排序的帐号。Map 任务成功完成，reducers 停止工作的比例为 66.68%。尝试了增加减速器数量等选项，还尝试了其他选项 set hive.auto.convert.join = true; 并设置 hive.hashtable.max.memory.usage = 0.9; 并设置 hive.smalltable.filesize = 25000000L; 但结果是一样的。尝试使用少量记录（如 5000 行），查询效果非常好。
请建议在这里可以做些什么来使它工作。
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 中避免的一般良好做法。在多对多关系之间进行多个内部连接会给您带来很多麻烦。
对于现在和将来的调试，您可以使用 JobTracker 来查找和检查有问题的 Reducer 的日志。然后，您可以检测 reduce 操作以更好地处理正在发生的事情。小心你当然不要用伐木把它炸毁！例如，尝试查看输入到 reduce 操作的记录数。