CN115580619B - 数据处理系统和数据处理方法 - Google Patents

Abstract

本申请实施例提供了一种数据处理系统和数据处理方法，该数据处理系统包括数据采集服务和数据处理服务，数据采集服务与至少一个边缘设备连接。其中，边缘设备用于采集监控环境中的数据，得到多条原始数据；数据采集服务用于从边缘设备中获取多条原始数据，并将多条原始数据发送给数据处理服务；数据处理服务用于处理数据采集服务发送的多条原始数据。由此可见，本申请的数据处理系统在数据采集服务和数据处理服务之间，去除了传统的消息服务队列，节省了部署消息队列服务所需的运行资源和服务器资源。而且，数据采集服务和数据处理服务之间采用点对点的模式进行通信，降低了消息传输时延，提高了系统响应的实时性。

Description

数据处理系统和数据处理方法

技术领域

本申请涉及大数据技术领域，尤其涉及一种数据处理系统和数据处理方法。

背景技术

随着信息化建设的发展，大规模低延迟物联网数据的采集、存储、计算和管理成为信息数字化的核心。

相关技术中，在大规模低延迟物联网数据采集场景中，通常采用具备分组订阅能力的消息队列（Message queue，MQ）服务在数据采集服务和数据处理服务之间进行数据中转，以实现数据处理过程中数据处理服务中各处理服务处理数据量的负载均衡。

由于所有待处理数据均需要通过消息队列服务进行转发，因此，需要为消息队列服务部署对应的运行资源。然而，为了保证数据采集服务、消息队列服务和数据处理服务之间相互独立，需要为消息队列服务规划独立的服务器资源，导致系统整体运行资源消耗过大。

发明内容

本申请提供了一种数据处理系统和数据处理方法，在数据管理系统中去除了消息队列服务，使得数据采集服务和数据处理服务可以进行点对点通信。技术方案如下：

第一方面，本申请提供了一种数据处理系统，该数据处理系统包括：数据采集服务和数据处理服务，数据采集服务与至少一个边缘设备连接；

边缘设备，用于采集监控环境中的数据，得到多条原始数据；

数据采集服务，用于从边缘设备中获取多条原始数据，并将多条原始数据发送给数据处理服务；

数据处理服务，用于处理数据采集服务发送的多条原始数据。

在一种可能的实现方式中，数据采集服务部署在至少一个第一虚拟节点上，数据采集服务包括转发路由器和多个采集参与者；且每个第一虚拟节点上部署至少一个采集参与者；

各采集参与者，用于获取边缘设备采集的多条原始数据，并将多条原始数据发送给转发路由器；

转发路由器，用于将多条原始数据发送给数据处理服务。

在一种可能的实现方式中，数据处理服务部署在至少一个第二虚拟节点上，数据采集服务包括多个处理参与者；且每个第二虚拟节点上部署至少一个处理参与者；

各处理参与者，用于按照预设的数据处理逻辑，对应处理转发路由器发送的原始数据。

在一种可能的实现方式中，数据采集服务通过预设的同步协议，在各第一虚拟节点之间同步节点信息；数据处理服务通过同步协议，在各第二虚拟节点之间同步节点信息；

其中，节点信息包括存活节点的节点标识，以及各存活节点的节点状态。

在一种可能的实现方式中，转发路由器还用于根据目标转发策略，将多条原始数据分发给至少一个处理参与者；

其中，目标转发策略包括轮询策略、随机策略、负载均衡策略中的任一种。

在一种可能的实现方式中，转发路由器通过以下至少一种方式确定目标转发策略：

根据各第二虚拟节点的节点运行资源，和/或，各处理参与者的数据处理资源，确定目标转发策略；

根据各原始数据分别对应的数据包信息，确定数据处理服务中的数据处理量波动信息；并根据数据处理量波动信息，确定目标转发策略。

在一种可能的实现方式中，若各第二虚拟节点的节点运行资源处于预设的节点资源波动范围内，则转发路由器确定目标转发策略为轮询策略或随机策略；若各处理参与者的数据处理资源处于预设的处理资源波动范围内，则转发路由器确定目标转发策略为轮询策略或随机策略；若各第二虚拟节点的节点运行资源未处于节点资源波动范围内，和/或，若各处理参与者的数据处理资源未处于处理资源波动范围内，则转发路由器确定目标转发策略为负载均衡策略。

在一种可能的实现方式中，若数据处理服务中的数据处理量波动信息处于预设的数据处理量范围内，则转发路由器确定目标转发策略为轮询策略或随机策略；若数据处理服务中的数据处理量波动信息未处于数据处理量范围内，则转发路由器确定目标转发策略为负载均衡策略。

在一种可能的实现方式中，数据采集服务基于数据采集需求，调整第一虚拟节点的数量，以新增或减少数据处理系统中采集参与者的数目。

在一种可能的实现方式中，数据处理服务基于数据处理需求，调整第二虚拟节点的数量，以新增或减少数据处理系统中处理参与者的数目。

第二方面，本申请提供了一种数据处理方法，该方法应用于数据处理系统，数据处理系统包括数据采集服务和数据处理服务，数据采集服务与至少一个边缘设备连接；该方法包括：

数据采集服务从边缘设备中获取多条原始数据；边缘设备用于采集监控环境中的数据，得到多条原始数据；

数据采集服务将多条原始数据发送给数据处理服务；

数据处理服务处理数据采集服务发送的多条原始数据。

第三方面，本申请提供了一种电子设备，该电子设备包括存储器和处理器，存储器存储有计算机程序，处理器执行该计算机程序时实现上述第二方面中的数据处理方法的步骤。

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

第五方面，本申请提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序被处理器执行时实现上述第二方面中的数据处理方法的步骤。

本申请提供的技术方案至少可以达到以下有益效果：

数据处理系统包括数据采集服务和数据处理服务，数据采集服务与至少一个边缘设备连接。其中，边缘设备用于采集监控环境中的数据，得到多条原始数据；数据采集服务用于从边缘设备中获取多条原始数据，并将多条原始数据发送给数据处理服务；数据处理服务用于处理数据采集服务发送的多条原始数据。由此可见，本申请的数据处理系统在数据采集服务和数据处理服务之间，去除了传统的消息服务队列，节省了部署消息队列服务所需的运行资源和服务器资源。而且，数据采集服务和数据处理服务之间采用点对点的模式进行通信，降低了消息传输时延，提高了系统响应的实时性。

附图说明

图1是本申请一示例性实施例示出的一种传统数据处理系统的架构图；

图2是本申请一示例性实施例示出的一种数据处理系统的系统架构图；

图3是本申请一示例性实施例示出的一种Actor通信模式示意图；

图4是本申请一示例性实施例示出的另一种数据处理系统的系统架构图；

图5是本申请一示例性实施例示出的一种Actor路由调度机制示意图；

图6是本申请一示例性实施例示出的一种数据处理方法的流程示意图；

图7是本申请一示例性实施例示出的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案及优点更加清楚明白，下面将结合附图及实施例，对本申请的技术方案做进一步详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

目前大规模低延迟物联网数据采集场景，主要采用消息队列服务在数据采集服务和数据处理服务之间进行数据中转，以实现数据处理过程中的负载均衡。

具体地，参见图1所示的系统架构图，在该数据处理系统100中，数据采集服务120从边缘设备110中获取原始数据，并对原始数据进行序列化处理，将处理后的序列化数据通过预设的发送通道1和发送通道2发送给消息队列服务130。进一步地，消息队列服务130通过处理服务1的订阅通道1，将分配的第一序列化数据发送给数据处理服务140中部署的处理服务1；消息队列服务130通过处理服务2的订阅通道2，将分配的第二序列化数据发送给数据处理服务140中部署的处理服务2；消息队列服务130通过处理服务3的订阅通道3，将分配的第三序列化数据发送给数据处理服务140中部署的处理服务3。

进一步地，数据处理服务140中的各处理服务接收到消息队列发送的序列化数据后，先对其进行反序列化处理，得到需要处理的原始数据，然后按照处理服务中预设的数据处理逻辑，对原始数据进行处理。

然而，上述通过消息队列服务实现数据处理服务中各处理服务之间的负载均衡时，可能存在以下至少一个问题：

（1）需要额外部署运行消息队列服务的服务器资源；

由于所有采集的原始数据都需要经过消息队列服务进行转发，因此，整体系统运行资源需要增加消息队列服务的运行资源。而且，为了保证各服务间相互独立，需要为消息队列服务独立规划对应的服务器资源。

（2）系统稳定性依赖于消息队列服务的稳定性；

由于所有采集的原始数据都需要经过消息队列服务进行转发，若消息队列服务运行异常，则会导致数据转发中断。而数据处理服务未接收到有效数据的情况下，会导致数据处理过程中断，数据处理系统整体处于不可用状态。

（3）消息到达数据处理服务的时延较高；

由于所有采集的原始数据都需要经过消息队列服务从数据采集服务转发到数据处理服务，且数据采集服务、消息队列服务和数据处理服务独立部署，因此，所有采集的原始数据需要进行序列化－发送－转发－接收－反序列化的处理。如此，不考虑数据包大小和网络波动情况下，较点对点通讯而言，通过消息队列服务进行数据转发需要额外增加数据传输时延。

（4）系统并发速度依赖于消息队列服务的转发速度和转发时延；

由于所有采集的原始数据都需要经过消息队列服务进行转发，消息队列服务转发原始数据的转发速度和转发时延无法匹配数据转发要求时，导致采集的海量数据无法按照数据转发要求顺利发送给数据处理服务，将会成为数据处理系统的性能瓶颈。

针对上述至少一个技术缺陷，本申请提供了一种数据处理系统和数据处理方法，在数据处理系统中去除了传统的消息队列服务，以减少整个数据处理系统对外部系统组件的依赖，减少了系统复杂度，同时减少系统运行所需的资源。而且，数据采集服务和数据处理服务进行点对点通讯，还可以减少消息传输时延，提高系统响应的实时性。

在一个示例性实施例中，如图2所示，本申请实施例提供了一种数据处理系统，该数据处理系统200包括：数据采集服务220和数据处理服务230，数据采集服务220与至少一个边缘设备210连接。

其中，边缘设备用于采集监控环境中的数据，得到多条原始数据；数据采集服务用于从边缘设备中获取多条原始数据，并将多条原始数据发送给数据处理服务；数据处理服务用于处理数据采集服务发送的多条原始数据。

在一种可能的实现方式中，数据采集服务与边缘设备之间预先建立有至少一个数据传输通道，数据采集服务可以通过预设的数据传输通道，实时或定时获取边缘设备采集的多条原始数据；或者，边缘设备可以通过预设的数据传输通道，实时或定时向数据采集服务上传自身采集的原始数据。

需要说明的是，本申请中的原始数据可以是边缘设备从监控环境中采集到的数据；也可以是边缘设备对所采集的数据进行预处理后得到的数据。本申请实施例对此不做限制。

其中，边缘设备可以执行的数据预处理可以包括但不限于为：数据筛选、数据去噪、数据去重、数据的简单计算、数据存储等等。

可选地，部署的边缘设备较多时，还可以设置至少一个边缘网关，边缘网关作为边缘设备与数据采集服务之间的中转设备，将各边缘设备采集的原始数据转发给数据采集服务。

同理，数据采集服务将多条原始数据发送给数据处理服务时，也可以通过预设的数据传输通道来实现，在此不再赘述。

进一步地，对于数据处理服务而言，其中预先设置有对应的数据处理逻辑，以使数据处理服务接收到数据采集服务发送的多条原始数据后，可以按照对应的数据处理逻辑，对原始数据进行处理，得到数据处理结果。

其中，在去除消息队列服务后，数据采集服务和数据处理服务器之间可以直接进行数据传输和通信，因此二者间的通信模式可称为点对点通信模式。

可选地，数据处理服务还可以与其他外部系统连接，以将数据处理结果存储至外部系统中，或者在外部系统中展示数据处理结果，便于用户了解各边缘设备所监控环境的环境情况，以及环境中所部署的设备的运行情况等。

作为一个示例，边缘设备可以是安装在边缘网络上的智能传感器、可编程逻辑控制器（Programmable Logic Controller，PLC）、边缘智能路由器、信息和通信技术融合（Informational Communications Technology，ICT）网关、分布式合规设备总帐（Distributed Compliance Ledger，DCL）等，本申请实施例对此不做限制。

其中，智能传感器可以用于实时或定期采集设备、环境和子系统的状态信息，对数据进行分类、分析和打包等，减少数据上传后计算和分析的时间和资源消耗，提高数据处理系统的数据处理效率。PLC本质上是一种具有编程、操作、控制和输出能力的智能计算机，它可以根据工业生产和工业应用的需要进行自适应集成；另外，PLC还可以在边缘端以低延迟和高效率管理和控制其他设备的运行。边缘智能路由器用于实现有线或4G/5G等全网通组网模式、高速路由、WiFi支持、本地存储、设备监控和前端设备控制的集成，具有丰富的行业接口和应用功能接口，支持对功能复杂的边缘设备的一站式接入，可以提高数据通信的集中化水平和效率。ICT网关具备先进的设备接入能力、数据采集能力、边缘计算能力、5G/4G/有线等综合通信传输能力，能够用于实现物联网系统中数据交互和多设备全过程的控制。DCL是一种基于区块链技术的，安全加密的分布式存储网络，其允许连接标准联盟（Connectivity Standards Alliance，CSA）和授权供应商发布的设备信息，同时，可以通过DCL 客户端在该分布式存储网络中查询相关信息。通过DCL可以实现全球不同品牌/类型的物联网设备之间的互联互通和跨平台兼容。

需要说明的是，本申请实施例和附图仅以PLC、DCL和智能仪表作为边缘设备进行举例说明，并不在于限制边缘设备只能为PLC、DCL和智能仪表。

在本申请实施例中，数据处理系统在数据采集服务和数据处理服务之间，去除了传统的消息服务队列，节省了部署消息队列服务所需的运行资源和服务器资源。而且，数据采集服务和数据处理服务之间采用点对点的模式进行通信，降低了消息传输时延，提高了系统响应的实时性。

基于上述实施例所示的数据处理系统，在大规模低延迟物联网数据采集过程中，本申请进一步采用分布式参与者（Actor）模型，对数据采集服务和数据处理服务的架构进行优化，以解决海量数据并发计算处理的问题。

其中，Actor模型是一个用于解决分布式计算的数学模型。Actor 能回应接收到的消息、能够自我决策、创建更多的 Actor、能够发送更多的消息，以及决定如何回应下一个接收到的消息。

在Actor模型中，各Actor彼此之间可以直接发送消息，无需经过中介转发，消息是异步发送和处理的。在Actor模型中一切都是Actor，所有逻辑或模块都可以看成Actor，通过不同Actor之间的消息传递实现模块之间的通信和交互。而且，各Actor是相互隔离的，不会共享内存，只能通过发邮件（message）进行交互。

作为一个示例，参见图3，Actor1、Actor2和Actor3之间可以发送邮件，邮件会存储在各Actor对应的邮箱中。Actor处理自身邮箱中接收的多封邮件时，是按照接收顺序依次处理的。

基于Actor模型的优势，本申请将数据采集服务和数据处理服务均通过分布式Actor集群的方式实现，即数据采集服务包括多个可以并行进行数据采集的采集参与者，以提高数据采集效率；数据处理服务包括多个可以并行进行数据计算处理的处理参与者，提高数据处理效率。

在一个示例性实施例中，如图4所示，数据采集服务部署在至少一个第一虚拟节点上，数据采集服务包括转发路由器和多个采集参与者，且每个第一虚拟节点上部署至少一个采集参与者。

其中，各采集参与者用于获取边缘设备采集的多条原始数据，并将多条原始数据发送给转发路由器；转发路由器用于将多条原始数据发送给数据处理服务。

继续参见图4，基于相同的技术构思，数据处理服务部署在至少一个第二虚拟节点上，数据采集服务包括多个处理参与者，且每个第二虚拟节点上部署至少一个处理参与者。其中，各处理参与者用于按照预设的数据处理逻辑，对应处理转发路由器发送的原始数据。

应该理解的是，图4中的数据采集服务中仅以两个采集参与者进行示意，数据处理服务仅以三个处理参与者进行示意，在实际部署时，其中可以包括更多或更少的参与者，本申请实施例对此不做限制。

需要说明的是，本申请的数据采集服务和数据处理服务均通过分布式集群的方式实现，该数据采集服务的Actor集群部署在至少一个第一虚拟节点上，数据处理服务的Actor集群部署在至少一个第二虚拟节点上。

作为一个示例，第一虚拟节点和第二虚拟节点可以为虚拟机，也可以为物理机，本申请实施例对此不做限制。

其中，一个虚拟节点上可以部署一个Actor，也可以部署多个Actor，取决于该Actor集群中每个Actor可用的数据处理资源，和/或，各虚拟节点的节点运行资源。

应该理解的是，节点运行资源可以包括该虚拟节点所在的虚拟机/物理机中的存储器资源、中央处理器（Central Processing Unit，CPU）资源等，本申请实施例对此不做限制。

具体地，数据采集服务的Actor集群包括一个Actor路由和多个采集Actor。具体实施时，由多个采集Actor并行地从边缘设备中获取原始数据，并将获取到的多条原始数据发送给Actor路由，由Actor路由将多条原始数据转发给数据处理服务中的多个处理参与者。

数据处理服务的Actor集群包括多个处理Actor，多个处理Actor可以并行处理数据。具体实施时，Actor路由对采集Actor获取到的多条原始数据进行分配，确定各原始数据对应的处理Actor，进而将多条原始数据分别转发给对应的处理Actor进行处理。

应该理解的是，针对多条原始数据，Actor路由转发给各处理Actor的原始数据量可以相同，也可以不同，本申请实施例对此不做限制。

需要说明的是，Actor路由在向处理Actor转发原始数据时，只针对目前处于存活状态的处理Actor进行转发，并非针对数据处理服务的Actor集群中的所有处理Actor。如此，Actor路由转发原始数据给处于存活状态的处理Actor后，可以保证该处理Actor对原始数据进行有效处理，从而提高数据处理效率。

进一步地，数据采集服务中的转发路由器向数据处理服务转发多条原始数据时，转发路由器根据目标转发策略，将多条原始数据分发给至少一个处理参与者。目标转发策略包括轮询策略、随机策略、负载均衡策略中的任一种。

其中，轮询策略是指：转发路由器将多条原始数据逐条发送数据处理服务中的多个处理参与者。

作为一个示例，若转发路由器需要转发的原始数据包括：数据a、数据b、数据c、数据d、数据e、数据f和数据g，且数据处理服务包括：处理Actor1、处理Actor2和处理Actor3。则转发路由器采用轮询策略进行原始数据分发的过程为：将数据a转发给处理Actor1，将数据b转发给处理Actor2，将数据c转发给处理Actor3；然后，继续将数据d转发给处理Actor1，将数据e转发给处理Actor2，将数据f转发给处理Actor3；最后，将数据g转发给处理Actor1。

经过轮询策略进行数据转发后，处理Actor1按顺序依次处理数据a、数据d和数据g；处理Actor2按顺序依次处理数据b和数据e；处理Actor3按顺序依次处理数据c和数据f。

上述随机策略是指：转发路由器基于随机算法，将多条原始数据随机分发给数据处理服务中的多个处理参与者。

作为一个示例，若转发路由器需要转发的原始数据包括：数据a、数据b、数据c、数据d、数据e、数据f和数据g，且数据处理服务包括：处理Actor1、处理Actor2和处理Actor3。则转发路由器采用随机策略进行原始数据分发的过程为：基于随机算法确定数据a、数据b、数据c和数据d由处理Actor1处理，确定数据e由处理Actor2处理，确定数据f和数据g由处理Actor3处理。基于该随机分配结果，转发路由器将数据a、数据b、数据c和数据d转发给处理Actor1，将数据e转发给处理Actor2，将数据f和数据g转发给处理Actor3。

同理，基于随机策略进行数据转发后，处理Actor1根据数据接收顺序，依次处理数据a、数据b、数据c和数据d；处理Actor2处理数据e；处理Actor3根据数据接收顺序，依次处理数据f和数据g。

需要说明的是，在上述两种方式中，若数据处理服务中处理参与者的数据处理能力不同，则多条原始数据的整体数据处理时长受限于数据处理能力最差的处理参与者，会导致数据处理的整体时长存在一定的延长。

基于此，本申请还可以基于负载均衡策略进行数据转发。其中，负载均衡策略是指：转发路由器根据各处理参与者的数据处理能力，将多条原始数据分发给数据处理服务中的多个处理参与者，以保证各处理参与者之间负载均衡。

其中，处理参与者的数据处理能力可以根据处理参与者自身可用的数据处理资源，和/或，该处理参与者所在的第二虚拟节点的节点运行资源确定。

作为一个示例，若转发路由器需要转发的原始数据包括：数据a、数据b、数据c、数据d、数据e、数据f和数据g，且各数据的数据包大小相等，同时数据处理服务包括：处理Actor1、处理Actor2和处理Actor3。则转发路由器采用负载均衡策略进行原始数据分发的过程为：基于各处理参与者自身的数据处理资源、待处理数据量、所在的第二虚拟节点的节点运行资源等，确定处理Actor1只能处理2条数据，处理Actor2可以处理5条数据，处理Actor3可以处理3条数据。则转发路由器将数据a和数据b转发给处理Actor1，将数据c、数据d、数据e、数据f和数据g转发给处理Actor2。

同理，基于负载均衡策略进行数据转发后，处理Actor1根据数据接收顺序，依次处理数据a和数据b；处理Actor2根据数据接收顺序，依次处理数据c、数据d、数据e、数据f和数据g。

应该理解的是，在基于负载均衡确定各处理参与者的数据处理能力，以确定其所能处理的数据量后，可以采用满负荷的分配方式进行分配，如上述示例的方式。也可以采用其他方式进行分配，比如，处理Actor1只能处理2条数据，为避免处理Actor1处于满负荷状态，在分配原始数据时，给处理Actor1分配1条原始数据即可；同理，为避免处理Actor2处于满负荷状态，给处理Actor2分配4条原始数据，然后将剩下的2条原始数据分配给处理Actor3。

需要说明的是，本申请实施例对于目标转发策略不做限制，可以是上述列举的任一方式 ，还可以是其他方式。而且，在采用任一转发策略进行数据转发时，还可以对转发方式进行实时调整，本申请实施例并不限制转发操作的具体实施方式和执行顺序。

在本申请的一些实施例中，参见图5所示的Actor路由调度机制示意图，在Actor集群的某个虚拟节点中，部署在该虚拟节点上的各Actor之间可以采用Pool路由进行数据传输。

基于上述所示的三种转发策略，转发路由器确定目标转发策略的实现方式，包括但不限于以下两种：

在一种可能的实现方式中，转发路由器确定目标转发策略的实现过程可以为：根据各第二虚拟节点的节点运行资源，和/或，各处理参与者的数据处理资源，确定目标转发策略。

其中，节点运行资源包括但不限于该第二虚拟节点所在的虚拟机/物理机中的存储器资源、CPU资源等；处理参与者的数据处理资源可以包括但不限于可用计算资源、可用存储资源、待处理数据量等。本申请实施例对此不做限制。

作为一个示例，若各第二虚拟节点的节点运行资源处于预设的节点资源波动范围内，则转发路由器确定目标转发策略为轮询策略或随机策略；若各处理参与者的数据处理资源处于预设的处理资源波动范围内，则转发路由器确定目标转发策略为轮询策略或随机策略；若各第二虚拟节点的节点运行资源未处于节点资源波动范围内，和/或，若各处理参与者的数据处理资源未处于处理资源波动范围内，则转发路由器确定目标转发策略为负载均衡策略。

其中，节点资源波动范围和处理资源波动范围是预先设置的数值范围，其具体数值可以基于人为经验值，以及集群中处理参与者的部署情况等确定，本申请实施例对此不做限制。

换言之，在资源充足的情况下，转发路由器可以采用轮询策略和随机策略中的任一种方式进行数据转发；在资源不充足的情况下，转发路由器采用负载均衡策略进行数据转发，保证多条原始数据可以被处理参与者及时有效地处理。

可选地，由于随机策略无需逐一分发数据，数据分发效率更高。因此，在资源充足的情况下，转发路由器优先采用随机策略进行数据转发。

在另一种可能的实现方式中，转发路由器确定目标转发策略的实现过程可以为：根据各原始数据分别对应的数据包信息，确定数据处理服务中的数据处理量波动信息；并根据数据处理量波动信息，确定目标转发策略。

其中，数据包信息包括原始数据的数据包大小，和/或，原始数据对应的数据计算量。

同理，数据处理量波动信息是预先设置的数值范围，其具体数值可以基于人为经验值，以及数据处理服务中各处理参与者的数据处理能力等确定，本申请实施例对此不做限制。

作为一个示例，若数据处理服务中的数据处理量波动信息处于预设的数据处理量范围内，则转发路由器确定目标转发策略为轮询策略或随机策略；若数据处理服务中的数据处理量波动信息未处于数据处理量范围内，则转发路由器确定目标转发策略为负载均衡策略。

也即是，在数据处理量波动信息处于预设的数据处理量范围内时，表征各条原始数据的数据包大小一致，多条原始数据的数据处理量处于数据处理服务的正常作业范围内，数据处理服务可以对多条原始数据进行正常处理。

而在数据处理量波动信息未处于预设的数据处理量范围内时，表征各条原始数据的数据包大小不同，且偏差较大；由于各处理参与者当前可用的数据处理资源可能不同，若采用轮询策略或随机策略进行数据转发时，可能存在有些处理参与者无法处理原始数据的情况。因此，采用负载均衡策略进行数据转发，由转发路由器根据各原始数据的数据包信息，以及各处理参与者的数据处理能力，将多条原始数据进行转发，以保证各处理参与者可以正常处理分发的原始数据。

此外，在采用分布式参与者（Actor）模型实现数据采集服务和数据处理服务时，为保证数据采集服务的Actor集群，以及处理服务的Actor集群内，各节点的状态一致性，数据采集服务可以通过预设的同步协议，在各第一虚拟节点之间同步节点信息；同理，数据处理服务通过同步协议，在各第二虚拟节点之间同步节点信息。

其中，节点信息包括存活节点的节点标识，以及各存活节点的节点状态。

在其中一些实施例中，节点状态包括下述5种状态：joining状态、up状态、leaving/exiting状态、down状态和removed状态。其中，joining状态用于描述虚拟节点尝试加入Actor集群时的初始状态，up状态用于描述虚拟节点加入Actor集群后的正常运行状态，leaving/exiting状态用于描述虚拟节点退出Actor集群时所处的中间状态，当Actor集群无法感知到某一个虚拟节点后，将其标记为down状态，removed 状态表示该虚拟节点已从Actor集群中删除，以后也无法再加入该Actor集群。

作为一个示例，这里的“虚拟节点”可以具体为数据采集服务的Actor集群中的任一虚拟运行容器，或者，数据处理服务的Actor集群中的任一虚拟运行容器，即“虚拟节点”就是Actor集群的虚拟运行容器。

在一种可能的实现方式中，同步协议可以为Gossip 协议，该协议也称为流行病协议（epidemic protocol）。

其中，在Gossip 协议中，同步过程是由种子节点发起，当一个种子节点有状态需要更新到网络中的其他节点时，它会随机地选择周围几个节点散播消息。收到消息的节点会重复该过程，继续选择周围的几个几点散播消息，以此类推，直至集群中所有的节点都收到节点状态一致的消息。虽然消息散播过程需要一定的时间，不能保证某个时刻所有节点都收到消息，但最终所有节点都会收到消息。因此，Gossip 协议是一个最终一致性协议。

如此，在本申请的数据采集服务和数据处理服务对应的Actor 集群内，采用Gossip协议进行节点信息同步，Gossip 协议下的消息同步过程极其简单，实现较容易。而且，基于Gossip 协议天然的分布式系统容错特性，任何节点的宕机和重启都不会影响Gossip 消息的传播。同时，由于Gossip协议不要求任何中心节点，所有节点都是对等的，因此，在网络连通的情况下，任意一个节点都可以把节点信息散播到全网。由于Gossip协议中的消息会以一传十、十传百一样的指数级速度在网络中快速传播，因此，系统状态的不一致可以在很快的时间内收敛到一致，消息传播速度达到了 logN。

进一步地，基于上述同步协议，本申请中的数据处理系统还可以随时调整系统中采集参与者和/或处理参与者的数目

在一种可能的实现方式中，数据采集服务可以基于数据采集需求，调整第一虚拟节点的数量，以新增或减少数据处理系统中采集参与者的数目。同理，数据处理服务也可以基于数据处理需求，调整第二虚拟节点的数量，以新增或减少数据处理系统中处理参与者的数目。

也即是，在引入同步协议的情况下，可以增加或减少数据处理系统中虚拟节点的数量，该调整过程不会影响其他虚拟节点中Actor的正常运行；而且，新增节点的状态最终会与其他节点的状态一致。

具体地，以数据采集服务为例，当数据采集服务的Actor集群中资源饱和时，若需要新增采集参与者，则先需要增加底层的虚拟机或物理机数目，以通过增加第一虚拟节点的数目来扩充集群资源。在此基础上，在扩充的集群资源中部署需要新增的采集参与者。

在本申请实施例中，数据采集服务包括转发路由器和多个采集参与者，数据处理服务包括多个处理参与者。采集参与者负责对下数据采集，并将采集的多条原始数据发送至转发路由器；转发路由器采用轮询策略、随机策略和负载均衡策略等数据转发策略，将多条原始数据转发给数据处理服务中的多个处理参与者，处理参与者接收原始数据后按照数据处理逻辑进行数据处理。如此，本申请采用分布式Actor模型设计的数据处理系统，系统扩展性更好，可以随时增加/减少系统中的采集参与者和处理参与者，增强了系统扩展性。而且，采用Actor路由器模型，具备更丰富的消息调度策略，可以针对不同的数据采集场景，采用更合适的数据转发策略，以提高整个系统的数据处理效率。

在一个示例性实施例中，基于相同的技术构思，如图6所示，本申请还提供了一种数据处理方法。该方法应用于上述任一实施例所示的数据处理系统，该数据处理系统包括数据采集服务和数据处理服务，数据采集服务与至少一个边缘设备连接。该方法包括以下步骤：

步骤610：数据采集服务从边缘设备中获取多条原始数据。

其中，边缘设备用于采集监控环境中的数据，得到多条原始数据。

可选地，数据采集服务可以采用多个采集参与者，并行地从边缘设备中获取原始数据。

步骤620：数据采集服务将多条原始数据发送给数据处理服务。

在一种可能的实现方式中，数据采集服务包括多个采集参与者和转发路由器，采集参与者从边缘设备中获取原始数据后，将多条原始数据发送给转发路由器；由转发路由器将多条原始数据转发给数据处理服务。

进一步地，转发路由器可以采用轮询策略、随机策略、负载均衡策略等任一种转发策略将多条原始数据分发给数据处理服务中的多个处理参与者。

步骤630：数据处理服务处理数据采集服务发送的多条原始数据。

在一种可能的实现方式中，数据处理服务包括多个处理参与者，各处理参与者中预先存储有数据处理逻辑。因此，各数据处理者接收到转发路由器发送的原始数据后，按照预设的数据处理逻辑，并行处理接收到的原始数据。

上述实施例提供的数据处理方法的实现原理和有益效果，可以参见上文中关于数据处理系统的具体限定和详细解释，在此不再赘述。

在一个示例性实施例中，本申请实施例还提供了一种电子设备。该电子设备可以为数据处理系统中数据采集服务中的节点设备，也可以为数据处理服务中的节点设备，以用于实现本申请实施例提供的数据处理方法。如图7所示，该电子设备包括一个或多个处理器710、存储器720、系统总线730和通信接口740，且处理器710、存储器720和通信接口740通过系统总线730连接。

其中，处理器可以是中央处理单元（Central Processing Units，CPU）或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备中的其他组件以执行期望的功能。

可选地，处理器中装置有具备数据分析、数据处理、信息汇总等相关的应用软件。

存储器可以包括一个或多个计算机程序产品，该计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。其中，易失性存储器例如可以包括随机存取存储器（Random Access Memory，RAM）和/或高速缓冲存储器（cache）等。作为一个示例，该非易失性存储器可以包括只读存储器（Read-Only Memory，ROM）、硬盘、闪存等。在该计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器可以运行程序指令，以实现上文示出的各实施例中的数据处理方法和/或其他期望的功能。

该电子设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC（近场通信）或其他技术实现。

在一些实施例中，电子设备还可以包括：输入装置和输出装置（图7中未示出），这些组件通过总线系统和/或其他形式的连接机构（图7中未示出）互连。该输入装置可以是显示屏上覆盖的触摸层，也可以是电子设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。该输出装置可以向外部输出各种信息。例如，显示器/显示屏、扬声器、以及通信网络及其所连接的远程输出设备等。

当然，为了简化，图7中仅示出了该电子设备中与本申请实施例有关的组件中的一些，除此之外，根据具体应用情况，电子设备还可以包括任何其他适当的组件。

在一个示例性实施例中，本申请还提供了一种计算机可读存储介质。其中，该计算机可读存储介质可存储有计算机程序，该计算机程序被电子设备中的处理器调用并运行时，可实现本申请提供的数据处理方法中的部分或全部步骤。

作为一个示例，该计算机可读存储介质可以为磁碟、光盘、只读存储记忆体或随机存储记忆体等。

应该理解的时，本申请实施例中的技术方案可借助软件加必需的通用硬件平台的方式来实现。因此，本申请实施例中的技术方案本质上或者对现有技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品可以存储在计算机可读存储介质中。

在一个示例性实施例中，本申请还提供了一种计算机程序产品。其中，该计算机程序产品包括计算机程序，该计算机程序被电子设备中的处理器调用并运行时，可实现本申请提供的数据处理方法中的部分或全部步骤。

以上仅为本申请实施例的具体实施方式而已，并不用于限定本申请实施例的保护范围，凡在本申请实施例的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请实施例的保护范围之内。

Claims (10)

1.一种数据处理系统，其特征在于，包括：数据采集服务和数据处理服务，所述数据采集服务和所述数据处理服务均为分布式的参与者集群，所述数据采集服务与至少一个边缘设备连接；

所述边缘设备，用于采集监控环境中的数据，得到多条原始数据；

所述数据采集服务包括转发路由器和多个采集参与者；各所述采集参与者用于获取所述边缘设备采集的所述多条原始数据，并将所述多条原始数据发送给所述转发路由器；所述转发路由器，用于将所述多条原始数据发送给所述数据处理服务；

所述数据处理服务包括多个处理参与者，各所述处理参与者用于按照预设的数据处理逻辑，对应处理所述转发路由器发送的原始数据。

2.根据权利要求1所述的系统，其特征在于，所述数据采集服务部署在至少一个第一虚拟节点上，且每个所述第一虚拟节点上部署至少一个所述采集参与者；所述数据处理服务部署在至少一个第二虚拟节点上，且每个所述第二虚拟节点上部署至少一个所述处理参与者。

3.根据权利要求2所述的系统，其特征在于，所述数据采集服务通过预设的同步协议，在各所述第一虚拟节点之间同步节点信息；所述数据处理服务通过所述同步协议，在各所述第二虚拟节点之间同步节点信息；

其中，所述节点信息包括存活节点的节点标识，以及各所述存活节点的节点状态。

4.根据权利要求2所述的系统，其特征在于，所述转发路由器用于根据目标转发策略，将所述多条原始数据分发给至少一个所述处理参与者；

其中，所述目标转发策略包括轮询策略、随机策略、负载均衡策略中的任一种。

5.根据权利要求4所述的系统，其特征在于，所述转发路由器通过以下至少一种方式确定所述目标转发策略：

根据各所述第二虚拟节点的节点运行资源，和/或，各所述处理参与者的数据处理资源，确定所述目标转发策略；

根据各所述原始数据分别对应的数据包信息，确定所述数据处理服务中的数据处理量波动信息；并根据所述数据处理量波动信息，确定所述目标转发策略。

6.根据权利要求5所述的系统，其特征在于，

若各所述第二虚拟节点的节点运行资源处于预设的节点资源波动范围内，则所述转发路由器确定所述目标转发策略为轮询策略或随机策略；

若各所述处理参与者的数据处理资源处于预设的处理资源波动范围内，则所述转发路由器确定所述目标转发策略为轮询策略或随机策略；

若各所述第二虚拟节点的节点运行资源未处于所述节点资源波动范围内，和/或，若各所述处理参与者的数据处理资源未处于所述处理资源波动范围内，则所述转发路由器确定所述目标转发策略为负载均衡策略。

7.根据权利要求5所述的系统，其特征在于，

若所述数据处理服务中的数据处理量波动信息处于预设的数据处理量范围内，则所述转发路由器确定所述目标转发策略为轮询策略或随机策略；

若所述数据处理服务中的数据处理量波动信息未处于所述数据处理量范围内，则所述转发路由器确定所述目标转发策略为负载均衡策略。

8.根据权利要求2所述的系统，其特征在于，所述数据采集服务基于数据采集需求，调整所述第一虚拟节点的数量，以新增或减少所述数据处理系统中采集参与者的数目。

9.根据权利要求2所述的系统，其特征在于，所述数据处理服务基于数据处理需求，调整所述第二虚拟节点的数量，以新增或减少所述数据处理系统中处理参与者的数目。

10.一种数据处理方法，其特征在于，应用于上述权利要求1至9中任一项所述的数据处理系统，所述方法包括：

数据采集服务中的各采集参与者从边缘设备中获取多条原始数据，并将所述多条原始数据发送给转发路由器；

所述转发路由器将所述多条原始数据发送给数据处理服务；

所述数据处理服务中的各处理参与者按照预设的数据处理逻辑，对应处理所述转发路由器发送的原始数据。

Images