Skip to main content

架构

ArcGraph 系统架构如下图所示。

img.png

  • 存、算、分析一体化设计,采用 Graph HTAP 理念,实现在线查询与图计算分析的融合。

  • 单机分布式一体化内核架构设计,既可以敏捷部署,又具备强大的性能和横向扩展能力。

  • 实现计算与存储的分离,并遵循“Log as Database”的设计理念,解耦计算和存储。

ArcGraph 的 TP 系统可以分为三层

1. 查询引擎(Query Engine)
查询引擎是 ArcGraph 的大脑,它是无状态的 Cypher Query Compiler 引擎。该查询引擎通过采用 Rust 的 Logos 库和 Nom 库来解析 Cypher 语言并生成 AST。随后,通过 Planner 进行转换,利用自研的具备自上向下和自下向上优化框架(借鉴 Cascade 框架的思想),同时结合点和边统计信息以及历史 Plan 信息,通过 RBO、CBO 和 HBO 的多轮 Plan 优化,生成高效的执行计划。

2. 计算引擎(Computing Engine)
高性能的计算引擎是 ArcGraph 的发动机,采用了 MPP 的架构;该计算引擎承担多项重要任务,包括执行计划的 DAG 切割、 DAG 在分布式 computing 节点间的分发,以及执行计划的启动、暂停、恢复和删除等生命周期管理。最后,计算引擎会暂时缓存计算结果,通过 gRPC 按批发送给客户端。

由于系统采用存、算分离的分布式架构, ArcGraph 的计算引擎采用中心化的 TSO 分配策略以及分布式的 MVCC 能力,以确保分布式事务的隔离性和一致性。同时,它还采用了 multi-raft 协议以确保 WAL log 在多个计算节点的一致性,从而天然的具备了分布式节点之间的 HA 功能。

图数据(点和边)通过灵活的分区策略存储在不同 Partition 中,这些 Partition 可由分布式计算节点池中的不同计算节点提供服务。通过调整分区策略,可以达到优化分布式执行的效果,例如将相关性的点和边数据由同一个计算节点提供服务,从而降低图查询经典多跳时的分布式通讯成本。

3. 存储引擎(Storage Engine)
存储引擎采用 share-nothing 的架构,提供 ArcGraph 的持久层服务。存储层采用多级存储系统,首先是提供高性能数据访问的内存引擎,提供图拓扑信息、MVCC、脏页管理;然后是本地 SSD 固态存储,提供持久化 WAL 日志服务,并借助 Raft 协议来保证节点间的分布式一致性;最后是提供异步写入的远端存储,根据业务系统需要,可以灵活对接单机 RocksDB,分布式 TiKV 或云对象存储(OSS)。

运行模式

ArcGraph 提供了单机版、敏捷版两种运行模式,适用于不同的应用场景。

img_8.png

  • 单机版
    单机版允许 ArcGraph 在一台机器上快速部署,以便用户可以快速地开始使用。单机版通常适用于个人开发测试,不能保证高可用,因此不建议在生产环境使用。

  • 敏捷版
    敏捷版通过引入 Raft 技术,允许三个节点之间的数据复制和故障转移,以确保数据的可靠性和系统的可用性,数据三副本存储。敏捷版的性能、容量和稳定性等各方面相对均衡,推荐使用。在存储架构上,敏捷版又分为本地存储和分布式 K/V 存储两种。

    • 本地存储:数据保存在本机数据盘,性能更优,但容量受限于所在主机的存储空间。
    • 分布式K/V存储:数据保存在分布式 Key/Value 集群中,适用于对数据容量有极高扩展性的场景。

数据分区 与 分布式并行查询

数据分区是指将数据集分成若干个较小的子集或分区,以便在分布式系统中进行分布式处理和存储。这种策略可以提高数据处理的效率和灵活性,同时也可以减轻单个节点的处理负担。

架构优势:

  • 灵活分区策略
    基于哈希的分区策略 Hash(vertex_type), Hash(vertex_id) ...,系统通过使用点类型(Vertex_Type)和点 ID(Vertex_id)等属性作为输入,将其通过哈希函数映射到特定的分区。这种策略可以使得相同类型或 ID 的顶点在同一个分区中,从而方便针对特定类型的数据进行查询和处理。同时,使用哈希函数可以实现负载均衡,使得每个分区包含大致相同的数据量。

  • 分布式存储
    基于分区策略达到点/边/索引数据的分布存储效果,通过将数据分区并存储在不同的服务器节点上,可以并行处理和查询各个分区的数据。索引数据可以跨多个分区分布,以提高查询效率。

  • 点/边分区一致性
    边的分区采用起始点分区一致,加速多跳查询性能,对于边数据,建议按照起始点所在的分区进行划分。这样可以使得同一跳的边的数据在相同的分区中,从而加速多跳查询。

  • 基于 Vertex_id 计算点的 location 信息
    通过顶点 ID 计算获取点的 location 信息。该架构可以通过一种映射关系或者计算规则,将顶点 ID 映射到具体的地理位置。

img_5.png

ArcGraph 是一个实现分布式查询的图数据库,计算层采用 MPP 分布式架构,每个计算节点采用基于 Push 模式的向量化执行引擎,实现原理大致如下:

(1)执行计划切割——基于 QueryEngine 优化后的物理执行计划,执行引擎先结合算子的属性(例如是否是 pipeline breaker,如 Hash Join 算子),完成对执行计划进行切割,最终生成 DAG 图,基于 DAG 间的依赖关系,对其中的每个子 DAG 进行分布式并行调度执行。
(2)计划分发——根据执行计划中涉及数据 partition 分布信息,把执行计划分发到所涉及的 partition leader 节点。
(3)分布式调度执行——由 coordinator 节点发起 pipeline ,并在计算节点 server 上分布式行执行;每个计算节点上的计算引擎采用 push 模型,并结合 Batch 方式进行向量化执行,同时算子内部利用协程进行计算加速(例如并行执行多节点的 Expand),高效完成执行计划的分布式并行执行计算。

在计算过程中,如果有些算子产生大量中间结果(如 aggregate 算子),计算引擎具备“Flush to Disk”的功能,可以物化部分结果到外存,从而避免 OOM 的问题。在有些场景中,如果计算引擎生成结果的速度快于 Client 拉取数据的速度,引擎会自动暂停 Pipeline 的执行,等待 Client 消费一定量 ResultCache 中数据后再恢复执行。针对图查询中典型多跳场景,根据节点的亲和性,对于需要到远端机器执行下一跳的节点集合,可以根据不同机器目的地进行缓存,并按批发送到远端机器。这些节点数据发送到对端机器后,会启动新的子 pipeline 进行并行处理,然后根据 Plan 进行后续处理执行。

分布式存储

img_1.png

ArcGraph 存储层基于数据温度实现了“热、温、冷”的三级存储结构:

  • 首先,提升 ArcGraph 性能的高效内存引擎,包括常驻内存的图拓扑信息,基于 LRU 的点/边属性 Cache,以及支持 DML 功能的 MVCC,脏页管理和 index buffer 管理。
  • 下面一层是基于 Log 即 Database 思想的高效本地存储,用来存放 L1 delta,也就是 WAL 日志,并通过 multi-raft 实现节点间的日志同步达到高可用功能。
  • 第三层是传统的持久层,为了方便不同场景的灵活部署,系统采用了多种存储方式:快捷部署的单机 RocksDB 部署,大数据量场景的分布式 K/V 部署,以及性价比友好的 S3/OSS 存储。

我们以 K/V 存储引擎为例,介绍下 ArcGraph 存储功能接口。每个存储节点都有一个 K/V 存储引擎作为持久性存储,从上到下提供三个功能:

  1. 最上层是计算层提供统一的图查询接口,比如点/边的查询和写入接口。当接到计算层的 Get()或 Put()请求后,首先根据点和边的 Key 在分布式存储中的 NameNode 上查询对应分区拓扑的 Leader 节点信息,然后把请求路由到对应的 KV 节点进行处理。
  2. 分布式 K/V 存储中间采用 Raft 协议来实现分布式一致性和高可用性。当系统负载发生变化或者存储系统中的节点或者网络出现故障时,分区 Leader 可以人为或基于 Raft 协议自动进行切换。
  3. K/V 存储引擎用于实现图点/边数据的持久性;为了节省存储空间,会根据系统配置,对数据进行不同程度的压缩存储。

Semi-Stateful 与 Log as Database

随着数据库的存算分离,传统数据库的业务 IO 瓶颈已经转化为计算层和存储层之间的 IO 瓶颈,在这种情况下,底层存储节点和网络时延对于响应时间有很大的影响,事务操作的性能也会很大程度上受到影响,尤其是分布式提交等复杂操作。因此,ArcGraph 采用了 Semi-Stateful 架构,继承了“日志即数据”的思想,并在计算层增加本地高性能 SSD 日志 Store,用以对 DML 的 WAL 日志进行存储,并定期对 WAL 日志进行 CheckPoint,并把 Checkponit 数据写入底层存储引擎。这带来了如下优点:

  • 在 DML 操作中,只需要记录 WAL 日志,从而显著减少了网络占用。
  • 将复杂的 DML 操作由数据和日志的同步操作转变为连续的异步操作。
  • 引入了一个分布式的、基于 Raft 协议同步的 WAL 日志服务,降低了网络层或数据存储层问题对数据库的影响。

img_2.png

ArcGraph 可采用灵活的分区策略,例如基于点的 ID 或点的 Type 进行 Hash,并采用边的分区跟随起始点的分区策略。通过这种方式,可以将图的点和边数据分为不同的 tablet 分区,每个分区都有多个 WAL 日志的副本,并使用 multi-raft 共识算法来实现 WAL 日志的分布式一致性。在同一个 Raft 组内,节点可以担任不同的角色,包括 Leader、Follower 和 Learner。

  • Group Leader:负责接收分区 DML 操作所生成的 WAL 日志写入请求,并在 Raft 组内完成日志的同步及一致性确认, 最后确保成功写入本地的日志 Store。
  • 其它 Group Follower 节点(一般是其它 TP 计算节点):完成对 Raft Leader 新的日志进行同步确认,并在心跳超时后发起 Leader 选举。
  • Group Learner 节点(通常是 AP 计算节点):对最新的 WAL 日志进行同步,获取最新的 Delta 数据,并将其与从底层存储引擎获取的 Snapshot 数据进行合并,合并后的数据用来完成用户特地场景的 AP 计算(图计算)任务。

图 HTAP

img_3.png ArcGraph 具备强大的图 HTAP(Hybrid Transactional and Analytical Processing)计算能力,专为低延迟、高并发和复杂的事实计算设计。同时支持 T+1 场景。TP (Transaction Processing)引擎和 AP (Analytical Processing)引擎共享 Cypher Query 前端(Parser,Validator,Planner,Optimizer),根据生成的执行计划,TP 场景的由 TP 引擎分布式并发执行,针对执行计划中的图算法类 AP 算子(比如 SSSP,PageRank),则由 AP 引擎负责进行处理,AP 引擎首先从 TP 引擎获得查询子图,然后进行分布式图计算。此外 AP 引擎也支持从数据库外部加载数据,例如 Hadoop 或者对象存储系统,由此支持了图 HTAP 处理。同时 AP 计算节点实现了 Serverless 能力,可以根据用户请求负载差异,动态扩缩容。

Serverless OLAP

img_4.png

多模态能力

img_6.png

ArcGraph 将向量、JSON 和图进行了深度融合。在图的 Schema 中,通过为属性字段提供 JSON 类型和向量类型的字段支持,实现了图结构的半结构化和向量能力。 以电影知识图谱为例:影片与制作人作为顶点,形成图拓扑关系,每部电影都有其独特的 ID 和其他信息(如标题、年份等),这些信息我们通过使用 JSON 进行表示。此外,我们将电影的内容或简介文本描述进行向量化处理,并将这些向量数据作为电影顶点的属性字段存储在图数据中。 针对向量字段的索引部分,通过 HNSW 索引来加速向量数据的检索。这种索引与图数据的处理结构非常相似,因为它也采用了类似多层图的数据结构。并且使用 HNSW 索引的优点是其检索效率高且召回率较高。为了进一步实现图与向量数据的整合处理,我们在系统中加入了以下三个特性:

  1. 使用 SIMD 进行距离计算加速,与传统方式相比,我们的方法可以提高 4 倍的性能。
  2. 支持属性过滤的向量检索功能,同类系统只能进行纯向量检索,而不能进行其他字段(标量)的联合检索。
  3. 通过原有图技术沉淀,向量数据模型上也实现了完整的 CRUD 和 ACID 功能。

同时 ArcGraph 采用了“One Query”的设计哲学,意在为用户提供一个统一的查询接口。这不仅仅体现在数据模型的统一,更进一步在于查询语言的统一。通过一条查询语句,用户可以同时检索向量数据、JSON 数据和图数据。

ArcGraph 图数据库生态

主要包括产品的客户端、图智能 Analytic 平台、图开发 Studio 平台、Infra 服务及通用服务等方面。ArcGraph 合理的生态布局能够确保产品的稳定性、可扩展性和易用性。

产品生态架构

总结

ArcGraph 是一款云原生架构、存查分析一体化(图 HTAP)的分布式多模态图数据库,采用 Multi-Raft 协议来满足系统的分布式一致性和高可用性;同时支持存储节点和计算节点的无缝扩缩容,支持分布式事务和分布式查询功能;通过采用原图内存引擎,支持高性能图查询和 Serverless 图计算;并且通过图、JSON 和向量(Vector) 的深度融合,实现了 ArcGraph 的多模态能力。