CN109117259A

CN109117259A - 任务调度方法、平台、装置及计算机可读存储介质

Info

Publication number: CN109117259A
Application number: CN201810826237.3A
Authority: CN
Inventors: 李冬峰; 杨松; 王哲涵; 李彦良
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2018-07-25
Filing date: 2018-07-25
Publication date: 2019-01-01
Anticipated expiration: 2038-07-25
Also published as: CN109117259B

Abstract

本公开提供了一种任务调度方法、平台、装置及计算机可读存储介质，涉及计算机技术领域。其中的任务调度方法包括：路由组件接收客户端提交的应用任务；在第一预设条件下，路由组件调用AMRMproxy组件将应用任务提交至Hadoop系统运行；在第二预设条件下，路由组件调用AMRMproxy组件将应用任务提交至Kubernetes系统运行。本公开实现了调度任务在Hadoop系统与Kubernetes系统间的运行和切换，从而实现了Hadoop系统与Kubernetes系统间的跨平台任务调度。

Description

任务调度方法、平台、装置及计算机可读存储介质

技术领域

本公开涉及人工智能技术领域，特别涉及一种任务调度方法、平台、装置及计算机可读存储介质。

背景技术

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。HDFS(HadoopDistributed File System，Hadoop分布式文件系统)有高容错性的特点，并且设计用来部署在低廉的硬件上，能够提供高吞吐量来访问应用程序的数据，适合具有超大数据集的应用程序。YARN(Yet Another Resource Negotiator，另一种资源协调者)是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes的目标旨在消除编排物理或虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes也提供稳定、兼容的基础(平台)，用于构建定更高级的自动化任务。Kubernetes具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。Kubernetes还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

发明内容

本公开解决的一个技术问题是，如何实现Hadoop系统与Kubernetes系统间的跨平台任务调度。

根据本公开实施例的一个方面，提供了一种任务调度方法，包括：路由组件接收客户端提交的应用任务；在第一预设条件下，路由组件调用AMRMproxy组件将应用任务提交至Hadoop系统运行；在第二预设条件下，路由组件调用AMRMproxy组件将应用任务提交至Kubernetes系统运行。

在一些实施例中，路由组件调用AMRMproxy组件将应用任务提交至Hadoop系统运行包括：路由组件调用系统状态存储组件，获取各个子Hadoop系统的状态信息；路由组件调用路由策略存储组件，获取空闲状态子Hadoop系统的访问地址；路由组件利用访问地址，调用AMRMproxy组件创建与空闲子Hadoop系统资源管理器ResourceManager的连接，以将应用任务提交至系统资源管理器运行。

在一些实施例中，路由组件调用AMRMproxy组件将应用任务提交至Kubernetes系统运行包括：路由组件调用系统状态存储组件，获取Kubernetes系统中各个容器docker的状态信息；路由组件调用路由策略存储组件，获取空闲状态容器的访问地址；路由组件利用访问地址，调用AMRMproxy组件在空闲状态容器上运行Hadoop的服务镜像文件，以运行应用任务。

在一些实施例中，任务调度方法还包括：AMRMproxy组件接收各个子Hadoop系统的资源管理器发送的心跳数据包；AMRMproxy组件根据实际接收到各个子Hadoop系统的资源管理器发送的心跳数据包的频率，确定各个子Hadoop系统的状态；AMRMproxy组件在系统状态存储组件中更新将各个子Hadoop系统的状态信息。

在一些实施例中，任务调度方法还包括：AMRMproxy组件接收Kubernetes系统发送的各个容器的状态信息；AMRMproxy组件在系统状态存储组件中更新Kubernetes系统的各个容器的状态信息。

在一些实施例中，任务调度方法还包括：在路由策略存储组件中预先配置各个子Hadoop系统的访问地址。

在一些实施例中，任务调度方法还包括：在路由策略存储组件中预先配置Kubernetes系统中各个容器的访问地址。

在一些实施例中，第一预设条件是时间为9点至24点；第二预设条件是时间为0点至9点。

在一些实施例中，任务调度方法还包括：Kubernetes系统利用容器中的存储资源，存储应用任务运行产生的中间数据；Kubernetes系统将应用任务运行产生的结果数据反馈至AMRMproxy组件；AMRMproxy组件将结果数据存储至Hadoop系统的分布式文件系统。

在一些实施例中，路由组件接收客户端提交的应用任务包括：多个路由组件随机接收客户端提交的应用任务，以实现负载均衡。

根据本公开实施例的一个方面，提供了一种任务调度平台，包括路由组件以及AMRMproxy组件，其中，路由组件被配置为接收客户端提交的应用任务；在第一预设条件下，路由组件被配置为调用AMRMproxy组件将应用任务提交至Hadoop系统运行；在第二预设条件下，路由组件被配置为调用AMRMproxy组件将应用任务提交至Kubernetes系统运行。

在一些实施例中，任务调度平台还包括系统状态存储组件以及路由策略存储组件；路由组件被配置为：调用系统状态存储组件，获取各个子Hadoop系统的状态信息；调用路由策略存储组件，获取空闲状态子Hadoop系统的访问地址；利用访问地址，调用AMRMproxy组件创建与空闲子Hadoop系统资源管理器ResourceManager的连接，以将应用任务提交至系统资源管理器运行。

在一些实施例中，任务调度平台还包括系统状态存储组件以及路由策略存储组件；路由组件被配置为：调用系统状态存储组件，获取Kubernetes系统中各个容器docker的状态信息；调用路由策略存储组件，获取空闲状态容器的访问地址；路由组件利用访问地址，调用AMRMproxy组件在空闲状态容器上运行Hadoop的服务镜像文件，以运行应用任务。

在一些实施例中，AMRMproxy组件还被配置为：接收各个子Hadoop系统的资源管理器发送的心跳数据包；根据实际接收到各个子Hadoop系统的资源管理器发送的心跳数据包的频率，确定各个子Hadoop系统的状态；在系统状态存储组件中更新将各个子Hadoop系统的状态信息。

在一些实施例中，AMRMproxy组件还被配置为：接收Kubernetes系统发送的各个容器的状态信息；在系统状态存储组件中更新Kubernetes系统的各个容器的状态信息。

在一些实施例中，路由策略存储组件被配置为：预先存储各个子Hadoop系统的访问地址。

在一些实施例中，路由策略存储组件被配置为：预先存储Kubernetes系统中各个容器的访问地址。

在一些实施例中，AMRMproxy组件还被配置为：接收Kubernetes系统发送的应用任务运行产生的结果数据；将结果数据存储至Hadoop系统的分布式文件系统。

在一些实施例中，路由组件的数量是多个，多个路由组件被配置为随机接收客户端提交的应用任务，以实现负载均衡。

根据本公开实施例的又一个方面，提供了一种任务调度装置，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器中的指令，执行前述的任务调度方法。

根据本公开实施例的再一个方面，提供了一种计算机可读存储介质，其中，计算机可读存储介质存储有计算机指令，指令被处理器执行时实现前述的任务调度方法。

本公开实现了调度任务在Hadoop系统与Kubernetes系统间的运行和切换，从而实现了Hadoop系统与Kubernetes系统间的跨平台任务调度。

通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得清楚。

附图说明

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1示出了本公开一个实施例的任务调度方法的流程示意图。

图2示出了实现本公开任务调度方法的系统架构示意图。

图3示出了本公开一个实施例的任务调度平台的结构示意图。

图4示出了本公开另一个实施例的任务调度装置的结构示意图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本公开保护的范围。

发明人研究发现，很多电商的主营业务采用Kubernetes系统，同时大数据平台采用Hadoop系统。因此Kubernetes系统和Hadoop系统各自负责相对独立的业务。其中，Kubernetes系统主要用于承担用户在线购物的主营业务。但由于人的购物习惯，Kubernetes系统的主要压力是在白天的9点至24点之间。凌晨0至8点，Kubernetes系统约80％的资源处于闲置状态。另一方面，大数据平台为电商各业务部门提供7*24小时数据服务，Hadoop系统从每日凌晨开始将业务数据抽取到数据仓库中进行数据的加工、清洗、转换、加工等操作。

发明人通过自主研发实现了一种调度任务方案，使得Hadoop系统可以在凌晨0至8点期间利用Kubernetes系统闲置的资源进行数据计算与加工，从而复用闲置资源并节约成本。

为便于理解，首先对Hadoop系统以及kubernetes系统的运行原理进行简单介绍。

一、Hadoop系统的运行原理

Yarn是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager(RM)、NodeManager(NM)、ApplicationMaster(AM)。其中，ResourceManager(简称RM)负责整个集群的资源管理和分配，是一个全局的资源管理系统。NodeManager(简称NM)是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。ApplicationMaster(简称AM)用户提交的每个应用程序均包含1个AM，主要功能包括：与RM调度器协商以获取资源、将得到的任务进一步分配给内部的任务、与NM通信以启动/停止任务、监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

Hadoop系统的运行原理如下：

(1)Client客户端向ResourceManager提交应用程序，其中包括启动该应用的ApplicationMaster的必需信息，例如ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等；

(2)ResourceManager启动一个container容器用于运行ApplicationMaster；

(3)启动中的ApplicationMaster向ResourceManager注册，启动成功后与RM保持心跳；

(4)ApplicationMaster向ResourceManager发送请求，申请相应数目的container容器；

(5)ResourceManager返回ApplicationMaster的申请的containers容器信息。申请成功的container容器，由ApplicationMaster进行初始化；container容器的启动信息初始化后，AM与对应的NodeManager通信，要求NM启动container容器；AM与NM保持心跳，从而对NM上运行的任务进行监控和管理；

(6)container容器运行期间，ApplicationMaster对container进行监控，container通过RPC协议向对应的AM汇报自己的进度和状态等信息；

(7)应用运行期间，client直接与ApplicationMaster通信获取应用的状态、进度更新等信息；

(8)应用运行结束后，ApplicationMaster向ResourceManager注销自己，并允许属于它的container被收回。

二、kubernetes系统的运行原理

当业务系统需要部署到Kubernetes系统时，需要分配N个docker容器，并根据业务系统调整资源。例如，当节日促销时可以为增多业务系统的docker数量，当凌晨购物量减少时可以减少业务系统的docker数量。对业务系统而言，可以将docker视为物理服务器。作为Kubernetes系统，可以支持动态调整系统资源、按需分配。Kubernetes主要由以下几个核心组件组成：

(1)etcd保存了整个集群的状态；

(2)apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

(3)controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

(4)scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

(5)kubelet负责维护容器的生命周期，同时也负责Volume(CVI)和网络(CNI)的管理；

(6)Container runtime负责镜像管理以及Pod和容器的真正运行(CRI)；

(7)kube-proxy负责为Service提供cluster内部的服务发现和负载均衡。

三、Hadoop系统与Kubernetes系统间的跨平台任务调度方法

图1示出了本公开一个实施例的任务调度方法的流程示意图。如图1所示，本实施例中的任务调度方法包括步骤S102～步骤S106。

在步骤S102中，路由组件接收客户端提交的应用任务。

可选的，多个路由组件可以随机接收客户端提交的应用任务，以实现负载均衡。

在步骤S103中，路由组件判断当前满足第一预设条件还是第二预设条件。

在第一预设条件下执行步骤S104，第一预设条件例如可以是时间9点至24点。在步骤S104中，路由组件调用AMRMproxy组件将应用任务提交至Hadoop系统运行。

步骤S104具体可以包括步骤S1042～步骤S1046。

在步骤S1042中，路由组件调用系统状态存储组件，获取各个子Hadoop系统的状态信息；

在步骤S1044中，路由组件调用路由策略存储组件，获取空闲状态子Hadoop系统的访问地址；

在步骤S1046中，路由组件利用访问地址，调用AMRMproxy组件创建与空闲子Hadoop系统资源管理器ResourceManager的连接，以将应用任务提交至系统资源管理器运行。

在第二预设条件下执行步骤S106，第二预设条件例如可以是时间0点至9点。在步骤S106中，路由组件调用AMRMproxy组件将应用任务提交至Kubernetes系统运行。

步骤S106具体可以包括步骤S1062～步骤S1066。

在步骤S1062中，路由组件调用系统状态存储组件，获取Kubernetes系统中各个容器docker的状态信息；

在步骤S1064中，路由组件调用路由策略存储组件，获取空闲状态容器的访问地址；

在步骤S1066中，路由组件利用访问地址，调用AMRMproxy组件在空闲状态容器上运行Hadoop的服务镜像文件，以运行应用任务。

可选的，步骤S104还可以包括步骤S1041、S1043。

在步骤S1041中，AMRMproxy组件接收各个子Hadoop系统的资源管理器发送的心跳数据包，然后根据实际接收到各个子Hadoop系统的资源管理器发送的心跳数据包的频率，确定各个子Hadoop系统的状态，并在系统状态存储组件中更新将各个子Hadoop系统的状态信息。

在步骤S1043中，在路由策略存储组件中预先配置各个子Hadoop系统的访问地址。

可选的，步骤S106还可以包括步骤S1061、S1063。

在步骤S1061中，AMRMproxy组件接收Kubernetes系统发送的各个容器的状态信息，并在系统状态存储组件中更新Kubernetes系统的各个容器的状态信息。

在步骤S1063中，在路由策略存储组件中预先配置Kubernetes系统中各个容器的访问地址。

可选的，任务调度方法还可以包括步骤S108～步骤S112。

在步骤S108中，Kubernetes系统利用容器中的存储资源，存储应用任务运行产生的中间数据；

在步骤S110中，Kubernetes系统将应用任务运行产生的结果数据反馈至AMRMproxy组件；

在步骤S112中，AMRMproxy组件将结果数据存储至Hadoop系统的分布式文件系统。

上述实施例实现了调度任务在Hadoop系统与Kubernetes系统间的运行和切换，从而实现了Hadoop系统与Kubernetes系统间的跨平台任务调度。通过Hadoop系统与Kubernetes系统的跨平台任务调度，调度任务可以在不同系统间任意流转，从而合理利用计算资源。同时，上述实施例还通过技术手段屏蔽了系统间差异，实现了Hadoop系统与Kubernetes系统的调度任务统一管理，在用户无感知的情况下提高任务运行效率。此外，上述事实上例还能够实现Hadoop系统与Kubernetes系统的调度任务容灾，由于Hadoop系统和Kubernetes系统是跨机房的双系统，当由于其中一个系统宕机、机房断电等极端情况下，可以将调度任务切换跨机房的另一个系统上，从而保障数据的安全。

四、Hadoop系统与Kubernetes系统间的跨平台任务调度方法的具体应用例介绍。

图2示出了实现本公开任务调度方法的系统架构示意图。下面结合图2进行分阶段介绍。

(一)用户提交应用程序

Client是用户提交应用程序Application(简称：App)的客户端。用户需要向统一调度平台提交应用程序，由统一调度平台自动转发到可执行的子Hadoop系统，最终分发到Kubernetes系统上运行。任务调度平台简化了用户提交应用程序的操作，不必指定固定的yarn等信息，屏蔽了与用户无关的细节。

Client的实现方法包括：调用向统一调度平台提交应用程序Application。调用submitApplication(applicationId应用程序ID，application queue应用程序运行队列)方法向Yarn-Router提交应用程序Application应用程序的执行脚本。

提交Application方法的示例代码是：

public SubmitApplicationResponse submitApplication(

SubmitApplicationRequest request)throws YarnException,IOException{}

(二)统一调度平台的路由组件对应用程序进行处理

应用程序Application实际上被提交到统一调度平台的路由组件Router组件。Router是一组多个相同Router组成，多个Router起到负载均衡的作用。每个Application被随机分布到不同的Router上，并执行相同的功能逻辑。

首先，Router组件的主要作用是接收client提交的大量Application，并随机分布到route上进行处理，起到负载均衡的作用。其次，Router组件调用StateStore组件、PolicyStore组件获取必要信息。最后，Router组件将应用程序Application提交给AMRMproxy。

(三)路由Route获取StateStore组件中的系统信息

系统状态存储组件StateStore组件存储了系统状态信息，其中主要记录了所有子Hadoop系统和Kubernetes系统的状态信息。StateStore信息内容例如可以为：

clusterID//系统ID

clusterName//系统名称

clusterType//系统类型hadoop或Kubernetes系统

clusterState//系统状态，0空闲，1繁忙

alive//是否故障，0正常，1故障

usable//是否可用，0可用，1不可用

StateStore的信息可以存储在MYSQL数据库中，并接口形式对其他组件提供增加、删除、修改、查询操作。

(1)StateStore的信息可以由子Hadoop系统sub-cluster通过心跳定制发送到AMRMproxy组件。AMRMproxy调用StateStore新增接口存储系统最新数据，示例代码为：

StateStore.addClusterInfo//存储系统信息

(2)Route组件可以调用StateStore的查询接口进行数据查询，示例方法为：

StateStore.getClusterInfo//存储系统信息

(3)系统管理员可以调用StateStore的修改接口修改系统信息。示例代码为：

StateStore.updateClusterInfo//修改系统信息

(4)系统管理员可以调用StateStore的删除接口删除系统信息，示例代码为：

StateStore.deleteClusterInfo//删除系统信息

(四)Route获取PolicyStore路由策略

PolicyStore是路由策略存储组件，其中主要包含应用程序和资源请求如何路由到不同子Hadoop系统的策略。PolicyStore本质上是一份配置文件，记录应用程序Application与子Hadoop系统的对应关系。Route组件只有获得PolicyStore的路由策略会自动解析到能够使用的hadoop系统地址和ResourceManager地址，例如源ip地址为192.168.1.1的数据包通过该路由的时下一跳ip地址为172.168.1.1。内容示例代码为：

RM//ResourManager地址，例如：http://172.0.0.1

NS//NodeSpace地址：hdfs://ns/user/***

路由策略示例代码为：route-map(conf)#int e1/0(conf-if)#ip policy route-map pdb

(五)AMRMproxy与hadoop系统ResourceManager交互

AMRMproxy是应用程序和Hadoop系统的ResourceManager通讯的桥梁，是统一调度平台的核心功能。应用程序application与ResourceManager的所有通信都通过AMRMProxy进行。由AMRMProxy分配调度任务运行在hadoop系统上。

1、AMRMproxy心跳

正常情况下子Hadoop系统的ResourceManager每3秒钟向AMRMproxy组件提交一次系统信息(即：心跳)。

(1)若心跳按时到达，AMRMproxy认为hadoop系统正常可用，后续应用程序继续提交到此hadoop系统，并更新StateStore的信息：

系统信息示例代码为：

clusterState＝0//系统空闲

Alive＝0//正常

Usable＝0//可用

(2)若300秒心跳未达到，AMRMproxy认为此Hadoop系统繁忙，需将应用程序提交到此其他hadoop系统。更新StateStore的信息示例代码为：

clusterState＝1//繁忙

Alive＝0//正常

Usable＝1//不可用

(3)若600秒心跳未达到，AMRMproxy认为此Hadoop系统故障，需将应用程序提交到此其他hadoop系统，更新StateStore的信息示例代码为：

clusterState＝1//繁忙

Alive＝1//故障

Usable＝1//不可用

2、AMRMproxy向Hadoop的ResourceManager提交应用任务

Router组件会获取StateStore中的系统的信息，并会轮询选择可以使用的系统；Router组件还会获取PolicyStore中的路由策略，并自动解析可以系统的访问路径。当Route组件调用AMRMproxy组件时，会默认带上StateStore、PolicyStore信息，示例代码为：

clusterID＝11000//系统ID

clusterName＝10K//系统名称

RM＝172.169.2.11:888//ResourManager地址

NS＝hdfs://ns1/user///NodeSpace地址

JH(jobhistory)＝172.169.2.13:888//jobHistory地址

然后，AMRMproxy组件根据上述信息通过TCP/IP的3次握手协议创建与指定系统ResourManager连接，将应用程序Application提交到此系统的ResourceManager运行。

(六)AMRMproxy触发自动部署Kubernetes服务

当AMRMproxy向Hadoop系统的ResourManager提交调度任务时，若时间为每天凌晨0-9点，AMRMproxy自动触发Hadoop系统服务部署到Kubernetes系统的功能，因为在这段时间内Kubernetes系统的资源是相对闲置的，才可以为hadoop提供服务。若时间为每天凌晨9-24点时，AMRMproxy会将任务提交到Hadoop系统执行。因为在这段时间内Kubernetes系统需要为电商提供服务。自动部署功能本质上是在Kubernetes系统的docker上运行Hadoop的服务镜像文件，具体包括：

(1)Yarn的ResourceManager启动，示例代码为：

service ssh start

#获取容器IP

ip＝`ifconfig eth0|grep'inet addr'|cut-d:-f 2|cut-d”-f 1`

sed-i"s/hadoop-master/$ip/"$HADOOP_HOME/etc/hadoop/

core-site.xml

sed-i"s/hadoop-master/$ip/"$HADOOP_HOME/etc/hadoop/

yarn-site.xml

#启动master节点hadoop

$HADOOP_HOME/sbin/start-dfs.sh&

$HADOOP_HOME/sbin/start-yarn.sh&

#启动hosts注册服务(

/tmp/registerServer&

/bin/gotty--port 8000--permit-write--reconnect/bin/bash

(2)Yarn的NodeManager启动，示例代码为：

service ssh start

#传进master的server名

sed-i"s/hadoop-master/$1/"$HADOOP_HOME/etc/hadoop/

core-site.xml

sed-i"s/hadoop-master/$1/"$HADOOP_HOME/etc/hadoop/

yarn-site.xml

#启动NodeManager和DataNode服务

/usr/local/hadoop/sbin/hadoop-daemon.sh start datanode&

/usr/local/hadoop/sbin/yarn-daemon.sh start nodemanager&

#启动向master注册hostname和ip的服务

/tmp/registerClient$1

#为了容器启动后不退出

tail-f/dev/null

至此Hadoop的服务已经在Kubernetes系统上运行起来，可以支持Hadoop的计算任务执行。

(七)调度任务在Kubernetes系统上计算与存储

当在Kubernetes系统上启动Hadoop服务成功后，Hadoop系统的计算任务即可通过ResourceManager将任务分配到Kubernetes上运行Hadoop的计算任务。在Kubernetes系统上启动Hadoop服务中运行与在Hadoop系统中运行相比，在计算结果存储的处理方式有如下区别：计算任务中生成的中间数据、过渡数据、临时数据等非最终结果数据，存储在Kubernetes系统docker的本地存储中，占用的docker本身的存储资源；计算任务的最终结果需要存储到hadoop系统HDFS中存储并保持，避免Kubernetes系统资源回收后造成的数据流失。

上述应用例能够充分利用kubernetes系统在夜间的空闲运行任务，充分利用kubernetes系统的计算资源进行海量数据计算与加工，从而为企业节省巨大的硬件资源采购成本。Hadoop与kubernetes系统的混合调度、调度任务统一管理、调度任务的容灾，能够满足电商等行业运行各种业务时所需的生产环境。

下面结合图3描述本公开一个实施例的任务调度平台。

图3示出了本公开一个实施例的任务调度平台的结构示意图。如图3所示，本实施例中的任务调度平台30包括：路由组件302以及AMRMproxy组件304。其中，路由组件302被配置为接收客户端提交的应用任务；在第一预设条件下，路由组件302被配置为调用AMRMproxy组件304将应用任务提交至Hadoop系统运行；在第二预设条件下，路由组件602被配置为调用AMRMproxy组件304将应用任务提交至Kubernetes系统运行。

在一些实施例中，任务调度平台30还包括系统状态存储组件306以及路由策略存储组件308；路由组件302被配置为：调用系统状态存储组件306，获取各个子Hadoop系统的状态信息；调用路由策略存储组件308，获取空闲状态子Hadoop系统的访问地址；利用访问地址，调用AMRMproxy组件304创建与空闲子Hadoop系统资源管理器ResourceManager的连接，以将应用任务提交至系统资源管理器运行。

在一些实施例中，任务调度平台30还包括系统状态存储组件306以及路由策略存储组件308；路由组件302被配置为：调用系统状态存储组件306，获取Kubernetes系统中各个容器docker的状态信息；调用路由策略存储组件308，获取空闲状态容器的访问地址；路由组件302利用访问地址，调用AMRMproxy组件304在空闲状态容器上运行Hadoop的服务镜像文件，以运行应用任务。

在一些实施例中，AMRMproxy组件304还被配置为：接收各个子Hadoop系统的资源管理器发送的心跳数据包；根据实际接收到各个子Hadoop系统的资源管理器发送的心跳数据包的频率，确定各个子Hadoop系统的状态；在系统状态存储组件306中更新将各个子Hadoop系统的状态信息。

在一些实施例中，AMRMproxy组件304还被配置为：接收Kubernetes系统发送的各个容器的状态信息；在系统状态存储组件306中更新Kubernetes系统的各个容器的状态信息。

在一些实施例中，路由策略存储组件308被配置为：预先存储各个子Hadoop系统的访问地址。

在一些实施例中，路由策略存储组件308被配置为：预先存储Kubernetes系统中各个容器的访问地址。

在一些实施例中，AMRMproxy组件304还被配置为：接收Kubernetes系统发送的应用任务运行产生的结果数据；将结果数据存储至Hadoop系统的分布式文件系统。

在一些实施例中，路由组件302的数量是多个，多个路由组件被配置为随机接收客户端提交的应用任务，以实现负载均衡。

图4示出了本公开另一个实施例的任务调度装置的结构示意图。如图4所示，该实施例的任务调度装置40包括：存储器410以及耦接至该存储器410的处理器420，处理器420被配置为基于存储在存储器410中的指令，执行前述任意一个实施例中的任务调度方法。其中，存储器410例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序(Boot Loader)以及其他程序等。

任务调度装置40还可以包括输入输出接口430、网络接口440、存储接口450等。这些接口430、440、450以及存储器410和处理器420之间例如可以通过总线460连接。其中，输入输出接口430为显示器、鼠标、键盘、触摸屏等输入输出设备提供连接接口。网络接口440为各种联网设备提供连接接口。存储接口450为SD卡、U盘等外置存储设备提供连接接口。

本公开还包括一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现前述任意一个实施例中的任务调度方法。

本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

Claims

1.一种任务调度方法，包括：

路由组件接收客户端提交的应用任务；

在第一预设条件下，路由组件调用AMRMproxy组件将所述应用任务提交至Hadoop系统运行；

在第二预设条件下，路由组件调用AMRMproxy组件将所述应用任务提交至Kubernetes系统运行。

2.如权利要求1所述的任务调度方法，其中，所述路由组件调用AMRMproxy组件将所述应用任务提交至Hadoop系统运行包括：

路由组件调用系统状态存储组件，获取各个子Hadoop系统的状态信息；

路由组件调用路由策略存储组件，获取空闲状态子Hadoop系统的访问地址；

路由组件利用所述访问地址，调用AMRMproxy组件创建与空闲子Hadoop系统资源管理器ResourceManager的连接，以将所述应用任务提交至所述系统资源管理器运行。

3.如权利要求1所述的任务调度方法，其中，所述路由组件调用AMRMproxy组件将所述应用任务提交至Kubernetes系统运行包括：

路由组件调用系统状态存储组件，获取Kubernetes系统中各个容器docker的状态信息；

路由组件调用路由策略存储组件，获取空闲状态容器的访问地址；

路由组件利用所述访问地址，调用AMRMproxy组件在所述空闲状态容器上运行Hadoop的服务镜像文件，以运行所述应用任务。

4.如权利要求2所述的任务调度方法，其中，所述任务调度方法还包括：

AMRMproxy组件接收各个子Hadoop系统的资源管理器发送的心跳数据包；

AMRMproxy组件根据实际接收到各个子Hadoop系统的资源管理器发送的心跳数据包的频率，确定各个子Hadoop系统的状态；

AMRMproxy组件在所述系统状态存储组件中更新将各个子Hadoop系统的状态信息。

5.如权利要求3所述的任务调度方法，其中，所述任务调度方法还包括：

AMRMproxy组件接收Kubernetes系统发送的各个容器的状态信息；

AMRMproxy组件在所述系统状态存储组件中更新Kubernetes系统的各个容器的状态信息。

6.如权利要求2所述的任务调度方法，其中，所述任务调度方法还包括：

在路由策略存储组件中预先配置各个子Hadoop系统的访问地址。

7.如权利要求3所述的任务调度方法，其中，所述任务调度方法还包括：

在路由策略存储组件中预先配置Kubernetes系统中各个容器的访问地址。

8.如权利要求1所述的任务调度方法，其中，所述第一预设条件是时间为9点至24点；所述第二预设条件是时间为0点至9点。

9.如权利要求1所述的任务调度方法，其中，所述任务调度方法还包括：

Kubernetes系统利用容器中的存储资源，存储所述应用任务运行产生的中间数据；

Kubernetes系统将所述应用任务运行产生的结果数据反馈至AMRMproxy组件；

AMRMproxy组件将所述结果数据存储至Hadoop系统的分布式文件系统。

10.如权利要求1所述的任务调度方法，其中，所述路由组件接收客户端提交的应用任务包括：

多个路由组件随机接收客户端提交的应用任务，以实现负载均衡。

11.一种任务调度平台，包括路由组件以及AMRMproxy组件，其中，路由组件被配置为接收客户端提交的应用任务；

在第一预设条件下，路由组件被配置为调用AMRMproxy组件将所述应用任务提交至Hadoop系统运行；

在第二预设条件下，路由组件被配置为调用AMRMproxy组件将所述应用任务提交至Kubernetes系统运行。

12.如权利要求11所述的任务调度平台，所述任务调度平台还包括系统状态存储组件以及路由策略存储组件；

路由组件被配置为：调用系统状态存储组件，获取各个子Hadoop系统的状态信息；调用路由策略存储组件，获取空闲状态子Hadoop系统的访问地址；利用所述访问地址，调用AMRMproxy组件创建与空闲子Hadoop系统资源管理器ResourceManager的连接，以将所述应用任务提交至所述系统资源管理器运行。

13.如权利要求11所述的任务调度平台，所述任务调度平台还包括系统状态存储组件以及路由策略存储组件；

路由组件被配置为：调用系统状态存储组件，获取Kubernetes系统中各个容器docker的状态信息；调用路由策略存储组件，获取空闲状态容器的访问地址；路由组件利用所述访问地址，调用AMRMproxy组件在所述空闲状态容器上运行Hadoop的服务镜像文件，以运行所述应用任务。

14.如权利要求12所述的任务调度平台，其中，所述AMRMproxy组件还被配置为：

接收各个子Hadoop系统的资源管理器发送的心跳数据包；

根据实际接收到各个子Hadoop系统的资源管理器发送的心跳数据包的频率，确定各个子Hadoop系统的状态；

在所述系统状态存储组件中更新将各个子Hadoop系统的状态信息。

15.如权利要求13所述的任务调度平台，其中，所述AMRMproxy组件还被配置为：

接收Kubernetes系统发送的各个容器的状态信息；

在所述系统状态存储组件中更新Kubernetes系统的各个容器的状态信息。

16.如权利要求12所述的任务调度平台，其中，所述路由策略存储组件被配置为：预先存储各个子Hadoop系统的访问地址。

17.如权利要求13所述的任务调度平台，其中，所述路由策略存储组件被配置为：预先存储Kubernetes系统中各个容器的访问地址。

18.如权利要求11所述的任务调度平台，其中，所述第一预设条件是时间为9点至24点；所述第二预设条件是时间为0点至9点。

19.如权利要求11所述的任务调度平台，其中，所述AMRMproxy组件还被配置为：

接收Kubernetes系统发送的所述应用任务运行产生的结果数据；

将所述结果数据存储至Hadoop系统的分布式文件系统。

20.如权利要求11所述的任务调度平台，其中，所述路由组件的数量是多个，多个路由组件被配置为随机接收客户端提交的应用任务，以实现负载均衡。

21.一种任务调度装置，包括：

存储器；以及

耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器中的指令，执行如权利要求1至10中任一项所述的任务调度方法。

22.一种计算机可读存储介质，其中，所述计算机可读存储介质存储有计算机指令，所述指令被处理器执行时实现如权利要求1至10中任一项所述的任务调度方法。