CN106599184B - 一种Hadoop系统优化方法 - Google Patents

一种Hadoop系统优化方法 Download PDF

Info

Publication number
CN106599184B
CN106599184B CN201611148198.3A CN201611148198A CN106599184B CN 106599184 B CN106599184 B CN 106599184B CN 201611148198 A CN201611148198 A CN 201611148198A CN 106599184 B CN106599184 B CN 106599184B
Authority
CN
China
Prior art keywords
backup
tasktracker
queue
execution queue
task
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.)
Expired - Fee Related
Application number
CN201611148198.3A
Other languages
English (en)
Other versions
CN106599184A (zh
Inventor
陈旺虎
马生俊
俞茂义
李金溶
郏文博
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Northwest Normal University
Original Assignee
Northwest Normal University
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Northwest Normal University filed Critical Northwest Normal University
Priority to CN201611148198.3A priority Critical patent/CN106599184B/zh
Publication of CN106599184A publication Critical patent/CN106599184A/zh
Application granted granted Critical
Publication of CN106599184B publication Critical patent/CN106599184B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1461—Backup scheduling policy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明涉及大数据与云计算领域，尤其涉及一种Hadoop系统优化方法。其中，对HDFS数据分布存储阶段的优化包括：选择DataNode；对选出的DataNode排序；采用同向增量的轮循方法放置数据。对MapReduce数据并行计算阶段的优化包括：生成执行队列Q；执行R0备份；更新执行队列Q；执行R1备份；更新执行队列Q；执行R2备份；更新执行队列Q；针对性执行。本发明采用自适应的轮循放置策略，可以将数据基本均匀地放置在DataNode，防止出现节点负载不平衡等问题。同时将所有的map任务都在本机执行，很大程度上减少了数据的网络传输，减少了map任务对网络传输的依赖，极大地避免了网络延迟带给应用的瓶颈。

Description

一种Hadoop系统优化方法
技术领域
本发明涉及大数据与云计算领域，尤其涉及一种Hadoop系统优化方法。
背景技术
Hadoop以其可靠、高效、可伸缩的数据处理方式，成为目前比较受用户青睐的分布式系统架构。Hadoop框架最核心的设计是HDFS(Hadoop分布式文件系统)和MapReduce，HDFS为海量的数据提供了存储，而MapReduce为海量的数据提供了计算。现有的Hadoop框架中HDFS默认采用随机的数据放置，这种方式下数据放置不均匀，而且由于没有兼顾节点负载(计算负载和存储负载)导致负载不平衡。另一方面，在MapReduce并行计算时，某些节点处理任务所需的数据不在本地，需要从其他节点网络传输过来，尤其当数据量非常大时，对网络传输的需求会巨大，无疑地，网络传输成为发展的瓶颈。这些问题严重影响了Hadoop框架的执行效率。
发明内容
为解决上述问题，本发明针对Hadoop框架中的HDFS数据分布存储和MapReduce数据并行计算两个过程进行了优化。
对于HDFS数据分布存储，提出了“自适应的数据轮循放置策略”，一方面轮循的数据放置可以解决在HDFS中数据放置不均匀的问题；另一方面自适应的数据放置即根据节点自身的能力(计算能力和存储能力)选择将较多的数据放置在能力较大的节点上，可以解决在HDFS中数据放置时出现节点负载不平衡甚至出现某些节点负载过重等问题。
对于MapReduce数据并行计算，提出了“基于数据的本机执行”的并行计算策略，尽可能将所有map任务在本机处理即几乎所有数据的读取都在本机磁盘执行，这样既可以减少对网络传输的依赖，又可以大幅度地提高应用效率。
本发明采用的具体方案如下：
一种Hadoop系统优化方法，包括对HDFS数据分布存储阶段的优化和对MapReduce数据并行计算阶段的优化；其中，对HDFS数据分布存储阶段的优化包括以下步骤：
步骤1.1、选择DataNode：根据Hadoop集群内每个DataNode的磁盘使用率选择具有存储能力的DataNode用于存储数据；
步骤1.2、对选出的DataNode排序：将已选择的DataNode根据其计算能力的大小降序排序；
步骤1.3、放置数据：按照步骤1.2产生的顺序采用同向增量的轮循方法，将所有Block的备份存储到选出的DataNode；
对MapReduce数据并行计算阶段的优化包括以下步骤：
步骤2.1、生成执行队列Q：各TaskTracker将存储在本地的Block的备份按Block编号和备份编号的增序进行排序生成各自的执行队列q，优先考虑备份编号；HDFS默认备份数是3，第i个Block的备份为
Figure BDA0001179293570000021
所有TaskTracker的执行队列q统称为执行队列Q；步骤2.2、执行R0备份：各TaskTracker顺序地执行自己队列q中备份编号为0的备份R0，当有一个TaskTracker执行完自己队列q中R0的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务；
步骤2.3、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份；
步骤2.4、检查执行队列Q是否为空，若空则停止执行任务；
步骤2.5、执行R1备份：各TaskTracker顺序地执行自己队列q中备份编号为1的备份R1，当有一个TaskTracker执行完自己队列q中R1的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务；
步骤2.6、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份；
步骤2.7、检查执行队列Q是否为空，若空则停止执行任务；
步骤2.8、执行R2备份：各TaskTracker顺序地执行自己队列q中备份编号为2的备份R2，当有一个TaskTracker执行完自己队列q中R2的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务；
步骤2.9、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份；
步骤2.10、检查执行队列Q是否为空，若空则停止执行任务；
步骤2.11、针对性执行：检查是否还存在个别Block的备份未进行处理，在JobTracker的协调下将没有处理的Block的备份进行最后一次针对性处理。
步骤1.1中选择DataNode的标准是磁盘使用率在80％以下的视为有存储能力。
步骤1.2中，通过CPU和内存的类型判断计算能力大小。
步骤1.3中同向增量的轮循方法是指每个Block的各份备份均按顺时针方向循环选取DataNote放置，并用增量区别每份备份的开始位置。所述的增量小于等于步骤1.1选出的DataNode总数的一半。例如，选出并排好序的DataNode有10个，增量m为4，每个Block有3份备份，那么，第1份备份开始放置数据的第一个DataNode为序列中的第1个DataNode，第2份备份开始放置数据的第一个DataNode为序列中的第(1+m)即第5个DataNode，第3份备份开始放置数据的第一个DataNode为序列中的第(1+2*m)即第9个DataNode。
步骤2.3、2.6和2.9中已经被处理的备份既包括本机处理的备份，也包括其他TaskTracker处理的备份，相同备份是指针对同一Block的备份，包括R0、R1、R2。
步骤2.2中若有TaskTracker的队列中没有R0备份，则不参与此次执行，步骤2.5、2.8同样处理。
本发明在HDFS数据分布存储时采用轮循的数据放置策略，数据可以很均匀地存储在集群内的各DataNode上。但是，有些DataNode的存储能力较小，可能无法承受均匀地放置数据，如果这样会导致这些节点存储负载过重甚至无法存储数据；有些DataNode的计算能力较弱，可能造成计算较慢而影响整体的性能。为此，本发明又通过Hadoop对存储能力的评定选择有足够存储能力的DataNode来保存数据，同时，还将选出的有足够存储能力的DataNode按照计算能力降序排序，尽可能将多的Block存储在计算能力较大的DataNode上，以解决轮循放置数据的计算负载问题。
另外，为保证数据的可靠性和容错性，将3份Block的备份采用“同向增量”的方法存储。同向是指放置3份备份时都按顺时针方向放置；增量是指放置3份备份时用增量区别每一份的开始位置。同向存储避免了当参与存储的DataNode为奇数个时，在最中间的DataNode上出现同一Block的相同备份的问题；增量存储避免了所有的Block的相同备份出现在同一DataNode上的问题。
步骤2.1-2.11中所述的JobTracker和TaskTracker是MapReduce主从架构的组成。JobTracker是主节点，负责管理和调度；TaskTracker为从节点，负责执行任务。
本发明的有益效果：
1、本发明中HDFS数据分布存储时采用自适应的轮循放置策略，相比于一般的HDFS采取的随机放置策略，此优化方法可以兼顾存储和计算负载，可以将数据基本均匀地放置在DataNode，防止出现节点负载不平衡甚至出现某些节点负载过重等问题。
2、本发明中MapReduce数据并行计算将所有的map任务都在本机执行，相比于一般的MapReduce，此优化方法很大程度上减少了数据的网络传输，减少了map任务对网络传输的依赖，极大地避免了网络延迟带给应用的瓶颈，可以提高应用的执行效率。
附图说明
图1是HDFS数据分布存储阶段的步骤流程图；
图2是MapReduce数据并行计算阶段的步骤流程图。
具体实施方式
下面结合附图对本发明的实施进行详细说明。
一种Hadoop系统优化方法，包括对HDFS数据分布存储阶段的优化和对MapReduce数据并行计算阶段的优化。
如图1所示，对HDFS数据分布存储阶段的优化包括以下步骤：
步骤1.1、选择DataNode：根据Hadoop集群内每个DataNode的磁盘使用率选择具有存储能力的DataNode用于存储数据，磁盘使用率在80％以下的则认为有存储能力。
步骤1.2、对选出的DataNode排序：将已选择的DataNode根据其计算能力的大小降序排序，计算能力的大小根据CPU和内存的类型来判断。
步骤1.3、放置数据：按照步骤1.2产生的顺序采用同向增量的轮循方法，将所有Block的备份存储到选出的DataNode。同向增量的轮循方法是指每个Block的各份备份均按顺时针方向循环选取DataNote放置，并用增量区别每份备份的开始位置。所述的增量小于等于步骤1.1选出的DataNode总数的一半。
如图2所示，对MapReduce数据并行计算阶段的优化包括以下步骤：
步骤2.1、生成执行队列Q：各TaskTracker将存储在本地的Block的备份按Block编号和备份编号的增序进行排序生成各自的执行队列q，优先考虑备份编号；HDFS默认备份数是3，第i个Block的备份为Ri 0、Ri 1、Ri 2，所有TaskTracker的执行队列q统称为执行队列Q。
步骤2.2、执行R0备份：各TaskTracker顺序地执行自己队列q中备份编号为0的备份R0，若有TaskTracker的队列中没有R0备份，则不参与此次执行，当有一个TaskTracker执行完自己队列q中R0的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务。
步骤2.3、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的(包括本机处理的和其他TaskTracker处理的)Block的相同备份(R0、R1、R2)。
步骤2.4、检查执行队列Q是否为空，若空则停止执行任务。
步骤2.5、执行R1备份：各TaskTracker顺序地执行自己队列q中备份编号为1的备份R1，若有TaskTracker的队列中没有R1备份，则不参与此次执行，当有一个TaskTracker执行完自己队列q中R1的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务。
步骤2.6、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份。
步骤2.7、检查执行队列Q是否为空，若空则停止执行任务。
步骤2.8、执行R2备份：各TaskTracker顺序地执行自己队列q中备份编号为2的备份R2，若有TaskTracker的队列中没有R2备份，则不参与此次执行，当有一个TaskTracker执行完自己队列q中R2的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务。
步骤2.9、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份。
步骤2.10、检查执行队列Q是否为空，若空则停止执行任务。
步骤2.11、针对性执行：检查是否还存在个别Block的备份未进行处理，在JobTracker的协调下将没有处理的Block的备份进行最后一次针对性处理。
下面举例说明本发明的实施过程。
假设现有一个数据集，将其按固定大小可划分为15个数据块(Block)；集群可提供5个节点(DataNode1，DataNode 2……DataNode5)用于存储和计算。假设DataNode 1:DataNode 2:DataNode 3:DataNode 4:DataNode 5的计算能力比为3:2:2:1:1。
1.HDFS阶段优化策略
1.1 选择DataNode：假设这5个节点都有足够的存储能力，全部被选中。
1.2 对DataNode排序。假设这5个节点的计算能力从大到小为：
DataNode 1>DataNode2>Data Node3>DataNode4>DataNode5
1.3 放置数据。将3份备份采用本文方法放置——同向增量的数据轮循放置策略。
将第1个备份记为R0，第2个备份记为R1，第3个备份记为R2。因为每个备份都是所有数据块的完整备份，所以各包含15个数据块。
故
Figure BDA0001179293570000091
Figure BDA0001179293570000092
因为是在排好序的5个DataNode上同向增量的轮循放置，假设增量为2，可得R0的开始放置位置为第1个位置即DataNode1，R1的开始放置位置为第3个位置即DataNode3，R2的开始放置位置为第5个位置即DataNode5。可以得到各DataNode上放置3份备份的情况：
Figure BDA0001179293570000093
其中，i表示第i个Block，j表示第j个备份，s表示某节点在放置第j个备份时处于第s个位置，k表示轮循次数。
以DataNode1为例，详细说明：
(1)当放置第1个备份R0时，从DataNode1开始放置，所以DataNode1是第1个位置，即s＝1，故在DataNode1上放置R0备份的Block为
Figure BDA0001179293570000094
k可取0、1、2，即R＝{R1 0，R6 0，R11 0}。
(2)当放置第2个备份R1时，从DataNode3开始放置，所以DataNode1是第4个位置，即s＝4，故在DataNode1上放置R1备份的Block为
Figure BDA0001179293570000101
k可取0、1、2，即R＝{R4 1，R9 1，R14 1}。
(3)当放置第3个备份R2时，从DataNode5开始放置，所以DataNode1是第2个位置，即s＝2，故在DataNode1上放置R2备份的Block为
Figure BDA0001179293570000102
k可取0、1、2，即R＝{R2 2，R7 2，R12 2}。
同理，可以得到所有DataNode上存储的Block的备份为：
DataNode1：R＝{R1 0，R6 0，R11 0，R4 1，R9 1，R14 1，R2 2，R7 2，R12 2}；
DataNode2：R＝{R2 0，R7 0，R12 0，R5 1，R10 1，R15 1，R3 2，R8 2，R13 2}；
DataNode3：R＝{R3 0，R8 0，R13 0，R1 1，R6 1，R11 1，R4 2，R9 2，R14 2}；
DataNode4：R＝{R4 0，R9 0，R14 0，R2 1，R7 1，R12 1，R5 2，R10 2，R15 2}；
DataNode5：R＝{R5 0，R90 0，R15 0，R3 1，R8 1，R13 1，R1 2，R6 2，R11 2}；
2.MapReduce阶段优化策略
2.1 生成执行队列Q。同时考虑Block的编号和备份的编号进行排序，即按照Ri j的下标和上标排序，优先考虑上标，可得各TaskTracker的队列结果为：
TaskTracker1：q＝{R1 0，R6 0，R11 0，R4 1，R9 1，R14 1，R2 2，R7 2，R12 2}；
TaskTracker2：q＝{R2 0，R7 0，R12 0，R5 1，R10 1，R15 1，R3 2，R8 2，R13 2}；
TaskTracker3：q＝{R3 0，R8 0，R13 0，R1 1，R6 1，R11 1，R4 2，R9 2，R14 2}；
TaskTracker4：q＝{R4 0，R9 0，R14 0，R2 1，R7 1，R12 1，R5 2，R10 2，R15 2}；
TaskTracker5：q＝{R5 0，R10 0，R15 0，R3 1，R8 1，R13 1，R1 2，R6 2，R11 2}；
2.2 执行R0备份。因为DataNode1:DataNode2:DataNode3:DataNode4:DataNode5的计算能力比为3:2:2:1:1。可见，TaskTracker1将率先完成处理R0备份。此时，所有TaskTracker分别已处理的Block的备份为：
TaskTracker1：{R1 0，R6 0，R11 0}，TaskTracker2：{R2 0，R7 0}，TaskTracker3：{R3 0，R8 0}，TaskTracker4：{R4 0}；TaskTracker5：{R5 0}；
2.3 更新执行队列Q。所有TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份。即删除那些与已被处理的Block的备份下标相同的备份。可得结果为：
TaskTracker1：q＝{R9 1，R14 1，R12 2}；
TaskTracker2：q＝{R12 0，R10 1，R15 1，R13 2}；
TaskTracker3：q＝{R13 0，R9 2，R14 2}；
TaskTracker4：q＝{R9 0，R14 0，R12 1，R10 2，R15 2}；
TaskTracker5：q＝{R10 0，R15 0，R13 1}；
2.4 检查执行队列Q是否为空。可见所有TaskTracker的执行队列q不为空。
2.5 执行R1备份。因为TaskTracker3的执行队列q中没有R1的备份，其不参与此次执行。TaskTracker1还是率先完成处理R1备份。因为要其他TaskTracker要处理完当前任务才结束执行，所以此时所有TaskTracker分别已处理的Block的备份为：
TaskTracker1：{R9 1，R14 1}，TaskTracker2：{R10 1，R15 1}，TaskTracker3：{}，TaskTracker4：{R12 1}，TaskTracker5：{R13 1}。
2.6 更新执行队列Q。可得结果为：
TaskTracker1：q＝{}；
TaskTracker2：q＝{}；
TaskTracker3：q＝{}；
TaskTracker4：q＝{}；
TaskTracker5：q＝{}；
2.7 检查执行队列Q是否为空。可见所有TaskTracker的执行队列全部为空，表明任务已完全处理，任务处理结束。

Claims (5)

1.一种Hadoop系统优化方法，其特征在于：包括对HDFS数据分布存储阶段的优化和对MapReduce数据并行计算阶段的优化；其中，对HDFS数据分布存储阶段的优化包括以下步骤：
步骤1.1、选择DataNode：根据Hadoop集群内每个DataNode的磁盘使用率选择具有存储能力的DataNode用于存储数据；
步骤1.2、对选出的DataNode排序：将已选择的DataNode根据其计算能力的大小降序排序；
步骤1.3、放置数据：按照步骤1.2产生的顺序采用同向增量的轮循方法，将所有Block的备份存储到选出的DataNode；
同向增量的轮循方法是指每个Block的各份备份均按顺时针方向循环选取DataNote放置，并用增量区别每份备份的开始位置，所述的增量小于等于步骤1.1选出的DataNode总数的一半；
对MapReduce数据并行计算阶段的优化包括以下步骤：
步骤2.1、生成执行队列Q：各TaskTracker将存储在本地的Block的备份按Block编号和备份编号的增序进行排序生成各自的执行队列q，优先考虑备份编号；HDFS默认备份数是3，第i个Block的备份为Ri0、Ri1、Ri2，所有TaskTracker的执行队列q统称为执行队列Q；
步骤2.2、执行R0备份：各TaskTracker顺序地执行自己队列q中备份编号为0的备份R0，当有一个TaskTracker执行完自己队列q中R0的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务；
步骤2.3、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份；
步骤2.4、检查执行队列Q是否为空，若空则停止执行任务；
步骤2.5、执行R1备份：各TaskTracker顺序地执行自己队列q中备份编号为1的备份R1，当有一个TaskTracker执行完自己队列q中R1的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务；
步骤2.6、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份；
步骤2.7、检查执行队列Q是否为空，若空则停止执行任务；
步骤2.8、执行R2备份：各TaskTracker顺序地执行自己队列q中备份编号为2的备份R2，当有一个TaskTracker执行完自己队列q中R2的备份时停止执行任务；同时，JobTracker通知其他TaskTracker执行完当前任务后停止执行任务；
步骤2.9、更新执行队列Q：在JobTracker的协调下，各TaskTracker从自己的执行队列q中删除所有已经被处理的Block的相同备份；
步骤2.10、检查执行队列Q是否为空，若空则停止执行任务；
步骤2.11、针对性执行：检查是否还存在个别Block的备份未进行处理，在JobTracker的协调下将没有处理的Block的备份进行最后一次针对性处理。
2.根据权利要求1所述的Hadoop系统优化方法，其特征在于：步骤1.1中选择DataNode的标准是磁盘使用率在80％以下的视为有存储能力。
3.根据权利要求1所述的Hadoop系统优化方法，其特征在于：步骤1.2中，通过CPU和内存的类型判断计算能力大小。
4.根据权利要求1所述的Hadoop系统优化方法，其特征在于：步骤2.3、2.6和2.9中已经被处理的备份既包括本机处理的备份，也包括其他TaskTracker处理的备份，相同备份是指针对同一Block的备份，包括R0、R1、R2。
5.根据权利要求1所述的Hadoop系统优化方法，其特征在于：步骤2.2中若有TaskTracker的队列中没有R0备份，则不参与此次执行，步骤2.5、2.8同样处理。
CN201611148198.3A 2016-12-13 2016-12-13 一种Hadoop系统优化方法 Expired - Fee Related CN106599184B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611148198.3A CN106599184B (zh) 2016-12-13 2016-12-13 一种Hadoop系统优化方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611148198.3A CN106599184B (zh) 2016-12-13 2016-12-13 一种Hadoop系统优化方法

Publications (2)

Publication Number Publication Date
CN106599184A CN106599184A (zh) 2017-04-26
CN106599184B true CN106599184B (zh) 2020-03-27

Family

ID=58801937

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611148198.3A Expired - Fee Related CN106599184B (zh) 2016-12-13 2016-12-13 一种Hadoop系统优化方法

Country Status (1)

Country Link
CN (1) CN106599184B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107168802A (zh) * 2017-05-18 2017-09-15 郑州云海信息技术有限公司 一种云存储中小文件的合并方法及装置
CN108491167B (zh) * 2018-03-29 2020-12-04 重庆大学 一种工业过程工况数据快速随机分布存储方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104239520A (zh) * 2014-09-17 2014-12-24 西安交通大学 一种基于历史信息的hdfs数据块放置策略
CN104809231A (zh) * 2015-05-11 2015-07-29 浪潮集团有限公司 一种基于Hadoop的海量web数据挖掘方法
CN105487930A (zh) * 2015-12-01 2016-04-13 中国电子科技集团公司第二十八研究所 一种基于Hadoop的任务优化调度方法
CN106021285A (zh) * 2016-04-29 2016-10-12 武汉佰钧成技术有限责任公司 一种基于Hadoop平台的海量数据增量抽取与分析方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015194855A (ja) * 2014-03-31 2015-11-05 富士通株式会社 情報処理システム、制御プログラム、及び情報処理システムの制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104239520A (zh) * 2014-09-17 2014-12-24 西安交通大学 一种基于历史信息的hdfs数据块放置策略
CN104809231A (zh) * 2015-05-11 2015-07-29 浪潮集团有限公司 一种基于Hadoop的海量web数据挖掘方法
CN105487930A (zh) * 2015-12-01 2016-04-13 中国电子科技集团公司第二十八研究所 一种基于Hadoop的任务优化调度方法
CN106021285A (zh) * 2016-04-29 2016-10-12 武汉佰钧成技术有限责任公司 一种基于Hadoop平台的海量数据增量抽取与分析方法

Also Published As

Publication number Publication date
CN106599184A (zh) 2017-04-26

Similar Documents

Publication Publication Date Title
CN102831120B (zh) 一种数据处理方法及系统
CN103309738B (zh) 用户作业调度方法及装置
Venkataraman et al. The power of choice in {Data-Aware} cluster scheduling
JP5998206B2 (ja) クラスタデータグリッドにおける拡張可能な中央集中型動的リソース分散
Ge et al. GA-based task scheduler for the cloud computing systems
EP2419845B1 (en) Policy-based storage structure distribution
CN103369042B (zh) 一种数据处理方法和装置
Hedlund Understanding Hadoop clusters and the network
CN103312825B (zh) 一种数据分布存储方法和装置
CN108810115B (zh) 一种适用于分布式数据库的负载均衡方法、装置及服务器
CN102752198A (zh) 多核报文转发方法、多核处理器及网络设备
CN104199739A (zh) 一种基于负载均衡的推测式Hadoop调度方法
CN106101213A (zh) 信息分布式存储方法
JP2014186364A (ja) 分散システム
JP2019517065A (ja) 再構成可能な分散処理
CN106599184B (zh) 一种Hadoop系统优化方法
Lin et al. A load-balancing algorithm for hadoop distributed file system
Li et al. {MilliSort} and {MilliQuery}:{Large-Scale}{Data-Intensive} Computing in Milliseconds
Fink Distributed computation on dynamo-style distributed storage: riak pipe
Mao et al. A fine-grained and dynamic MapReduce task scheduling scheme for the heterogeneous cloud environment
CN106547629A (zh) 一种状态机副本管理模型的优化方法
CN113590281A (zh) 基于动态集中式调度的分布式并行模糊测试方法及系统
Mao et al. FiGMR: A fine-grained mapreduce scheduler in the heterogeneous cloud
Lim et al. Heuristic neighbor selection algorithm for decentralized load balancing in clustered heterogeneous computational environment
Rahmati et al. Data replication-based scheduling in cloud computing environment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20200327

Termination date: 20201213