尝试连接6个表，每个表大约有500万行。尝试加入帐户号码，该帐号在所有表格中按升序排序。地图任务成功完成，减速机停止工作在66.68％。尝试增加减少数量的选项，并尝试其他选项设置hive.auto.convert.join = true;并设置hive.hashtable.max.memory.usage = 0.9;并设置hive.smalltable.filesize = 25000000L;但结果是一样的。尝试少量记录（如5000行），查询工作得很好。
请建议可以在此处完成的工作。
答案 0 :(得分：11)
66％的减速器开始实际减少（0-33％是洗牌，33-66％是排序）。在与hive的连接中，reducer在两个数据集之间执行笛卡尔积。
我猜测在所有数据集中至少有一个外键频繁出现。注意NULL和默认值。
例如，在连接中，假设键“abc”在六个表（10 ^ 6）的每一个中出现十次。这是一个密钥的百万输出记录。如果“abc”在一个表中出现1000次，在另一个表中出现1000次，在另一个表中出现1000次，那么在其他三个表中出现两次，则得到80亿条记录（1000 ^ 3 * 2 ^ 3）。你可以看到这是如何失控的。我猜测至少有一个密钥会产生大量的输出记录。
这也是在Hive之外的RDBMS中避免的一般良好做法。在多对多关系之间进行多次内部联接可能会给您带来很多麻烦。
答案 1 :(得分：0)
现在进行调试，将来可以使用JobTracker查找和检查有问题的Reducer的日志。然后，您可以检测reduce操作，以便更好地处理正在发生的事情。小心你当然不要用日志记录它！ 例如，尝试查看输入到reduce操作的记录数。