CN115562676A - 一种图计算引擎的触发方法 - Google Patents

Abstract

本发明提供了一种图计算引擎的触发方法，属于图计算技术领域，解决了现有图计算引擎的编译过程执行效率较差的问题。触发方法包括：接收OpenCypher操作指令；启动Cypher编译器，对OpenCypher操作指令进行语法及语义解译，将解译后的OpenCypher操作命令编译为分布式逻辑执行计划，并根据分布式逻辑执行计划生成在分布式环境下执行的物理执行计划；向GraphMaster进行注册并申请资源；GraphMaster根据物理执行计划获取待执行任务，将待执行任务分解成多个一级任务，并将各一级任务分配给不同的GraphSlave；GraphSlave将接收到的一级任务分解成多个二级任务，并将各二级任务分配给不同的Worker，由Worker执行相应二级任务；所有待执行任务完成后，向GraphMaster申请资源注销，等待接收下一次OpenCypher操作指令。

Description

一种图计算引擎的触发方法

技术领域

本发明涉及图计算技术领域，尤其涉及一种图计算引擎的触发方法。

背景技术

图计算是人工智能的一个使能技术。大致将人工智能的基本能力分成三个部分，第一部分就是理解的能力，第二部分是推理的能力，第三部分就是学习的能力，简称URL(Understanding，Reasoning，Learning)。而图计算是与URL息息相关的，举例来说，要对整个现实世界有一个客观、完整、全面的认识，那就需要一个理解的能力。图计算技术能够把任何事物之间的所有关系全部刻画出来，完整地描述出来。图计算被业界视为下一代人工智能的重要基石，它是人工智能从数据驱动的感知智能向认知智能转变理解语义关联的关键。

目前，图计算引擎的编译过程执行效率往往很差，严重影响了图计算引擎的触发效率，限制了图计算引擎的使用范围。

发明内容

鉴于上述的分析，本发明实施例旨在提供一种图计算引擎的触发方法，用以解决现有图计算引擎的编译过程执行效率较差的问题。

本发明提供了一种图计算引擎的触发方法，包括：

接收OpenCypher操作指令；

启动Cypher编译器，对OpenCypher操作指令进行语法及语义解译，将解译后的OpenCypher操作命令编译为分布式逻辑执行计划，并根据所述分布式逻辑执行计划生成在分布式环境下执行的物理执行计划；

向GraphMaster进行注册并申请资源；GraphMaster根据物理执行计划获取待执行任务，将待执行任务分解成多个一级任务，并将各一级任务分配给不同的GraphSlave；

GraphSlave将接收到的一级任务分解成多个二级任务，并将各二级任务分配给不同的Worker，由Worker执行相应二级任务；

所有待执行任务完成后，向GraphMaster申请资源注销，等待接收下一次OpenCypher操作指令。

在上述方案的基础上，本发明还做出了如下改进：

进一步，所述方法还包括：在Worker执行相应二级任务过程中，通过图计算引擎中的RestAPI接口模块提供的标准RESTful接口，获取图计算状态、执行图数据的增删改查、以及构建符合业务模型的图算法。

进一步，所述方法还包括：在Worker执行相应二级任务的过程中，通过图计算引擎中的分布式图存储引擎模块对图数据进行管控及数据处理操作。

进一步，在Worker执行相应二级任务的过程中，通过图计算引擎中的原生图存储格式模块将所述图数据以高效的压缩格式存储于所述分布式图数据库系统中。

进一步，所述根据所述分布式逻辑执行计划生成在分布式环境下执行的物理执行计划，包括：

根据预设的过滤条件，对所述分布式逻辑执行计划进行优化；

对所述优化后的分布式逻辑执行计划进行物理映射，生成在分布式环境下执行的物理执行计划。

进一步，在所述图计算引擎中，通过OpenCypher接口模块接收所述OpenCypher操作指令，以实现对图计算引擎的访问。

进一步，所述OpenCypher接口模块还用于提供图函数计算功能；所述图函数包括基础函数、聚合函数、数学函数、字符串操作函数、集合操作函数以及crux-cypher内部函数。

进一步，在Worker执行相应二级任务的过程中，通过图计算引擎中的分布式图执行引擎模块为用户提供实时图查询和离线图分析服务；

所述分布式图执行引擎模块采用GraphMaster-Slave架构。

进一步，在所述GraphMaster-Slave架构中，

GraphWorker节点由GraphSlave节点管理；

用户的OpenCypher接口与图计算引擎交互过程中的信息流分为控制流信息和数据流信息；其中，GraphMaster和GraphSlave节点之间交互所述控制流信息；用户上传的所述数据流信息不经过GraphMaster节点进行转发，直接发送给GraphSlave节点进行处理。

进一步，所述GraphWorker节点是由GraphSlave节点使用fork和exec函数拉起的进程；

所述GraphWorker节点的职责有：

根据GraphSlave的任务拓扑信息，和相应的GraphWorker节点建立上下游关系；

执行GraphSlave节点下发的任务信息，接收GraphSlave节点发送的动态链接库的位置信息，调用动态链接库模块中的dlopen系列函数拉起.so文件；

接收上游GraphWorker节点发送的数据，调用用户自定义代码进行数据处理，并将处理后的数据发送到下游节点或者放到本地存储当中；

向GraphSlave节点汇报本节点的资源使用情况和任务执行情况。

与现有技术相比，本发明至少可实现如下有益效果之一：

本发明提供的图计算引擎的触发方法，通过改进Cyper编译器的编译方式，增加过滤流程，有效提升了编译过程的执行效率，解决了现有图计算引擎的触发过程在编译性方面的问题，有效提升了编译效果。同时，通过改进分布式图存储引擎模块的架构，借助图分区算法改变原生图存储格式，有效提升了图数据的存储速率，解决了现有图计算引擎在存储性方面的问题。

本发明中，上述各技术方案之间还可以相互组合，以实现更多的优选组合方案。本发明的其他特征和优点将在随后的说明书中阐述，并且，部分优点可从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过说明书以及附图中所特别指出的内容中来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明实施例提供的图计算引擎的触发方法流程图；

图2为本发明实施例提供的图计算引擎的结构示意图；

图3为本发明实施例提供的分布式图存储引擎模块的组成示意图；

图4为本发明实施例提供的分布式图存储引擎模块的存储层的内部协作关系示意图；

图5为本发明实施例提供的LSM Tree的存储结构示意图；

图6为本发明实施例提供的分布式图执行引擎模块的结构示意图；

图7为本发明实施例提供的另一种图计算引擎的结构示意图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理，并非用于限定本发明的范围。

本发明的一个具体实施例，公开了一种图计算引擎的触发方法，流程图如图1所示，包括以下步骤：

步骤S1：接收OpenCypher操作指令；

步骤S2：启动Cypher编译器，对OpenCypher操作指令进行语法及语义解译，将解译后的OpenCypher操作命令编译为分布式逻辑执行计划，并根据所述分布式逻辑执行计划生成在分布式环境下执行的物理执行计划；

步骤S3：向GraphMaster进行注册并申请资源(CPU Core和Memory)；GraphMaster根据物理执行计划获取待执行任务，将待执行任务分解成多个一级任务，并将各一级任务分配给不同的GraphSlave；

步骤S4：GraphSlave将接收到的一级任务分解成多个二级任务，并将各二级任务分配给不同的Worker，由Worker执行相应二级任务；在此过程中，Worker还向GraphMaster发送任务监控报告。

步骤S5：所有待执行任务完成后，向GraphMaster申请资源注销，等待接收下一次OpenCypher操作指令。

当接收到下一次OpenCypher操作指令时，跳转到步骤S1，并重复执行步骤S1-S5。

在步骤S3中，GraphMaster还负责执行系统的总体控制状态。

在步骤S4的执行过程中，还同时执行以下内容：

Worker向GraphMaster发送任务监控报告；

通过图计算引擎中的原生图存储格式模块将所述图数据以高效的压缩格式存储于所述分布式图数据库系统中；

通过图计算引擎中的RestAPI接口模块提供的标准RESTful接口，获取图计算状态、执行图数据的增删改查、以及构建符合业务模型的图算法；

通过图计算引擎中的分布式图执行引擎模块为用户提供实时图查询和离线图分析服务。

需要强调的是，图计算引擎的触发过程基于如下图计算引擎实现，图计算引擎的结构示意图如图2所示，包括：

分布式图存储引擎模块，采用“多Master-多Worker”的方式构建分布式图数据库系统，用于对图数据进行管控及数据处理操作；

Cyper编译器，用于实现标准OpenCypher语言的语法及语义解译；还用于将解译后的OpenCypher操作命令编译为分布式逻辑执行计划，并根据分布式逻辑执行计划生成在分布式环境下执行的物理执行计划；

分布式图执行引擎模块，用于为用户提供实时图查询和离线图分析服务；

图分析算法模块，集成多种分布式图计算算法和深度学习图算法，用于构建图谱挖掘模型；

OpenCypher接口模块，用于实现用户通过扩展的openCypher语言访问图计算引擎。

此外，本实施例提供的图计算引擎还包括RestAPI接口模块和原生图存储格式模块；其中，

RestAPI接口模块提供标准RESTful接口，用于获取图计算状态、执行图数据的增删改查、以及构建符合业务模型的图算法。

原生图存储格式模块，用于借助图分区算法，将所述图数据以高效的压缩格式存储于所述分布式图数据库系统中。

下面，对本实施例提供的图计算引擎中的各个模块做如下介绍：

(1)分布式图存储引擎模块

采用“多Master-多Worker”，其中，多个Master组成Master Group，用于负责元信息管理、任务调度、负载均衡等功能；Worker作为图数据的实际存储角色，用于提供数据处理操作，所述数据处理操作包括图数据的读取、更新(含“写入”)和删除。存储引擎通过Raft协议来保证数据一致性和高可用性。分布式图存储引擎模块的组成示意图如图3所示。

为了保证分布式系统的容错能力和高可用性，需要分别对Master和Worker提供额外设计。对于Master而言，由于数据都是Worker汇报所得，因此，由多个Master进程组成的HA Group就可以满足高可用性。而对于提供数据读写服务的Worker而言，进程、磁盘或服务器的故障会导致图数据无法读取和写入，从而导致图数据不可用问题。

为了解决这个问题，分布式图存储引擎模块在进行数据处理操作过程中，将图数据划分为多个分区，每个Worker的最小逻辑存储单元为一个分区。对于每个分区，挑选若干(3个或更多)Worker作为宿主。分区的多个副本之间通过Raft协议管理数据的一致性。

Raft协议是一个提供最终一致性的协议，相较于HDFS的强一致性，Raft协议能够带来较低的数据延迟；相较于Paxos协议而言，Raft协议更容易理解和维护。

Raft协议的工作机制介绍：

存储层承接消息处理模块的读写请求，完成异步处理后发送回复。存储层同时提供越过正常请求机制的存储接口，以实现提高计算速度的底层优化。

存储层内部包含了基于Raft一致性协议的多副本热备份功能，使得一份写入请求可以应用到多台主机上。当一台主机失效，上层的消息处理模块可以检测到失效的发生，从而将Master地位的主机进行切换，使得客户的读写请求处理不受影响。

存储层直接通过文件系统控制对磁盘的读写。存储模块拥有对多块磁盘的使用率平衡功能，使各块磁盘的负载比较均匀，避免负载不均带来的请求处理瓶颈。

分布式图存储引擎模块的存储层的内部协作关系示意图如图4所示。其中，箭头表示了单台主机写入数据的流动过程。这里以写入过程为例说明图处理计算引擎存储模块内部各类的交互过程。

首先，上层的消息处理模块把封装为写入事件的数据发送给GraphDB。在分布式图存储引擎模块中，数据库的每一个图对应一个GraphDB实例。为了实现上文提到的磁盘读写均衡功能，每一个图被划分成多个GraphShard，而数据记录会被按照其哈希值分配到对应的GraphShard中。同一张图的不同GraphShard可以拥有不同磁盘上的的数据存储路径。这样就通过数据的分桶实现了磁盘的充分利用。

分布式图存储引擎模块中的多副本备份的单位就是GraphShard。在GraphShard类中，包含了Raft消息同步机制。Raft帮助GraphShard将从GraphDB收到的写入事件在多个主机的同一个GraphShard之间进行同步。所以GraphShard并不会在收到GraphDB传来的写入事件之后立即将事件解析为写入数据。写入动作实际上是由Raft master在集群间同步的写入事件触发的。

为了保证多副本数据最终状态一致，图处理计算引擎使用Raft一致性协议作为多副本的协调机制，并利用Raft的日志(log)来短期备份写入的数据。

Raft是分布式存储一致性算法。在分布式系统中，为了防止服务器数据由于只存一份而导致在服务时由于一个存储节点故障就产生服务完全不可用或数据丢失的严重后果，数据的存储会有多个备份副本，分别存储于不同的存储服务器上，都可以提供服务。这样一来，如果有合适的算法能保障各服务器对同一份数据存储的内容一致，并且在一台服务的存储服务器故障时，这个集群能以适当的逻辑切换到其他正常服务器提供服务，那么就可以实实在在地保障分布式存储服务的质量。Raft就是为这样的系统服务的。

存储一致性根据对于各个服务器的同一份数据之间允许差异的严格程度不同，可以分为强一致性、最终一致性、弱一致性。根据“CAP定理”，一个分布式系统不能同时保障一致性(Consistency)、可用性(Availability)与分区容错性(Partition tolerence)。但是经过权衡，系统可以达到“BASE”效果：基本可用(Basically available)、软状态(Softstate)、最终一致性(Eventually consistent)。Raft所达到的最终一致性，是指各节点上的数据在经过足够的时间之后，最终会达到一致的状态。

Raft集群各机之间的RPC报文可分为两种：添加条目RPC(AppendEntriesRPC，以下简称AE)与请求投票RPC(RequestVote RPC，以下简称RV)。AE是leader用来向follower加entry使用的。RV是“候选人”(candidate，是除了leader、follower以外的第三种状态，只出现于选举时)用来向其他follower要求给自己投票的。

如果超过一定时间，follower检测不到来自leader的周期性心跳消息(leader将不含实际entry的AE作为心跳使用)，就会变为candidate状态。此时，Raft集群就会开始选举leader。在Raft中，时间上有着term的概念，表示一个leader的统治期；每个term有着独特的递增的序号，称为term ID。leader会在自己发送的AE中都附上自己的term ID。当新的candidate产生，它会在上一个leader的term ID基础上加1，作为自己的term ID，并在广播给所有其他机的RV中也附上新的termID。任何非candidate的节点收到了带有比自己已经见过的任何ID更大的termID的RV时，就会回复这个RV，并更新“自己已经见过的最大ID”。如果同时这个RV中说明的candidate含有的日志足够新(详细说明见下一小节)，follower就会为这个candidate投票。这样一来，任何节点就都不会为同一个term ID投两票。

如果一个candidate收到了足够的票数(票数加上自己的一票能够占集群的多数)，就会开始发送心跳，宣告自己在这个term内的leader地位，开始服务。由于在一个leader失效时，可能有多个follower超时的时刻相同，发出RV广播的时刻也大致相同，结果在新term都得不到足够的票数，所以candidate存在等票超时与随机等待机制，避免一致冲突，选不出leader。candidate在等足够的票时当然也会看有没有其他candidate宣布胜利。如果都没有发生的话，在一段超时后，candidate们会再开启新term ID，但会随机等待一段时间，然后才广播RV请求投票(广播RV前相当于follower，可以投票)。由于随机等待的时间有长有短，最终一定会由率先结束等待的candidate获胜。

Raft集群由leader统一处理所有客户端请求，会将写请求转换为log entry，然后用AE向follower发送来复制log。Leader创建日志条目时，会给它附上两个属性：term ID与log index。term ID即为自己统治期的ID，在当前term的日志条目都用这个ID；而logindex也是一种递增序号，但它是在集群的整个运行期间连续的。跨term时，log index会在前面的的基础上递增1，而非归零重计。如此一来，考虑到选举机制保证了一个term ID一定对应确定的一个leader节点，我们由term ID+log index这个组合就一定可以确定唯一的一条日志。

Leader生成了写操作的日志之后，就通过AE将日志条目发送到各个follower处，让它们把日志按早晚顺序加入自己的日志存储中。如果有集群多数的节点(包含leader自己)都成功存储了一条日志(follower会回复自己的存储情况)，那么leader就认为这条日志及更早的日志的存储都是安全的，会回复客户端写操作成功，并会告知集群已经可以将到此条的所有日志中的写操作实际进行，修改自己的存储数据。

当leader上台时，会以自己的日志存储为准，使其他节点与自己对齐。如果比自己快，就截掉多的；比自己慢，就用自己的日志存储给它慢慢补足。但是在复制日志的过程中，各个follower可能因各种原因速度差异较大。那么如果leader突然故障，而一个复制的特别慢的follower选举为leader，就可能会导致大量写操作失效。之所以要保证日志已经复制到了多数机上，才可认为写操作成功，就是为了避免这种情况。之前在讲解选举机制时提到：RV要包含candidate的日志存储版本消息，也就就是最后一条日志的term ID+logindex。如果投票的follower发现这candidate的版本消息比自己的还要旧，就会拒绝给它投票。由于只有复制到了多数节点的日志的写操作才被回报为成功，而选举时必须要获得多数票才能当选，所以最终当选的leader一定拥有上一个leader所回报为成功的操作的所有日志，不会缺失。

(2)原生图存储格式模块

通过原生图存储格式模块，可以将图数据按策略分散存储于集群中，拥有良好的可扩展性，并具备存储任意规模图的理论能力。

工作机制：

利用LSM Tree(Log Structured Merge Tree)作为图数据的存储模型，实现较高的写入速度。

BTree将磁盘看成固定大小的页，页是读写的最小单元。一个页面指向其他的一些页面，并形成一个高扇出(出度高)的树状结构。由于数据是按块存储的，BTree在新增数据或删除数据的时候，很可能会出现一个页面放不下，或者多个页面数据稀疏的情况，这时候就会发生「页分裂」和「页合并」操作，因此不适合海量图数据存储操作，而LSM Tree不是面向页的操作，其能更好的利用顺序写的优势，写入通常更快。LSM Tree的存储结构如图5所示，其中，LSM Tree有以下三个重要组成部分。

1)MemTable

MemTable是在内存中的数据结构，用于保存最近更新的数据，会按照Key有序地组织这些数据，LSM树对于具体如何组织有序地组织数据并没有明确的数据结构定义，例如Hbase使跳跃表来保证内存中key的有序。

因为数据暂时保存在内存中，内存并不是可靠存储，如果断电会丢失数据，因此通常会通过WAL(Write-ahead logging，预写式日志)的方式来保证数据的可靠性。

2)Immutable MemTable

当MemTable达到一定大小后，会转化成Immutable MemTable。ImmutableMemTable是将转MemTable变为SSTable的一种中间状态。写操作由新的MemTable处理，在转存过程中不阻塞数据更新操作。

3)SSTable(Sorted String Table)

有序键值对集合，是LSM树组在磁盘中的数据结构。为了加快SSTable的读取，可以通过建立key的索引以及布隆过滤器来加快key的查找。

LSM树(Log-Structured-Merge-Tree)正如它的名字一样，LSM树会将所有的数据插入、修改、删除等操作记录(注意是操作记录)保存在内存之中，当此类操作达到一定的数据量后，再批量地顺序写入到磁盘当中。这与B+树不同，B+树数据的更新会直接在原数据所在处修改对应的值，但是LSM数的数据更新是日志式的，当一条数据更新是直接append一条更新记录完成的。这样设计的目的就是为了顺序写，不断地将Immutable MemTable flush到持久化存储即可，而不用去修改之前的SSTable中的key，保证了顺序写。

在本实施例中，图计算引擎将数据由内存中有序的MemTable写入磁盘中形成sst文件，不同的sst文件形成逻辑上的层级数据。层数较低的数据(如Level 0)数据相较于层级较高的数据(如Level 2)更新，由于单个sst文件整体有序，sst文件之间的没有key范围重叠，数据的平均查找效率为O(k*log(n/k))。

随着sst文件数量的增长，大量小文件会带来存储压力并影响读取速度。LSM Tree模型引入了多层合并概念，将小文件按照层级逐层向下合并，一方面减少文件数量，另一方面依然保证层数较低数据较新的模型。

(3)Cyper编译器

在本实施例中，Cyper编译器除实现标准功能外，还提供了一些扩展语言编译能力。

在本实施例中，Cyper编译器的工作过程包括以下步骤：词法语法分析、语义分析、逻辑执行计划生成、物理执行计划生成。具体说明如下：

词法分析是编译的第一个阶段，将Opencypher字符序列转换为单词(Token)序列的过程，词法分析器一般以函数的形式存在，供语法分析器调用。语法分析器借助元信息和多存储抽象信息对Opencypher进行语法检查、并构建由输入的单词组成的抽象语法树。

语义分析是编译过程的一个逻辑阶段，其任务是对结构上正确的源程序进行上下文有关性质的审查以及类型审查。语义分析是审查源程序有无语义错误，为代码生成阶段收集类型信息。比如语义分析的一个工作是进行类型审查，审查每个算符是否具有语言规范允许的运算对象，当不符合语言规范时，编译程序应报告错误。

语义解译完成后，即可将OpenCypher操作命令编译为分布式逻辑执行计划。需要说明的是，在分布式逻辑执行计划中，不经优化的代码，执行效率往往很差，因此，得到分布式逻辑执行计划后，需要进行优化。具体地，可以根据预设的过滤条件，对所述分布式逻辑执行计划进行优化。

在本实施例中，可以设置以下过滤条件：删除公共子查询(CSE)；过滤没有用的列；过滤没有用的分区。具体实施过程中，过滤没有用的列后，没有用的列则不会在扫描表时读出来(Columnprune)；被过滤掉的分区下的数据，则完全不需要读取(Partitionprune)；此外，还可以预设其他过滤条件，特别是对隐式join where中的过滤条件，尽量下推到扫表的过程(PPD)，这样引擎就可以通过索引或者扫表的过滤提高查询效率；常量传播就编译时可以精确确定的值计算出来，避免运行时重复计算。

对所述优化后的分布式逻辑执行计划进行物理映射，即可生成在分布式环境下执行的物理执行计划。

(4)分布式图执行引擎模块

在本实施例中，分布式图执行引擎模块用于为用户提供实时图查询和离线图分析能力，其计算能力随着节点数目增长线性扩展，从而支持海量边点的图分析，利用数据locality特性加速图查询和分析任务。

分布式图执行引擎模块采用GraphMaster-Slave架构，其结构示意图如图6所示，描述如下：

GraphWorker节点由GraphSlave节点进行管理。用户OpenCypher接口与图计算引擎交互过程中的信息流分为控制流信息和数据流信息，其中，GraphMaster和GraphSlave节点之间交互所述控制流信息；用户上传的所述数据流信息不经过GraphMaster节点进行转发，而是直接发送给GraphSlave节点进行处理。

a)GraphMaster节点架构设计

GraphMaster是整个分布式计算系统的控制节点，负责整个平台的所有控制信息的管理工作，GraphMaster节点采用主备节点一致性协议进行管理。GraphMaster节点，Second GraphMaster节点和Third GraphMaster节点运行在三台服务器上，通过TCP协议同步控制信息。三个GraphMaster节点之间通过心跳协议进行异常或故障检测。当主GraphMaster节点出现异常时，Second GraphMaster节点会立即检测到主GraphMaster节点的异常，并及时接替主GraphMaster对整个系统的控制工作，保证系统的高可靠性，避免了单点故障问题。

GraphMaster节点集群控制着所有GraphSlave节点和GraphWorker节点，通过读取执行计划，生成用户需要执行的任务拓扑图，通过控制信息数据管理模型和资源分配调度算法模型动态生成需要执行的任务和指定任务下发的GraphSlave节点。由GraphSlave节点调度GraphWorker节点调度动态链接库获取需要处理的数据并进行处理。

GraphMaster节点作为系统的控制管理节点，运行着控制信息数据管理模型和资源调度分配算法模型等系统核心管理模型，GraphMaster节点的主要子模块有5个，5个子模块维护着GraphMaster节点的管理运行工作，具体：

任务管理子模块：通过XML文件管理模块和动态链接库调度模块提供的信息，动态生成任务执行流程和制定任务运行策略。

资源感知调度算法子模块：接收任务管理模块生成的任务流程并结合系统资源使用情况动态生成任务运行策略。资源感知调度算法包含三个核心算法，系统初始化资源感知调度算法，系统运行中资源重新配置调度算法以及系统灾备调度算法。

心跳保活子模块：GraphMaster集群节点之间需要定时检测节点是否正常运行，心跳保活协议通过节点之间不断发送心跳报文来检测对方节点是否存在异常。

主备节点容错算法子模块：运行着主备节点一致性协议，保证GraphMaster节点，SecondGraphMaster节点和ThirdGraphMaster节点之间的状态管理，保证GraphMaster节点存在异常时系统能迅速调度SecondGraphMaster节点接管系统控制管理。

一致性哈希磁盘存储子模块：控制信息数据等数据的磁盘持久化管理模块，保证数据在系统发生宕机或者系统在重启的时候可以从磁盘中快速获取历史运行情况，迅速完成系统初始化。提供运行过程中的控制信息数据的查询调度。

b)GraphSlave节点架构设计

GraphSlave节点主要职责包括：

收到GraphMaster下发的任务信息以后拉起相应的GraphWorker节点，并向GraphMaster节点发送节点上线信息。

操作GraphWorker节点执行业务环境准备流程，包括GraphSlave动态拉起N个GraphWorker节点，连接上下游GraphWorker形成任务拓扑流，GraphWorker拉起对应的动态链接库，任务执行结束后进程资源的释放。

GraphMaster节点和GraphSlave节点之间存在心跳保活协议，保证GraphMaster和GraphSlave节点之间及时知道对方运行异常。GraphSlave也会接收GraphWorker的任务运行信息并及时反馈给GraphMaster。

GraphSlave统计本节点系统资源使用情况，GraphWorker节点数量以及每个GraphWorker节点的资源使用情况。并定期发送给GraphMaster节点。

GraphWorker管理子模块：负责创建或结束GraphWorker计算节点。

资源收集子模块：收集本GraphSlave节点上的所有GraphWorker的资源使用量。及时发送到GraphMaster。

心跳保子活模块：定时向GraphMaster节点发送心跳信息，心跳协议可包含资源信息或任务信息。接受并回复GraphSlave发送的心跳。

任务调度子模块：接受GraphMaster发送的任务信息，调度本节点拉起的GraphWorker，建立GraphWorker节点上下游关系，执行任务流。

c)GraphWorker架构设计

GraphWorker节点是由GraphSlave节点使用fork和exec函数拉起的进程。

GraphWorker节点主要职责有：

根据GraphSlave的任务拓扑信息，和相应的GraphWorker节点建立上下游关系。

执行GraphSlave节点下发的任务信息，接收GraphSlave节点发送的动态链接库的位置信息，调用动态链接库模块中的dlopen系列函数拉起.so文件。

接收上游GraphWorker节点发送的数据，调用用户自定义代码进行数据处理，并将处理后的数据发送到下游节点或者放到本地存储当中。

向GraphSlave节点汇报本节点的资源使用情况和任务执行情况。

(5)图分析算法模块

图分析算法模块内集成内部和外部算法模块，用于以RDD的方式提供数据和计算的接口。内置算法库包含PageRank，Connected Components，Fast-Unfolding等基础算法，同时外置了NLP、NlU和深度学习算法来适配图计算业务场景。

其中，图分析算法集成多种分布式图计算算法和深度学习图算法，构建图谱挖掘模型。支持图算法包括：StarNet、Page Rank、Strong Connected Component、LabelPropagation、K-core、Bow Tie、Graph Centrality、Fraud Rank、Heavy Edge Detector、MotifFinding。

图分析提供cypher查询接口，2D展示查询结果，并提供了针对查询结果的各项页面操作。

(6)OpenCypher接口模块

OpenCypher接口模块，用于实现用户可以通过扩展的open-Cypher语言访问图处理计算引擎，在提供标准功能之外，还提供了一些扩展语言，提供图函数计算功能，图函数包括基础函数、聚合函数、数学函数、字符串操作函数、集合操作函数以及crux-cypher内部函数，以满足图计算和复杂查询流程的需求。

能够为数据供应商提供快速访问图形处理能力，能够通过其与图计算引擎的接口共用一个通用查询语言。

OpenCypher查询语句遵循格式示意如下：

[MATCH WHERE]

[OPTIONAL MATCH WHERE]

[WITH[ORDER BY][SKIP][LIMIT]]

RETURN[ORDER BY][SKIP][LIMIT]；

函数的存在，大大提升了图计算和复杂查询的效率，将可能需要反复执行的代码封装为函数，并在需要该功能的地方进行调用，不仅可以实现代码服用，更重要的是保证代码的一致性。常用的基础函数如表1所示。常用的图计算聚合函数表如表2所示。

表1图计算基础函数表

表2图计算聚合函数表

函数名	参数	功能
			count	structure	返回参数在结果集中的个数
min	values	返回参数在集合中的最小值
			max	values	返回参数在集合中的最大值
sum	values	返回集合中数据的总和

(7)RestAPI接口模块

用于提供标准RESTful接口获取图计算状态，也可通过JAVAAPI执行图的增删改查和构建符合业务模型的图算法。

工作过程：以查询API为例介绍图计算引擎RestAPI接口设计。

请求路径：/api/stellar/cypher

请求类型：POST

查询参数示例：

{

"cypher_graph":"snap_test",

"cypher_input":"match(a)-[f]-(b)return a,flimit 5；",

"execution_mode":0,

"result_form":0,

"vertex_attr_filter":{

"flag":0,

"filters":[{

"label":"__all__",

"attrs":["uid"]

}]

},

"edge_attr_filter":{

"flag":0,

"filters":[{

"label":"__all__",

"attrs":["uid"]

}]

}

}

·属性filter的格式示例：

参数中引入属性filter的场景描述：在查询结果中，点或者边可能会有很多个属性值，使得返回的json格式数据很大，但很多时候部分属性对于查询用户来说是不关注的。所以，考虑在返回数据时可以将查询用户不关注的属性过滤掉，只返回用户关注的属性信息。

由于不同label的数据会有不同的属性，所以针对不同label提供不同的过滤条件。也可用字符串"__all__"来指代所有的label，对所有label的数据进行属性过滤。

提供两种形式的属性过滤，只返回某些属性、以及不返回某些属性。

图计算引擎的另一种结构示意图如图7所示，主要由存储层、计算层和接口层组成。在存储层，GraphDB(原生图存储)用顶点表、边表以及有序索引表为图数据提供具有高效压缩能力的底层存储。借助图分区算法，图数据可按策略分散存储于集群中，由分布式存储引擎实现GraphDB分区副本的一致性和扩展性，理论上具备任意规模的图数据存储能力。在计算层，借助分布式图计算引擎，通过内置图算法，可同时为用户提供实时图查询和离线图分析能力，计算能力随着节点数目增长线性扩展，从而支持海量边点的图分析，利用数据locality特性加速图查询和分析任务。在接口层，实现了OpenCypher，除提供标准功能外，还提供了一些扩展语言，以满足图计算和复杂查询的需求。

综上所述，本实施例提供的图计算引擎的触发方法，通过改进Cyper编译器的编译方式，增加过滤流程，有效提升了编译过程的执行效率，解决了现有图计算引擎的触发过程在编译性方面的问题，有效提升了编译效果。同时，通过改进分布式图存储引擎模块的架构，借助图分区算法改变原生图存储格式，有效提升了图数据的存储速率，解决了现有图计算引擎在存储性方面的问题。

本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种图计算引擎的触发方法，其特征在于，包括：

接收OpenCypher操作指令；

启动Cypher编译器，对OpenCypher操作指令进行语法及语义解译，将解译后的OpenCypher操作命令编译为分布式逻辑执行计划，并根据所述分布式逻辑执行计划生成在分布式环境下执行的物理执行计划；

向GraphMaster进行注册并申请资源；GraphMaster根据物理执行计划获取待执行任务，将待执行任务分解成多个一级任务，并将各一级任务分配给不同的GraphSlave；

GraphSlave将接收到的一级任务分解成多个二级任务，并将各二级任务分配给不同的Worker，由Worker执行相应二级任务；

所有待执行任务完成后，向GraphMaster申请资源注销，等待接收下一次OpenCypher操作指令。

2.根据权利要求1所述的图计算引擎的触发方法，其特征在于，所述方法还包括：

在Worker执行相应二级任务过程中，通过图计算引擎中的RestAPI接口模块提供的标准RESTful接口，获取图计算状态、执行图数据的增删改查、以及构建符合业务模型的图算法。

3.根据权利要求1所述的图计算引擎的触发方法，其特征在于，所述方法还包括：

在Worker执行相应二级任务的过程中，通过图计算引擎中的分布式图存储引擎模块对图数据进行管控及数据处理操作。

4.根据权利要求3所述的图计算引擎的触发方法，其特征在于，在Worker执行相应二级任务的过程中，通过图计算引擎中的原生图存储格式模块将所述图数据以高效的压缩格式存储于所述分布式图数据库系统中。

5.根据权利要求1-4中任一项所述的图计算引擎的触发方法，其特征在于，所述根据所述分布式逻辑执行计划生成在分布式环境下执行的物理执行计划，包括：

根据预设的过滤条件，对所述分布式逻辑执行计划进行优化；

对所述优化后的分布式逻辑执行计划进行物理映射，生成在分布式环境下执行的物理执行计划。

6.根据权利要求1所述的图计算引擎的触发方法，其特征在于，在所述图计算引擎中，通过OpenCypher接口模块接收所述OpenCypher操作指令，以实现对图计算引擎的访问。

7.根据权利要求6所述的图计算引擎的触发方法，其特征在于，所述OpenCypher接口模块还用于提供图函数计算功能；所述图函数包括基础函数、聚合函数、数学函数、字符串操作函数、集合操作函数以及crux-cypher内部函数。

8.根据权利要求6所述的图计算引擎的触发方法，其特征在于，在Worker执行相应二级任务的过程中，通过图计算引擎中的分布式图执行引擎模块为用户提供实时图查询和离线图分析服务；

所述分布式图执行引擎模块采用GraphMaster-Slave架构。

9.根据权利要求8所述的图计算引擎的触发方法，其特征在于，在所述GraphMaster-Slave架构中，

GraphWorker节点由GraphSlave节点管理；

用户的OpenCypher接口与图计算引擎交互过程中的信息流分为控制流信息和数据流信息；其中，GraphMaster和GraphSlave节点之间交互所述控制流信息；用户上传的所述数据流信息不经过GraphMaster节点进行转发，直接发送给GraphSlave节点进行处理。

10.根据权利要求9所述的图计算引擎的触发方法，其特征在于，所述GraphWorker节点是由GraphSlave节点使用fork和exec函数拉起的进程；

所述GraphWorker节点的职责有：

根据GraphSlave的任务拓扑信息，和相应的GraphWorker节点建立上下游关系；

执行GraphSlave节点下发的任务信息，接收GraphSlave节点发送的动态链接库的位置信息，调用动态链接库模块中的dlopen系列函数拉起.so文件；

接收上游GraphWorker节点发送的数据，调用用户自定义代码进行数据处理，并将处理后的数据发送到下游节点或者放到本地存储当中；

向GraphSlave节点汇报本节点的资源使用情况和任务执行情况。

Images