CN113900810A - 分布式图处理方法、系统及存储介质 - Google Patents

Abstract

本申请提出了一种分布式图处理方法、系统及存储介质，接收到针对目标业务的图处理任务，获取目标业务关联的图数据后，为了提高处理效率，将图处理任务分解为多个子图处理任务，分发给相应的计算引擎，由计算引擎响应子图处理任务，将基于BSP‑GAS耦合计算模型对该子图处理任务对应的图数据进行同步迭代的图处理，即利用BSP计算模型和GAS计算模型各自的优点实现图计算，降低迭代计算过程中产生的网络传输和调度开销的同时，获得了相对较快的收敛速度，提升了整个分布式图处理系统的性能，使其能够适用于多种类型图处理任务应用场景。

Description

分布式图处理方法、系统及存储介质

技术领域

本申请涉及数据处理技术领域，更具体地说是涉及一种分布式图处理方法、系统及存储介质。

背景技术

如今，人工智能技术已被广泛应用到如智能交通、社交网络、信息推荐等各领域，其中，大规模图计算在基于人工智能的机器学习、数据挖掘、自然语言处理等应用实现过程中是至关重要，通常利用基于MapReduce的分布式处理架构，满足不同领域的应用需求。

在基于MapReduce的分布式处理架构的工作处理流程中，其是将一个图计算作业分成多个map(映射)任务和reduce(归约)任务，从而将该图计算作业抽象成map任务处理阶段和reduce任务处理阶段，再将各任务分发给不同节点执行。对于迭代计算应用，通常是在外部多次链式启动作业，会产生较高网络传输开销，大大降低了处理效率。

发明内容

有鉴于此，为了解决上述技术问题，本申请提供了以下技术方案：

一方面，本申请提出了一种分布式图处理方法，所述方法包括：

接收到针对目标业务的图处理任务，获取所述目标业务对应的图数据；

将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的计算引擎；

触发所述计算引擎响应分发到的所述子图处理任务，基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果；其中，所述图计算模型是指整体同步并行BSP-定点程序GAS耦合计算模型；

利用得到的多个子图处理结果，得到所述图处理任务的图处理结果，将所述图处理结果反馈至相应的业务客户端。

可选的，所述基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果，包括：

获取所述多个计算引擎执行分发到的所述子图处理任务各自缓存的节点状态信息；

按照预设的增量缓存策略，依据所述节点状态信息，检测下一次超步迭代计算过程中是否提取相应计算引擎的更新数据；

依据检测结果，执行针对相应计算引擎的GAS处理逻辑，更新该计算引擎的所述节点状态信息，并将本次超步迭代计算得到的该计算引擎的更新增量推送至相邻计算引擎，以更新相应所述相邻计算引擎的节点状态信息。

可选的，所述按照预设的增量缓存策略，依据所述节点状态信息，检测下一次超步迭代计算过程中是否提取相应计算引擎的更新数据，包括：

依据所述节点状态信息，确定相应计算引擎是否已得到相邻计算引擎的增量；

所述依据检测结果，执行针对相应计算引擎的GAS处理逻辑，包括：

若未得到相邻计算引擎的增量，执行针对该计算引擎的GAS处理逻辑，从该计算引擎的相邻计算引擎提取该相邻计算引擎的增量；

若得到相邻计算引擎的增量，执行针对该计算引擎的GAS处理逻辑过程中，从该计算引擎的节点状态信息中，获取该计算引擎的相邻计算引擎的增量。

可选的，所述将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的计算引擎，包括：

依据多个计算引擎各自的计算资源，将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至具有相应计算资源的计算引擎。

可选的，所述将所述多个子图处理任务分发至具有相应计算资源的计算引擎，包括：

对于所述目标业务对应的图数据中的各图节点，获取所述各图节点具有的索引号，与相应图节点被分发到的计算引擎的IP地址之间的第一映射关系；

若所述计算引擎创建多个进程，获取所述各图节点具有的索引号，与用于构建相应图节点的图数据的所述进程的进程信息之间的第二映射关系；

依据所述第一映射关系和所述第二映射关系，获取目标图节点映射的目标进程下的目标图数据。

可选的，所述子图处理任务对应的图数据是采用具有哈希链表结构的字典进行存储索引；所述字典表示不同节点ID哈希值与不同图节点之间的第三映射关系；

若检测到多个图节点的节点ID哈希值相同，在所述字典中配置这多个图节点各自对应的随机标识码。

可选的，在不同的所述计算引擎的图处理过程中，通过消息传递机制，实现不同超步迭代计算的同步；

其中，所述消息传递机制包括通过不同类型消息，实现针对不同图对象的不同类型操作；所述不同类型消息包括信令消息和数据消息；所述不同图对象包括全局图网络、计算引擎的目标进程、目标图节点以及不同图节点之间的目标图边；所述不同类型操作包括图节点和/或图边的添加操作、删除操作、属性配置操作、属性获取操作。

可选的，所述方法还包括：

检测到待传输消息为多个消息类型构成的复合消息，将所述复合消息压缩为字符数组；

将所述字符数组发送至目标对象，由所述目标对象通过预设数据转换格式，将所述字符数组转换为相应的数据结构；所述目标对象为所述计算引擎、所述计算引擎中的任一进程或所述图数据中的任一图节点。

又一方面，本申请还提出了一种分布式图处理系统，所述系统包括域控制设备、图计算引擎集群以及图存储引擎集群，其中：

所述域控制设备，用于接收接入相应域网络的客户端发送的针对目标业务的图处理任务；

所述图存储引擎集群包括多个存储引擎，所述存储引擎用于查询相应数据库中所述目标业务对应的图数据；

所述图计算引擎集群包括主计算引擎和多个从计算引擎：

所述主计算引擎，用于获取所述目标业务对应的图数据，将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的从计算引擎；

所述从计算引擎，用于响应分发到的所述子图处理任务，基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果，发送至所述主计算引擎；其中，所述图计算模型是指整体同步并行BSP-定点程序GAS耦合计算模型；

所述主计算引擎，用于利用得到的多个子图处理结果，得到所述图像处理任务的图处理结果，通过所述域控制设备将所述图处理结果反馈至所述客户端。

又一方面，本申请还提出了一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器加载执行，实现如上述的分布式图处理方法。

由此可见，本申请提供一种分布式图处理方法、系统及存储介质，接收到针对目标业务的图处理任务，获取目标业务关联的图数据后，为了提高处理效率，将图处理任务分解为多个子图处理任务，分发给相应的计算引擎，由计算引擎响应子图处理任务，将基于BSP-GAS耦合计算模型对该子图处理任务对应的图数据进行同步迭代的图处理，即利用BSP计算模型和GAS计算模型各自的优点实现图计算，降低迭代计算过程中产生的网络传输和调度开销的同时，获得了相对较快的收敛速度，提升了整个分布式图处理系统的性能，使其能够适用于多种类型图处理任务应用场景。

附图说明

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

图1示出了实现本申请提出的分布式图处理方法的分布式图处理系统的一可选示例的架构示意图；

图2示出了实现本申请提出的分布式图处理方法的分布式图处理系统的又一可选示例的架构示意图；

图3示出了本申请提出的分布式图处理方法的一可选示例的流程示意图；

图4示出了本申请提出的分布式图处理方法的又一可选示例的流程示意图；

图5示出了本申请提出的分布式图处理方法中，每一超步的不同子步的状态机转换过程示意图；

图6示出了本申请提出的分布式图处理方法中，相邻计算节点的同步迭代更新过程示意图；

图7示出了本申请提出的分布式图处理装置的一可选示例的结构示意图。

具体实施方式

针对背景技术部分的描述，为了提高处理效率，提出采用基于BSP(BulkSynchronous Parallel，整体同步并行计算模型)的分布式处理架构进行数据处理，满足图计算应用需求，在BSP模型引入“超步”概念，其是以图网络顶点为中心，将一图计算任务抽象为一系列全局超步，每一个超步可以由并发计算、通讯传输、栅栏同步三个处理过程，这样，通过对多个超步进行迭代执行计算，直至全部顶点收敛，得到所需计算结果。

可见，BSP模型基于超步实现图数据的迭代计算，在每一个超步内通过消息通信机制实现数据的网络传输，并在不同超步间进行并行数据同步，保证任务的收敛性和计算结果的正确性，相对于基于MapReduce模型实现的图计算，减少了报文在网络中的传输次数，提高了迭代计算应用中的处理效率和可靠性。

然而，这种基于BSP模型的数据处理方法，往往仅适用于类Pregel的边切割系统，对于点切割的应用场景，由于点切割导致某一顶点分布在不同的物理节点上，这样，消息推送和Combine切片机制的应用，不仅不会减少报文在网络中的传输次数，甚至可能会导致传输次数增加，降低处理效率。

对此，进一步提出基于GAS(Gather-Apply-Scatter)模型(即顶点程序模型)的分布式处理架构，其可以认为是对以顶点为中心的图计算编程模型的一种细化，如将顶点Update函数处理过程划分为三个连续的处理阶段：负责提取消息的信息收集阶段(Gather)、负责基于收集的消息进行本地处理的应用阶段(Apply)和负责发送新的消息的分发阶段(Scatter)，通过细化计算过程来增加计算并发性，提高每一个处理阶段的并发处理能力。

由于并发任务间无需任何数据同步过程，任意时刻每个并发任务都可对全局参数进行读取和更新，这提高了计算资源的利用率和整体任务的执行速度。但并行执行的某一些任务因执行设备负载高或硬件故障等因素，会导致其等在迭代轮数上，使其严重滞后于并行执行的其他任务，导致整个并行任务的最终计算结果不正确，也就是说，基于GAS模型的分布式处理架构实现的并发任务，无法保证任务执行结果的正确性。

针对上述问题，本申请提出对于上述BSP模型和GAS模型进行耦合，得到一种新的分布式处理架构，记为BSP-GAS耦合计算模型，利用两个模型各自的优势克服或改善对方模型的缺陷，提升整个系统的可扩展性和易实施性，通过网络通讯和计算开销，来提高设备的处理能力，进而提高任务执行结果的可靠性和准确性。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图1，为实现本申请提出的分布式图处理方法的分布式图处理系统的一可选示例的架构示意图，该系统可以采用B/S(Browser/Server Architecture，浏览器/服务器)架构模式，如图1所示，该系统可以包括：域控制设备110、图计算引擎集群120以及图存储引擎集群130，其中：

域控制设备110可以是域控制器(Domain Controller，DC)，是指在“域”模式下，至少有一台服务器负责每一台接入该域网络的电脑和用户的验证工作。通常情况下，一个域可以对应配置域控制设备，本申请对域控制设备110的数量及其工作过程不做详述。

在实际应用中，由于域控制设备110包含了由这个域的账户、密码、属于这个域的计算机等信息构成的数据库，这样，用户通过浏览器向域控制器110代理的后台服务器集群发送针对目标业务的图处理任务，这种情况下，浏览器可以接入该域控制设备110的域，经过账号、密码等信息的验证后，若验证通过，域控制设备110将该图处理任务发送至后台服务器集群，如上述图计算引擎集群。

图计算引擎集群120可以包括多个计算引擎Spark，且这多个计算引擎可以采用星型结构，如将中心节点确定为主计算引擎，将其他计算引擎作为从计算引擎，由该主计算引擎实现对图处理任务的分割、以及对全部从计算引擎的管理和控制，实现不同从计算节点之间的同步性运行，实现过程本申请不做详述。

结合上文对本申请提出的计算引擎实现的新的图计算的技术构思，各从计算引擎对分配到的子图处理任务进行图计算过程中，可以基于新构建的分布式图计算模型实现，即上述BSP-GAS耦合计算模型实现，实现过程可以参照下文方法实施例相应部分的描述，本实施例不做赘述。

由此可见，多个从计算引擎基于BSP-GAS耦合计算模型，执行用户发送的图处理任务，实现对相应图数据的同步迭代的图计算，从而结合上文描述的BSP计算模型和GAS计算模型各自的优点，降低调度开销的同时，获得相对较快的收敛速度，达到提升整个分布式图处理系统的性能的目的。

在本申请提出的一些实施例中，上述多个计算引擎可以部署在相同或不同的物理服务器或云服务器，实现本申请提出的分布式图处理方法，本申请对计算引擎的部署方法不做限制，可视情况而定。

图存储引擎集群130可以包括多个存储引擎，该存储引擎可以指数据库存储引擎，在数据库管理系统中，可以通过该存储引擎实现数据的创建、查询、更新和删除等操作，不同存储引擎可以提供不同的存储机制、索引机制、锁定水平，还可以提供不同的功能和能力。本申请对存储引擎的结构及其工作原理不做详述。

在本申请实施例中，可以采用分布式索引方式，从图形数据库中，检索目标业务对应的图数据。该图形数据库是一种NoSQL数据库(非关系型数据库)，应用图形理论存储实体之间的关系信息，例如社会网络中人与人之间的关系，相对于关系型数据库，该图形数据能够更好地实现关系型数据的存储，本申请可以将关系型数据称为图数据。

由于图论中的图由若干给定的点及连接两点的线所构成的图形，这种图形通常用来描述某些事物之间的某种特定关系，用点代表事物，用连接两点的线表示相应两个事物间具有这种关系。基于此，本申请实施例种可以采用关系网络(Relation Networks)，也可以称为知识图谱或大规模语义网中的各节点，以及节点之间边所表示的相应节点之间的关系，表示应用场景下的大规模知识。该关系网络中的节点可以表示相应场景下的实体，而节点之间的关系，可以通过对相应实体进行语义分析等方式确定。

本申请实施例中，上述图计算引擎集群按照本申请提出的分布式图处理方法，可以可靠且精准地获得如能源电商数据等相关业务的图计算，得到相应业务的知识图谱，将其反馈至用户客户端输出，并发送至图形数据库进行存储，本申请对知识图谱的存储方法不做限制。

应该理解，图1所示的分布式图处理系统并不对本申请提出的系统架构构成任何限定，在实际应用中，该分布式图处理系统还可以包括比图1所示的更多或更少的设备，或组合设备，如图2所示，该系统还可以包括通信连接上述域控制设备110和图计算引擎集群120的分布式文件系统，以及与图计算引擎集群120中的各计算引擎通信连接的资源管理设备，用于实现对各计算引擎的计算执行资源的灵活配置管理，避免计算引擎负载过大的同时，能够充分利用计算引擎的计算执行资源，避免资源浪费，提高图像计算效率；还可以包括与各存储引擎通信连接的图形数据库等，本申请在此不做一一列举。

结合上文图1和图2所示的分布式图处理系统，以及上文描述的本申请提出的技术构思，下面将对本申请提出的分布式图处理方法进行举例详述，但并不局限于下文各实施例描述的技术方案。

参照图3，为本申请提出的分布式图处理方法的一可选示例的流程示意图，该方法可以适用于上文所述的图计算引擎集群120，如图3所示，该方法可以包括：

步骤S11，接收到针对目标业务的图处理任务，获取目标业务对应的图数据；

结合上文实施例相应部分的描述，目标业务可以是任一应用场景下的数据处理业务，如能源电商数据查询业务等，用户可以通过浏览器发起针对目标业务的图处理任务，如获取能源电商数据的关系网络等，图计算引擎集群接收到该图处理任务后，主计算引擎可以通过存储引擎获取针对该目标业务的图数据，如该目标业务关联的多个实体的实体属性，以及不同实体之间的关系数据等，本申请对图数据的获取过程不做详述。

步骤S12，将图处理任务分解为多个子图处理任务，将多个子图处理任务分发至相应的计算引擎；

由于图处理任务所需计算资源较大，独立的计算引擎很难满足该图处理任务的图计算需求，所以，本申请提出将图处理任务分解为多个子图处理任务，之后，将这多个子图处理任务分发给相应的从计算引擎执行，本申请对该图处理任务分解实现方法不做限制。

在一些实施例中，本申请可以依据所获取的目标业务的图数据进行平均分组，将每一组图数据的图计算任务确定为一个子图处理任务，相当于将图处理任务分解为多个子图处理任务，不同子图处理任务对不同组的图数据进行图计算。

在又一些实施例中，主计算引擎也可以基于多个从计算引擎各自的计算资源(即可使用的计算执行资源)，将图处理任务分解为多个子图处理任务，将多个子图处理任务分发至具有相应计算资源的计算引擎。如可以依据各从计算引擎的负载情况，实现对图处理任务的动态分组，实现过程本申请不做详述。

需要说明，在该又一些实施例中，主计算引擎可以先对图处理任务分组，再由各从计算引擎依据分发到的子图处理任务，通过存储引擎加载相应的图数据，并不局限于上文描述的步骤执行顺序。当然，在图处理任务分组的过程中，还可以结合获取的目标业务对应的图数据，以及各从计算引擎的计算资源实现上述分组，本申请对图处理任务的分组实现方法不做限制。

步骤S13，触发计算引擎响应分发到的子图处理任务，基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果；

如上文对本申请技术构思的相关描述，计算引擎中加载的图计算模型是指BSP-GAS耦合计算模型，即BSP-GAS分布式耦合图处理架构，本申请对该架构的构建方法及其内容不做详述，该计算模型的工作原理可以结合但并不局限于上文分别对BSP和GAS分布式处理架构的工作原理的相关描述，本申请实施例不做赘述。

步骤S14，利用得到的多个子图处理结果，得到图处理任务的图处理结果，将图处理结果反馈至相应的业务客户端。

继上文描述，主计算引擎得到相应从计算引擎反馈的子图处理结果后，可以将各子图处理结果合并，得到图处理任务的图处理结果，如能源电商的关系网络/知识图谱等，可以将其反馈至用户发起图处理任务的浏览器，即业务客户端进行展示，方便用户由此直观得知能源电商中的各实体，以及不同实体的不同维度的信息等。

综上，本申请计算引擎响应子图处理任务，将基于BSP-GAS耦合计算模型对该子图处理任务对应的图数据进行同步迭代的图处理，即利用BSP计算模型和GAS计算模型各自的优点实现图计算，降低迭代计算过程中产生的网络传输和调度开销的同时，获得了相对较快的收敛速度，提升了整个分布式图处理系统的性能，使其能够适用于多种类型图处理任务应用场景。

参照图4，为本申请提出的分布式图处理方法的又一可选示例的流程示意图，该方法可以包括：

步骤S21，接收到针对目标业务的图处理任务，获取目标业务对应的图数据；

步骤S22，依据多个计算引擎各自的计算资源，将图处理任务分解为多个子图处理任务，将多个子图处理任务分发至具有相应计算资源的计算引擎；

按照本申请实施例提出的基于各计算引擎当前可使用的计算资源，实现对图处理任务动态分解，将分解后的子图处理任务分配给具有与其相匹配的计算资源的计算引擎，避免计算引擎超负载工作或计算资源浪费，之后，各计算引擎(本实施例主要是指从计算引擎)可以依据分发到的子图处理任务对应的图数据(为了方便描述，可以将其记为子图数据)，构建其与该计算引擎之间的映射关系，以使计算引擎后续可以依据该映射关系实现图计算。

基于上述分析，在一种可能的实现方式中，可以由主计算引擎实现对图数据的分割，以及对多个从计算引擎的管理和配置，对于目标业务对应的图数据中的各图节点，每一个图节点配置有唯一对应的索引号，且在完成上述分解后，可以获取各图节点具有的索引号，与相应图节点被分发到的计算引擎的IP地址之间的第一映射关系，本申请对该第一映射关系的表示方式不做限制。

可选的，对于每一个从计算引擎的标识，可以采用32无符号整型(uint32)表示，所以，在获取各从计算引擎的IP地址后，可以将其转换成整型，将其添加至索引结构的首位，由此表示图节点映射到哪个计算引擎，即确定相应的第一映射关系，这样，在实际应用中，通过图节点的索引号中的首位，可以确定该图节点位于哪个计算引擎上。

此外，在实际工作过程中，一个计算引擎可能会创建一个或多个从计算进程，为了避免同一主机的不同从计算进程之间的干扰，可以获取不同从计算进程的进程信息，将其添加至索引号中，如使用16比特位存储进程信息。因此，本申请可以通过这种处理方式，获取各图节点具有的索引号，与用于构建相应图节点的图数据的进程的进程信息之间的第二映射关系，这样，通过该索引号中的进程信息，即查询该第二映射关系，可以准确且快速确定用于构建该图节点数据结构的进程。且依据上述第一映射关系和第二映射关系，可以准确获取目标图节点(即目标业务对应的任一图节点，如目标业务关联的任一实体)映射的目标进程下的目标图数据，如该实体属性和关系数据等。

另外，为了通过节点ID快速查找到目标进程下构建的图数据，即该图节点数据结构，可以预先定义具有字典，来表示不同节点ID哈希值与不同图节点之间的第三映射关系，这样，对于各子图处理任务对应的图数据，可以采用具有哈希链表结构的字典进行存储索引，本申请对该字典的定义方式及其包含的key值(即图节点哈希值)的获取方法不做详述，对于字典的value值可以为图节点对象。

其中，若检测到多个图节点的节点ID哈希值相同，可以在字典中配置这多个图节点各自对应的随机标识码，也就是说，字典中的多个节点ID哈希值产生冲突，可以产生一个32位的随机数来标识这两个不同的图节点，但并不局限于这种随机标识码的生成方式。

步骤S23，触发多个计算引擎执行分发到的子图处理任务，获取各计算引擎对应缓存的节点状态信息；

本申请实施例中，为了方便描述，可以将执行图计算的各计算引擎记为计算节点，呈分布式结构布局。结合上文对计算引擎实现的BSP-GAS耦合计算模型的相关描述，GAS计算模型的粒度不同于Pregel的超步，而是将超步再次划分为子步，参照图5所示的超步中子步的状态机转换流程示意图，本申请在图计算过程中，以子步为计算粒度，由Gather、Apply和Scatter三个子步组成一个超步。

其中，Gather/Scatter函数是以单条边为操作粒度，那么对于一个顶点(即图节点)的众多邻边，可以分别由相应的worker独立地调用Gather/Scatter函数，满足点分割的图存储模式的图处理，从而避免Pregel模型会遇到的问题。

基于上述分析，本申请提出采用PowerGraph的变量缓存的策论对Gather-Apply-Scatter计算模型进行优化，可以对每个计算节点在内存中增设一个缓冲器Accumulator，用于缓存该计算节点的状态信息，以便通过判断缓存的节点状态信息，控制定点程序的执行逻辑，并对缓冲器中无更新的计算节点，直接跳过上述Gather子步阶段的操作，从而减少网络通信开销和计算循环。

因此，本申请可以基于上述构思，预先配置相应的增量缓存策略，以便在实际应用中，按照预设的增量缓存策略，依据节点状态信息，检测下一次超步迭代计算过程中是否提取相应计算节点的更新数据，解决了传统的GAS计算模型对多个计算节点的每一次迭代计算过程中，都要执行上述三个子步操作，导致网络通信和计算开销大的技术问题。

步骤S24，依据该节点状态信息，确定相应计算引擎是否已得到相邻计算引擎的增量；若是，进入步骤S25；若否，执行步骤S26；

步骤S25，执行针对该计算引擎的GAS处理逻辑过程中，从该计算引擎的节点状态信息中，获取该计算引擎的相邻计算引擎的增量；

步骤S26，执行针对该计算引擎的GAS处理逻辑，从该计算引擎的相邻计算引擎提取该相邻计算引擎的增量；

步骤S27，更新该计算引擎的节点状态信息，并将本次超步迭代计算得到的该计算引擎的更新增量推送至相邻计算引擎，以更新相应相邻计算引擎的节点状态信息。

示例性的，本申请以相邻计算节点u和v之间实现增量缓存策略的过程为例进行说明，Au和Av分别表示计算节点u和计算节点v对应的缓冲器。参照图6所示的相邻两次超步迭代计算，计算节点u和计算节点v的节点状态信息的变化示意图，假设第i次超步迭代计算，计算节点u和计算节点v的初始节点状态信息均为空，即Au＝empty，Av＝empty，若先对计算节点u执行GAS处理逻辑，计算节点u可以Gather操作和Apply操作，将自身缓存的节点状态信息更新为A'u。在Scatter阶段计算节点u将根据用户自定义的sum函数，将本轮超步中计算节点u的更新增量Δu推送给相邻计算节点v，推送完成之后，计算节点v对应的缓存的节点状态信息Av更新为Av+Δu。

可见，在第i次超步迭代计算过程中，计算节点u将自身的增量传递给了计算节点v，这样，在第i+1次超步迭代计算过程中，计算节点v可以不执行Gather阶段，直接从其节点状态信息Av中提取计算节点u的增量Δu。这种增量缓存策略应用到节点规模较大的场景下，可以减少大部分计算节点的Gathe子步操作，达到减少对应的跨计算节点通讯和计算的开销。

在本申请提出的一些实施例中，在上述多个计算引擎的图处理过程中，可以通过消息传递机制，实现不同超步迭代计算的同步，本申请对该消息传递机制的内容不做限制。

本申请实施例中，对于上述图处理过程中涉及到的消息类型可以分为信令消息和数据消息两大类。该信令消息可以用于主计算引擎向所有的从计算引擎发送超级步信令，并启动从计算引擎的进程中的活跃节点执行自定义函数；还可以用于从计算引擎向主计算引擎传递本地执行节点信令；还可以用于主计算引擎向从计算引擎的进程发送活跃节点的数量的请求信令，并返回在超级步<5，所有的消息传递结束后，本机从计算进程存在的活跃节点数量，用于实现对相应从计算引擎的计算资源计算，实现对不同计算引擎分配相适应的计算执行资源。上述数据消息主要负责实现主计算引擎和各从计算引擎之间，以及不同从计算引擎之间的数据传输，实现过程本申请不做详述。

对于图数据中不同图节点之间的消息传递，可以图之间传递消息分为多种操作类型和多个图对象。示例性的，该图对象可以包括全局图网络，计算引擎的目标进程、目标图节点以及不同图节点之间的目标图边。也就是说，对全局网络进行的操作的消息，例如主计算引擎为每个节点赋一个初始的变量，或者从计算引擎向主计算引擎节点发送消息；对目标从计算进程中的节点集操作消息，例如主计算引擎针对特性slave进程的节点发送一个消息值，获取该从计算进程中的极大度值；对目标图节点操作消息；对目标图边的操作消息等。

上述不同的操作类型可以包括对图节点或者边的添加操作；对图节点或者边的删除操作；设置图节点或者边属性；获取如节点或者边属性。也就是说，图节点和/或图边的添加操作、删除操作、属性配置操作、属性获取操作等四种操作类型，根据需要还可以进行配置，并不局限于本实施例描述内容。

在消息传递过程中，本申请可以构造公共消息数据结构Message，其中的变量Object为消息的操作对象，Action代表具体的方法，Target是消息传递的目标。在实际应用中，该目标可能是一台主机、一个进程或者一个节点；Value可以是具体的消息内容，如int、float、string、byte等其中的任一简单类型，还可以是多种消息组成而成的复合类型的消息。

在实际的消息传递过程，检测到待传输消息为多个消息类型构成的复合消息，将复合消息压缩为字符数组，再将字符数组发送至目标对象，由目标对象通过预设数据转换格式(如JSON格式)，将字符数组转换为相应的数据结构；其中，该目标对象可以为计算引擎、计算引擎中的任一进程或图数据中的任一图节点等，可视情况而定。

参照图7，为本申请提出的分布式图处理装置的一可选示例的结构示意图，该装置可以包括：

数据获取模块210，用于接收到针对目标业务的图处理任务，获取所述目标业务对应的图数据；

任务分解模块220，用于将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的计算引擎；

图处理模块230，用于触发所述计算引擎响应分发到的所述子图处理任务，基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果；其中，所述图计算模型是指整体同步并行BSP-定点程序GAS耦合计算模型；

图处理结果得到模块240，用于利用得到的多个子图处理结果，得到所述图处理任务的图处理结果，将所述图处理结果反馈至相应的业务客户端。

可选的，上述图处理模块230可以包括：

节点状态信息获取单元，用于获取所述多个计算引擎执行分发到的所述子图处理任务各自缓存的节点状态信息；

检测单元，用于按照预设的增量缓存策略，依据所述节点状态信息，检测下一次超步迭代计算过程中是否提取相应计算引擎的更新数据；

更新单元，用于依据检测结果，执行针对相应计算引擎的GAS处理逻辑，更新该计算引擎的所述节点状态信息；

更新增量传输单元，用于将本次超步迭代计算得到的该计算引擎的更新增量推送至相邻计算引擎，以更新相应所述相邻计算引擎的节点状态信息。

可选的，上述检测单元可以包括：

增量确定单元，用于依据所述节点状态信息，确定相应计算引擎是否已得到相邻计算引擎的增量；

上述更新单元可以包括：

第一增量提取单元，用于在未得到相邻计算引擎的增量的情况下，执行针对该计算引擎的GAS处理逻辑，从该计算引擎的相邻计算引擎提取该相邻计算引擎的增量；

第二增量提取单元，用于在得到相邻计算引擎的增量的情况下，执行针对该计算引擎的GAS处理逻辑过程中，从该计算引擎的节点状态信息中，获取该计算引擎的相邻计算引擎的增量。

在一些实施例中，上述任务分解模块220可以包括：

分解单元，用于依据多个计算引擎各自的计算资源，将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至具有相应计算资源的计算引擎。

第一映射关系获取单元，用于对于所述目标业务对应的图数据中的各图节点，获取所述各图节点具有的索引号，与相应图节点被分发到的计算引擎的IP地址之间的第一映射关系；

第二映射关系获取单元，用于若所述计算引擎创建多个进程，获取所述各图节点具有的索引号，与用于构建相应图节点的图数据的所述进程的进程信息之间的第二映射关系；

目标图数据获取单元，用于依据所述第一映射关系和所述第二映射关系，获取目标图节点映射的目标进程下的目标图数据。

其中，上述子图处理任务对应的图数据是采用具有哈希链表结构的字典进行存储索引；所述字典表示不同节点ID哈希值与不同图节点之间的第三映射关系；

基于此，上述装置还可以包括字典配置单元，用于检测到多个图节点的节点ID哈希值相同，在所述字典中配置这多个图节点各自对应的随机标识码。

在又一些实施例中，上述装置还可以包括：

消息传输模块，用于在不同的所述计算引擎的图处理过程中，通过消息传递机制，实现不同超步迭代计算的同步；

其中，所述消息传递机制包括通过不同类型消息，实现针对不同图对象的不同类型操作；所述不同类型消息包括信令消息和数据消息；所述不同图对象包括全局图网络、计算引擎的目标进程、目标图节点以及不同图节点之间的目标图边；所述不同类型操作包括图节点和/或图边的添加操作、删除操作、属性配置操作、属性获取操作。

可选的，上述装置还可以包括：

复合消息处理模块，用于检测到待传输消息为多个消息类型构成的复合消息，将所述复合消息压缩为字符数组；

消息传输处理单元，用于将所述字符数组发送至目标对象，由所述目标对象通过预设数据转换格式，将所述字符数组转换为相应的数据结构；所述目标对象为所述计算引擎、所述计算引擎中的任一进程或所述图数据中的任一图节点。

需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

本申请还提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现上述分布式图处理方法的各步骤，具体实现过程可以参照上述分布式图处理方法实施例相应部分的描述。

本申请还提出的一种适用于上述分布式图处理方法得计算机设备，该计算机设备可以是物理服务器或云服务器等，可以包括至少一个存储器和至少一个处理器，其中：

存储器可以用于存储实现上述分布式图处理方法的程序；处理器可以用于加载执行存储器存储的程序，实现上述分布式图处理方法的各步骤。

在本申请实施例中，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。处理器，可以为中央处理器(Central Processing Unit，CPU)、特定应用集成电路(application-specificintegrated circuit，ASIC)、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件等。

应该理解的是，上文描述的计算机设备的结构并不构成对本申请提出的计算机设备的限定，在实际应用中，计算机设备可以包括更多的部件，或者组合某些部件，如各种通信模块等，本申请在此不做一一列举。

最后，需要说明的是，关于上述各实施例中，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

本申请涉及到的术语诸如“第一”、“第二”等仅用于描述目的，用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。且不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量，由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

另外，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种分布式图处理方法，其特征在于，所述方法包括：

接收到针对目标业务的图处理任务，获取所述目标业务对应的图数据；

将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的计算引擎；

触发所述计算引擎响应分发到的所述子图处理任务，基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果；其中，所述图计算模型是指整体同步并行BSP-定点程序GAS耦合计算模型；

利用得到的多个子图处理结果，得到所述图处理任务的图处理结果，将所述图处理结果反馈至相应的业务客户端。

2.根据权利要求1所述的方法，其特征在于，所述基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果，包括：

获取所述多个计算引擎执行分发到的所述子图处理任务各自缓存的节点状态信息；

按照预设的增量缓存策略，依据所述节点状态信息，检测下一次超步迭代计算过程中是否提取相应计算引擎的更新数据；

依据检测结果，执行针对相应计算引擎的GAS处理逻辑，更新该计算引擎的所述节点状态信息，并将本次超步迭代计算得到的该计算引擎的更新增量推送至相邻计算引擎，以更新相应所述相邻计算引擎的节点状态信息。

3.根据权利要求2所述的方法，其特征在于，所述按照预设的增量缓存策略，依据所述节点状态信息，检测下一次超步迭代计算过程中是否提取相应计算引擎的更新数据，包括：

依据所述节点状态信息，确定相应计算引擎是否已得到相邻计算引擎的增量；

所述依据检测结果，执行针对相应计算引擎的GAS处理逻辑，包括：

若未得到相邻计算引擎的增量，执行针对该计算引擎的GAS处理逻辑，从该计算引擎的相邻计算引擎提取该相邻计算引擎的增量；

若得到相邻计算引擎的增量，执行针对该计算引擎的GAS处理逻辑过程中，从该计算引擎的节点状态信息中，获取该计算引擎的相邻计算引擎的增量。

4.根据权利要求1～3任一项所述的方法，其特征在于，所述将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的计算引擎，包括：

依据多个计算引擎各自的计算资源，将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至具有相应计算资源的计算引擎。

5.根据权利要求4所述的方法，其特征在于，所述将所述多个子图处理任务分发至具有相应计算资源的计算引擎，包括：

对于所述目标业务对应的图数据中的各图节点，获取所述各图节点具有的索引号，与相应图节点被分发到的计算引擎的IP地址之间的第一映射关系；

若所述计算引擎创建多个进程，获取所述各图节点具有的索引号，与用于构建相应图节点的图数据的所述进程的进程信息之间的第二映射关系；

依据所述第一映射关系和所述第二映射关系，获取目标图节点映射的目标进程下的目标图数据。

6.根据权利要求5所述的方法，其特征在于，所述子图处理任务对应的图数据是采用具有哈希链表结构的字典进行存储索引；所述字典表示不同节点ID哈希值与不同图节点之间的第三映射关系；

若检测到多个图节点的节点ID哈希值相同，在所述字典中配置这多个图节点各自对应的随机标识码。

7.根据权利要求1～3任一项所述的方法，其特征在于，在不同的所述计算引擎的图处理过程中，通过消息传递机制，实现不同超步迭代计算的同步；

其中，所述消息传递机制包括通过不同类型消息，实现针对不同图对象的不同类型操作；所述不同类型消息包括信令消息和数据消息；所述不同图对象包括全局图网络、计算引擎的目标进程、目标图节点以及不同图节点之间的目标图边；所述不同类型操作包括图节点和/或图边的添加操作、删除操作、属性配置操作、属性获取操作。

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

检测到待传输消息为多个消息类型构成的复合消息，将所述复合消息压缩为字符数组；

将所述字符数组发送至目标对象，由所述目标对象通过预设数据转换格式，将所述字符数组转换为相应的数据结构；所述目标对象为所述计算引擎、所述计算引擎中的任一进程或所述图数据中的任一图节点。

9.一种分布式图处理系统，其特征在于，所述系统包括域控制设备、图计算引擎集群以及图存储引擎集群，其中：

所述域控制设备，用于接收接入相应域网络的客户端发送的针对目标业务的图处理任务；

所述图存储引擎集群包括多个存储引擎，所述存储引擎用于查询相应数据库中所述目标业务对应的图数据；

所述图计算引擎集群包括主计算引擎和多个从计算引擎：

所述主计算引擎，用于获取所述目标业务对应的图数据，将所述图处理任务分解为多个子图处理任务，将所述多个子图处理任务分发至相应的从计算引擎；

所述从计算引擎，用于响应分发到的所述子图处理任务，基于图计算模型，对该子图处理任务对应的图数据进行同步迭代的图处理，得到相应的子图处理结果，发送至所述主计算引擎；其中，所述图计算模型是指整体同步并行BSP-定点程序GAS耦合计算模型；

所述主计算引擎，用于利用得到的多个子图处理结果，得到所述图像处理任务的图处理结果，通过所述域控制设备将所述图处理结果反馈至所述客户端。

10.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器加载执行，实现如权利要求1～8任一项所述的分布式图处理方法。

Images