CN110995725A - 数据处理方法和装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供的数据处理方法和装置、电子设备及计算机可读存储介质，涉及数据处理技术领域。在本申请实施例中，首先，对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息。其次，将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。通过上述方法，可以提高数据处理的效率。

Description

数据处理方法和装置、电子设备及计算机可读存储介质

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种数据处理方法和装置、电子设备及计算机可读存储介质。

背景技术

在现有的大数据处理场景中，主要分成两大类，一类是针对大批量数据的批处理方式，另一类是针对实时流处理，基于这样的需求，许多的大数据开源组件都提供了这两类场景中的一类或者两类解决方案，如Hadoop MapReduce、Storm、Spark、Flink等，而Spark正是其中比较优秀的大数据开源计算引擎之一，它通过Spark core和Spark sql两个子组件满足了大数据批量计算的需求，通过Spark Streaming和Spark Structured Streaming两个子组件满足了大数据流式实时计算的需求。但是正是由于其分布式计算的特性，在执行Spark应用时往往需要通过脚本的方式将程序提交到Spark集群去执行，集群执行程序的业务逻辑，最终把结果保存到持久化存储系统(如：Hbase、Elasticsearch等)或者内存存储系统(如：Redis等)中，然后需要此结果数据的第三方应用再从这些存储系统中获取这些结果数据。

从这个流程来看，从提交应用到执行程序再到获取结果，是一个异步的过程。首先第三方系统只能通过脚本命令的方式提交应用，而这种方式很难以低耦合的方式内嵌或者集成到第三方系统内部，从而以平滑无侵入的方式提交请求，其次在获取执行结果的时候，其实很难及时获知应用已经执行完成，结果已经生成，只能通过其它的方式去间接同步获取结果(比如轮询)，或者不主动获取结果，而是被动触发获取结果(比如由另一套系统来触发这个操作)，而这两种方式都很难完美解决由客户端子系统(或者第三方系统)同步发出请求，等待响应的需求。

在现有技术中，上述通过Spark应用进行大数据计算的数据处理方式流程复杂，从而存在着数据处理的效率低的问题。

发明内容

有鉴于此，本申请的目的在于提供一种数据处理方法和装置、电子设备及计算机可读存储介质，以改善现有技术中存在的问题。

为实现上述目的，本申请实施例采用如下技术方案：

一种数据处理方法，包括：

对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息；

将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

在本申请实施例较佳的选择中，所述对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息的步骤，包括：

通过负载均衡进程对待处理的至少一个请求报文进行分发处理；

通过至少一个请求消息前置进程对分发处理后的各请求报文统一进行打包处理，得到至少一个请求消息。

在本申请实施例较佳的选择中，所述通过至少一个请求消息前置进程对分发处理后的各请求报文统一进行打包处理，得到至少一个请求消息的步骤，包括：

对各请求报文进行JSON打包处理，得到属于JSON文件格式的至少一个请求消息。

在本申请实施例较佳的选择中，所述将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果的步骤，包括：

通过包括至少一个redis频道的redis进程将各请求消息发送至对应的各Spark应用进程，并通过各Spark应用进程将所述各请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

在本申请实施例较佳的选择中，所述Spark集群设置有SparkSession进程，所述将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果的步骤，包括：

通过所述SparkSession进程控制所述Spark集群启动并初始化；

将所述至少一个请求消息发送至初始化后的Spark集群进行计算，得到各请求消息对应的各计算结果。

在本申请实施例较佳的选择中，所述数据处理方法还包括：

通过至少一个Spark应用进程对所述各计算结果打包成对应的各响应消息；

通过至少一个请求消息前置进程对各响应消息进行转换处理，得到对应的各响应报文并发送至客户端设备。

在本申请实施例较佳的选择中，所述通过至少一个请求消息前置进程对各响应消息进行转换处理，得到对应的各响应报文并发送至客户端设备的步骤，包括：

通过至少一个请求消息前置进程将各响应消息转换成各客户端设备对应的http响应报文，并通过负载均衡进程将各http响应报文分发至对应的所述客户端设备。

本申请实施例还提供了一种数据处理装置，包括：

请求报文处理模块，用于对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息；

请求消息计算模块，用于将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

本申请实施例还提供了一种电子设备，包括存储器和处理器，所述处理器用于执行所述存储器中存储的可执行的计算机程序，以实现上述的数据处理方法。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被执行时实现上述数据处理方法的步骤。

本申请实施例提供的数据处理方法和装置、电子设备及计算机可读存储介质，通过对请求报文进行分发处理和打包处理之后发送至Spark集群进行计算，得到对应的计算结果，以避免现有技术中通过Spark应用进行大数据计算的数据处理方式流程复杂，所导致的数据处理的效率低的问题。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的电子设备的结构框图。

图2为本申请实施例提供的数据处理方法的流程示意图。

图3为本申请实施例提供的步骤S110的流程示意图。

图4为本申请实施例提供的数据处理装置的结构框图。

图标：10-电子设备；12-存储器；14-处理器；100-数据处理装置；110-请求报文处理模块；120-请求消息计算模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

如图1所示，本申请实施例提供了一种电子设备10。其中，所述电子设备10可以包括存储器12、处理器14和数据处理装置100。

可选地，所述电子设备10的具体种类不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，所述电子设备10可以是服务端设备。其中，所述服务端设备上设置有服务器端子系统，所述服务器端子系统可以与客户端子系统相对应，构成客户/服务器(Client/Server，C/S)系统结构。所述服务器端子系统可以泛指为所述客户端子系统提供业务服务或者数据服务的子系统，用户通过所述客户端子系统提交请求，所述服务器端子系统接收到该请求后，开始执行请求对应的业务逻辑，并将结果返回给所述客户端子系统，所述客户端子系统通过某种表现形式展现给用户。一般来说，所述服务端子系统部署在远程服务器上，可以是部署到一台服务器上，也可以在多台服务器上进行部署，并通过负载均衡的方式供客户端子系统进行访问。

详细地，所述存储器12和处理器14之间直接或间接地电性连接，以实现数据的传输或交互。例如，相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述数据处理装置100包括至少一个可以软件或固件(firmware)的形式存储于所述存储器12中的软件功能模块。所述处理器14用于执行所述存储器12中存储的可执行的计算机程序，例如，所述数据处理装置100所包括的软件功能模块及计算机程序等，以实现数据处理方法。

其中，所述存储器12可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

所述处理器14可能是一种集成电路芯片，具有信号的处理能力。上述的处理器14可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)、片上系统(System on Chip，SoC)等。

可以理解，图1所示的结构仅为示意，所述电子设备10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

结合图2，本申请实施例还提供一种可应用于上述电子设备10的数据处理方法。其中，所述数据处理方法有关的流程所定义的方法步骤可以由所述电子设备10实现，下面将对图2所示的具体流程进行详细阐述。

步骤S110，对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息。

在本申请实施例中，在获取所述待处理的至少一个请求报文之后，可以对所述待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息。

步骤S120，将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

在本申请实施例中，通过步骤S110得到所述至少一个请求消息之后，可以将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

通过以上方法，通过对请求报文进行分发处理和打包处理之后发送至Spark集群进行计算，得到对应的计算结果，以避免现有技术中通过Spark应用进行大数据计算的数据处理方式流程复杂，所导致的数据处理的效率低的问题。

需要说明的是，在现有技术中，为了解决在客户端子系统或者第三方系统中提交Spark应用的低耦合、无侵入性，利用消息队列采用异步的方式来提交应用请求。根据这种技术方案，需要将待调用的Spark应用任务ID和执行参数等信息先保存到参数数据库中，当客户端子系统或者第三方系统需要执行某个Spark应用调用任务时，根据任务的ID从参数数据库中获取Spark应用的执行参数，然后将任务ID和参数等信息封装成请求对象并发送到消息队列中，同时会有个执行线程监控消息队列的状态，如果有请求对象存在，则取出后根据请求对象数据动态生成执行脚本文件保存到指定的目录中，脚本执行程序会扫描目录中所有未执行过的脚本文件，读取脚本文件内容，打包需要提交的执行程序，并提交给Spark集群去执行，集群执行成功后，将结果数据保存到结果存储系统中，并调用结果服务回调接口，通知客户端子系统或者第三方系统更改任务的执行状态，客户端子系统或者第三方系统监测到任务的状态为成功后，会通过结果服务去获取结果数据，并以指定的形式展现给用户。

首先，上述的技术方案虽然利用消息队列的方式解决了客户端子系统或者第三方系统与提交Spark应用程序解耦分离的问题，但是整个架构过于复杂，需要通过多个服务串联起来实现。如果其中某一环出现问题，会导致整个流程的失败，而且每个环节环环相扣，无法实现某个环节的水平伸缩，降低了系统的健壮性和可扩展性。其次，上述的技术方案中Spark应用的提交从本质上看还是采用脚本的方式来实现，这种方式在每次执行任务时都需要启动和初始化Spark集群，然后执行任务。对于大量数据的批处理请求，由于处理时间远远大于启动和初始化集群的时间，则这部分的消耗可以忽略不计，但是如果执行的任务实际处理时间很短，则会凸显出这部分的消耗，极大地降低了执行的效率。然后，该方案中结果获取部分仍然采用的是通过接口回调异步通知的方式，如果客户端子系统或者第三方系统需要同步获取数据，则需要通过轮询结果状态的方式来实现，这种方式时效性不高并且实现起来也较麻烦。

详细地，分布式计算是一种与单机集中式计算相对的计算方法，是为了解决集中式计算对于大数据量的处理需要耗费大量的时间才能完成，或者根本无法完成而产生的一种解决方案。它可以将大量的数据切分成若干切片，并交给多个任务去处理，这些任务会分配给多台计算机进行处理，可以充分利用多台计算机的软硬件资源，以提高计算效率。

需要说明的是，对于客户端子系统和服务器端子系统的请求响应方式来说，一个完整的系统内部的协调模式可以包括同步模式和异步模式。

其中，同步模式是指：客户端子系统与服务器端子系统建立连接后，客户端子系统发出请求并等待服务器端子系统的响应，在接收到客户端子系统的请求后，服务器端子系统可以在主线程内或者新启动一个线程去处理此客户端子系统的请求。当处理完成后，服务器端子系统可以将处理的结果或者状态信息通过原连接返回给客户端子系统，客户端子系统收到响应并处理完该响应后，才能继续执行接下来的业务逻辑。

异步模式是指：客户端子系统与服务器端子系统建立连接后，客户端子系统发出请求，客户端子系统主线程无需等待服务器端的响应，即可执行后面的业务逻辑。服务器端子系统接收到客户端子系统的请求后，可以在主线程内，也可以单独启动一个线程去执行该请求对应的业务逻辑。当执行完成后，服务器端子系统将结果或者状态信息，通过原有的连接或者指定的连接返回给客户端子系统，客户端子系统在接收到该响应后，匹配响应对应的请求，并对响应做相应的处理。

需要说明的是，耦合是指元素、模块、系统之间的连接、依赖的程度。比如，A模块与B模块的耦合高，则代表二者缺一不可，一旦其中一个有问题，那么另一个也会受影响。从设计模式的角度来讲，这种依赖程度越小，则系统的设计越优秀，因此低耦合也是高质量软件设计标准之一。

轮询是指以指定的时间周期不断地检查待使用的服务、数据等资源是否已经准备好，是否可以正常访问。如果待检查的服务、数据资源能正常提供访问，则结束轮询，继续下一步流程，否则继续周期性地检查。

水平伸缩是指当对系统的请求流量增加时，可以通过增加服务器并在服务器上部署相同的应用而无需修改业务代码的方式来提高系统吞吐量，在系统的请求流量恢复正常后，可以在无差别地不影响业务执行的情况下减少服务器来避免资源的浪费。

其中，吞吐量一般指单位时间内成功传输(处理)的数据量，描述的单位可以是每秒多少字节，每秒多少兆等。它往往用来衡量一个系统的处理性能，若吞吐量指标高，则说明系统的处理性能强，反之则说明系统的处理性能弱。影响吞吐量的因素可以有存储设备读取和写入的速度，CPU的时钟频率(即CPU的性能)，系统的结构等。

在步骤S110之前，所述数据处理方法还包括以下子步骤：

获取待处理的至少一个请求报文。

详细地，所述请求报文可以由客户端设备发送。其中，所述客户端设备上设置有客户端子系统。所述客户端子系统与服务器端子系统相对应，构成客户/服务器(Client/Server，C/S)系统结构。所述客户端子系统可以泛指为用户提供的应用程序子系统，安装在用户使用的机器设备上，需要和所述服务器端子系统配合使用，从而为用户提供服务功能，主要的表现形式可以包括提供给用户使用的人机操作界面程序。

对于步骤S110，需要说明的是，所述对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，结合图3，步骤S110可以包括步骤S111和步骤S112。

步骤S111，通过负载均衡进程对待处理的至少一个请求报文进行分发处理。

步骤S112，通过至少一个请求消息前置进程对分发处理后的各请求报文统一进行打包处理，得到至少一个请求消息。

对于步骤S111，需要说明的是，负载均衡进程是指在多个节点上安装(部署)的相同的服务器端子系统可以通过预设的负载均衡算法将客户端子系统的请求报文分发到不同节点的服务器端子系统去处理，从而分担单台服务器的处理压力，提高系统吞吐量，增加数据处理能力。

可选地，所述预设的负载均衡算法的具体种类不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，所述负载均衡算法可以是轮询算法。也就是说，可以通过轮询算法对待处理的至少一个请求报文进行分发处理。

又例如，在另一种可以替代的示例中，所述负载均衡算法可以是随机算法。也就是说，可以通过随机算法对待处理的至少一个请求报文进行分发处理。

又例如，在另一种可以替代的示例中，所述负载均衡算法可以是最小连接算法。也就是说，可以通过最小连接算法对待处理的至少一个请求报文进行分发处理。

详细地，本申请实施例提供的技术方案通过负载均衡进程在有大量的客户端子系统发送请求时，实现负载均衡，缓解由于单台服务器所造成的系统性能问题，来实现服务器大数据端平滑的水平伸缩，提高了系统的可扩展性，从而既可以应对客户端子系统的流量洪峰，又可以合理利用资源。

对于步骤S112，需要说明的是，所述请求消息前置进程的主要功能就是接收和解析所述负载均衡进程分发的请求报文，按照统一的消息格式对请求报文进行打包，得到对应的请求消息所述请求消息前置进程可以通过springboot微服务方式来实现，可以轻松方便地部署多个，应对所述负载均衡进程分发过来的多个请求报文。

可选地，所述通过至少一个请求消息前置进程对分发处理后的各请求报文统一进行打包处理，得到至少一个请求消息的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，步骤S112可以包括以下的子步骤：

对各请求报文进行JSON打包处理，得到属于JSON文件格式的至少一个请求消息。

详细地，请求消息前置进程为了让后面的Spark客户端可以无差别部署，需要统一请求报文格式。因此，所述请求消息前置进程需要解析http格式的请求报文，并按照系统约定的统一格式对请求报文进行打包。考虑到消息的可读性以及消息尽可能小，可以采用JSON的格式来定义，以通过请求消息的ID对每个请求消息进行区分。如果需要对请求消息的字段进行修改，并兼容以前的请求消息格式，可以对请求消息加上版本字段以兼容旧格式版本，请求消息的参数名和参数值分别用key和value来区分，不同的业务可以通过业务类型字段来标识。例如，请求消息可以包括{“requestId”:”r0001”,”version”:”v1”,”businessType”:”b01”,”params”:[{“key”:”key1”,”value”:”value1”},{“key”:”key2”,”value”:”value2”}]……}。

上述方法的目的是为了增加系统的可扩展性，首先，从部署的可扩展性来考虑，如果遇到请求的洪峰，则可以通过在不同的服务器上部署相同的应用来应对大流量的请求。当流量降下去后，又可以很容易地减少后端服务器的数量，可以使多余的服务器为其它业务服务，从而平滑地实现了水平可伸缩性。其次，从业务处理的可扩展性来考虑，由于系统所面临的客户端业务多种多样，必然会带来业务请求格式的多样性。如何能让大数据端无差别地处理这些业务参数、约束等，解析成对应的业务对象，并提交给集群处理，不是一件容易的事情。本方案采用的技术方案是通过消息前置进程来为大数据端屏蔽业务的复杂性，抽象出各种业务请求的共性和差异性，组装成系统统一的请求消息格式并发往大数据端，请求消息格式的定义既考虑了可读性、可扩展性也考虑了兼容性。

对于步骤S120，需要说明的是，所述将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，步骤S120可以包括以下的子步骤：

通过包括至少一个redis频道的redis进程将各请求消息发送至对应的各Spark应用进程，并通过各Spark应用进程将所述各请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

需要说明的是，为了向Spark集群提交请求，并同步获取响应消息，本方案采用借助redis频道的方式来实现。请求消息前置进程需要将请求消息发布到订阅的请求频道上，并等待接收响应频道上的响应消息，每个Spark客户端节点也通过订阅redis进程上的请求频道来接收请求消息，并组装成业务对象通过常驻的SparkSession提交给Spark集群去计算，计算结果通过collectAPI收集到Spark客户端节点上的Spark driver后发布到redis响应频道，最终会返回给客户端子系统。

其中，之所以采用redis频道来构建服务请求和响应的桥梁，主要是考虑到redis是基于内存的key-value存储系统，因此在发送请求和接收响应时性能非常高，远远高于普通的http请求和响应的速度。其次，系统在发送http请求时需要按照http报文请求格式组装请求消息，请求消息体略显庞大，如果遇到请求和响应数据较多时性能不是很理想。通过redis发布订阅频道的方式来传输请求和响应消息，可以自定义报文，一方面更灵活，可以根据具体的需求修改报文格式，尽可能减少传输报文大小，并且可以接收更大量的请求响应数据；另一方面借助redis集群的特点，可以通过部署多个redis频道来应对请求的洪峰，可扩展性得到了更大的提高。并且redis集群可以单独部署，不用内嵌到Spark客户端中，一方面可以减轻Spark客户端的负载，另一方面可以和别的应用共用redis集群，极大地节约了服务器资源。

进一步地，所述Spark集群的具体结构不受限制，可以根据实际实际应用需求进行设置。

例如，在一种可以替代的示例中，所述Spark集群设置有SparkSession进程，步骤S120可以包括以下子步骤：

首先，通过所述SparkSession进程控制所述Spark集群启动并初始化。其次，将所述至少一个请求消息发送至初始化后的Spark集群进行计算，得到各请求消息对应的各计算结果。

需要说明的是，为了解决如何向Spark集群提交任务的问题，本申请实施例提供的技术方案是采用常驻SparkSession的方式。在通过脚本启动Spark应用时，会初始化Spark环境，构建SparkSession对象。当Spark客户端监听到redis请求频道上有请求消息发布时，则会接收请求消息并解析，生成对应的业务逻辑，以SparkRDD或者SparkSQL的方式提交到Spark集群去处理。并且SparkSession进程在执行完此任务后，并不会退出，从而实现了多任务提交的复用，既节约了系统资源，又提高了系统执行的效率，避免了通过脚本方式提交任务时每次都需要重新启动和初始化Spark集群的开销。

进一步地，在所述Spark集群计算得到各计算结果之后，所述数据处理方法还可以包括以下子步骤：

首先，通过至少一个Spark应用进程对所述各计算结果打包成对应的各响应消息。其次，通过至少一个请求消息前置进程对各响应消息进行转换处理，得到对应的各响应报文并发送至客户端设备。

需要说明的是，Spark客户端进程的主要功能是订阅发布redis频道，用来接收统一格式的请求消息，并将所述请求消息提交Spark集群。在Spark集群对请求消息进行计算得到计算结果之后，所述Spark客户端进程可以将计算结果打包成自定义的响应消息，并发送到对应的redis频道。

也就是说，在客户端子系统发送至少一个请求报文之后，可以通过负载均衡进程对待处理的至少一个请求报文进行分发，将所述至少一个请求报文分发至对应的请求消息前置进程。所述请求消息前置进程在接收所述至少一个请求报文之后，可以分别对所述至少一个请求报文进行打包处理，得到统一格式的至少一个请求消息，并将所述至少一个请求消息发送至redis进程上对应的redis频道。所述redis进程在接收所述至少一个请求消息之后，可以分别将所述至少一个请求消息传输至对应的Spark应用进程。所述Spark应用进程可以与所述redis进程上对应的redis频道建立连接，以接收所述redis进程传输的请求消息，并将所述请求消息提交到所述Spark集群进行计算，得到各请求消息对应的各计算结果。

进一步地，在所述Spark集群对所述请求消息进行计算，得到各请求消息对应的各计算结果之后，所述Spark集群可以将所述各计算结果发送至对应的Spark应用进程进行处理。所述Spark应用进程在接收到所述各计算结果之后，可以将所述各计算结果进行打包处理，得到统一格式的至少一个响应消息，并将所述至少一个响应消息发送至所述redis进程上对应的redis频道。所述redis进程在接收所述至少一个响应消息之后，可以分别将所述至少一个响应消息传输至对应的请求消息前置进程。所述请求消息前置进程在接收到所述至少一个响应消息之后，可以将所述至少一个响应消息进行转换处理，得到对应的至少一个响应报文，并将所述至少一个响应报文发送至对应的客户端子系统。

结合图4，本发明实施例还提供了一种数据处理装置100，可以应用于上述的电子设备10。其中，该数据处理装置100可以包括请求报文处理模块110和请求消息计算模块120。

所述请求报文处理模块110，用于对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息。在本实施例中，所述请求报文处理模块110可以用于执行图2所示的步骤S110，关于所述请求报文处理模块110的相关内容可以参照前文对步骤S110的具体描述。

所述请求消息计算模块120，用于将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。在本实施例中，所述请求消息计算模块120可以用于执行图2所示的步骤S120，关于所述请求消息计算模块120的相关内容可以参照前文对步骤S120的具体描述。

在本申请实施例中，对应于上述的数据处理方法，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序运行时执行上述数据处理方法的各个步骤。

其中，前述计算机程序运行时执行的各步骤，在此不再一一赘述，可参考前文对所述数据处理方法的解释说明。

综上所述，本申请实施例提供的数据处理方法和装置、电子设备及计算机可读存储介质，通过对请求报文进行分发处理和打包处理之后发送至Spark集群进行计算，得到对应的计算结果，以避免现有技术中通过Spark应用进行大数据计算的数据处理方式流程复杂，所导致的数据处理的效率低的问题。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息；

将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

2.如权利要求1所述的数据处理方法，其特征在于，所述对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息的步骤，包括：

通过负载均衡进程对待处理的至少一个请求报文进行分发处理；

通过至少一个请求消息前置进程对分发处理后的各请求报文统一进行打包处理，得到至少一个请求消息。

3.如权利要求2所述的数据处理方法，其特征在于，所述通过至少一个请求消息前置进程对分发处理后的各请求报文统一进行打包处理，得到至少一个请求消息的步骤，包括：

对各请求报文进行JSON打包处理，得到属于JSON文件格式的至少一个请求消息。

4.如权利要求1所述的数据处理方法，其特征在于，所述将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果的步骤，包括：

通过包括至少一个redis频道的redis进程将各请求消息发送至对应的各Spark应用进程，并通过各Spark应用进程将所述各请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

5.如权利要求1所述的数据处理方法，其特征在于，所述Spark集群设置有SparkSession进程，所述将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果的步骤，包括：

通过所述SparkSession进程控制所述Spark集群启动并初始化；

将所述至少一个请求消息发送至初始化后的Spark集群进行计算，得到各请求消息对应的各计算结果。

6.如权利要求1所述的数据处理方法，其特征在于，所述数据处理方法还包括：

通过至少一个Spark应用进程对所述各计算结果打包成对应的各响应消息；

通过至少一个请求消息前置进程对各响应消息进行转换处理，得到对应的各响应报文并发送至客户端设备。

7.如权利要求6所述的数据处理方法，其特征在于，所述通过至少一个请求消息前置进程对各响应消息进行转换处理，得到对应的各响应报文并发送至客户端设备的步骤，包括：

通过至少一个请求消息前置进程将各响应消息转换成各客户端设备对应的http响应报文，并通过负载均衡进程将各http响应报文分发至对应的所述客户端设备。

8.一种数据处理装置，其特征在于，包括：

请求报文处理模块，用于对待处理的至少一个请求报文进行分发处理和打包处理，得到至少一个请求消息；

请求消息计算模块，用于将所述至少一个请求消息发送至Spark集群进行计算，得到各请求消息对应的各计算结果。

9.一种电子设备，其特征在于，包括存储器和处理器，所述处理器用于执行所述存储器中存储的可执行的计算机程序，以实现权利要求1-7任意一项所述的数据处理方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，该程序被执行时实现权利要求1-7任意一项所述数据处理方法的步骤。

Images