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

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

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

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

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

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

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

在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。

• 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的两种实现方式。

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

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

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

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

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

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

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

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

具体场景有：

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

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

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

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

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

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

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