一文读懂大数据量组合数据集在永洪的应用实例

作者: 永洪BI  来源: 永洪科技  时间:2020年01月07日

我们知道数据分析的第一步是准备数据,所以在前面的课程里,我们介绍了元数据(Yonghong BI课程系列之概念:元数据),今天这篇文章,主要介绍大数据量组合数据集在永洪中的应用实例:Mapsidejoin。

什么是Mapsidejoin?按照字面意思,Mapsidejoin就是M—节点—组合 。在了解Mapsidejoin之前,首先我们要了解一下MapReduce模型以及产品的四个节点CNMR的作用,通过MapReduce模型中,Mapsidejoin和Reducesidejoin的对比,了解在大数据量数据集进行组合时,Mapsidejoin的优点。


Yonghong中集群节点介绍

Client Node —C节点是客户端访问节点,客户通过访问C节点来提交任务。

Naming Node —N节点相当于集群的大脑,除了监控集群其他节点外,还要收集客户通过C节点提交的任务进行分配等等。

Map Node — M节点是存储数据文件的节点

Reduce Node —R节点是用来做汇总计算的计算


MapReduce模型介绍

百度百科对MapReduce的定义感觉还是比较全面的,简单的概括一下:MapReduce是一个基于集群的计算平台,是一个简化分布式编程的计算框架,是一个将分布式计算抽象为Map和Reduce两个阶段的编程模型。而Yonghong在进行组合数据集计算时用到的就是MapReduce模型。

适用场景:多M节点的分布式集群,大数据量数据的组合包括大表join小表,大表join大表。

1、为什么要使用Mapsidejoin

在MapReduce模型中,对于组合计算可以分为Map-side-join 和Reduce-side-join两种,下面用一个例子简单介绍一下:

假设我们有两张表:表1人员表为大表,表2地区表为小表,如下图所示: 

我们想通过id把表1的name和表2的Address连接起来 ,那么就需要以id为连接列,做inner join, 连接对应的id为id=1,id=2,id=3,id=4。

假如现在我们的集群里面有Map1和Map2两个Map节点,那么当我们将表1和表2入集市以后,经过数据的拆分存储,我们可能会出现以下情况:

► 情况1:可以进行Mapsidejoin

如上图所示,经过拆分后的表1和表2,连接列id=1-4 对应的数据存放在了同一个节点,在join时,Map节点会检测连接列数据是否已经完成对应,如果此时数据对应后就可以在Map节点上进行join,Map节点将join后的结果发送给Reduce节点,Reduce节点将结果进行汇总计算就可以了。

► 情况2:不能进行Mapsidejoin时会进行Reducesidejoin

上图所示, 经过拆分存储后的数据显示表1的id1,2存放在了Map1节点;而表2的id1,2 存放在了Map2 节点上面;这个时候在join时Map节点检测到对应的数据不在同一个节点上,就会将所有的数据拿到Reduce节点重新进行全量的join。

以上两种情况简单的说明了Mapsidejoin 和 Reducesidejoin。

2、Mapsidejoin和Reducesidejoin的优点
  • Map端join的好处是可以提前过滤掉join中需要排除的大量数据,会减少数据的传输,因此Mapsidejoin 适用于大数据量join的场景。

  • Reduce端做join优点是比较灵活,缺点是需要做大量数据传输和整个join过程都比较耗时,因此Reducesidejoin适用于小数据量的场景。

此外, 由于当数据量巨大时,做join是非常消耗资源的,对于非Mapsidejoin的形式,无论是直连数据库压到数据库做join,还是数据集市的形式去做Reducesidejoin,都会对节点造成极大压力,容易造成产品很卡的情况,再严重就会造成OOM,宕机等。所以我们需要使用Mapsidejoin来规避这种场景, 当数据量大的时候,我们可以部署多个M节点,通过将数据先导入集市,存放在集群中的多个M节点,然后在M节点上面进行计算来实现Mapsidejoin,这样能把C,R节点的压力平均分到M节点上面,解决大数据量join可能带来的使用压力,让资源的利用更加高效。

那么我们怎么实现Mapsidejoin呢 ?如何保证数据经过拆分后,连接列对应的数据一定存放在同一个Map节点上面呢?下面介绍永洪Mapsidejoin的两种实现方式。


永洪Mapsidejoin的两种形式

事实表——维度表

适用场景(大表join小表)

在分布式系统中,当有星形数据(一个大表,若干个小表)需要join的时候,可以将小表的数据复制到每个Map节点,执行Mapsidejoin, 而无须到Reduce节点进行连接操作,从而提升表连接的效率。

在MPP集市中,我们将大表以普通的增量导入形式入集市,将所有小表在增量导入时勾选维度表的形式,如下图所示:

此时勾选维度表的小表会全量生成在每一个Map节点。

以上面表1人员表,表2地区表的为例:表1增量导入正常拆分,表2以增量导入维度表形式入集市。

如图所示,此时在每一个M节点上,因为表2全量存储,所以表1和表2对应的id数据就一定能在同一个M节点找到。

但是事实表——维度表的形式也有局限性,比如两个以上的大表做join时,就需要将其中的一个或多个大表,存放到每一个M节点上,大数据量的大表进行维度表存储本来就会加大资源消耗,而且大表作为维度表,无法压到内存中进行计算,因此无法使用Mapsidejoin。

所以针对这种情况,我们采取分片列来支持大表join大表的使用场景。

分片列         

适用场景(大表join大表)

在8.5.1版本之前,我们只能用维度表join事实表的形式去做Mapsidejoin,在一些用户场景中,无法提前进行数据表关联做成宽表模型入集市,同时也不满足Mapsidejoin(或broadcast join)计算的要求,因此需要在集市中做分布式join的计算支持。

具体场景有:

1)业务上需要,比如:部分汇总后再进行关联,某时间段内产品销售额大于特定值时的产品报修批次分布;特定值进行关联,选择某个时间段里面最后出现的数据和另外的表关联;自关联,本月数据和上月数据关联计算等等;这些场景下(一般是雪花模型或更复杂)如果提前join会导致数据膨胀,从而产生非常多的冗余数据,但实际使用时因为有过滤条件则不会产生太多数据;

2)数据量较大的事实表需要频繁增量更新,且全量数据join成宽表入集市的时间开销太大;

3)自服务场景下,是否要关联表,以及关联什么字段存在不确定性,需要保留原始细节表来进行自助查询。

分片列的Mapsidejoin实现逻辑其实和上面情况1的图片类似。

我们通过增量导入分片列的形式将表1和表2的关联列使用hash算法,保证两张表的id对应的数据经过拆分后一定会存储在同一个Map节点上面,这样经过拆分的大表就可以压到内存中计算。

操作步骤:

1、将需要组合的大表以增量导入的形式入集市,同时需要勾选分片列属性,选择分片列为链接列。比如表1在增量导入集市时要勾选分片列为id ,表2也需要同样的操作。

2、将生成的数据集市数据集进行组合,Map节点在检测数据时会自动使用Mapsidejoin形式连接。

小结

一定要记住使用Mapsidejoin的前提是分布式集群多M节点且大数据量数据集市的数据集做join。

最后我们用一张图片来简单的回顾一下Mapsidejoin的两种形式。

大表jion大表用分片列

大表join小表用事实表——维度表

 

版权声明

 

永洪BI
更敏捷、更快速、更强大

申请试用
Copyright © 2012-2020 北京永洪商智科技有限公司
京ICP备12050607号 京公网安备110110802011451号