CN103279390A - 一种面向小作业优化的并行处理系统 - Google Patents

Abstract

本发明涉及一种面向小作业优化的并行处理系统，由下至上依次包括资源管理模块、资源伸缩模块、计算系统模块、模型翻译模块和作业逻辑模块；所述资源管理模块实现对整体系统的资源管理并提供管理平台；所述资源伸缩模块在管理平台上为计算系统模块提供工作节点；所述计算系统模块是系统的运行时的环境，用于实现在一个JVMJava虚拟机中的不同线程之间直接共享数据；所述模型翻译模块用于将作业逻辑翻译成运行环境中可识别的工作流；所述作业逻辑模块用于设置数据传输模式和逻辑表达模型。本发明实现了一套编程可扩展、资源可伸缩的并行处理系统Binos，以及Binos-HashMR和Binos-FileMR两套不同的MapReduce编程模型，通过数据存储、传输、处理逻辑等相关方面的优化，显著提高了小作业的执行效率。

Description

一种面向小作业优化的并行处理系统

技术领域

本发明涉及一种面向小作业优化的并行处理系统，属于分布式计算机领域。

背景技术

近年来，分布式数据处理系统成为了海量数据处理的解决方案。针对不同的应用场景，学术界和产业界，推出了多个并行处理系统。研究分析不同的并行处理系统，总结出编程模型是由处理逻辑、数据组织、传输模式三部分构成。随着应用逻辑的发展，现有的并行处理系统，很难快速实现处理逻辑、应用特征相适应的数据组织和传输方式组合定制。

根据实际生产集群下作业特征的分析，大部分作业为输入数据量较小、占有资源较少的小作业，如何提高小作业的执行效率成为了并行处理系统面临的重要问题。根据国外大型互联网公司的生产集群的日志显示，作业的资源利用率不高，Facebook的Hadoop集群中，作业的平均CPU利用率为16%，平均内存利用率为19%。如何提高集群的资源利用率、加快小作业的执行效率，成为当前分布式数据处理系统相关研究中面临的重要问题。

针对目前分布式数据处理系统出现的问题，学术界和工业界提出了相关的系统和系统。为了解决MapReduce编程模型的表达能力的局限性，工业界提出了Pig、Hive、Cascading等相关的系统，通过MR作业的组装，实现了复杂的作业逻辑。这种方式虽然扩展了MapReduce编程模型的应用范畴，但是简单地按照作业逻辑顺序提交MR子作业，不利于作业的全局调度优化、以及作业与作业之间的数据传输方式的灵活定制，从而影响了作业的执行效率。学术界提出了CIEL、Transformer等系统，通过基本的操作原语构建多种作业逻辑，这种方式可以很好地表达不同的作业逻辑，但是，固定的数据传输模式，使得在满足不同的应用需求上还存在困难。为了提高生产集群内资源的利用率，Berkeley大学开发了一套支持多种系统的分布式资源共享平台Mesos，Mesos通过接管运行时环境下的调度器，按照作业的需求匹配工作节点中的可用资源，使得在统一的资源平台上可以共享使用多个系统。Mesos在一定程度上提供了分布式环境下资源的利用率，但是需要介入系统调度器内部的方式，使得系统的扩展性存在一定的压力。Hadoop-Yarn是为了解决MapReduce单一编程模型的问题而来，将资源管理和作业执行逻辑的维护分离，通过Application-Master维护作业逻辑和资源请求，实现作业的部署和执行。虽然Mesos和Yarn提出了支持多种编程模型的方法，但是在支持小作业等方面，由于是按需申请资源，而实际的生产集群内小作业数目多，占有资源少的特点，使得作业的执行效率受到了资源频繁申请和释放的影响。图1为Yarn下不同输入数据量对执行效率的影响，通过图1可以看出，在输入数据量较小时，由于作业内资源动态申请与释放，使得系统仍然有较大的时间开销。

我们分析了当前并行处理系统的发展现状，结合实际生产集群内小作业的需求特点，提出了一种加速小作业执行效率的并行处理系统Binos。

发明内容

本发明所要解决的技术问题是针对输入数据量小、占有资源少的特点，提供一种面向小作业优化的并行处理系统。

本发明解决上述技术问题的技术方案如下：一种面向小作业优化的并行处理系统，由下至上依次包括资源管理模块、资源伸缩模块、计算系统模块、模型翻译模块和作业逻辑模块；

所述资源管理模块实现对整体系统的资源管理并提供管理平台；

所述资源伸缩模块在资源管理模块之上，通过资源的申请与释放，实现对于上层计算系统模块的资源供应和回收；

所述计算系统模块是系统的运行时的环境，用于实现在一个JVMJava虚拟机中的不同线程之间直接共享数据，并在资源伸缩模块提供的工作节点的基础上建立分布式内存系统；

所述模型翻译模块运行在计算系统模块之上，为作业提供表达逻辑的基本单元，将作业逻辑模块表达的逻辑翻译成计算系统内可以识别的执行体；

所述作业逻辑模块用于设置数据传输模式和逻辑表达模型。

本发明的有益效果是：本发明所述在该系统下设计了Binos-FileMR、Binos-HashMR两种MapReduce编程模型，与Hadoop的MapReduce编程模型在相同实验环境下，执行词频统计作业，统计在不同输入数据量下执行时间的对比；Binos-HashMR对Hadoop-MR在词频统计应用中的加速比，基本上在3倍左右。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步，所述模型翻译模块将作业翻译成子任务和通道两种基本元素，所述子任务是执行计算的单位，所述通道是与子任务相关的输入输出通路。

所述子任务之间具有两种逻辑关系，包括并行关系和依赖关系；

所述并行关系包括同源并行关系和异源并行关系，所述同源并行关系指具有相同计算逻辑的子任务之间的关系；所述异源并行关系指不同计算逻辑的子任务之间的关系；

所述依赖关系包括调度依赖关系和执行依赖关系，所述调度依赖关系指一个子任务被调度后，开始调度与其具有调度依赖关系的子任务；所述执行依赖关系指一个子任务执行之后，开始调度与其具有执行依赖关系的子任务。

进一步，所述作业逻辑模块将具有相同计算逻辑的至少两个子任务进行封装成簇任务，所述簇任务之间通过隧道进行通信，所述隧道包括两个簇任务之间所有的数据通道，并将所述的数据通道标识为相同属性。

进一步，所述计算系统模块用于将工作节点中的数据存储到进程内存中，进入计算系统模块中的子任务通过读取进程内存中的数据与工作节点实现通信，并将子任务产生的中间数据存储入进程内存。

采用上述进一步方案的有益效果是，子任务可以之间从工作节点的进程内存中读取数据，避免了数据序列化、存取本地磁盘或其他数据容器的开销。

进一步，所述资源管理模块为Yarn分布式资源管理平台。

采用上述进一步方案的有益效果是，分布式资源管理平台为每一个计算系统提供资源，保证最低资源配置，并监控系统内工作节点的状态，保证工作节点个数，同时，实现动态分配资源。

进一步，所述资源伸缩模块用于提供固定资源配置和动态资源科伸缩的资源使用方法，所述资源使用方法通过队列饱和度监控系统的任务工作负载状况，按照容忍区间的设置，在包装最低资源供应的前提下，动态调整工作节点的个数。

附图说明

图1为Yarn下不同输入数据量对执行效率的影响示意图；

图2为本发明实施例1所述的一种面向小作业优化的并行处理系统结构示意图；

图3为本发明实施例1所述模型翻译模块逻辑关系模型示意图；

图4为本发明实施例1所述子任务之间逻辑关系与传输模型关系图；

图5为本发明实施例1所述计算系统模块中进程级与线程级任务调度示意图；

图6为本发明实施例1所述计算系统模块中分布式内存系统部署示意图；

图7为本发明实施例1所述计算系统模块中分布式内存系统中DataDaemon功能结构图；

图8为本发明实施例1所述资源伸缩模块中资源动态管理器Binos-Manager系统图；

图9为本发明实施例1所述的一种面向小作业优化的并行处理系统定制的Binos-HashMR的双向链表结构示意图。

附图中，各标号所代表的部件列表如下：

1、资源管理模块，2、资源伸缩模块，3、计算系统模块，4、模型翻译模块，5、作业逻辑模块。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

如图2所示，本发明实施例1所述的一种面向小作业优化的并行处理系统，由下至上依次包括资源管理模块1、资源伸缩模块2、计算系统模块3、模型翻译模块4和作业逻辑模块5；所述资源管理模块1实现对整体系统的资源管理并提供管理平台；所述资源伸缩模块2在管理平台上为计算系统模块提供工作节点；所述计算系统模块3是系统的运行时的环境，用于实现在一个JVMJava虚拟机中的不同线程之间直接共享数据，并在资源伸缩模块2提供的工作节点的基础上建立分布式内存系统；所述模型翻译模块4用于将作业逻辑翻译成运行环境中可识别的工作流；所述作业逻辑模块5用于设置数据传输模式和逻辑表达模型。

所述模型翻译模块4将作业翻译成子任务和通道两种基本元素，所述子任务是执行计算的单位，所述通道是与子任务相关的输入输出通路。

如图4所示，所述子任务之间具有两种逻辑关系，包括并行关系和依赖关系；所述并行关系包括同源并行关系和异源并行关系，所述同源并行关系指具有相同计算逻辑的子任务之间的关系；所述异源并行关系指不同计算逻辑的子任务之间的关系；所述依赖关系包括调度依赖关系和执行依赖关系，所述调度依赖关系指一个子任务被调度后，开始调度与其具有调度依赖关系的子任务；所述执行依赖关系指一个子任务执行之后，开始调度与其具有执行依赖关系的子任务。

如图3所示，所述作业逻辑模块5将具有同源并行关系的至少两个子任务进行封装成簇任务，所述簇任务之间通过隧道进行通信，所述隧道包括两个簇任务之间所有的数据通道，并将所述的数据通道标识为相同属性。

如图5所示，所述计算系统模块3用于将工作节点中的数据存储到进程内存中，进入计算系统模块中的子任务通过读取进程内存中的数据与工作节点实现通信，并将子任务产生的中间数据存储入进程内存。

所述资源管理模块1为Yarn分布式资源管理平台。

如图8所示，所述资源伸缩模块2用于提供固定资源配置和动态资源科伸缩的资源使用方法，所述资源使用方法通过队列饱和度监控系统的任务工作负载状况，按照容忍区间的设置，在包装最低资源供应的前提下，动态调整工作节点的个数。

如图3所示，为本发明实施例1所述模型翻译模块逻辑关系模型示意图。

作业逻辑表达模型基本元素有两种：子任务和通道。子任务是真正部署到节点执行计算的单位，用户程序通过实现简单接口指定实现的逻辑。通道是与子任务相关的输入输出，有依赖关系的子任务之间通过通道相互关联。

子任务之间逻辑关系分为两类：

（1）并行关系。一种是同源并行关系，标识具有相同计算逻辑的子任务之间的关系，对于同一个数据源的数据进行划分，并行计算；另一种是异源并行关系，标识不同计算逻辑的子任务之间的关系。

（2）依赖关系。根据具有依赖关系的任务调度时机的不同，可以分为调度依赖关系、执行依赖关系。调度依赖关系标识了任务要在指定的任务被调度之后再调度；执行依赖关系标识了任务要在指定的任务执行结束之后再被调度执行。

根据子任务之间逻辑关系的介绍，我们对于同源并行关系的任务进行封装，封装成簇任务，簇是可扩展的基本单位。簇与簇之间的传输被指定成隧道（Tunnel），Tunnel是配置数据传输方式的单位。图3是包含簇和隧道的逻辑关系模型示意图。

簇内子任务的个数由上一个阶段簇的输出或者程序配置决定，通过隧道设置不同的传输方式，隧道内的数据通道是子任务与子任务之间的传输纽带。隧道包含了两个簇之间所有的数据通道，并标识以相同的属性。这里以隧道为单位进行配置，提高了模型管理的效率。由于每一个簇都是执行同一个逻辑单元子任务的集合，模型设计人员只需设置一次执行逻辑，然后经过模型编译即可自动拆分成不同的子任务。

如图4所示，为本发明实施例1所述子任务之间逻辑关系与传输模型关系图。

数据传输模式和子任务之间逻辑关系息息相关。例如，如果子任务与子任务之间的依赖关系是执行依赖关系，即上一个任务执行结束之后，下一个任务才被运行时环境调度，此时数据容器需要保存上一个阶段任务的执行结果，数据容器可以是磁盘文件、数据管理系统等。这种传输大多数是阻塞式的，例如Dryad实现的MapReduce编程模型，Map任务执行结束之后，中间结果存储在本地磁盘文件，Reduce任务启动之后，通过TCP拷贝中间数据，然后再处理。若子任务与子任务之间的依赖关系是调度依赖关系，则上一个阶段的任务被调度执行之后，不等待它执行结束，而马上调度下一个阶段的任务，此时，由于两个任务可以在执行过程中进行数据交互。例如，在MapReduce-Online的设计中，MapTask会在执行过程中向ReduceTask推送数据，ReduceTask和MapTask之间配置调度依赖关系，MapTask在ReduceTask调度完成之后，再启动，这样逻辑上ReduceTask就会在MapTask执行的生命周期内一直存在，从而实现任务调度为数据传输的需求服务的目的。

随着数据容器和传输模型的发展，不同类型的作业，应该设置相适应的数据传输模型，才能使得数据处理的效率能够满足作业的需求。子任务之间的逻辑依赖关系，经过调度和部署，最终会变成数据传输模式的映射。以隧道为单位配置数据容器和传输模型，可以很好地兼容和处理不同数据容器下的数据，避免了从不同位置拷贝数据到统一容器造成的数据冗余和开销，同时可以有针对性地满足不同作业的需求。

如图5所示，为本发明实施例1所述计算系统模块中进程级与线程级任务调度示意图，，线程级任务调度和分布式内存系统是计算系统Binos使用的方式。

一个JVM的不同线程之间可以直接共享数据，效率优于进程之间的存取数据。如图3中线程级任务调度，在工作节点的Daemon中，内存维护被执行作业的子任务线程的处理结果，在调度到有数据依赖关系的子任务时，子任务可以直接从工作节点的Daemon的内存中读取数据，避免了数据序列化、存取本地磁盘或其它数据容器的开销。

针对小作业处理数据较少的特点，使用线程级任务调度方案，可以将作业的中间处理结果存放到工作节点Daemon的内存中，显然在调度下一个阶段的任务时，它需要的这部分数据就可以直接从工作节点Daemon的内存中获取。反观，如果采取进程级任务调度，在任务执行结束之后，进程退出，由它产生的处理结果必须存入文件或者其它的数据容器来维护，当该作业内有数据依赖的任务被调度到该工作节点，那么需要获取数据，就需要读取文件或者从其它的数据容器中获取。显然，存取数据容器、文件显然要比存取同一进程内的内存开销要大得多。

如图6、7所示，为本发明实施例1所述计算系统模块中分布式内存系统部署示意图和本发明实施例1所述计算系统模块中分布式内存系统中DataDaemon功能结构图。

针对生产集群中小作业占有资源较少、处理数据量不多的背景，将子任务产生的中间数据放入内存，通过消息队列实现不同节点之间的数据传输，在并行处理系统运行时环境的Master-Slave架构之上，构建一套分布式内存系统，支持不同的编程模型。

分布式内存系统是Master-Slave的架构，与Binos-Engine的Binos-Master和Binos-Slave共置节点。这里Master是协调器（DataCoord），Slave是数据存储器（DataDaemon）。DataCoord维护了Slave节点的数据服务、端口信息以及作业相关的属性信息，方便Slave工作节点的查询。DataDaemon提供了本地Key-Value数据的维护和传输功能。图4显示了分布式内存系统部署架构与并行计算引擎Binos-Engine运行时环境的部署关系。

为了应对编程模型对于不同数据传输模式的需求，使用ZeroMQ实现DataDaemon之间的数据传输。ZeroMQ是用于并发系统的Socket高效的通信库，支持端对端的多种传输模式（fanout,pub-sub,pipeline,request-reply,push-pull）。

应用程序将数据写入DataDaemon的In-Memorykey/value的存储区，然后按照编程模型和作业逻辑的定义，在控制命令下，发送和接收数据，实现不同节点之间数据的交互。图5描述了分布式内存系统中DataDaemon功能结构图，主要提供三类服务：

（1）与DataCoord交互服务。获取不同DataDaemon服务端口、位置、作业相关信息等。提供ZeroMQ的全双工异步队列Dealer和Request/Reply两类消息通信模式。

（2）与其它DataDaemon控制信息交互服务。按照处理逻辑的需求，发送获取数据的请求等。使用ZeroMQ全双工异步队列Dealer实现控制信息交互。

（3）与其它DataDaemon数据交互服务。按照作业逻辑的需求，使用ZeroMQ的push-pull模式，发送和接收内存中的数据。

如图8所示，为本发明实施例1所述资源伸缩模块中资源动态管理器Binos-Manager系统图。

Yarn是一个面向作业的分布式资源管理平台，以Container为基本单位实现资源的申请与释放。在Yarn的资源系统之上执行MapReduce作业，每个作业维护一个AppMaster，解析作业的执行逻辑，按照作业的需求向RM申请Container资源。AppMaster获得资源之后，会将合适的子任务调度到该Container上执行，启动JVM进程执行。这里AppMaster相当与中心节点，而在Container上启动的JVM进程，相当于工作节点，这是一个只在作业生命周期存在的Master/Slave的架构。

Binos-Engine是支持线程级任务调度和部署的并行处理系统的执行引擎，Master负责作业、任务的的调度以及工作节点的维护，Slave负责启动线程级的子任务，由于在Slave进程内启动线程，不会在该节点生成新的进程，因此，可以借用Yarn的AppMaster与子工作进程之间的Master/Slave的架构，映射成Binos-Master和Binos-Slave。AppMaster和Binos-Master部署在同一个节点，AppMaster按照作业负载和资源使用情况的变化，向系统申请Container，部署Binos-Slave。

针对小作业执行的特点，如果每次都按照作业的需求申请和释放资源，使得小作业的执行效率大大降低。借助Yarn平台，可以按照预先设置去申请Container，并在确保不同的节点的前提下部署Binos-Slave进程，保证并行计算引擎运行时环境下的Binos-Master/Binos-Slave的初始配置资源不释放。这样小作业提交到Binos-Master之后，可以立即调度到合适Binos-Slave执行，加快了小作业的调度和部署的效率。

作为一个并行处理系统的执行引擎，工作节点的个数的增加，相当于扩展了该节点的计算能力。Binos-Slave内部以线程的方式部署任务，但是部署任务的个数受到了节点工作能力的影响。因此，在Binos-Engine环境中，适当调大工作节点Binos-Slave可同时执行任务的数目，在计算能力允许的条件下，可有效提高节点的计算能力。显然，随着执行引擎中作业队列中作业数目的增加，同一时刻满足执行条件的任务，就会增多，固定资源配置使得作业的吞吐率和作业的执行效率都会有所影响。因此，借助Yarn平台，系统可以通过AppMaster申请新的Container来启动Binos-Slave来缓解任务负载过重的压力。Binos-Engine能够实现动态调整主要得意于之前系统的设计和决策：

（1）Binos-Slave在Binos-Engine中可以实现热部署和热退出。运行时环境的执行引擎能够快速处理Binos-Slave加入和退出的情况。

（2）Binos-Engine的默认调度模块使用任务均衡优先的调度方式。新加入的节点，由于被分配的任务数为零，Binos-Master会优先调度任务到该节点，从而可以快速实现任务负载在工作节点之间的均衡。

Binos-Manager的固定资源配置的启动过程：

（1）向RM申请资源，获取Container，在该节点启动AppMaster。

（2）启动Binos-Master。为了保证AppMaster与Binos-Master位于同一个节点，实现中心化的控制，Binos-Manager在AppMaster中直接启动Binos-Master。

（3）获取Binos-Master的url。每一个动态启动的Binos-Slave需要获取中心节点url。由此，AppMaster截获Binos-Master启动之后的输出，匹配出正确url。

（4）申请资源，启动Binos-Slave。AppMaster维护了Yarn分布式资源平台中NM的位置信息NM-Nodes，AppMaster同时维护了当前运行的Binos-Slave的节点位置信息Slave-Nodes。这样每次申请资源的结果都会进行匹配，获取两个集合的差集，保证在不同节点之上部署Binos-Slave。该过程直到配置的Binos-Slave个数全部启动，结束资源申请。

在不同的NM的Container资源上启动Binos-Slave的原因在于，线程级共享内存的策略，使得一个计算节点分割计算资源隔离出多个Container部署Binos-Slave，不如在一个节点部署单一资源粒度较大的Container，这样在该Container中的Binos-Slave就可以同时部署更多的任务，当进程内子任务之间可以通过内存共享数据时，进程内共享资源的优势就更明显。

（1）AppMaster动态获取执行引擎中队列饱和度。

$\mathrm{Queue}\_\mathrm{Sat}=\frac{\mathrm{wq}.\mathrm{length}\×\mathrm{average}\_\mathrm{task}\_\mathrm{num}+\underset{i=1}{\overset{\mathrm{rq}.\mathrm{length}}{\mathrm{\Σ}}}\mathrm{rq}\left[i\right].\mathrm{unfinshed}\_\mathrm{task}\_\mathrm{num}}{\mathrm{slaveNodes}.\mathrm{num}\×\mathrm{slotsEachSlave}}$

表1队列饱和度公式参数解析表

（2）根据预设饱和度的调整区间、资源管理器内设置的初始Slave个数以及最大Slave的个数，AppMaster向Yarn提出资源申请和回收的请求。Binos-Manager设置了资源申请释放的阈值范围，min_threshold为最小阈值，一般设置的值一般不超过0.5，max_threshold为最大阈值，设置值一般大于1.5。max_slaves是系统设置的最多Slave的个数，init_slaves是初始Slave节点的个数。申请和回收资源的表达式如下：

$\mathrm{elastic}=\left\{\begin{array}{c}\mathrm{resource}\_\mathrm{req}(\mathrm{Queue}\_\mathrm{sat}>\max \_\mathrm{threshold})\&cap;(\mathrm{slaves}.\mathrm{num}<\max \_\mathrm{slaves})\\ \mathrm{resource}\_\mathrm{rec}(\mathrm{Queue}\_\mathrm{sat}<\min \_\mathrm{threshold})\&cap;(\mathrm{slaves}.\mathrm{num}>\mathrm{init}\_\mathrm{slaves})\end{array}\right.$

资源弹性的过程如下：

a）队列饱和度大于最大阈值，并且当前Binos-Slave的个数小于Binos-Manager设置的Slave个数最大值，则AppMaster向Yarn提交资源请求。

b）队列饱和度小于最小阈值，并且当前Binos-Slave的个数大于Binos-Manager设置的固定Slave的个数，则AppMaster向Yarn提交资源回收请求。

在计算资源弹性伸缩的过程中，加入节点对于任务调度和执行系统没有影响。然而，如果退出一个计算节点，AppMaster首先选择一个资源使用最少的Binos-Slave，通过与Binos-Master的交互，观察工作节点使用的情况，在连续一段时间内，工作节点上没有任务数目及资源使用的变化时，则启动回收资源，工作节点从Binos-Engine中退出。

如图9所示，为本发明实施例1所述的一种面向小作业优化的并行处理系统定制的Binos-HashMR的双向链表结构示意图。

编程模型由数据组织、传输方式和处理逻辑三部分构成。下面将介绍Binos-HashMR借助分布式内存系统，在编程模型这三部分的内容。

（1）Binos-HashMR数据组织。Binos-HashMR按照传统MapReduce的key/value格式，DataDaemon为job的每一个Partition维护了一个TreeMap。由于TreeMap按照key进行排序，map()函数输出的每一个key/value插入对应partition的TreeMap，map任务结束之后，则在DataDaemon中每个partition的结果是有序的。在Reduce数据预处理阶段使用了带有双向指针的链表结构。

（2）Binos-HashMR传输方式。借助ZeroMQ的push/pull模式，在两个Daemon之间传输数据。

（3）Binos-HashMR处理逻辑。处理逻辑上，仍然是split-map-reduce三阶段，map处理结果直接写入DataDaemon，reduce从map所在节点获取相应partition的数据，然后Merge排序，生成全局有序的数据，交由reduce()函数处理，reduce的输出结果写回文件系统。整个处理过程中，除了从HDFS读取输入数据，到最后写回文件之外，全部操作数据放在DataDaemon维护的内存中完成。

Hadoop-MapReduce编程模型shuffle阶段，从MapTask所在节点拷贝数据，使得Reduce的逻辑处理需要等待获取数据、Merge过程的完成。在Binos-HashMR编程模型中，我们对此做了如下的优化：

（1）复用TreeMap合并map的输出结果。Binos-Engine支持线程级任务调度和执行，使得MapReduce作业的多个MapTask可能被调度到同一节点内，由于这些MapTask共享DataDaemon，我们使用多线程并发访问安全的TreeMap，使得该节点同作业的MapTask复用TreeMap。作业的Map阶段结束之后，每个节点对于输出数据块与Reduce个数相同，与该节点内MapTask的个数无关。如果Key的重复次数很大，经过设置的Combiner过程会合并更多的数据，中间数据整体上变少，尤其在类WordCount之类的应用上作用突出。复用TreeMap进一步的结果是降低节点消耗的内存，传输消耗的网络带宽和耗时随之也会减小。

（2）ReduceTask支持边传输、边Merge、边执行reduce()函数。ReduceTask被启动之后，DataDaemon向其它DataDaemon发送请求该节点内对应partition数据的命令。设置push/pull模式的顺序分阶段获取数据。在ReduceTask所在节点启动多个线程对于获取的部分结果，进行Merge排序。

为了降低Hadoop-MR编程模型中，shuffle阶段的瓶颈带来的性能开销，最高程度地发挥多核多线程处理优势，平衡网络资源和加快编程模型数据处理速度。DataDaemon将MapTask处理的结果，执行序列化->传输->反序列化->排序->数据合并->Reduce的过程，完全流水线同时执行。其中如果进行多线程全局Merge，并与Reduce过程同时执行是亮点。这部分关键步骤如下：

a）在ReduceTask所在节点的DataDaemon建立一个全局的共享链表（如图9所示）。

b）在Reduce端并发接收来自多个DataDaemon的同一partition下的数据，执行序列化，完成序列化之后，则将数据交给Merge线程。

c）每个Merge线程处理来自一个或者多个节点发送来的partition数据，为每个节点设置一个指向链表某个Item的指针。由于来自同一个节点的数据块是有序，每次获取传输过来的数据，只需从该节点指针的位置开始排序即可。

d）当一个Merge线程对于某一个节点获取来的partition数据块（分阶段传输过来的数据，只是某节点partition数据的一段）处理结束之后，将最后指针发送事件返回给数据拉取线程。

e）数据拉取线程通过判断所有的指针中最小的Key。当获得了这个Key之后，则这个Key之前的数据就是不会改变了，数据拉取线程再向reduce返回这个Key之前的所有数据，执行reduce过程。

整个过程是完全的流水线式处理方式，不在像以前的需要将所有的数据传送到Reduce再做处理。除此外，由于对数据的排序是多线程并发归并排序，并且在排序的同时就返回部分已经全局有序的结果。因此，Reduce不需要等到所有数据都排序完整之后，再进行处理。

小作业执行流程

(1)用户实现了编程模型接口，或者实现作业逻辑之后，打包生成job.jar文件。

(2)提交job.jar到作业客户端，在客户端本地执行job.jar，生成描述作业逻辑关系和属性信息的job.xml,描述子任务的task-id.xml。

(3)将job.xml、task-id.xml、job.jar提交到分布式文件系统之上，作业通过远程过程调用提交到Binos的Master的作业队列中。

(4)Master解析作业内子任务的逻辑关系，按照作业内任务的数据依赖关系，满足执行条件的子任务被提交到任务队列。

(5)调度任务到工作节点上部署执行。

(6)子任务状态的改变向中心节点更新。

(7)作业内全部的子任务执行结束之后，作业执行结束，统计作业执行信息。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种面向小作业优化的并行处理系统，其特征在于，由下至上依次包括资源管理模块、资源伸缩模块、计算系统模块、模型翻译模块和作业逻辑模块；

所述资源管理模块实现对整体系统的资源管理并提供管理平台；

所述资源伸缩模块在资源管理模块之上，通过资源的申请与释放，实现对于上层计算系统模块的资源供应和回收；

所述计算系统模块是系统的运行时的环境，用于实现在一个JVMJava虚拟机中的不同线程之间直接共享数据，并在资源伸缩模块提供的工作节点的基础上建立分布式内存系统；

所述模型翻译模块运行在计算系统模块之上，为作业提供表达逻辑的基本单元，将作业逻辑模块表达的逻辑翻译成计算系统内可以识别的执行体；

所述作业逻辑模块用于设置数据传输模式和逻辑表达模型。

2.根据权利要求1所述的一种面向小作业优化的并行处理系统，其特征在于，所述模型翻译模块将作业翻译成子任务和通道两种基本元素，所述子任务是执行计算的单位，所述通道是与子任务相关的输入输出通路。

3.根据权利要求1所述的一种面向小作业优化的并行处理系统，其特征在于，所述作业逻辑模块将具有相同计算逻辑的至少两个子任务进行封装成簇任务，所述簇任务之间通过隧道进行通信，所述隧道包括两个簇任务之间所有的数据通道，并将所述的数据通道标识为相同属性。

4.根据权利要求1所述的一种面向小作业优化的并行处理系统，其特征在于，所述计算系统模块用于将工作节点中的数据存储到进程内存中，进入计算系统模块中的子任务通过读取进程内存中的数据与工作节点实现通信，并将子任务产生的中间数据存储入进程内存。

5.根据权利要求1所述的一种面向小作业优化的并行处理系统，其特征在于，所述资源管理模块为Yarn分布式资源管理平台。

6.根据权利要求1所述的一种面向小作业优化的并行处理系统，其特征在于，所述资源伸缩模块用于提供固定资源配置和动态资源科伸缩的资源使用方法，所述资源使用方法通过队列饱和度监控系统的任务工作负载状况，按照容忍区间的设置，在包装最低资源供应的前提下，动态调整工作节点的个数。

Images