基于spark的分布计算引擎服务

技术领域

本公开涉及大数据计算技术领域，尤其涉及一种基于spark的分布计算方法、基于spark的分布计算引擎服务系统和电子设备。

背景技术

随着大数据技术的发展，企业对数据分析的需求越来越旺盛，同时随着数据量的增加和分析需求的复杂化，对于数据计算引擎的扩展性和高可用性也提出了更高的要求。同时spark作为一款广泛使用的开源计算框架，被应用在很多数据分析产品中提供计算服务，如何利用spark提供高可用的计算服务成为一个技术难点。

spark作为计算框架，不像传统数据库可以直接提供sql查询服务，而是需要用户自己编程提交代码，或者启动Thrift Server提供sql服务，但是Thrift Server是单副本程序，无法提供高可用的服务，一旦程序异常退出则需要人工重启服务，同时Thrift Server无法做资源隔离及横向扩展，导致很容易被单个用户的请求占满资源，影响其他用的的查询。

况且利用spark做数据分析需要用户编程并提交代码，响应过慢且门槛高。

此外，Thrift Server可以基于spark提供sql服务，但是Thrift Server既是任务接收方又是执行方，所以只能启动单个程序，一旦程序因为某些sql卡住或者崩溃就无法提供服务，同时无法做资源隔离和水平扩展。

发明内容

为了解决上述问题，本申请提出一种基于spark的分布计算方法、基于spark的分布计算引擎服务系统和电子设备。

本申请一方面，提出一种基于spark的分布计算方法，包括如下步骤：

S1、用户(BI Server)提交数据查询请求的任务到任务分发组件(Job ControlTower)；

S2、任务分发组件(Job Control Tower)将任务写入并通知到任务队列(PG)；

S3、任务队列(PG)接收到任务后通知spark中分布式设置的计算组件(Spark JobEngine)拉取任务；

S4、计算组件(Spark Job Engine)从任务队列(PG)拉取任务，并提交任务给spark；

S5、spark执行任务。

作为本申请的一可选实施方案，可选地，步骤S3中，在通知spark中分布式设置的计算组件(Spark Job Engine)拉取任务之后，还包括：

从spark分布式设置的计算组件(Spark Job Engine)中，判断可用的计算组件(Spark Job Engine)；

将该可用的计算组件(Spark Job Engine)作为目标计算组件(Spark JobEngine)。

作为本申请的一可选实施方案，可选地，步骤S3中，在通知spark中分布式设置的计算组件(Spark Job Engine)拉取任务之后，还包括：

判断所述目标计算组件(Spark Job Engine)的数量是否不低于两个：

若是，则进入步骤S4；

反之放弃，并发出对应的计算服务通知。

作为本申请的一可选实施方案，可选地，步骤S4中，在计算组件(Spark JobEngine)从任务队列(PG)拉取任务，并提交任务给spark之前，还包括：

判断是否存在多个所述目标计算组件(Spark Job Engine)：

若是，则从多个所述目标计算组件(Spark Job Engine)中，选取一个所述目标计算组件(Spark Job Engine)执行任务；若是存在多个任务，则分别随机选择一个所述目标计算组件(Spark Job Engine)执行相应的任务；

反之放弃。

作为本申请的一可选实施方案，可选地，步骤S5，在spark执行任务之后，还包括：

由spark通知所述目标计算组件(Spark Job Engine)任务完成，并将执行任务的计算结果反馈至对应的所述目标计算组件(Spark Job Engine)；

所述目标计算组件(Spark Job Engine)将所述计算结果写入所述任务队列(PG)，同时通知所述任务队列(PG)；

任务队列(PG)通知所述任务分发组件(Job Control Tower)任务完成；

所述任务分发组件(Job Control Tower)获取任务的所述计算结果，并返回用户(BI Server)。

本申请另一方面，提出一种基于spark的分布计算引擎服务系统，包括：

任务分发组件(Job Control Tower)，用于接收用户(BI Server)提交的数据查询请求的任务，并将任务写入并通知到任务队列(PG)；

任务队列(PG)，用于接收到任务后，通知spark中分布式设置的计算组件(SparkJob Engine)拉取任务；

计算组件(Spark Job Engine)，用于从任务队列(PG)拉取任务，并提交任务给spark；

spark，用于执行任务，执行完毕，通知所述目标计算组件(Spark Job Engine)任务完成，并将执行任务的计算结果反馈至对应的所述目标计算组件(Spark Job Engine)。

作为本申请的一可选实施方案，可选地，所述任务队列(PG)，还用于：

在通知spark中分布式设置的计算组件(Spark Job Engine)拉取任务之后，从spark分布式设置的计算组件(Spark Job Engine)中，判断可用的计算组件(Spark JobEngine)；

将该可用的计算组件(Spark Job Engine)作为目标计算组件(Spark JobEngine)。

作为本申请的一可选实施方案，可选地所述任务队列(PG)，还用于：

在计算组件(Spark Job Engine)从任务队列(PG)拉取任务，并提交任务给spark之前，判断所述目标计算组件(Spark Job Engine)的数量是否不低于两个：

若是，则进入步骤S4；

反之放弃，并发出对应的计算服务通知。

作为本申请的一可选实施方案，可选地，

所述目标计算组件(Spark Job Engine)，还用于：将所述计算结果写入所述任务队列(PG)，同时通知所述任务队列(PG)；

任务队列(PG)，还用于：通知所述任务分发组件(Job Control Tower)任务完成；

所述任务分发组件(Job Control Tower)，还用于：获取任务的所述计算结果，并返回用户(BI Server)。

本申请另一方面，还提出一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令时实现所述的一种基于spark的分布计算方法。

本发明的技术效果：

本申请通过解耦任务分配与任务计算层，使得任务计算层可以由多个计算进程(多个可用的计算组件(Spark Job Engine)共同提供服务，支持启动多个任务，从而避免执行任务过程中宕机而影响整体服务，多个任务计算组件也可以避免单个用户请求占满所有资源而影响服务，同时常驻的spark计算组件可以提供实时的数据查询服务，避免用户编程提交代码的高门槛和高延迟。防止单个查询导致整体不可用。解决原有的Thrift Server只能由单个服务提供JDBC连接，无法实现高可用，同时执行复杂sql的时候Thrift Server服务容易卡住或者崩溃的技术缺点。

根据下面参考附图对示例性实施例的详细说明，本公开的其它特征及方面将变得清楚。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本公开的示例性实施例、特征和方面，并且用于解释本公开的原理。

图1示出为本发明基于spark的分布计算方法的实施流程示意图；

图2示出为本发明基于spark的分布计算引擎服务系统的应用系统示意图；

图3示出为本发明电子设备的应用示意图。

具体实施方式

以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本公开，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以实施。在一些实例中，对于本领域技术人员熟知的、手段、元件和电路未作详细描述，以便于凸显本公开的主旨。

实施例1

本申请基于spark执行用于递交的数据查询任务，spark的任务执行不在本申请的考虑之中。

如图1所示，本申请一方面，提出一种基于spark的分布计算方法，包括如下步骤：

S1、用户(BI Server)提交数据查询请求的任务到任务分发组件(Job ControlTower)；

S2、任务分发组件(Job Control Tower)将任务写入并通知到任务队列(PG)；

S3、任务队列(PG)接收到任务后通知spark中分布式设置的计算组件(Spark JobEngine)拉取任务；

S4、计算组件(Spark Job Engine)从任务队列(PG)拉取任务，并提交任务给spark；

S5、spark执行任务。

原有的Thrift Server只能由单个服务提供JDBC连接，无法实现高可用，同时执行复杂sql的时候Thrift Server服务容易卡住或者崩溃。

本实施例，目标计算组件(Spark Job Engine)的数量，具体根据需要执行的任务数量而定，可以一个或者多个。

如图2所示，本申请在spark中设置有分布式部署的多个计算组件(Spark JobEngine)(图2中简述为Job Engine1、Job Engine2和Job Engine3)，其中，分布的(SparkJob Engine)，有的是单计算进程组件，有的是双进程组件(Job Engine1)，可以用来执行不同任务类型的任务进程。比如若是任务包含同时的两项执行内容，则可以选择双进程的比如Job Engine1，作为目标计算组件(Spark Job Engine)执行该任务。

具体执行任务时，根据任务类型，选择对应的计算组件(Spark Job Engine)作为对应任务的目标计算组件(Spark Job Engine)。

因此，本申请通过解耦任务分配与任务计算层，使得任务计算层可以由多个计算进程(多个可用的计算组件(Spark Job Engine)共同提供服务，支持启动多个任务，从而避免执行任务过程中宕机而影响整体服务，多个任务计算组件也可以避免单个用户请求占满所有资源而影响服务，同时常驻的spark计算组件可以提供实时的数据查询服务，避免用户编程提交代码的高门槛和高延迟。

本实施例中，任务队列(PG)，可以通过常见的消息队列(包括但不限于redis、kafka、postgres等)及数据库(包括但不限于postgres、mysql等)实现，本实施例不进行限定。

作为本申请的一可选实施方案，可选地，步骤S3中，在通知spark中分布式设置的计算组件(Spark Job Engine)拉取任务之后，还包括：

从spark分布式设置的计算组件(Spark Job Engine)中，判断可用的计算组件(Spark Job Engine)；

将该可用的计算组件(Spark Job Engine)作为目标计算组件(Spark JobEngine)。

如图2所示，需要为当前任务适配对应的计算组件(Spark Job Engine)，找到对当前任务可用的计算组件(Spark Job Engine)，作为目标计算组件(Spark Job Engine)。若是存在多个可以执行任务的计算组件，则只选取一个执行。

作为本申请的一可选实施方案，可选地，步骤S3中，在通知spark中分布式设置的计算组件(Spark Job Engine)拉取任务之后，还包括：

判断所述目标计算组件(Spark Job Engine)的数量是否不低于两个：

若是，则进入步骤S4；

反之放弃，并发出对应的计算服务通知。

计算组件可以通过启动多个副本实现水平扩展。

因此，需要判定分布式部署的多个计算组件(Spark Job Engine)中，至少要有两个计算组件(Spark Job Engine)可用，以此保证如果某个特定的计算组件(Spark JobEngine)无法正常工作，其它计算组件可以继续处理任务而不停机，从而实现高可用。

计算组件(Spark Job Engine)的可用判定，可以由系统后台根据各个计算组件(Spark Job Engine)的后台进程程序来判定，若是后台进程程序停止，则认定不可用。

本实施例，若是可用的计算组件(Spark Job Engine)的数量低于两个，可以由后台发出预警，但是并不要求停机维护，系统仍然可用，只是性能会略微降低。

作为本申请的一可选实施方案，可选地，步骤S4中，在计算组件(Spark JobEngine)从任务队列(PG)拉取任务，并提交任务给spark之前，还包括：

判断是否存在多个所述目标计算组件(Spark Job Engine)：

若是，则从多个所述目标计算组件(Spark Job Engine)中，选取一个所述目标计算组件(Spark Job Engine)执行任务；若是存在多个任务，则分别随机选择一个所述目标计算组件(Spark Job Engine)执行相应的任务；

反之放弃。

若是对于当前的任务，Spark中存在多个适配执行该任务的目标计算组件(SparkJob Engine)，则可以从中选择一个执行该任务。

可以采用随机算法，随机选取一个。

也可以调取各个目标计算组件(Spark Job Engine)的后台进程程序的进程值(比如PID)，进行排序，从中找到排序靠前的进程作为执行该任务的目标计算组件(Spark JobEngine)。

作为本申请的一可选实施方案，可选地，步骤S5，在spark执行任务之后，还包括：

由spark通知所述目标计算组件(Spark Job Engine)任务完成，并将执行任务的计算结果反馈至对应的所述目标计算组件(Spark Job Engine)；

所述目标计算组件(Spark Job Engine)将所述计算结果写入所述任务队列(PG)，同时通知所述任务队列(PG)；

任务队列(PG)通知所述任务分发组件(Job Control Tower)任务完成；

所述任务分发组件(Job Control Tower)获取任务的所述计算结果，并返回用户(BI Server)。

spark执行任务之后，将任务执行的计算结果反馈用户。具体结合附图1和上述递交任务的过程进行理解。

显然，本领域的技术人员应该明白，实现上述实施例中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成的，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各控制的实施例的流程。本领域技术人员可以理解，实现上述实施例中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成的，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各控制的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)、随机存储记忆体(RandomAccessMemory，RAM)、快闪存储器(FlashMemory)、硬盘(HardDiskDrive，缩写：HDD)或固态硬盘(Solid-StateDrive，SSD)等；存储介质还可以包括上述种类的存储器的组合。

实施例2

基于实施例1的实施原理，本申请另一方面，提出一种基于spark的分布计算引擎服务系统，包括：

任务分发组件(Job Control Tower)，用于接收用户(BI Server)提交的数据查询请求的任务，并将任务写入并通知到任务队列(PG)；

任务队列(PG)，用于接收到任务后，通知spark中分布式设置的计算组件(SparkJob Engine)拉取任务；

计算组件(Spark Job Engine)，用于从任务队列(PG)拉取任务，并提交任务给spark；

spark，用于执行任务，执行完毕，通知所述目标计算组件(Spark Job Engine)任务完成，并将执行任务的计算结果反馈至对应的所述目标计算组件(Spark Job Engine)。

作为本申请的一可选实施方案，可选地，所述任务队列(PG)，还用于：

在通知spark中分布式设置的计算组件(Spark Job Engine)拉取任务之后，从spark分布式设置的计算组件(Spark Job Engine)中，判断可用的计算组件(Spark JobEngine)；

将该可用的计算组件(Spark Job Engine)作为目标计算组件(Spark JobEngine)。

作为本申请的一可选实施方案，可选地所述任务队列(PG)，还用于：

在计算组件(Spark Job Engine)从任务队列(PG)拉取任务，并提交任务给spark之前，判断所述目标计算组件(Spark Job Engine)的数量是否不低于两个：

若是，则进入步骤S4；

反之放弃，并发出对应的计算服务通知。

作为本申请的一可选实施方案，可选地，

所述目标计算组件(Spark Job Engine)，还用于：将所述计算结果写入所述任务队列(PG)，同时通知所述任务队列(PG)；

任务队列(PG)，还用于：通知所述任务分发组件(Job Control Tower)任务完成；

所述任务分发组件(Job Control Tower)，还用于：获取任务的所述计算结果，并返回用户(BI Server)。

本实施例的“基于spark的分布计算引擎服务系统”，其各个应用主体的功能和交互，详见实施例1的描述。

上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

实施例3

如图3所示，更进一步地，本申请另一方面，还提出一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令时实现所述的一种基于spark的分布计算方法。

本公开实施例来电子设备包括处理器以及用于存储处理器可执行指令的存储器。其中，处理器被配置为执行可执行指令时实现前面任一所述的一种基于spark的分布计算方法。

此处，应当指出的是，处理器的个数可以为一个或多个。同时，在本公开实施例的电子设备中，还可以包括输入装置和输出装置。其中，处理器、存储器、输入装置和输出装置之间可以通过总线连接，也可以通过其他方式连接，此处不进行具体限定。

存储器作为一计算机可读存储介质，可用于存储软件程序、计算机可执行程序和各种模块，如：本公开实施例的一种基于spark的分布计算方法所对应的程序或模块。处理器通过运行存储在存储器中的软件程序或模块，从而执行电子设备的各种功能应用及数据处理。

输入装置可用于接收输入的数字或信号。其中，信号可以为产生与设备/终端/服务器的用户设置以及功能控制有关的键信号。输出装置可以包括显示屏等显示设备。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。