> ​
导读：在数据库的运维实践中，集群迁移与版本升级是及时满足业务需求的关键环节。这篇经验贴分享了使用 NebulaGraph Spark Connector 将多个业务的集群从 NebulaGraph 2.6.2 向 3.8.0 版本迁移，并部署到各自对应新集群中的完整方案，涉及业务隔离集群搭建、跨版本数据转运、脏数据处理等核心要点。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/425/%E5%A5%87%E5%AF%8C%E7%A7%91%E6%8A%80-7.png)


# 一、背景


* 多个业务使用同一套 NebulaGraph 集群,当其中某一个业务有大量耗时查询或者大量数据加载时,这时此集群的压力可能会急剧上升,导致所有的业务出现服务性能极度下降的情况；

* NebulaGraph 使用古早的 2.6.2 版本，很多业务需求较难快速实现。


# 二、需求

* 为每个业务搭建一套属于自己的 NebulaGraph 集群;
* 将旧集群中的各个业务的数据迁移到自己业务对应的新集群中;
* 新集群需要使用 3.8.0 版本 NebulaGraph;
* 旧的 NebulaGraph 集群下线。


# 三、数据迁移工具选型

通过 NebulaGraph 官网查看有没有现成的数据迁移工具，能直接实现我们的需求，调研如下：

* 社区版的 NebulaGraph BR：限制是版本为 3.x 才能用；只能恢复到原集群，不可跨集群等等。遂放弃。
* NebulaGraph Importer：导入数据使用。这个之前没怎么用过，应该是使用官方提供的工具执行相应的命令将数据发送到对应的集群。考虑到失败无法重试的缘故，遂放弃。
* NebulaGraph Exchange：这个主要考虑到配置文件的繁琐性，且我们集群上的 Spark 客户端一般不暴露出来直接使用，都是通过 dolphinscheduler 使用的。遂放弃。
* NebulaGraph Spark Connector：连接器使用，通过官网的 demo 发现这个可以将 NebulaGraph 数据写成 DF 格式，还可以将 DF 格式数据写入 NebulaGraph；且通过 dolphinscheduler 好控制。因此，我们决定使用 NebulaGraph Spark Connector 进行数据迁移。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/425/640%20(3).webp)


# 四、具体步骤


## （一）NebulaGraph to HDFS

运行 NebulaGraph to HDFS 对应的工作流，将 NebulaGraph 数据备份到 HDFS。

edge 类型导入 HDFS 为例：


```
package nebula

import com.vesoft.nebula.connector.connector.{NebulaDataFrameReader, NebulaDataFrameWriter}

import com.vesoft.nebula.connector.{NebulaConnectionConfig, ReadNebulaConfig}

import org.apache.spark.sql.SparkSession

object Edge2HDFS {

  def main(args: Array[String]): Unit = {

    try {

      if (args.length < 4) {

        println("Usage: <space> <edge> <graph_host> <hdfs path>")

        System.exit(-1)

      }

      val space = args(0)

      val edge = args(1)

      val graph_host = args(2)

      val hdfsPath = args(3)

      val spark:SparkSession =SparkSession.builder()

        .appName(space + "_" + edge)

        .getOrCreate()

      val config = NebulaConnectionConfig

        .builder()

        .withMetaAddress(graph_host)

        .withConenctionRetry(2)

        .withExecuteRetry(2)

        .withTimeout(36000000)

        .build()

      val edge_config = ReadNebulaConfig

        .builder()

        .withSpace(space)

        .withLabel(edge)

        .withNoColumn(false)

        .withPartitionNum(400)

        .build()

      val edges = spark.read.nebula(config, edge_config).loadEdgesToDF()

      edges.repartition(400).write.

        format("json").

        mode("overwrite").save(hdfsPath)

    } catch {

      case e: Exception => {

        // 在这里捕获异常，并进行相应的处理

        // 例如，记录异常信息、进行异常恢复操作等

        e.printStackTrace() // 这里只是简单地打印异常信息，你可以根据需要进行适当的处理

      }

    }

}

}
```



## （二）HDFS to NebulaGraph

运行 HDFS to NebulaGraph, 对应的工作流把备份在 HDFS 上的数据加载到 3.8.0 的 NebulaGraph.

edge 类型导入 NebulaGraph 为例：


```
package com.nebula

import com.vesoft.nebula.connector.connector.NebulaDataFrameWriter

import com.vesoft.nebula.connector.{NebulaConnectionConfig, WriteNebulaEdgeConfig}

import org.apache.spark.sql.SparkSession

object Edge2nebula {

  def main(args: Array[String]): Unit = {

    try {

      if (args.length < 5) {

        println("Usage: <space> <edge> <graph_host> <hdfsPath> <meta_host>")

        System.exit(-1)

      }

      val space = args(0)

      val edge = args(1)

      val graph_host = args(2)

      val hdfsPath = args(3)

      val meta_host = args(4)

      val _SPARK_SESSION: SparkSession = SparkSession.builder()

        .appName(edge)

        .getOrCreate()

      val config = NebulaConnectionConfig

        .builder()

        .withMetaAddress(meta_host)

        .withGraphAddress(graph_host)

        .withConenctionRetry(2)

        .withTimeout(36000000)

        .build()

      // HDFS 目录路径

      val edgeHdfsPath = s"hdfs://HACluster" + hdfsPath + "/*.json"

      var edgeDF = _SPARK_SESSION.read

        .format("json")

        .load(edgeHdfsPath)

      edgeDF = edgeDF.withColumnRenamed("_srcId", "_vertexId")

      edgeDF = edgeDF.withColumnRenamed("_dstId", "dstId")

      edgeDF = edgeDF.withColumnRenamed("_rank", "rank")

      edgeDF.show(10)

      val edgeCount = edgeDF.count()

      // 打印记录总数

      println(s"Total number of rows: $edgeCount")

      val nebulaWriteContainConfig: WriteNebulaEdgeConfig = WriteNebulaEdgeConfig

        .builder()

        .withSpace(space)

        .withEdge(edge)

        .withSrcIdField("_vertexId")

        .withSrcPolicy(null)

        .withDstIdField("dstId")

        .withDstPolicy(null)

        .withRankField("rank")

        .withUser("root")

        .withPasswd("nebula")

        .withBatch(50)

        .build()

      edgeDF.write.nebula(config, nebulaWriteContainConfig).writeEdges()

    } catch {

      case e: Exception => {

        // 在这里捕获异常，并进行相应的处理

        // 例如，记录异常信息、进行异常恢复操作等

        e.printStackTrace() // 这里只是简单地打印异常信息，你可以根据需要进行适当的处理

      }

   }

}

}
```

将代码写好编译成 jar 包上传到 dolphinscheduler 并通过 dolphinscheduler 创建对应的工作流就可以用了。

贴一下 Spark 参数：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/425/640%20(4).webp)

## （三）数据量与准确性检验

数据量检验可通过执行 `SHOW STATS` 命令，对比新旧集群的统计信息，确保数据完整无缺失。准确性验证则通过在新旧 NebulaGraph 集群上执行相同的 nGQL 查询语句，对比返回结果是否一致。通过这两种方式，全面验证数据迁移的完整性和准确性，确保业务在新集群上可正常运行。


## 五、遇到的问题

1.读写时可能会遇到

`com.vesoft.nebula.client.graph.exception.IOErrorException: java.net.SocketTimeoutException: Read timed out`

这是我们设置的超时时间太短了。我们把withTimeout(36000000)设置得大一些就好了。

2.导入数据时可能会遇到

`RaftPart buffer is full`

这是我们并发设置得太大了，调整 Spark 参数，降低 Executor 数量，batch 数量等，减小并发。



3.如果遇到 NebulaGraph 中创建 tag 和 edge 使用的属性类型和数据类型不一致的脏数据的话，就无法正常读取数据到 HDFS.

这时候需要下载官网的 nebula-spark-connector 源码调整相应的部分，编译打包上传到自己的 maven 库引用，然后将脏数据找到，进行手动处理，再重新跑一遍 NebulaGraph to HDFS 对应的工作流。


# 六、总结

通过以上步骤，可使用 NebulaGraph Spark Connector 顺利实现复杂业务隔离需求下的 NebulaGraph 集群迁移与版本升级。NebulaGraph Spark Connector 是一个强大的生态工具，能够将 NebulaGraph 中的数据读取为 DF 格式，并支持将 DF 数据写入 NebulaGraph, 具有良好的扩展性和易用性，非常适合大规模数据迁移任务。希望本文能为其他有类似需求的社区用户提供参考与帮助。

可参考官方文档，进一步了解 NebulaGraph Spark Connector：

https://docs.nebula-graph.com.cn/3.6.0/connector/nebula-spark-connector/



​

篇经验贴分享了使用 NebulaGraph Spark Connector 将多个业务的集群从 NebulaGraph 2.6.2 向 3.8.0 版本迁移，并部署到各自对应新集群中的完整方案，涉及业务隔离集群搭建、跨版本数据转运、脏数据处理等核心要点。

复杂业务隔离需求下的 NebulaGraph 集群迁移与版本升级全攻略

在即将来临的暑假，尽情探索图数据库的新世界吧！2025 年开源之夏，NebulaGraph 社区发布了 4 个项目，更适合高校开发者的度假方式来啦～
![](https://pic1.zhimg.com/80/v2-6246d3cd5be02a458f713a84bf247cb5_1440w.png)


参与开源社区的代码贡献，和世界各地的开发者一起成长，这经历可超有含金量，可媲美大厂实习经历！

**2023 开源之夏参与者**

**NebulaGraph contributor 宋同学：**

> “参与 NebulaGraph 开源项目经历是我校招的加分利器，它让我积累了丰富代码经验，熟悉实战开发流程。还能学到课本外的前沿知识、热门技术框架。同时，许多大厂面试官都热衷贡献开源项目，这种共同爱好让面试更像朋友之间的技术交流。最终，我在秋招中顺利斩获了滴滴、小米、京东、快手等多个大厂 offer.”

![](https://pica.zhimg.com/80/v2-852c8f8bf6542ab54b7407d6dbe34628_1440w.png)

（图源宋同学在 nMeetup 上的分享）

# 开源之夏

开源之夏是中国科学院软件研究所于 2020 年发起的“开源软件供应链点亮计划”系列暑期活动，旨在鼓励高校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。

活动联合各大开源社区，针对重要开源软件的开发与维护提供项目开发任务，并向全球高校学生（需年满 18 周岁）开放报名。学生可自主选择感兴趣的项目进行申请，中选后在项目开发者（社区导师）的指导下进行开发。根据项目的难易程度和完成情况，结项者将获取开源之夏劳务报酬和结项证书。

💰**基础项目**：8000

💰**进阶项目**：12000

# NebulaGraph

NebulaGraph 是一个可靠的分布式、线性扩容、性能高效的图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时的图数据库解决方案。

2019 年 5 月 15 日，NebulaGraph 在 GitHub 开源 alpha 版本，拥有遍布全球的用户和开发者以及活跃的社区，GitHub star 数超 11k.

作为开源项目，NebulaGraph 始终重视代码共建共享和高校开发者的培养，连续 5 年参与中国科学院软件研究所发起的开源之夏，鼓励全球高校开发者参与开源贡献，为社区注入新鲜血液。

# 为什么选择开源之夏 x NebulaGraph 项目？

* 代码能力跃升：你的代码将运行在支撑超大规模数据集群的图数据库中。

* 实习直通车：顺利结项并经导师推荐，将拥有 NebulaGraph 实习机会。

* 与大牛同行：4 位顶级导师带你玩转世界级分布式图数据库。

* 简历镀金：参与 GitHub 万星项目，开源贡献记录永久可见。

* 硬核成长：从内核到生态工具，贡献真实应用场景。

# NebulaGraph 项目介绍

## 01 NebulaGraph 支持向量近似近邻检索

* 项目难度：进阶

* 编程语言：C++

* 技能要求：

1. 熟悉 C++，对分布式数据库有一定开发经验。

2. 掌握向量检索的基本原理和算法，如 HNSW、IVF、Annoy 等。

* 项目描述：LLM 的创新推动了很多 AI 应用的落地，构建此类应用通常采用 RAG(Retrieval-Augmented Generation) 架构模式，RAG 被认为是解决 LLM AI 幻觉的有效方式，并可以为其提供更丰富的上下文使得 LLM 的响应更准确。向量近似近邻检索，即 Approximate Nearest Neighbor (ANN) Search，可以在高维向量空间中快速检索相似向量并为 RAG 提供后端支持。然而，目前 NebulaGraph 尚未支持向量相关的功能，这限制了其在 AI 场景中的应用潜力。若在 NebulaGraph 中支持向量，将为其提供向量持久化存储能力、利用数据库的扩展性来满足业务数据规模扩张需求、实现知识图谱和向量检索结合的 GraphRAG 来改善传统 RAG 的一些痛点。

* 项目产出：

1. 实现向量数据类型并支持其持久化。

2. 实现向量相关的 DDL 语句，包括 create tag、create index 等语句。

3. 实现向量相关的 DML 语句，包括 insert、update、delete 等语句。

4. 设计并实现 ANN Search 语句。

5. 满足分布式一致性和可用性要求，保证向量数据副本一致性及内存磁盘数据一致性。

* 导师：志鹏，NebulaGraph Committer.是一位开发经验丰富的图数据库内核研发工程师。在开源之夏，他以硬核的图数据库内核研发功底备受认可。志鹏的指导风格耐心细致，同时对新技术充满热情。

* 邮箱：kyle.cao@vesoft.com

## 02 NebulaGraph 集成 PyG

* 项目难度：基础

* 编程语言：Python

* 技能要求：需要熟悉 PyG 的 remote server 机制和 FeatureStore 与 GraphStore 抽象，并了解 NebulaGraph 的 基本知识，利用 NebulaGraph 的 GraphClient 和 StorageClient，实现 PyG FeatureStore 与 GraphStore.

* 项目描述：PyG 是一个用于在 PyTorch 中创建和训练图神经网络的强大而灵活的框架。它简化了图数据的处理，并提供了各种 GNN 模型的构建块，助力研究人员和开发者在图结构数据上进行创新。NebulaGraph 是一款开源的、分布式的、易扩展的原生图数据库，能够承载包含数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查询。PyG 作为 GNN 的训练推理框架、它的图抽象支持从远程的分布式基础设施上存取，这个抽象叫“remote server”，有了这个抽象，我们可以连接两个项目，让 PyG 社区受益于 NebulaGraph 的超大规模分布式图存储，驱动分布式图申请网络的训练。

* 项目产出：设计实现 PyG 的 NebulaGraph remote server ，作为其 FeatureStore 与 GraphStore.

* 导师：思为，NebulaGraph Committer, NebulaGraph GenAI Team Leader. 作为 GraphRAG 的提出者，思为拥有无限想象力，指导风格充满激情与活力，善于引导你突破常规思维，大胆尝试新的技术方案。在他的团队里，每一个创意都能得到充分的尊重与支持。

* 邮箱：[wey.gu](http://wey.gu/)@vesoft.com

## 03 为 NebulaGraph 支持 Airbyte

* 项目难度：基础

* 编程语言：Java

* 技能要求：

1. 对 Airbyte 框架有一定的了解，有丰富的 Java 开发经验，对反射有充足的实践经验和认知。

2. 对数据的 ETL 过程有一定的了解。

* 项目描述：Airbyte 是一款领先的数据集成平台，专注于构建和管理 ETL（提取、转换、加载） 或 ELT（提取、加载、转换） 数据管道，帮助用户将来自多种源头（如 API、数据库、文件等）的数据高效迁移到现代数据存储与分析平台，包括 数据仓库、数据湖以及新兴的 数据湖仓等。期望在 NebulaGraph 上增加对 Airbyte 的支持，方便用户可以通过 Airbyte 将各种数据源的数据，导入到 NebulaGraph 中。

* 项目产出：

1. 增加 Airbyte 的 Writer，支持数据通过 Airbyte 从 Mysql 到 Nebulagraph 的迁移

2. 代码能够合入到 Airbyte 仓库，满足相关开发测试规范

* 导师：秋梵，NebulaGraph Contributor, 开源之夏 2024 年 NebulaGraph 项目导师，带领晓阳同学顺利结项，并获得 2024 年开源之夏“最快进步奖”。不仅热爱开源，秋梵还是一枚二次元爱好者，是能一起写代码也能一起追番的“中国好导师”。

* 邮箱：knqiufan@foxmail.com

## 04 为 NebulaGraph Exchange 支持数据源插件化

* 项目难度：基础

* 编程语言：Java、Scala

* 技能要求：

1. 对 Spark 分布式框架有一定的了解，有丰富的 Java 或 Scala 开发经验，对反射有充足的实践经验和认知。

2. 熟悉当前 NebulaGraph Exchange 项目的架构流程，了解 NebulaGraph Exchange 中的配置管理模块和数据源管理模块的逻辑流程。

* 项目描述：NebulaGraph Exchange 是一款专业的数据导入工具，致力于将各类异构数据源的高效导入到 NebulaGraph 图数据库中。当前版本已支持包括关系型数据库、NoSQL、大数据平台等在内的十余种主流数据源。但 NebulaGraph Exchange 的数据源都是内嵌在 NebulaGraph Exchange 的核心代码中，每添加一种新数据源都需要进行代码扩展和代码修改，然后进行重新打包发版，存在数据源与核心代码高度内聚的问题，使得添加新数据源和维护已有数据源的成本增加。基于以上背景，该项目旨在实现 NebulaGraph Exchange 数据源的插件化架构，通过标准接口和扩展机制，使 NebulaGraph Exchange 能够在无需修改核心代码的情况下，通过引入插件 JAR 包的方式灵活支持新的数据源。

* 项目产出：

1. 对当前 NebulaGraph Exchange 架构进行优化改进，将数据源相关的功能流程抽象化，实现数据导入和数据源管理的低耦合结构。

2. 实现不同数据源的插件化模块化开发，利用反射实现 NebulaGraph Exchange 对不同数据源插件 jar 包的动态加载和调用，从而实现各个数据源的独立化维护，增强 NebulaGraph Exchange 的数据源支持的能力，实现 NebulaGraph Exchange 数据源的插件化开发和维护，为用户自定义特殊的数据源提供抽象能力。

* 导师：昌圆，NebulaGraph Java 系列生态工具（NebulaGraph Exchange、NebulaGraph Flink Connector 等） Maintainer, 常被社区小伙伴称赞为“顶级大佬”。此外，昌圆发表了多篇图数据库相关专利，学术能力也一级棒，真·全能型导师。

* 邮箱：anqi.wang@vesoft.com

## 开源之夏活动流程

![](https://pic1.zhimg.com/80/v2-e9955e2ad3718ef1a734a605b5b9788c_1440w.png)


# To Do List

如果你对 NebulaGraph 发布的项目感兴趣，在接下来的一个月内，你需要做的事：

* 进入开源之夏官网，了解开源之夏每个流程的时间，并查看 NebulaGraph 项目详情；

* 访问 NebulaGraph 官网，查看 NebulaGraph 文档，进一步了解我们；

* 填写项目意向问卷，与 NebulaGraph 官方近距离交流项目详情⬇️；

* 根据开源之夏规定时间，完善个人信息并填写项目申请；

* 等待中选结果。

![](https://picx.zhimg.com/80/v2-a2256b10e92661a087125ed9c570a275_1440w.gif)



祝大家在开源世界里，收获满满～

度过一个有意义的暑假：）

开源之夏 2025 NebulaGraph 项目介绍

开源之夏｜从 NebulaGraph 开启你的图数据库开源之旅！

> 导读：作者黄春晖，震坤行大数据平台高级开发工程师，专注于工业 MRO 领域数据中台架构设计，2024 年开始推动 NebulaGraph 在公司多业务场景的深度集成，包括智能采购决策，供应链风控体系等。本文从业务痛点、NebulaGraph 选型与架构、业务场景、未来规划等方面，介绍 NebulaGraph 在震坤行的应用实践。

![](https://picx.zhimg.com/80/v2-21b824ac4d5404fe8612a05215408263_1440w.jpg?source=d16d100b)

# 一、业务痛点

震坤行工业超市是一家专注于数字化转型的线上工业用品服务平台，致力于为客户提供透明、高效、低成本的一站式工业品解决方案。

![](https://pic1.zhimg.com/80/v2-e5f606381161880efafda61c669ea9fb_1440w.jpg?source=d16d100b)

我们通过数字化管理工具和大数据技术，协同合作伙伴优化供应链全链路，覆盖从采购、制造到交付的全流程。同时，震坤行提供优质的工业品选购服务，结合自建仓储物流体系，为线上线下客户打造高效、可靠的工业品采购与交付体验。

![](https://picx.zhimg.com/80/v2-395711080c894bac9cd05999e52ae4ea_1440w.jpg?source=d16d100b)


我们在引入 NebulaGraph之前，业务痛点主要是以下三个方面：

* **数据规模与复杂性的双重压力**：业务扩展导致客户-供应商关系、客户行为等复杂关系数据快速增长，传统数据库难以高效存储和查询，实时分析需求难以满足。

* **关系数据库的局限性**：关系数据库在多表连接等操作上性能瓶颈显著，无法支持复杂关系数据的实时分析和深度挖掘，影响供应链优化等高价值场景落地。

* **数据价值落地困难**：复杂关系数据在供应链优化、风险预警等场景中的应用，面临数据建模、算法优化和效果验证等挑战，技术与业务深度融合是关键。

# 二、NebulaGraph 选型与架构

## （一）Why NebulaGraph？

* **高效的关系表达**：通过图结构直观表示实体及其关系，节点表示实体（如客户、供应商、商品），边表示关系（如供应、购买）。特别适合震坤行复杂的供应链网络，能清晰呈现多层次的客户-商品-供应商关系。

* **强大的路径分析能力**：支持高效的图遍历算法，能够快速进行路径分析（如最短路径、共同邻居等），为震坤行提供强大工具，用于挖掘客户需求、优化供应链路径和识别客户风险。

* **实时查询与响应**：具备高并发、低延迟的查询能力，支持实时推荐、风险预警等场景，满足震坤行对实时性的需求，助力用户行为分析和供应链动态调整，快速响应业务变化。

* **可扩展性与高性能**：采用分布式和存算分离的架构，支持水平扩展，轻松应对震坤行数据量的快速增长，确保高并发场景下依然保持高性能。

## （二）技术架构

![](https://pic1.zhimg.com/80/v2-302e108521f4cbfb16e9b4e19880608a_1440w.jpg?source=d16d100b)

1.**数据采集**

* 业务数据：来源于 ERP、MySQL、SQL Server 等系统，通过 DataX 或 Flink-CDC 工具同步到阿里云 MaxCompute.

* 埋点数据：通过 SDK 采集客户行为数据（如浏览路径、订单流程）并上传至阿里云 DataHub.

* 非结构化数据：包括合同、图片、文档等，通过 OSS 进行存储。

2.**数据加工**

数据采集完毕后，我们会采用以下两种方式进行计算。

* 离线计算：利用 MaxCompute 和 Spark 处理大规模批量数据，适用于数据清洗、聚合等任务。

* 实时计算：通过 Flink 处理流式数据，支持实时分析和响应。

3.**数据存储-NebulaGraph**

目前我们部署了两套 NebulaGraph 集群：

* 在线服务集群：面向实时查询结果，主要用于客户行为路径分析、客户关系查询等场景。

* 图算法集群：处理复杂图算法，支持供应商风险评估等高级分析。

4.**数据服务**

* API 网关：提供统一接口，支持应用鉴权、负载均衡和流量控制，确保服务的稳定性和安全性。

* 个性化 API：根据不同平台的不同业务需求提供定制化接口，例如客户行为路径分析、客户关系查询、供应商风险评估。

# 三、应用实践

## （一）应用场景之精准推荐

![](https://picx.zhimg.com/80/v2-1fd42e4f209aff3e6c11b90add12bf10_1440w.jpg?source=d16d100b)

在使用 NebulaGraph 前，我们电商领域的精准推荐一直存在挑战。我们之前主要依赖 Elasticsearch 进行推荐，这种方式主要基于客户输入的关键词，比如螺丝的型号或规格，然后与我们的产品名称和属性进行匹配。然而，这种简单的关键词匹配方式对用户的真实意图分析不够全面，较难提供个性化的精准推荐。

我们有自己的线上商城，包括官网、App、小程序，对基础用户信息是有记录的，因此，我们计划引入擅长处理实体关系的 NebulaGraph 图数据库，利用用户特征和用户与商品的行为关系数据，构建更智能的推荐系统。

在引入 NebulaGraph 进行推荐和搜索优化的过程中，我们构建了一个完整的数据处理流程，解决传统推荐系统中的痛点。

![](https://picx.zhimg.com/80/v2-6a68fdfef27fa3413a6267f65cefdfad_1440w.jpg?source=d16d100b)

1.**数据输入与建模**

我们首先将线上的用户行为数据（如浏览、点击、购买等）和商品数据（如价格、类别、品牌等）作为输入。这些数据通过数据处理工具（如 Flink 和 DataX）进行清洗和转换，并加载到 NebulaGraph 中进行图建模。

2.**图数据库结构**

在 NebulaGraph 中，我们构建了一个以商品和用户为核心的图结构。商品节点包含价格、类别、品牌等属性，而用户节点则关联到客户信息。用户与商品之间的关系通过行为轨迹（如浏览、点击、购买、收藏等）建立，形成一个复杂的关系网络。

3.**实时特征提取与推荐优化**

通过 NebulaGraph 的原生 nGQL 查询语言，我们能够实时提取用户在平台上的行为特征，如浏览时长、点击次数、品牌偏好、价格偏好等。这些特征通过 API 接口实时返回给搜索引擎和推荐系统。

在推荐系统中，这些实时特征被用于优化召回和排序过程。具体来说：

* 召回阶段：引入实时特征以生成更相关的候选商品集合。

* 排序阶段：利用特征对候选商品进行排序，确保推荐结果更符合用户偏好。

这种优化显著提升了推荐的准确性和个性化程度，尤其是在新客户冷启动场景中。对于新客户，我们在注册时识别其行业和区域信息，并根据历史数据中相同行业或区域的用户行为，为其推荐相关商品。

**成果与规划**

**通过引入 NebulaGraph 进行推荐和搜索优化，我们在搜索推荐的点击率上取得了显著提升，整体提升了 15%，下单转化率提升 5%**。

未来，我们计划拓展更多关系数据维度（如客户需求采集），进一步提升推荐精准性，并引入 AI 实时学习机制，动态适应用户行为变化，实现推荐系统的自我优化，为更多用户提供了一个更加智能和个性化的购物体验。

## （二）应用场景之供应链

![](https://pic1.zhimg.com/80/v2-60027d0a73dbab04b24b2b4363038b7e_1440w.jpg?source=d16d100b)


在震坤行的供应链管理中，我们面临四个主要痛点，这些痛点影响了我们的运营效率和客户体验。

* **供应商整合与采购成本**：我们对接的供应商类型多样，包括原厂、代理和贸易商。由于缺乏统一的供应商信息整合，我们在采购决策时面临信息割裂的问题。

* **库存管理**：震坤行在全国拥有 32 个仓库，其中包括专门存储化学品和危险品的特殊仓库。之前的库存管理是单节点的，无法实现全国库存的全局可视化管理

* **履约协调**：客户订单处理需要智能选择发货仓库，以满足客户的交货时间和地址要求。

* **交付精准度**：在交付环节，我们面临信息不通畅、路径规划低效和服务体验受损的问题。物流信息查询困难、交货时间预测不准确以及配送路线不佳都影响了客户体验。

![](https://pic1.zhimg.com/80/v2-7028e0f1f45e4058da0b0ff3dcc00e91_1440w.jpg?source=d16d100b)

震坤行的供应链网络以商品为核心，客户需求驱动整个流程。商品从供应商流向仓库，再通过物流网络精准交付给客户。在 NebulaGraph 的支持下，从采购、库存、履约到最终交付，我们构建了一个高效、可视化的供应链网络。

1.**采购决策**

![](https://picx.zhimg.com/80/v2-f6e405faceebccc1be423c1bc770ded7_1440w.jpg?source=d16d100b)

客户订单是采购决策的起点。当客户订单提交后，系统会根据订单中的商品需求、数量、交货地址等信息，结合商品的价格、运费和交期等属性，在 NebulaGraph 中进行智能分析。通过实时查询和特征提取，系统会综合评估商品的评价、运费等信息，智能选择最合适的供应商渠道。最终，通过智能采购决策，系统自动推荐供应商和备选供应商，帮助公司优化采购成本，同时确保客户订单的最佳交付效果。

2.**库存管理**

![](https://picx.zhimg.com/80/v2-15e2badb215409141b9ba695de381b35_1440w.jpg?source=d16d100b)


我们的商品在库存中按照批次、数量、状态（如商品是否完好无损、存放时长）等属性进行管理。通过实时数据共享，仓库运营人员可以即时查询到商品在全国不同仓库的状态，从而更好地进行上下架操作和库存管理，制定更有效的库存策略，减少积压商品的占比，并实现联合库存管理和智能补货。

3.**智能履约**

![](https://pic1.zhimg.com/80/v2-9d06a600e2b75f6a585c28ca3b621821_1440w.jpg?source=d16d100b)


我们通过智能履约系统优化了从客户订单到物流配送的整个流程。当客户订单提交后，系统会根据订单中的需求数量、要求交期和收货地址等信息，智能检测并分配库存。例如，如果客户需要 100 个商品，系统会从不同仓库智能分配库存，可能从 A 仓库发 50 个，从 B 仓库发 50 个，然后统一配送。这种智能库存管理不仅提高了库存周转率，还降低了仓储成本，优化了整体供应链效率。

4.**精准交付**

![](https://picx.zhimg.com/80/v2-310e9ca1c29df3f192f59532cbc49708_1440w.jpg?source=d16d100b)


当客户订单生成后，系统会从相应仓库出货，并将订单信息实时传输到物流中心，如不同仓库库存和车队的发货信息。我们会对这些信息进行全局优化，例如，如果两个订单需要运往同一地区，系统会智能合并订单，使用同一辆车进行配送，从而降低运输成本。此外，我们还利用实时物流共享和 NebulaGraph 最短路径算法，优化配送路线，确保货物能够按时、高效地送达客户手中。

**成果**

* **客户满意度提升：透明的物流信息、精准的交付和高效的履约流程，显著提升了客户满意度，客户售后工单数减少20%**。

* 智能化与自动化：基于 NebulaGraph 的图算法（如最短路径算法、协同过滤算法等）可以自动优化库存、采购、履约和配送等环节，减少人为干预。此外，我们通过 NebulaGraph 搭建的智能供应链系统能够快速响应市场变化，提升竞争力。

* **成本降低与效率提升：通过优化库存管理、采购策略和配送路线，显著降低了运营成本，有货率提升15%，呆滞库存减少10%**。

#  四、未来规划

## （一）企业级知识库

![](https://pica.zhimg.com/80/v2-e1ba86984282c3b89b7b762dfb61d6a3_1440w.jpg?source=d16d100b)


![](https://picx.zhimg.com/80/v2-bd71e0dcbd950912e1a55597461d330c_1440w.jpg?source=d16d100b)


我们正在与 NebulaGrph GenAI 团队规划构建属于震坤行的企业级知识库，希望能高效整合结构化和非结构化数据，让我们的内部团队，如销售、客服、运营等人员，通过知识库实现智能问答，快速获取所需信息，提高工作效率。

## （二）智能风控体系

![](https://picx.zhimg.com/80/v2-38f57f85e773d82a36ccb48a7afc2877_1440w.jpg?source=d16d100b)

![](https://picx.zhimg.com/80/v2-a1b339e5f1f3c2f7af9cb2b5bd624e89_1440w.jpg?source=d16d100b)


我们亦在探索通过 NebulaGraph 去构建一个智能风控体系，用于全面识别和管理客户与供应商的潜在风险。风控主体分为客户、供应商两类，基于工商信息、企业征信、历史履约信息、新闻舆情等数据构建风控网络，通过子公司、股权、关键任职关系等数据识别客户和供应商的关系，做到客商风控一体。

如客户进行交易时，系统实时分析客户交易行为及司法风险，同时关联得到相关供应商的经营风险和采购行为，将业务规则映射 nGQL 抽取出客商风控特征，补充使用社区发现算法，判断是否存在欺诈风险，降低供应链风险。

# 五、总结

NebulaGraph 在震坤行的落地，是一次技术赋能业务的深度实践。通过强大的关系分析与处理能力，震坤行在精准推荐、供应链优化等业务场景取得了显著成果。精准推荐从“猜你喜欢”进化为“懂你需要”，供应链从“被动响应”转变为“主动优化”，客户满意度和运营效率双双提升。

未来，震坤行与 NebulaGraph 将进一步探索知识库和智能风控的深度应用，用 AI 技术重塑工业品电商的未来，释放更大的数字化转型潜力。

「ps：本文整理自震坤行在 NebulaGraph 社区 nMeetup 上的分享，震坤行目前已升级为 NebulaGraph 企业版」

本文从业务痛点、NebulaGraph 选型与架构、业务场景、未来规划等方面，介绍 NebulaGraph 在震坤行的应用实践。

震坤行工业超市全链路优化｜推荐成单与供应链管理效益均提升 15 %

> 导读： 
作者郑皓月，携程集团高级云原生研发工程师，专注于分布式存储领域。
图数据库在携程是首次落地，为接入携程集团研发体系适配现有系统，**自 2021 年起，郑老师及其团队对NebulaGraph 进行了一系列定制化改造。截止 2024 年，已有包括酒店、机票、金融在内的 16 个部门接入 NebulaGraph.** 
本文从 NebulaGraph 架构、部署及客户端改造等方面，介绍携程集团维护多云集群下多套 NebulaGraph 环境的经验，与三中心、跨域多活的部署策略。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/0414banner-02.jpg)



# 一、背景

为了满足越来越多 BU 对知识图谱、地理信息查询，图推理等业务场景的需求，自 2021 年起，我们首次尝试在携程的基础设施中引入了图技术。

在评估多种图数据库产品后，考虑到 NebulaGraph 采用计算存储分离的架构，具有高可扩展性，使用 Raft 协议保证数据的强一致性，支持千亿级超大规模数据集，并且 NebulaGraph 社区活跃，响应速度快，我们最终选择了 NebulaGraph 来构建我们的图数据库平台。

# 二、NebulaGraph 平台架构

## （一）架构概览

![](https://pic1.zhimg.com/80/v2-1455f18f3395859543db51daa4902cd5_1440w.jpg?source=d16d100b)

NebulaGraph 平台的架构设计旨在提供高效、可扩展且易于管理的图数据库服务。该平台基于 Kubernetes 进行部署，利用 Custom Resource Definitions（CRD）来管理 Graph、Meta 和 Storage 三个关键的 StatefulSets. 每个 StatefulSet 都包含了一个 NebulaGraph 服务容器以及一个 Sidecar 用于收集核心指标。

我们根据集群的类型，为部署在不同 Kubernetes 集群（三机房部署）的 MetaService 申请 DNS 用于服务发现，属于同一个 Kubernetes 集群(单机房部署或蓝绿集群)的 MetaService 则以 FQDN 的形式来组织。

首先，用户在 PaaS 平台申请图数据库资源。随后，InfinityStones 运维支撑平台通过调用 Kubernetes Client API 来生成相应的 CRD. 一旦 Operator 检测到 CRD 变更，将会在 Kubernetes 集群中创建对应的资源。Sidecar 会将采集到的 NebulaGraph 服务指标推送至 VictoriaMetrics，并最终在 Grafana 监控告警平台上展示，为用户提供实时的系统状态监控。

此外，集群信息会被注册到 Qconfig 配置中心，应用端通过拉取 Qconfig 中对应的配置来访问集群。用户可以在 SiteController 流量分发控制平台上进行自主路由，以优化流量分配和提升服务性能。

##  （二）隔离级别

![](https://picx.zhimg.com/80/v2-87868e203c2bef6a10737de54ccb2e03_1440w.jpg?source=d16d100b)


通过调研 NebulaGraph 集群的部署方式，发现大部分公司在部署集群时采用的是集群内多 Space 租户的形式，也就是只部署少量 NebulaGraph 集群，集群内部通过业务场景划分为多个 Space 分配给用户使用, Space 之间存在资源竞争，隔离等级低，一旦宿主机发生故障将会有多个用户受到影响，但是运维简单，有新用户接入时只需创建 Space，集群资源利用率高。

考虑到不同用户对集群资源的使用跟业务类型强相关，差距较大，我们采用单集群单 Space 租户的集群级别隔离，针对每个用户的业务创建新集群，由 Kubernetes 调度器进度调度分配，隔离等级高，故障影响范围小，但可能会造成一定程度的资源浪费。

##  （三）部署策略

我们提供了三种部署策略以适应不同的业务需求。

1. 单机房部署策略

![](https://pica.zhimg.com/80/v2-1e3e077498ecc08ce621fe2b069c02bb_1440w.jpg?source=d16d100b)


单机房部署策略将集群的 Graph、Meta 和 Storage 服务集中部署在一个 IDC 内。避免了集群内部节点跨机房通信问题，通过多副本的方式保证高可用。但应用与集群之间可能存在跨机房调用，并且无法避免机房级宕机导致的服务不可用，适用于非核心应用。

2. 三中心部署策略

![](https://picx.zhimg.com/80/v2-1e3e077498ecc08ce621fe2b069c02bb_1440w.jpg?source=d16d100b)


三中心部署策略将 Graph、Meta 和 Storage 服务被分别部署在三个不同的 IDC 中。任一机房宕机，集群仍然能够提供服务，从而实现了机房级的容灾保障。各 IDC 的数据通过 Raft 协议保证强一致性，适用于核心应用。

然而，由于集群内部节点存在跨机房通信，会带来一定程度的性能损耗。考虑到不同用户对集群资源的使用跟业务类型强相关，差距较大，我们采用单集群单 Space 租户的集群级别隔离，针对每个用户的业务创建新集群，由 Kubernetes 调度器进度调度分配，隔离等级高，故障影响范围小，但可能会造成一定程度的资源浪费。

3. 跨域多活部署

![](https://picx.zhimg.com/80/v2-e5e9cae393167216efba2bff282bf5f3_1440w.jpg?source=d16d100b)


为解决上述痛点，我们实现了跨域多活部署，也就是蓝绿集群。将完整的集群部署在多个 IDC 中，通过应用端双写来保证集群间数据一致性。客户端可以选择就近访问同 IDC 的集群来减少网络开销。

图中是一个典型的应用端双写保证集群间数据一致性的例子。首先，应用端将数据变更推送到消息队列，例如 Kafka, 部署在不同 IDC 的 Service 再通过不同的 Consumer group 来消费同一份数据，将数据变更写入到对应 IDC 的集群中。

##  （四）部署成效

![](https://picx.zhimg.com/80/v2-310d2c3da526077789a92d7502e0844f_1440w.jpg?source=d16d100b)


这是我们生产环境中酒店业务蓝绿部署和三机房部署的对比，可以看到蓝绿集群的访问延迟相比三机房部署降低了约一半。蓝绿双活部署是在性能和可用性上一个折中的选择，减少了大约 70% 查询过程中数据跨域带来的网络性能损耗，同时提供了机房级容灾保障，ATP 能达到 4 个 9. 目前我们将跨域双活扩展到了跨域多活，支持在多个 IDC 中部署集群。

# 三、NebulaGraph 客户端改造

##  （一）读写分离

![](https://picx.zhimg.com/80/v2-791f5443ad22b2e79fa2e079a20cf2b7_1440w.jpg?source=d16d100b)


对于蓝绿集群，我们使用双写的方式保证数据一致性。在发生故障时，我们希望访问故障 IDC 的应用端能继续访问另一个集群，而不会将本 IDC 的数据重复写入，因此读和写的逻辑通常是不同的。我们基于 IDC 和访问策略构造了不同的 nebula pool.

对于查询操作（如 match、go、show、describe），客户端将访问 Read Pool，而例如 create, drop，insert， delete 等 schema 定义和数据操控操作将访问write pool. 如果访问策略为就近访问，我们会将 read pool 和 write pool 合并。

我们还增加了流量分配功能，访问策略为"all" 时，通过权重轮询部署在不同 IDC 的集群，可以达到按比例分配访问流量的目的，从而实现负载均衡。

当路由策略设置为"read near"或"write near"时，客户端只会访问同属一个 IDC 的 NebulaGraph 集群，实现就近访问。如果访问策略设置为"all"，代表客户端可以访问所有集群，并且将根据流量分配策略按权重轮询多个 Nebula 集群，实现流量分发。

##  （二）故障切换

![](https://picx.zhimg.com/80/v2-5924ca7b6cd51fc1467c23e7eef61e21_1440w.jpg?source=d16d100b)


我们通过将集群信息注册到 Qconfig 配置中心， 实现了 NebulaGraph 配置的热推送。任何配置的修改都会实时推送到应用端，使客户端能够根据最新的集群配置来初始化新的连接池，从而进行正确的路由。我们还在 Sitecontroller 平台上集成了流量分配和访问策略切换的功能，用户可以根据业务需求自行调整配置。

##  （三）Session 管理

![](https://pica.zhimg.com/80/v2-5d5a9930ba54c92747223cfcc6486c84_1440w.jpg?source=d16d100b)


我们在初次使用 NebulaGraph 时，使用的是 2.5.0 版本，当时客户端的一些管理功能还比较薄弱，例如多线程环境下访问 Session 时可能存在线程不安全的问题，以及 Session 过期或失效需要用户自行处理。因此，我们对客户端进行了一些改造。

每一个 SessionHolder 都会维护一个基于访问策略和 IDC 构建的 Sessionmap，创建阻塞队列来管理 Session 的数量和版本，当管理中心有配置变更时，将会根据最新的配置释放和重建 Session 队列。客户端尝试从 Session 队列中获取 Session，通过 borrow and return的方式，一个执行器只能获得一个 Session，避免了 Session 共用带来的问题。

为增强 Session 复用，我们将根据执行结果来判断是否需要释放 Session. 例如因为网络抖动或查询语法错误导致的执行失败，没有必要释放重建 Session, 进而对 Meta 造成压力。Graph 每 10 秒会把 Session 信息持久化到 Meta，如果 Session 永不过期，Meta 会产生大量 Wal，负担很重。因此，我们将 Session 的过期时间设置为 24 小时，在获取到过期 Session 时，会重试一次执行，以平衡 Session 复用和 Meta 负载。

在实际生产中，我们注意到用户在执行周期性任务时可能会遇到 Session 批量过期的情况。为了解决这一问题，我们在将 Session 放回队列时会记录其最后使用时间。如果发现 Session 可能已经过期，先执行一次检查操作，以确定其是否仍然有效。如果 Session 确实失效，将重试直至获取到有效的 Session.

##  （四）语句生成器封装

![](https://picx.zhimg.com/80/v2-e712c0781029d07105882c6df9562542_1440w.jpg?source=d16d100b)

NebulaGraph 提供的 Opencypher 和自研的 nGQL 语法都是声明式语言，风格上类似 SQL, 对于用户来说易上手，但是在使用过程中不容易埋点监控。基于这个原因，我们重新封装了一个过程式语句生成器，以函数式数据流的方式重写了 nGQL 语法，接入了公司的监控日志指标平台，保证了 NebulaGraph 服务的可观测性，帮助用户迅速排障。

# 四、调优实践

最后，我还想分享一下我们在 NebulaGraph 实际落地过程中遇到的一些性能问题及调优实践。

![](https://pic1.zhimg.com/80/v2-53bee016052bd76d38d292c9e57585cf_1440w.jpg?source=d16d100b)

国际机票拆票集群在 AWS 的集群配置是 7 个 16c128g600g 的 Storage 节点，以及 8 个 4c16g10g 的 Graph节点，这样一个集群每月成本大概是 4.5w 人民币。

当时集群边写入 QPS 约 2w+，边删除 QPS 约 300-1000，宿主机的 CPU 利用率达到 50%，机票团队增加了新的数据源，希望我们能在不扩容的情况下新增一种边类型的写入，QPS 大概会增加 23%。除了 blockcache 的配置是 40G，大约 Storage节点内存的1/3，以及根据机器的规格调整了一些线程数外，其他的参数都是 NebulaGraph 的默认配置。

![](https://picx.zhimg.com/80/v2-9179c8f11479518deb3ad597b0610f11_1440w.jpg?source=d16d100b)

为了满足机票团队的需求，我们对 RocksDB 以及一些 NebulaGraph 的参数进行了调整。

write_buffer_size 默认是 256M, max_write_buffer_number 为 8，也就是说 memtable 大小是 256M,有 8个 memtable,而 target_file_size_base 默认是64M，也就是说 memtable 每 flush 一次，会生成 4 个 sst.

* 调整 target_file_size_base 为 256M，增加 sst 大小，减少 compact 频率，sst 落地后变为 256M，此时 CPU 利用率,io write 频率无明显变化，每次 io write 数据量尖峰变高。

* 调整 min_write_buffer_number_to_merge 为 4(默认为1)，每 4 个 memtable 写满 flush 一次，减少了 flush 的频率，io write 频率明显下降，CPU 使用率波动较之前平缓。

* 调整 level0_slowdown_writes_trigger 为 20，当 L0 文件数达到 20 的时候将会降低写入速度，这个参数默认为 8，跟 memtable 的数量一样，可能会造成 write stall.

* 调整 level0_file_num_compaction_trigger 为 10，当 L0 文件数达到 10 时，触发 L0 到 L1 compaction. level0_stop_writes_trigger 为 40，当 L0 文件数达到 40 时，停止写入。此时 io write 频率进一步下降。

* 调整 rocksdb_rate_limit，限制写入速度为 20MB/s，该参数默认没有设置，据我们观察大约为 50MB/s。该参数为 NebulaGraph 封装参数，并非 Rocksdb 本身的参数。此时 io write 尖峰基本消除，相较初始 Storage，CPU 利用率明显更加平滑。磁盘读写的频率下降非常明显，在接入新边类型数据后，可以看到边插入速率大约增加了 700，而 Storage CPU 无明显增长。

# 五、未来展望

![](https://picx.zhimg.com/80/v2-d10303c2ca64439ca5da50b00110a819_1440w.jpg?source=d16d100b)


##  （一）故障感知自动切换

目前，当机房发生故障时，用户需要到 SiteController 平台手动调整路由访问策略，人为介入可能会导致响应不及时。未来，我们期望客户端能够感知机房级故障并且自动切换访问策略。

##  （二）Raft Listener 实现集群间数据同步

为了解决集群间的数据一致性问题，我们计划引入 Raft Listener 机制来实现数据同步。在现有的架构中，集群间需要通过双写来保证数据一致性，而海外集群目前只能作为独立集群存在，亟需数据同步功能。Listener 在 Raft 中并不参与投票，只是负责监听，Meta 和 Storage leader 在接受到写请求时，除了同步一份数据给 Follower，也会同步一份数据给 Listener,在获得同步日志后，Listener 可以将不同操作的数据组装成一个请求发送给另一个集群，从而实现数据同步。

通过这些未来的改进，NebulaGraph 将提供更加稳定、高效和自动化的图数据库服务，满足携程业务的不断增长和变化的需求。

---

推荐阅读⬇️

[携程 x NebulaGraph｜业务增益 32%，NebulaGraph 在携程风控场景下的落地实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247512477&idx=1&sn=cc847b80046a99937d6b3ef33ad9287f&scene=21#wechat_redirect)

NebulaGraph 在携程集团的应用与实践

携程集团千亿级全场景业务实践｜NebulaGraph 实现 23% QPS 跃升与毫秒级响应

> 关于作者：郝鑫，Airwallex 空中云汇风控平台工程师，nebula-go Maintainer.自 2023 年底起，重点做图计算相关工作，业务场景侧重于风控。

![](https://pic1.zhimg.com/80/v2-94c6811f5a30542210afda39034a62c8_1440w.jpg?source=d16d100b)


# 一、Airwallex 空中云汇 

作为知名的全球支付及金融平台，Airwallex 空中云汇致力于为企业提供一站式跨境支付解决方案。

我们从实际业务场景入手，来让大家更了解 Airwallex 空中云汇。大家平时在购物、玩游戏、订阅视频网站平台，或者使用一些付费软件时，都会有不同产品下的跨境支付场景，包括刷卡支付或者定时订阅支付。这些支付服务的提供方包括游戏公司、电商平台，或者其他平台上的商户。

而 Airwallex 空中云汇，其实就站在这些企业的背后，为这些企业提供收单、收款以及资金管理相关的服务。

![](https://picx.zhimg.com/80/v2-a3d025ac4f0745ba003aedd7f21f1a09_1440w.jpg?source=d16d100b)


在跨境场景下，我们面临的客户形式和背景会非常多样化。

一方面其中有一些客户是游戏公司，面向不同国家的用户提供一个提供游戏内购款相关的产品；还有一些是电商平台，包括自营平台和类似于淘宝这种为不同商户提供服务的平台。

另一方面我们的客户不仅仅是这些平台本身，还包括平台上的商户。这些商户在法律上是一个独立的商业实体，所以我们需要对这些实体有非常清晰明确的认识。

![](https://picx.zhimg.com/80/v2-ed6e88edcd41dc2afd12e31d88bc8136_1440w.jpg?source=d16d100b)


以上展示的是一张从公司官网上摘录的 UI 界面，帮助大家感受 Airwallex 的业务场景。

# 二、NebulaGraph 的应用场景

我们把 NebulaGraph 的使用场景分为四个主要类目：

![](https://picx.zhimg.com/80/v2-3c850bcf5bc655ec9b3f6a6187d278a3_1440w.jpg?source=d16d100b)


# **（一）客户关系洞察**

刚才已经简单提到，在跨境场景下，不同国家的法律法规有其特殊性，商业实体是法律上的基本单位，我们需要对这些实体进行分类和关联。这有助于我们了解客户所在地的法律法规和业务范围，确保合规性。

**1. 个人信息关联**

* 商业实体的授权人和法人：这些人的信息需要与商业实体相关联，以确保我们了解谁在实际控制和管理这些实体。

* 注册账户的实际操作者：当个人注册并使用我们的服务时，他们的邮箱、手机号等信息需要与他们的账户相关联，这有助于我们在需要时进行身份验证和风险评估。

**2. 设备信息关联**

涉及客户使用的设备，如 IP 地址、设备 ID 等。这些信息可以帮助我们识别异常登录行为，例如从不寻常的地理位置或设备进行的登录。

**3. 网络信息关联**

包括客户的网络行为和交易模式。通过分析客户的网络活动，我们可以识别异常的交易模式或潜在的风险交易。例如，频繁的大额交易或在短时间内从多个不同地点进行的交易都可能引发警报。

**4. 人脸信息关联**

这是生物识别技术的一部分，用于验证客户身份。

# **（二）实时交易关联**

我们实时交易的时候，需要用 NebulaGraph 进行一些交易的关联。

设备信息关联，与 KYC 场景下的设备信息关联存在差异，这里的设备信息主要来源于集成了 Airwallex SDK 的支付组件。当用户进行支付操作时，会应用 Airwallex 不同平台的 SDK（移动端，网页端等），用户追踪设备 ID，设备型号，IP 地址等信息。

支付和收款信息的关联主要用于验证交易的合法性和安全性；在电商环境下，账单信息关联是识别异常购买模式和潜在欺诈行为的关键，而物流信息关联主要用于追踪商品流向和确保交易的完整性。

# **（三）模型特征提取**

在模型特征提取方面，我们并不是直接使用原始数据，而是先对数据进行处理，生成特征。这些特征随后被用于不同模型的训练和实时推断。在线图服务运行时，会定期生成数据快照用于模型训练，同时在线服务也需要实时接口来计算特征，用于模型推断。

# **（四）可视化交互**

我们目前的实现较为简单，主要面向内部运营人员。我们提供了一些 Web 页面，允许运营人员根据自身需求输入信息并进行操作，以实现按需查询和交互。

# 三、Why NebulaGraph？


# **（一）背景**


上述提到的客户关系洞察（KYC，Know Your Customer）是风控领域确保客户身份真实性和评估其风险状况的重要流程。它不仅在新客户注册时进行，还贯穿于客户整个生命周期，以应对客户资料或交易行为的变化。

KYC 的核心在于验证客户身份、了解其财务状况和风险特征，从而防止欺诈和金融犯罪。

![](https://pic1.zhimg.com/80/v2-ff2ffeb054f41af74c0f2d785f51290d_1440w.jpg?source=d16d100b)


**图关系是 KYC 的自然表征。通过图数据库，可以将客户、账户、设备、交易等信息以节点和边的形式进行建模，直观地展示客户之间的复杂关联。例如，法人与商业实体的关联、账户与设备的关联等**。这种结构化表示不仅提升了数据的可读性，还使得异常行为的识别更加高效，比如通过关联分析发现潜在的欺诈链条。

**因此，我们使用 NebulaGraph 其实是一种非常水到渠成的选择**。

# **（二）面临的问题**

在引入 NebulaGraph 之前，我们使用的是一个简单的 Python 图服务，主要用于处理一些基础的图关系应用。当时公司还处于早期阶段，数据量相对较小，因此我们从离线数仓中读取所有数据，通过传统的操作提取点和边的信息，并将其存储在内存中构图。

![](https://pic1.zhimg.com/80/v2-d1c129d42406115b581748feede2e935_1440w.jpg?source=d16d100b)


这种架构在数据量较小时表现尚可，但随着业务的发展，逐渐暴露出一些问题。

首先，稳定性不足，因为需要定时更新数据，每隔 10 分钟就需要重新读取和构图，这个过程容易出现故障。其次，内存效率较低，尤其是在数据量逐渐增加的情况下，内存占用成为一个瓶颈。此外，查询语言的表现力有限，无法满足复杂场景的需求，导致开发效率低下。这些问题促使我们考虑引入图数据库来解决业务中的挑战。

# **（三）NebulaGraph 选型**

![](https://picx.zhimg.com/80/v2-969a11bff0b9fc4f1a0625e61d27baaa_1440w.jpg?source=d16d100b)

**当时在选型时，我们对比测试了多个图数据库。我们淘汰了性能测试中表现不佳的一些图数据库，即使个别图数据库与 NebulaGraph 性能接近，但在功能全面性上有所欠缺。此外， NebulaGraph 拥有丰富的企业应用案例也是我们选择它的重要因素**。

# 四、系统架构设计

# **（一）客户关系系统架构**


### **客户关系的构图**


![](https://pica.zhimg.com/80/v2-708c65b27ff8c1eed1b17741d89f887a_1440w.jpg?source=d16d100b)

如图所示，我们对账户节点进行了高度简化。实际上，我们内部的账户信息是一个层级结构，因为每个子账户实际上都是一个独立的公司。

我们构建的是一个异构图，这种结构有几个显著的优点：

**1. 易于满足不同的查询场景**

异构图能够灵活地适应多种查询需求。例如，我们可以轻松地查询某个账户的关联信息，或者分析账户之间的交易模式。

**2. 易于引入新的关系类型**

随着业务的发展，我们可能会遇到新的数据类型或关系。异构图的灵活性使得添加这些新的关系类型变得相对简单，只需要在图中添加相应的节点和边。

**3. 易于结合 TTL 进行数据清理**

TTL（Time to Live）机制可以帮助我们自动清理过期的数据，确保图数据库中的信息保持最新和相关。

在过去的几年中，我们不断引入新的关系类型，使得我们的图结构比上图上显示的更为丰富。这种灵活性不仅满足了我们当前的需求，还为未来可能的新发展提供了便利。我们可以在不同的边上配置不同的属性和权重，以便进行更精细的数据分析和清洗。

### **系统架构**


![](https://picx.zhimg.com/80/v2-92e21f24d18fbc184a660fc2a461777a_1440w.jpg?source=d16d100b)


**1. 数据写入**

* 小时级批处理（全量）：通过一个中等量级的属性更新，将所有数据一次性写入到数据库。

* 业务系统实时数据补齐（增量）：在新客户注册时，由于没有历史数据，业务系统会通过 API 实时补齐数据，并写入到数据库中。

**2. Schema First**

* Schema as Code：所有字段的定义和变更都在代码中完成，自动生成功能确保了数据的一致性。

* 单一 Schema：既用于服务代码，同时也生成 ETL 的 Schema。这样可以确保数据的一致性和开发效率。

我们的图服务主要用于以下几个方面：

**1. 模型特征提取**

我们需要实时进行客户分析，以及其他不同场景下的交易和用户行为分析。

**2. 规则引擎**

这是我们内部的一个风控引擎，通过图的特征数据进行规则处理，最终做出不同的判断。

**3. 业务服务**

内部的其他业务服务可以利用图数据库的数据进行相应的处理。

**4. 可视化**

提供一些界面让运营人员进行查询和分析。


### **业务复杂性**


![](https://pic1.zhimg.com/80/v2-a4f44e084169e0a4775a2e5777164be5_1440w.jpg?source=d16d100b)

1. Schema复杂且易变

* 数据模式复杂，节点类型多样（约 10 多种），不同节点上的属性信息差异较大。

* 数据模式变更频繁，每月可能有局部调整，需要灵活的管理流程。

2. 数据逻辑变更与清洗

* 数据清洗和逻辑变更需要一个易于操作的流程，以应对业务的快速变化。



###  **应对策略**



1. 一处定义，动态生成

* 在代码中统一定义数据模式（Schema），每次代码提交时自动生成相应的数据模式定义。

* 修改字段名称、添加字段或调整属性时，只需在代码中操作，系统会自动生成变更语句并逐步完成自动变更。

2. TTL + 全量写入

* 使用 TTL 机制结合全量写入的方式，确保数据的时效性和完整性。

![](https://pica.zhimg.com/80/v2-36245b17b96fa6bd09d08abf2caa169e_1440w.jpg?source=d16d100b)


我们采用了一种 Declarative 的 Schema 管理方式。 当我们对一个字段进行命名、添加、属性信息进行修改的时候的时候，会在内部自动生成相应的变更语句。

![](https://pic1.zhimg.com/80/v2-2a58aa041e9f347a551348ffd3427d55_1440w.jpg?source=d16d100b)

在查询结果映射方面，我们采用了“声明即所得”的方式。

通过在代码中定义结构体，并使用注解直接映射查询结果中的字段，查询结果会自动填充到对应的结构体字段中，无需手动处理字段映射。此外，通过 SDK 或接口动态获取字段信息，确保每次查询都能正确映射到最新的 Schema，避免了因字段变化导致的查询错误，提高了系统的稳定性。

# **（二）交易关联系统架构**

![](https://picx.zhimg.com/80/v2-c14b623a5b38c00204cc4a1e989af680_1440w.jpg?source=d16d100b)

![](https://pica.zhimg.com/80/v2-cf52f1a4b3574823aa7e5da01a6124a4_1440w.jpg?source=d16d100b)

![](https://pic1.zhimg.com/80/v2-0e6102b31d9ff1349305f9d22a8a0e03_1440w.jpg?source=d16d100b)


在交易关联系统中，与客户关系系统存在较大差异，在这里，我们对实时性要求更高，因此我们采用了分离计算、读时合并的架构。

历史数据（超过 4 小时）通过小时级批处理进行预计算，生成子图的点边信息，并存储在图数据库中。实时数据（4 小时以内）则通过 Kafka 实时获取上游交易的原始数据，在服务端进行拆分和构建后写入 NebulaGraph.

# 五、未来展望

![](https://picx.zhimg.com/80/v2-c7d3b5332dc8c536fa1f53dba99a8b76_1440w.jpg?source=d16d100b)

目前，单一 Nebula 集群在计算资源隔离方面存在不足，导致不同应用间的查询峰值会相互干扰，且一套集群无法同时满足 TP（事务处理）和 AP（分析处理）的目标。此外，图算法的支持也存在一定的开放性不足和生态不够丰富的问题。

在未来，我们希望能够改善这些问题，通过更好的资源隔离技术和更丰富的图算法生态，来提升系统的性能和可用性。我们期待与社区和其他开发者一起合作，共同推动技术的发展和生态的建设。

:grinning:
「ps：本文整理自 Airwallex 在 NebulaGraph 社区 nMeetup 上的分享，Airwallex 目前已升级为 NebulaGraph 企业版」

NebulaGraph 在 Airwallex 跨境金融风控的应用

导读：某全球知名信息与通信技术（ICT）解决方案供应商通过 NebulaGraph 构建了覆盖云原生 DevOps 全流程的图数据库管理平台，并有效优化了 NebulaGraph 的可维护性、安全性、可靠性。本文将深入探讨自动化部署、数据安全性和可靠性建设的关键策略，为数据库管理提供全面的解决方案。

![](https://pic1.zhimg.com/80/v2-5f936ec0018e8f6a09eade14d8a900f6_1440w.jpg?source=d16d100b)




# **一、引言**

## **（一）云原生DevOps**

首先，我们来谈谈“云原生 DevOps”.

“云原生”是一个合成词，由 ''Cloud'' 和 ''Native'' 组成，''Cloud'' 它指的是我们的应用程序开发是基于云上进行的。''Native'' 是一个理念，意味着我们在开发应用程序时，从设计之初就应考虑到它是在云上运行的，基于云上的资源进行开发。

**总之，我们在设计时不会过多关注底层细节，如资源物理集群信息，而是更聚焦于业务程序需求本身。**

## **（二）数据库平台能力建设**

我们终端云服务背后有很多云服务能力，比如我们手机后台的云服务能力。这些服务能力是基于云服务平台的能力构建的，涉及到各种能力的组件，比如数据的持久化。

数据持久化是在数据库平台上进行构建，**基于我们原有的能力结合 NebulaGraph 图数据库，已经有 20 + 业务使用数据库平台上的 NebulaGraph 能力，例如特征工厂、数据血缘、风控等**。我们为提高多个业需求和运维效率，将这些能力整合。

## **（三）业务背景**

![](https://pica.zhimg.com/80/v2-f0049a9492fda22090f2f0afcdf11081_1440w.jpg?source=d16d100b)


在计划构建图数据库平台时，我们关注几个关键信息：批量图数据库的集群维护、人力成本、专业技能要求、安全性、业务支撑要求等。这些挑战要求图数据库必须具备高可用性、高性能和高安全性。

最终我们选择了 NebulaGraph 构建来一个高效、可靠且安全的图数据库平台，以支持业务的快速发展。这个平台不仅能够处理大规模数据，还能够应对复杂的业务关系，同时保持高可用性和安全性。

# **二、整体架构**

我们的数据库平台主要分为两大板块：数据库治理和数据库引擎。

![](https://picx.zhimg.com/80/v2-2033f2685242e035d135cf6963f526d7_1440w.jpg?source=d16d100b)


数据访问框架的核心是 WiseDBA, 它是一个集成了 DevOps 理念的数据库治理平台，旨在实现变更自动化和数据同步合规。数据库治理模块涵盖了数据库的整个生命周期，包括设计、开发、发布和运维等，在每一个阶段，我们都提供了表设计工具、SQL 审核与发布工具等一系列工具，来提高治理效率。

数据库引擎通过同城双活和异地多活等方式保障高可用性，利用增量备份和快速恢复确保数据安全，同时优化了查询性能和数据处理能力，通过物理集群连接解决容量瓶颈，并实现数据库节点的弹性伸缩以适应业务需求变化。

我们的平台已经支持了多种数据库，包括 GaussDB、DCS(基于 Redis)、ClickHouse、NebulaGraph 以及 CSS(基于 Elasticsearch 构建的文档数据库).

通过这样的框架设计，能够为各种业务场景提供稳定、高效、安全的数据库服务。

# **三、NebulaGraph 引擎管理架构设计**

NebulaGraph 引擎管理架构设计是确保数据库稳定性和高效性的关键。这一架构设计提供了覆盖 DevOps 全流程的数据库治理能力，实现数据安全和数据隐私的全面防护。

![](https://pica.zhimg.com/80/v2-1855b6913a6ddd0f9344ec0fd6c45bb5_1440w.jpg?source=d16d100b)


## **（一）使用者视角**

**管控面**

各个治理工具覆盖了 DevOps 全流程，从设计、开发、发布、运维各阶段管控 NebulaGraph 数据库：

* 表设计工具：辅助用户设计数据库表结构。

* SQL 审核工具：在开发阶段审核 SQL 语句，确保质量。

* SQL 变更工具：管理数据库变更，确保变更的安全性和可追溯性。

* 性能诊断工具：提供性能诊断，帮助用户识别和解决性能问题。

* 健康巡检工具：定期检查数据库健康状况，预防潜在问题。

**运行面**

这部分是业务接入 SDK, 最终业务应用程序还是需连到机器上，进行数据的检索，我们增强了以下能力：

* 安全认证：确保业务应用程序与数据库之间的连接是安全的。

* 连接池：管理数据库连接，提高资源利用率。

* 自动重连：在连接断开时自动重新建立连接，保证业务连续性。

* 配置热生效：允许在不重启服务的情况下更新配置，提高灵活性。

* 主备切换：在主数据库出现问题时，自动切换到备份数据库，确保服务不中断且无感知。

## **（二）提供者视角**

**NebulaGraph 管理台**

NebulaGraph 管理台是 NebulaGraph 数据库治理的基石，它结合了治理工具，全面实现了数据库变更的自动化。管理台提供了实例管理、图空间账号管理、图空间管理和 Tag/Edge 管理功能，使得管理 NebulaGraph 的各项操作都变得简单高效。

**SDK 配置管理台**

SDK 配置管理台专注于业务接入的自动化。该管理台将接入规范集成到 SDK中，使得业务接入配置管理变得高效，包括连接池参数配置、数据库账号配置以及 SDK 配置下载等功能。

此外，SDK 配置管理台还提供了读写分离配置、DB 请求灰度配置功能，有助于业务在不同环境下实现平滑过渡，同时有效控制和管理潜在的风险。

通过这样的 NebulaGraph 引擎管理架构设计，屏蔽了 NebulaGraph 整个物理集群的组网部署信息，专注于业务逻辑的开发。

# **四、NebulaGraph 集群可维护性建设**

所谓“可维护性”，即通过自动化日常操作，屏蔽操作内部细节，提升批量集群的可维护性。

## **（一）简化安装过程及集群调参等动作，降低了业务试用接入门槛**

![](https://pic1.zhimg.com/80/v2-15483238693ce0fce33273ab42e96702_1440w.jpg?source=d16d100b)


一个图数据库集群的开通，如果按照传统方式做一个中间件引入、部署，整个流程十分繁杂。我们通过云原生 DevOps 的能力，把周边的组建整合起来，最终实现业务在部署集群的时候，只需选择部署的环境、集群名、图数据库版本等基础信息，以及业务关心的单云/双云、主机的规格、节点的个数、缩放空间，再点击立即创建后台，基本在 20 分钟以内就能完成整个集群的自动化部署。并且在完成自动化部署后，后台有自动化的能力把账号配置进行自动化处理。

## **（二）云原生-基础设施即代码方式申请实例、图空间、链接配置等**

![](https://pica.zhimg.com/80/v2-83b12e61a60a9d2def4cfd40720590a0_1440w.jpg?source=d16d100b)

在开发过程中，当研发需要一个新的图数据库引擎实例时，会以页面文本的方式描述所需的集群规格、磁盘大小、节点数等集群信息。这些描述信息会被基础设施即代码（IaC）平台执行，我们的后台会自动找到所申请的组件，组件后台再完成自动化的安装。在整个过程中，无需关注细节，因为 IaC 代码可以重复执行，进行调和，以达到目标状态。在整个过程中是无人值守的，IaC 代码跑完，就能实现开发需求。

## **（三）集群配置分级管控、配置飘移检测，降低集群运维风险**

![](https://picx.zhimg.com/80/v2-b4850b685404e6a0fe4072e8e7c9cf33_1440w.jpg?source=d16d100b)


做数据库平台最大的挑战是，在初始阶段，数据库通常以中间件的形式存在，由各个业务自行配置和维护。在维护过程中，分布式集群的多节点特性使得问题定位变得困难，一旦出现问题，不仅需要花费大量时间进行排查，并且在排查过程中，业务也会遭受损失。

因此，我们的配置管理进行了分级分类。

* 不开放部分配置给业务处理，以减少误操作风险。

* 提供 Agent 能力，通过 Agent 读取核心进程内存数据和本地配置文件数据，并将其存储到预设的空间中。

* 实现配置漂移检测，检测节点内配置是否生效以及节点间配置是否一致

# **五、NebulaGraph 集群数据安全性建设**

## **策略一：事前预防**

![](https://pica.zhimg.com/80/v2-df5f41257f6f2db924049df7eb10cabe_1440w.jpg?source=d16d100b)

1. 权限最小化

* 人员权限：将数据库操作权限按角色由高到低进行划分：DBA>运维 SRE>研发。

* 账号管理：

* 人机账号：控制账号的有效期，避免账号泄露导致未经授权的操作。

* 机器账号：分为治理账号和业务程序账号，治理账号用于 DevOps 流程中的设计工具，业务程序账号仅赋予应用程序所需的最小权限。

2. 管理操作工具化

* 引擎管理台：作为数据库平台的一部分，用于执行日常管理和监控任务。

* 数据库跳板机：作为进入数据库后台的跳板，通过严格的权限控制，只允许特定人员操作。

* 主机堡垒机：在跳板机无法解决问题时，连接到数据库集群，进行更深入的操作。这一层级的权限要求更高，通常由 DBA 执行。

## **策略二：事中拦截+事后恢复**

![](https://picx.zhimg.com/80/v2-32f12f6c446c1d79cf73f4ebc85299d9_1440w.jpg?source=d16d100b)

**事中拦截**

1. 版本测试与发布评估

在版本测试发布时，会对业务要执行的操作进行负面评估，即判断当前运营环境是否允许这样的操作，以及当前的情况是否合适。

2. 软删除机制

如果业务坚持要删除某个对象，NebulaGraph 会采取软删除的方式，即暂时禁用该对象，使其无法被业务使用。这样，如果业务发现误删了数据，可以迅速通过软删除的能力进行恢复。

**事后恢复**

1. 快速恢复能力

由于采用了软删除机制，当需要恢复数据时，只需将禁用的对象重新启用即可。这种方式比传统的硬删除后恢复要快得多。

2. 定期快照与备份

NebulaGraph 结合了社区提供的快照能力，定期将业务数据上传到 OBS 中。这样，即使数据被误删，也可以通过快照进行恢复。数据发现的越早，恢复的越快；发现的越晚，恢复成本越高。

# **六、NebulaGraph 集群可靠性建设**

在 NebulaGraph 的日常操作变更和数据安全防护方面，我们已经实施了工具化和相应的防护措施。然而，为了确保集群在运行或变更过程中不会出现可靠性问题，还需要进一步加强可靠性能力的建设。

## **（一）集群变更，业务不中断**

![](https://pica.zhimg.com/80/v2-28c28951c3e6a3d677fff5b1314ab094_1440w.jpg?source=d16d100b)


关键点在于我们将 NebulaGraph 的 SDK, 放在配置中心里，业务不感知这个连接，如 IP、账号密码等。另一方面，为了避免对业务造成影响，我们的图数据库管理平台是滚动升级，逐个节点进行循环执行。如果某个节点出现问题，我们有 NebulaGraph 作为兜底，比如我们发现某个节点有问题，暂时把它踢掉，通过间隔检查，发现问题已顺利解决，我们再把它加载过来。并且如果后期需要修改参数，业务也无需重启，利用热加载将其加载到 NebulaGraph 的 SDK 里。

## **（二）故障业务不中断——双云组网**

![](https://pica.zhimg.com/80/v2-07bdcfa59ae7d90095e783071903c5ed_1440w.jpg?source=d16d100b)


双云组网形式，有多种实现方式，比如通过业务双写的方式和利用集群本身的能力。我们的双云组网实现过程中，引入了 meta 、storage、graph. 在 meta 、storage 数据中加入鉴定组件，meta 和 storage 不参与选举，但负责接收并处理来自其他组件的数据副本。然后，这些数据会被同步到备集群中，整个过程中业务无需感知。

故障业务不中断——双云切换

![](https://picx.zhimg.com/80/v2-c9e113196b1eb664564542c725597706_1440w.jpg?source=d16d100b)


为了保障业务的连续性，NebulaGraph 集群采用了双云切换策略，该策略包括以下几个关键点：

* 对接注册中心：集群的链接信息被写入到注册中心，Nebula-SDK 从注册中心拉取配置，确保业务能够获取最新的集群配置信息。

* 读写分离：系统支持读写分离能力，可以在主、备集群之间分配读写请求，以提升查询性能。

* 主备切换：系统能够自动探测集群的健康情况。一旦发现集群异常，可以自动迁移到健康的集群，并进行回切，以保证业务的连续性。

双云切换流程

* 探测集群健康情况：业务 SDK 会定期检查集群的健康状态。

* 自动切换到健康集群：如果主集群出现故障，SDK 将自动切换到备集群，确保业务不受影响。

* 切流数据同步：在切换过程中，数据同步机制确保数据的一致性。

## **（三）节点指标&日志采集**

![](https://picx.zhimg.com/80/v2-2cbb249945d0f1b9f9abd5dc82426b06_1440w.jpg?source=d16d100b)

为了确保 NebulaGraph 集群的可靠性，我们实施了节点指标和日志的采集策略，这包括：

* 丰富的主机监控：对集群所在主机节点的 CPU、内存、磁盘空间等关键资源进行监控，确保资源使用情况在可控范围内。

* 分钟级 200+个指标监控：提供秒级的数据采集，支持超过 200 个指标的监控，这使得运维团队能够快速定位集群的性能瓶颈或异常。

* 灵活便捷的告警机制：当监控指标超出预设阈值时，系统会触发告警，通知运维人员及时采取措施，如扩容或优化配置。

# **七、未来规划**

**继续聚焦单节点故障自愈能力**

![](https://picx.zhimg.com/80/v2-f3a12794ba85ea3d3d0526406fe5a6df_1440w.jpg?source=d16d100b)

我们正在努力提升 NebulaGraph 集群在面对单节点故障时的自愈能力，以确保集群的稳定性和业务的连续性。

* 容量问题：单个大规模集群( 50+ 节点) Meta 进程可能会遇到性能瓶颈。我们正在对这一问题进行压测，以评估和解决可能出现的性能问题。

* 性能问题：在Flink 大规模实时写入的情况下，如何避免图查询能力受损。目前，我们采取的措施是实现读写分离，但这种分离是在双集群层面上进行的。在双云部署的环境下，一个集群负责写入操作，而另一个集群则专门处理读取请求，以此来优化性能。

NebulaGraph 图数据库平台的能力建设是一个持续进化的过程。我们将继续在云原生 DevOps 全流程中不断探索、优化，构建一个更加强大、安全、可靠的图数据库平台，以满足日益增长的业务需求和挑战。

如何构建覆盖云原生 DevOps 全流程的 NebulaGraph 图数据库管理平台

覆盖云原生 DevOps 全流程的图数据库平台能力建设

![](https://pic1.zhimg.com/80/v2-b62ebd2301b9bc3d8cc24427f0a9be49_1440w.jpg?source=d16d100b)


# **RAG 的历史**

云风作为中国程序员圈的先驱，曾在一篇文章中写道：“**无论我们想学什么，都应该从学习它的历史开始**。”这篇文章的许多观点都对我影响深远。今天，我们就从 RAG 的历史开始聊起。

![](https://pic1.zhimg.com/80/v2-6c2b68cfc55015b2189dc7f77d767958_1440w.jpg?source=d16d100b)


在传统大模型中，就是一个 model: 我问一个问题，经过该大模型，给出一个回答。那 RAG 则是我的问题会经历一个向量数据库，根据检索到的信息给出答案。向量数据库的广泛使用已经很久了，淘宝搜索、以图搜图或者谷歌、百度搜索，背后都是它在发挥关键作用。

**具体而言，RAG（Retrieval Augmented Generation）是一种结合了检索和生成的范式。它通过检索相关参考材料，然后从检索到的信息中进行上下文学习，以生成回答**。它能够通过检索相关文档来增强生成模型的能力，从而在问答系统中提供更准确和丰富的回答。

![](https://pica.zhimg.com/80/v2-aa43fe534e564dc18bf83203bd0e429a_1440w.jpg?source=d16d100b)


RAG 的历史可以追溯到 2020 年，那时还没有 GPT-3.5，人们普遍认为 GPT 只是一个玩具，因为它非常昂贵。在这个时期，Facebook 的 AI Research 团队发表了一篇论文，标志着 RAG 的诞生。这篇论文使用的是 GPT-2 模型，研究人员发现，将大型语言模型与自然语言处理相结合，可以产生非常好的效果。

![](https://picx.zhimg.com/80/v2-1a7f1dd15b1152379758a5e643b496d8_1440w.jpg?source=d16d100b)


# **GraphRAG 的历史**

2022 年 3 月，OpenAI 公布了自己的 API, 这使得大家开始思考如何利用这个 API 来实现更多的功能，这时向量数据库的潜力被重新发现。大家意识到，通过向量数据库或者在传统数据库中加入向量类型，可以实现 RAG 的功能。

例如，我有一个文档，先靠 OpenAI 或者其他大模型，转换成向量，储存在向量数据库里。这时我提出问题，大模型将其转换为向量，在向量数据库中查找最匹配的段落，组织语言后生成最终答案。通过这样的方式，有效解决大模型在专业领域知识不足的问题。

随着向量数据库的兴起，图数据库公司也开始思考如何利用自己的技术来实现类似 RAG 的功能。**NebulaGraph GenAI Team Leader 古思为提出了将图数据库与 RAG 结合的想法，并向 LlamaIndex提了第一个PR，将 KG-RAG 转变为 GraphRAG**. 这个转变意味着人们开始探索使用图模型来增强 RAG 的功能，利用图数据库的搜索强度可能比传统的向量更好，能够起到一定的 RAG 作用。

![](https://picx.zhimg.com/80/v2-9610c8e2a3d959e880909a324b4aad0c_1440w.jpg?source=d16d100b)


微软在 2024 年 4 月份发布了 GraphRAG 的第一篇论文，市场上很多项目开始从 RAG 向 GraphRAG 迁移。这一转变的原因是 RAG 存在一些问题，而 GraphRAG 在某些领域存在突出优势。

![](https://pica.zhimg.com/80/v2-f434d9c8728c4683a253fad396ebc217_1440w.jpg?source=d16d100b)


# **RAG VS GraphRAG**

刚我们已经提到，在处理查询时，RAG 会利用大型语言模型，将查询转换为向量形式，然后在向量数据库中检索相关信息，并通过上下文学习生成回答。市场上对这一过程进行了多种优化，例如 rerank, 它使用大型语言模型对检索结果进行再次排序，以提高回答的相关性。

![](https://pic1.zhimg.com/80/v2-d24e2d428156bddb99738daf4d487935_1440w.jpg?source=d16d100b)


然而，RAG 在处理细粒度检索和全局上下文搜索时存在局限性，如知识碎片化和上下文丢失问题。**例如，在《红楼梦》中搜索林黛玉「哭泣」的原因可以找到结果，但搜索她「不笑」则无法找到答案，因为书中并没有提供相关信息**。这些问题限制了 RAG 在企业级应用中的准确性和可靠性，因为企业需要的是接近 100% 的准确率，而 RAG 往往只能达到 95% 的准确率，这在商业环境中是不够的。

![](https://pic1.zhimg.com/80/v2-12f1365629de7adc1e1bb838ce63ddf5_1440w.jpg?source=d16d100b)

相比之下，**GraphRAG 不依赖于向量数据库，而是利用图数据库来存储和检索信息**。它通过大型语言模型抽取文档中的主要关系和实体，并将它们转换为图结构存储在图数据库中。**这种方法不仅提高了检索的强度，还能够更好地处理全局上下文搜索和领域知识集成的问题**。

# **GraphRAG 的能力总结**

![](https://pica.zhimg.com/80/v2-e7ec9a2bd6d33b3e52c32bb326ba4a8a_1440w.jpg?source=d16d100b)


![](https://pica.zhimg.com/80/v2-bd9b3b5ec83f57d8bc884a9f0784778f_1440w.jpg?source=d16d100b)

GraphRAG 通过图索引、文本到查询的转换以及链式探索（Chain of Exploration）来增强模型的探索能力，类似于传统 RAG 中的思考量，但增加了探索量。**这种基于图的方法可以利用图数据库找到真正的重组关系，实现更复杂的 AI 编排工具，满足市场上对高精度和高可靠性的需求**。

# **何时使用GraphRAG**

何时推荐使用 GraphRAG呢？我们可以考虑以下几种情况。

![](https://pica.zhimg.com/80/v2-5dedae1e0d6129784ba62770d85d4e7e_1440w.jpg?source=d16d100b)


首先，当**面对高度离散的数据时**。例如，企业可能拥有大量分散的文档和多年的杂乱数据库，GraphRAG 能够帮助整合这些信息，构建起企业知识图谱，从而实现更深层次的数据理解和利用。

其次，当**需要对全局信息进行理解**时。以《红楼梦》为例，如果我们想要对书中的人物关系和情节有全面的理解，GraphRAG 能够提供全局的视角，帮助我们捕捉到更细微的联系和深层次的内涵。

此外，**领域知识的集成**是 GraphRAG 的另一个重要应用场景。在职业招聘领域，GraphRAG 可以帮助匹配求职者的技能、工作经验与职位要求，从而提高招聘效率；在医学领域，GraphRAG 能够通过分析个体的特定特征来预测疾病，这对于精准医疗和个性化治疗方案的制定具有重要意义。

# **GraphRAG 企业知识管理与应用构建平台**

NebulaGraph 已经在实际项目中应用了 GraphRAG.

![](https://picx.zhimg.com/80/v2-6ed4433c5045ad70bef8305752fca795_1440w.jpg?source=d16d100b)


NebulaGraph 利用 GraphRAG 做 index, 对企业内部文档进行问答集的构建，旨在为企业提供高效、智能且易用的知识解决方案。通过引入知识级概念和 Meta Agent 概念，该平台显著降低了员工的使用门槛，使他们能够通过聊天式交互轻松构建知识应用，实现低心智负担的操作。

# **GraphRAG 的缺点**

在探讨 GraphRAG 技术时，我们不得不提到它的一个主要缺点——成本。**GraphRAG 的高成本主要源于其初始化阶段**，特别是当使用像 GPT-4 这样的先进模型来构建索引并存储在图数据库中时。

**然而这种成本在技术发展的不同阶段有所变化**。正如我们刚开始提到的，GPT-3 曾因其高昂的价格而让许多用户望而却步，然而随着 GPT-3.5 的推出，成本有所下降。 GPT-4 问世后，人们只会在发布后的一段时间内觉得过于昂贵。随着时间的推移，成本将进一步降低，更多经济实惠甚至免费的模型会陆续出现。

![](https://picx.zhimg.com/80/v2-da3ba0351bf180d08187e3eba0cacc26_1440w.jpg?source=d16d100b)


**尽管 GraphRAG 的初期投入可能较大，但这种成本在很大程度上是一次性的：贵，但只贵一次**。对于拥有大量文档和数据的企业来说，一旦构建了 GraphRAG 模型并将其存储在数据库中，这些数据和模型就成为了企业的长期资产。随着时间的推移，这些资产可以被反复利用，从而分摊了初始成本。此外，GraphRAG 带来的效率提升和知识管理优势，使得这种投资在长期看来是合理的。

因此，尽管 GraphRAG 的启动成本较高，但它为企业提供了一种强大的工具，以实现更智能的数据管理和决策支持，这在当今的数据驱动型经济中至关重要。


——————————分割线——————————————————————

🙋活动推荐

诚邀您参加【NebulaGraph x Airwallex 图数据库与风控】上海站，一场聚焦于图数据库与 GraphRAG 在风控领域创新应用的 nMeetup，[点此报名](https://9753492656408.huodongxing.com/event/3799122350000)

![](https://picx.zhimg.com/80/v2-515cae27af412c84eb52414701bd91e8_1440w.jpg?source=d16d100b)



🔍相关阅读

[首个提出 GraphRAG 的团队在做什么？](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516100&idx=1&sn=aaacb7b5fcb68acdb4a12d1a98af4cfb&scene=21#wechat_redirect)

[首发完整版教程，MCP 集成至 LlamaIndex 的技术实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)

[NebulaGraph MCP Server 正式开源！探索 AI+图数据库无限可能](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516029&idx=1&sn=144dbf68dd1cd770cf6bee531500ccad&scene=21#wechat_redirect)

[GraphRAG vs DeepSearch？GraphRAG 提出者给你答案](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515612&idx=1&sn=e5b3f13debc62fcf53119e55ce2b6b71&scene=21#wechat_redirect)

[NebulaGraph 的 GraphRAG 进展、实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247514593&idx=1&sn=bed17f080e374d9cb957d14f17a01062&scene=21#wechat_redirect)

[VLDB 2024｜NebulaGraph RAG 正式官宣](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511923&idx=1&sn=4d9a9b80cf528212b64ef96ec6a62fad&scene=21#wechat_redirect)

[基于 NebulaGraph ，构建属于你的 Graph RAG](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511536&idx=1&sn=f73ada9ea4c97d23acaed65c60a06034&scene=21#wechat_redirect)

有哪些炙手可热的场景需要 GraphRAG 实现？

> “NebulaGraph 作为一款云原生图数据库，属于传统 Infra, 但我们逐渐意识到，AI 的发展将彻底改变数据库的应用场景和技术架构。于是，我们团队开始探索图数据库在 AI 领域的价值。”本文整理自 NebulaGraph @PsiACE 在 KCD Beijing 上的演讲， 与大家分享 NebulaGraph GenAI Team 的工作与进展。

![](https://picx.zhimg.com/80/v2-c00d5a1549bde4fe3e2a1730e391ceaa_1440w.jpg?source=d16d100b)



> 本文首发于[「NebulaGraph 技术社区」](https://mp.weixin.qq.com/s/346RoWfDa9zfKO8jmtGEgg)

# **Part 1 背景趋势**

## **01 传统 RAG 方法的痛点**

![](https://picx.zhimg.com/80/v2-3a5ff55238d81ca779830cda0714ce1b_1440w.jpg?source=d16d100b)



传统 RAG 方法在实际应用中面临诸多挑战：

* **细粒度知识检索能力不足**：举个例子，做 chunk 分块是一个很强的对信息浓度的假设，无论是用语义的方式还是固定大小来分块，一旦确定了这个分块，其实对知识被召回的数据的信息浓度做了一个很强的假设，有的时候就存在一些重要而细粒度的分散的信息没办法进行召回，质量就会有些损失。

* **全局上下文关联缺失**：索引的知识块中，核心知识点和其他知识点的关联，有些知识有局部性，例如 A 和 B 在一个块关联，B 和 C 在一个块关联，C 和 D 在一个块关联，如果某些任务依赖于全局的上下文，但任务中又只提及 A 和 D，这中间的关联在做 chunk 的 RAG 索引一般是丢失的，无法获取全局上下文的关联。

* **向量相似性与相关性错配**：传统 RAG 的索引方法追求相似，但实际上相似并不等于相关。例如，检索保温杯与保温大棚相关文章，在向量数据库中大概率会变成两个非常相似的向量，从而使得生活场景与农业场景产生错配。

* **全局性问题及推理型问题回答能力不足**：传统 RAG 在处理全局宏观性问题和需要推理的问题时，往往只能给出片面的答案，缺乏深度分析和逻辑推理。如果将树比喻成知识，整片森林（所有的树）代表全部知识，如果问这个森林是什么形状的，很明显这是一个宏观的问题，当只召回到一部分的树是无法回答这个问题的。

# **02 GraphRAG 的优势**

NebulaGraph 专注于图技术，已进行了多年的开源分布式图数据库的研发。**在 RAG 技术还未被称为 RAG，而是上下文学习方法的时候，我们就意识到以图的方式处理知识会对解决这些问题有很大帮助。因此，NebulaGraph 率先提出了 GraphRAG 的方法，并于 2023 年 8 月与 LlamaIndex 联合发布 GraphRAG**.

GraphRAG 的优势显著：

![](https://picx.zhimg.com/80/v2-29bc1580eb8ccd4f71abfa9437037cd4_1440w.jpg?source=d16d100b)



* **细粒度的切分实体和关系**：通过知识图谱技术，将多模态文本中的实体和关系进行细粒度的拆分，保留高度凝练的知识细节。例如，在讨论“苹果”时，能够准确识别是指水果还是苹果手机，并明确它们之间的关系。

* **保留事物间的关联关系**：在知识图谱中明确事物之间的关联，提升可解释性。比如，在工业排障场景中，通过图数据库可以清晰地展示故障之间的关联关系，高效地追根溯源，帮助用户快速定位问题。

* **图查询和图算法得到相关上下文**：利用图查询和图算法，将边和实体对应的节点都提取出来，精准获取相关上下文信息，使回答更全面、更符合预期。

## **03 云原生图数据库 NebulaGraph 的价值**

* **完整的 Infra 基座**

![](https://picx.zhimg.com/80/v2-cf72e141be2f5fc8d94a1945ca861edf_1440w.jpg?source=d16d100b)


在过去几个月里，GraphRAG 技术作为 RAG 下 state of art 的范式，得到了充分的关注，可以看到包括微软、Meta、Google都做了一些不错的工作。不过大多数实现仅仅是借用图的形式表示而并没有建立在图数据库之上，**但可以预想，随着数据量的增大，图数据库的价值在 GenAI 时代将会更加重要。因为它是一个完整的 Infra 基座，对各种运行环境和云厂商具有良好的兼容性，能够与 K8S 等技术深度集成，原有日志、可视化等工具也可完整接入，无需额外定制化开发和运维保障，这使得企业可以充分利用现有的技术资源去使用 GraphRAG**.

* **大规模复杂场景检验**

![](https://pica.zhimg.com/80/v2-02bc652d3f3e912c8d448a54ae2f0b6f_1440w.jpg?source=d16d100b)


某知名海外社交平台的好友推荐、广告推荐等场景，充分证明了 NebulaGraph 在高实时性、高精度需求场景下的高性能。**该社交平台的用户关系超过 100 亿，单个最大规模图谱超过 400 亿点，1000 亿边，但仅需 2 个工程师就可以维护所有与 NebulaGraph 相关的产品，有效降低运维成本**。


# **Part 2 技术路线**

## **01 GraphRAG-Agentic Workflow**

以往大家 RAG 的理解是检索增强生成，但我们对 RAG 的理解分为以下三个部分：‍

![](https://pic1.zhimg.com/80/v2-956e63775ded66938b20926a11048091_1440w.jpg?source=d16d100b)


* Retrieval（检索）：检索大量数据，补充数据实时性，将多模态数据转化为可检索形式。

* Agent（智能体）：可定义工具集，调用各种方法和生态产品。比如，在处理复杂问题时，Agent 可以调用不同的工具和算法，进行多轮推理和分析。

* Ground Truth（真实情况）：Ground Truth 的建设是通过 "专家经验 Human in Loop + 机器智能" 的协同机制，构建可复用、可进化的知识体系，实现知识与真实世界的同构映射，确保不同业务场景、不同阶段的应用均可基于相应的事实基准开展工作。

## **02 GraphRAG-ParseCraft**

为什么不是完全依赖现有工具去做这个事情，而是需要自己去研发一些组件呢？因为在整个解析的流程中可能涉及到一些预处理和后处理的工作，而且对于特定的内容需要有足够的能力来干涉解析过程，确保生成符合预期的结果。比如在我们的场景中可能会涉及的部分包括：

![](https://picx.zhimg.com/80/v2-ac8ac40e373a3c11f21dd7975cbf57ef_1440w.jpg?source=d16d100b)


* 特定领域的内容的理解和表征：比如故障树分析，这个场景拿到的是一个图片，但是图片上的事件存在关联关系，我们需要把它转换到图上面，并标识这些关键路径和事件。

* 通用场景下的关键结构的转换：比如文章的段落、目录，天生就是具有结构化、和领域化的内容，比如一个章节内大概率是围绕相关主题展开的，在解析过程中需要留存；再比如布局之间的关联，可能影响上下文，如果要精细地做一些事情，可能不得不将这些信息保存下来。

ParseCraft 注重集成性和可定制性，作为接入层，除了定制基于视觉语言模型的解决方案外，还能融合文档解析、布局识别等方案，只需实现少数几个 API ，就可以获得格式转换和可观测性的能力增强。预计今年上半年开源。例如，在处理复杂的文档和表格时，ParseCraft 可以将其转化为大模型易于理解的格式，提高处理效率。

## **03 GraphRAG-Deep Seach**

![](https://pic1.zhimg.com/80/v2-45829c20e348f6b2bf678f8c4fc25ba9_1440w.jpg?source=d16d100b)


我们目前的 GraphRAG 实现本身也是符合 Agentic 范式的，结合推理模型，如 DeepSeek R1 / Qwen QwQ 等，可以对任务进行预先规划，并驱动在 Workflow 中进行多轮探索和评估，与 Deep Search 充分兼容，能够节约开销、增强效果。

## **04 GraphRAG-All in MCP**

![](https://pica.zhimg.com/80/v2-242c370a7b4678147c90e5abe4bf3126_1440w.jpg?source=d16d100b)


我们团队积极参与 MCP 相关工作，输出 LlamaIndex 社区第一个 MCP 工具支持方案，落地 Local MCP 范式，并且进入官方 repo 进行集成。此外，我们实现内部工具集定义落地了 Local MCP 范式，在复用 MCP 相关接口标准的同时，改用函数调用的模式，为内部工具调用和后续开放 MCP 服务能力提供基础。实现函数调用与接口复用。例如，在处理复杂的图查询时，MCP 可以提供强大的支持，提高查询效率和准确性。（MCP 集成至 LlamaIndex 完整教程，[详情请查看](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)🔍）

## **05 Graph Insight-Text to GQL**

![](https://picx.zhimg.com/80/v2-4ddcb4c2a9fb3fcbacec36eac802bdc6_1440w.jpg?source=d16d100b)


早期数据库领域和大模型结合的一个重要方向就是 Text2SQL ，对于图数据库，对应的就是 Text2Cypher，当然，随着 ISO GQL 标准的确立，现在 Text2GQL 也成为了关键的一环。NebulaGraph 在这个方向上也做了一些努力，沉淀出了一套 Graph Insight 的方法。

一方面，利用基础的 Text2GQL 方法，用户可以以问答形式在已有图谱上进行简单的图查询和图计算。另一方面，通过利用内置的一些算子模版，可以将复杂的图查询转化为填空题，降低大模型编写复杂查询语句和探索图的难度。通过提示词工程和 ReAct 等方式，Agent 可以利用上下文对生成的 GQL 语句进行自校准，帮助写出更加准确和符合业务目标的 GQL 语句。

当然，用户也可以在这个基础上将过去积累的图算法作为模版封装，充分利用过去业务场景积累的经验，释放图上的价值。

## **06 Graph Insight- Agentic & CoE**

![](https://picx.zhimg.com/80/v2-21f3b3e505539c5c3040a084f6bf955c_1440w.jpg?source=d16d100b)



Graph Insight 我们聚集 Agentic 范式图探索能力与 Chain of Exploration（CoE），构建了一套高效的图知识处理与分析体系。不仅能深度挖掘图谱内的知识，还能以自然融合的方式整合多源数据 —— 将图探索作为 Agent 调用的工具，无缝对接互联网知识等外部数据源，打破单一数据边界，实现知识的跨域协同。

## **07 Graph Insight - MCP**

![](https://picx.zhimg.com/80/v2-5e25407eb4e62a78892f18a3dc947e5e_1440w.jpg?source=d16d100b)


针对热门的 MCP方向，团队构建了 NebulaGraph MCP Server（已正式开源，[详情请查看](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516029&idx=1&sn=144dbf68dd1cd770cf6bee531500ccad&scene=21#wechat_redirect)🔍）。该服务不仅为大模型提供查询接口，支持直接调用执行图数据查询，还预封装了实用的算子模板，包括邻居发现、路径发现等核心功能，简化图数据操作流程。

# **Part 3 应用案例**

## **01 产品 - 图 AI 工具链**

![](https://pica.zhimg.com/80/v2-1aec0efb7dfa7924fbcc195e8ad50b2b_1440w.jpg?source=d16d100b)


我们面向开发者提供了一套完整的工具链，包括对向量、全文索引等能力做了支持，方便企业自行开发 AI 应用，核心功能包括图谱构建、图谱推理、模型微调等。

## **02 产品 – 图 AI 应用平台**

![](https://pica.zhimg.com/80/v2-5c31c93871d81ef222752b9f21d4d321_1440w.jpg?source=d16d100b)



面向终端用户，开箱即用，帮助用户以对话方式快速构建 AI 应用，如智能客服机器人、故障排查助手、研报生成机器人等，具有智能文档处理、零代码、零工作流、零提示词设计等特点。用户可以通过简单的对话方式，快速构建一个智能客服机器人，提高客户服务效率。

## **03 工业解决方案‍**

![](https://pic1.zhimg.com/80/v2-7d5624c96495ed72fff5e8d1b7f8ba36_1440w.jpg?source=d16d100b)



NebulaGraph 与行业头部企业协作，构建面向工业协同研发系统的 Graph + AI 解决方案，落地行业首个生成式人工智能驱动的实际应用场景，基于知识图数据库及智能问答系统进行数据交互，荣获沙丘社区 2024 最佳案例 15 强。

此外，在复杂排障知识图谱的构建和探索上，我们也积累了一定经验，充分运用大模型赋能排障系统，在一些场景下拥有超过 40 万有效节点。

## **04 金融行业解决方案**

![](https://picx.zhimg.com/80/v2-f9dc87dec0dcc73ccc7f6981aa6817f1_1440w.jpg?source=d16d100b)



利用基于大模型的知识图谱自动抽取和构建技术，和在金融领域深耕积累的经验洞见，NebulaGraph 和合作伙伴共同构建和发布基于 GraphRAG 和 Agentic Workflow 的行业解决方案，共同推动 Graph + AI 技术在金融风控等领域的发展。

# **结语**

NebulaGraph 在 GenAI 领域的探索和实践，不仅解决了传统 RAG 方法的痛点，还通过云原生图数据库的价值，为各行业提供了强大的技术支持。未来，NebulaGraph 将继续深化技术路线，拓展应用领域，推动 GenAI 技术的不断发展和创新。







————————————分割线————————————————

🙋活动推荐

诚邀您参加【NebulaGraph x Airwallex 图数据库与风控】上海站，一场聚焦于图数据库与 GraphRAG 在风控领域创新应用的 nMeetup，[点此报名～](https://9753492656408.huodongxing.com/event/3799122350000)

🔍相关阅读

[首发完整版教程，MCP 集成至 LlamaIndex 的技术实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)

[NebulaGraph MCP Server 正式开源！探索 AI+图数据库无限可能](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516029&idx=1&sn=144dbf68dd1cd770cf6bee531500ccad&scene=21#wechat_redirect)

[GraphRAG vs DeepSearch？GraphRAG 提出者给你答案](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515612&idx=1&sn=e5b3f13debc62fcf53119e55ce2b6b71&scene=21#wechat_redirect)

[NebulaGraph 的 GraphRAG 进展、实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247514593&idx=1&sn=bed17f080e374d9cb957d14f17a01062&scene=21#wechat_redirect)

[VLDB 2024｜NebulaGraph RAG 正式官宣](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511923&idx=1&sn=4d9a9b80cf528212b64ef96ec6a62fad&scene=21#wechat_redirect)

[基于 NebulaGraph ，构建属于你的 Graph RAG](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511536&idx=1&sn=f73ada9ea4c97d23acaed65c60a06034&scene=21#wechat_redirect)

NebulaGraph GenAI Team 在 GraphRAG 上的工作与进展

首个提出 GraphRAG 的团队在做什么？

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/banner)

导读：‍‍‍‍NebulaGraph 作为领先的分布式图数据库，凭借其强大的性能与灵活的扩展性，为众多开发者与数据分析师打开了高效处理海量关联数据的大门。为了让个人用户能够迅速融入 NebulaGraph 的世界，本文精心整理了三种实用方案，无论是 Windows、macOS 用户，还是 Linux 爱好者，亦或是青睐云端服务的开发者，都能从中找到适合自己的快速上手路径。



# **▌一、Windows & macOS 用户首选**

**NebulaGraph Desktop**

对于习惯于使用图形化界面进行操作的 Windows 和 macOS 用户来说，NebulaGraph Desktop 是开启 NebulaGraph 之旅的理想起点。这款由 NebulaGraph 社区推出的桌面软件，集成了本地实例管理、可视化数据管理以及开发调试等丰富功能，解决了以往部署繁琐、工具分散的痛点，让数据库管理变得轻松愉悦。

![1](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/640%20(3).webp)

### **NebulaGraph Desktop 特点**

-    用于管理 NebulaGraph 服务的现代、直观的界面
-    实时服务监控和健康检查
-    资源使用指标（CPU、内存、网络）
-    单独的服务控制
-    服务日志查看器
-    美观、响应迅速的 UI
-    支持离线模式（无需提取 Docker Hub 镜像）

**项目地址**

[https://github.com/wey-gu/NebulaGraph-Desktop](https://github.com/wey-gu/NebulaGraph-Desktop)

**NebulaGraph** **Desktop 遵循 Apache 2.0 协议，欢迎开发者们共同参与功能迭代与生态扩展。**

## **安装步骤**

#### **1\. 安装 Docker Desktop**

NebulaGraph Desktop 依赖于 Docker Desktop，因此首先需要安装 Docker Desktop。它是一款功能强大的容器管理工具，适用于 Mac、Linux (Ubuntu, Debian, Fedora, Arch, RHEL) 或 Windows 等多种操作系统，能够帮助用户轻松构建、共享和运行容器化应用程序及微服务。其简洁的图形用户界面，让容器、应用程序和映像的管理变得直观而高效。

![2](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/2)

在 Windows 系统下，Docker Desktop 需要使用 WSL 2 或 Hyper-V，安装完成后，会默认下载安装 WSL 子系统，无需额外进行配置。

![3](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/3)

#### **2\. 安装** **NebulaGraph** **Desktop**

下载 NebulaGraph.Desktop.Setup.0.3.5-windows.exe.

依据安装提示快速完成软件部署。

#### **3\. 启动** **NebulaGraph** **服务**

安装完成后，打开 NebulaGraph Desktop，点击【Start All】按钮，即可轻松启动 NebulaGraph 服务。

![4](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/4)

可以看到有四个服务正在健康运行，表明数据库已成功启动。

![5](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/5)

浏览器中访问 localhost:7001/login 即可进入 NebulaGraph Studio 工具，开始进行数据管理与操作。

‍

# **▌二、Linux 开发必备 NebulaGraph 单机版**

Linux 版本更适合于 DBA 或者有 Linux 运维经验的从业者。以 CentOS 7 为例，其安装与使用过程简洁明了，能够让开发者迅速搭建起专属的开发环境，专注于核心业务逻辑的实现。

### **1\. 下载安装包**

使用 wget 命令，从官方 NebulaGraph 的 RPM 安装包以及控制台工具。

```
wget https://oss-cdn.nebula-graph.com.cn/package/3.1.0/nebula-graph-3.1.0.el7.x86_64.rpm
wget https://github.com/vesoft-inc/nebula-console/releases/download/v3.8.0/nebula-console-linux-amd64-v3.8.0
```

### **2\. 执行安装**

使用 `yum` 命令完成安装。

```
sudo yum install -y nebula-graph-3.1.0.el7.x86_64.rpm
```

### **3\. 启动服务并检查状态**

安装完成后，使用 NebulaGraph 提供的脚本启动所有相关服务，并通过 `status` 命令查看服务的运行状态。

```
[shawnyan@el7 ~]$ sudo /usr/local/nebula/scripts/nebula.service start all
[WARN] The maximum files allowed to open might be too few: 1024
[INFO] Starting nebula-metad...
[INFO] Done
[INFO] Starting nebula-graphd...
[INFO] Done
[INFO] Starting nebula-storaged...
[INFO] Done
[shawnyan@el7 ~]$ sudo /usr/local/nebula/scripts/nebula.service status all
[WARN] The maximum files allowed to open might be too few: 1024
[INFO] nebula-metad(33fd35e): Running as 2501, Listening on 9559
[INFO] nebula-graphd(33fd35e): Running as 2570, Listening on 9669
[INFO] nebula-storaged(33fd35e): Running as 2602, Listening on 9779
[shawnyan@el7 ~]$
```

### **4\. 连接到** **NebulaGraph**

赋予控制台工具可执行权限，并运行该工具，即可连接到本地的 NebulaGraph 实例。

```
[shawnyan@el7 ~]$ chmod +x nebula-console-linux-amd64-v3.8.0
[shawnyan@el7 ~]$ ./nebula-console-linux-amd64-v3.8.0
Notice: Defaulting to localhost (127.0.0.1) with port 9669 using credentials (username: root, password: nebula).

Welcome!

(root@nebula) [(none)]> show hosts;
+-------------+------+-----------+----------+--------------+---------------------+------------------------+---------+
| Host        | Port | HTTP port | Status   | Leader count | Leader distribution | Partition distribution | Version |
+-------------+------+-----------+----------+--------------+---------------------+------------------------+---------+
| "127.0.0.1" | 9779 | 19669     | "ONLINE" | 100          | "my_space_1:100"    | "my_space_1:100"       | "3.1.0" |
+-------------+------+-----------+----------+--------------+---------------------+------------------------+---------+
Got 1 rows (time spent 2.097ms/2.728015ms)

Mon, 10 Mar 2025 12:34:56 CST

(root@nebula) [(none)]>
```

# ▌三、1**4 天免费试用 NebulaGraph Cloud on AWS**

NebulaGraph Cloud 是一项完全托管的云数据库服务，支持[原生 GQL](https://mp.weixin.qq.com/s?__biz=MzU5NzQ0ODU2Ng==&mid=2247487701&idx=1&sn=63a2e6e1f8d1dec94383d62fbd400c96&scene=21#wechat_redirect)，全天候 24*7 可用，安全可靠，按需付费，提供多种规格选项，注册账号即刻享受服务，突破物理环境的局限。

**注册地址**：[https://cloud.nebula-graph.io/login](https://cloud.nebula-graph.io/login)

![6](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/6)

目前，NebulaGraph Cloud 提供 14 天免费试用，在 2025 年 4 月之前订阅可享受 6 个月的特别折扣。

注册成功后，登陆管理界面，创建数据库。

![7](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/7)

云提供商默认为 AWS，可用区默认为 us-east-2。稍等片刻，数据库创建成功。

![8](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/8)

使用 NebulaGraph Studio 连接到数据库，并写入、查看测试数据。

![9](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/9)

NebulaGraph Cloud 提供了丰富的观测指标，用户可以在管理界面中实时监控数据库的运行状态，包括性能指标、资源利用率等。

![10](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.18/10)

# ****▌四、总结‍‍****

以上三种方案各有优势，涵盖本地开发与云端部署场景，除以上部署方式外，NebulaGraph 还支持**分布式集群部署**，大家可按需选择。

| **方案** | **场景** | **优势** | **注意事项** |
| --- | --- | --- | --- |
| NebulaGraph Desktop | 本地开发、图形化操作 | 一键部署，集成工具链 | 需安装 Docker Desktop |
| 单机版部署 | Linux 服务器部署 | 纯命令行控制，资源占用低 | 需手动维护服务 |
| NebulaGraph Cloud | 基于 AWS，出海必备 | 免运维，弹性伸缩 | 可用区较少 |

**祝你在** **NebulaGraph** **图数据库之旅玩得开心～**

‍

整理了三种实用方案，无论是 Windows、macOS 用户，还是 Linux 爱好者，亦或是青睐云端服务的开发者，都能从中找到适合自己的快速上手路径。

萌新轻松上手 NebulaGraph 的三种方案

![8407c34521fc4c53a38aab78265d0c03_](https://discuss-cdn.nebula-graph.com.cn/uploads/default/original/3X/f/a/fa718525022066c8e99b101fbaf712be496783d2.jpeg)

**大家好，我是第二期做客「社区 AMA」的嘉宾：姚成耀**。

大家对什么是社区 AMA 有疑问的话，你可以先看下官方出的活动介绍：[🎉社区 AMA 重磅回归！欢迎大家 Ask Me Anything🎙️🎙️](https://discuss.nebula-graph.com.cn/t/topic/16638)

简单来说，**社区 AMA 活动期间，你可以向我提指定范围的问题，我将在活动期间内回复你的问题**。

# 关于我

我是姚成耀，现在在博睿数据担任大数据开发工程师，现负责公司内 [NebulaGraph](https://github.com/vesoft-inc/nebula) 数据库的开发及维护工作。从3.0.0版本开始接入一直到目前最新的3.8.0版本。 由于我们公司有很多私有化客户，所以有一些较为丰富的使用场景，也遇到过一些升级，迁移方面的问题，也对内核进行过一些二开，目前由于是偏向业务方向的二开，需要修改一下才能是更通用的功能，目前由于比较忙一直没时间改提pr来着。

# 提问范畴

你可以向我提问 **`内核原理`**、**`nebula-java 客户端`**、**`性能优化`** 相关的问题。

# 这边有礼

为了鼓励大家向成耀提出实用的问题，成耀将会在他的 AMA 结束之后指定 2 名提问者送上由 [NebulaGraph](https://github.com/vesoft-inc/nebula) 社区提供的交流礼。

本期交流礼：**[NebulaGraph](https://github.com/vesoft-inc/nebula) 电脑包** & **笔记本（别想多了，是写字的笔记本～）** 

![image](https://discuss-cdn.nebula-graph.com.cn/uploads/default/optimized/3X/a/6/a67d0ad821e3a60dfe260629c37e7d234ff20110_2_384x499.jpeg)

# 参与方式

NebulaGraph 论坛：在 [AMA 活动帖](https://discuss.nebula-graph.com.cn/t/topic/16649)下，直接与我交流

社区AMA第二期：可向嘉宾提问关于内核原理、nebula-java 客户端、性能优化相关问题

NebulaGraph 社区 AMA｜内核原理、nebula-java 客户端、性能优化问题都可以问我～

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/MCP/dac249151143b177336ead527966a939472621355.jpg)

> 本文首发于 NebulaGraph 技术社区 [https://mp.weixin.qq.com/s/YhtDxiPIVRR3VQAoVQxYjw](https://mp.weixin.qq.com/s/YhtDxiPIVRR3VQAoVQxYjw)

# ▌一、背景


过去几周，Model Context Protocol (MCP) 在技术社区中引发了广泛的讨论和关注。借此机会，我参与了几个相关的开源项目，包括为 **LlamaIndex 官方仓库贡献了 McpToolSpec 实现**，以及和 Xuanwo、FrostMing 合作开发了一版 **Model Context Protocol Server for Apache OpenDAL™**。

MCP 是目前唯一一个在生态上具有优势的标准。在这一背景下，我们**基于 NebulaGraph 3.x 实现了一个简单的 NebulaGraph MCP Server，作为 NebulaGraph X MCP 生态中的第一个基础组件，供大家探索 AI 与图数据库结合的可能性**，希望能够看到更多在这个模式下的有趣工作。


# ▌二、Model Context Protocol (MCP)


MCP 是由 Anthropic 团队推出的一项开放协议，旨在为 AI 系统提供统一的、高效的方式访问多种数据资源。通过采用客户端-服务器架构，MCP 将数据访问标准化，解决了传统 AI 系统在不同数据源之间的碎片化问题。

**MCP 核心特点**

1.  **标准化的通信方式**：通过 MCP，AI 助手能够有效地访问各种数据源，比如本地数据、远程服务和企业工具。
    
2.  **开放性与生态优势**：目前 MCP 社区中已有近 1000 个 MCP Server 实现，覆盖搜索、天气、数据库等多个领域，支持工具的快速接入。
    
3.  **灵活的架构**：通过定义客户端和服务端的交互协议，MCP 为开发者提供了构建可扩展、可复用系统的基础。
    

虽然目前在安全性和可靠性上仍有一些挑战，但随着协议规范的完善和成熟开发模式的引入，这些问题将逐步得到解决。


# ▌三、NebulaGraph MCP Server 功能


由于最近一段时间一直围绕 GraphRAG 和 Agentic Workflow 做一些工作，利用大模型和智能体进行图上数据的洞见和挖掘是一个非常重要的议题。为此，我快速开发了 NebulaGraph MCP Server，以支持 NebulaGraph 3.x 作为工具接入 MCP 生态，供语言模型（如 Claude、GPT 等）调用和使用。

目前 **NebulaGraph MCP Server 基于 FastMCP 实现，遵循 MCP 的核心规范，旨在提供高效、轻量的图数据库连接服务**。通过将 NebulaGraph 的功能暴露为标准化的工具接口，该 Server 能够让大模型轻松调用 NebulaGraph 数据，实现简单的图探索任务。

 **多种传输方式**：
    
-   支持 stdio 和 SSE 两种传输模式，满足不同开发和部署场景的需求。
    
  **基础图探索能力**：
    
-   图空间（Graph Space）列出：允许模型查询可用的图空间。
    
-   模式（Schema）查询：支持查询指定图空间的模式定义。
    
-   查询执行（Query Execution）：支持通过 MCP Server 执行 NebulaGraph 查询。
    
   **内置算子模板**：
    
-   实现了路径搜索和邻居发现等常用操作的模板，方便语言模型按需调用这些工具，快速获取图数据的初步洞察（Insight）。
    

为了展示它的效果，我基于 LlamaIndex 中的 McpToolSpec 和 ReActAgent 构建了一个简单的示例，下面是对应的截图：
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/MCP/3799122350000_wechat)


# ▌四、结语


**NebulaGraph MCP Server 是对 MCP 生态的一个初步尝试，旨在为语言模型和图数据库的结合提供一个起点**。随着协议的逐步成熟和生态的扩展，我们期待它能够在更多真实场景中发挥价值。如果您对这一方向感兴趣，欢迎一起探索、尝试！

**🔍相关阅读**：[首发完整版教程，MCP 集成至 LlamaIndex 的技术实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)‍‍

基于 NebulaGraph 3.x 实现了一个简单的 NebulaGraph MCP Server，作为 NebulaGraph X MCP 生态中的第一个基础组件，供大家探索 AI 与图数据库结合的可能性

NebulaGraph MCP Server 正式开源！探索 AI+图数据库无限可能


# ******▌********一、背景**


GraphRAG 是检索增强生成（RAG）技术的高级技术之一，旨在解决传统 RAG 的局限性。上周，[NebulaGraph 团队分享了关于 GraphRAG Indexing 模型蒸馏训练的工作](https://x.com/wey_gu/status/1892828461322162223) ，收获了诸多积极反馈。最近也收到些试图将 GraphRAG 和 DeepSearch 放在对立面混淆视听的信息。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/640-2.webp)

本文应朋友们建议整理而成，将分享 NebulaGraph 团队在 GraphRAG 领域的探索与实践历程，涵盖自 2023 年 6 月以来在 **GraphRAG** 基础研究上的进展，以及对**高级 RAG** 和 **Fusion GraphRAG** 的理解与实践。


# ******▌********二、RAG 与 GraphRAG 的缘起**



## RAG：检索增强生成


过去两年来，生成式 AI 和大语言模型的飞速发展堪称人类技术史上的重要里程碑。它们赋予计算机前所未有的上下文学习和推理能力，使得许多专属人类的复杂任务得以自动化甚至超越。然而，如何高效利用这些模型完成具体任务，成为技术落地的关键。

**RAG（Retrieval Augmented Generation，检索增强生成）作为一种基础范式应运而生。其核心在于通过“检索”（Retrieval）增强“生成”（Generation）：**

* 生成：将任务描述和领域知识（即提示词）输入大语言模型，生成相应的回答。

* 检索增强：利用检索技术为模型提供高度相关的上下文知识，从而提升生成质量。

在 RAG 中，检索环节至关重要。根据应用场景的不同，RAG 可分为两类：

* 面向公共检索系统：如 Google 或学术搜索引擎，依赖大模型调用外部 API，适用于通用知识获取。市面上的代表性产品包括 Perplexity Search 和 DeepSeek。
* 面向私有领域知识：如企业内部的研发文档或研究报告，需结合智能文档处理（IDP）、知识索引（Index）和知识管理系统。此类场景对检索技术的精准性和深度提出了更高要求。


###  朴素的 RAG

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/1.gif)


对于非结构化或半结构化知识，朴素 RAG 的典型流程包括：

* 将文档分割成块（Chunk）。

* 通过向量化嵌入（Embedding）构建语义索引，或结合 BM25 全文索引实现检索。

* 在任务执行时，基于任务需求直接检索或通过检索重写（如 HyDE）优化结果。

然而，这种方法在知识组织上的局限性使其难以满足企业级需求，具体挑战将在下文详述。

### RAG 的挑战


朴素 RAG 在实际应用中面临以下难题：

* 大海捞针：分块假设知识分布均匀，但某些关键信息可能被稀释在无关内容中，导致召回失败。

* 穿针引线：线性分割破坏了知识间的关联，难以还原全局上下文。

* 宏观问题：基于分片和关键词的索引无法有效应对全局性问题，如“哪些话题最具创新性”。

* 文档理解不足：缺乏智能文档处理时，公式、表格等复杂信息无法被正确解析和索引，影响回答质量。



# 高级 RAG



做好 RAG 并非一蹴而就，而是一个持续探索的过程。本质上，我们需要将对应用特点、RAG 技术特性以及知识本身的深刻理解，融入到 RAG 流水线的设计之中。

下图展示了一个近期发布的高级 RAG 总结性工作的简化图例：一个高级 RAG

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/2.webp)


**可见，在现代高级的 RAG 方法中，数据持久化层包含 "Graph DB"（即图数据库，一种以图结构——“节点”和“边”为中心的数据库），而图数据库也正是本文主题 GraphRAG 的重要基础设施。**

现代图数据库能够以高效、可扩展的方式驱动多租户、超大数据规模、高并发场景下复杂关联关系（图数据）的持久化、查询、访问和计算。它是高级 RAG 系统、智能体记忆系统（Agent Memory）的重要骨干基础设施，如下图所示。面向关联关系的图状结构，与我们梳理知识的脑图、甚至大脑中的神经元结构都非常相似。这种并非偶然的结构相似性，正是高级 RAG 知识索引解决朴素 RAG 方法挑战的关键。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/3.gif)


常见的高级 RAG 方法，在特别的索引结构上，包括树状索引（Tree-RAG）、分层检索（Raptor）和图状索引（GraphRAG），其中 GraphRAG 是我们文章的重点。


## ****高级 RAG****


**GraphRAG 这个方法最初是我们在 2023 年 8、9 月份开始，在 LlamaIndex 社区上持续做的一些工作和两次公开的 Webinar 上提出，并给出了开源的实现和可复现的效果比较试验。（** **[Graph RAG: 知识图谱结合 LLM 的检索增强](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247508410&idx=1&sn=a0432b3bbeac4e60a43c320f88201e81&scene=21#wechat_redirect)）**

在最初的 GraphRAG 参考实践中，我们给出了索引期基于大模型的同构图谱抽取的实现和查询区基于实体、关系语义的捞取与可配置的子图查询的知识召回，并比较了基于 Text-to-Query 方法的一些效果比较与结合方案的实现。现在，为了区隔之后 Graph-based RAG 方法的演进，我们把最初的 GraphRAG 叫做 **SubGraph RAG** 。

在当时的 VLDB workshop 上([VLDB 2024｜NebulaGraph RAG 正式官宣](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511923&idx=1&sn=4d9a9b80cf528212b64ef96ec6a62fad&scene=21#wechat_redirect))，我们分享过的两个观点是

* 在与知识打交道的过程中，只用分片处理的方法、绕过 Graph（Knowledge Graph）一定是不够的，这也是我们做 GraphRAG 探索的初衷

* 这个 GraphRAG 的方法仅仅是一个开始，我们在不断探索更多在 Graph 之上的探索、推理的策略

随后，我们和 Researcher: Diego 一起讨论，**做了图索引之上 Chain of Exploration 的工作** ，并在 PyCon China 2024 上第一次给出了做了 Chain of Exploration 的分享。

之后，我们看到了非常多的 GraphRAG 相关工作被发表，比如 MIT 材料科学的两篇 利用我们的工作的 MechGPT、海马体 RAG 利用 pagerank 权重的工作 HippoRAG、LinkedIn 的利用 半结构化数据图建模的 RAG工作都非常有启发性。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/4.webp)


当然，最让我们兴奋的工作是微软的 GraphRAG: From Local to Global 工作，**他** **们充分探索了基于大模型抽取的知识图谱索引之上利用社区发现算法得到分级聚集结构下的全局性摘要**，这些摘要是没有偏见的保有原始知识中天然聚集性质、重要性质的脉络知识，在回答带有宏观全局性的问题中效果非常好。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/5.webp)


我们从这些后续的工作中受益匪浅，在与我们的客户 Graph based RAG 落地工作中，不断打磨、探索、累积了很多各个环节的优化、方法、策略。

最终形成了我们称为 **Fusion GraphRAG** 的方案。


# ******▌********三、Fusion GraphRAG**


Fusion GraphRAG 是我们团队在 GraphRAG 基础上的创新实践。它融合了高级 RAG 技术，通过图状结构存储文档层级、章节关系及特殊元素（如公式、表格），实现高效、灵活的检索。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/6.gif)


**Fusion GraphRAG 的本质在于 Sota 的高级 RAG 方法融合、充分连接的元知识索引、充分打磨调优的 GraphRAG**（可选索引）。

* Fusion GraphRAG 通过在一个联通图谱内的“元知识”索引，清晰地揭示海量知识文档的内在关联，呈现从文件夹、文档、章节到段落、图表、公式的完整脉络，此为知识图谱的“元知识频谱”。

* 在此基础上，用户可选择不同粒度的知识抽取方法（非必须），构建图谱结构的图索引，形成“增强图频谱”。

* 进一步，用户可以对图索引和元知识层进行诸如图摘要、权重分配、时序/状语信息补充等增强操作，以提升知识检索和利用的效率。


# *▌*四、Fusion GraphRAG 实现私域 Deep Research


**Fusion GraphRAG 融合了先进的 IDP 技术与 RAG 索引方法，并将提取的多模态知识有机地关联为图状结构，从而精确映射真实世界知识的内在逻辑。** 依托高性能、支持图语义与向量检索的现代图数据库作为持久化底层，Fusion GraphRAG 能在这一统一图谱上实现面向元知识层次与图谱增强的高级检索。

例如：

* 多层级知识检索：通过我们提出的 “Chain of Exploration” 检索器——一个能自主在图谱中探索并查找任务相关知识的智能 Agent，Fusion GraphRAG 可以在同时包含文件夹、文件层级以及章节（附摘要）结构信息的图谱上，既完成传统基于 Chunk 的检索任务，又能支持基于分层结构实现的脑图式 RAG 检索。（注：此方法不依赖昂贵的图谱抽取技术，后续将探讨如何进一步降低抽取成本。）
* 全局与局部深度分析：通过引入图抽取与图社区摘要等增强手段，“Chain of Exploration” 能够在图谱上按需执行全局搜索以解决宏观问题，同时进行针对多个知识点的精准局部检索，甚至对涉及复杂关联的深度问题（如关键知识间路径查找）进行分析。

* 多 Agent 协同：利用 Fusion GraphRAG 构建多 Agent 系统，可以将一整套算法与行为准则封装为一个专用的 Fusion GraphRAG Agent，此 Agent 可作为另一 RAG Agent 的召回计划生成器，在少而精的专业知识（know-how）构建的 Fusion Graph Index 指引下，自动规划出基于海量知识库的复杂查询方案。这为构建私有领域的自主学习 Deep Research/Action Agent 提供了有力支撑。

* 私有知识库内的深度研究：在 Fusion GraphRAG 之上，我们可以轻松实现针对私有知识库的 Deep Researcher。依托天然的知识连接与索引，再结合针对 “Chain of Exploration” Agent 的优化提示工程，以及类似 DeepSeek R1 的推理模型，就能实现类似 Deep Researcher 的 RAG 召回效果，为深度研究提供强大动力。


# ******▌********五、回到 GraphRAG 的时间线**


在我们的视角下，GraphRAG 正在不断演进，下面简要梳理这一发展历程：

* GraphRAG - 2023-08NebulaGraph 在 LlamaIndex 社区首次提出并实现了基本的 GraphRAG 模型。

* GraphRAG with Community Summary - 2024-04微软在论文中提出了基于社区发现算法实现全局摘要的 GraphRAG 方法，为图谱检索提供了新的思路。

* Fusion GraphRAG

  * 融合了文档层级、章节层级、以及文中各类特殊元素（如公式、表格、图表）的多频谱混合图状索引；

  * 支持可选的知识抽取与知识增强（包括社区摘要、时序增强等），构建混合层级结构查询、全局图召回、知识频谱图谱召回以及（可选） Chain of Exploration 检索；

  * 同时支持将公共知识图谱、现有知识图谱以及图状数据中的 Chain of Exploration 召回方法进行融合。

### **图抽取**

需要指出的是，在大模型时代，对原始知识进行类似知识图谱的抽取并非 Fusion GraphRAG 的必选项，因为并非所有 RAG 任务都需要细粒度的“知识预习”。图抽取的代价较高，目前多数公开方案成本也不低。

> 注：LazyGraphRAG 的相关工作同样值得关注，它提供了另一种优化思路。

> 附：Fusion GraphRAG 的索引及增强流程示意图

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/7.webp)


### **让图抽取成为默认策略**

高质量的 GraphRAG 索引虽然效果显著，但成本昂贵。我们的终极目标是让图抽取的成本降低到与 Embedding 类似的水平，实现大规模普及。

实际上，AI 技术社区（包括我们自身）已经在朝这一方向不断努力：利用 NER 模型、更小型（例如 Phi 系列）的 LLM 进行 SFT、小规模 LLM 的 few shot 方案、尽可能的可编程方法，甚至融合 NER 与 LLM 的多种方案，都是当前探索的方向。最近，我们也看到了一些令人振奋的曙光！

本质上，我们探索的基于 LLM 的抽取方法都采用了不同形式的 CoT（思维链）策略。近期，DeepSeek-MATH 论文中首次提出的 GRPO 方法在 DeepSeek R0 中用于冷启动获取 Think-aloud（思考过程）的深度 CoT 能力表现非常出色。同时，我们注意到基于 Qwen2.5（小尺寸 0.5b 模型）进行 GRPO 训练，在需要强推理能力的任务（例如数学问题）上，通过大约 200 步训练就能获得令人满意的效果。

结合这些观察，我们开展了如下探索：
* 数据收集与预处理：利用 DeepSeek R1，在挑选的最新原始知识数据（晚于模型 cut-off date）的基础上进行抽取任务，并开启 `<think>` 模式，收集高质量的 CoT 与图抽取的 Ground Truth，筛选掉质量不合格或思考过程过长的样本，作为训练数据。

* 奖励机制设计：基于开源社区中针对数学问题推理训练的 GRPO 奖励函数，我们设计了奖励高质量推理过程和高质量抽取结果的奖励函数。这两项奖励均依托高质量、低成本的指令大模型进行评估打分。

在一块 A100 显卡上经过约 200 步训练后，我们初步评估结果显示：基于 Qwen2.5-3b 的小尺寸抽取模型在引入 GRPO 训练后，其性能已经超越了 GPT-4o-mini。以下是各模型的对比结果：

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/8.webp)


正如当初推出首个 GraphRAG 开源实现时一样，这项工作仅仅是个起点。它证明了图抽取技术成本正在不断降低，未来我们有望大胆应用于更多场景，实现大规模的知识 GraphRAG。与此同时，这个方法也为特定领域范式数据抽取质量的提升提供了经济可行的方案。

> 训练数据、合成过程以及训练流程均已开源https://github.com/wey-gu/grpo-graph-extraction

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/9.webp)


### **RAG 应用落地的挑战**

众所周知，**RAG 更多的是一种技术和功能，而非一个完整的产品** 。在企业级应用中，产品形态本身所面临的挑战，往往远超技术或原理上的难题。

举个例子，Excel 电子表格软件凭借其公式计算和数据可视化功能，为会计和企业数据处理领域带来了颠覆性的变革。理论上，只需学习 Excel 中的各类公式和图表功能，就能获得大量实战经验，成为专业的数据分析师。但实际上，我们观察到，大多数企业员工仅仅熟悉 Excel 的基本操作，而许多昂贵且高级的 SaaS 产品，其功能实际上也不过是 Excel 部分能力的延伸。

如果基于 RAG 能力构建的企业产品，只是一个具备强大应用编排和知识库索引能力的“无代码”平台，那么这样的平台很可能只能在企业内部的少部分用户或团队中落地。大部分宝贵的领域知识仍停留在个人或小圈子中，无法以智能高效的方式被全面激活和利用。

为了解决这一问题，我们基于 FusionGraphRAG 与 Agentic RAG 技术，打造了一个全新的高级知识库与低门槛应用平台 —— NebulaGraph AI 应用平台（内部命名为 “Catalyst”，即催化剂）。该平台的核心设计理念包括：

* 无需构建复杂 Workflow：用户不需要自行搭建工作流。
* 无需编写繁琐 Prompt：用户无需学习复杂的指令语法。
* 简化知识定义：用户只需将对私有知识的理解转化为对不同“知识篮子”的定义。
* 智能对话交互：用户通过与我们的“元智能体”交流，传达解决问题的方法。

这种设计大幅降低了使用门槛，使得企业内部的知识能够被更高效、更智能地激活与应用，真正实现“插上翅膀”的飞跃。

### **AI 应用平台**

在这个平台中，企业用户可以将成百上千个文档轻松归入各自的知识“篮子”，并为每个篮子选择适合的“预学习”——即索引模式：
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/10.webp)


**知识探索**用户可以随时在各个知识篮子中进行探索，快速定位所需信息，直观理解知识集合内的知识分布、深浅、特种。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/11.webp)


**智能应用生成**用户无需亲手编写复杂的 prompt，只需通过对话的方式与平台互动，即可生成各种类型的智能应用、迭代沉淀应用的 prompt。例如：

* 平台内置了生成智能体应用的“元智能体”，让对话即成为开发工具。

* “帮我构建一个投研报告生成助手”

* “我要做一个 xx 申报助手”

* “基于我所有的周报知识，构建一个 yy 领域回答助手，我想放到钉钉签名上，免得别人来烦我关于 yy 的问题” ……

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/12.webp)


**问答搜索应用**平台支持构建问答型搜索应用，帮助用户快速获得精确答案。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/13.webp)


**知识溯源**同时，针对问答应用，基于连接的知识溯源，追踪答案的来源，确保信息透明可靠。


# ******▌********六、总结**


GraphRAG 的发展代表了 RAG 技术从基础检索向高级知识管理的演进。通过解决传统 RAG 在知识稀释、关联丢失和宏观问题上的挑战，GraphRAG 为企业级应用提供了更高效、灵活的解决方案。我们团队开发的 **Fusion GraphRAG 融合了智能文档处理（IDP）、多层次知识索引和图状结构，将知识的内在关联映射到检索过程中，显著提升了复杂任务的处理能力。**

在实践中，我们通过优化图抽取成本（R1 知识蒸馏、 GRPO 方法、 Qwen2.5-3B 规模上的工作，并开源出来。），让 GraphRAG 技术更具经济可行性，使其能够广泛应用于企业知识管理和智能应用平台。

未来，我们相信 GraphRAG 将成为高级 RAG 和智能体记忆（Agent Memory）的核心基础设施，推动深层研究和智能决策的进一步发展。NebulaGraph AI 应用平台的推出，正是这一愿景的初步实现。

最后，对于 GraphRAG，这是 Sherman 和我们 NebulaGraph GenAI team 每一位同学共同相信的观点：

* **狭义的 “GraphRAG”、甚至 “SubGraph RAG”，在特定场景仍然有优势，我们可以按需应用这个技术组合**

* **Deep Research, Deep Search 的形态与 Graph-based RAG 方法，尤其是 Fusion GraphRAG 可以形成很好的互补**

* **Graph Infra 是高级 RAG/Agent Memory 中不可绕过的结构与方法（Graph is inevitable in Advanced RAG），是以向量为基础的 RAG 的重要演进与互补。**



分享 NebulaGraph 团队在 GraphRAG 领域的探索与实践历程，涵盖自 2023 年 6 月以来在 **GraphRAG** 基础研究上的进展，以及对高级 RAG 和 Fusion GraphRAG  的理解与实践。

文章

标签