CN114968610B - 数据处理的方法、多媒体框架及相关设备 - Google Patents

Abstract

本申请提供数据处理的方法、多媒体框架及相关设备，该方法应用于多媒体框架，该多媒体框架包括管理节点、第一执行节点和第二执行节点，该方法包括以下步骤：第一执行节点上的第一元件启动业务处理生成数据流，获取第一元件的连接信息，根据连接信息，通过通信通道向第二执行节点的第二元件发送数据流，其中，连接信息包括第一元件与第二元件之间的连接关系和通道信息，通信通道是管理节点创建的。该方法通过管理节点对多个执行节点进行统一调度和配置，使得各个节点可以分布式的编排业务管道，减少管理节点的处理压力，提高业务编排效率，而且可以分布式处理业务流程，提高多媒体系统的业务处理效率。

Description

数据处理的方法、多媒体框架及相关设备

技术领域

本申请涉及计算机领域，尤其涉及一种数据处理的方法、多媒体框架及相关设备。

背景技术

多媒体系统是集电话、电视、媒体、计算机网络等于一体的信息综合化系统。通常情况下，多媒体系统通过将所需的功能模块封装成元件(element)，然后连接各个元件的输入输出端口(pad)，将元件串联成一个完整的管道(pipeline)实现完整业务流的开发，元件的高可复用性和业务流开发的便捷性，使其在流媒体和人工智能(artificialintelligence,AI)场景使用广泛。

但是，随着AI技术以及边缘计算技术的兴起，单个节点上的元件数量越来越多，对节点的性能要求越来越高，且元件之间的连接关系也更加复杂，不仅编排效率低，且业务流处理过程所需的时间长，业务处理效率低。

发明内容

本申请提供了数据处理方法、多媒体框架及相关设备，用于解决多媒体系统编排效率低、业务处理效率低的问题。

第一方面，提供了一种数据处理方法，该方法应用于多媒体框架，该多媒体框架包括管理节点和多个执行节点，该方法可包括以下步骤：

管理节点，用于根据业务流创建请求构建业务管道，业务管道包括部署在第一执行节点集合中多个元件以及多个元件间的连接关系，第一执行节点集合包括至少一个第一执行节点，至少一个第一执行节点中每个第一执行节点为多个执行节点中任意一个执行节点，管理节点还用于向每个第一执行节点发送元件信息和多个元件间的连接关系，其中，每个第一执行节点的元件信息包括部署在其节点中的多个元件的创建信息；每个第一执行节点，用于获取待处理数据流，根据多个元件间的连接关系完成待处理数据流的处理，并将处理后的数据流发送至业务管道中与其相邻的下一个执行节点。

其中，管理节点和多个执行节点可以由计算设备实现，计算设备具体可以是物理服务器，也可以是虚拟机；管理节点和多个执行节点可以分别部署于不同的计算设备上，管理节点也可以与个别执行节点部署于同一个计算设备上。管理节点和执行节点还可以由不同的处理器实现，具体可以是同一个设备上的处理器，也可以是不同设备上的处理器，举例来说，管理节点是计算设备的中央处理器，执行节点是该计算设备的神经网络处理器。应理解，上述举例用于说明，本申请不作具体限定。

该方法通过管理节点对多个执行节点进行统一调度和配置，使得各个节点不但可以分布式的编排业务管道，提高多媒体系统的编排效率，减少管理节点的处理压力，而且可以分布式地处理业务流程，提高多媒体系统的业务处理效率。

在一种可能的实现方式中，管理节点可接收业务流创建请求，然后根据业务流创建请求在第一执行节点与其他执行节点之间建立通信通道，获得通道信息。应理解，该通道信息用于供第一执行节点在与其相邻的下一个执行节点发送数据流时，通过该通信通道将数据流发送至业务管道中与其相邻的下一个执行节点。

其中，该通道信息可包括通信通道的接口参数和调用方式等等，还可包括其他可以供元件通过通信通道传输数据流的其他必要信息。通信通道可以是用于传输数据流的通信通道，也可以是用于传输控制流的通信通道，还可以是用于传输数据流和控制流的通信通道并且，通道信息包括第一执行节点与其他执行节点之间的通信通道的接口信息，或者，通道信息包括多个执行节点之间的通信通道的接口信息，具体可以根据业务流的需求确定，本申请不作具体限定。

其中，数据流可以是业务管道处理过程产生的数据和消息等，比如人脸识别过程中的样本数据、预测数据、梯度信息等等。若元件是业务管道的首个元件，那么待处理数据流可以是该元件生成的数据流，若元件是非首个元件，那么待处理数据流可以是该元件接收的数据流，比如第二元件的待处理数据流可以是由第一元件发送的数据流。

具体实现中，业务流创建请求包括整个业务流中的所有元件的元件信息的集合和上述多个元件之间的连接关系。管理节点可以对业务流创建请求中的多个元件之间的连接关系进行分析，若存在不同节点上的元件之间的连接关系，在对应节点之间建立通信通道，并保存相应通信通道的通道信息。

可选地，业务流创建请求可以是用户通过上层应用触发的，上层应用可以以配置文件的形式向用户呈现，用户通过编写代码的形式对各个元件进行编排，生成业务流创建请求，用户还可以从配置文件中输入指令，读取编排好的元件和元件之间的连接关系。或者，上层应用也可以以图形用户界面(graphical user interface,GUI)形式向用户呈现，用户通过拖选所需的元件对各个元件进行编排，GUI可向用户呈现出编排好的元件和元件之间的连接关系。应理解，上层应用还可以以其他形式向用户呈现，本申请不作具体限定。举例来说，用户创建用于分类的AI模型时，需要创建输入模块、特征提取模块、分类模块以及输出模块，用户可以从上层应用的GUI中依次拖拽用于实现输入模块的元件1，实现特征提取模块的元件2，实现分类模块的元件3以及实现输出模块的元件4，对各个元件进行编排后，上层应用生成相应的业务流创建请求，并将其发送至管理节点。应理解，上述举例用于说明，本申请不作具体限定。

上述方式中，管理节点根据业务流创建请求，在执行节点之间建立通信通道，可以使得执行节点在处理数据流时，能够通过通信通道实现节点之间的通信，而无需额外部署用于实现节点间通信的通信元件，减少业务管道所需的元件数量，数据流的处理流程清晰直观，提高业务流的编排效率。

在另一种可能的实现方式中，管理节点可根据业务流创建请求，确定元件间的连接关系以及每个第一执行节点的元件信息，然后将元件间的连接关系以及每个第一执行节点的元件信息分别发送给对应的第一执行节点。其中，每个第一执行节点的元件信息包括部署在其节点中的多个元件的创建信息。具体实现中，元件信息可用于指示元件的硬件属性，比如元件的型号、类型、大小、序列号、参数等等，多个元件间的连接关系可用于指示元件之间的连接属性，比如元件之间的输入输出端口之间的对应关系，元件1的输出端口与元件2的输入端口连接，应理解，上述举例用于说明，本身不作具体限定。

值得注意的是，该元件间的连接关系包括上述通道信息，使得第一执行节点上的元件可以通过通信通道向与业务管道中其相邻的下一个执行节点发送数据流。当然，若管理节点根据业务流创建请求确定与第一执行节点与其他节点之间没有通信需求，那么管理节点可以不建立通信通道，发送给各个执行节点的连接关系也不包括通道信息。

具体实现中，管理节点向每个执行节点发送的多个元件间连接关系可以是业务管道中全部元件间的连接关系，也可以是每个执行节点上所包含的多个元件之间的连接关系，具体可根据业务需求确定，本申请不作具体限定，比如业务管道包括元件1～元件4，元件1和元件2部署于执行节点1，管理节点发送至执行节点1的多个元件间连接关系，可以是元件1～元件4之间全部连接关系，也可以是元件1和元件2与其他元件之间的连接关系，本申请不作具体限定。

上述方式中，管理节点根据业务流创建请求，分别确定每个执行节点需要创建的元件的元件信息，并将多个元件间的连接关系以及元件信息发送给各个执行节点，由各个执行节点分布式的构建业务管道，从而降低管理节点的处理压力，提高多媒体框架编排业务管道的效率，提高用户的使用体验。

在一种可能的实现方式中，每个第一执行节点，用于根据元件信息创建部署在其节点中的多个元件，存储多个元件间的连接关系在其节点中的多个元件的端口。具体地，存储在元件端口中的多个元件间的连接信息可以管理节点发送的多个元件间的连接信息(具体可以是整个业务管道中全部元件之间的连接关系，也可以是元件所在节点上的多个元件之间的连接关系)，还可以是与该元件直接相连的其他元件之间的连接关系。

举例来说，执行节点1若接收到管理节点发送的多个元件间的连接关系包括：元件1与其他元件之间的连接关系1，以及元件2与其他元件之间的连接关系2，那么执行节点1可将连接关系1存储于元件1的端口中，应理解，上述举例用于说明，本申请不作具体限定。

具体实现中，执行节点可根据上述多个元件间的连接信息，确定元件的下游元件信息，然后将下游元件信息存储在该元件的输出端口，其中，下游元件信息指的是与元件的输出端口直接或间接相连的其他元件的信息。

可选地，执行节点可根据上述多个元件间的连接信息，确定元件的上游元件信息，然后将上游元件信息存储在元件的输入端口，其中，上游元件信息指的是与元件的输入端口直接或间接相连的其他元件的信息。

这样，元件获取待处理数据流时，若待处理数据流是由其他节点发送的，那么元件可以先从输入端口中的上游元件信息对数据流的来源进行校验，校验成功后再对待处理数据流进行处理，在将处理后的数据流发送至其他元件时，可先从输出端口中获取下游元件信息，确定是否包括通道信息，若包括，则通过通信通道向其他元件发送数据流。若不包括，则通过指针传递的方式传递至其他元件。

上述方式中，执行节点根据管理节点发送的多个元件间的连接关系确定每个元件的下游元件信息，并将其存储在元件的输出端口，可以使得该元件在向其他元件发送数据流时，从输出端口获取下游元件信息，向业务管道中与其相邻的下一个节点发送数据流，实现执行节点之间的通信，为各个执行节点实现分布式处理业务流奠定了通信基础。同时，执行节点根据管理节点发送的多个元件间的连接关系确定每个元件的上游元件信息，并将其存储在元件的输入端口，可以使得元件接收到其他元件发送的数据流时，先根据输入端口中的上游元件信息对数据流的来源进行校验，校验成功后再对数据流进行处理，从而避免对错误数据流进行处理导致业务流处理错误或失败情况的发生。

在另一种可能的实现方式中，第一执行节点通过通信通道向与其相邻的下一个执行节点发送控制流，控制流包括事件和消息中的一种或多种。其中，事件指的是通知元件做一些操作，消息指的是通知元件一些信息。举例来说，事件可以是指：第一元件启动后生成数据流，在数据流发送至第二元件之前，可向第二元件发送校验数据流格式的事件通知；消息可以是指：第二元件校验数据流格式成功后，可以向第一元件返回校验成功的消息，上述举例用于说明，本申请不对控制流的具体内容进行限定。

对于单个节点上的多媒体框架来说，节点之间控制流的通信需通过专门的控制流通道进行转发，而无法同数据流一同转发给其他节点。这样将会导致数据流和控制流不同步，影响业务流的处理效率，而使用第一方面描述的方法，控制流和数据流可以同步传输。仍以上述例子为例，第一元件启动后生成数据流，然后将用于校验数据流格式的事件通知以数据流的形式，与数据流一同发送至第二元件，第二元件可以同步接收到数据流和控制流，对数据流进行数据格式的校验，从而避免由于数据流和控制流的不同步对业务流处理产生影响，提高业务流的处理效率。

在另一种可能的实现方式中，管理节点还可接收上层应用下发的业务流的修改请求，根据业务流修改请求分别向每个节点的代理发送元件修改信息和连接修改信息，使得每个节点的代理的元件管理模块可以根据元件修改信息对元件进行修改，连接管理模块根据连接修改信息对元件之间的连接关系进行修改。其中，元件修改信息可包括该节点需要修改元件信息，比如删除元件的信息、增加元件的信息、搜索元件的信息以及修改已有元件的配置参数等等，连接修改信息可包括元件之间连接关系的修改信息，比如将第一元件和第二元件之间的连接关系删除，增加第二元件与第三元件之间的连接关系等，本申请不作具体限定。

其中，业务流的修改请求可以是用户通过前述内容中的配置文件或者GUI界面生成的，比如用户从GUI界面中拖选新的第四元件插入至业务管道中，修改第四元件与第三元件之间的连接关系，或者，用户从GUI界面中将第一元件删除，或者，用户从GUI界面中修改第一元件的配置参数，若第一元件113是AI模型中的特征提取模块，那么用户可从GUI界面中修改特征提取模块的网络层数，卷积核数量等等。应理解，上述举例用于说明，本申请不作具体限定。

上述方式中，管理节点可统一处理上层应用下发的业务流修改请求，根据修改请求向各个节点下发相应的元件修改信息和连接修改信息，使得元件修改效率更高。

需要说明的，对于单个节点上的多媒体框架来说，由于管道业务部署于单台计算设备，业务流传输至其他节点时，需要添加用于节点间通信的通信元件，发送端额外部署发送元件，接收端额外部署接收元件，这样，若某个业务流需要在节点之间发生多次通信，那么使用将会部署大量用于节点间通信的通信元件，使得编排结构十分复杂，确数据流的流向关系不清晰，降低编排效率，而使用第一方面描述的数据处理方法，该方法基于分布式多媒体框架，管理节点可以对多个执行节点进行统一调度，提前建立好节点间的通信通道，无需在双方节点上增加上述用于节点间通信的通信元件，使得元件数量减少，编排结构简单，每个元件之间的连接关系非常清楚，数据流的处理流程清晰直观，可以提高业务流的编排效率。

第二方面，提供了一种管理节点，应用于多媒体框架，多媒体框架包括管理节点和多个执行节点，管理节点包括：节点管理模块，用于根据业务流创建请求构建业务管道，业务管道包括部署在第一执行节点集合中多个元件以及多个元件间的连接关系，第一执行节点集合包括至少一个第一执行节点，至少一个第一执行节点中每个第一执行节点为多个执行节点中任意一个执行节点；节点管理模块，用于向每个第一执行节点发送元件信息和多个元件间的连接关系，其中，每个第一执行节点的元件信息包括部署在其节点中的多个元件的创建信息。

可选地，管理节点还包括通道管理模块，通道管理模块，用于根据业务流创建请求在第一执行节点与其他执行节点之间建立通信通道，获得通道信息；节点管理模块，用于根据业务流创建请求构建业务管道，确定所述每个第一执行节点的元件信息以及元件间的连接关系，其中，多个元件间的连接关系包括通道信息。

第三方面，提供了一种执行节点，应用于多媒体框架，多媒体框架包括管理节点和多个执行节点，执行节点包括：处理单元，处理单元用于获取待处理数据流，根据多个元件间的连接关系完成待处理数据流的处理，并将处理后的数据流发送至业务管道中与执行节点相邻的下一个执行节点，多个元件间的连接关系是管理节点向执行节点发送的，业务管道是管理节点根据业务流创建请求构建的，业务管道包括部署在多个执行节点中多个元件以及多个元件间的连接关系。

可选地，多个元件间的连接关系包括通道信息，通道信息是管理节点根据业务流创建请求在第一执行节点与其他执行节点之间建立通信通道后获得的，处理单元，用于根据通道信息，将处理后的数据流通过通信通道，发送至业务管道中与其相邻的下一个执行节点。

可选地，执行节点还包括代理单元，代理单元用于根据元件信息创建部署在节点中的多个元件；代理单元用于存储多个元件间的连接关系在多个元件的端口。

可选地，处理单元，用于通过通信通道向与执行节点相连的下一个执行节点发送控制流，控制流包括事件和消息中的一种或多种。

第四方面，提供了一种管理节点，该管理节点应用于多媒体框架中，该管理节点包括处理器和存储器，存储器存储有代码，处理器包括用于执行第一方面或第一方面任一种可能实现方式中由管理节点实现的各个模块的功能。

第五方面，提供了一种执行节点，该执行节点应用于多媒体框架中，该管理节点包括处理器和存储器，存储器存储有代码，处理器包括用于执行第一方面或第一方面任一种可能实现方式中由执行节点实现的各个模块的功能。

第六方面，提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

第七方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

图1是本申请提供的一种多媒体系统的结构示意图；

图2是本申请提供的一种数据处理方法的步骤流程示意图；

图3是本申请提供的一种管理节点的结构示意图；

图4是本申请提供的一种执行节点的结构示意图；

图5是本申请提供的一种计算设备的结构示意图。

具体实施方式

为了便于理解本发明的技术方案，首先，对本发明涉及的“多媒体框架”进行解释说明。

多媒体系统是集电话、电视、媒体、计算机网络等于一体的信息综合化系统。通常情况下，多媒体系统基于多媒体框架进行实现，比如Gstreamer框架，Gstreamer框架是一个基于管道的开源多媒体框架，框架内将各功能模块封装成元件(element)，然后连接各个元件的输入输出端口(pad)，将元件串联成一个完整的业务管道(pipeline)实现完整业务流的开发。Gstreamer框架由于其元件的高可复用性和业务流开发的简易性，在流媒体和人工智能(artificial intelligence,AI)场景使用广泛。应理解，多媒体框架还包括基于Gstreamer框架开发的应用或者平台，比如华为的MindX SDK、英伟达(Nvidia)的deepstream、因特尔(Intel)的dlstreamer等等，本申请不对多媒体框架的具体类型进行限定。

下面对基于Gstreamer的多媒体框架进行简要介绍。基于Gstreamer的多媒体框架通常部署于单个计算设备上，从上至下可分为三层，最上层为应用层，比如Gstreamer自带的一些工具，以及基于Gstreamer封装的库，库中包括用于实现各种功能的应用模块，用户可从库中拖拽各种应用模块，像搭积木一样将元件串联成一个完整的业务管道实现业务流的开发；中间层为核心层，主要为上层应用提供所需接口，根据用户通过上层应用触发的业务流创建请求，确定业务管道的结构框架；最下层为元件层，中间层可根据管道的结构框架，对元件层进行加载和管理，实现用于的业务流开发。

通常情况下，上述基于Gstreamer的多媒体框架的处理流程可分为两个阶段，一个阶段是业务流编排阶段，指的是计算设备基于用户需求创建管道的阶段，此时完整的业务管道将被部署于计算设备上；另一个阶段是业务流处理阶段，指的是创建好管道后，由该计算设备对完整的业务管道进行处理。随着AI技术以及边缘计算技术的兴起，一个完整的业务管道所需元件数量越来越多，元件之间的连接关系也更加复杂，部署该管道的计算设备的性能要求越来越高，不仅业务流编排阶段的编排效率低，且业务流处理阶段所需的时间变长，业务处理效率低。

为了解决多媒体系统的业务处理效率低、编排效率低的问题，本申请提供了一种多媒体框架，该多媒体框架包括管理节点和多个执行节点，在管理节点的管理下，各个节点的代理不但可以分布式地编排业务管道，而且可以分布式地处理业务流程，具体地，在业务流编排阶段，各个执行节点可分别在各自节点上创建、连接和修改元件，降低管理节点的业务处理压力，同时提高业务流编排的效率；在业务流处理阶段，各个节点可通过管理节点预先创建的通信通道实现节点间的通信，协调地完成大规模多媒体任务，从而提高多媒体系统的业务处理效率和编排效率。

图1是本申请提供的一种多媒体框架的结构图。如图1所示，该多媒体框架可包括多个执行节点和管理节点300。其中，管理节点300和多个执行节点之间通过内部网络或者外部网络进行通信连接。图1以多个执行节点包括第一执行节点100和第二执行节点200为例进行了举例说明，本申请不对多个执行节点的数量进行限定。

具体实现中，管理节点300和多个执行节点可以由计算设备实现，计算设备具体可以是物理服务器，比如X86服务器、ARM服务器等等；计算设备也可以是基于通用的物理服务器结合网络功能虚拟化(network functions virtualization,NFV)技术实现的虚拟机(virtual machine,VM)，虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，比如云计算中的虚拟设备，本申请不作具体限定。

可选地，管理节点300和多个执行节点可以分别部署于不同的计算设备上，比如管理节点300部署于计算设备1，第一执行节点100部署于计算设备2，第二执行节点200部署于计算设备3。应理解，上述举例用于说明，本申请不作具体限定。

可选地，多个执行节点中的每个节点分别部署在不同的计算设备，但管理节点300可以与某个节点部署于同一个计算设备上，比如管理节点300和第一执行节点100在同一个计算设备上，或者，管理节点300和第二执行节点200在同一个计算设备上。本申请不作具体限定。

具体实现中，管理节点300和多个执行节点还可以由不同的处理器实现，具体可以是同一个设备上的处理器，也可以是不同设备上的处理器，举例来说，管理节点300是计算设备X的中央处理器(central processing unit,CPU)，节点100和节点200是该计算设备X的神经网络处理器(neural-network processing unit,NPU)，其中，节点100是NPU1，节点200是NPU2。应理解，上述举例用于说明，本申请不作具体限定。

其中，管理节点300用于根据业务流创建请求构建业务管道，该业务管道包括多个元件以及多个元件间的连接关系，管理节点300还用于向第一执行节点100发送元件信息和上述多个元件间的连接关系，其中，元件信息包括部署在第一执行节点100中的多个元件的创建信息。具体实现中，元件信息可用于指示元件的硬件属性，比如元件的型号、类型、大小、序列号、参数等等，多个元件间的连接关系可用于指示元件之间的连接属性，比如元件之间的输入输出端口之间的对应关系，元件1的输出端口与元件2的输入端口连接，应理解，上述举例用于说明，本身不作具体限定。

多个执行节点中的每个执行节点，用于获取待处理数据流，根据多个元件间的连接关系完成待处理数据流的处理，并将处理后的数据流发送至业务管道中与该执行节点相邻的下一个执行节点。其中，数据流可以是业务管道处理过程产生的数据和消息等，比如人脸识别过程中的样本数据、预测数据、梯度信息等等。在图1所示的应用场景中，第二执行节点200即为第一执行节点100相邻的下一个执行节点，第一执行节点100可以启动业务流处理，生成待处理数据流，然后根据多个元件间的连接关系将处理后的数据流发送至第二执行节点200。

进一步地，管理节点300和多个执行节点中的每个执行节点(图1以第一执行节点100和第二执行节点200为例)存在多种划分方式，示例性地，如图1所示，管理节点300可包括节点管理模块310和通道管理模块320，多个执行节点中的每个执行节点可包括代理和至少一个元件(图1以第一执行节点100包括第一代理110、第一元件113以及第三元件114，第二执行节点200包括第一代理210和第二元件213为例进行了说明)，至少一个元件是由代理创建。应理解，图1仅为一种示例性的划分方式，各个模块单元之间可以合并或者拆分为更多或更少的模块单元，本申请不作具体限定，且图1中所示的系统和模块之间的位置关系也不构成任何限制。

其中，管理节点300中的节点管理模块310和通道管理模块320、以及执行节点中的代理主要在业务流编排阶段进行工作，执行节点中的元件在业务流处理阶段工作，下面分别结合上述两个阶段对各个节点中的各个模块进行解释说明。

首先，在业务流编排阶段中，通道管理模块320用于根据业务流创建请求，在多个执行节点之间建立通信通道，比如图1中所示的，在第一执行节点100和第二执行节点200之间建立通信通道400，其中，业务流创建请求包括整个业务流中的所有元件的元件信息的集合和上述多个元件之间的连接关系。具体实现中，通道管理模块320可以对业务流创建请求中的多个元件之间的连接关系进行分析，若存在不同节点上的元件之间的连接关系，通道管理模块320可以在对应节点之间建立通信通道，并保存相应通信通道400的通道信息，该通道信息可包括通信通道400的接口参数和调用方式等等，还可包括其他可以供元件通过通信通道400传输数据流的其他必要信息，本申请不作具体限定。其中，通信通道可以是用于传输数据流的通信通道，也可以是用于传输控制流的通信通道，还可以是用于传输数据流和控制流的通信通道并且，通道信息包括第一执行节点与其他执行节点之间的通信通道的接口信息，或者，通道信息包括多个执行节点之间的通信通道的接口信息，具体可以根据业务流的需求确定，本申请不作具体限定。

具体实现中，业务流创建请求可以是用户通过上层应用触发的，上层应用可以以配置文件的形式向用户呈现，用户通过编写代码的形式对各个元件进行编排，生成业务流创建请求，用户还可以从配置文件中输入指令，读取编排好的元件和元件之间的连接关系。或者，上层应用也可以以图形用户界面(graphical user interface,GUI)形式向用户呈现，用户通过拖选所需的元件对各个元件进行编排，GUI可向用户呈现出编排好的元件和元件之间的连接关系。应理解，上层应用还可以以其他形式向用户呈现，本申请不作具体限定。举例来说，用户创建用于分类的AI模型时，需要创建输入模块、特征提取模块、分类模块以及输出模块，用户可以从上层应用的GUI中依次拖拽用于实现输入模块的元件1，实现特征提取模块的元件2，实现分类模块的元件3以及实现输出模块的元件4，对各个元件进行编排后，上层应用生成相应的业务流创建请求，并将其发送至管理节点300。应理解，上述举例用于说明，本申请不作具体限定。

节点管理模块310用于根据业务流创建请求确定每个节点需要创建的元件，获得每个节点的元件信息，第一执行节点100的元件信息包括部署在第一执行节点100中的多个元件的创建信息，以及多个元件间的连接关系。同理，节点管理模块310向第二执行节点200的第二代理210发送第二执行节点200的元件信息，以业务流创建请求中的多个元件间的连接关系。在图1所示的场景中，第一执行节点的元件信息可包括用于创建第一元件113和第三元件114的元件信息，第二执行节点的元件信息可包括用于创建第二元件213的元件信息。

具体实现中，节点管理模块310向每个执行节点发送的多个元件间连接关系可以是业务管道中全部元件间的连接关系，也可以是每个执行节点上所包含的多个元件之间的连接关系，具体可根据业务需求确定，本申请不作具体限定，比如节点管理模块310发送至第一执行节点100的多个元件间连接关系，可以是第一元件113、第二元件213以及第三元件114之间全部连接关系，也可以是第一元件113和第三元件114与其他元件之间的连接关系，本申请不作具体限定。

值得注意的是，第一执行节点100上的第一元件113与第二执行节点200上的第二元件213存在连接关系，那么节点管理模块310发送至第一执行节点100的连接关系中，还可包括通道信息，使得第一元件113在业务流处理过程中可以根据通道信息将数据流传输至第二执行节点200上的第二元件213。

举例来说，若业务流创建请求中的所有元件的元件信息的结合为元件1、元件2、元件3和元件4，整个业务流中多个元件间的连接关系为，元件1连接元件2，元件2连接元件2，元件3连接元件4，若元件1和元件2在第一执行节点100上处理，元件3和元件4在第二执行节点200上处理，通道管理模块320可根据业务流创建请求确定业务流在第一执行节点100和第二执行节点200之间有通信需求，通道管理模块320可以在第一执行节点100和第二执行节点200之间建立通信通道400，然后节点管理模块将用于创建元件1和元件2的元件信息1以及多个元件间的连接关系发送至第一执行节点100，或者，将用于创建元件1和元件2的元件信息1以及元件1和元件2与其他元件间的连接关系发送至第一执行节点100。同理，节点管理模块可以将用于创建元件3和元件4的元件信息2发送至第二执行节点200，将用于创建元件3和元件4的元件信息2以及多个元件间的连接关系发送至第一执行节点100，或者，将用于创建元件3和元件4的元件信息2以及元件3和元件4与其他元件间的连接关系发送至第一执行节点100。其中，上述多个元件间的连接关系包括通道信息。

应理解，在其他例子中，若通道管理模块320确定第一执行节点100和第二执行节点200之间没有通信需求，那么通道管理模块320可以不在第一执行节点100和第二执行节点200之间建立通信通道，节点管理模块310发送给各个执行节点的连接关系也不包括通道信息。

每个节点上的代理用于接收节点管理模块310发送的元件信息和多个元件间的连接信息，并基于元件信息创建元件，根据多个元件间的连接信息将元件串联成一个完整的管道实现完整业务流的开发。具体实现中，每个节点上的代理可包括元件管理模块和连接管理模块(例如图1中的第一执行节点100上的第一代理110可包括元件管理模块111以及连接管理模块112，第二执行节点200上的第一代理210可包括元件管理模块211以及连接管理模块212)，其中，元件管理模块(比如图1中的元件管理模块111和元件管理模块211)用于根据元件信息创建至少一个元件。连接管理模块(比如图1中的连接管理模块112和连接管理模块212)用于根据连接信息连接各个元件，具体可以按照连接信息描述的连接关系，将各个元件的输入输出端口进行连接，应理解，这里的连接指的是逻辑上进行连接，通过存储元件端口信息的方式记录每个元件之间的连接关系，使得元件在业务流处理阶段可以根据连接关系将生成的数据流传递到下一个元件中，而不是说将各个元件进行物理上的连接。

具体地，第一执行节点100上的第一代理110可以根据管理节点300发送的第一执行节点的元件信息创建第一元件113和第三元件114，然后将多个元件间的连接信息存储于第一元件113和第三元件114的端口中。同理，第一执行节点200上的第二代理210也可以根据第二执行节点的元件信息创建第二元件213，然后将多个元件间的连接信息存储于第二元件的端口中。这里，存储在元件端口中的多个元件间的连接信息可以管理节点300发送的多个元件间的连接信息(具体可以是整个业务管道中全部元件之间的连接关系，也可以是元件所在节点上的多个元件之间的连接关系)，还可以是与该元件直接相连的其他元件之间的连接关系。在图1所示的场景中，第一代理110若接收到管理节点300发送的多个元件间的连接关系包括：第一元件113和第三元件114与其他元件之间的连接关系，那么第一代理110可将第一元件113与第二元件213之间的连接关系存储于第一元件113的端口中，应理解，上述举例用于说明，本申请不作具体限定。

具体实现中，第一代理110可根据上述多个元件间的连接信息，确定第一元件113的下游元件信息，其中，下游元件信息指的是与第一元件113输出端口直接或间接相连的其他元件的信息，然后将下游元件信息存储在第一元件的输出端口。这样，在业务流处理阶段，第一元件113生成数据流后，可从输出端口获取下游元件信息，向第二元件213发送数据流。若下游元件中存在其他节点中的元件，下游元件信息可包括上述通道信息。

可选地，第一代理110可根据上述多个元件间的连接信息，确定第一元件113的上游元件信息，其中，上游元件信息指的是与第一元件113输入端口直接或间接相连的其他元件的信息，然后将上游元件信息存储在第一元件的输入端口。这样，第一元件113接收到其他元件发送的数据流时，可先根据输入端口中的上游元件信息对数据流的来源进行校验，校验成功后再对数据流进行处理，从而避免对错误数据流进行处理导致业务流处理错误或失败情况的发生。

通过管理节点300中的节点管理模块310和通道管理模块320对业务流创建请求进行分析，确定每个执行节点对应的元件信息和多个元件间的连接关系后，各个执行节点可接收管理节点300分别发送的元件信息和多个元件间的连接关系，并基于此进行元件的创建和连接，可以减轻管理节点300在业务流编排阶段中的处理压力，且各个节点分布式创建和连接元件能够减少业务流编排所需的时间，提高编排效率。

其次，在业务流处理阶段，执行节点上的元件用于获取待处理数据流，根据多个元件间的连接关系完成待处理数据流的处理，并将处理后的数据流发送至业务管道中与其相邻的下一个执行节点。

其中，若元件是业务管道的首个元件，比如图1所示的第一元件113，那么待处理数据流可以是该元件生成的数据流，比如第一元件113生成的数据流；若元件是非首个元件，比如图1所示的第二元件213以及第三元件114，那么待处理数据流可以是该元件接收的数据流，比如第二元件213的待处理数据流可以是由第一元件113发送的数据流，本申请不对待处理数据流的来源进行限定。

具体实现中，元件在将处理后的数据流发送至其他元件时，可先从输出端口中获取多个元件间的连接关系，确定是否包括通道信息，若包括，则通过通信通道400向其他元件发送数据流。若不包括，则通过指针传递的方式传递至其他元件。

下面结合图1中的具体场景，对上述业务流编排阶段和业务流处理阶段各个模块单元的处理过程进行举例说明。

在业务流编排阶段，管理节点300的通道管理模块320可以根据业务流创建请求，在第一执行节点100和第二执行节点200之间创建通信通道400，获得通道信息。管理节点300的节点管理模块310可根据业务流创建请求，向第一代理110中的元件管理模块111发送元件信息1和多个元件间的连接信息1，向第二代理210中的元件管理模块211发送元件信息2和多个元件间的连接信息2，其中，元件信息1包括用于创建第一元件113和第三元件114的相关信息，比如元件类型、元件模版、元件参数等等，元件信息2包括用于创建第二元件213的相关信息。多个元件间的连接信息1包括通道信息、第一元件113的输出端口与第二元件213的输入端口对应的信息，第三元件114的输入端口与第二元件213的输出端口对应的信息。多个元件间的连接信息2包括通道信息、第二元件213的输入端口与第一元件113的输出端口对应的信息，第二元件213的输出端口与第三元件114的输入端口对应的信息。

第一代理110中的元件管理模块111接收到元件信息1和多个元件间的连接信息1后，可根据元件信息1创建第一元件113和第三元件114，第二代理210中的元件管理模块211可根据元件信息2创建第二元件213。第一代理110中的连接管理模块112可根据多个元件间的连接信息1确定第一元件113的下游元件信息1和下游元件信息2，该下游元件信息1包括第二元件213的输入端口信息和通道信息，下游元件信息2包括第三元件114的输入端口信息，然后将下游元件信息1存储于第一元件113的输出端口src1，将下游元件信息2存储在第一元件113的输出端口src2。同理，第二代理210中的连接管理模块212可以根据多个元件间的连接信息2确定上游元件信息1，上游元件信息1包括第一元件113的输出端口信息和通道信息，然后将上游元件信息1存储在第二元件213的输入端口sink1

在业务流处理阶段，第一元件113执行完毕后，可先从第一元件113的输出端口src1和src2获取下游元件信息，根据下游元件信息中的通道信息确定与src1端口相连的第二元件213是其他节点中的元件，与src2端口相连的第三元件114是本地元件，因此可根据通道信息，使用通信通道400将数据流传输至第二元件213，通过指针传递的方式将数据流传递至第三元件114。第二元件213和第三元件114的输入端口接收到数据流之后，对数据流的来源和输入端口存储的第一元件的输出端口信息进行校验，校验成功后，第二元件213对输入端口接收到的数据流进行处理。应理解，图1用于举例说明，本申请不作具体限定。

可以理解的，对于单个节点上的多媒体框架来说，由于管道业务部署于单台计算设备，业务流传输至其他节点时，需要添加用于节点间通信的通信元件，发送端额外部署发送元件，接收端额外部署接收元件，这样，若某个业务流需要在节点之间发生多次通信，那么使用将会部署大量用于节点间通信的通信元件，使得编排结构十分复杂，确数据流的流向关系不清晰，降低编排效率，而使用图1所示的分布式多媒体框架，管理节点300可以对多个执行节点进行统一调度，提前建立好节点间的通信通道，无需在双方节点上增加上述用于节点间通信的通信元件，使得元件数量减少，编排结构简单，每个元件之间的连接关系非常清楚，数据流的处理流程清晰直观，可以提高业务流的编排效率。

在一实施例中，在业务流处理过程中，控制流也可以使用上述通信通道400进行传输，该控制流包括事件和/或消息，其中，事件指的是通知元件做一些操作，消息指的是通知元件一些信息。举例来说，事件可以是指：第一元件113启动后生成数据流，在数据流发送至第二元件213之前，可向第二元件213发送校验数据流格式的事件通知；消息可以是指：第二元件213校验数据流格式成功后，可以向第一元件113返回校验成功的消息，上述举例用于说明，本申请不对控制流的具体内容进行限定。

应理解，对于单个节点上的多媒体框架来说，节点之间控制流的通信需通过专门的控制流通道进行转发，而无法同数据流一同转发给其他节点。这样将会导致数据流和控制流不同步，影响业务流的处理效率，而使用本申请提供图1所示的分布式多媒体框架，控制流和数据流可以同步传输。仍以上述例子为例，第一元件113启动后生成数据流，然后将用于校验数据流格式的事件通知以数据流的形式，与数据流一同发送至第二执行节点213，第二执行节点213可以同步接收到数据流和控制流，对数据流进行数据格式的校验，从而避免由于数据流和控制流的不同步对业务流处理产生影响，提高业务流的处理效率。

在一实施例中，管理节点300还可接收上层应用下发的业务流的修改请求，根据业务流修改请求分别向每个节点的代理发送元件修改信息和连接修改信息，使得每个节点的代理的元件管理模块可以根据元件修改信息对元件进行修改，连接管理模块根据连接修改信息对元件之间的连接关系进行修改。其中，元件修改信息可包括该节点需要修改元件信息，比如删除元件的信息、增加元件的信息、搜索元件的信息以及修改已有元件的配置参数等等，连接修改信息可包括元件之间连接关系的修改信息，比如将第一元件113和第二元件213之间的连接关系删除，增加第二元件213与第三元件114之间的连接关系等，本申请不作具体限定。

其中，业务流的修改请求可以是用户通过前述内容中的配置文件或者GUI界面生成的，比如用户从GUI界面中拖选新的第四元件插入至图1所示的管道中，修改第四元件与第三元件之间的连接关系，或者，用户从GUI界面中将第一元件113删除，或者，用户从GUI界面中修改第一元件113的配置参数，若第一元件113是AI模型中的特征提取模块，那么用户可从GUI界面中修改特征提取模块的网络层数，卷积核数量等等。应理解，上述举例用于说明，本申请不作具体限定。

可以理解的，本申请提供的多媒体框架，通过管理节点300统一处理上层应用下发的业务流修改请求，根据修改请求向各个节点下发相应的元件修改信息和连接修改信息，使得元件修改效率更高。

可选地，管理节点300还可以将部分元件进行打包，生成元件箱柜(bin)，然后将箱柜信息以及箱柜连接关系发送至各个执行节点，其中，箱柜信息包括元件箱柜的创建信息，比如箱柜所包括元件的参数、配置、连接关系等等，箱柜连接关系包括箱柜在业务管道中与其他箱柜或者元件之间的连接关系，各个执行节点可根据箱柜信息创建相应的元件箱柜，根据箱柜连接关系将该元件箱柜和其他箱柜或元件进行连接。同理，管理节点接收的业务流修改请求若包括对元件箱柜进行修改，比如在箱柜中增添元件，或者修改箱柜中部分元件的参数，那么管理节点也可以根据业务流修改请求生成相应的箱柜修改信息和箱柜连接信息，具体可参考上述元件修改信息和连接修改信息的描述，这里不再重复展开赘述。

综上可知，本申请提供的多媒体框架包括管理节点和多个执行节点，管理节点可以对多个执行节点进行统一调度和配置，使得各个节点不但可以分布式的编排业务管道，提高多媒体系统的编排效率，减少管理节点的处理压力，而且可以分布式地处理业务流程，提高多媒体系统的业务处理效率。

为了便于本申请提供的数据处理方法能够更好的被理解，下面结合图2对本申请提供的数据处理方法进行解释说明，该方法可应用于如图1所示的多媒体框架中。

如图2所示，图2是本申请提供的一种数据处理方法，该方法可包括以下步骤：

S310：管理节点300在第一执行节点100和第二执行节点200之间创建通信通道400，获得通道信息。其中，该通道信息包括通信通道的接口参数或者调用方式，还可包括通信通道的其他信息，用以供第一元件113根据通道信息，通过上述通信通道400向第二元件213发送数据流。

具体地，管理节点300可以是在接收到上层应用下发的业务流创建请求后，根据业务流创建的通信通道400，该业务流创建请求包括整个业务流中所有元件的元件信息的集合和整个业务流中的多个元件间的连接关系，管理节点300可以对业务流创建请求中的多个元件之间的连接关系进行分析，若存在不同节点上的元件之间的连接关系，通道管理模块320可以在对应节点之间建立通信通道，并保存相应通信通道400的通道信息，该通道信息可包括通信通道400的接口参数和调用方式等等，还可包括其他可以供元件通过通信通道400传输数据流的其他必要信息，本申请不作具体限定。

具体实现中，业务流创建请求可以是用户通过上层应用触发的，上层应用可以以配置文件的形式向用户呈现，也可以以GUI形式向用户呈现，还可以以其他形式向用户呈现。应理解，对于业务流创建请求的详细描述还可参考图1实施例，这里不再重复赘述。

S320：管理节点300向第一执行节点100发送元件信息和上述多个元件间的连接关系，以供第一代理110创建和连接至少一个元件。其中，元件信息是管理节点300根据业务流创建请求确定的第一执行节点100上部署的多个元件的创建信息，多个元件间的连接关系可以是业务流创建请求中业务管道中全部元件间的连接关系，也可以是管理业务流创建请求确定的第一执行节点100上部署的多个元件间的连接关系，具体可参考图1实施例中的描述，这里不重复赘述。

在一实施例中，对于与其他节点存在通信需求的节点，管理节点300向其发送的多个元件间的连接关系还包括步骤S310获得的通道信息。示例性的，图1所示的第一元件113在第一执行节点100上，第二元件213在第二执行节点200上，因此第一执行节点100接收到的多个元件间的连接信息包括通道信息，若某第一执行节点100上的元件与其他节点上的元件之间不存在连接关系，那么第一代理110接收到的连接信息可不包括上述通道信息。

可选地，多个元件间的连接信息以相邻的两个元件的输入输出端口之间的对应关系来呈现，比如连接关系为，元件1与元件2相连，且数据流走向为元件1的输出结果输入元件2，那么对应的连接信息可以是：元件1的输出端口对应元件2的输入端口，若元件1和元件2处于不同执行节点，那么连接信息还可包括通道信息。应理解，上述举例用于说明，本申请不作具体限定，对于元件信息和连接信息的具体描述可参考图1实施例，这里不再重复赘述。

S330：第一执行节点100根据元件信息和多个元件间的连接关系，创建第一元件113，并将个元件间的连接关系存储在第一元件113的端口中。

其中，存储在元件端口中的多个元件间的连接信息可以是管理节点300发送的多个元件间的连接信息(具体可以是整个业务管道中全部元件之间的连接关系，也可以是元件所在节点上的多个元件之间的连接关系)，还可以是与该元件直接相连的其他元件之间的连接关系。在图1所示的场景中，第一执行节点100若接收到管理节点300发送的多个元件间的连接关系包括：第一元件113和第三元件114与其他元件之间的连接关系，那么第一执行节点100可将第一元件113与第二元件213之间的连接关系存储于第一元件113的端口中，应理解，上述举例用于说明，本申请不作具体限定。

具体实现中，第一执行节点100可根据上述多个元件间的连接信息，确定第一元件113的下游元件信息，其中，下游元件信息指的是与第一元件113输出端口直接或间接相连的其他元件的信息，然后将下游元件信息存储在第一元件的输出端口。这样，在业务流处理阶段，第一元件113生成数据流后，可从输出端口获取下游元件信息，向第二元件213发送数据流。若下游元件中存在其他节点中的元件，下游元件信息可包括上述通道信息。

可选地，第一代理110可根据上述多个元件间的连接信息，确定第一元件113的上游元件信息，其中，上游元件信息指的是与第一元件113输入端口直接或间接相连的其他元件的信息，然后将上游元件信息存储在第一元件的输入端口。这样，第一元件113接收到其他元件发送的数据流时，可先根据输入端口中的上游元件信息对数据流的来源进行校验，校验成功后再对数据流进行处理，从而避免对错误数据流进行处理导致业务流处理错误或失败情况的发生。

值得注意的是，在图1所示的场景中，与第一元件113直接相连的下游元件是第二元件213，且第二元件213与第一元件113不在同一节点上，因此第一代理110将通道信息存储在第一元件113的端口中，以供第一元件113在业务处理过程中，通过通信通道400跨节点传输数据流；若与第一元件113直接相连的第二元件213在同一节点上，那么第一元件113的端口中没有上述通道信息。比如图1所示的场景中，第三元件114与第一元件113的输出端口src2相连，因此第一元件113的输出端口src2中包括第三元件114的输入端口sink2的信息，但是没有通道信息。上述举例用于说明，本申请不作具体限定。

S340：第一元件113获取待处理数据流，根据多个元件间的连接关系完成待处理数据流的处理。

其中，若元件是业务管道的首个元件，比如图1所示的第一元件113，那么待处理数据流可以是该元件生成的数据流，比如第一元件113生成的数据流；若元件是非首个元件，比如图1所示的第二元件213以及第三元件114，那么待处理数据流可以是该元件接收的数据流，比如第二元件213的待处理数据流可以是由第一元件113发送的数据流，本申请不对待处理数据流的来源进行限定。

S350：第一元件113将处理后的数据流发送至业务管道中与其相邻的下一个执行节点，即第二执行节点200。

具体地，第一元件113启动业务处理生成数据流后，可从第一元件113的输出端口中获取下游元件信息，确定其中是否包括通道信息，若包括，则第一元件113可通过通信通道400向其他元件发送上述数据流，若不包括，第一元件113可通过指针传递的方式向其他元件发送数据流。

在一实施例中，在业务流处理过程中，控制流也可以使用上述通信通道400进行传输，即步骤S350处，第一元件113还可通过通信通道400向第二元件213发送控制流，该控制流包括事件和/或消息，其中，事件指的是通知元件做一些操作，消息指的是通知元件一些信息。关于事件和消息的描述可参考图1实施例，这里不再重复赘述。

可以理解的，使用本申请提供的数据处理方法，控制流和数据流可以同步传输，避免了由于数据流和控制流的不同步对业务流处理产生影响，提高业务流的处理效率。

在一实施例中，步骤S330之后，管理节点还可接收上层应用下发的业务流的修改请求，根据业务流修改请求确定第一执行节点100需要修改的元件修改信息和连接修改信息，将上述元件修改信息和连接修改信息发送至第一执行节点100的第一代理110，以供第一代理110根据元件修改信息和连接修改信息对第一元件113进行修改。元件修改信息和连接修改信息的描述可参考图1实施例中的描述，本申请不作具体限定。

可选地，业务流的修改请求可以是用户通过前述内容中的配置文件或者GUI界面生成的，比如用户从GUI界面中拖选新的第四元件插入至图1所示的管道中，修改第四元件与第三元件之间的连接关系。可以理解的，通过管理节点300统一处理上层应用下发的业务流修改请求，并根据修改请求向各个节点下发相应的元件修改信息和连接修改信息，使得元件修改效率更高。

应理解，第二执行节点200在业务流编排和业务流处理阶段的数据处理方法可参考上述步骤S310～步骤S350以及图1实施例，这里不重复展开赘述。

综上可知，本申请提供的数据处理方法，管理节点可以对多个执行节点进行统一调度和配置，使得各个节点不但可以分布式的编排业务管道，提高多媒体系统的编排效率，减少管理节点的处理压力，而且可以分布式地处理业务流程，提高多媒体系统的业务处理效率。

上面详细阐述了本申请实施例的方法，为了便于更好的实施本申请实施例上述方案，相应地，下面还提供用于配合实施上述方案的相关设备。

图3是本申请提供的一种管理节点300的结构示意图。如图3所示，管理节点300可应用于图1所示的多媒体框架，多媒体框架包括管理节点300和多个执行节点，管理节点可包括节点管理单元330和通道管理单元340。

节点管理单元330，用于根据业务流创建请求构建业务管道，业务管道包括部署在第一执行节点集合中多个元件以及多个元件间的连接关系，第一执行节点集合包括至少一个第一执行节点，至少一个第一执行节点中每个第一执行节点为多个执行节点中任意一个执行节点；

节点管理单元330，用于向每个第一执行节点发送元件信息和多个元件间的连接关系，其中，每个第一执行节点的元件信息包括部署在其节点中的多个元件的创建信息。

在一实施例中，通道管理单元340用于根据业务流创建请求在第一执行节点与其他执行节点之间建立通信通道，获得通道信息；节点管理单元330，用于根据业务流创建请求构建业务管道，确定每个第一执行节点的元件信息以及元件间的连接关系，其中，多个元件间的连接关系包括通道信息。

应理解，节点管理单元330的描述可参考图1～图2实施例中节点管理模块310的描述，通道管理单元340的描述可参考图1～图2实施例中通道模块320的描述，这里不重复赘述。

图4是本申请提供一种执行节点400的结构示意图。如图4所示，执行节点400可应用于图1所示的多媒体框架，多媒体框架包括管理节点和多个执行节点400，执行节点400可包括处理单元410和代理单元420。

处理单元410用于获取待处理数据流，根据多个元件间的连接关系完成待处理数据流的处理，并将处理后的数据流发送至业务管道中与执行节点400相邻的下一个执行节点，多个元件间的连接关系是管理节点向执行节点发送的，业务管道是管理节点根据业务流创建请求构建的，业务管道包括部署在多个执行节点中多个元件以及多个元件间的连接关系。

在一实施例中，多个元件间的连接关系包括通道信息，通道信息是管理节点根据业务流创建请求在第一执行节点与其他执行节点之间建立通信通道后获得的，处理单元410用于根据通道信息，将处理后的数据流通过通信通道，发送至业务管道中与其相邻的下一个执行节点。

在一实施例中，代理单元420用于根据元件信息创建部署在执行节点中的多个元件；代理单元420用于存储多个元件间的连接关系在多个元件的端口。

在一实施例中，处理单元410用于通过通信通道向与执行节点相连的下一个执行节点发送控制流，控制流包括事件和消息中的一种或多种。

应理解，图4中的代理单元420即为图1中的代理110，处理单元410即为图1中的元件，处理单元410的数量可以为一个或者多个。具体实现中，管理节点300和执行节点400可以由计算设备实现，计算设备具体可以是物理服务器，也可以虚拟机。管理节点300和执行节点400可以分别部署于不同的计算设备上，也可以部署于同一个计算设备上。管理节点300和执行节点400还可以由不同的处理器实现，具体可以是同一个设备上的处理器，也可以是不同设备上的处理器，举例来说，管理节点300是计算设备X的中央处理器CPU，执行节点是该计算设备X的NPU。应理解，上述举例用于说明，本申请不作具体限定。

应理解，处理单元410的描述可参考图1～图2实施例中元件(例如第一元件113、第二元件213以及第三元件114)的描述，代理单元420的描述可参考图1～图2实施例中代理(比如第一代理110和第二代理210)的描述，这里不重复赘述。

综上可知，本申请提供的管理节点300和执行节点400，管理节点300可以对多个执行400节点进行统一调度和配置，使得各个节点不但可以分布式的编排业务管道，提高多媒体系统的编排效率，减少管理节点的处理压力，而且可以分布式地处理业务流程，提高多媒体系统的业务处理效率。

图5是本申请提供的一种计算设备500的结构示意图，该计算设备500可以是图1～图3中的管理节点300，也可以是图1和图2中的第一执行节点100和第二执行节点200，还可以是图4中的执行节点400。

如图5所示，计算设备500包括：处理器510、通信接口520以及存储器530。其中，处理器510、通信接口520以及存储器530可以通过内部总线540相互连接，也可通过无线传输等其他手段实现通信。本申请实施例以通过总线540连接为例，总线540可以是外设部件互连标准(peripheral component interconnect,PCI)总线或扩展工业标准结构(extendedindustry standard architecture,EISA)总线等。总线540可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器510可以由至少一个通用处理器构成，例如CPU、NPU或者CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application-specific integrated circuit,ASIC)、可编程逻辑器件(programmable logic device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device,CPLD)、现场可编程逻辑门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic,GAL)或其任意组合。处理器510执行各种类型的数字存储指令，例如存储在存储器530中的软件或者固件程序，它能使网络设备210提供较宽的多种服务。

存储器530用于存储程序代码，并由处理器510来控制执行。程序代码中可以包括一个或多个软件模块。

当计算设备是前述内容中的管理节点时，这一个或多个软件模块可以为图3所示实施例中提供的软件模块，如节点管理单元和通道管理单元，其中，通道管理单元用于根据业务流创建请求创建通信通道，获得通道信息，节点管理单元用于根据业务流创建请求构建业务管道，向每一个执行节点发送元件信息和多个元件间的连接关系。具体可用于执行图2实施例中的步骤S310-步骤S320及其可选步骤，还可以用于执行图1-图3实施例描述的其他由管理节点300执行的步骤，这里不再进行赘述。

当计算设备是前述内容中的执行节点时，这一个或多个软件模块可以为图4所示实施例中提供的软件模块，如处理单元和代理单元，其中，代理单元用于根据管理节点发送的元件信息创建部署在节点中的多个元件，并将多个元件间的连接关系存储在元件的端口中；处理单元用于获取待处理数据流，根据多个元件间的连接关系完场待处理数据流的处理，并将处理后的数据流发送至业务管道中与执行节点相邻的下一个执行节点。具体可用于执行图2实施例中的步骤S310-步骤S320及其可选步骤，还可以用于执行图1-图3实施例描述的其他由管理节点300执行的步骤，这里不再进行赘述。

存储器530可以包括易失性存储器(Volatile Memory)，例如随机存取存储器(Random Access Memory，RAM)；存储器530也可以包括非易失性存储器(Non-VolatileMemory)，例如只读存储器(Read-Only Memory，ROM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；存储器530还可以包括上述种类的组合。存储器530可以存储有程序代码，具体可以包括用于供处理器510执行图1-图3实施例描述的其他步骤的程序代码，这里不再进行赘述。

通信接口520可以为有线接口(例如以太网接口)，可以为内部接口(例如高速串行计算机扩展总线(peripheral component interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他服务器或模块进行通信，具体实现中，通信接口520可用于接收报文，以供处理器510对该报文进行处理。

需要说明的是，本实施例可以是通用的物理服务器实现的，例如，ARM服务器或者X86服务器，也可以是基于通用的物理服务器结合NFV技术实现的虚拟机实现的，虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，比如在本实施例可以在云计算基础设施上实现。

需要说明的，图5仅仅是本申请实施例的一种可能的实现方式，实际应用中，计算设备500还可以包括更多或更少的部件，这里不作限制。关于本申请实施例中未示出或未描述的内容，可参见前述图1-图4实施例中的相关阐述，这里不再赘述。

本申请还提供一种数据处理系统，该数据系统基于图1所示的多媒体框架，该数据处理系统用于实现上述图2所示方法的流程的操作步骤。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在处理器上运行时，图2所示的方法流程得以实现。

本申请实施例还提供一种计算机程序产品，当计算机程序产品在处理器上运行时，图2所示的方法流程得以实现。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括至少一个计算机指令。在计算机上加载或执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含至少一个可用介质集合的服务器、数据中心等数据存储节点。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital videodisc,DVD)、或者半导体介质。半导体介质可以是SSD。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (15)

1.一种数据处理的方法，其特征在于，所述方法应用于多媒体框架，所述多媒体框架包括管理节点和多个执行节点，所述方法包括：

所述管理节点，用于根据业务流创建请求构建业务管道，所述业务管道包括部署在第一执行节点集合中多个元件以及所述多个元件间的连接关系，所述第一执行节点集合包括至少一个第一执行节点；所述至少一个第一执行节点中每个第一执行节点为所述多个执行节点中任意一个执行节点；向每个所述第一执行节点发送元件信息和所述多个元件间的连接关系，其中，所述每个第一执行节点的元件信息包括部署在其节点中的多个元件的创建信息；

所述每个第一执行节点，用于获取待处理数据流，根据所述多个元件间的连接关系确定上游元件信息，通过所述上游元件信息对所述待处理数据流的来源进行校验，校验成功后完成所述待处理数据流的处理，并将处理后的数据流发送至所述业务管道中与其相邻的下一个执行节点，其中，上游元件信息指的是与元件的输入端口直接或间接相连的其他元件的信息。

2.根据权利要求1所述的方法，其特征在于，所述根据业务流创建请求构建业务管道包括：

所述管理节点接收业务流创建请求；

所述管理节点根据所述业务流创建请求在所述第一执行节点与其他执行节点之间建立通信通道，获得通道信息；

所述管理节点根据所述业务流创建请求构建业务管道，确定所述每个第一执行节点的元件信息以及所述元件间的连接关系，其中，所述多个元件间的连接关系包括所述通道信息；

所述将处理后的数据流发送至所述业务管道中与其相邻的下一个执行节点包括：

所述每个第一执行节点根据所述通道信息，将所述处理后的数据流通过所述通信通道，发送至所述业务管道中与其相邻的下一个执行节点。

3.根据权利要求2所述的方法，其特征在于，所述通道信息包括所述第一执行节点与其他执行节点之间的通信通道的接口信息，或者，所述通道信息包括所述多个执行节点之间的通信通道的接口信息；

所述多个元件间的连接关系包括所述多个执行节点中元件间的连接关系。

4.根据权利要求1所述的方法，其特征在于，所述每个第一执行节点，用于根据所述元件信息创建所述部署在其节点中的多个元件，存储所述多个元件间的连接关系在所述其节点中的多个元件的端口。

5.根据权利要求1所述的方法，其特征在于，所述管理节点是中央处理器，所述多个执行节点是神经网络处理器。

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

所述第一执行节点通过通信通道向所述与其相邻的下一个执行节点发送控制流，所述控制流包括事件和消息中的一种或多种。

7.根据权利要求1至6中任一权利要求所述的方法，其特征在于，所述业务流创建请求是用户通过上层应用触发的，所述上层应用向用户呈现的方式包括配置文件和图形用户界面GUI。

8.一种管理装置，其特征在于，应用于多媒体框架，所述多媒体框架包括所述管理装置和多个执行装置，所述管理装置包括：

节点管理模块，用于根据业务流创建请求构建业务管道，所述业务管道包括部署在第一执行装置集合中多个元件以及所述多个元件间的连接关系，所述第一执行装置集合包括至少一个第一执行装置，所述至少一个第一执行装置中每个第一执行装置为所述多个执行装置中任意一个执行装置；

所述节点管理模块，用于向所述每个第一执行装置发送元件信息和所述多个元件间的连接关系，其中，所述每个第一执行装置的元件信息包括部署在其装置中的多个元件的创建信息，所述多个元件间的连接关系用于供所述第一执行装置获取待处理数据流的情况下，根据所述多个元件间的连接关系根据所述多个元件间的连接关系确定上游元件信息，通过所述上游元件信息对所述待处理数据流的来源进行校验，校验成功后完成所述待处理数据流的处理，并将处理后的数据流发送至所述业务管道中与其相邻的下一个执行装置，其中，上游元件信息指的是与元件的输入端口直接或间接相连的其他元件的信息。

9.根据权利要求8所述的管理装置，其特征在于，所述管理装置还包括通道管理模块，

所述通道管理模块，用于根据所述业务流创建请求在所述第一执行装置与其他执行装置之间建立通信通道，获得通道信息；

所述节点管理模块，用于根据所述业务流创建请求构建业务管道，确定所述元件信息以及所述元件间的连接关系，其中，所述多个元件间的连接关系包括所述通道信息。

10.一种执行装置，其特征在于，应用于多媒体框架，所述多媒体框架包括管理装置和多个所述执行装置，所述执行装置包括：

处理单元，所述处理单元用于获取待处理数据流，根据多个元件间的连接关系确定上游元件信息，通过所述上游元件信息对所述待处理数据流的来源进行校验，校验成功后完成所述待处理数据流的处理，并将处理后的数据流发送至业务管道中与所述执行装置相邻的下一个执行装置，所述上游元件信息指的是与元件的输入端口直接或间接相连的其他元件的信息，所述多个元件间的连接关系是所述管理装置向所述执行装置发送的，所述业务管道是所述管理装置根据业务流创建请求构建的，所述业务管道包括部署在多个所述执行装置中多个元件以及所述多个元件间的连接关系。

11.根据权利要求10所述的执行装置，其特征在于，所述多个元件间的连接关系包括通道信息，所述通道信息是所述管理装置根据所述业务流创建请求在所述执行装置与其他执行装置之间建立通信通道后获得的，

所述处理单元，用于根据所述通道信息，将所述处理后的数据流通过所述通信通道，发送至所述业务管道中与其相邻的下一个执行装置。

12.根据权利要求11所述的执行装置，其特征在于，所述执行装置还包括代理单元，所述代理单元用于根据元件信息创建所述部署在装置中的多个元件；

所述代理单元用于存储多个元件间的连接关系在所述多个元件的端口。

13.根据权利要求11或12中任一权利要求所述的执行装置，其特征在于，所述处理单元，用于通过所述通信通道向与所述执行装置相连的下一个执行装置发送控制流，所述控制流包括事件和消息中的一种或多种。

14.一种管理装置，其特征在于，包括处理器和存储器，所述存储器存储有代码，所述处理器执行所述代码实现如权利要求1至7中任一权利要求中所述管理节点的操作步骤。

15.一种执行装置，其特征在于，包括处理器和存储器，所述存储器存储有代码，所述处理器执行所述代码实现如权利要求1至7中任一权利要求中所述执行节点操作步骤。

Images