导读：开源之夏 2025 ，**蔡锋泽同学成功中选「NebulaGraph PyG Integration」项目**。本项目旨在实现 NebulaGraph 与 PyG（PyTorch Geometric）的高效集成，为图神经网络研究人员与开发者提供更便捷的大规模图数据训练支持。本文从蔡同学的技术视角回顾整个开发过程，重点分享架构设计及技术实现。

![](https://picx.zhimg.com/80/v2-8870f0c15698b6608ec637d6ad54d07f_1440w.png?source=ccfced1a)

**NebulaGraph PyG Integration**

旨在简化图神经网络（GNN）任务从 NebulaGraph 读取和处理图数据的过程。通过封装底层图存储访问和数据转换，帮助用户便捷调用 NebulaGraph 数据，免去繁琐的数据预处理，使 GNN 的训练和推理更加高效便捷。

[https://github.com/Fengzdadi/nebula-pyg](https://github.com/Fengzdadi/nebula-pyg) （后续会捐赠给 Nebula Contrib）

# 一、架构设计

项目的整体设计参考了 KUZU 为 PyG 提供远程图数据适配的思路，并在其基础上结合 NebulaGraph 的特性做了诸多改进。

核心是实现 PyG 定义的 FeatureStore 和 GraphStore 接口。为了简化用户的使用流程，我们在上层封装了 NebulaPyG 类，提供一行代码初始化两个存储实例的能力。该类还提供了 create_snapshot() 方法，用于解决关键的 VID（Vertex ID）映射问题。

我们将一些通用工具模块化，放在 utils.py 和 type_helper.py 中，包括特征维度判断工具 get\_feature\_dim()、全局快照生成方法 scan\_all\_tag_vids() 等。此外，还引入了 base_store 作为基类，用于处理 PyG 的 DataLoader 在多进程环境中引发的资源竞争与同步问题。

以下是项目中的主要类关系图：

![](https://pic1.zhimg.com/80/v2-787b153b2dd3bd50cac58b4288875379_1440w.png?source=ccfced1a)

# 二、技术实现

## （一）开发环境配置

1.  **环境管理**
    

nebula-python 选用 pdm 作为包管理工具，主要看中其能严格锁定依赖版本的能力，适合多端协作，但由于我是独立开发，所以并未体会到便捷之处，反而踩了一些坑，比如在安装 torch 等相关库时仍遇到一些兼容性问题，需通过手动配置解决。

**2.NebulaGraph 环境**

目前社区版的 storaged 必须在与 Python 解释器相同的网络环境下运行，并且 NebulaGraph 仅能在指定的 Linux 环境下安装。

如果使用 nebula-pyg，有以下两种方式，更推荐前者：

-   在指定的 Linux 环境中本地安装 NebulaGraph 和 Python 环境；
    
-   使用 docker-compose 启动 NebulaGraph，并将 Python 解释器通过 SSH 连接至同一网络。
    

不推荐使用 WSL，经思为老师提醒，它在 I/O 性能方面存在已知问题，我们在测试阶段也确实遇到了 storaged崩溃及文件读写错误。

## （二）VID 映射方案

NebulaGraph 支持 FIXED_STRING(N) 和 INT64 两种 VID 格式，而 PyG 要求节点索引必须为{0,……，num_nodes-1}。在 KUZU 的实现中，要求用户在导入数据时，index 必须满足 PyG 的要求，但考虑到工业级别中的图数据 ID 通常不符合该要求（如 UUID 或 Snowflake 算法生成的分布式 ID），并且在分布式数据库中，大部分情况不会是自增的int， 因此 VID 映射尤为必要。

听从思为老师的建议，我放弃了初期设想的 KV-Cache 方案，因其难以处理动态图中顶点删除后的序号连续性。最终采用了 Snapshot 机制，并使用 python 原生的 pickle 进行持久化。

Snapshot 产生的 pickle 文件 会包含有以下几个内容：

-   vid\_to\_idx
    
-   idx\_to\_vid
    
-   vid\_to\_tag：节点分类信息；
    
-   edge\_type\_groups：三元组信息
    

前两个正反两项映射的设计并非冗余—— dict 里面的 KV 对正向的查询更快，时间复杂度应该是 O(1)，如果在想通过 idx 去找 vid 的时候仅仅用 vid\_to\_idx ，时间复杂度就会到达 O(n)。

## （三）FeatureStore 的扫描策略

最初使用的是 scan\_vertex\_async 接口进行全图扫描，再过滤出所需顶点的属性。用NebulaGraph 提供的 basketballplayer 成功跑通了所有的测试，但却发现这种方法在大规模数据集上效率极低（如 ogbn-products 数据集读取超过 8 小时仍未有进展）。

我试图参考 KUZU 的实现方式：KUZU scan_vertex 函数中，有 indices 这个参数，能直接根据 indices(index) 直接从 storage 中获取指定 indice 的属性。那么在 NebulaGraph 中，只需要在 stroaged 中加入一个算子即可。

该方案被思为老师否决了，当时思为老师说的是 storaged 只适合做全图扫描，并不适合做条件查询。总结如下：

-   NebulaGraph 的 storaged 是基于 RocksDB，有天然的顺序读（iterator）方案，直接具有全图遍历的功能。
    
-   如果想实现这个功能，至少要做谓词求值、联合条件、选择最佳索引、回表取属性、聚合/去重/排序这些事情，从职责上来讲，这些都是 query 优化器的工作，最终还是应该由 graphd 来做。
    

最终我们采用 FETCH 语句查询，实测在 10 万级顶点的读取可在 1.2–1.5 秒内完成。

## （四）get_tensor 中的 x,y 处理

PyG 要求将特征数据拼接为 data.x，标签数据作为 data.y。但 NebulaGraph 不支持 Vector 或复合类型。

我们引入了 Y_CANDIDATES 列表（包含 label、y、target、category 等常见标签名），自动将匹配列作为 data.y。

对于特征列，提供了两种模式：

-   x 模式：自动将所有特征列拼接为 data.x；
    
-   feats 模式：返回原始特征列，用户可自行拼接和消融。
    

## （五）多进程处理

在引入查询机制后，当 DataLoader 的 num_workers 大于 1 时，出现了响应数据错位的问题。根本原因是 NebulaGraph 的 Session 不支持多进程共享，包括 session_pool 也不是进程安全的。

我们通过工厂函数 \+ 懒加载模式为每个进程创建独立 Session，详细方案可参考 [Multi-process Description](https://example.com/multi-process-blog-link)。值得注意的是，PyTorch 的 DataLoader 支持 fork 和 spawn 两种多进程模式，后者行为有所不同，但目前我们的方案是基于 fork 模式设计的。

# 三、致谢

本项目最终实现了一个功能完整、支持丰富的 NebulaGraph-PyG 适配器，在某些方面（如特征处理模式、Snapshot 机制），相比 KUZU 提供了更丰富的功能选项。

特别感谢思为老师对我的指导，如最开始提到的环境问题，我花了一周还没有搞定，思为老师知道后，直接和我开了视频会议，一边详细得和我解释 NebulaGraph 的架构和项目重点，一边花了 2 个小时远程帮我配好了开发环境。

另外，思为老师也让我充分感受到在开源社区中的平等协作。我在和思为老师的线上线下交流中，每次都会带“您”，但思为老师告诉我不必如此，我才意识到“您”带来的疏远感确实好强，这也让我想起我的朋友 iyear 曾告诉我的：在社区里，你身份地位是最不被 care 的，不论是地位，不论年龄，不论国籍，大家平等交流，用心解决问题。

写到这里已经凌晨四点了。原来热爱，从不觉困。

💡本文经过修改与删减，更多技术细节与开发故事见蔡同学博客

[NebulaGraph × PyG](https://fengzdadi.github.io/blog/2025/nebulagraph-pyg/)

通过封装底层图存储访问和数据转换，帮助用户便捷调用 NebulaGraph 数据，免去繁琐的数据预处理，使 GNN 的训练和推理更加高效便捷。

如何实现 NebulaGraph 与 PyG 高效集成？

# 背景💻

8 月 22 日，**NebulaGraph 在香港成功举办“深度关联与实时分析下的金融新范式”nMeetUP**, 邀请金融科技、Web3、人工智能等领域的多位专家，围绕图技术、股权穿透、Crypto 风控、知识图谱等热点话题展开了深度分享。

一起回顾本次 nMeetUp 的精彩议题吧～

# PPT 获取🔗

https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/HongKong-0822/HongKong-meetup-0822.pdf

# 议题回顾🎯

## 1️⃣中证数智：NebulaGraph 赋能金融机构穿透式管理

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


**中证数智@胡新**，分享了如何通过 NebulaGraph 将海量数据构建为关联关系网络，帮助金融机构深切落实"穿透式"监管，并通过图计算实现实控人挖掘、集团客户集中度控制、关联交易识别、反洗钱可疑交易识别等风控合规应用，及客户管理商机挖掘等营销应用。

**（一）重点回顾**

**1. 知识图谱构建：**

* 整合内外部数据源，包括工商、司法、舆情、交易等，构建覆盖全市场的企业关系图谱， 3 亿+节点，4 亿+边。
* 支持多类型节点（企业、人、产品）和关系（持股、担保、交易、诉讼等），并通过图更新工具实现动态更新。

**2. 图算法实现股权穿透：**

* 利用疑似实际控制人算法和表决权迭代法，解决传统持股算法在多层嵌套股权结构中的穿透力不足问题。
* 支持无限层级穿透，实测最深可达 50 层，覆盖董事、监事、高级管理人员超 4 亿个节点。

**3. 应用场景：**

* 风险传导分析：实时识别客户与风险主体之间的关联路径。
* 集团客户管理：识别实际控制人，防范关联交易风险。
* 智能营销：通过图谱挖掘潜在业务机会，提升营销精准度。

**（二）技术亮点**：

* 使用 NebulaGraph 实现毫秒级多层关系查询；
* 对比传统解决方案的 2 周耗时，4 亿节点的数据加载及股权穿透可在 24h 内完成。

## 2️⃣Apache Doris：构建金融级可观测性方案

![](https://picx.zhimg.com/80/v2-ed4e0dd0d35f0caa95cfb2642967f120_1440w.png)


**VeloDB@肖康**，介绍了基于 Apache Doris 核心驱动的可观测性解决方案。

**1. 架构优势**：

* 存算分离，灵活适配不同部署需求。
* 支持多表关联、向量化执行、CBO 优化器，在 ClickBench、TPC-H 等基准测试中表现优异。

**2. AI 时代新能力**：

* **向量检索**：支持混合查询（关键词+向量），适用于 RAG 场景。
* **MCP协议**：支持与大模型交互，提供数据库查询、结构分析、性能监控等 AI 原生工具。
* **AI Functions**：内置 LLM_TRANSLATE、LLM_FILTER 等函数，支持在 SQL 中直接调用 AI 能力。

## 3️⃣BlockSec：用 NebulaGraph 打造 Crypto 风控系统

![](https://picx.zhimg.com/80/v2-307a5e3e9840c687a979d42512c0c90c_1440w.png)


**BlockSec @谢云飞**，认为在链上世界中，“图是骨架，标签是灵魂”，分享了如何利用 NebulaGraph 为链上地址和交易打标签，构建加密货币领域的风控系统，应对链上洗钱、黑客攻击等风险。

**（一）重点回顾**

**1. 标签系统**：

* 通过链上行为模式、链下情报、人工专家分析等方式为地址打标签（如漏洞利⽤、钓⻥攻击、混币器等)，准确识别⾼⻛险实体与行为。
* 通过多源交叉验证和产品反馈循环不断提升标签精确度。

**2. 风控系统架构**：

* 四层架构：数据层（多链数据提取）、情报层（地址标签生成）、存储层（NebulaGraph）、计算层（风险引擎）。
* 支持实时数据流入、标签动态更新、风险路径计算。

**3. 风险量化模型**：

* 基于法币敞⼝计算、时间序列过滤、理发策略构建⻛险模型。
* 计算在⼀笔资⾦中，来源于诈骗者和攻击者的比例，实现风险量化的目标。

**（二）技术亮点**

* 采用多源情报融合机制，日均处理超百万地址标签。
* 基于时间序列过滤与权重分配算法，实现跨链资金流溯源，精准量化风险贡献比例。

## 4️⃣普适智能：基于知识图谱的 Web3 风控策略

![](https://picx.zhimg.com/80/v2-ee968fd15287a8cd131dba5232d3d04a_1440w.png)


**普适智能@陈啸翔**，分享了如何利用 NebulaGraph 整合链上交易、链下身份及社群行为等多维数据，构建动态风险感知网络，实现对复杂风险（如身份欺诈、恶意交易、合约漏洞）的精准识别与主动防御，为 Web3 业务的稳健与安全运行提供核心支撑。

**（一）重点回顾**

**1. 风控挑战**：

* 交易所面临批量注册、洗钱交易、黑客提现等风险，传统规则引擎难以应对复杂关联关系。
* 数据源分散，链上链下数据融合困难，实时性要求高。

**2. 图模型构建**：

* 整合地址、设备、IP、身份 ID 等多维数据，构建统一风控图谱。
* 使用 Louvain 社区发现、中心性分析等算法识别风险团伙。

**3. 实时风控架构**：

* 双集群架构：在线集群负责高并发读写，离线集群负责异步图计算与机器学习。
* 支持实时图规则引擎，可在注册、登录、交易等环节实时阻断风险行为。

**4. 典型场景**：

* 批量注册检测：通过 IP、设备、行为路径等关联识别 Sybil 攻击。
* 交易风险分析：通过资金汇聚、路径异常等模式识别洗钱行为。

**（二）技术亮点**

* 支持百亿级节点规模的图谱构建与查询；
* 图特征嵌入机器学习模型，提升风控准确率；
* 提供零代码图谱构建与可视化分析平台。

# 5️⃣Apache Doris 4.0：人工智能时代的数据仓库

![](https://picx.zhimg.com/80/v2-407ccd9bea30a9f21a8d0db339024fbf_1440w.png)


**VeloDB@李文强**，介绍了 Apache Doris 4.0 在查询优化、执行引擎、向量检索等方面的技术升级。

**1. Pipeline 执行引擎**：

* 引入 Pipeline 模型，实现算子间数据流式交换，减少线程切换开销。

**2. 向量检索与 AI 集成**：

* 支持浮点型向量索引和混合查询（关键词+向量）。
* 内置 MCP Server，支持与 AI Agent 无缝集成，提供数据库查询、结构分析等功能。

# Ending🎉

作为 NebulaGraph 在香港的首场 nMeetUp，它的意义远不止于一次技术分享，我们希望更多小伙伴了解图、应用图，推动金融风控、营销与决策走向深度关联与实时智能的新阶段。

香港！期待下次再见～🇭🇰


# 案例分享💼

我们会将 NebulaGraph 相关议题整理成文，为大家解锁 NebulaGraph 的业务价值提供参考，请关注近期 NebulaGraph 公众号推文～

# 致谢❤️

特别感谢中证数智、普适智能、BlockSec 的大力支持～

![](https://picx.zhimg.com/80/v2-88c174d5c8c93e90f7b6bd2e8647d567_1440w.png)

![](https://picx.zhimg.com/80/v2-5d86795f5aa5bdafaee2f47dc2fbf408_1440w.png)

香港 nMeetup 回顾+PPT下载｜香港 nMeetup 回顾+PPT下载｜Web3 风控+知识图谱+股权穿透+金融合规

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


# 01 关于 Nebula Contrib

Nebula Contrib 是由 NebulaGraph 社区贡献者（包括社区用户、独立开发者、合作伙伴）共同创建和维护的生态项目集合。为了解决实际使用中的小麻烦、探索新玩法，或者单纯想让大家用得更顺手，他们开发了相应的项目，并秉持“众人拾柴火焰高”的开源精神，将其贡献给社区，合入到 Nebula Contrib 中，NebulaGraph 官方会为这些项目提供一定的指导与支持，但主力军仍是这群可爱的社区贡献者。

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


# 02 Nebula Contrib 里的超赞项目

## graph-ocean

**👍项目发起人**：@Anyzm

🔗**GitHub**：https://github.com/nebula-contrib/graph-ocean

📕graph-ocean 是一基于 nebula-java 客户端的 ORM 框架，其诞生源于实际业务中的痛点：Anyzm 就职于奇富科技，早期使用 NebulaGraph（v1.0.0） 时，Java 客户端是用枚举来呈列用到的 Tag 和 Edge 数据，而将 API 解析成 nGQL 的过程中也强依赖枚举，对业务代码侵入性强。因此 Anyzm 借鉴 JPA（Java Persistence API） 注解思想，设计了一套轻量级注解，将实体映射到数据库元素。

* 基于注解将实体与 NebulaGraph 的顶点、边、属性自动映射，实现对象与图数据的双向转换。

* 提供核心 API，支持顶点/边的增删改及查询操作，无需手动编写 nGQL 语句，直接操作 Java 对象即可。

* 实体对应的元数据在首次解析后缓存，避免重复运行反射计算实体与 schema 的映射关系。

🥳**一些小彩蛋**

* 奇富科技是 NebulaGraph 最早期的用户之一，在使用过 Neo4j、AgensGraph、JanusGraph 后，奇富科技于 2020 年 6 月使用刚发布的 NebulaGraph. 如今，NebulaGraph 仍被广泛应用于奇富科技的反欺诈、图挖掘、大数据血缘、图+大模型等多个核心场景。

* 大家熟悉的论坛活跃用户@江一旺（Puto 交流群热心答疑助手@awang ）也来自奇富科技，他也在 Nebula Contrib 下贡献了一款针对 JetBrains 的 Console 工具——nebula-console-intellij-plugin 2，支持 nGQL 语法高亮和关键字自动补全、数据表格分页显示、关系图展示等，可方便快捷操作 NebulaGraph.

## NgBatis

👍**项目发起人**：@CurvusY

🔗**GitHub**：https://github.com/nebula-contrib/ngbatis

📕NgBatis 是针对 NebulaGraph+ Springboot 的数据库 ORM 框架。包含了一些类似于 mybatis-plus 的单表操作，另外还有一些图特有的实体-关系基本操作。该项目的初衷是尽可能地减少日常开发中或重复或繁琐的工作。

* 开箱即用，实现与 Springboot、Springcloud 的快速集成

* 实现 GQL 与 Java 代码分离，使用 XML 统一管理

* 使用模板引擎，解决 nGQL 参数拼接繁琐、容易写错的问题

* 实现 ResultSet 与 Java 对象根据属性名自动转换

* 单表基本增、删、改、查以及分页

* 本地 Session 管理，降低资源消耗

🥳**一些“小彩蛋”**

大叶老师是生物学专业，大三开始去计算机系蹭课，后来又上了计算机培训班，毕业后如愿成为一名程序员，目前是笃笃科技 founder. 产品名为星影——图数据库客户端，提供可视化操作界面，让用户可以通过图形化的方式，对图数据库进行操作，目前支持且唯一支持 NebulaGraph. 在[《NebulaGraph + DeepSeek 轻松看懂《哪吒2》人物关系》](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515541&idx=1&sn=062562907c6c65e940d34a95ac251ad8&scene=21#wechat_redirect)中，非常漂亮的《哪吒2》人物关系可视化效果就出自星影。

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


> 💡以上两个项目都是基于 Java 的 NebulaGraph ORM，如果你习惯用 JPA ,可以选择 nebula-ocean, 如果更习惯 MyBatis 进行开发，并希望你的问题得到快速反馈与解决（大家都开玩笑说大叶老师住在 GitHub 和技术交流群里，回复速度极快），那么 NgBatis 将是最佳选择。

## NebulaGraph MCP Server

👍**项目发起人**：@PsiACE

🔗**GitHub**：https://github.com/nebula-contrib/nebulagraph-mcp-server

🥳PsiACE 在 MCP 开源后，就快速将 MCP 集成至 LlamaIndex，随后开发了 NebulaGraph MCP Server. 它可以将 NebulaGraph 的功能暴露为标准化的工具接口，从而让大模型轻松调用 NebulaGraph 数据，实现一系列的图探索任务。PsiACE 将其贡献给社区，供大家更轻松地探索 NebulaGraph + AI 的无限可能。

1. 多种传输方式：

支持 stdio 和 SSE 两种传输模式，满足不同开发和部署场景的需求。

1. 基础图探索能力：

* 图空间（Graph Space）列出：允许模型查询可用的图空间。

* 模式（Schema）查询：支持查询指定图空间的模式定义。

* 查询执行（Query Execution）：支持通过 MCP Server 执行 NebulaGraph 查询。

1. 内置算子模板：

* 实现了路径搜索和邻居发现等常用操作的模板，方便语言模型按需调用这些工具，快速获取图数据的初步洞察（Insight）。

🥳**小预告**

PsiACE 近期一直在做 NebulaGraph 的 GenAI 相关工作，后续会将许多经验与工作进展分享到社区，大家可以大大的期待一下～

## 还有这些⬇️

1. nebula-jdbc ：JDBC 驱动，可使用 JDBC API 来操作 NebulaGraph

2. nebula-carina：NebulaGraph Python ORM，简化 Web、AI 开发

3. nebula-norm：NebulaGraph Golang ORM，只用实例对象即可进行图数据查询

4. DataX-nebula：阿里云 DataX 插件，批量离线导入导出 NebulaGraph 数据

5. nebula-bench：基准工具箱，使用LDBC 数据集测试 NebulaGraph

6. nebula-node ：Node.js 客户端，少量代码即可在 Node 里跑 NebulaGraph

7. nebula-net：数据工具，将 MySQL 集群中的数据实时同步到 Nebula Graph

……

Nebula Contrib 里每个项目都非常棒～但由于篇幅原因，本文仅挑选部分项目进行介绍，访问下方链接探索更多有趣的项目：

https://github.com/nebula-contrib/

# 03 成为 Contributor

许多小伙伴经常和星云仔说：“我也想成为 contributor，但感觉好难啊。”

其实，这门槛真的比你想象中低得多～谁说贡献就一定要去啃内核、改存储引擎？

NebulaGraph 的内核上手难度确实不低，但围绕它的生态工具、应用扩展、周边适配，才是社区最需要、也最容易上手贡献的领域！这就是 Nebula Contrib 存在的意义——让每个人的小想法、小优化，都能汇聚成照亮他人的光芒。

**你的贡献，如此多样**：

* 开发一个小工具：就像 NgBatis、nebula-carina 那样，用你熟悉的语言把它实现出来！一个数据迁移脚本、一个可视化插件... 解决一个具体的小痛点，就是巨大的价值！

* 写写文档，润润色： 发现某个项目的 README 不够清晰？某个功能的使用说明有歧义？上手写！文档贡献是社区最最最欢迎的～

* 帮忙捉虫： 试用 Contrib 里的项目，发现哪里运行不正常？或者有性能可以优化的地方？提交一个清晰的问题报告 (Issue)，详细描述你的发现，甚至提出改进思路，就是在帮项目变得更好！如果能顺手提交一个修复的 PR (Pull Request)，那就更棒了～

**不限于 GitHub ，你还可以**：

* 分享你的使用经验： 把你使用 NebulaGraph 的经验写成博客、在社区论坛分享，也欢迎来 nMeetup 上做个 lightning talk～

* 答疑解惑： 在论坛或微信群里，看到有人遇到了你曾经解决过的问题？伸出援手，耐心解答！维护一个友好、活跃的社区氛围。

# 04 Ending

Nebula Contrib 是 NebulaGraph 社区创造力和协作精神的生动体现。从提升开发体验的工具，到探索前沿应用的桥梁，这里的每一个项目都凝聚着社区伙伴的智慧～

欢迎你加入这个有爱的 org,让 NebulaGraph 更强大(•̤̀ᵕ•̤́๑)ᵒᵏᵎᵎᵎᵎ

Nebula Contrib 是由 NebulaGraph 社区贡献者（包括社区用户、独立开发者、合作伙伴）共同创建和维护的生态项目集合。

这个宝藏 org ！有超多 NebulaGraph 实用工具～

> 导读：图数据库的核心价值在于揭示数据之间隐藏的复杂关系。NebulaGraph 支持丰富的图算法，将隐秘关系高效转化为 actionable 的洞见。
> 本期技术科普将带你了解图算法与 NebulaGraph Algorithm，看看 NebulaGraph 社区用户如何将这些图算法用于生产环境以及如何上手。



# **一、** 图数据库与图算法

## （一）什么是“图”？

想象一下你有一张**关系网**：

**1\. 点**：代表独立的实体。比如：

-   你微信里的所有好友。
    
-   城市地图上的所有十字路口。
    
-   一个项目里的所有任务。
    

2.**线**：代表这些实体之间的关系。比如：

-   微信里，你和某个好友是“好友关系”（一条线连着你俩）。
    
-   城市地图上，两个十字路口之间有一条“道路”（一条线连着两个路口）。
    
-   项目里，任务 A 必须在任务 B 开始之前完成（一条线从 A 指向 B，表示依赖）。
    

这种由“点”（图数据库中的顶点或节点）和连接它们的“线”（图数据库中的边）组成的结构，就叫做“图”。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/nebula-graph-studio-case.webp)

（用 NebulaGraph Studio 进行某公司股权穿透）

## （二）什么是图算法？

图算法就是一套聪明的“解题思路”或“工具包”，专门用来分析这种“点”和“线”组成的关系网，计算关于这个网络的问题。

**为什么需要专门的“图算法”？**

-   **超越简单查询**：传统查询能找到直接邻居，但图算法能分析整个网络的结构和动态。
    
-   **量化关系价值**：把模糊的“关联”变成可计算的指标（如重要性、紧密度、相似度）。
    
-   **发现隐藏模式**：自动识别传统关系数据库难以查询的社群、关键枢纽、传播路径。
    

**图算法的应用**

**找最短路径：**

-   **问题**：从家（点A）导航到公司（点B），导航如何规划最快/综合成本最低的路线？
    
-   **图算法**：经典的最短路径算法（如 Dijkstra 算法），能快速计算出从 A 到 B 的所有可能路线中，总权重（通常代表路程长度、通行时间或综合成本）最小的那条路径。
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/dijkstra.webp)

**好友推荐：**

-   **问题**：微信/微博/Facebook 怎么知道你可能认识谁，从而给你推荐好友？
    
-   **图算法**：基于共同邻居的链路预测算法（如 Jaccard 算法）会分析你的社交网络图：关注你的直接好友（一度邻居），然后考察他们的好友（你的二度邻居）。那些与你拥有大量共同好友（即共同的一度邻居） 但尚未与你建立连接的人，就很可能被推荐给你。
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/jaccard.webp)

**网页排名：**

-   **问题**：搜索引擎怎么决定当你搜索“图算法”时，哪个网页应该排在前面？
    
-   **图算法**：PageRank 算法。它的核心思想是：
    
-   被很多其他网页链接指向的网页（点），通常比较重要（票数多）。
    
-   被一个重要网页链接指向的网页，也会获得更高的重要性（重要的一票更有分量）。
    
-   算法会不断计算每个网页的“重要性得分”，得分高的排名就靠前。
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/page-rank.webp)

# **二、图算法类型及应用场景**

图算法大致可分为以下几种类型：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/%20algorithm-over-view.webp)

# **三、NebulaGraph Algorithm**

NebulaGraph Algorithm 是一款基于 GraphX 的 Spark 应用程序，通过提交 Spark 任务的形式使用完整的算法工具对 NebulaGraph 数据库中的数据执行图计算，也可以通过编程形式调用 lib 库下的算法针对 DataFrame 执行图计算。

## （一）NebulaGraph 支持的图算法

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/nebula-graph-algorithm-overview.webp)

> 上图为社区版支持的基础图算法，企业版支持更多高性能算法（如 InfoMap、APSP、DegreeWithTime、HyperANF 等）及基于 ISO-GQL 的自定义图算法。

## （二）NebulaGraph 用户这么用

**NebulaGraph 用户们如何用图算法解锁业务价值？**


### **1、中心性分析-PageRank**

-   **何时用**：当你需要找出整个网络中“影响力大”或“被广泛引用/连接”的节点时。
    
-   **场景举例**：识别社交媒体上的关键意见领袖；在金融交易网络中定位核心中转账户。
    
-   **社区用户**：[Boss 直聘](https://www.nebula-graph.com.cn/posts/NebulaGraph-use-case-BOSS-zhipin)整合链路追踪（Trace）、系统指标（Metrics）、日志（Logs）三大数据源，构建统一的全链路异常拓扑图，发现多个真子图分散出现在图结构中，每个子图都有“风暴中心”，故采用 PageRank 算法动态计算节点故障权重（Rank 值由节点出入度、链路错误数、事件进行加权计算），得出 Rank 值最高的 TopN 故障节点（即 “风景眼”），从而快速实现根因定位，平均收敛时间仅 20s.
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/boss-use-nebula.webp)

### **2、 社区发现-Louvain、Hanp**

-   **何时用**？需要在大规模网络中发现层次化的社区结构时。
    
-   **场景举例**：社交网络中的兴趣社群划分；电商用户群体细分（购买模式相似）；城市交通流量分区。
    
-   **社区用户**：[中国移动](https://www.nebula-graph.com.cn/posts/cmcc-financial-riskcontrol-practice)首先基于所有移动用户构建一个关系网络，采用 Louvain、Hanp 算法进行社区发现与挖掘，如个人的信用评分以及个人之间的关系，然后对这个社区进行打分，识别出这个社区是否为一个欺诈社区或者是一个低信用的社区，从而进行风险管理。
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/zhongguoyidong-use-nebula.webp)

### **3、社区发现-LabelPropagation**

-   **何时用**？需要快速发现社区，或者网络结构清晰、社区边界明显时。
    
-   **场景举例**：实时推荐系统中的用户兴趣圈识别；新闻/信息传播路径上的群体划分。
    
-   **社区用户**：在[众安保险](https://www.nebula-graph.com.cn/posts/zhongan-insurance-knowledge-graph-practice)，LabelPropagation 应用于贷中环节。LabelPropagation 主要是通过一个确定的点 Y 去传播、衍生出它相关点。比如，贷中用户名单中某个用户是严重逾期人员，这个人员便是打上逾期标签的确定点 Y，结合既定的风控规则查看点 Y 关联延伸的点中哪些点出现相似逾期行为，从而判断这些点是否属于严重逾期的社群。
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/zhonganbaoxian-use-nebula.webp)

### **4、ConnectedComponent/StronglyConnectedComponent**

-   **何时用？** **CC** (弱连通分量)关心是否可以通过路径（忽略边方向）连通。用于发现孤岛。SCC (强连通分量)：关心是否可以通过有向路径互相到达。用于分析紧密循环依赖。
    
-   **场景举例**：分析社交网络中的孤立用户群体 (`CC`)；研究论文引用网络中的研究学派 (`SCC`)；分析系统模块间的循环依赖 (`SCC`)。
    
-   **社区用户**：[众安保险](https://www.nebula-graph.com.cn/posts/zhongan-insurance-knowledge-graph-practice)使用 ConnectedComponent 计算出用户关系图谱。当发现一个手机号被异常数量（如五六十人）标记为“家庭联系人”时，该手机号及其关联用户即构成一个潜在风险社群。处于此类异常社群是用户风险的强信号（充分不必要条件），用户也可能是因亲属涉黑产而被牵连。众安据此对社群内用户进行初步风控标记和深入核查。
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/zhonganbaoxian-use-nebula.webp)

# 四、NebulaGraph AI Suite

除了 NebulaGraph Algorithm, @wey 在 2023 年为社区提供了一个名为 NebulaGraph AI Suite 的项目，它是在 NebulaGraph 之上跑算法的 Python 套件，能给用户一个自然、简洁的高级 API。简单来说，用很少的代码量就可以执行图上的算法相关的任务。

在[《手把手教你用 NebulaGraph AI 全家桶跑图算法》](https://www.nebula-graph.com.cn/posts/nebulagraph-ai)中，@wey 给出了详细的上手教程。该项目完全开源，如果你有新的 idea, 欢迎共建～

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/nebula-ai-suite.png)


# 五、行动起来～

NebulaGraph Algorithm，提供了一套强大的“关系显微镜”。那些困扰你的问题（谁最重要？哪些人是一伙的？最优路径怎么走？）是否能用图算法来解决？访问 NebulaGraph 官方文档，深入了解 NebulaGraph Algorithm 的配置细节，开始你的图算法探索之旅吧！

文档🔍⬇️

[https://docs.nebula-graph.com.cn/3.8.0/graph-computing/nebula-algorithm](https://docs.nebula-graph.com.cn/3.8.0/graph-computing/nebula-algorithm)

---

[香港 nMeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247517169&idx=1&sn=ab591d3a4bb66d9e5cd65caaf59b7100&scene=21#wechat_redirect) 报名中🔥

进一步探索 NebulaGraph 在#知识图谱、#Web3、#金融风控 的最新应用

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




带你了解图算法与 NebulaGraph Algorithm，看看 NebulaGraph 社区用户如何将这些图算法用于生产环境以及如何上手。


技术科普｜图算法是什么？何时用、怎么用？

> 导读：在开源之夏 2025，李萧同学成功中选【为 NebulaGraph Exchange 实现插件化数据源】。他的项目申请书清晰且全面，与 mentor 沟通积极，虽然是第一次为开源项目实现 feature，但最终**仅用了两周的时间顺利完成开发任务并合入**。本期我们邀请李萧同学分享他在 NebulaGraph 社区的开源之旅，也为对开源项目感兴趣但迷茫的小伙伴们提供一些参考～

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

个人主页：

https://melodylx666.github.io/lx-bigdata/

**关于开发项目**

为 NebulaGraph Exchange 实现插件化数据源，使 NebulaGraph Exchange 支持导入自定义数据源数据。

PR：

https://github.com/vesoft-inc/nebula-exchange/pull/209

文档：

https://docs.nebula-graph.com.cn/3.8.0/import-export/nebula-exchange/use-exchange/ex-ug-import-from-custom/

---


参与开源之夏 2025，在 NebulaGraph 社区做贡献，对我个⼈⽽⾔收获很多，我想将⼀些通⽤的开发思路分享出来，和⼤家⼀起交流进步。本⽂的核⼼内容主要分为择项原因、开发经验、项目收获三个部分。

# **一、择项原因**

为什么选择 NebulaGraph 技术社区以及【为 NebulaGraph Exchange 增加插件化数据源】这⼀项⽬呢？

## 1\. 对⽣态增强这⼀类型的项⽬感兴趣

很多⼈都⼗分向往数据库的开发，⽽传统的数据库内核开发对开发者要求很⾼，并且竞争激烈。**于是我认为可以从其他⻆度切⼊：⼀个完整的数据库产品，内核研发并不是全部**。⽣态增强(⽐如数据库导⼊导出)⼯具，对于开发者来说相对容易上⼿，⽽用户也往往更加⻘睐⼯具丰富的数据库产品。

上述思路不只可以⽤在开源之夏，在⽇常的实习求职⽅向上也可以借鉴。

## 2\. 技术栈匹配

NebulaGraph Exchange 是⼀个完全由 Scala 编写的 Spark Application，⽽ Spark ⼜是我⽐较熟悉的计算引擎。所以从技术上来说开发的卡点会⽐较少。

## 3\. 社区支持

因为本地开发环境的限制，想要完整跑通⼀个⼤数据类的项⽬是并不容易的。⽽ NebulaGraph Exchange 的社区资料⼗分完善，和导师的沟通交流也⼗分顺畅，使得我可以快速上⼿项⽬并验证想法。

# **二、开发经验**

开发经验部分，**我将其分为【需求理解】以及【功能开发】两个核⼼阶段**，这也是上⼿所有项⽬的必经之路。

## 1\. 需求理解

对需求的理解程度直接决定了后续开发的质量。看到需求描述，我们需要清楚对于开发者和用户来说，当前的痛点是什么。这部分值得多花⼀些时间来考虑清楚。可以⾃⼰总结完毕之后，和导师交流，后续的设计与开发就围绕确定下来的核⼼痛点展开。

针对【为 NebulaGraph Exchange 实现数据源插件化】任务⽽⾔，可以发现原有的痛点如下：

-   对于开发侧，每增加或者修改⼀种新的数据源，都要对原有代码进⾏改动并重新发版，数据源维护成本较⾼。
    
-   对于用户侧，⽆法添加⾃定义数据源，以及修改现存数据源设计。
    

我个⼈的最初想法其实是将所有的数据源全部去除，统⼀使⽤插件 jar 包⽅式维护。⽽在和导师沟通之后，明确了可以将数据源划分为存量数据源和增量数据源，分别使⽤不同的数据源管理模式，这样在开发侧可以做到最⼩改动，⽽用户侧可以低成本升级。

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

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

（节选自李萧同学的项目申请书）

## 2\. 功能开发

在开发任何功能的时候，都需要从以下三个⻆度来思考问题：

-   正确性：既要保证新增功能能够正确运⾏，⼜要保证不能影响原有功能。
    
-   ⾼效性：在正确性基础之，上优化功能细节，提⾼运⾏效率。
    
-   易⽤性：在正确性基础之上，保证用户可以低成本上⼿。
    

这⼏点看上去像是“正确的废话”，但是在开发过程对于这⼏点的关注是不可或缺的。下⾯我会结合本次任务来具体说明。

**正确性**

最简单的⽅式就是通过“最⼩改动”的⽅式来添加新功能，也就是在需求理解部分提到的，将数据源进⾏类型划分，专注于⾃定义类型的数据源的引⼊即可。同时，由于 NebulaGraph Exchange 涉及到不同版本的 Scala & Spark，实现的时候就需要关注使⽤的语法是否在不同版本都可以通过编译和单元测试。

**⾼效性**

其实插件化数据源加载在本质上不会成为系统的性能瓶颈，因为它只是在 Tag/EdgeType 粒度上做的类加载，不过依旧需要明确插件的加载时机以及实现⽅式(是Scala object 还是 Java class)。

**易⽤性**

这点是⼗分关键的。为了让启动命令改动最⼩，在代码实现时抛弃了添加额外命令⾏参数，在内部实现了数据源模式的⾃动切换。同时，插件的形式，从开始繁杂的插件实例管理，到最后统⼀修改为了配置驱动的插件单例对象，用户对于插件实现的⾃由度更⾼。最后也输出了⼀份易于上⼿的用户⽂档，便于使⽤此功能。

# **三、项⽬收获**

本次开源之夏的开发，令我印象最深的就是**对于需求的充分理解永远需要排在⾸位。**现在可供参考的优秀开源代码越来越多，⽽ AI Coding ⼯具也越来越强，代码开发变得越来越便捷。对于开发者来说，只有不断提升对需求的理解能⼒，才能让这些开发⼯具更好地为⾃⼰所⽤，提升⾃⼰的开发效率。**

最后，感谢安祺导师，以及 NebulaGraph 社区运营⼩姐姐。在开发过程中，她们给了我很⼤帮助，让我在开源之夏的体验直接拉满～

> 星云仔有话说

**每年开源之夏都有数百个开发项目，作为开源小白，如何选择适合自己的开源项目呢？**


**先“大海捞针”**：1️⃣兴趣2️⃣技术栈3️⃣难度，兴趣永远是最好的老师，技术栈决定你是否有完成一个项目的基础能力，难度就不多说了～结合这三点，在开源之夏搜索关键字，至少能找到 3 个符合你条件的项目。

**再“择优录取**”：1️⃣完成这个项目能带给我什么？（从开发过程中我将得到哪些成长？对我以后想从事的 xx 岗位有帮助吗？）2️⃣这个项目所在社区是否活跃？这个社区的背景如何？3️⃣我当前的能力和时间，选择哪个项目能够出色的完成？结合这三点，再挑选一个最适合自己的项目。


**跳出开源之夏，高校开发者如何选择第一个开源项目呢?** NebulaGraph PMC Sherman 曾给出两点建议:一是与兴趣匹配，开源项目意味着技术的快速迭代与变革创新，开发者往往面临纷繁复杂的疑难问题，而兴趣是挑战困难的第一动力;二是与知识能力匹配，这不仅能提高学习和贡献的效率，还能在实践中稳步提升技能，逐步迈向更复杂的项目挑战。

**最后，祝大家都能拥抱开源，享受开源～**


---

[香港 nMeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247517169&idx=1&sn=ab591d3a4bb66d9e5cd65caaf59b7100&scene=21#wechat_redirect) 报名中🔥

进一步探索 NebulaGraph 在#知识图谱、#Web3、#金融风控 的最新应用

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

社区开发者为 NebulaGraph Exchange 实现插件化数据源，使 NebulaGraph Exchange 支持导入自定义数据源数据。

如何高效地为开源项目做贡献？以 NebulaGraph Exchange 为例


> 导读：本文整理自 NebulaGraph 解决方案架构师@鲍翰林的分享，文末附分享回放与 PPT 下载。


8 月 1 日，香港《稳定币条例》正式生效，这是全球首个针对法币稳定币的全面监管框架，标志着稳定币行业迈入强监管时代。条例核心要求清晰而严格：锚定法定货币、需持牌经营、100%资产储备、充分披露、定期审计、遵守 KYC/AML.

新规之下，行业如何构建满足监管要求、抵御复杂风险的风控体系？图技术正凭借其深度关系挖掘、实时风险洞察的独特能力，成为 Web3 合规风控的新基石。


# 一、强监管时代，传统风控力不从心

传统数据库无法构建稳定币的关系网络

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-risk-control.png)

* **脱锚隐患**：链上风险叠加传统金融风险外溢，易引发价格脱钩。
* **黑产猖獗**：黑客盗币、洗钱、批量注册套利等行为利用链上匿名性隐蔽操作。

* **数据孤岛**：传统风控依赖“表单式”数据分析，难以穿透多跳地址、识别跨平台关联团伙。

**稳定币风控的核心痛点在于全是“关系”**，本质是关系密集型、路径驱动型的：黑客的一次盗币往往涉及“异地登录→异常设备→快速创建 API→卖币→提币至陌生地址”的完整行为链，并通过多跳地址转移资金。

**关系型数据库在建模复杂实体关系（如“IP-设备-地址-交易”的多维关联）、执行深度链路查询（如追踪 5 层转账路径）时存在天然瓶颈**，导致风险漏判与响应滞后，面对加密世界复杂、动态的“关系网”？显然力不从心。

[复杂关系场景，图数据库为何是首选？](https://discuss.nebula-graph.com.cn/t/topic/16889)


# 二、图数据库天然适配 Web3 风控

图数据库以“点”（即实体，如人、地址、设备）和“边”（即关系，如 A 给哪些账户转账、B 用了哪些不同设备登录）建模现实世界，天然契合 Web3 多源异构、强关联的数据特征。

基于 NebulaGraph 的风控解决方案架构分为三层：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-solution.png)

## 数据层：融合链上链下全域数据
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-web3-data.png)

整合链上地址（Crypto Address）、交易记录（Blockchain TX）、用户 KYC 信息（ID/Phone/Email）、支付渠道（Card/Fiat）、设备指纹（IP/FVIDEO）等，构建千亿点万亿边的统一图模型，为关系网络分析奠定基础。


## 图引擎层：分布式计算与实时分析


### 1. 社区发现算法（WCC/Louvain）：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-web3-algorithm.png)

自动聚类高风险团伙。例如，通过关联共用IP、设备或资金汇入同一“黑洞地址”的账户群，揪出背后操控的“羊毛党军团”。


### 2. 实时图规则引擎：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-real-time.png)

毫秒级识别风险模式。如“5 分钟内同一 IP 登录 10+地址”触发盗号预警；“多地址向未关联 KYC 的新地址大额转账”触发洗钱拦截。


### 3. 多跳穿透查询：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-web3-query.png)

秒级追踪 N 层资金链路。结合区块高度与时序过滤，精准还原黑客的混币路径。


### 4. 应用层：驱动风控全流程升级

* 事前预警：基于图特征（出入度、中心性、社区紧密度）动态生成策略。
* 事中决策：实时扫描 N 度关联实体，风险扩散拦截（如标记一个涉诈钱包，自动冻结其紧密关联账户）。
* 事后分析：可视化还原攻击路径，辅助审计举证。


> 算法突破：相比 GraphX ，NebulaGraph 企业版在算法性能上实现 10-100 倍提升，内存开销降低 5 倍，并支持 ISO-GQL ，降低开发门槛。



# 三、NebulaGraph x Web3 风控案例


## 百亿级 CSI 风控平台

**挑战**：交易所日交易量超百亿美元，需在海量数据中识别洗钱、市场操控等可疑活动，满足严格 AML/KYC 要求。

**方案**：基于 NebulaGraph 构建 40 亿点、400 亿边的风控图谱，融合链上/链下数据。

**价值**：
* 秒级穿透交易链路：追踪资金多层流转路径。
* 精准识别跨平台风险：发现隐匿的关联账户网络。
* 自动化合规报告：提升审计可解释性与监管透明度。


## 交易所实时营销反作弊

**挑战**：某交易所空投活动中，80% 的高额奖励被 5% 的地址盗走，羊毛党利用“设备农场”控制数百地址套利。

**方案**：构建 3000 万点、20 亿边的用户-设备-活动图谱，实时分析关联。

**价值**：

* 误报率降至 5% 以下：精准识别“单点正常、群体异常”的作弊集群。
* 50 毫秒完成 3 跳查询：实时拦截批量注册与套利行为。
* 存储减 40%，算力省 60%：大幅优化资源成本。


## 链上资金追踪

**挑战**：黑客利用多跳地址和混币器隐藏路径，传统分析难以追踪。

**方案**：整合 30亿+ 标签地址，构建 3 亿节点、10 亿边资金流图。

价值：

* 深度交易图谱分析：还原跨链洗钱与攻击路径。
* “地址健康度”画像：动态评估风险等级。
* API 响应<1.5 秒：支撑实时合规审查。


# 四、Ending

当链上风险日益复杂化、隐蔽化，传统风控手段已显疲态。NebulaGraph 凭借深度关系挖掘、实时多跳穿透、动态风险扩散的能力，为监管机构与 Web3 企业提供了关键基础设施：

* **对稳定币发行方**：确保 100% 储备透明可追溯，满足定期审计要求。
* **对交易所/钱包**：实现毫秒级反欺诈、反洗钱拦截，降低合规成本。
* **对监管机构**：获得可解释、可验证的全链资金视图，提升监管效率。



**🎯联系我们**

填写 NebulaGraph 企业版咨询问卷，根据你的业务场景与需求，我们将安排相关人员为您提供专业解决方案。

*🫱https://www.nebula-graph.com.cn/contact*

**⏬直播回放及 PPT 下载**

访问 NebulaGraph 论坛下载 PPT.


**[🔥香港 nMeetUp 报名中](https://mp.weixin.qq.com/s/wxMFmd3Ny45M8yv6wuOtAw)**

进一步探索 NebulaGraph 在知识图谱、Web3、金融风控的最新应用



《稳定币条例》颁布，进入稳定币强监管时代，传统风控力不从心，如何利用 NebulaGraph 抢占风控主动权？

《稳定币条例》强监管，图技术如何抢占风控主动权？


> 导读：阿里妈妈团队基于 NebulaGraph 构建了百亿级实时营销推荐系统，赋能淘宝天猫精准营销。本文整理自宋铭涛老师在北京 nMeetUp 上的分享。


> 作者宋铭涛（承开），阿里妈妈广告技术部超融合数据架构工程师。


# 一、业务背景


## （一）阿里妈妈

**阿里妈妈**是阿里巴巴集团旗下商业数字营销平台，阿里妈妈依托淘宝、天猫等平台的用户数据和交易数据，为商家提供精准营销服务。例如，淘宝/天猫商家可通过阿里妈妈进行直通车推广、人群定向投放等操作。

**阿里妈妈营销引擎团队**专注于广告领域的研究与开发，利用淘宝内外的海量用户行为数据，致力于构建一个基于阿里大数据的支持广告主实时洞察投放策略、精准定位投放人群以及优化投放效果分析的交互式系统。

我们的合作伙伴众多，面临的业务场景复杂多变，技术挑战巨大。



## （二） 引入 NebulaGraph 的背景

到 2024 年末，经过与相关团队就特定问题场景的深入交流，我们意识到许多场景非常适合采用图数据库技术。此外，随着大规模模型 RAG 等需求的增长，对图数据的需求也日益增加。

因此，我们对 Neo4j、BlazeGraph、DGraph 和 NebulaGraph 等图数据库进行了测试与调研，最终选择了 NebulaGraph 作为解决方案：

* 在性能对比中，NebulaGraph 表现优异，超过了包括 Neo4j、DGraph 和 TuGraph 在内的图数据库。
* NebulaGraph 的架构设计允许存储和计算能力的横向扩展，这对我们复杂的使用场景尤为重要。
* NebulaGraph 拥有丰富的基础设施，便于参考整合，并支持二次开发。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/nebulagraph-overview.jpg)


# 二、应用场景


## （一）同款异常点检测

淘宝或者天猫的需求场景中，同款和相似款的应用场景很多，其中一个实现方式是，使用分类器对于同款商品集做分类提取，在算法理想 work 的情况下，同款商品簇内的两两商品直接互为同款。

但现实是：算法模型本身的运行设置、机器运算、数据问题等原因导致误差传递，进而使得本应该判断为同款的商品，得到置信度很低的值，成为异常点。


比如图中商品 2 和商品 4 在文本表述和图像上存在一定的区别，模型将两个商品判断为非同款，但是置信度不高，只有 0.5579. 而通过两个 SKU 本身信息和商品的邻接信息可知，这两个 SKU 应该是同款。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/alimama-use-nebulagraph.png)

在该场景下，我们使用 NebulaGraph 对相关数据进行建模，信息如下：

**Schema**

* 点（Vertex）：代表一个商品
* 点（Vertex）Tag：点的属性，可以包括商品多模态表征、图像表征等
* 边（Edge）：商品之间是否为同款，已经对应的 score，后续可以添加图像相似度等信息

**查询使用 k-hop 子图查询**

* 输入：待预测的 pair
* 输出：k-hop 子图（主要关注 1-hop 和 2-hop）和子图节点的 feature

通过引入 NebulaGraph 图数据结构,在同款离群点检测的已有成熟链路中，AB 实验结果提升了 2 个pt.


## （二）其它 case


我们也在用 NebulaGraph 做 GraphRAG 的相关工作，另外，风控算法团队也在用 NebulaGraph 进行黑产团伙识别、异常用户检测等。


# 三、服务架构

为了更好地借助 NebulaGraph 实现业务需求，基于我们的基建，我们搭建了以下服务架构。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/nebulagraph-based-in-alimama.png)

## （一）整体架构


分层的职责如下：

* **应用**：提供图的 SDK，业务方可以在业务服务中引入 SDK，实时地对图数据库进行业务操作。
* **存储**：基于 hippo (对应 K8S ) 的高可用服务物理集群和服务系统。
* **生产**：这里主要进行导入图相关数据的处理。图数据主要有两种来源，第一种是业务方把 odps 数据 etl 成转成点和边的表，然后离线导入到图数据库中；第二种是业务线上实时产生的数据、或者通过 Flink 等流式处理产生的近线数据，调用在线批量写接口实时灌到图数据库中。
* **支撑平台**：提供了 元数据管理、数据导入管理、监控报警、集群管理等依赖功能。


## （二）主要存储（NebulaGraph 集群如何灵活搭建）

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/alimama-storage.png)

不同的业务场景下，NebulaGraph 集群需要不同的规格和部署方式，如何灵活支持？

从 NebulaGraph 官方的信息中看到，NebulaGraph 生成集群运行需要以上进程，集群的灵活性取决于集群如何灵活组织编排上面的进程？需要确定哪些机器是 nebula-metad ，哪些是 nebula-graphd? 哪些 nebula-storage? 我们的环境机器都是 hippo(docker)拉起的机器。


## （三）集群管控系统

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/nebulagraph-manage.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/nabulagraph-manage-code.png)
为了解决以上问题，我们设计了一套集群管控系统。通过管控系统我们会为每个拉起的机器分配一个标识，这里使用数字 ID 标识，通过组织编排 ID 就可以灵活组建出来不同规格的机器，进而满足不同的诉求。


## （四）存储和计算节点分离

这些运行的集群都是 hippo 拉起的机器，中间调度系统都好几层。如何保存数据和恢复服务呢？

我们的架构利用中间件 ALILFS (类似开源的 JuiceFS) ，它将远端的 Pangu(阿里云存储高效的存储系统) ，以提供 Posix 接口挂载到拉起的机器上，这样已经挂载的机器可以像访问本地磁盘的方式一样访问远端的 Pangu 存储。

结合前面的集群管控系统，将每个 ID 的机器分配并绑定不同存储路径。hippo 拉起的机器即可自动加载属于自己的数据。

## （五）生产-数据 Bulk-load 方案

我们的场景下，数据量百亿级别，需要有一套高效的数据导入方案，通过对 NebulaGraph 和 NebulaGraph Exchange 模块的研究，结合我们公司的基建设计实现了一套基于 NebulaGraph 底层存储 SST 文件的导入系统。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/Bulk-load.png)


NebulaGraph 的底层数据结构使用 RocksDB 存储，数据编码格式如上，利用以上信息和对 NebulaGraph Exchange 的研究， 我们设计实现大批量数据导入方案是：利用离线 ODPS 资源构造图数据内部的二进制文件，之后利用图数据库的封装的 RocksDB 的 ingest 函数操作 load 构造的二进制文件，以实现批量大数据导入图数据库。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/Bulk-load-1.png)

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/Bulk-load-2.png)


为了简化操作，我们把 SST 文件生成封装成 UDTF，执行 SQL 就会触发文件生成， 并进行元数据和导入信息的设置，并发起导数任务进入 pipeline.
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-alimama/data-pipeline.png)


# 四、当前问题与解决办法

数据量巨大，导入时候，底层的 RocksDB 进行 compact，导致导入时间长尾严重，目前我们通过切分数据来减少 compact 的影响。

Bulk-load SST ingest 之后，大批量量数据导入，数据重建索引耗时和 mem 很大，通过分割数据、集群规格、配置动态调整解决。

# 五、未来规划

团队有对 RocksDB 和其他 KV 数据库的研究和魔改（二次开发），在未来的一些成果可以和 NebulaGraph 结合，提升服务能力，希望能以 PR 的方式贡献社区。

最后，如果您希望加入我们的团队，或者想与阿里妈妈建立合作关系，欢迎与我联系。

📮songmingtao.smt@taobao.com


阿里妈妈基于 NebulaGraph 构建了百亿级实时营销推荐系统，赋能淘宝天猫精准营销。

阿里妈妈百亿级营销实践｜NebulaGraph 赋能淘宝天猫精准营销

# 💡Why Attend?

在瞬息万变的金融市场，穿透式监管、实时风控、Crypto 合规、AI 驱动分析已成为机构的核心竞争力。面对海量数据与复杂关联，如何构建高效、低成本的技术栈？

参与本次香港线下 nMeetUp，**与 NebulaGraph 图数据库与 Doris 实时数据仓库的用户、核心研发，共同探讨金融科技前沿解决方案吧～**

In volatile financial landscape, penetration-based supervision, real-time risk control, crypto compliance, and AI-driven analytics are mission-critical capabilities. How can institutions build efficient, cost-effective tech stacks for massive data and complex relationships? 

Join our Hong Kong nMeetUp to explore cutting-edge FinTech solutions with industry experts from NebulaGraph (Graph Database) and Doris (Real-time Data Warehouse).

#  ⏰Agenda
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/HongKong-822/nebulagraph-agenda.jpg)

# 🎯Key Takeaways


## **🙋Master Penetration-Based Risk Control**

Learn to build billion-scale relationship networks with NebulaGraph for ultimate controller mining, related-party transaction detection, AML monitoring, and regulatory compliance.

**✨洞悉穿透式风控**

掌握用 NebulaGraph 构建亿级关系网络，实现实控人挖掘、关联交易识别、反洗钱监测，落实穿透式监管。

## **🙋Unlock Cost-Efficiency**

Discover how Apache Doris delivers 5x cost efficiency over Elasticsearch for financial-grade observability without performance trade-offs.

**✨解锁降本增效利器**

了解基于 Apache Doris 的金融级可观测方案，相比 Elasticsearch，如何带来 5 倍的成本效率提升。

## **🙋Future-Proof Crypto Risk Management**

Explore NebulaGraph’s innovative use cases in cryptocurrency fund tracing, address labels, and compliance (FATF/MiCA) to secure on-chain ecosystems.

 ✨掌握 Web3/Crypto 风控

探索 NebulaGraph 在加密货币资金追踪、地址标签分析、合规（FATF/MiCA）中的创新应用，构建链上风险防御网。 




## 🙋Power Next-Gen AI Applications


Get exclusive insights on how Apache Doris 4.0 enables AI workloads (e.g., vector search) to tackle data challenges in the AI era.

✨把握 AI 时代数据引擎

抢先了解 Apache Doris 4.0 如何赋能 AI 应用（如向量检索），应对智能时代的数据挑战。 


# Join Us Now
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/HongKong-822/registation.png)







NebulaGraph 图数据库与 Doris 实时数据仓库如何打造深度关联与实时分析下的金融新范式？

香港 nMeetUp 报名｜Web3 x金融风控×知识图谱

> **导读**
> 
> GraphRAG 如何选择图数据库？不同的 GraphRAG 实现方案有哪些优劣势？如何结合大模型与图数据库实现 GraphRAG 的完全国产化？别再让 AI “胡说八道”给答案了～从真实的企业级 GraphRAG 探索历程中，获取最精华的经验总结！
> 
> 作者张哲源，从事多年人工智能行业，目前在中科数睿从事大模型开发与应用。


本人是多个图数据库的认证专家，相对来说，评判会公正客观。本人不偏袒任何一个图数据库，所有观点代表个人在使用中的想法。

同时看完我们的完整探索过程也能理解：为什么我在 [NebulaGraph 北京 nMeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516965&idx=1&sn=7e7030ee6d437721e5b50f82009defa4&scene=21#wechat_redirect) 中，对 NebulaGraph 和 TuGraph 使用相同算法，却走了两条路径。

# **一、我所使用过的国产图数据库**

## NebulaGraph

分布式原生图数据库，强调“千亿节点、万亿边”水平扩展与毫秒级查询；自研 nGQL（兼容部分 Cypher 风格），支持属性图、索引、图算法组件；有企业版与云服务形态。

## HugeGraph

实现 Apache TinkerPop3 / Gremlin，支持多种后端存储（HBase、Cassandra、RocksDB 等）与多类索引，定位“分析型+快速关联查询”，支持与 Hadoop/Spark 集成及图算法库。

## TuGraph

面向高性能、分布式事务 \+ 图分析场景，应用于支付风控等业务；公开材料强调在多项国际基准中表现及万亿级业务实践锤炼。

## GES

面向百亿节点/千亿边规模实时多跳查询、风控/推荐/反欺诈等；提供可视化分析界面。

## KonisGraph

KonisGraph（TencentDB for KonisGraph）是一种云端图数据库服务，基于腾讯在海量图数据上的实践经验，提供一站式海量图数据存储、管理、实时查询、计算、可视化分析能力；KonisGraph 支持属性图模型和 TinkerPop Gremlin 查询语言，能够帮助用户快速完成对图数据的建模、查询和可视化分析。

# **二、不同 GraphRAG 方案的探索**

## 基于 NebulaGraph 的探索阶段

NebulaGraph 在 2023 年 8 月与 LlamaIndex 首次提出并实现 GraphRAG.

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

我们早在 2023 年年初就有业务痛点。

需要一个机制在确保权限边界与敏感最小暴露的前提下，快速回答“某监管条款在哪些现行合同条款体现并与竞品 X 定价/功能差异是什么”这类跨域多跳问题。

目标是：

-   提升合规核查与条款比对效率，减少误用过期条款或未授权资料；
    
-   支持监管→合同→内部政策→风险指标或竞品功能差异的可追溯路径；
    
-   对频繁修订保持低成本增量更新与“最新有效”识别；
    
-   通过最小必要敏感上下文与回答引用路径满足审计与风险控制。
    

我们尝试了早期的 RAG 方案、微调方案、提示词挂 RAG 通过召回不同提示词来检索不同知识块等。但都难以解决这个需求，一直被压着。

我们看到了 NebulaGraph 给出的 GraphRAG 方案后，做出了尝试。我们跑了几个简单的文档，发现了一些问题，但勉强可用。

-   如果出现本文档这类信息，那么很多文档都会被当作一个文档实体。
    
-   有概率出现中英文混杂。
    
-   丢失文档细节。 我们做了文档清洗、提示词工程、NER 模型训练等虽然缓解了原生框架的问题。
    

## 基于微软 GraphRAG 的探索阶段（想国产化实现）

2024 年 7 月， 微软公布开源代码 GraphRAG，由于之前我们改良了 GraphRAG，那么测试这个开源框架我们就有了明确的目标：

验证 Microsoft GraphRAG 的“实体/关系抽取 + 社区聚类 + 层级摘要 +Local/Global 双检索”在 全局综述类问题（宏观趋势、风险主题汇总、合同修订焦点）与跨文档主题归纳上，相比现有自研 NebulaGraph GraphRAG（偏 fine‑grained clause / entity 精准定位）是否带来：

-   全局主题覆盖增益；
    
-   引用多样性提升；
    
-   可解释聚合摘要能力；
    
-   同时评估成本、延迟与权限/敏感改造可行性。
    

我们采用了与 NebulaGraph 几乎一样的预处理方案，但有几个问题：

-   构建与查询成本（指时间成本相对于原方案高了20%，但精度确实提高了不少）
    
-   增量更新与重建代价（早期缺乏高效增量 → 后续版本提供但仍需复杂逻辑）
    
-   全局模式的 Token 膨胀与 Prompt 长度风险
    
-   实体 / 社区质量与稳定性（聚类与摘要噪声扩散）
    
-   幻觉与摘要偏差（仍依赖 LLM 生成，新增风险向量）
    

我们也尝试了更换图数据库（这里指国产的几大图数据库，但没有 Tugraph，因为我当时还不知道这个图数据库）、更换模型（qwen、glm 等国产模型）但并没有实际上的提升。

## 基于 DB-GPT 的 GraphRAG 探索

随后，我们注意到了蚂蚁开源的 GraphRAG 同时也第一次接触到了 TuGraph.

-   尽管 DB-GPT 已相对优化微软 GraphRAG 的 token 与延迟，社区摘要 / Global 查询仍包含多轮 LLM 生成与汇总：当查询是“精确定位 / 简答 / 条款或字段点查 / 结构化参数问答”时，走社区全局合并会引入不必要成本与延迟；
    
-   在我们所处的金融 / 合同 / 竞品场景里，大量日常问题（例如“条款 7.3 的违约责任是什么？”、“竞品 A 的实时告警支持延迟阈值？”）需要的是高精度局部片段 + 少量相邻上下文，原生框架并不支持这些，而且也只对 TuGraph做了支持。想改进起来，开发成本可能有点高，而且上述问题也未必可以缓解。
    

## KAG 的探索

2024 年 10 月，我们又注意到了新星 KAG.我们在浏览技术论坛时看到：

-   纯向量 RAG 容易受限于“语义相似 ≠ 知识推理相关性”，对数值、时间、规则、逻辑链条敏感度不足；
    
-   GraphRAG 通过图 + 摘要改善跨文档综合与主题覆盖，但其基于抽取的社区摘要仍可能受噪声与逻辑形式缺失影响；
    
-   因此 KAG 旨在让 LLM 与知识图双向增强，显式支持多跳逻辑、结构约束与可验证推理路径，以提升专业领域（政务、医疗等）问答的专业性与可解释性。
    

于是，我们尝试了新的方法 KAG. 我看完多个技术文章以及论文，为了方便理解我简单说一下 RAG 到 KAG 的进阶：

-   RAG 核心是检索相关片段 → 拼接上下文 → 生成，优点是可更新、降低幻觉但对逻辑链条与结构化约束弱；
    
-   GraphRAG（微软） 在 RAG 之上加入 LLM 生成知识图 + 社区发现与多级摘要，强化全局主题探索与长文档信息组织；
    
-   KAG 则进一步把逻辑形式（类似“查询计划”）与双向互索引引入推理流程，强调结构与文本之间的往返映射、可验证推理路径与多种算子融合，以减小“相似但不推理相关”与摘要层噪声对结果的影响。
    

但是，KAG 仍需：

-   高质量、领域覆盖充分的知识建模（图谱与逻辑形式）与互索引维护;
    
-   对多样化复杂知识的抽取与建模精度;
    
-   合理的逻辑规划与算子库扩展（否则会退化成普通 RAG）；
    
-   额外构建与调度成本权衡（在简单 FAQ / 单跳问答上可能不如轻量 RAG）
    

# **三、GraphRAG 的完全国产化**

## DeepSeek 之前

由于尝试了各类开源框架并未解决我们的问题，我们走了站在巨人肩膀的道路。同时在走自己的路的同时，也没有忘记看看新的技术。比如 DB-GPT 的 0.72 我们也做了尝试和调研。

最初我们的想法是融合 RAG+GraphRAG 技术。GraphRAG 相对微软的我把实体的描述信息、实体长度>50字符的信息、摘要大于 200 字符拆分后放到 RAG, 最后把两边的信息拼接起来做个文本摘要当作已知信息，与用户的问题拼接后当作 input 给大模型，最后生成答案。但实际的效果在 3K 的样本中并没有超越其他技术方案。

经过这次的实验我想，有 NL2SQL 为什么不尝试 NL2Cypher 呢？这样是不是可以一定程度上让大模型自己找到需要的实体关系从而避免生成一些无关摘要以及减少提示词的长度呢？

同时社区算法我们只要社区不要摘要，总结让模型自己完成。例如，将“芒果”、“香蕉”、“菠萝”直接归类于“水果”社区。当处理全局查询（如“水果有哪些？”）时，只需从“水果”社区向下遍历其子成员即可获得结果。

经过这次的调整，我们也仅仅减少了构建和检索时间，精度没有提升，反而丢失了很多信息。同时，发现模型居然有些数字进入图谱中是错的。不自己看将难以发现。同时，所有的国产图数据库都不完全兼容 Neo4j 的语法，而很多大模型的语句都是生成的 Neo4j 可以运行的语句，可能还要额外的微调。

## DeepSeek 之后

在这个时候，DeepSeekR1 横空出世。我们初步评测后发现，DeepSeek 在知识抽取以及 Cyper 生成上可以进行诱导。于是乎，我们采取了两个技术并行的思路。

微调 DeepSeek 并让他生成占位符，同时根据问题复杂度控制思考长度。

尝试 MySQL 进行数值存储以增加数值信息的查询，以及修改解决新发现的模型生成错误数字的问题。

这个是我们微调的结果，并且可以在 ollama上、vllm 等框架上运行。也生成了占位符。当然目前微调效果最好的是 NebulaGraph （支持的语句可能更多还是其他原因，我们暂时没有发现，但是我们模型生成的语句成功执行的概率大于其他数据库），但是从多图检索的效果上看却是 TuGraph 更快。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-zhongkeshurui/GraphRAG-code-1.webp)

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-zhongkeshurui/GraphRAG-code-2.webp)

因此我们出于成本的考虑我们采用了 NebulaGraph+TuGraph 两种方案并行的路线，但是并不代表其他图数据库不行，可能随着数据量增大确实效果会好转，但我们的人力物力不支持我们同时跑这么多图数据库。

## 结合 MCP+客户反馈

在经过公司内部的研究、MCP 的出现以及我们卖给产品的客户反馈，因此微调方案变更为了：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-zhongkeshurui/how-to-build-GraphRAG.webp)

同时，也明确了：

-   充分发挥各数据库优势。NebulaGraph 走微调的道路，TuGraph 图谱管理上下文信息（含可能用到的语句）、其他数据库后续开发（客户可能有偏好，同时我们发现其他的数据库随着数据量的增多确实有所提升）
    
-   放弃图社区改用子图融合和类别下钻的方式合并查找类别信息（类似上文提到的水果的列子）
    

## 核心流程

系统把原始文本按块流式送入大模型抽取三元组 → 迭代补全与指代消解 → 图/指标分层落库 → 查询时按问题复杂度选择图 / 向量 / API → 用占位符生成草稿 → 并行回填得到可解释答案，从而降低幻觉并保证数值与结构准确。

注意：NebulaGraph 要进行微调，TuGraph 要设计图谱管理上下文信息。

# **四、实现方法拆解**

## 离线 / 在线一体的流式解析阶段

-   文本分块 & 第一轮抽取：固定大小的文本块进入 LLM，输出等长数组组成 (实体1, 关系, 实体2) 三元组，实现初始结构化抽取（输入：原始分块；输出：三元组数组）。
    
-   不完整句检测：检测块尾是否截断或含代词，若是则把最近 k 个三元组与后续文本拼接以形成更完整上下文（缓解切分导致的语义断裂）。
    
-   第二轮解析（补充上下文）：在扩展后的上下文里执行指代消解与再抽取，对第一次结果去重与合并，提高实体、关系完整度与正确归属。
    
-   流式循环：写库后立即清空暂存数组、复位索引，继续下一个文本块，实现准实时的解析流水线（降低峰值内存）。
    

## 分层存储与数据治理

-   结构性的实体节点、关系、维度属性写入图数据库；
    
-   易变 / 指标类数值落到 MySQL，解决“指标集中修改困难”问题（图保持关系语义，数值在行存中灵活更新）。
    

## 查询时动态检索与规划

动态检索：用户提问进入 LLM 前置分析“复杂度 / 类型”，在图数据库中探测相关实体是否存在，进而决定调用：仅图查询、图 + 向量补充、或外部函数 / API（多通道检索策略）等。

## 占位符生成与并行回填

-   占位符输出：模型在推理草稿里用 §GRAPH§ / §FUNC§ / §MYSQL§ 等标记尚未获取的真实结果，避免臆测并把 I/O 与生成并行化。
    
-   回填呈现：前端或中间层并行执行实际查询（图遍历、SQL、外部接口），按占位符映射替换，得到最终答案及其来源，提升可解释与数值准确率
    
-   备注：因为执行查询程序就能判断是否正确，如果错误，开个 subtask（本身整个程序也有个监工 AI）重新生成。因此，占位符生成错误这一问题可很大程度缓解。
    

# **五、大模型与 NebulaGraph 结合的知识库**

## 效果展示

我们的思考过程：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-zhongkeshurui/NebulaGraph-RAG-1.webp)

我们的回答：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-zhongkeshurui/NebulaGraph-RAG-2.webp)

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/use-case-zhongkeshurui/NebulaGraph-RAG-3.webp)

## 优劣势及未来展望

-   优势：减少幻觉（仅回答已存在实体 \+ 占位符后填）、检索并行加速、图多跳增强复杂推理、指标准确率接近 100%、模块解耦可独立迭代。
    
-   局限：趋势 / 创意生成受限（因偏结构填充）、长篇连续指代有内存与上下文风险、前期微调 & 建库成本高、运维面（LLM + NebulaGraph + MySQL）复杂、占位符流程需要精细脱敏与权限控制。
    
-   未来：支持其他图数据库，优化方案解决上下文风险以及趋势分析问题。
    


GraphRAG 如何选择图数据库？不同的 GraphRAG 实现方案有哪些优劣势？如何结合大模型与图数据库实现 GraphRAG 的完全国产化？

中科数睿的实践：如何落地 GraphRAG 国产化？

**2025 年 8 月 1 日，中国香港《稳定币条例》即将正式生效，这是全球首个针对法定稳定币的全面监管框架**。新规要求发行机构实施与传统金融同等级的 KYC/AML 流程，对单笔超 10万港元交易执行强化尽调，并确保储备资产 100% 隔离存放。

国际清算银行（BIS）近期报告则警示：稳定币的跨境伪匿名特性正加剧洗钱风险，传统风控体系面临失效危机。

**在这场政策收紧风暴中，发行机构面临的核心矛盾已浮出水面：**

政策要求发行机构必须实现资产挂钩透明化 、跨境交易可追溯 、用户身份穿透式管理 ，但传统风控体系对复杂关系网络的识别能力已接近极限。




# 一、传统风控失效
## 身份关联的复杂性成为首要难题

香港条例强制要求用户身份与链上地址绑定，但某跨境洗钱案中，单个犯罪者操控超过 200 个钱包地址分散资金。传统系统依赖静态规则和简单关联分析，无法动态识别此类集群化行为。


## 跨境资金追踪的滞后性进一步放大风险

稳定币通过跨链桥实现多链资产转移，资金路径被切割成碎片化轨迹。BIS 数据显示，43% 的洗钱交易因风控响应延迟得逞，而美国法案要求的 10 分钟冻结时限，对传统小时级扫描的系统构成严峻挑战。


## 系统性风险的传导失控更值得警惕

中国香港的条例赋予用户对发行方储备资产的优先索赔权，一旦某稳定币出现挤兑，其托管银行可能因连带责任陷入流动性危机。当前风控系统缺乏对“发行方-银行-债权人”网状关系的动态模拟能力，无法预判风险传染路径。

# 二、NebulaGraph 的风控解决方案

面对上述挑战，NebulaGraph 正成为头部发行机构的核心选择。其技术价值已在生产环境中得到验证：

## 动态图谱：实时更新全景数据，应对跨境监管压力

稳定币的跨链特性导致资金路径碎片化，传统风控系统因数据割裂无法快速串联完整轨迹。

NebulaGraph 通过多链交易关联图谱技术 ，将不同公链（如比特币、以太坊、Solana）上的地址、时间戳和金额统一建模，形成全景资金流向视图。可毫秒级更新地址关联网络，捕捉犯罪者频繁切换钱包的动态行为。

> 某跨境支付平台通过最短路径分析，秒级串联一笔稳定币从 TRON 链到 ETH 链的完整转移路径，并实时评估风险等级。这种动态图谱能力还支持一键生成符合多国监管要求的证据链，大幅缩短合规响应时间。

## 图计算：穿透复杂关系网络，精准识别隐藏风险

稳定币发行机构面临的核心挑战之一是用户身份与链上地址的深度关联 。传统风控依赖静态规则（如黑名单匹配）或简单关联分析，难以应对犯罪者操控数百个地址分散资金的“集群化”攻击。

NebulaGraph 通过图计算，将用户身份、链上地址、设备指纹、交易时间戳等多维度数据构建成动态演进的关系网络 ，利用社区发现算法自动识别隐藏的资金池。

> 在某跨境洗钱案中，系统通过分析 200+ 地址的交易模式，发现其资金流转路径与正常用户显著偏离，毫秒级锁定幕后控制者。此外，图计算还可模拟“发行方-银行-债权人”的网状依赖关系，预测稳定币挤兑引发的流动性危机传导路径，为机构提供风险传染的预警模型。

## 实时图特征：高并发下的毫秒级响应，守护系统性安全

在高负载场景下，稳定币发行机构需应对突发流量洪峰，如市场剧烈波动时的交易激增，同时满足监管对实时风险拦截的要求。传统数据库在每秒数千次的复杂关联查询时便可能出现延迟，而 NebulaGraph 已在实战中验证其万亿级实时关联分析能力。

NebulaGraph 基于分布式架构，支持每秒数万次高并发查询，即使面对极端场景仍能稳定输出毫秒级响应。这种实时能力不仅满足监管时效要求，更可主动拦截洗钱、挤兑等系统性风险，守护机构稳健运营。


# 三、结语

中国香港《稳定币条例》生效仅剩15天——合规能力正从成本项转化为生存资格证。稳定币监管收紧只是开始，未来政策将进一步向 DeFi 协议 、NFT 金融化等领域延伸。

当传统金融机构仍在链上数据整合中挣扎时，先行者已借 NebulaGraph 建立起风控护城河。

**越早构建“关系认知”，越能在政策变局中掌握主动权！**


# NebulaGraph 直播

**扫码预约 NebulaGraph 直播：图技术如何抢占稳定币风控主动权？**
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/stablecoin-risk-control.jpg)

技术科普｜稳定币监管全面升级，发行机构如何应对风控新挑战？

作者万佳飞，SRE 工程师，AIOps 经验丰富，擅长根因定位，目前在做 AI Agent 提效，本文源万佳飞老师在北京 [nMeetUp](https://mp.weixin.qq.com/s/USGhoEzn2dD8zti5pnWaCA) 上的分享。

> 导读：在数字化服务日益成为业务核心竞争力的今天，系统的稳定性直接关乎用户体验与企业声誉。BOSS 直聘选择以 NebulaGraph 高性能分布式图数据库为核心，构建了创新的异常调用分析与根因定位平台，实现了运维效率与稳定性的质的飞跃。



# 一、业务背景
BOSS 直聘成立于 2014 年，是目前国内平均月度活跃用户数最多的在线招聘平台。BOSS 直聘率先引入了一种改变中国在线招聘业的颠覆性模式—直聘模式：求职者与招聘者通过平台进行即时沟通，成为求职者使用频率最高的求职 App.
然而面对百万级日活和复杂的业务架构，继续沿用**传统运维模式暴露出一系列尖锐问题：**
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/boss-zhipin-%20problem.webp)
- **视角割裂，难以快速定位**：监控指标、日志、调用链追踪、事件数据分散在不同系统，缺乏统一关联视角。服务调用链不清晰，尤其在跨团队、跨技术栈的场景下，排查如同“盲人摸象”。
- **定位路径无体系，“故障靠人扛”**：故障排查高度依赖专家个人经验，缺乏标准化流程和自动化手段。异常告警无法有效聚合到业务视角或真正的技术根因层面（如网络设备故障、特定服务瓶颈），导致“轮番接锅”、责任认定不清。
- **工具繁多，效率低下**：运维人员需要在多个工具间切换，使用门槛高，信息整合成本巨大，难以在紧迫的故障恢复时间内形成有效决策。

这些问题最终体现为**平均故障修复时间（MTTR）居高不下**，不仅影响用户体验，也严重消耗了宝贵的研发运维资源，阻碍了业务稳定性建设的持续提升。

# 二、以图数据库为核心的技术选型
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/boss-zhipin-problem-2.webp)
面对挑战，BOSS 直聘的运维团队认识到，解决问题的**关键在于打破数据孤岛，构建清晰、动态的服务与资源全景依赖图谱，并基于图谱实现智能化的异常传播分析与根因定位。**

在技术选型上，团队重点考量了：
- **海量关系处理能力**：需要存储和处理数以亿计的服务、实例、主机、中间件节点及其间复杂的调用、部署、依赖关系；
- **实时查询性能**：故障发生时，需要毫秒级响应复杂图查询（如路径查找、邻居遍历、子图匹配），快速定界定位；
- **灵活的数据建模**：业务架构和技术栈持续演进，图谱模型需要灵活适应变化；
- **分布式与高可用**：支撑核心运维场景，必须具备极高的可用性和水平扩展能力。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/Neo4j-vs-NebulaGraph.webp)

**经过 Neo4j 和 NebulaGraph 的深入选型对比，我们发现 NebulaGraph 在各方面都更加契合 BOSS 直聘实现智能根因定位的业务需求。**

# 三、基于 NebulaGraph 的根因定位
在完成技术选型后，BOSS 直聘围绕“**如何将复杂故障问题转化为结构化图问题**”，构建了一整套基于 NebulaGraph 的根因定位机制，涵盖建模、采集、计算与展示四大核心环节。
## （一）多维度依赖建模：从业务全景到物理实体
为实现精准、全面的故障识别与定界，团队基于实际架构将图谱建模划分为多个层级：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/graph-database-modeling-1.webp)
- **水平层建模**：定义服务之间的调用关系，如应用之间通过 HTTP、RPC、SQL 等协议产生的调用链；
- **垂直层建模**：连接应用与底层基础设施，如 VM、数据库、中间件、网关等，构建完整的依赖路径；
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/graph-database-modeling-2.webp)
- **根因维度建模**：抽象各种可能的根因来源（如发布变更、配置错误、资源瓶颈、硬件故障等）并纳入图中表示，构建“可归因”的根因节点；
- **时序建模能力**：通过 NebulaGraph 的多版本边（TimeRank）机制，存储调用随时间变化的性能指标，支持时序回溯与根因溯源。

## （二）数据采集与图数据构建
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/graph-database-storage.webp)
在数据获取方面，系统打通了多个运维关键数据源，包括：
* **Trace/Span**：服务调用链追踪信息；
* **Metric**：来自 Prometheus、JVM 等的性能指标；
* **Log/Event**：日志与告警事件；
* **Infra 信息**：主机、容器、中间件资源状态。
上述数据通过 Kafka 采集后进入图构建流程，经过统一的属性富化、聚合与点边建模，最终转化为包含属性和时间的 NebulaGraph 图谱结构。构建过程中，节点间的边不仅记录了“谁调用谁”，还嵌入了延迟、错误率等指标数据。

## （三）图计算驱动的故障定位
有了清晰的图谱模型，BOSS 直聘在 NebulaGraph 上实现了一套图计算驱动的根因分析流程：
* **定界计算**：从异常告警出发，计算最短路径、上游影响范围，快速圈定可能根因范围；
* **传播链追溯**：通过图遍历与路径匹配，还原从根因节点出发的“影响路径”；
* **根因打分与排序**：根据故障发生频率、上下游影响度、关联指标异常程度，对候选根因进行打分，聚焦“最可能”原因；
* **影响链可视化**：系统自动生成“根因 → 主机/中间件 → 应用服务 → 用户影响”的完整链路，用图形方式呈现给值班工程师，辅助快速止损。

采用 **PageRank 算法**动态计算节点故障权重：

**1. 数据融合**

整合链路追踪、系统指标、日志三大数据源，构建统一的全链路异常拓扑图，发现多个真子图分散出现在图结构中，每个子图都有“风暴中心”。

**2. 图算法驱动定位**

采用 PageRank 算法动态计算节点故障权重：

* 计算：Rank 值由节点出入度、链路错误数、事件进行加权计算
* 输出：Rank 值最高的 TopN 故障节点（即 “风景眼”）

**3. 关联分析**

通过图关系划分关联队列（直接故障节点）与非关联队列（间接影响节点），精准缩小排查范围。

**应用示例**
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/nebulagraph-gain-in-boss-zhipin.webp)
- 根因：该图描述了由于网络设备 A 端口故障，影响了主机，进而影响了应用 auth-service.
- 影响：进而链式传递影响了数个应用，风暴眼位 auth-service. 根因位网络设备 A.

## （四）联动触发与治理闭环
该图谱系统还被用于联动故障止损与恢复流程：
* 告警触发后，自动调用根因图分析，聚焦故障“发源地”；
* 同步通知责任团队或通过自愈策略（如摘流、重启、降级）实现自动化止损；
* 故障恢复后自动记录事件链路，作为后续 SLO 回溯与稳定性分析的依据。

# 四、运维效能的全面提升
NebulaGraph 驱动的根因定位为 BOSS 直聘的稳定性保障带来了显著收益，严格遵循了故障响应（发现->处理->恢复）三阶段优化目标，核心体现在 MTTR 的大幅缩短：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/nebulagraph-gain-in-boss-zhiping.webp)

# 五、未来迈向智能运维（AIOps）
BOSS 直聘的 NebulaGraph 实践已取得显著成功，但探索并未止步，团队着眼于更智能化的未来：
* **数据建模增强**：覆盖更全面、更细节的建模数据。并预计算与存储，构造高质量建模；
* **Data Agent**：专门分析关联形数据结构的 AI 助手，从关联形数据中提取重点；
* **根因定位 Agent**：从海量的日志、监控等中挖掘目前无法发现的根因。

BOSS 直聘基于 NebulaGraph 构建的异常调用根因定位平台，是图数据库技术在现代复杂 IT 运维场景中成功落地的典范。NebulaGraph **有效解决了传统运维故障定位难、定界慢、协作乱的痛点，实现了 MTTR 的显著优化，为业务稳定性构筑了坚实屏障**。期待随着持续深化 Graph+AI 应用，BOSS 直聘的智能运维之路越走越宽广。

BOSS 直聘选择以 NebulaGraph 高性能分布式图数据库为核心，构建了创新的异常调用分析与根因定位平台，实现了运维效率与稳定性的质的飞跃。

20 秒根因定位:BOSS 直聘基于 NebulaGraph 构建智能运维


> 导读： 面对日均数万人参与、月均百万级 Excel 处理、百万工时消耗的“做数”困境，以及复杂的数据权限与血缘关系挑战， **NebulaGraph 图数据库落地其智能化大数据分析平台 UData 后**，**实现了查询延迟降低 30%，整体查询性能提升 5 倍，权限校验响应时间 <100ms 等显著成效**。作者李世豪，京东物流 UData 数据开发工程师，本文源李世豪老师在北京 nMeetUp 上的分享。


# 一、业务背景

京东集团 2007 年开始自建物流，2017 年正式成立京东物流集团，2021 年 5 月，京东物流于香港联交所主板上市。目前，京东物流主要聚焦于快消、服装、家电家具、3C、汽车、生鲜等六大行业，为客户提供一体化供应链解决方案和物流服务。

## （一）业务痛点

作为中国领先的供应链解决方案提供商，京东物流每天需要处理海量、多源、异构的业务数据：数据运营岗从线上、线下系统手动下载各类繁杂数据，通过 Excel 进行拼接、透视分析和公式计算，最后将结果保存至本地并线下分享。
* **日均做数人数超过数万人**，相当于一个大型工厂的全体员工都在手动处理数据，每天约有 10 万名一线业务人员需要频繁查看数据。
* **Excel 月处理量达百万级**，这意味着我们每个月要手动操作数百万次表格；  
* **做数总耗时高达百万小时/月**，相当于数百人全年无休。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/JD-business-background.jpg)

在百万级数据规模下，我们遇到了几大核心挑战：

* **数据来源多，做数成本高**：业务系统分散，数据标准不统一，导致“数据孤岛”现象严重。 例如：“时效分析”需要关联 TMS 系统、分拣报表、终端配送数据，但各系统口径不一致，人工对齐耗时巨大。
* **数据需求多且变化快，上下协同难**：分析需求涵盖时间（年/月/日）、环节（仓储/分拣/配送）、产品（快递/快运）、组织（集团/省区/场地）等多个维度，目前每天有几万个提数任务，几万张不同的数据看板，同时新需求上线往往需要多方配合，无法快速响应业务变化。
* **数据安全难以保障**：Excel 文件在线下传播带来了数据泄露风险。


## （二）UData 一站式数据分析平台

面对以上问题，我们亟须找到一种更高效、更灵活的数据管理和数据处理方案：京东物流搭建了 UData——一款一站式、自助式的数据分析平台。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/JD-UData.jpg)

UData 实现了百万级数据的自助取数，支持实时数据监控与交互式分析，可随时查看 KPI 达成情况、工单单量变化，还能通过数据地图直观呈现业务分布。

# 二、Why NebulaGraph？

在涉及海量高度互联数据的获取、处理及访问控制场景中，传统关系型数据库在复杂关系建模与查询效率方面存在显著瓶颈，而基于原生图存储结构及高效遍历能力的图数据库技术则展现出显著优势。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/JD-why-choose-NebulaGraph.jpg)

我们最终选择了 NebulaGraph 建设 UData.

## （一）天然适配复杂关系

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/JD-why-choose-NebulaGraph-2.jpg)

NebulaGraph 图数据库**以“点-边”结构直接映射数据血缘和权限的网状关系**。

## （二）高效的查询语句

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/JD-why-choose-NebulaGraph-3.jpg)

**MySQL 通过五六十行的 SQL 进行查询，但 nGQL 只需短短几行，极大提升了代码的可维护性，代码量降低 80%，性能提升 10 倍**。

## （三）活跃的开源社区

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/NebulaGraph-community.png)

NebulaGraph 作为国内最大最活跃的图数据库开源社区，拥有来自各行各业的图数据库开发者，许多技术问题能在论坛得到快速响应。

# 三、实践案例

## （一）性能优化

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/NebulaGraph-in-JD.png)

将用户点选配置或者 SQL 解析为图结构，建立基于表的血缘关系，寻找热表或者重点保障的表，进行替换，提高查询效率，复杂血缘分析任务从分钟级降至秒级，**整体查询时长降低 30 %**。


## （二）稳定性提升

缓存和路由是我们度过 618 和双 11 大促的重要手段，在这两个功能上，NebulaGraph 也给我们带来了很大的稳定性提升。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/NebulaGraph-in-JD-2.png)

* **缓存方面**，针对报表的历史访问记录，生成报表的特征，以 15 分钟为一个周期，获取历史 7 天的访问数据，生成时序图，通过时序图学习算法进行预测，判断下个区间内，对应的报表是否会有访问，提前对报表数据进行缓存，大大减少了系统繁忙时的压力，**目前系统的缓存可以覆盖 75% 以上的报表查询和访问**。

* **集群路由方面**，依赖图计算方法，获取每个节点（报表）对于集群的压力，新增时寻找相似的节点判断该得分，通过得分生成不同的策略，保障查询集群的稳定性。此外，我们还会通过血缘分析报表的组成，以达到分配到最优集群进行查询的目的。


# 四、未来规划

NebulaGraph 的应用只是起点，我们计划在以下方向持续探索：
* **智能数据治理**：结合图算法识别数据资产中的特定结构（如循环依赖），自动优化数据链路。
* **GraphRAG**：用于智能客服和报表生成，通过图结构理解业务语义，提升问答准确率。
* **实时检索优化**：探索图与向量数据库的结合，实现“数据+知识”的混合检索。 溯源到业务平台，构建物流数据分析知识图谱

京东物流通过 NebulaGraph 图数据库赋能 UData 平台，有效破解了百万级 Excel 手工处理困境。**通过“点-边”结构高效映射复杂数据关系，简洁高效的 nGQL 等图技术，实现查询延迟降低 30%、性能提升 5 倍、权限响应 <100ms 的突破性成果**。未来，智能数据治理与 GraphRAG 等图技术深化应用，将持续推动物流数据向实时化、智能化演进，为 618、双 11 等互联网大促注入新动能。
 

NebulaGraph 图数据库落地其智能化大数据分析平台 UData 后，实现了查询延迟降低 30%，整体查询性能提升 5 倍，权限校验响应时间 <100ms 等显著成效。