Hadoop中连接(join)操作很常见,Hadoop“连接”的概念本身,和SQL的“连接”是一致的。SQL的连接,在维基百科中已经说得非常清楚。比如dataset A是关于用户个人信息的,key是用户id,value是用户姓名等等个人信息;dataset B是关于用户交易记录的,key是用户id,value是用户的交易历史等信息。我们当然可以对这两者以共同键用户id为基准来连接两边的数据。
首先,在一切开始之前,先确定真的需要使用Hadoop的连接操作吗?
如果要把两个数据集合放到一起操作,Hadoop还提供了Side Data Distribution(data sharing)的方式,这种方式对于小数据量的情况下效率要高得多,说白了就是把某些数据缓存到本地,例如在本地内存中,直接操作执行,具体包括两种子方式:
- 使用Job Configuration传递;
- 使用Distributed Cache。
当数据量比较大时,是不适合采用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的类型。