本发明涉及一种任务调度装置，尤其涉及针对大数据任务的调度装置。
背景技术：
随着大数据时代的来临,如何实现高效的存储和计算，通常采用的提高CPU性能和改用更大容量磁盘的做法，已经变得越来越困难。在这种背景下，以网络和网络通信技术为依托，将分散在不同地理位置的计算机连接起来，组成空间上分散、逻辑上统一的数据存储和计算集群，成为当前实现大规模数据处理的主要选择,以及不同大数据计算框架层出不穷，如面向大数据存储计算的hadoop，面向内存迭代运算的spark，专门针对流式计算的storm等，这些计算框架在处理各自领域业务时都有特定的优化性能十分高效，但是这些计算框架都存在一个问题，那就是任务间的协作依赖处理问题，当业务计算任务之间存在先后执行依赖的时候，计算框架就往往受到严重制约，甚至引起效率在数量级程度的下降。
技术实现要素：
以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。
本发明的目的在于解决上述问题，提供了一种大数据任务调度装置，是一种通用的大数据任务调度方案，可以在不同平台上运行，提高大数据的处理性能。
本发明的技术方案为：本发明揭示了一种大数据任务调度装置，包括执行器、时间存储接口、数据接口以及调度器，其中：
执行器，封装具体任务的执行，提供统一的调用接口供调度器调用；
时间存储接口，记录数据接口的时间，并提供查询服务；
数据接口，存储数据；
调度器，实现大数据各个任务之间的调度。
根据本发明的大数据任务调度装置的一实施例，执行器实现的操作包括数据清洗、数据结构的改变、数据计算。
根据本发明的大数据任务调度装置的一实施例，执行器执行执行机制是同步和异步同时存在，多个任务依赖链之间是异步的，在一个任务依赖链中任务和任务之间是同步的。
根据本发明的大数据任务调度装置的一实施例，时间存储接口进一步包括：
时间更新单元，当任务成功执行时，更新数据的截止时间；
时间查询单元，查询数据的截止时间；
时间修改单元，更改数据的截止时间。
根据本发明的大数据任务调度装置的一实施例，数据接口进一步包括：
按时间存储单元，基于时间标识存储数据；
非时间存储单元，不按时间标识存储数据；
数据获取单元，提供数据分片计算的信息，对异构的底层数据提供读取的封装。
根据本发明的大数据任务调度装置的一实施例，调度器进一步包括：
数据管理模块，计算全量数据的运算，计算相对时间内的数据，对单位时间数据进行增量计算；
任务依赖模块，处理任务依赖队列中各个任务执行的先后顺序；
容错机制模块，根据不同集群本身的容错机制做定制化对接；
补跑策略模块，让数据接口从其上游的数据接口重新获取数据并进行计算，若数据接口是时间相关的，则通过时间存储接口将下游所有数据时间设为故障或延迟发生前，再重启相关任务链，以使数据计算正确，若数据接口是时间无关的，则直接重启相关任务链。
本发明对比现有技术有如下的有益效果：本发明的大数据任务调度装置中设有执行器、时间存储接口、数据接口以及调度器。本发明的大数据任务调度装置 在不同的平台上实现运行，可以用任意现代编程语言来实现，包括但不限于java、scala、ruby、python、C#、C++等。数据调度在执行层面会被拆解为若干小而具体的任务进行，例如mapreduce、hive sql等，优化的异构的调度不同计算框架的任务。
附图说明
图1示出了本发明的大数据任务调度装置的实施例的原理图。
具体实施方式
在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。
图1示出了本发明的大数据任务调度装置的实施例的原理。请参见图1，本实施例的大数据任务调度装置包括：执行器1、时间存储接口2、数据接口3以及调度器4。
其中执行器1用于封装具体任务的执行，提供统一的调用接口供调度器4调用。执行器1实现的操作可能是hadoop、hbase、hive、spark等，它们主要是完成业务的一些计算，如数据的清洗、数据结构的改变、数据的计算等操作。
执行器1执行机制上可以是异步的也可以是同步的，以适应不同场景调度并发性能的需求。执行器1执行机制大量使用同步和异步策略。当有大量的且不存在依赖的任务先后提交到集群时，集群不可能等一个任务完成了再执行另外一个任务，这样会导致效率低下，所以并行且异步执行多任务是非常有必要且高效的。任务与任务之间没有任何影响，一个任务的失败不会影响到另外一个任务的执行，以及任务执行的结果；当业务处理任务之间存在依赖关系的时候，只有等被依赖的任务执行完毕，依赖的数据准备好了，下一个依赖的任务才能开始执行，当被依赖的任务执行失败，那么接下来依赖的任务就不再执行了，以此类推。这种同步机制虽然降低了效率，但是再保证数据的准确性上还是有必要这样做的。
所以执行器1执行执行机制是同步和异步同时存在的，多个任务依赖链之间是异步的，而在一个任务依赖链中任务与任务之间是同步的。
时间存储接口2主要负责记录数据接口的时间，并提供查询服务。时间存储接口2进一步包括时间更新单元21、时间查询单元22以及时间修改单元23。其中时间更新单元21用于实现当任务成功执行时，更新数据的截止时间。当任务成功执行，系统会调用时间存储接口更新数据的截止时间，也就是该数据任务下次要执行的开始的时间，但是当该任务在本次执行失败，那么在记录的时间不做变动仍然是上次该数据上次成功执行的时间。时间查询单元22用于查询数据的截止时间。时间修改单元23用于更改数据的截止时间。时间修改单元23提供时间修改服务，由于大数据计算的特殊性，有时候任务计算的数据会出现不准确，比如可能是数据生成与消费异步，延迟等情况导致的，可以通过该接口把数据的截止时间即下次执行的时间向前调整，这样就可以让这部分数据重新进行计算。每当新的任务要上线的时候，也可以通过该接口事先设置好对应数据接口的第一次运行的起始时间。
数据接口3负责存储数据，对不同系统上的数据存取提供统一的抽象，如hbase、hive、hdfs、redis、以及mysql等关系型数据库。数据存储上大体分为按时间存储，以及不按时间存储。相应的，数据接口3包括按时间存储单元31、非时间存储单元32以及数据获取单元33。
其中按时间存储单元31是基于时间标识存储数据。按时间存储的数据，具体的粒度可以从年细分到秒甚至毫秒，并提供按相应单位量获取的接口，以及数据时间的起始范围接口。数据按时间存储一方面是考虑到是随着时间线型增长的，通过按时间存取可以很自然的设计数据的分片获取方式，另外一方面很多业务并不要求使用全量数据，例如推荐系统一般只考虑用户最近一段时间的行为做推荐，用户行为会随着年龄和使用时间发生变化，取全量数据做分析是不合适的，在这个例子下，我们会安装天汇总用户行为，数据的粒度设为天，然后推荐的离线分析接口再按照一定时间范围从用户行为的数据接口获取数据。
非时间存储单元32是不按时间标识存储数据。非按时间存储的数据，只提供全量获取的接口。当要存储的数据是以后不变的或者是变化很少的数据时，数据存储时就没有必要按照时间的标识去存储了。
数据获取单元33是提供数据分片计算的信息，对异构的底层数据提供读取的封装。不论数据如何存储，数据接口都提供数据分片计算的信息，这个是大数据并行计算的基础，通过分片接口也可以对异构的底层数据提供高效读取的封装。更多数据接口细节可以参考调度器的数据管理说明。
调度器4负责大数据各个任务之间的调度。作为方案核心，具有以下功能，数据管理、任务依赖、容错机制、补跑策略。通过执行器的抽象，各个异构的计算框架在调度上并没有区别。
调度器4进一步包括数据管理模块41、任务依赖模块42、容错机制模块43以及补跑策略模块44。
数据管理模块41计算全量数据的运算，计算相对时间内的数据，对单位时间数据进行增量计算。
大数据的运算统一用以下几种方式概括：
1)计算全量数据的运算，常见于各种全站式数据分析和挖掘，在这种情形下，数据任务的输入从依赖的数据接口获取分片信息，进而提交给任务执行器进行任务计算。
2)计算相对时间内的数据，常见于近期数据分析和挖掘，在这种情形下，数据任务的输入通过时间存储接口获取分片信息，进而提交给任务执行器进行任务计算。
3)对单位时间数据进行增量计算，常见于日常数据收集和计算，为其他计算提供基础，在这种情形下，数据任务依赖于时间存储接口并对输入数据任务完成情况做检查，确保数据计算时的完整性。
上文提到的时间处理的具体规则如下：
1)任务执行前会获得一个当前时间戳，任务不自己获取当前时间，一切时间通过该时间戳计算。
2)如果有结束时间的任务，根据固定规则把时间戳加工成任务的结束时间：
a.首先确定粗结束时间：如果输入数据接口是按时间存储，并且按照原始数据收集计算而来，则使用传入的时间戳，否则使用输入数据接口的最后结束时间，如果有多个输入数据接口，取时间最早的那个。
b.检查输入数据的时间粒度是否大于本任务的时间粒度，如果大于则报错(输入数据接口如果跟时间无关也报错)
c.把粗结束时间裁剪成任务输出数据的粒度，如果输出数据跟时间无关，则不做剪裁。这样就获得了结束时间
3)如果是增量时间任务则通过时间服务获取自己上次的完成时间作为开始时间，如果是相对时间任务根据结束时间计算出相对时间作为开始时间
4)如果有容错方案(具体可以参考容错方案一节)或者特殊要求，会把之前拿到的开始或结束时间做正负修正，但是修正范围必须是整数倍的任务时间粒度
5)如果有最大运行范围限制(避免单次运行占用太多资源)会对结束时间做裁剪，使得开始结束时间范围不超过运行范围限制
6)如果输入数据接口不满足结束时间要求，例如相对时间任务最近n天必须是昨天开始的n天，则当前任务挂起进入等待。
任务依赖模块42处理任务依赖队列中各个任务执行的先后顺序。任务依赖机制，处理的是一个任务依赖队列中各个任务执行的先后顺序，依赖的原则有：
顺序性：被依赖的任务永远执行在依赖的任务前，比如A任务依赖于B任务，只有当B任务跑成功完了，A任务才能跑。
串联性：任务依赖队列中的任务是串联的，前一个任务跑失败了，后面的任务就不在跑了，这一点是为了避免不必要的浪费时间和数据不准确，比如B任务需要处理A任务跑完的数据，如果A任务跑失败了，B任务就没有数据了，当然任务依赖链就断了。
并发性：当任务运行没有依赖关系时，根据集群情况允许任务并发执行。
资源调度性：调度器会把它全部的资源数字化，如内存数、CPU核数、硬盘数、机器数、网络带宽等，每个任务会请求数字化的资源，完成会释放它之前获取的资源。当资源不够，会尝试调度其他资源较小的任务，当全部资源都不足，调度器就会进入等待，直到有足够的资源释放。系统也支持定制化的资源调度，例如最大最小资源任务优先等。
完整性：如果任务依赖队列中任务按照依赖顺序执行下去，那么依赖队列中的最后一个任务一定会被执行到。
容错机制模块43根据不同集群本身的容错机制做定制化对接。调度器会根据不同集群本身的容错机制做定制化对接，在充分利用底层集群特性上，调度器还把数据接口设计为幂等的，支持数据重复计算，而不是有状态的，多次计算会导致数据不同，例如增加操作就是有状态的，运行多次就会重复增加多次，在这种情况下一般会用累加历史数据来代替，等等。同时调度器也设计了统一的rollback接口，即使有特殊情况也可以通过该接口来还原数据，保证数据接口的幂等性。
补跑策略模块44让数据接口从其上游的数据接口重新获取数据并进行计算，若数据接口是时间相关的，则通过时间存储接口将下游所有数据时间设为故障或延迟发生前，再重启相关任务链，以使数据计算正确，若数据接口是时间无关的，则直接重启相关任务链。
补跑策略是对上文容错机制幂等性的一个重要补充，幂等性是建立在数据没有出错或发生变化情况下，但是有时候会由于CAP理论的限制，在满足大吞吐量可拓展的基础上，是没有办法保证数据的实时性的，实际上很多数据收集都是异步进行，在上游任务比较繁忙或者发生故障情况下，数据难免迟到或者出错，我们通过补跑机制，让一个数据接口，从它上游的数据接口重新获取数据，进行计算，即重跑相关任务，如果数据接口是时间相关的，调度器会通过时间存储接口把下游所有数据时间设为故障或延迟发生前，再重启相关任务链，使数据计算正确。如果数据接口是时间无关的，那只要简单重启相关任务链即可。上面说提到的时间修改判断是递归的，可能任务链上有的是时间相关，有的是时间无关，他们是迭代进行判断和处理的。在实际生产环境上，如果没有特殊情况，跟时间有关的数据接口，都会进行一个往前看若干时间单位的动作，这个可以保证重新进来的数据被计算正确。
尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。
本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这 两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。
结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。
结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。
在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订 户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。
提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。