Hadoop的Map-sidejoin和Reduce-sidejoin

Hadoop中连接（join）操作很常见，Hadoop“连接”的概念本身，和SQL的“连接”是一致的。SQL的连接，在维基百科中已经说得非常清楚。比如dataset A是关于用户个人信息的，key是用户id，value是用户姓名等等个人信息；dataset B是关于用户交易记录的，key是用

Hadoop中连接（join）操作很常见，Hadoop“连接”的概念本身，和SQL的“连接”是一致的。SQL的连接，在维基百科中已经说得非常清楚。比如dataset A是关于用户个人信息的，key是用户id，value是用户姓名等等个人信息；dataset B是关于用户交易记录的，key是用户id，value是用户的交易历史等信息。我们当然可以对这两者以共同键用户id为基准来连接两边的数据。

首先，在一切开始之前，先确定真的需要使用Hadoop的连接操作吗？

如果要把两个数据集合放到一起操作，Hadoop还提供了Side Data Distribution（data sharing）的方式，这种方式对于小数据量的情况下效率要高得多，说白了就是把某些数据缓存到本地，例如在本地内存中，直接操作执行，具体包括两种子方式：

当数据量比较大时，是不适合采用Side Data Distribution的，这时候就需要考虑Join了。

Map-side Join

Map-side Join会将数据从不同的dataset中取出，连接起来并放到相应的某个Mapper中处理，因此key相同的数据肯定会在同一个Mapper里面一起得到处理的。如果Mapper前dataset中的数据是无序的，那么对于dataset A的任意一个key，要到其它的dataset中寻找该key对应的数据，造成的复杂度是n的x次方，x等于dataset的个数。因此要求dataset是有序的，这样每个对于任何一个Mapper来说，每一个dataset都只需要遍历一次就可以取到所有需要的数据。Map-side Join对dataset的限制很多，进入不仅仅是有序，不同的dataset中数据的partition方式也要一致，其实最终目的就是保证同样key的数据同时进入一个Mapper。

Reduce-side Join

Reduce-side Join原理上要简单得多，它也不能保证相同key但分散在不同dataset中的数据能够进入同一个Mapper，整个数据集合的排序在Mapper之后的shuffle过程中完成。相对于Map-side Join，它不需要每个Mapper都去读取所有的dataset，这是好处，但也有坏处，即这样一来Mapper之后需要排序的数据集合会非常大，因此shuffle阶段的效率要低于Map-side Join。如果希望在shuffle之后，进入Reducer的时候，value列表是有序的，那么就需要使用Hadoop的Secondary Sort（移步此文）。

不管使用Map-side Join还是Reduce-side Join，都要求进行Join的数据满足某一抽象，这个抽象类型即为进入Mapper或者Reducer的input key的类型。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接《四火的唠叨》

你可能也喜欢：