我有一个pig脚本,它有一个来自两个不同数据源的内部连接。这个连接恰好是第一个导致Map减少的操作。在手之前唯一的操作就是过滤器和foreachs。当这个连接被执行的时候,所有的东西都完美而快速地进入了Map阶段,但是当它进入reduce阶段时,除了1之外,所有的reducer都很快完成了。然而,1只是坐在那里,在减少阶段的一部分,在一个非常缓慢的步伐,在数据上颠簸。以至于它可能需要一个小时+只是等待1减速机完成。我尝试过增加减速器以及切换到斜联接,但似乎没有任何帮助。
有什么好主意吗。
我也做了一个解释,看看我能看到什么,但这只是显示了一个简单的单一工作流程,没有什么惊人的。
1条答案
按热度按时间dgenwo3n1#
很可能发生的事情是一个单一的关键有大量的示例在双方和它的爆炸。
例如,如果您加入:
... 你会得到12双鞋
x
! 所以你可以想象,如果一个密钥有1000个,而另一个数据集中有2000个相同的密钥,那么从这2000行就可以得到200万对。不幸的是,单减速器在这次爆炸中首当其冲。添加减速机或使用倾斜连接在这里是没有帮助的,因为在一天结束时,一个减速机需要处理这一对大爆炸。
以下是一些需要检查的事项:
听起来只有一个join键导致了这个问题,因为只有一个reducer被锤击。罪魁祸首是
NULL
. 其中一个中的列是否可以为空?如果是这样的话,它会爆炸的!尝试过滤掉NULL
上外键前先把两个关系跑一遍,看看有没有区别。或者,代替null。。。也许您有某种默认值,或者有一个值经常出现。试着弄清楚每把钥匙到底有多少把,弄清楚爆炸会是什么样子。类似于(警告:我实际上并没有测试这段代码,希望它能工作):
同样,它可能与爆炸无关。你的一个亲戚可能很多时候只有一把钥匙。例如,在wordcount示例中,以单词“the”结尾的reducer要比以“zebra”结尾的reducer要做更多的计数。我不认为是这种情况,因为只有一个减速机被锤打,这就是为什么我认为#1可能是这种情况。
如果你有很多钥匙,那就是原因。你也知道是什么钥匙导致了这个问题。