CN102629219A - 并行计算框架中的Reduce端自适应负载均衡方法 - Google Patents
并行计算框架中的Reduce端自适应负载均衡方法 Download PDFInfo
- Publication number
- CN102629219A CN102629219A CN2012100470281A CN201210047028A CN102629219A CN 102629219 A CN102629219 A CN 102629219A CN 2012100470281 A CN2012100470281 A CN 2012100470281A CN 201210047028 A CN201210047028 A CN 201210047028A CN 102629219 A CN102629219 A CN 102629219A
- Authority
- CN
- China
- Prior art keywords
- map
- data
- reduce
- hash function
- bucket
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及一种并行计算框架中的Reduce端自适应负载均衡方法,通过采用动态哈希函数划分方法来预测任务所输入数据的分布,并且根据所预测数据的分布特点产生一个静态哈希函数,使得在该静态哈希函数的作用下,所有数据的分发尽可能均匀地分配到各个计算节点中,进而任务调度能够根据数据分布的情况动态自适应地调整数据和计算资源的分配,减少了运算中出现的偏斜,提高了效率。
Description
技术领域
本发明属于信息技术领域,涉及一种在分布式计算的环境下进行分布式节点负载均衡的方法,特别涉及一种并行计算框架中的Reduce端自适应负载均衡方法。
背景技术
随着数据量的增长以及对数据处理能力需求的增加,传统的并行计算已经不能很好地应对大数据量下的分布式计算。
目前Map-Reduce计算框架通过数据和任务的随机分配以及硬件资源的并行利用,较好地解决大数据量下的分布式计算的任务分配以及调度的问题,但由于Map-Reduce的任务分配依赖于静态哈希函数设定以及并行计算个数的设置,导致分布式计算不够均匀,也不够面对不同数据自适应。我们以Map-Reduce的实现Hadoop系统为例说明上述问题
如图1所示,为传统Map-Reduce架构及流程示意图。其中Hadoop文件系统(简称HDFS,Hadoop File System)负责数据的备份、分布式存取,而Map-Reduce计算框架则根据数据的分布,首先把数据进行Map阶段的处理,每一个Hadoop文件交给一个Map进行处理,输出的记录为key-value对,经过划分之后,同一个key下的所有value都将会进入同一个Reduce中进行处理。Reduce阶段的输出结果会重新被存放到HDFS中。具体流程为:
1、开始运行Job。用户书写Map和Reduce程序,并且把程序作为Job提交运行。
2、Job客户端从Job Tracker获取分配的ID,获得ID才能够获得计算资源。
3、把Job需要的资源复制到HDFS,需要的资源包括程序中可能使用到的代码包或者其他数据。
4、提交Job给Job Tracker,Job Tracker将开始跟踪Job的运行情况。
5、Job的初始化,环境参数设置,计算资源获取等。
6、从HDFS上获取Job需要的所有输入分片(split)。每一个输入文件从逻辑上由多个split构成。
7、任务(Task)开始返回心跳信息。为了跟踪每一个Map或者Reduce任务的运行情况,所有这些任务需要按照一定的周期向Task Tracker和Job Tracker汇报运行状态。
8、Task Tracker开始从HDFS中获取运行资源,开始读取输入。
9、开始运行Map或者Reduce任务。
10、运行Map任务。
11、Map输出数据开始进行划分。
12、运行Reduce任务并把结果写入HDFS。
在这个传统的Map-Reduce运行架构图中,Map输出的数据经过Partition划分函数被分配到Reduce。具体做法是在用户开始运行Map-Reduce任务之前,必须设置好Reduce的个数,此时Partition将会根据key的哈希值对Reduce个数进行取余运算得到一个Reduce端的编号并且把这个key对应的一条记录(即一个key-value对)分配到该编号的Reduce。其中在Map对所有key-value对进行Partition之后首先按照块为单位存放在本地内存或者磁盘中,最后再把这些块通过网络传输或者直接磁盘复制(当Reduce和Map在同一个节点上的时候)的方式发送到对应Reduce所在的节点上,Reduce阶段将会对来自不同Map的数据进行排序(sort)、合并(merge),使得具有相同的key的所有记录能作为Reduce一次计算的输入。Reduce处理结束之后再把所有结果输出到HDFS中。在这个过程中,Map Task Tracker和Reduce Task Tracker分别需要定期到每一个Map和Reduce中收集相关的运行情况反馈信息。
正是由于这种简单的划分方式,当不同的key对应的记录个数分布不均匀或者key对应的value大小也不同的时候,导致了有一些Reduce获得的数据过大,有一些获得的数据过小,导致了偏斜。此外,由于在现实任务中Map输出的数据量和Map输入的数据量不尽相同,用户无法估计Reduce所要处理的数据量而设置合适的Reduce个数,无法自动适应分布不同的数据。
发明内容
本发明的目的在于提供一种并行计算框架中自适应的Reduce端负载均衡方法,解决上述偏斜问题,自动适应分布不同的数据。
本发明的并行计算框架中的Reduce端自适应负载均衡方法,其步骤包括:
1、各Map接收相应Hadoop文件,进行Map处理;
2、将各Map输出的数据采用动态哈希函数划分方法进行分桶保存,其中Map输出的数据中,同一key对应的记录保存在同一桶内;当一桶包含不同key时,其记录个数或占用的存储空间不得超过预先设定的阈值;
3、当各Map的输出达到设定比例后,根据所有Map输出的所有桶的分布情况产生一个静态哈希函数,该静态哈希函数根据桶的个数和桶内的记录个数或占用的存储空间将上述桶划分为若干互不相交的集合,且各个集合之间的均匀程度不得低于一定的阈值;
4、将新的Map输出根据静态哈希函数分配到上述某一集合内,直至所有Map输出的数据均分配至某一集合之中,且每个集合的大小不得超过一定的阈值;
5、将同一集合的数据分配到同一Reduce节点进行Reduce处理。
进一步地,存入某一key对应的Map输出数据的桶的桶号表示为二进制桶号,至少与根据该key的二进制哈希值前几位相同。
进一步地,新的Map输出根据其key的二进制哈希值寻找最接近的桶号,以划分到该桶号所属的集合中。
进一步地,,如果当一桶包含不同key而且其记录个数或占用的存储空间超过预先设定的阈值时,增加一个二进制位以分裂该桶。
所述各Map端的输出达到所有Map输出的预先设置的阈值百分比。
所述动态哈希划分方法为PAL动态哈希划分方法。
所述的各个集合之间均匀程度不得低于一定的阈值为至少70%以上集合的大小之间的差不超过所有集合平均值的20%。
所述的静态哈希函数为针对本次任务所有数据的分布特点的一种静态的划分方法,而且划分成的集合的个数等于所需要Reduce的个数。
所述的新的Map输出根据静态哈希函数分配到上述某一集合的过程为,各个Map随后输出的每条记录,根据该记录的key,在静态哈希函数中寻找与该key二进制最接近的桶号所在的集合,并且把该记录分配到对应的集合上去。
对于每一个集合的大小不得超过一定的阈值,如果其中包含不同的key,则该集合中数据的大小不超过Reduce处理单位的设定大小。集合大小不超过Reduce处理单位的预先设置的阈值百分比。Reduce处理单位的大小为系统自身设置数据块的大小。
对于预先设置的阈值百分比设置为75%。
本发明的特点在于:
1、本发明通过预先考察部分Map输出的数据的分布情况来获得整个任务中Reduce所需要的数据的合理划分方法,使得尽可能保证每一个Reduce所得到的数据量大小尽可能的接近(比如使得每一个Reduce获得的数据集合能够保证至少70%以上集合的大小之间的差不超过所有集合平均值的20%)。
2、本发明对已有的Map-Reduce计算框架进行优化,在优化了之后的Map-Reduce计算框架不再需要用户手动去设置Reduce的个数,而且同时解决了原先Map-Reduce框架下的负载均衡的问题。
3、本发明通过考察一定比例(比如70%)的输入数据,使用动态哈希方法来对全局数据的分布情况进行简要的预测,最终产生一个静态的哈希函数,使得在该静态哈希函数的作用下,所有输入的数据尽可能能均匀地被划分到不同的集合(在Reduce中也称为划分)中。
4、代替原先从Map输出开始就采用静态哈希函数划分数据的方法,本发明从Map端首先开始使用动态哈希函数进行处理,直到处理了特定比例的数据之后生成一个全局上能够均匀划分数据的静态哈希函数,并且此后使用该静态哈希函数来处理已经处理过的数据和剩下未处理的数据。
5、对于生成最终静态哈希函数的方法,每一个Map的输出数据在经过动态哈希函数处理之后将得到一个由桶(每个桶至少存放着一条记录)作为元素构成的集合。然而将所有Map经过动态哈希函数处理之后得到所有桶进行划分成大小相近的若干个互不相交的子集是NP难的,因此本专利将根据桶的分布情况产生一个静态的哈希函数,使得当所有的数据经过Map处理之后,该静态哈希函数接着能够把所有数据划分成近似均匀的特定个划分,每一个划分被分配到一个Reduce中。
因此,本发明通过采用动态哈希函数划分方法来预测任务所输入数据的分布,并且根据所预测数据的分布特点产生一个静态哈希函数,使得在该静态哈希函数的作用下,所有数据的分发尽可能均匀地分配到各个计算节点中,进而任务调度能够根据数据分布的情况动态自适应地调整数据和计算资源的分配,减少了运算中出现的偏斜。
附图说明
图1传统Map-Reduce架构及流程示意图
图2本发明Map-Reduce架构及流程示意图
图3本发明划分方法流程图
具体实施方式
下面说明本发明的具体实现步骤和详细方法。
本实施方式是在Hadoop平台上进行的,主要对Map-Reduce目前计算框架中存在的问题进行优化。这里首先给出整个负载均衡器的设计架构图,并且说明每一个主要模块负责的内容,接着详细说明每一个模块的设计以及实现方式。
本发明的方法要求在Map完成所有数据的一定比例(比如75%,后面所提到的75%也出自于此处;这个比例尽可能使得在不影响整体效率的情况下,尽可能地让产生的静态哈希函数能够充分体现整体数据的分布)的处理任务之后,根据Map的输出的数据分布情况决定Reduce端的数量和一个针对于Reduce端的数据划分方法,使得Map所有数据都能够尽可能均匀地分配给不同的Reduce当中。本发明同时还需要保证改进之后的均衡方法能够在效率上不低于原始的Map-Reduce计算模型,因此当Map不能重复处理这用于预测数据分布情况的数据(上述所说的75%部分),这要求本负载均衡方法在产生最终的划分方法之后,不能重新对已经处理过的那部分75%的数据进行再一次划分。
针对上述的要求,本发明对已有的Map-Reduce框架做针对性的修改。本发明的工作利用基于Hadoop进行说明,本专利的主要思想也涵盖其他实现Map-Reduce架构的系统,主要的改动是对Map-Reduce的Map结果输出之后采用PartitionBalancer代替原先的Partition,而新的PartitionBalancer涉及到原来Map-Reduce框架中的的Job Tracker,Task Tracker,MapTask,ReduceTask,OutputCollector的修改。为了体现主要的修改,本发明在传统Map-Reduce运行框架的基础上绘制了经过修改之后的本发明的框架图,如图2,其中图中的虚线边框的Partition是旧的,本发明将其改成新的PartitionBalancer。
原始的Job Tracker是需要汇总所有Task(包括MapTask和ReduceTask)的运行状态情况(主要包含完成的比率,用户增加的counter等)反馈给用户。本发明对Job Tracker增加统计Task Tracker反馈回来的分桶情况,同时修改Job Tracker以便支持Task Tracker启动或者暂停Map Task和Reduce Task的控制。
原始Task Tracker只负责Map Task和Reduce Task的进度跟踪和按照一定的周期不断地向Job Tracker汇报当前Task的运行情况。如果发现Task失败,则需要重启Task,保证Map-Reduce的容错性,此外还负责统计输入输出的记录个数。本发明需要对TaskTracker进行修改,修改对统计信息(counter)的管理,并且向Job Tracker汇报当前分桶情况和每个Map使用的Hash函数。
原始的Map Task负责不断地向Task Tracker汇报当前进度的情况,包括输入完成的比例、完成的比例。本发明需要对MapTask增加对输出结果划分的情况汇报(分桶情况)的功能。
原始的OutputCollector主要有MapOutputCollector和ReduceOutputCollector两个部分,其中MapOutputCollector负责把Map的输出都按照一定的划分方式把数据分配到各个Reduce中。由于当前简单的直接对key模Reduce个数的方法容易导致Reduce端数据的偏斜,因此本发明需要把划分改成动态哈希函数的划分方法首先进行预测,比如PAL动态哈希划分方法(请参见Per-Ake Larson,Dynamic Hash Tables,1988),进而获得能够针对当前处理数据的自适应的静态哈希函数划分方式,使得最后分配给每一个Reduce的数据量都大致相等。
原始的Reduce Task负责向Task Tracker获取Map Task的完成情况,然后根据Map完成的情况开始进行Copy和Sort等阶段,其中Copy阶段是由Reduce向Map进行RPC调用实现。由于MapOutputCollector采用了动态哈希的划分方法,如果进入同一个Reduce的数据量比较少(能够在系统允许使用的内存中存放)的情况下,可以在PartitionBalancer分桶过程中保留哈希表(key对应value的数组),这样Reduce阶段就不再需要Sort阶段,因此在数据量较少的情况下,本发明只需要按照桶进行哈希连接操作来代替原先Reduce相对低效的Sort与Merge阶段。
本发明增加了PartitionBalancer模块,它负责根据每一个MapTask反馈的分桶情况和完成比例产生一个只自适应当前Job数据的静态哈希函数,并采用该静态哈希函数用于数据划分。该模块的运行由Job Tracker控制。
下面对本发明框架涉及模块的详细说明
1、PartitionBalancer模块
PartitionBalancer是本发明整个负载均分分配的关键所在。PartitionBalancer根据JobTracker中提供的当前Job下的所有Map输出数据的桶的分布情况(<桶号,记录大小>集合),产生一个静态的哈希函数和特定的Reduce设置的个数,并且把这个哈希函数发送给所有Map端。这个静态的哈希函数划分方法将尽可能保证所有数据经过Map操作之后能够自适应地均匀把数据分配给各个Reduce中。
PartitionBalancer主要需要完成的内容就是根据给定<桶号,记录大小>的集合,产生需要的Reducer端的数量,以及一个合适的静态哈希函数,使得所有记录采用这个静态哈希函数进行划分之后,能够被划分到不同的分区中去,而且每一个分区中的数据尽可能地均匀,也就是分区中的均匀程度不得低于一定的阈值。由于求出该划分方法是NP难的(若NP中所有问题到某一个问题是图灵可归约的,则该问题为NP困难问题。而NP是指非确定性多项式(non-deterministic polynomial,缩写NP)。所谓的非确定性是指,可用一定数量的运算去解决多项式时间内可解决的问题。请参见http://baike.baidu.com/view/3408158.htm;http://en.wikipedia.org/wiki/NP-hard),因此这里采用一种近似的方法。
此外由于Reduce处理数据是按照块为单位来处理的,而块的大小由用户在安装计算框架的时候决定,一般是64MB(也有设为128MB的情况)的大小,这里假设给定的块大小为B,而且PartitionBalancer用于预测数据分进而产生静态哈希函数的数据是总数据的75%(这个毕业是预先设置的阈值百分比),则PartitionBalancer将尽可能使得最后形成静态哈希函数的时候得到的每一个划分的大小都小于B×75%,这样假设输入的是所有的数据的情况下,数据才将都尽可能小于块大小B,有利于Reduce进行数据调度的效率。此外考虑PartitionBalancer自身的效率问题,在ParitionBalancer中不进行分桶操作(分桶将会涉及桶号修改和所改动的桶中所有记录的重新分配),而只进行桶的合并进而产生静态哈希函数。而为了保证来到ParitionBalancer的每一个桶的大小都尽可能小于B×75%,Map端在使用动态哈希函进行分桶操作的时候就需要把这种限制考虑进去,这点在Map Task部分进行说明。下面说明如何进行静态哈希函数的产生。
假设每一个Map提交给PartitionBalancer的是<桶号,桶大小>的集合。那么要求经过处理获得静态哈希函数之后,产生以每一个由桶构成的集合大小都尽可能不超过B×75%。。
第一步,收集所有Map提交过来的<桶号,桶大小>,并且按照桶号进行合并成更大的桶。只要桶号完全相同则合并。
第二步,把桶号之间具有相互包含关系的桶进行合并。首先根据桶号进行字典序列排序,采用的排序方法是快速排序;然后根据桶号的包含关系不断地合并,如果桶号A和桶号B相交的部分是A(比如A(001)包含001**,则把001**加入到001桶当中),则把桶号为B的桶加入A桶中。这一步的作用在最后生成的静态划分函数了之后,对于一个新输入的记录可以很明确地找到对应的桶,而如果A桶和B桶不进行合并,那么如果一个二进制编号是001*的记录过来,就不知道应该加入A桶还是加入B桶才合适。
第三步,划分所有桶。首先对已经经过第二步处理得到的桶按照桶大小进行排序,对于大小大约或者等于B×75%的桶,每个桶各自进入单独的划分(每一个划分是由<桶号,桶大小>构成的集合);对大小小于B×75%的桶中最大的桶取出作为一个单独的新的划分,然后不断地从剩下的桶中取出最小的桶不断地加入这个该大桶所在的新划分中,直到该划分中所有桶的记录大小总和达到B×75%的大小;然后接着取出次大的桶作为新的划分,以此类推。这样对所有小于B×75%的桶都被分配到不同的划分中。
第四步,输出这些静态哈希函数的划分方式。经过第三步,我们可以得到一个由划分构成的集合R,而每一个划分中都包含一个或者多个桶号。那么这个R就是PartitionBalancer进行数据划分的依据,也就是这里所说的静态哈希函数,处于相同划分中的桶号对应的记录,将会进入相同的Reduce;而R中的划分的个数就是Reduce个数。
经过划分之后,已经可以确定那些处于相同划分的桶中的记录将会进入相同的Reduce中,因此最终划分的个数也就已经确定,也确定了Reduce的个数。Map输出新的Key-Value进来的时候,首先也按照Key的哈希之后的二进制寻找跟它接近的桶号,并且进入桶号所在的划分中,进而进入对应的Reduce中。显然,对于那部分参与静态哈希函数产生的那75%数据,它们也已经在产生静态哈希函数的过程中找到了对应的Reduce,避免了对它们进行重新划分。
2、Job Tracker模块
Job Tracker是整个Job的运行的控制中枢,本发明对Job Tracker进行扩展,使得根据当前Map的运行完成的情况和Map输出的分桶情况作出决策,是否开始生成静态哈希函数,如果确认已经可以开始生成静态哈希函数,则Job Tracker将告知所有Map暂停,并且开始汇总所有Map采用各自的动态哈希函数对数据进行预测而产生的分桶情况,再由PartitionBalancer根据这些分桶情况,开始生成静态哈希函数;当PartitionBalancer完成了静态哈希函数的生成之后,PartitionBalancer需要把最终的静态哈希函数通过Job Tracker交给每一个Map端的MapOutputBuffer,并且Job Tracker告知每一个Map开始采用这个全局的静态函数处理余下的数据。MapOutputBuffer采用该静态哈希函数把已经生成的记录和即将生成的数据映射给对应的Reduce中。
3、Map Task
Map端的操作主要由Map Task的对象来实现。本发明修改Map端,使得Map使用PAL动态哈希函数来生成桶,在这里需要对每一个桶的大小进行限制,并且不断地向Job Tracker报告当前进度,如果进度达到一定的比例(比如75%),则需要暂停,并且向Job Tracker汇报分桶情况,等待获得一个静态的哈希函数之后才开始继续处理剩余的部分数据(根据前面假设,这里是25%)。
在进行动态哈希产生分桶的过程中,需要对分桶进行如下限制:假设Map Task使用了M个Map,那么这些Map产生的所有桶将在PartitionBalancer端合并,假设每个桶平均大小是R’,那么最坏情况M个Map输出的桶都与其他Map输出的某一个桶进行合并,则合并得到的新桶中的记录大小将是MR’。为了保证最终进行划分的数据中每一个桶不超过块的大小B,假设设置的完成比率是p(一般是75%)的时候暂停Map,则假设输入全部的数据情况下,在Map端每一个桶的数据量大小必须满足:
否则该桶就需要分裂。也就是除了动态哈希自身设置的比例需要分桶之外,在此条件下仍然需要进行分桶操作。
4、Reduce Task
本发明修改Reduce Task,使得Reduce Task可以从PartitionBalancer提供的静态哈希函数的划分之后,可以直接获得预先经过处理的75%的数据,而不需要重新计算;剩余25%的数据则通过Map采用静态哈希函数之后获得。
此外,如果数据量不大,本发明的Reduce Task在运行过程中可以在内存中使用哈希表来存储记录,并且进行相同key下所有value的合并,从而可以代替原始Map-Reduce计算框架中Reduce之前包含的sort和merge的过程(该过程用于获得同一个key的所有value的列表)。
可以看出,对于一个Reduce来说,如果处理的数据量较少的情况下,内存中只需要保存桶一个桶下的key和保存与该key对应的所有记录的地址。因此减少了之前的sort的情况,从而也提高了效率。
Claims (13)
1.一种并行计算框架中的Reduce端自适应负载均衡方法,其步骤包括:
1)各Map接收相应Hadoop文件,进行Map处理;
2)将各Map输出的数据采用动态哈希函数划分方法进行分桶保存,其中Map输出的数据中,同一key对应的记录保存在同一桶内;当一桶包含不同key时,其记录个数或占用的存储空间不得超过预先设定的阈值;
3)当各Map的输出达到设定比例后,根据所有Map输出的所有桶的分布情况产生一个静态哈希函数,该静态哈希函数根据桶的个数和桶内的记录个数或占用的存储空间将上述桶划分为若干互不相交的集合,且各个集合之间的均匀程度不得低于一定的阈值;
4)将新的Map输出根据静态哈希函数分配到上述某一集合内,直至所有Map输出的数据均分配至某一集合之中,且每个集合的大小不得超过一定的阈值;
5)将同一集合的数据分配到同一Reduce节点进行Reduce处理。
2.如权利要求1所述的方法,其特征在于,存入某一key对应的Map输出数据的桶的桶号表示为二进制桶号,至少与根据该key的二进制哈希值前几位相同。
3.如权利要求2所述的方法,其特征在于,新的Map输出根据其key的二进制哈希值寻找最接近的桶号,以划分到该桶号所属的集合中。
4.如权利要求1或2或3所述的方法,其特征在于,如果当一桶包含不同key而且其记录个数或占用的存储空间超过预先设定的阈值时,增加一个二进制位以分裂该桶。
5.如权利要求1所述的方法,其特征在于,所述各Map端的输出达到所有Map输出的预先设置的阈值百分比。
6.如权利要求4所述的方法,其特征在于,所述动态哈希划分方法为PAL动态哈希划分方法。
7.如权利要求1所述的方法,其特征在于,所述的各个集合之间均匀程度不得低于一定的阈值为至少70%以上集合的大小之间的差不超过所有集合平均值的20%。
8.如权利要求1所属的方法,其特征在于,所述的新的Map输出根据静态哈希函数分配到上述某一集合的过程为,各个Map随后输出的每条记录,根据该记录的key,在静态哈希函数中寻找与该key二进制最接近的桶号所在的集合,并且把该记录分配到对应的集合上去。
9.如权利要求1所述的方法,其特征在于,所述的静态哈希函数为针对本次任务所有数据的分布特点的一种静态的划分方法,而且划分成的集合的个数等于所需要Reduce的个数。
10.如权利要求1所述的方法,其特征在于,对于每一个集合的大小不得超过一定的阈值,如果其中包含不同的key,则该集合中数据的大小不超过Reduce处理单位的设定大小。
11.如权利要求10所述的方法,其特征在于,集合大小不超过Reduce处理单位的预先设置的阈值百分比。
12.如权利要求11所述的方法,其特征在于,Reduce处理单位的大小为系统自身设置数据块的大小。
13.如权利要求5或11所述的方法,其特征在于,预先设置的阈值百分比的大小为75%。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210047028.1A CN102629219B (zh) | 2012-02-27 | 2012-02-27 | 并行计算框架中的Reduce端自适应负载均衡方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210047028.1A CN102629219B (zh) | 2012-02-27 | 2012-02-27 | 并行计算框架中的Reduce端自适应负载均衡方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102629219A true CN102629219A (zh) | 2012-08-08 |
CN102629219B CN102629219B (zh) | 2015-09-23 |
Family
ID=46587479
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210047028.1A Expired - Fee Related CN102629219B (zh) | 2012-02-27 | 2012-02-27 | 并行计算框架中的Reduce端自适应负载均衡方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102629219B (zh) |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103324577A (zh) * | 2013-06-08 | 2013-09-25 | 北京航空航天大学 | 基于最小化io访问冲突和文件分条的大规模分条文件分配系统 |
CN103412794A (zh) * | 2013-08-08 | 2013-11-27 | 南京邮电大学 | 一种面向流计算的动态调度分配方法 |
CN103455375A (zh) * | 2013-01-31 | 2013-12-18 | 南京理工大学连云港研究院 | Hadoop云平台下基于负载监控的混合调度方法 |
CN103942195A (zh) * | 2013-01-17 | 2014-07-23 | 中国银联股份有限公司 | 一种数据处理系统以及数据处理方法 |
CN104156268A (zh) * | 2014-07-08 | 2014-11-19 | 四川大学 | 一种GPU上MapReduce负载分配和线程结构优化方法 |
CN104252338A (zh) * | 2013-06-25 | 2014-12-31 | 华为技术有限公司 | 一种数据处理的方法和设备 |
CN104408159A (zh) * | 2014-12-04 | 2015-03-11 | 曙光信息产业(北京)有限公司 | 一种数据关联、加载、查询方法及装置 |
CN104468239A (zh) * | 2014-12-22 | 2015-03-25 | 上海大唐移动通信设备有限公司 | 一种基于规则的数据处理方法及装置 |
CN104598304A (zh) * | 2013-10-31 | 2015-05-06 | 国际商业机器公司 | 用于作业执行中的调度的方法和装置 |
CN103064741B (zh) * | 2012-12-24 | 2015-08-05 | 浙江工业大学 | 一种基于能量模型的可分负荷调度方法 |
CN105045607A (zh) * | 2015-09-02 | 2015-11-11 | 广东创我科技发展有限公司 | 一种实现多种大数据计算框架统一接口的方法 |
CN105095515A (zh) * | 2015-09-11 | 2015-11-25 | 北京金山安全软件有限公司 | 支持快速查询Map-Reduce输出结果的分桶方法、装置及设备 |
CN105608224A (zh) * | 2016-01-13 | 2016-05-25 | 广西师范大学 | 一种提高海量数据查询性能的正交多哈希映射索引方法 |
CN106156159A (zh) * | 2015-04-16 | 2016-11-23 | 阿里巴巴集团控股有限公司 | 一种表连接处理方法、装置和云计算系统 |
CN106484689A (zh) * | 2015-08-24 | 2017-03-08 | 杭州华为数字技术有限公司 | 数据处理方法和装置 |
CN106502790A (zh) * | 2016-10-12 | 2017-03-15 | 山东浪潮云服务信息科技有限公司 | 一种基于数据分布的任务分配优化方法 |
CN106600219A (zh) * | 2016-12-02 | 2017-04-26 | 广州支点网络科技股份有限公司 | 合作伙伴关系分组的方法及其系统 |
CN106598729A (zh) * | 2016-11-18 | 2017-04-26 | 深圳市证通电子股份有限公司 | 分布式并行计算系统的数据分配方法及系统 |
CN107045512A (zh) * | 2016-02-05 | 2017-08-15 | 北京京东尚科信息技术有限公司 | 一种数据交换方法及系统 |
CN107145394A (zh) * | 2017-04-28 | 2017-09-08 | 中国人民解放军国防科学技术大学 | 一种针对数据倾斜的均衡负载处理方法及装置 |
CN107562542A (zh) * | 2017-09-06 | 2018-01-09 | 腾讯科技(深圳)有限公司 | 分布式数据处理系统数据分区方法及装置 |
WO2018059029A1 (zh) * | 2016-09-30 | 2018-04-05 | 华为技术有限公司 | 一种资源分配方法、相关设备及系统 |
CN107967650A (zh) * | 2017-11-08 | 2018-04-27 | 中国银行股份有限公司 | 一种核心银行系统的批量账务数据处理方法及装置 |
CN109358944A (zh) * | 2018-09-17 | 2019-02-19 | 深算科技(重庆)有限公司 | 深度学习分布式运算方法、装置、计算机设备及存储介质 |
WO2019042199A1 (zh) * | 2017-08-30 | 2019-03-07 | 第四范式(北京)技术有限公司 | 用于执行机器学习的分布式系统及其方法 |
CN109992372A (zh) * | 2017-12-29 | 2019-07-09 | 中国移动通信集团陕西有限公司 | 一种基于映射归约的数据处理方法及装置 |
CN112231320A (zh) * | 2020-10-16 | 2021-01-15 | 南京信息职业技术学院 | 基于MapReduce算法的web数据采集方法、系统和存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101977162A (zh) * | 2010-12-03 | 2011-02-16 | 电子科技大学 | 一种高速网络的负载均衡方法 |
CN102004670A (zh) * | 2009-12-17 | 2011-04-06 | 华中科技大学 | 一种基于MapReduce的自适应作业调度方法 |
-
2012
- 2012-02-27 CN CN201210047028.1A patent/CN102629219B/zh not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102004670A (zh) * | 2009-12-17 | 2011-04-06 | 华中科技大学 | 一种基于MapReduce的自适应作业调度方法 |
CN101977162A (zh) * | 2010-12-03 | 2011-02-16 | 电子科技大学 | 一种高速网络的负载均衡方法 |
Cited By (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103064741B (zh) * | 2012-12-24 | 2015-08-05 | 浙江工业大学 | 一种基于能量模型的可分负荷调度方法 |
CN103942195B (zh) * | 2013-01-17 | 2017-07-25 | 中国银联股份有限公司 | 一种数据处理系统以及数据处理方法 |
CN103942195A (zh) * | 2013-01-17 | 2014-07-23 | 中国银联股份有限公司 | 一种数据处理系统以及数据处理方法 |
CN103455375A (zh) * | 2013-01-31 | 2013-12-18 | 南京理工大学连云港研究院 | Hadoop云平台下基于负载监控的混合调度方法 |
CN103455375B (zh) * | 2013-01-31 | 2017-02-08 | 南京理工大学连云港研究院 | Hadoop云平台下基于负载监控的混合调度方法 |
CN103324577A (zh) * | 2013-06-08 | 2013-09-25 | 北京航空航天大学 | 基于最小化io访问冲突和文件分条的大规模分条文件分配系统 |
CN103324577B (zh) * | 2013-06-08 | 2016-04-06 | 北京航空航天大学 | 基于最小化io访问冲突和文件分条的大规模分条文件分配系统 |
CN104252338A (zh) * | 2013-06-25 | 2014-12-31 | 华为技术有限公司 | 一种数据处理的方法和设备 |
CN103412794A (zh) * | 2013-08-08 | 2013-11-27 | 南京邮电大学 | 一种面向流计算的动态调度分配方法 |
CN104598304A (zh) * | 2013-10-31 | 2015-05-06 | 国际商业机器公司 | 用于作业执行中的调度的方法和装置 |
CN104598304B (zh) * | 2013-10-31 | 2018-03-13 | 国际商业机器公司 | 用于作业执行中的调度的方法和装置 |
CN104156268B (zh) * | 2014-07-08 | 2017-07-07 | 四川大学 | 一种GPU上MapReduce的负载分配和线程结构优化方法 |
CN104156268A (zh) * | 2014-07-08 | 2014-11-19 | 四川大学 | 一种GPU上MapReduce负载分配和线程结构优化方法 |
CN104408159A (zh) * | 2014-12-04 | 2015-03-11 | 曙光信息产业(北京)有限公司 | 一种数据关联、加载、查询方法及装置 |
CN104408159B (zh) * | 2014-12-04 | 2018-01-16 | 曙光信息产业(北京)有限公司 | 一种数据关联、加载、查询方法及装置 |
CN104468239A (zh) * | 2014-12-22 | 2015-03-25 | 上海大唐移动通信设备有限公司 | 一种基于规则的数据处理方法及装置 |
CN104468239B (zh) * | 2014-12-22 | 2018-08-21 | 上海大唐移动通信设备有限公司 | 一种基于规则的数据处理方法及装置 |
CN106156159A (zh) * | 2015-04-16 | 2016-11-23 | 阿里巴巴集团控股有限公司 | 一种表连接处理方法、装置和云计算系统 |
CN106484689B (zh) * | 2015-08-24 | 2019-09-03 | 杭州华为数字技术有限公司 | 数据处理方法和装置 |
CN106484689A (zh) * | 2015-08-24 | 2017-03-08 | 杭州华为数字技术有限公司 | 数据处理方法和装置 |
CN105045607A (zh) * | 2015-09-02 | 2015-11-11 | 广东创我科技发展有限公司 | 一种实现多种大数据计算框架统一接口的方法 |
CN105045607B (zh) * | 2015-09-02 | 2019-03-29 | 广东创我科技发展有限公司 | 一种实现多种大数据计算框架统一接口的方法 |
CN105095515A (zh) * | 2015-09-11 | 2015-11-25 | 北京金山安全软件有限公司 | 支持快速查询Map-Reduce输出结果的分桶方法、装置及设备 |
CN105608224A (zh) * | 2016-01-13 | 2016-05-25 | 广西师范大学 | 一种提高海量数据查询性能的正交多哈希映射索引方法 |
CN107045512A (zh) * | 2016-02-05 | 2017-08-15 | 北京京东尚科信息技术有限公司 | 一种数据交换方法及系统 |
US11003507B2 (en) | 2016-09-30 | 2021-05-11 | Huawei Technologies Co., Ltd. | Mapreduce job resource sizing using assessment models |
WO2018059029A1 (zh) * | 2016-09-30 | 2018-04-05 | 华为技术有限公司 | 一种资源分配方法、相关设备及系统 |
CN106502790A (zh) * | 2016-10-12 | 2017-03-15 | 山东浪潮云服务信息科技有限公司 | 一种基于数据分布的任务分配优化方法 |
CN106598729A (zh) * | 2016-11-18 | 2017-04-26 | 深圳市证通电子股份有限公司 | 分布式并行计算系统的数据分配方法及系统 |
CN106600219A (zh) * | 2016-12-02 | 2017-04-26 | 广州支点网络科技股份有限公司 | 合作伙伴关系分组的方法及其系统 |
CN107145394B (zh) * | 2017-04-28 | 2020-05-08 | 中国人民解放军国防科学技术大学 | 一种针对数据倾斜的均衡负载处理方法及装置 |
CN107145394A (zh) * | 2017-04-28 | 2017-09-08 | 中国人民解放军国防科学技术大学 | 一种针对数据倾斜的均衡负载处理方法及装置 |
WO2019042199A1 (zh) * | 2017-08-30 | 2019-03-07 | 第四范式(北京)技术有限公司 | 用于执行机器学习的分布式系统及其方法 |
CN107562542A (zh) * | 2017-09-06 | 2018-01-09 | 腾讯科技(深圳)有限公司 | 分布式数据处理系统数据分区方法及装置 |
CN107562542B (zh) * | 2017-09-06 | 2020-04-07 | 腾讯科技(深圳)有限公司 | 分布式数据处理系统数据分区方法及装置 |
CN107967650A (zh) * | 2017-11-08 | 2018-04-27 | 中国银行股份有限公司 | 一种核心银行系统的批量账务数据处理方法及装置 |
CN109992372A (zh) * | 2017-12-29 | 2019-07-09 | 中国移动通信集团陕西有限公司 | 一种基于映射归约的数据处理方法及装置 |
CN109358944A (zh) * | 2018-09-17 | 2019-02-19 | 深算科技(重庆)有限公司 | 深度学习分布式运算方法、装置、计算机设备及存储介质 |
CN112231320A (zh) * | 2020-10-16 | 2021-01-15 | 南京信息职业技术学院 | 基于MapReduce算法的web数据采集方法、系统和存储介质 |
CN112231320B (zh) * | 2020-10-16 | 2024-02-20 | 南京信息职业技术学院 | 基于MapReduce算法的web数据采集方法、系统和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN102629219B (zh) | 2015-09-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102629219B (zh) | 并行计算框架中的Reduce端自适应负载均衡方法 | |
KR102103130B1 (ko) | 서비스 데이터를 블록체인에 기입하기 위한 방법 및 장치, 그리고 서비스 하위세트를 결정하기 위한 방법 | |
EP2212806B1 (en) | Allocation of resources for concurrent query execution via adaptive segmentation | |
Li et al. | A platform for scalable one-pass analytics using mapreduce | |
CN103312825B (zh) | 一种数据分布存储方法和装置 | |
US20170024251A1 (en) | Scheduling method and apparatus for distributed computing system | |
CN108595254B (zh) | 一种查询调度方法 | |
CN103716381A (zh) | 一种分布式系统的控制方法,及管理节点 | |
CN102254246A (zh) | 一种工作流管理方法及其系统 | |
CN101625655A (zh) | 一种内存数据库的并行恢复方法 | |
CN103595805A (zh) | 一种基于分布式集群的数据放置方法 | |
CN107291550A (zh) | 一种针对迭代应用的Spark平台资源动态分配方法及系统 | |
CN105843687A (zh) | 一种任务资源的量化方法和装置 | |
CN104199912B (zh) | 一种任务处理的方法及装置 | |
CN110704438B (zh) | 一种区块链中布隆过滤器的生成方法及装置 | |
CN108270805A (zh) | 用于数据处理的资源分配方法及装置 | |
CN102508902A (zh) | 云存储系统中可变分块大小的块数据分块方法 | |
Li et al. | Improving the shuffle of hadoop MapReduce | |
CN104679590A (zh) | 分布式计算系统中的Map优化方法及装置 | |
CN109510852A (zh) | 灰度发布的方法及装置 | |
CN109032769B (zh) | 一种基于容器的持续集成ci任务处理方法及装置 | |
CN104239520B (zh) | 一种基于历史信息的hdfs数据块放置策略 | |
Mestre et al. | Efficient entity matching over multiple data sources with mapreduce | |
Zhang et al. | A parallel task scheduling algorithm based on fuzzy clustering in cloud computing environment | |
CN107566341A (zh) | 一种基于联邦分布式文件存储系统的数据持久化存储方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150923 Termination date: 20180227 |
|
CF01 | Termination of patent right due to non-payment of annual fee |