CN105610621B - 一种分布式系统架构任务级参数动态调整的方法及装置 - Google Patents

Abstract

本发明公开了一种分布式系统架构任务级参数动态调整的方法及装置，涉及云计算技术领域；解决了每个任务的参数配置不能在作业运行过程中动态地根据用户需求调整的技术问题；该技术方案包括：步骤一，在作业对象初始化时创建一个配置服务线程，该线程会每隔预定时间检查是否有新的p组配置；步骤二，如果有则优先为其分配资源；步骤三，每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置。

Description

一种分布式系统架构任务级参数动态调整的方法及装置

技术领域

本发明涉及云计算技术领域，特别涉及一种分布式系统架构任务级参数动态调整的方法及装置。

背景技术

MapReduce编程模型的思想来源于函数式编程语言Lisp，由Google公司于2004年提出并首先应用于大型集群。目前，Hadoop/MapReduc作为一个分布式大数据处理平台是该编程模型最成功的开源实现，由于其良好的扩展性和容错性，已得到越来越广泛的应用。

Hadoop目前有多达190个配置参数，其中大约有20个左右的参数对MapReduce作业的性能有显著的影响。通过这些参数可以进行三个方面的性能调优：CPU、内存和I/O优化。

这些参数根据参数设置的过程可以分为两类：任务的资源申请阶段配置的参数和任务资源分配后配置的参数。像mmmm、mrmm、mmcv和mrcv的重新配置均需要重新向Hadoop的资源调度器重新申请，当得到合适的资源后会根据数据局部化计算的要求分配给符合要求的任务，得到该资源的任务会进一步配置其它的参数，然后运行。所以作业在运行阶段动态调整参数需要考虑参数的配置流程。

每个MapReduce作业一般包括两种类型的任务：map任务和reduce任务。正是一定数量的map任务和reduce任务以分布式并行运行的方式完成了一个MapReduce作业的运行。不同的任务的工作量由于处理的数据的差异会不一样，然而，Hadoop在运行状态下并不支持不同任务参数的动态调整，虽然Hadoop对这些参数提供了默认的配置值，但是使用默认的配置并不能很好地适应不同任务的工作负载，这限制了MapReduce任务级的性能优化，从而导致Hadoop集群性能地衰减。

目前，已有的参数配置机制都是在Hadoop/MapReduce的离线状态下实施配置过程的，而作业在Hadoop/MapReduce上运行时，配置不会发生改变，而每个作业的配置也是完全一样。这对于连续运行的作业序列和数据计算分布不均匀的作业，这种配置机制不再适应。首先连续运行的作业序列在运行过程中配置需要根据不同的作业类型进行调整，因为不同的作业类型使用的CPU和I/O资源有可能不一样，固定的一种配置不再适应不同作业类型构成的序列。对于数据计算分布不均匀的作业，这种作业输入的数据量大，处理这些数据的不同部分耗费的CPU资源是不一样的，当数据处理耗费的资源发生变化时就有必要调整Hadoop/MapReduce的参数配置以适应新的情况，使得作业完成的时间达到最优。

发明内容

本发明要解决的是每个任务的参数配置不能在作业运行过程中动态地根据用户需求调整的技术问题。

为了解决上述问题，本发明提供了一种分布式系统架构任务级参数动态调整的方法，包括：步骤一，在作业对象初始化时创建一个配置服务线程，该线程每隔预定时间检查是否有新的p组配置；步骤二，如果有则优先为其分配资源；步骤三，每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置。

本发明还提供了一种分布式系统架构任务级参数动态调整的装置，包括：配置服务模块，用于在作业对象初始化时创建一个配置服务线程，该线程每隔预定时间检查是否有新的p组配置；资源再申请模块，用于如果有新的p组配置则优先为其分配资源；第二次配置模块，用于每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置。

本发明的技术方案实现了一种分布式系统架构任务级参数动态调整的方法及装置，增加了配置服务、资源再申请和配置装配服务，实现了Hadoop MapReduce任务级的性能参数动态配置功能。使得Hadoop/MapReduce在作业运行过程中不中断每个任务运行的前提下，能根据用户的需要动态调整每个任务的参数，让用户能够根据作业实际的运行情况动态地调整每个任务的参数以实现更好地在线性能优化。

附图说明

图1一种分布式系统架构任务级参数动态调整的方法流程图；

图2任务级参数动态配置结构示意图；

图3任务级参数动态配置流程图；

图4一种分布式系统架构任务级参数动态调整的装置示意图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本发明实施例以及实施例中的各个特征可以相互结合，均在本发明的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一，一种分布式系统架构任务级参数动态调整的方法，如图1所示，包括：

步骤一，在作业对象初始化的时创建一个配置服务线程，该线程每隔预定时间检查是否有新的p组配置；

具体的，本发明的技术方案创建的一个单独的配置服务线程，并设置每秒或其它预定时间，比如N秒，监控用户给定位置的配置文件的更新和作业是否完成。其中，p为正整数。

步骤二，如果有则优先为其分配资源；

具体的，本发明的技术方案设计了资源再申请的机制。设用户每次提供p组(p<＝(n-m))配置,每组需要配置的参数有k个，每组配置的格式为一个向量，则其中第i组配置为i＝{Ci1,Ci2,Ci3…Cik}，那么关于任务资源分配的参数可以设置为前四位Ci1,Ci2,Ci3和Ci4。其中Ci1和Ci2是map任务关于资源分配的参数，Ci3和Ci4则为reduce任务关于资源分配的参数。当这p组配置更新时，本机制将这p组配置保存在一个java的哈希map数据结构中同时将该结构拷贝一份给资源装配服务。设第i组配置Vi则保存为Map<i,Vi>，该数据结构设为Config。本机制在Hadoop的资源分配对象中设计的资源再申请机制会根据这p组配置中关于任务资源分配的参数值重新向Hadoop的资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后会优先为这p个资源申请分配资源，这种方式下，资源调度器并没有中断其它非动态配置的任务的资源分配。

步骤三，每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置。

具体的，本发明的技术方案在第二次配置过程中，每个任务自己负责动态调整参数，当任务通过自身id在资源装配服务中检索到自己的配置后，在任务初始化的时候就完成了第二次参数的配置，如果任务没有在资源装配服务中检索到自己的配置，则跳过配置，继续运行。

实施例二，一种分布式系统架构任务级参数动态调整的方法，在实施例一的基础上如图2至3所示，包括：

更优地，所述步骤一，如果有则优先为其分配资源具体为，当p组配置参数更新后，则通知给作业分配对象，所述作业分配对象包括资源再申请机制，所述资源再申请机制根据所述p组配置中关于任务资源分配的参数值重新向资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后优先为所述p个资源申请分配资源。

更优地，所述步骤一p组配置更新时，设用户每次提供p组配置，每组需要配置的参数有k个，每组配置的格式为一个向量，则其中第i组配置为Vi＝{Ci1,Ci2,Ci3…Cik}，将这p组配置保存在一个java的哈希map数据结构中，设第i组配置Vi则保存为Map<i,Vi>。

更优地，所述步骤二之后，步骤三之前，调用资源装配服务，所述资源装配服务内部维护了两个数据结构，一个负责保存参数的组数和具体的参数值以及它们的映射关系，另个一个负责保存任务的id与参数的组数之间的映射关系，所述资源装配服务利用这两个数据结构实现任务id与配置的匹配。

更优地，每p组参数配置完成后，所述配置服务线程会检测作业是否完成，如果完成则结束配置服务线程，如果没有则继续检查p组参数的配置文件是否更新，如果更新则继续步骤二、三的过程，直到作业完成结束配置服务。

如图2所示，任务对象(TaskImpl)，任务运行对象(TaskAttemptImpl)和作业对象(JobImpl)都是Hadoop yarn系统中实现的管理实际作业运行的对象，这些对象的运行过程Hadoop系统将它们划分成许多状态(如创建，初始化，运行和结束等)，图2中的这三个对象只例举了其中几个主要的对象转换。本技术方案的是通过分析这些对象的运行流程和状态转换过程而设计的。主要在Hadoop yarn的源码中设计了配置服务、资源再申请服务和配置装配服务，通过增加这些服务实现了任务级的参数动态配置机制。

如图3所示，首先当用户从终端提交给Hadoop系统一个MapReduce作业后，本机制会在作业对象初始化的时候创建一个单独的配置服务线程，设置每秒监控用户给定位置的配置文件的更新和作业是否完成。

当用户给定的p组配置参数没有更新则继续检查，该线程并不阻塞和暂停运行中的作业任务。

当用户给定的p组配置参数更新后，则通过一个同步的标志变量通知给Hadoop的作业分配对象，该对象在Hadoop源码中的名称为RMContainerAllocator，本发明技术方案在该对象中增加了资源再申请机制。该机制会根据这p组配置中关于任务资源分配的参数值重新向Hadoop的资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后会优先为这p个资源申请分配资源。在这种资源再申请的情况下，资源调度器并没有中断其它非动态配置的任务的资源分配，由此本机制也并没有阻塞和暂停运行中的作业任务。

本技术方案还设计了一个资源装配服务，当Hadoop的资源调度器将申请的资源提交给RMContainerAllocator对象后，该对象会调用资源装配服务，该服务内部维护了两个Java的Hash Map结构：Config和taskConfig。Config负责保存参数的组数和具体的参数值以及它们的映射关系，而taskConfig负责保存任务的id与参数的组数之间的映射关系。资源装配服务会利用这两个数据结构实现任务id与配置的匹配。

在第二次配置过程中，每个任务自己负责动态调整参数，当任务通过自身id在资源装配服务中检索到自己的配置后，在任务初始化的时候就完成了第二次参数的配置，如果任务没有在资源装配服务中检索到自己的配置，则跳过配置，继续运行。

每p组参数配置完成后，配置服务线程会检测作业是否完成，如果完成则结束配置服务线程，如果没有则继续检查用户给定的p组参数的配置文件是否更新，如果更新则继续上述的过程，直到作业完成结束配置服务。

该机制的实质是通过重新设计了Hadoop Yarn中的作业对象、任务试运行对象和资源分配对象，增加了配置服务和配置装配服务，实现了Hadoop MapReduce任务级的性能参数动态配置功能。

为了实现Hadoop作业在运行过程中的动态地修改任务级参数配置，同时还要保证不中断每个任务的运行流程，需要研究Hadoop的作业任务从提交、创建、初始化到运行的流程，根据任务运行流程中每个参数的特点和使用时机设计参数配置的机制。这些参数主要分为两种，一种是关于任务资源分配的参数，这类参数的配置需要在任务创建之前实施，而且还需要向Hadoop的资源调度器进行申请；一种是关于任务资源如何使用的参数，这类参数需要在任务初始化的时候配置，不依赖Hadoop系统中的其它对象。

针对这两类参数的配置需要进行两次配置，第一次在任务申请资源后等待合适的资源释放时，第二次在任务运行后的初始化时。所有Map任务的资源申请在作业创建之时就已经向Hadoop的资源调度器提交了，作业调度器会根据实际的硬件资源调度一定数量的任务同时运行，其它的任务会等待资源释放后运行，所有Reduce任务也需要等待Map任务完成一定的数量后才能向Hadoop的调度器申请资源，只有释放了足够的符合任务运行条件的资源后任务才能运行。本发明的动态配置机制正是为这些等待资源释放后再运行的任务设计的。

具体的，第一次配置时，Hadoop本身的机制是所有任务(设为n个任务)会根据默认配置向资源调度器提交资源申请，资源调度器会根据实际的资源调度m个任务运行，那么其它的n-m个任务则为本机制的动态配置的对象。设用户每次提供p组(p<＝(n-m))配置,每组需要配置的参数有k个，每组配置的格式为一个向量，则其中第i组配置为Vi＝{Ci1,Ci2,Ci3…Cik}，那么关于任务资源分配的参数可以设置为前四位Ci1,Ci2,Ci3和Ci4。其中Ci1和Ci2是map任务关于资源分配的参数，Ci3和Ci4则为reduce任务关于资源分配的参数。

当这p组配置更新时，本发明将这p组配置保存在一个java的哈希map数据结构中，设第i组配置Vi则保存为Map<i,Vi>，该数据结构设为Config。本发明在Hadoop的资源分配对象中设计了资源再申请机制，该机制会根据这p组配置中关于任务资源分配的参数值重新向Hadoop的资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后会优先为这p个资源申请分配资源，这种方式下，资源调度器并没有中断其它非动态配置的任务的资源分配。当找到符合条件的资源时，具体的任务会得到该资源，每一个任务在创建后Hadoop都分配了一个独一无二的任务id，设id为t的任务得到了p组配置中的第i组资源，则本机制设计的配置装配服务会为这组匹配保存到一个java的哈希map数据结构中，键为t,值为i,设该数据结构为taskConfig。此时完成了第一次配置的过程，第二次配置发生在任务运行后的初始化过程中，每个任务会根据自身的id查询taskConfig数据结构，找到配置的组数后，再利用组数i通过数据结构Config搜索到具体的配置Vi,根据Vi的配置值动态配置任务的对于参数值，这样就完成了一个任务的两次参数配置过程。

为了在配置过程中不阻塞任务的运行，本发明设计了一个配置服务线程，该线程作为一个单独的线程在作业创建的时候开始运行。该线程会每隔1秒钟检查用户是否提供了新的p组配置，如果提供了则获取该组配置参数并将该组参数放置在一个需要同步访问的列表中，随后更新配置变化的标志，Hadoop作业检测到该标志变化后选择轮候到的任务进行配置后再运行，如果用户还没有提供新的p组配置参数，Hadoop作业则不进行配置变化操作，且后续的任务一直保持正常运行的状态。这样任务被重新配置和不重新配置都不会中断和阻塞它的运行，而且这一过程对于用户而言是完全透明的。

实施例三，一种分布式系统架构任务级参数动态调整的装置，如图4所示，包括：配置服务模块，用于在作业对象初始化时创建一个配置服务线程，该线程每隔预定时间检查是否有新的p组配置；资源再申请模块，用于如果有新的p组配置则优先为其分配资源；第二次配置模块，用于每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置。

更优地，所述配置服务模块，如果有新的p组配置则优先为其分配资源具体为，当p组配置参数更新后，则通知给作业分配对象，所述作业分配对象包括资源再申请机制，所述资源再申请机制根据所述p组配置中关于任务资源分配的参数值重新向资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后优先为所述p个资源申请分配资源。

更优地，所述配置服务模块p组配置更新时，设用户每次提供p组配置，每组需要配置的参数有k个，每组配置的格式为一个向量，则其中第i组配置为Vi＝{Ci1,Ci2,Ci3…Cik}，将这p组配置保存在一个java的哈希map数据结构中，设第i组配置Vi则保存为Map<i,Vi>。

更优地，所述资源再申请模块作用之后，第二次配置模块作用之前，调用资源装配服务模块，所述资源装配服务模块内部维护了两个数据结构，一个负责保存参数的组数和具体的参数值以及它们的映射关系，另个一个负责保存任务的id与参数的组数之间的映射关系，所述资源装配服务利用这两个数据结构实现任务id与配置的匹配。

更优地，每p组参数配置完成后，所述配置服务线程会检测作业是否完成，如果完成则结束配置服务线程，如果没有则继续检查p组参数的配置文件是否更新，如果更新则继续资源再申请、第二次参数配置的过程，直到作业完成结束配置服务。

一种分布式系统架构任务级参数动态调整的装置与一种分布式系统架构任务级参数动态调整的方案一一对应，具体说明同实施例一、二。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明的权利要求的保护范围。

Claims (8)

1.一种分布式系统架构任务级参数动态调整的方法，该方法主要在Hadoop yarn的源码中设计了配置服务、资源再申请服务和配置装配服务，通过增加这些服务实现了任务级的参数动态配置机制，该方法包括：步骤一，在作业对象初始化时创建一个配置服务线程，该线程每隔预定时间检查是否有新的p组配置；步骤二，如果有则优先为所述新的p组配置分配资源；步骤三，每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置；

该方法设计了资源再申请的机制，设用户每次提供p组(p<＝(n-m))配置,每组需要配置的参数有k个，每组配置的格式为一个向量，则其中第i组配置为i＝{Ci1,Ci2,Ci3…Cik}，将任务资源分配的参数设置为前四位Ci1,Ci2,Ci3和Ci4，其中Ci1和Ci2是map任务关于资源分配的参数，Ci3和Ci4则为reduce任务关于资源分配的参数，当这p组配置更新时，将这p组配置保存在一个java的哈希map数据结构中同时将该结构拷贝一份给资源装配服务，设第i组配置Vi则保存为Map<i,Vi>，该数据结构设为Config，在Hadoop的资源分配对象中设计的资源再申请机制会根据这p组配置中关于任务资源分配的参数值重新向Hadoop的资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后会优先为这p个资源申请分配资源，这种方式下，资源调度器并没有中断其它非动态配置的任务的资源分配；

其中，p为正整数。

2.如权利要求1所述的任务级参数动态调整的方法，其特征在于，所述步骤一，如果有则优先为其分配资源具体为，当p组配置参数更新后，则通知给作业分配对象，所述作业分配对象包括资源再申请机制，所述资源再申请机制根据所述p组配置中关于任务资源分配的参数值重新向资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后优先为p个资源申请分配资源。

3.如权利要求1所述的任务级参数动态调整的方法，其特征在于，所述步骤二之后，步骤三之前，调用资源装配服务，所述资源装配服务内部维护了两个数据结构，一个负责保存参数的组数和具体的参数值以及它们的映射关系，另个一个负责保存任务的id与参数的组数之间的映射关系，所述资源装配服务利用这两个数据结构实现任务id与配置的匹配。

4.如权利要求1所述的任务级参数动态调整的方法，其特征在于，每p组参数配置完成后，所述配置服务线程会检测作业是否完成，如果完成则结束配置服务线程，如果没有则继续检查p组参数的配置文件是否更新，如果更新则继续步骤二、三的过程，直到作业完成结束配置服务。

5.一种分布式系统架构任务级参数动态调整的装置，其主要在Hadoop yarn的源码中设计了配置服务、资源再申请服务和配置装配服务，通过增加这些服务实现了任务级的参数动态配置机制，该装置包括：配置服务模块，用于在作业对象初始化时创建一个配置服务线程，该线程每隔预定时间检查是否有新的p组配置；资源再申请模块，用于如果有新的p组配置则优先为其分配资源；第二次配置模块，用于每个任务通过自身id检索到自己的配置后，在任务初始化时完成第二次参数的配置；

该装置设计了资源再申请的机制，设用户每次提供p组(p<＝(n-m))配置,每组需要配置的参数有k个，每组配置的格式为一个向量，则其中第i组配置为i＝{Ci1,Ci2,Ci3…Cik}，那么关于任务资源分配的参数可以设置为前四位Ci1,Ci2,Ci3和Ci4，其中Ci1和Ci2是map任务关于资源分配的参数，Ci3和Ci4则为reduce任务关于资源分配的参数，当这p组配置更新时，将这p组配置保存在一个java的哈希map数据结构中同时将该结构拷贝一份给资源装配服务，设第i组配置Vi则保存为Map<i,Vi>，该数据结构设为Config，在Hadoop的资源分配对象中设计的资源再申请机制会根据这p组配置中关于任务资源分配的参数值重新向Hadoop的资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后会优先为这p个资源申请分配资源，这种方式下，资源调度器并没有中断其它非动态配置的任务的资源分配；

其中，p为正整数。

6.如权利要求5所述的任务级参数动态调整的装置，其特征在于，所述配置服务模块，如果有新的p组配置则优先为其分配资源具体为，当p组配置参数更新后，则通知给作业分配对象，所述作业分配对象包括资源再申请机制，所述资源再申请机制根据所述p组配置中关于任务资源分配的参数值重新向资源调度器提交一个优先级高于非动态配置的任务优先级的资源申请，资源调度器接收到该申请后优先为所述p个资源申请分配资源。

7.如权利要求5所述的任务级参数动态调整的装置，其特征在于，所述资源再申请模块作用之后，第二次配置模块作用之前，调用资源装配服务模块，所述资源装配服务模块内部维护了两个数据结构，一个负责保存参数的组数和具体的参数值以及它们的映射关系，另个一个负责保存任务的id与参数的组数之间的映射关系，所述资源装配服务利用这两个数据结构实现任务id与配置的匹配。

8.如权利要求5所述的任务级参数动态调整的装置，其特征在于，每p组参数配置完成后，所述配置服务线程会检测作业是否完成，如果完成则结束配置服务线程，如果没有则继续检查p组参数的配置文件是否更新，如果更新则继续资源再申请、第二次参数配置的过程，直到作业完成结束配置服务。