一种基于MapReduce模型的提升表连接效率的方法与流程

文档序号:14714143发布日期:2018-06-16 01:00阅读:156来源:国知局
一种基于MapReduce模型的提升表连接效率的方法与流程

本发明属于计算机应用领域,涉及Hadoop平台中的MapReduce框架,涉及MapReduce 框架中关于大数据表连接任务的执行算法,具体涉及两表和多表两种情况下的数据表连接执 行方法。



背景技术:

近几年,随着人民生活水平的提高,互联网越来越普及,微博、微信等与互联网相 关应用的用户越来越多,并且物联网、智慧城市等技术的蓬勃发展,由此产生的数据正在飞 速的增长着,大数据时代已经全面来临。根据相关机构的预测,2020年的全球数据总量将会 达到40ZB。根据社交网络公司Facebook的统计,该社交平台每天会产生500TB的数据,而 阿里巴巴的一个事业部现在就已经存储了100PB的数据。为了能够高效且低成本的分析和挖 掘庞大数据潜在的价值,很多公司选择将数据存放到成本低、容错率高的分布式计算集群中 分析处理。

在2004年谷歌公司提出了MapReduce计算模型和GFS[26]分布式文件系统。这套数 据存储与处理系统,它的水平扩展性优良,因此可以兼容很多廉价的硬件设备,并且容错性 能好,大大降低了因为个别节点任务失败而导致整个任务失败的概率,其中MapReduce编程 模型通过向编程人员提供Map函数接口和Reduce函数接口这种方式,对使用者隐藏了底层 的并行控制操作,极大的方便了编程人员的开发过程,缩短了开发周期[27]。正是因为上述 的这些优点,以MapReduce为并行编程模型的数据处理系统逐渐成为了处理大数据的主流系 统。在这一章中,首先对即将要用到的Hadoop平台中的MapReduce和HDFS这两个核心模 块进行概述,之后针对已有的一些关于MapReduce框架的连接进行了分析与描述,并对基于 Reudce端的两表连接和单次任务完成的多表连接在执行过程中存在的不足进行了分析。

查询是数据处理的基本操作,而连接在查询操作中使用频率是最高的,因此数据表 的连接操作将会是MapReduce框架中的研究热点。然而MapReduce框架分布式的计算特点, 使其在处理连接操作时有诸多局限性,在多表连接的情况下效率更是低下。

对于两表连接而言,在MapReduce模型中原本使用的是Reduce Side Join算法,虽 然RSJ算法确实是要比传统的数据库技术在执行效率方面提高不少。但是就RSJ算法的执行 过程而言,仍然有着很大的改进空间。虽然在Map阶段,主节点对于任务的分发充分考虑了 数据移动不如算法移动的原则,尽量将Map任务分配到数据所在节点,避免不必要的网络传 输。但是,数据在Reduce阶段却不得不进行网络传输,由于数据表的连接就是将连接键相同 的元组合并输出,而当初录入的数据并不能保证每个数据分片的连接键都是相同的,因此在 混洗分区的时候不可避免的需要进行网络传输才能使连接键相同的元组被分入同一个Reduce 节点。

除了不可避免的网络传输,数据表中的数据也存在着“冗余”的情况,也就是说并 不是每一条元组都有来自另一张表key值相同的元组与之连接,也就不会出现在最后的结果 当中,但是这样的元组同样需要进行网络传输。在示例中,满足连接条件的元组,即来自不 同文件且连接键(Cu_id值)相同的元组。只有Cus_id为1和2的元组,同时出现在了两个 表中,因此连接操作只是针对这些元组进行。id为3的元组并不满足此次的连接任务需求, 虽然同样经过了网络传输等步骤,但是仍然是一组“无用”的数据。在示例中冗余的元组仅 仅只有一条,但是在实际的情况下,在海量数据中这样的数据占着很大的比例,他们会占用 大量I/O和网络带宽资源,降低了算法的效率。

对于多表连接而言,可以发现算法中存在以下两个方面的局限性。

(一)在链式多表连接中每完成一个MapReduce任务,都要将中间结果写入HDFS, 供下一个MapReduce任务进行读取。由此可以分析出,当待连接的数据表很多时,会导致产 生大量的中间结果,最终会给I/O和网络传输带来巨大的开销。

(二)链式多表连接处理连接任务时,需要顺序处理执行多个MapReduce任务,下 一个任务的部分数据依赖自上一个任务的输出结果,因此下一个任务需要一直等待上一个任 务完成才能启动,造成了任务等待时,硬件资源的浪费。



技术实现要素:

为了解决上述现有方法的不足,本发明提出了一种基于MapReduce模型的提升表连 接效率的方法,基于共享信息机制和流水线模型提升两表和多表连接的执行效率。

本发明采用的技术方案为一种基于MapReduce模型的提升表连接效率的方法,针对 大数据表连接效率提升问题,由于在MapReduce模型中多表连接是由多个两表连接完成的, 因此采取先对原两表方法进行改进,之后进一步对多表连接进行改进的技术路线。

为了达到改进两表连接的目的,本方法设计了信息共享机制对表的信息进行压缩共 享,通过共享信息对连接表中无效信息进行过滤,提升中间结果在网络中传输的效率,打破 大数据在本地存储时,分片数据信息不全面的瓶颈,从而达到提高整体算法效率的目的。

所述共享信息机制,包含三个功能模块,分别为信息分发模块、信息压缩模块和信 息转型模块。

所述信息分发模块,是利用Hadoop平台中的分布式缓存机制,对主节点中的大小为 几十MB以内的文件向所有从节点进行分发广播。

共享信息机制分为两个步骤:

S1当Hadoop平台分配任务时,通过静态方法DistributedCache.addCacheFile()设置需 要被广播到各个节点的文件。这些文件以URI(Uniform Resource Identifier)对象的形式存放 在分布式文件系统中。当主节点的Job Tracker运行时,自动读取URI配置文件,同时在所有 从节点的TaskTracker中创建指定文件的本地副本。

S2在各个map节点中,当需要使用背景数据时,通过调用DistributedCache.getLocal CacheFiles()获取文件所在路径,之后将“背景”数据读入内存。

所述信息压缩功能,是为了将文件中的连接键信息进行压缩,以便制作成共享信息 通过分布式缓存机制分发给各个从节点,达到信息共享的目的。为了达到这一目的,采用了 Bit-Map算法,对数据进行压缩。该算法是将任意长度的整型数据通过哈希函数映射成一位, 实现压缩数据的效果。

Bit-Map算法的设计思想是用一个bit来代表一个对应元素的value。因为仅仅用了一 个bit来存储,所以在海量数据中,节省大量空间。接下来用一个排序的实例来说明Bit-Map 的具体应用。现有一组0-7之间的数需要进行排序(例:4,7,2,5,3),因为数据的规模固定在 0-7之间,预先开辟一个8位一个字节的内存空间,将每个位都初始化为0。Bit-Map算法的 适用范围针对的是整型数据,数据表中的连接键却未必是整型数据,所以需要将连接键映进 行转型。

所述信息转型功能,是将待压缩的连接键由字符串类型转换成可用于压缩的整型数 据,字符串哈希函数正好可以解决这一问题。哈希函数虽然可用性强,但是冲突率却是每个 函数都存在的,而冲突率的大小直接影响了“背景”数据过滤元组的效果,因此哈希函数的 选取也是非常重要的。为保证算法的高效性和可用性,采用了BKDRHash字符串哈希函数, 用于转换字符串数据。

为了提高原MapReduce框架下的多表连接效率,除应用上述的信息共享机制,针对 多表连接中多个任务顺序执行效率较低的缺点,提出多任务的协调优化机制,用于协调多个 任务的并发执行。

所述多任务协调机制,这个机制是针对多表连接在处理多任务时缺乏并发性而设计。 在该模块的作用下,每个MapReduce任务的执行会参考共享信息的提取和任务的执行情况, 适时的启动下一个MapReduce任务,完成部分前期的数据准备工作,在上一个MapReduce 任务完全执行完毕时,再开始完成剩下的工作,实现提高任务并发性的效果。

不论是启动前的预备操作,还是为了部分输入数据的等待,这些在时间轴上与前一 个任务都是串行的关系。实际上将这部分花费的时间,与上一个任务在时间轴上进行并行, 形成一个流水线的并行模型,而且这些操作并不影响整个任务的流程。

不同的连接顺序对网络传输和I/O的影响还是很显著的,一个合理的连接顺序进一步提 高共享机制的过滤效率。

针对上述情况设计制定了一个表连接顺序选择的策略。

在MapReduce框架下,影响连接顺序主要需要考虑类似于传统连接顺序判定的连接基 数,表示两个表连接后输出结果和和输入数据表的笛卡尔积的比值,比值越大,表示连接基 数越大,说明两个表中相等的元组个数越多,反之则表示两个表中相等的元组个数越小。

虽然连接基数可以准确反映两个表中连接键的一致情况,但是连接基数的应用条件却 是建立在传统数据库的技术条件下,在传统的数据库中,由于数据量较小,所以可以对全局 数据创建索引对数据进行维护和统计,能够很便利的进行连接技术的计算。但是对于海量数 据来说,数据构成复杂、结构各异,不便于信息统计,只能分析处理一些很简单的日志文件, 因此只能得到一些统计信息,当数据存入HDFS时,文件系统中的计数器会对数据中的元组 数进行计数,除此之外也会记录一些基本信息。若是要计算像连接基数这样的数据,则需要 对两个数据表进行详细的对比计数,在大数据中这样的统计代价巨大,而且建立索引对于大 数据也是较为困难的。

所以使用数据属性种类与总元组数的比值来近似代表连接基数。

在规定的连接顺序中,每个表都有一个唯一确定的代表其本身的分布比例值,这个比例值近 似的表示连接基数的概念,比例值越小说明,使用该属性制作的共享有效信息就越少,体现 出的过滤效果也就越好;反之,共享信息越多,过滤掉的元组也就越少。

在实际的大数据平台中,分布比例通过统计近似的得出一个数值,通常有三种途径:1、 设计专门的技术器,用于在数据存储时进行统计计算。2、从概率统计的角度出发,随机采集 有限的样本进行估值。3、在大数据平台中,有专门的系统来估计分布比例大小。根据上述的 分析,现做出如下连接顺序规则:

(一)以不破坏最终的连接结果为原则,且各个表都能按规则连接的情况下,优先处 理分布比例小的表。

(二)当在连接队列的某一个位置同时出现多个比例相同的候选数据表时,此时应比 较表的大小,将数据表较小的进行优先处理。

本发明相对于现有技术,具有以下有益效果:

(一)通过读取表中的数据提取连接属性信息,接着通过Bit-Map算法将其进行压缩, 之后进行合并汇总,得到一个完整的共享信息,再通过分布式缓存机制实现信息的共享,利 用共享信息过滤掉不满足连接条件的数据,以此来减少网络上的数据传输,从而达到优化的 目的。

(二)通过利用任务调度器,协调多个任务并发,合理的利用不同表之间利用Map 机群和Reudce机群运行时间上的空档,提前执行MapReduce任务,增强了系统的并行性。

附图说明

图1为总体框架设计。

图2为两表连接算法示意图。

图3为流水线算法示意图。

图4为整体多表连接算法流程图

具体实施方式

下面结合附图对本发明作进一步描述。

多次执行MapReduce任务带来了冗余的中间结果造成了传输的负担,对冗余数据进 行排序和处理加大了I/O的开销。

除此之外,在顺序执行多个MapReduce任务的过程中,任务与任务之间的数据传输存 在依存关系,且缺少对于多任务的之间的协调控制机制,所以下一个任务需要等到上一个任 务完成时才能启动,然而在每个MapReduce在执行期间,由于存在Map端和Reudce端的任 务转换,在时间和硬件上存在空闲去执行下一个任务的Map端的部分任务。

针对上述传统多表连接存在的局限性,本节提出了一种基于信息共享机制的流水线模 型来优化算法,针对上数据的冗余中间结果和任务的并行性问题进行优化参见图1所示。图 中,在主节点上引入了任务协调模块和共享信息模块,他们与负责提交任务的客户端共同构 成了主节点。

参见图2本发明利用信息共享模块进行两表连接效率的优化,其具体过程分为两个 MapReduce任务,第一个为共享信息制作任务,第二个任务是在传统的RSJ算法执行之前利 用共享信息过滤无用数据。

参见图3,为多表连接流水线算法执行过程,M代表两个数据表在执Map端任务,R 则表示两个数据表在执行Reduce端任务,H表示两表连接的中间结果。当进行多表连接时, 先从待连接表的队列中读取前4张表,两两进行过滤数据表等Map端操作,之后传输到Reduce 机群进行后续操作。

例如,T1与T2交给Reduce1机群,T3与T4交给Reduce2机群。t1时刻Map端完成 对前4张表的处理,并把数据传输给Reduce机群进行连接操作,此时Map端处于空闲状态, 所以再加入两张表T5和T6继续进行Map端的过滤操作。

t2时刻,前4张表两两连接操作以及T5和T6的过滤操作都已经完成,之后将前四张 表的两个中间结果继续放入Reduce2机群进行连接操作,并将处理后的T5和T6传输到 Reduce1机群进行连接操作,与此同时再调入两张表T7和T8进入Map机群进行过滤操作。

在t3时刻,前4张表的中间结果的连接操作以及T5和T6的连接操作都已完成,将它 们的结果继续放入Reduce1机群中继续连接,同时把T7和T8的处理数据放入Reduce2机群 进行连接操作,再将T9和T10放入Map机群。依次类推直到完成所有表的连接。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1