用Rust编写核心组件！独家揭露阿里云开源GraphScope如何成为全球最快图计算引擎

上个月，国际权威图基准测评“LDBC SNB Interactive”（社交网络 - 交互查询）榜单更新中出现关键突破：阿里云开源的图计算引擎 GraphScope 登顶并打破榜单历史纪录，性能达此前纪录保持者 2.45 倍。

LDBC 全称 Linked Data Benchmark Council，是一个致力于发展图数据管理的产业联盟国际权威非盈利组织，其成员来自工业界和学术界，包括 Intel、AWS、Neo4j、TigerGraph 和 Oracle 等。

在此次基准测评中，GraphScope 以超过 33,000 QPS 的吞吐量排名第一。GraphScope 是阿里云自研的一站式图计算系统，于 2020 年 12 月开源，在 GitHub 上已超过 2.6k star。

GitHub 地址：
https://github.com/alibaba/GraphScope

不可或缺的图计算

在阿里巴巴的电商推荐、搜索、风控等场景中，有很多地方会用到 GraphScope 图计算引擎。

自 2020 年起的多年双十一期间，阿里巴巴的搜索以及风控团队采用 GraphScope 作为底部支撑实施了准实时欺诈检测，虚假订单检测能实现秒级识别，评测准确度达到了 97%。在此之前虚假订单一般需要等到第二天才能处理。

另外，在推荐场景中，常会用到链路预测，通过已知的网络结构预测尚未发生连边的两个节点之前产生连接的可能性。比如对社交网络做关系分析时，共同邻居是一个重要的特征，它标记了两个不直接关联的点之间共同的好友关系。

这个应用如果用传统的关系数据库写查询，会十分复杂，事实上，很多业务场景确实是通过 SQL + 一些 UDF 的方式写的。但由于复杂度的问题，要舍弃一些精度以及引入很多近似计算才能在一个很大规模的数据集上成功跑下来，但千亿规模的数据上需要近 10 个小时。

这种情况采用图建模的话，共同邻居的查找就十分直观，也很容易写。GraphScope 系统通过基于子图模型、增量化计算等技术，能高效的支撑千亿规模以上的图计算，并且由于图建模可以准确计算共同邻居，避免精度损失。这类之前用时 10 小时的计算任务，用 GraphScope 只需要约 600 秒。

现在，在阿里巴巴内部，已经海量任务跑在 GraphScope 图计算引擎上，GraphScope 每天要处理数万个图计算任务。

以前，相比于传统的关系型数据库以及 SQL，图数据库的使用所占的比重很小。但近年来，随着互联网应用的爆炸式增长和对用户需求的深度挖掘，大家开始认识到有些场景下，传统的 SQL 处理方式已经不能满足高效的需求。而图数据库，与其他的文档数据库、KV 数据库类似，为复杂数据分析提供了全新的维度。特别是在需求深入挖掘关联关系的场景下，图几乎成为了不二之选。这一趋势的重要性在 ISO SQL 标准的 2023 版本中得到了体现，其中，SQL/PGQ（Property Graph Query）被纳入，未来支持 SQL 的数据库中也将支持图的查询。

不仅在数据库中，图计算已经在大数据处理和分析中也开始展现其独特的价值和地位。根据 2022 年 8 月发布的 Gartner 报告，到 2025 年，图计算技术将在 80% 的数据和分析创新中扮演核心角色。这与 2021 年的数据大相径庭，当时图计算在数据和分析创新中的占比仅为 10%。这样的飞速增长无疑证明了图计算在未来数据分析领域的至关重要性。

正因如此，该团队一直在持续精益求精地打磨 GraphScope。2018 年，GraphScope 团队的主要成员加入阿里巴巴，并将其自研图计算技术 GRAPE (GraphScope 核心引擎之一的前身) 逐渐应用到阿里巴巴集团和阿里云上。经过几年打磨和使用后，2020 年 11 月，GraphScope 在第二届世界科技与发展论坛上重磅宣布开源并发布了白皮书，同年 12 月代码在 GitHub 开源。

架构演进

在以往的图计算系统中，由于针对不同类型的图计算任务设计了特定的特征，导致解决方案出现了严重的碎片化现象。这意味着每种不同类型的图计算任务都需要使用不同的系统或工具来进行处理，导致系统架构的复杂性急剧上升。

在处理现实业务时，一个复杂的工作流可能涉及多种不同类型的图计算任务，比如多模式的图计算，以及需要跨越多个系统进行协同的情况。举例来说，考虑一个包含交易图和欺诈检测的工作流，这可能需要在不同的系统中执行不同的图计算任务，这不仅会引入大量的 IO 开销，还会增加系统运维的复杂性。

在以前的部署方式中，为了完成工作流中的不同图计算任务，可能需要通过外部存储来部署多套系统，增加了整个系统的维护难度。此外，不同系统之间的数据交互也变得复杂，可能需要额外的工作来确保数据一致性和有效的传递。

这种复杂性还使得开发人员需要具备对多个系统的熟悉度，增加了开发和维护图计算任务的技术门槛。这对于数据科学家、算法用户和应用开发方来说，都带来了极大的挑战，限制了图计算在业务中的应用和发展。

在 2020 年，基于收集到的用户需求，GraphScope 团队提出了一种创新的概念——一站式图计算，通过一个系统整合了当时的多个图计算引擎（即当时 GRAPE、MaxGraph 和 GraphLearn）的能力，覆盖了图分析、图遍历、图学习等多种任务。

为了实现这一概念，他们进行了大量的研究和开发工作。例如，开展了自研的子项目 vineyard，这个项目解决了跨不同引擎之间数据交互与共享的挑战。值得一提的是，vineyard 项目开源后被捐赠给了云原生大数据社区，进入了 CNCF Sandbox。

经过这些改进，最终形成了 GraphScope 一站式图计算，可以在一个平台完成多类图计算任务，这也是业界首个一站式图计算系统。GraphScope 的用户们从一站式得到的好处，“从体验侧的价值来说，最主要的是极大程度降低了图计算门槛，极度简化了数据科学家、算法用户以及应用方开发、部署和运维图计算的成本，可将图计算研发上线的周期从以数周计，提效为一两天即可完成。”

组件化架构

在此基础上，为了进一步满足图业务的多样化和碎片化需求，GraphScope 正在推进下一代组件化架构 GraphScope Flex，以像乐高一样的组件化形式为各种具体的图计算场景提供方便的部署、服务和计算的能力。

在这一架构下，用户可以根据实际的业务场景，灵活地选用 GraphScope 中的若干组件，从而得到最合适其业务场景的部署形态，形成定制化的图计算环境。

与此对应，本次提交的 LDBC 基准测试就是基于 GraphScope Flex 架构的高吞吐图查询部署方案。在这个部署模式中，他们利用自研的多层级 Actor 框架 Hiactor 作为底层执行引擎，并结合了 GraphScope 在图存储和图分析引擎方面的积累。这种方案能够在保障事务性要求的前提下，为用户提供超高吞吐的图查询能力。

在开源之后，GraphScope 团队也在不断优化与创新。比如在高效图分析引擎上拓展了 GPU 加速，性能较之其他系统快 5 倍有余；通过引入新的 FLASH 高效模型，将内置图算法种类扩增到近 100 种。

Rust 编程语言的应用

此外，GraphScope 还利用近期备受关注的系统编程语言 Rust 编写了交互式查询的核心组件，分布式引擎 GAIA。相较于适用于高吞吐场景下的 hiactor 系统，GAIA 更着重于系统的扩展性和利用并行技术优化查询延迟。为了构建一个更加高效、稳健且安全的并行系统，从 GAIA 的原型系统（发表于 NSDI 2021）起，便选用 Rust 语言进行开发。

选择 Rust 主要是因为它提供的“编译时生命周期检查”、"卓越的并发控制"，以及“媲美 C/C++ 的执行效率”，具体来说：

编译时生命周期检查：Rust 在编译过程中提供的变量生命周期检查功能，使我们能够在编程的初始阶段尽可能地确保程序的正确性。相比其他语言，这为 GAIA 这样复杂的系统的实现提供了极高的可靠性保障，解决在分布式服务化的部署中的内存管理问题。

卓越的并发控制：并发编程中最常见的问题包括竞态条件和死锁。Rust 提供了各种机制来避免这些问题的发生，包括但不限于原生的互斥锁和读写锁，以及通过 Send 和 Sync 两个原生 trait 来保证线程安全。该并发控制是 GAIA 分布式系统实现的基础。

媲美 C/C++ 的执行效率：Rust 凭借零开销的抽象和底层优化，以及优质的标准库实现，使得其编写的程序能达到传统面向性能的编程语言 C/C++ 的水准。同时，通过生命周期检查和并发控制，Rust 很大程度地避免了 C/C++ 实现的系统常遇到的内存溢出和死锁等难以定位和修复的问题。

基于 GraphScope Flex 提供的组件化能力，GraphScope 可以通过 GAIA 来支持更多的复杂查询，实现对图数据更为复杂和深刻的洞察与分析，未来也可以为支持 LDBC 的 SNB BI 的工作负载奠定基础。

GraphScope 是如何打破纪录的

这次，GraphScope 登顶并打破榜单历史纪录的基准测评是 LDBC SNB Interactive ，也是业界最受认可的图数据库基准评测。

近年来参与 SNB Interactive 评测并在榜中领先的图数据库产品是蚂蚁集团开源的图数据库产品 TuGraph，最近成绩为 2023 年 1 月做的测试；另外，国内知名图厂商创邻科技的 Galaxybase 也在 2022 年 5 月提交过成绩。

在 LDBC SNB Interactive 评测中，为了全面评估图数据库，引入了复杂的数据表和多样化的读写混合查询。背后通过一个驱动器向待测系统快速、持续地发送这些查询请求，主要以系统处理查询的吞吐率（QPS）来衡量其性能。

其中涉及到处理技术难点，包括：

复杂查询优化：图查询等价于多表关联的查询，而此类优化一直是数据库的传统难题。同时，查询中涉及复杂算子如点对间最短路径，这本身就难以高效实现。复杂的 SNB 数据表结构，不同类型的数据量差异很大，不当的查询顺序可能导致大量中间结果，严重影响执行性能。

读写并发和事务：高并发的读写需要加锁，但在高吞吐情况下，锁开销会显著影响性能。图存储数据结构需要兼顾读写性能，传统的结构往往在写或读性能上存在不足。同时，在高并发情况下，保证事务的一致性和效率更加困难。

高并发查询：高并发场景下，物理线程切换会引入大量的开销。查询涵盖了复杂和简单查询，复杂查询可能长时间占用资源，导致系统吞吐大幅下降。

这些技术难点涉及图数据库的查询优化、读写并发、事务保证以及高并发查询等方面，对于系统设计和实现提出了严峻挑战。为了克服前述技术难题，GraphScope 主要从以下三个方面实现突破：

在图查询优化方面，通过引入“高维图数据的无偏估计”技术，子图采样可以准确估计基数，从而优化查询访问顺序，提高了特定查询性能。同时，采用了“双向路径搜索”算法，在包含最短路径的负载下，性能提升近 3000 倍。

在高性能读写图存储设计方面，通过采用“细粒度的锁控制”策略，将图数据写操作细分为修改（如属性更新）和插入（点 / 边），采用不同级别的锁以提高读写并发效率（对于修改操作使用常规读写锁，对于插入操作用细粒度或者无锁技术）。引入了“高效的版本控制”技术，通过原子操作降低锁开销，改进了事务同步。此外，改进了原有的 CSR 图数据结构，通过预留空间和自旋锁应用，在保证读效率的同时，有效支持插入操作。

为支持超高吞吐的计算引擎，引入了“轻量级用户态线程”技术，极大地减少了高并发场景下线程切换的开销。同时，采用了“异步协同式调度”策略，使得用户态线程在异步操作时能主动释放时间片，避免了复杂查询阻塞其他并发查询的情况。

这些关键技术的整合使得 GraphScope 在性能和效率方面都取得了显著突破。

图计算在大语言模型中的应用前景

今年以来，以 ChatGPT 为代表的大语言模型（LLM）迎来爆发式增长，虽然 LLM“涌现”出的智能令人兴奋不已，但其训练方式和特有的自然语言交互模式，使得将 LLM 应用于生产依然面临诸多挑战，例如：在训练数据滞后的情况下，如何提升 LLM 回答的实时性？在大部分 LLM 都具有“幻觉”（Hallucination）的情况下，如何确保回答的准确性？虽然 LLM 具有智能，但其大语言模型的本质决定了 LLM 在特定领域能力的限制，例如数学计算、网页搜索等。同时，在处理复杂任务时，往往需要对任务进行拆解和编排，利用工具逐个解决，如何才能端到端完成复杂任务？

为解决上述 LLM 原生问题，业界已经涌现出大量实践，举例来说：

当 LLM 充当 QA 助手时，回答的实时性问题可以通过在提示词（prompt）中加入实时信息得以解决。但这也引出另一个问题，如何找出和问题相关的实时信息呢？网络上的公开数据，尚且可以使用例如 serpapi 之类的搜索工具得到，那么特定领域数据或者私有数据如何处理呢？在提示词长度限制下，如何选出最相关的数据加入其中呢？

当 LLM 出现“幻觉”时，用户往往基于“常识”作出了判断，并通过降低活跃度（temperature）和细化提示词来降低“幻觉”。然而在处理特定领域（例如医疗、法律）任务时，即使用户具有该领域的“常识”，“幻觉”往往难以被识别，因为一般用户难以全面掌握领域知识。那么，有没有什么方法可以有效利用领域知识来识别 LLM 的“幻觉”呢？

针对复杂任务，将 LLM 与现有成熟生产工具结合，充分利用 LLM 的智能作为编排复杂工作流程的“大脑”，并调动生产工具完成端到端执行，是业界给出的方案。其中代表，包括闭源的 ChatGPT-Plugin 和开源的 Langchain。然而，在 LLM 单一自然语言交互模式下，如何才能实现工作流可视化、实时交互等，以提升系统整体的透明度，避免成为黑盒子呢？如何才能完成数据沉淀、统计分析、快速迭代等，从而提升工作流效率和可持续性呢？

得益于图抽象的语意表达能力和可解释性，图计算可以很好的解决上述业界正在面临的问题。

首先，将领域数据或私有数据存储于图数据库中，并通过边来表示数据点之间的关系，可以实现更精准的相关数据查找。常见的向量数据库通过比较查询和文档分片 embeding 之间的相似度来查找相关数据，然而对于稍显复杂的查询，其相似性并不体现在单个文档分片上。例如，用户的查询是“OpenAI 的前核心员工有没有自己创业的？”，这里其实包含两条信息，一是“谁是 OpenAI 的前核心员工”，二是“这些人有没有自己创业的”，相关信息可能出现在多个文档分片中，故使用向量数据库难以为 LLM 提供最相关信息。然而，若使用图数据库，便可以从 Company 节点出发，通过 Empolyment 边遍历核心员工，再将这些员工的 Profile 和 Company 一起构建 embeding，来与查询匹配，从而为 LLM 提供更为精准的相关数据。

其次，知识图谱作为一种高效领域知识表示，可以为识别 LLM 的“幻觉”提供事实支撑。例如：LLM 回答包含某公司董事会成员 A。如果通过向量数据库进行验证，可能某监事 A 总是出现在董事会会议中，其高频出现会被识别为董事会成员；而通过图数据库，可以查找到姓名为 A 的 Person 节点的职位是监事，从而识别出 LLM 的“幻觉”。

再者，将 LLM 作为“大脑”解决复杂问题，其核心思路是将可供选择的工具（例如网页搜索、数值计算、本地数据库访问等）的“说明书”加入提示词，和问题一起交由 LLM 来决定下一步使用哪种工具，以及应该为其提供什么样的输入。对于复杂问题，往往不是一步就能得到结果，所以 LLM 还要和用户一起完成工作流的编排，一般称为 Chain-of-Thought。实际上，由于 LLM 的返回具有选择性（即 LLM 会依据输入做出不同的选择，例如判断为是的情况下调用 A 工具，否则为 B 工具），用 Graph-of-Thought 来抽象这一工作流是更为通用的方法。不难看出，基于图抽象的图计算系统，可以更好的管理这一工作流，其对图数据的高效查询、分析和展示能力，可以实现更透明的观察、更易用的 UI 和更有效的数据管理。

LLM 的特点，决定了它须与私有数据、领域知识和工作流框架充分结合，才能在实际生产中产生价值，而图计算系统可以很好的解决目前 LLM 在这三方面遇到的问题。所以大家坚信图计算作为一项基础技术，将助力 LLM 走向生产，发挥价值。

此外，GraphScope 正在 Text2GQL 领域作出尝试，不仅考虑通过提示词工程来提升准确率，还会尝试通过对开源模型的调优（finetune）来定制更专注的 Text2GQL 模型，进一步提升准确率和查询效率。在 GQL（无论是 Gremlin 还是 Cypher）学习门槛较 SQL 都更高的今天，期待 Text2GQL 的实践，能够让更多的用户连接图数据库，享受图计算带来的价值。