posts - 82, comments - 269, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

 

Hadoop的几种Join方法

1)      Reduce阶段进行Join,这样运算量比较小.(这个适合被Join的数据比较小的情况下.)

2)      压缩字段,对数据预处理,过滤不需要的字段.

3)      最后一步就是在Mapper阶段过滤,这个就是Bloom Filter的用武之地了.也就是需要详细说明的地方.

 

下面就拿一个我们大家都熟悉的场景来说明这个问题: 找出上个月动感地带的客户资费的使用情况,包括接入和拨出.

(这个只是我臆想出来的例子,根据实际的DB数据存储结构,在这个场景下肯定有更好的解决方案,大家不要太较真哦)

这个时候的两个个数据集都是比较大的,这两个数据集分别是:上个月的通话记录,动感地带的手机号码列表.

 

比较直接的处理方法有2:

1) Reduce 阶段,通过动感地带号码来过滤.

                优点:这样需要处理的数据相对比较少,这个也是比较常用的方法.

                缺点:很多数据在Mapper阶段花了老鼻子力气汇总了,还通过网络ShuffleReduce节点,结果到这个阶段给过滤了.

 

2) Mapper 阶段时,通过动感地带号码来过滤数据.

                优点:这样可以过滤很多不是动感地带的数据,比如神州行,全球通.这些过滤的数据就可以节省很多网络带宽了.

                缺点:就是动感地带的号码不是小数目,如果这样处理就需要把这个大块头复制到所有的Mapper节点,甚至是Distributed Cache.(Bloom Filter就是用来解决这个问题的)

 

 

Bloom Filter就是用来解决上面方法2的缺点的.

方法2的缺点就是大量的数据需要在多个节点复制.Bloom Filter通过多个Hash算法, 把这个号码列表压缩到了一个Bitmap里面. 通过允许一定的错误率来换空间, 这个和我们平时经常提到的时间和空间的互换类似.详细情况可以参考:

http://blog.csdn.net/jiaomeng/article/details/1495500

但是这个算法也是有缺陷的,就是会把很多神州行,全球通之类的号码当成动感地带.但在这个场景中,这根本不是问题.因为这个算法只是过滤一些号码,漏网之鱼会在Reduce阶段进行精确匹配时顾虑掉.

这个方法改进之后基本上完全回避了方法2的缺点:

1)      没有大量的动感地带号码发送到所有的Mapper节点.

2)      很多非动感地带号码在Mapper阶段就过滤了(虽然不是100%),避免了网络带宽的开销及延时.

 

继续需要学习的地方:Bitmap的大小, Hash函数的多少, 以及存储的数据的多少. 3个变量如何取值才能才能在存储空间与错误率之间取得一个平衡.


 


只有注册用户登录后才能发表评论。


网站导航: