在招聘市场中，海量的实体（职位、求职者、技能、公司）之间充斥着天然多元的动态关系。传统基于关键词和规则的系统难以深度建模这些关联，而图数据库通过直观的点-边结构，不仅能映射现实世界的复杂关系，更能挖掘深层洞察，并赋予算法模型宝贵的可解释性。

本文将介绍 NebulaGraph 在某海外知名招聘网站的典型应用场景：如何通过分类学图谱与综合关系图谱，驱动招聘平台走向智能化。

# 一、传统招聘推荐模式

你是否曾在求职网站上，感觉推荐的职位总是差那么点意思？

![|472x456](https://pica.zhimg.com/80/v2-0047cecd1dc651889ecd8ee47915eab1_1440w.png?source=ccfced1a)

或者，作为招聘方，面对海量简历，却很难快速找到那个“对的人”？

![|526x448](https://pic1.zhimg.com/80/v2-da83d67fe904f09b77c532ef25473546_1440w.png?source=ccfced1a)


问题在于传统招聘平台大多依赖关键词匹配。你写「会 Oracle」，系统就推送所有带了「Oracle」的职位。例如：

* 一位 DBA 的技能是「Oracle Database」

* 一家咨询公司的职位是「Oracle （甲骨文）ERP 实施顾问」。

* 一个简单的关键词系统可能会因为「Oracle」这个词，把 ERP 顾问的职位推给 DBA.

更重要的是，它看不到关系。

比如会 Java 的人往往也熟悉 Spring 框架，有电商经验的人可能对支付系统更了解。软件工程师和数据科学家可能都需要掌握机器学习领域的知识。

这些数据背后的关联，传统技术难以捕捉。

而在图数据库的图谱中，Oracle 数据库和 Oracle 公司（及其 ERP 产品）是两个不同的实体节点，属于不同分类子树（数据库软件 vs. 软件公司/产品），因此不会造成误匹配。

# 二、基于图的招聘推荐

## （一）分类学图谱

1. 什么是分类学图谱？

分类学图谱是对术语进行层次化组织的一种知识体系，在招聘市场中，可以将其理解为招聘领域的结构化知识库。

某海外知名招聘网站将众多招聘要素纳入分类学图谱体系，例如技能、福利、职位类别等，形成树状或更复杂的图结构。

再将所有分类学数据整合为图：节点包括属性、职位等，边表示其关联关系，并存储于 NebulaGraph 中。

就如网购时通过分类筛选商品一样，先将职位类别组织成树状结构（例如技术研发职位分层体系，进一步细分为前端开发、后端开发、移动端开发等子类），并将它们进一步构建为图。

同时，属性节点如技能、专业认证、福利标签等也被整合进来。

例如「Java 技能」作为一种编程语言技能，在不同地区或行业的职位描述中可能有不同表述，通过唯一标识符将其归一化，并与相关的职位、课程、认证建立关联。又如，在某些行业，会特别要求持有某项专业认证，图谱可自然地建立岗位与认证之间的要求关系。

2. 技术实现与应用场景

智能搜索与导航： 我们访问招聘网站主页搜索职位时，基本都会在结果页顶部看到一些动态筛选条件。这些筛选条件和搜索时的自动补全功能都是通过分类学图实现的。例如，搜索「Java」，系统基于图谱，同时推荐要求「Spring Framework」或「JVM」的职位，因为它们处于同一紧密关联的子图中。动态筛选条件（如相关技能、必备认证）也能实时从图谱中生成与聚合。

数据标准化与理解：平台能自动将用户输入的多样化技能表述（如精通 PS、Adobe Photoshop 技能）映射到标准化的技能节点，为后续的精准匹配奠定基础。

结构化流程引导：在求职者填写信息或申请职位时，系统可基于职位所需的知识图谱路径，引导其逐步输入标准化的技能、认证信息，极大提升数据的质量和可用性。

## （二）综合关系图谱

1. 什么是综合关系图谱？

如果说分类学图谱是静态字典，那么综合关系图谱就是实时变化的故事线。它将用户行为数据（点击、申请、搜索）与实体知识图谱融合，形成一个动态的、全局的异构信息网络。

一个示意性案例如下：

左侧部分包括一些技能和分类。顶部的「软件开发」是一个职业类别，其子类包括「前端开发」等。

一个具体的职位可能要求掌握 JavaScript 技能 与 React 等主流框架，有 NebulaGraph 等图数据库项目经验，硕士学位，薪资范围在 20k-30k 左右，并提供某些福利。

> 💡如 NebulaGraph，不论工作年限，入职即享 12 天年假～！

某位求职者可能申请了这个职位，而这位求职者可能拥有在 Neo4j 等公司的工作经验。公司节点也可能包含一些属性，如多元化程度或规模大小。

此外，职位可能由某一招聘方发布，该公司本身也具有一些属性。这些信息都能用 NebulaGraph 直观地表示出来。

2. 从关系到洞察

这张动态图谱的价值，需要通过图算法与图神经网络来深度挖掘。

图嵌入学习：通过 GNN 等技术，系统可以为每一个求职者、职位、公司节点学习一个低维的向量表示。这个向量综合编码了其属性、关联实体与行为历史，是深度智能匹配的基石。

智能推荐与匹配：计算职位向量与求职者向量的相似度，能实现远超关键词匹配的精准推荐。例如，即使某求职者未明确列出「高可用架构」经验，但其职业轨迹和技能组合与大量该领域的资深人士高度相似，系统也可将其推荐给相关高端职位。

复杂模式挖掘：图数据库擅长执行多跳查询与路径分析。招聘方可以提问：“过去三年，成功入职我司核心研发岗位的人才，最常见的职业发展路径是什么？” 系统能迅速在图谱中遍历并找出共性模式（例如：常毕业于特定院校群 -> 在特定类型公司有3-4年核心项目的研发经验 -> 掌握某几项核心技能的复合组合）。

> （对推荐场景感兴趣的小伙伴，可查看以下案例）

[![](https://picx.zhimg.com/80/v2-ef97b3e5af5c68569f69d6f0af65619f_1440w.jpg?source=ccfced1a)](https://www.nebula-graph.com.cn/posts/zhilian-graph-database-%20practice)

[![](https://pic1.zhimg.com/80/v2-b49234f8a530acd69834f1a81d2c47cb_1440w.jpg?source=ccfced1a)](https://www.nebula-graph.com.cn/posts/use-case-alimama)


# 三、总结

图数据库的引入，使得招聘推荐系统，从传统机器学习的黑盒模型转向了可视化洞察，通过图结构，我们可以清晰展示结果是如何生成的，两个节点为何相互关联，从而提供直观的解释。

总而言之，图数据库通过将分类学知识与实时行为数据编织成一张多维互联的智能网络，为招聘市场构建了深度理解、精准匹配与可解释推荐的新一代基础设施。


NebulaGraph 在某海外知名招聘网站的典型应用场景：如何通过分类学图谱与综合关系图谱，驱动招聘平台走向智能化。

海外招聘网站案例｜用图数据库重新定义招聘推荐

2025 年，你和 NebulaGraph 一起肝了哪些项目？有没有哪篇文章在你百思不解时，给了你灵感？

星云仔根据社区的阅读热度和专业深度，盘出了这份「2025 NebulaGraph 高光文章年鉴」。快来看看，这些过去一年被反复转发和讨论的宝藏，你错过了哪一篇？

> 星云仔温馨提示：点击图片，直接跳转文章原文

# 一、图数据库选型

什么场景选择图数据库是最佳解决方案？本文以客户-经理-助理的典型关系为例，揭示关系型数据库依赖外键隐式表达关系的局限，并展示以 NebulaGraph 为代表的图数据库，在复杂关系场景的显著优势，用最通俗易懂的语言让你理解：当数据关系复杂、变化频繁且需深度探索时，图数据库是不可替代的解决方案。

[![](https://pica.zhimg.com/80/v2-9120da470584b8c54c9f82baf023eef4_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HOFkaGmjFPHSiX3Aqctr1K3QNcAfT33MF3Bxs8Za&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515828%26idx%3D1%26sn%3Deb22a1dd1b4f5ca4c1cf45dd20f6a543%26scene%3D21#wechat_redirect)


如何选择一款适合业务需求的图数据库？在 DB-Engines 国内外排名第一的 NebulaGraph 与 Neo4j 选型对比中，核心差异在于架构与定位。Neo4j 的 Cypher 语言成熟、生态完善，适合中小规模深度图分析。而 NebulaGraph 采用原生分布式架构，在十亿级边数据下查询性能优势显著，并全面支持信创环境，更适合需要水平扩展、高性能及国产化替代的大规模实时场景。

[![](https://picx.zhimg.com/80/v2-bc32a5fc9705b608673036dfde8ea1fb_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HP5kaGmjdqPxdf-4MDJpvB8kJkM0qkv92vpeSsHR&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247516042%26idx%3D1%26sn%3D10ba45d8f96921c65c2918cd68ea6425%26scene%3D21#wechat_redirect)


为何选择 NebulaGraph？作为全球数据库领域的“奥斯卡奖”，DB-Engines 排名是衡量数据库流行度的重要指标。2025 年 9 月，NebulaGraph 在 DB-Engines Graph 类别中排名第二，不仅证明了 NebulaGraph 在全球开发者社区和市场需求中的受欢迎程度，更体现了中国基础软件在国际舞台上的崛起。

[![](https://picx.zhimg.com/80/v2-d97ddda851dbd91289436bb63199c049_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21&poc_token=HCRlaGmjsfVbt-qIaQ2jQoeisjTKKt1GZ--7ttd4)


# 二、AI+知识图谱

在 DeepSeek 问世之初，尝试将其与 NebulaGraph 结合，从零构建农业知识图谱，验证 AI 在知识结构化方面的强大能力。

首先，DeepSeek 能够从单篇文章中提取实体与关系，生成规范的 nGQL 脚本，快速构建基础图谱。其次，面对多源信息，AI 可自动融合新知识，动态扩展图谱结构，并支持属性与关系的增量更新。最后，即使仅输入主题描述，DeepSeek 也能“无中生有”生成符合逻辑的图谱框架，为冷启动场景提供可行路径。

[![](https://picx.zhimg.com/80/v2-a694f462ffe3d75f4686d73997ec3ca5_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515784&idx=1&sn=d195852253cc8a23b0ce879f37c94034&scene=21&poc_token=HKyBaGmjmLry6iivplDU1carUUe44EE3nj2i6-JY)


用 DeepSeek + NebulaGraph 构建知识图谱的类似实践，还有以下两篇～

[用 NebulaGraph + DeepSeek 解锁元宵节文化知识图谱，你知道几个？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515785&idx=1&sn=fdfbd45d83a9bf98a9623c237fa104ef&scene=21#wechat_redirect)

[NebulaGraph + DeepSeek 轻松看懂《哪吒2》人物关系](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515788&idx=1&sn=deb566e6826106f6d454bd822c06f157&scene=21#wechat_redirect)

‍‍‍

# 三、GraphRAG

在高级 RAG 技术演进中，由 NebulaGraph 提出并落地的 GraphRAG 成为解决传统检索框架知识稀释、关联丢失与宏观分析难题的重要路径。2025 年，NebulaGraph 进一步提出 Fusion GraphRAG 方案，系统融合文档层级、章节结构与图谱语义，在统一图存储中实现多层级、多模态的知识索引与检索。

Fusion GraphRAG 不仅支持基于元知识层的精准召回，还可通过 Chain of Exploration 在图谱中自主探索，完成从全局摘要到局部深查的复杂任务。

基于 Fusion GraphRAG，NebulaGraph 进一步推出低门槛的 AI 应用平台，支持企业以知识篮子方式组织文档，并通过对话快速构建智能应用。

[![](https://pic1.zhimg.com/80/v2-63ffbc9cb383f7bb2b0b6804d88c3816_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HM6BaGmjRNDMi3KH04B_UyvN3-mYKOlrYfmF2Io1&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515791%26idx%3D1%26sn%3D70f19b1a2b329fcfe3f4c8b72dd73955%26scene%3D21#wechat_redirect)

针对生物医学领域知识复杂、AI 易产生幻觉的痛点，国外开发者 Diya Mandot 构建了专业的生物医学问答系统 BioGraphRAG. 该项目以 NebulaGraph 作为核心图数据库，高效存储并管理了超过千万实体、数千万关系的 BioKG 数据集，并利用多进程优化，将数据导入时间从 33 小时大幅缩短至 3 小时。

[![](https://picx.zhimg.com/80/v2-e12ae36d75c6816762bd2b998b69596d_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HOSBaGmjxzB_ij0xC8LrnTgl0MX76JPDfSSvEZUZ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515825%26idx%3D1%26sn%3D966b393b631c5409637052d3a725184b%26scene%3D21#wechat_redirect)


如何提升 RAG 的效果？如何把 NebulaGraph 和大模型相结合？这里有系列教程，手把手教大家从 0 到 1 搭建一款垂直领域 AI 应用。

[星云实验室 part 1｜用知识图谱+GraphRAG,构建垂直领域 AI 应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515815&idx=1&sn=a22215ce45b2ff9d45f852046310b378&scene=21#wechat_redirect)

[星云实验室 part 2｜用知识图谱+GraphRAG,构建垂直领域 AI 应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515817&idx=1&sn=76729810a53419a3848289fbdc24a90b&scene=21#wechat_redirect)

[星云实验室 part 3｜构建知识问答聊天引擎与前端交互页面](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515819&idx=1&sn=d4e7a553a10e698bc03c6267426174f1&scene=21#wechat_redirect)

# 四、用户案例‍‍‍‍

告警响起，面对成百上千个微服务调用，问题究竟出在哪层网络、哪个应用、哪台主机？这就是 BOSS 直聘运维团队每天要面对的挑战。

直到他们用 NebulaGraph 构建起一张实时的全景图谱，所有服务、主机、中间件都变为点和边，调用关系、性能指标一目了然。当故障再次发生时，借助 NebulaGraph 的高性能图查询与图算法，仅用 20 秒就能实现根因定位，把平均故障修复时间压缩到分钟级别，让运维团队从此告别连猜带蒙，真正实现智能运维的质变。

[![](https://picx.zhimg.com/80/v2-830615d0bcadf0b622a5886ff7c41ae4_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HP6BaGmjiXsF7hXGI7hzPnw39PoojuqqXl7udgEg&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515831%26idx%3D1%26sn%3D7a5034daaf9414cb20452af1dadfa272%26scene%3D21#wechat_redirect)


面对海量且复杂的业务关系，携程选择将 NebulaGraph 深度集成到其基础设施中，并巧妙构建了一套覆盖单机房、三中心与跨域多活的弹性部署策略。通过客户端的定制化改造，他们成功将跨域查询的网络损耗降低了 70%，并实现了QPS 跃升23%、平均响应稳定在毫秒级的出色表现。

这一实践不仅证明了 NebulaGraph 在千亿级超大规模场景下的强大性能，更体现了携程工程团队如何通过精细化的架构设计与调优，让图技术真正服务于核心业务。

[![image|690x293](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/xiechen.webp)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515805&idx=1&sn=2880a5d7dd0608f55a2b834687d64dac&scene=21&poc_token=HD2CaGmjeExMFMmFrg-va4ygfQ2LqyyCUaAOiFVf)


在追求 GraphRAG 国产化落地过程中，中科数睿团队系统探索了包括 NebulaGraph、TuGraph 在内的多款国产图数据库，并历经了从微软开源方案、DB-GPT 到 KAG 等多种技术路径的迭代。基于 DeepSeek 大模型微调与诱导生成，团队最终创新性地构建了流式解析、分层存储与动态规划相结合的混合架构。该方案有效利用 NebulaGraph 处理结构化关系，并结合占位符回填机制，显著提升了专业领域问答的准确性与可解释性，为 GraphRAG 国产化落地提供了宝贵的一手经验。

[![](https://picx.zhimg.com/80/v2-82bda69d7ed5faea8c19674a5356b236_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HFSCaGmjSYlCm9pt-P-jtNUX13llK-PImVyj7WSQ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515833%26idx%3D1%26sn%3D32a8665844ec6973b26ebb1abbfca03b%26scene%3D21#wechat_redirect)


# 五、技术科普

内存调试犹如大海捞针，尤其在复杂的 C/C++ 程序中，本文介绍的 Debug 神器 Core Analyzer 能够深入扫描堆内存，支持多种内存管理器，提供堆概览、泄漏检测、引用链追踪等一系列强大命令，极大提升内存问题排查的系统性与效率。它特别适用于并发场景下难以复现的疑难问题，是对 ASAN 等传统工具的重要补充。

[![](https://picx.zhimg.com/80/v2-ec3f4ff155da466d5002ed4b05fd7d2d_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HGOCaGmjmDaKj9nsYd3RwU_qZc4Zt5undEv0XLcQ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515811%26idx%3D1%26sn%3D42e6230d83a1a9570baf2496f048810e%26scene%3D21#wechat_redirect)


NebulaGraph 存储负责人@四王，回顾了 Redis 作者与 DDIA 作者围绕 Redlock 安全性的经典辩论，深刻揭示了分布式锁在时钟漂移、进程暂停等场景下的共性问题，其本质在于实现分布式一致性共识。对分布式锁的技术讨论充分体现了 NebulaGraph 团队对分布式系统核心问题的持续关注与研究深度，也为大家理解 NebulaGraph 的分布式架构实践提供了理论参照。

[![](https://picx.zhimg.com/80/v2-cedbf35a7506295f112a7284d8770423_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515816&idx=1&sn=f1f509474e7e887aac6d8ad2a56de769&scene=21&poc_token=HHaCaGmjfQZtHVry1V_bTb267PJS7RtgWcPy5Jmt)

# 六、Ending

回顾 2025，这些文章不仅记录了一场场技术的探索与实践，更映射出图数据库走向核心基础设施的清晰轨迹。无论是与 AI 的深度融合，还是在千亿级场景中的稳定性锤炼，NebulaGraph 与社区开发者共同交出了一份扎实的答卷。

感谢每一位读者的关注与阅读。技术的价值，在于被理解、被应用、被改进。希望这份年度盘点能成为你新一年探索路上的得力助手。




2025 年值得一读的图数据库文章

盘点 2025 年值得一读的图数据库文章～

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/community-star/community-star-2025.jpg)

2025 NebulaGraph 社区之星璀璨揭晓！

12 月 22 日晚，快手直播遭遇大规模黑产攻击。

**超过 1.7 万个僵尸账号同时开播，海量违规内容绕过审核系统，露骨画面、擦边直播及诱导转账的“密码房福利”层出不穷**。多名网友描述"点开直播全是黄色内容"，甚至调侃“十个直播七个在放片”，部分直播间观众达数十万人。**用户举报按钮形同虚设，即便违规内容下架，新违规账号却持续涌现**。

最终迫使快手在 2 小时后，采取全平台截断直播的极端措施终止这场充斥淫秽与血腥的 P0 级事故。12 月 23 日快手股价盘中一度下探超 5.7%，较前一交易日蒸发约 164 亿港元。

这一夜，被不少从业者称为快手的“至暗时刻”。

但更值得警惕的是：

这并非某一家平台的偶发事故，而是整个行业风控体系的一次系统性失效暴露。

风控安全，不进则退。在 AI 驱动的自动化攻击面前，依赖 IP 黑名单、静态规则、预计算指标、事后审核的传统风控体系，已经难以支撑现代互联网业务的安全底座。

# 一、黑产击溃传统风控范式

快手 12.22 直播事故，真正击穿的，不是审核能力，而是风控范式。

从公开信息来看，快手并非没有健全的审核机制与风控体系，而是风控系统在黑产攻击方式升级后力不从心。

传统平台风控体系，大多建立在以下逻辑之上：

-   将账号、设备、IP、行为等关联指标提前计算
    
-   将结果写入 Redis / ClickHouse
    
-   通过规则引擎 \+ 阈值判断做风险决策
    ![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/traditional-risk-control.webp)

这套“预计算 \+ 静态规则”的体系，在过去多年行之有效，但在黑产迈入自动化攻击后便暴露出致命短板。

## 1\. 关联关系是“活的”，而预计算是“死的”

黑产并非单账号违规，而是：

-   多账号
    
-   多设备
    
-   多 IP
    
-   实时变换组合
    
-   同步协同攻击
    
关联网络在分钟级甚至秒级重构，而 T+1 或分钟级预计算指标天然滞后。

## 2\. 单点看似正常，整体却是异常

在传统风控视角下：

-   每个账号行为“合规”
    
-   每个 IP 访问“正常”
    
-   每次开播“合法”
    
真正的风险隐藏在多跳关系与群体结构中，而不是任何一个孤立指标。

## 3\. 高并发场景下，规则系统被压垮

当 1.7 万账号同时触发检测时：

-   AI 识别模型排队
    
-   人工复核失效
    
-   规则系统被放大流量拖垮
    

最终只能通过“全量截断”这种业务级熔断止血。

这场事故揭示了一个残酷现实：黑产的攻击是动态、协同、结构化的，而传统风控系统仍停留在静态、割裂、事后响应的阶段。

# 二、风控的本质在于“关系”

无论是直播黑产、支付欺诈，还是稳定币洗钱，本质都不是某个行为异常，而是：一张不断变化的关系网络，在协同掩盖真实意图。

-   一个设备控制上百账号
    
-   多个地址将资金归集至同一黑洞
    
-   多个看似无关的行为，构成完整攻击链路
    

这类问题，天然属于图问题。而这，正是传统预计算风控体系无法解决的核心原因。

在传统风控系统中，引入图数据库后，风险被可视化地展示为图谱。

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

NebulaGraph x 奇富科技（原 360 数科）群体关系图

上图是奇富科技生产环境的一个图，不同颜色的点分别表示不同的意义，红色是风险点，黄色是疑似风险，灰色是普通用户。

# 三、NebulaGraph 的实时图风控

## 1\. NebulaGraph

NebulaGraph 是一款开源分布式图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时的图数据库解决方案。

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

在百亿级数据量下的测试中：

-   传统关系型数据库：4 度关联查询，154 秒
    
-   NebulaGraph：4 度关联查询，0.14 秒
    

性能提升 1000 倍以上，这正是实时风控在高并发场景下的基础能力。

目前，NebulaGraph 已在以下场景中落地：

-   金融反欺诈与反洗钱
    
-   Web3 合规与资金追踪
    
-   交易平台黑产识别
    
-   实时风险图谱构建
    

NebulaGraph 的用户包括 Airwallex、众安保险、BlockSec、得物、携程集团等，构建了从千亿节点到万亿关系的实时风控图系统。

## 2.实时动态风控体系
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/risk-control-nebula.webp)

以 NebulaGraph 为代表的实时图风控体系，并不是在优化规则，而是在重构风控的底层认知方式。

**（1）不再预计算关系，而是实时构图**

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/dynamic-analysis.webp)

-   用户、账号、设备、IP、交易、行为
    
-   实时写入图中
    
-   关系随业务发生即时变化
    

风控系统不再依赖算好的结果，而是直接读取真实世界的当前关系状态。

**（2） 多跳穿透，识别群体型风险**
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/graph-algorithm.webp)

通过图查询和图算法，可以在毫秒级完成：

-   N 度关联穿透
    
-   账号–设备–IP–账号的闭环识别
    
-   团伙结构、控制中心、扩散路径识别
    

从「看单点」升级为「看结构」。

**（3）实时规则 + 图算法双引擎**

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

-   实时规则：
    
-   “5 分钟内同一设备登录 10+ 账号”
    
-   “同一 IP 批量开播”
    
-   图算法：
    
-   社区发现
    
-   中心性分析
    
-   异常子图识别
    

规则负责即时拦截，图算法负责结构洞察。

**（4）在快手中引入图数据库**

如果在快手的场景中，引入实时图风控会发生什么？

在类似直播平台的业务中，实时图风控可以前置到多个关键入口：

-   注册
    
-   登录
    
-   开播
    
-   内容发布
    

当黑产设备开始批量注册或登录时：

-   关联关系已在图中显现
    
-   风险结构在规模化前被识别
    
-   攻击在“发起之前”即被阻断
    

这意味着：

-   审核系统不再被洪水冲垮
    
-   业务无需通过全量截断自伤止血
    
-   风控从被动救火转为主动拦截
    
    # 四、结语
    

这次事故，并不是开始，也不会是结束。随着 AI 攻击工具、自动化脚本、Web3 与跨境业务的普及，黑产只会更加动态、隐蔽、系统化。

企业必须重新认知风控：

-   风控不是一套产品，而是一种能力
    
-   防线不是静态规则，而是动态关系网络
    

只有具备实时构图、动态感知、结构洞察能力的图风控体系，才能在这场长期对抗中掌握主动权。

NebulaGraph 将持续作为实时风控的底座，帮助企业在复杂关系网络中构建真正可进化的风控能力。

迎接动态风险，从拥抱实时图开始。

---
🔥推荐阅读

[《稳定币条例》强监管，图技术如何抢占风控主动权？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515838&idx=1&sn=4301cd1dce294f75f13bac03bc13e647&scene=21#wechat_redirect)

[基于知识图谱的 Web3 风控：普适智能一站式知识中台](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515978&idx=1&sn=079d22d3bf3f06b5d13e70598a081dd4&scene=21#wechat_redirect)

[NebulaGraph 在 Airwallex 跨境金融风控的应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515804&idx=1&sn=82973a9f946708468e9fddfd52243ebd&scene=21#wechat_redirect)

[NebulaGraph + LLM 处理风控知识图谱的探索和实践](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515771&idx=1&sn=4c8c1c729b01ddc9eca5bf0f0ad60156&scene=21#wechat_redirect)

[风控利器：BlockSec 用图+标签破解 Crypto 合规难题](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516261&idx=1&sn=f3e91388b2a0e796801bea67bd6f9517&scene=21#wechat_redirect)



以图为底座的实时动态风控系统

快手直播事故，传统风控为何被黑产击溃？


> 图算法的小白级科普⬇️

[技术科普｜图算法是什么？何时用、怎么用？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515839&idx=1&sn=046e14a224c3f47e2a97748916d366be&scene=21#wechat_redirect)

（文章结尾有 NebulaGraph 在风控领域的用户案例合集哦～）

在电商风控战场中，黑产的手段正变得越来越隐蔽——批量注册的“垃圾账号”用不同设备登录、分散地址下单，通过“断链伪装”规避规则拦截；恶意商家联合多个账号刷单，制造虚假热销假象......传统的“单维度规则校验”（如仅判断IP是否异常、账号是否新注册）早已难以应对这种“跨主体关联作弊”。

而图算法的核心优势，正是把分散的“点”（账号、IP、设备、地址等）通过“边”（关联关系）连接成网，从“关系视角”识破黑产的集体作弊行为。

2023 年，得物风控对比了 Neo4j、Dgraph、JanusGraph、NebulaGraph，最终选择将 NebulaGraph 作为风控解决方案。

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/dewu-risk-control/choose-graph-database.webp)

图源「得物风控」公众号

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/dewu-risk-control/risk-control-system.webp)

图源「得物风控」公众号

今天就带大家拆解风控领域最常用的3类图算法，结合电商场景讲清算法思路和落地应用。通俗易懂无门槛～

# 一、风控里的“图”是什么？

在风控场景中，图的构成非常简单，无需复杂的数学基础就能理解：

-   节点：就是风控中的“参与主体”，比如账号、IP地址、设备ID、收货地址、手机号、银行卡号等；
    
-   边：就是主体之间的“关联关系”，比如账号A登录过IP地址B、账号C绑定了手机号D、账号E用地址F下单、账号G和H共用设备I等；
    
-   属性：节点或边的补充信息，比如账号的“注册时间”“是否实名认证”、IP的“归属地”“是否为代理IP”、关联关系的“发生时间”“频次”等。
    

举个例子：黑产用1个IP注册10个账号，这10个账号都绑定了不同的虚拟手机号，且都往同一个超市地址下单。这里的“1个IP+10个账号+10个手机号+1个地址”是节点，“注册”“绑定”“下单”是边，构成了一张典型的“黑产作弊图”。

图算法的作用，就是从这张网中找到“异常的关联模式”，比如“一个国内IP关联上百个注册账号且都是海外手机号”“多个账号共用一个设备且都有恶意下单行为”。

# 二、风控常用三大图算法及应用场景

## （一）连通分量算法：找到作弊团伙

**算法思路**

简单说就是“找圈子”——在图中找到所有相互连通的节点集合（即“连通分量”），同一个集合里的节点无论通过多少层边关联，都属于同一个“团伙”。

比如：账号A → IP → 账号B → 设备 → 账号C**，**这3个账号通过IP和设备间接连通，就会被划分为同一个连通分量，认定为“关联账号团伙”。

算法的核心价值：**把分散的作弊主体“聚合成团”，避免单个账号漏判**——黑产单个账号可能看起来“正常”（如注册时间长、有少量真实下单），但整个团伙的行为特征（如集中下单、共用资源）会暴露作弊本质。

**电商应用场景：识别“批量关联作弊”**

-   场景1：垃圾注册团伙识别

    黑产用同一IP（或代理IP池）批量注册账号，这些账号可能绑定不同手机号，但都共用某几个设备。通过连通分量算法，将“IP-账号-设备-手机号”关联的所有节点划分为一个团伙，只要团伙中部分账号被标记为“垃圾注册”，整个团伙的其他账号都会被纳入风控视野，提前拦截恶意行为（如领券、下单）。

-   场景2：刷单团伙识别
    
     恶意商家组织100个账号刷单，这些账号可能来自不同IP，但都往商家的固定商品下单，且部分账号共用支付设备。连通分量算法会将这些“账号-商品-支付设备-收货地址”关联的节点聚合成团，结合“团伙下单时间集中、收货地址相似”等特征，判定为刷单团伙，以此及时落罚恶意商家和刷单账号。
    

落地小技巧

-   对连通分量进行“大小筛选”：比如仅关注节点数≥5的团伙（避免正常用户的少量关联被误判）；
    
-   给边设置“权重”：比如“账号-设备”的关联权重高于“账号-IP”（设备唯一性更强），权重越高的边对“团伙聚合”的影响越大。
    

## （二）度中心性算法：揪出核心作弊算法思路

**算法思路**

“度”是指一个节点连接的边的数量——度中心性越高，说明这个节点和其他节点的关联越密集，越可能是“核心枢纽”。

在风控中，我们重点关注“入度”（其他节点主动关联它的次数）和“出度”（它主动关联其他节点的次数）：

-   比如一个IP的“出度”是100（关联100个账号登录），说明这个IP是批量注册/登录的核心；
    
-   一个设备的“入度”是50（50个账号共用它），说明这个设备是黑产的“共用工具”。
    

算法的核心价值：**快速定位作弊网络中的“关键节点”，精准打击黑产的“基础设施”**——查封一个核心IP/设备，可能连带阻断几十个作弊账号的操作。

**电商应用场景：打击“黑产核心资源”**

-   **场景1：识别恶意IP/设备**
    
    正常用户的IP通常只关联1-2个账号，若某IP的度中心性（关联账号数）达到50+，且关联的账号多为新注册、无实名认证，可判定为“黑产专用IP”，酌情考虑拉黑或升级管控该IP的所有后续注册/登录请求；同理，某设备关联几十个账号且都有恶意下单行为，可判定为“黑产共用设备”，酌情考虑封禁设备对应的所有账号。
    
-   **场景2：识别“养号中介”账号**
    
    部分黑产账号的核心作用是“关联其他作弊账号”（如作为“主账号”邀请新账号注册、共享优惠券），这类账号的度中心性极高（关联上百个下级账号）。通过度中心性算法识别出这类“核心中介账号”，封禁后可切断黑产的账号扩散链路。
    

**落地小技巧**

-   分维度计算度中心性：比如单独计算“IP-账号”“设备-账号”“手机号-账号”的度，避免不同维度的关联相互干扰；
    
-   结合时间窗口：比如统计“近7天”的关联度，避免长期积累的正常关联（如家庭共用IP、企业IP等）被误判。
    

##（三）密集子图挖掘算法：精准拆分隐蔽作弊小团体

**算法思路**

比连通分量算法更精细的“团伙拆分工具”——核心是在一张大范围连通的关联图中，精准定位“内部关联极密集、与外部关联极稀疏”的子图（也就是黑产实际运作的“小团体”）。

简单说：连通分量算法是“只要沾边就归为一类”（比如一个IP关联的100个账号全算一个大团伙），而密集子图挖掘是“关系够近才凑一组”——同样是100个账号关联同一个IP，其中30个账号之间还存在“互相转账、共用收货地址、交叉助力”等多重紧密关联，这30个账号就会被挖掘成一个密集子图；剩下70个账号若仅和IP有关联、彼此无交集，可能拆成多个独立的密集子图，对应不同的作弊小团体。

算法的核心价值：**打破“大团伙”的笼统判定，拆分出黑产实际运作的“作战单元”**——同一个黑产资源（如代理IP池、共用设备）可能被多个独立团伙共用，密集子图能精准区分不同团伙的作弊链路，避免对正常用户的关联误判，也为针对性打击提供依据。

**电商应用场景：精准打击“细分作弊团伙”**

-   **场景1：拆分多团伙共用资源的作弊行为**
    
    某代理IP池被3个独立黑产团伙共用，A团伙专注刷单、B团伙专注薅平台优惠券、C团伙专注恶意注册。虽然所有团伙账号都关联该IP池（属于同一个连通分量），但A团伙内部账号会频繁交叉下单、B团伙内部账号会领同一类优惠券，彼此无关联。通过密集子图挖掘，可将3个团伙拆分为3个独立的密集子图，针对A团伙封禁下单权限、B团伙限制领券、C团伙直接拦截注册，避免“一刀切”导致的误判或漏判。
    
-   **场景2：识别“跨平台协同作弊小团体”**
    
    黑产为规避单平台风控，会在电商APP、小程序、H5端分别注册账号，但这些账号会共用同一台设备、绑定同一组手机号，且存在跨平台交叉操作（如APP端领券、小程序端下单）。密集子图挖掘能跨平台聚合这些“设备-手机号-账号”关联紧密的节点，形成“跨端作弊密集子图”——即便某端账号未表现出恶意（如APP端账号仅浏览未下单），但因属于作弊密集子图，可提前限制其核心行为（如限额下单、需实名认证），阻断跨平台作弊链路。
    

**落地小技巧**

-   常用算法选择：风控场景无需复杂模型，Louvain算法（效率高、适合大规模图数据，能自动平衡子图规模）或LPA（标签传播算法，无监督、易落地、计算快）完全够用；
    
-   结合行为特征打标：挖掘出密集子图后，可根据子图内账号的核心行为（如高频下单、批量领券、恶意注册），给每个子图打上“刷单团”“薅券团”“注册机团”等标签，后续针对标签制定差异化拦截策略；
    
-   设定密度阈值：可通过“子图内实际关联数/最大可能关联数”计算密度，仅关注密度≥0.3的子图（避免正常用户的少量交叉关联被误判为作弊小团体）。
    

# 三、图算法落地关键

很多同学会问：“算法识别出团伙后，怎么落地到风控策略里？” 分享3个实战中常用的闭环逻辑：

1.分级拦截：根据连通分量大小、度中心性高低、子团伙风险概率，给节点打风险等级（高/中/低）——高风险直接封禁，中风险限制行为（如权益限制、发垃圾券等），低风险持续监控；

2.传导处罚：若一个节点被判定为恶意（如账号被封禁），其关联的节点（如登录IP、绑定设备）同步提升风险等级，实现“打一个、带一片”；

3.实时+离线结合：离线用图算法（如连通分量、密集子图发现）挖掘团伙，生成“风险团伙名单”；实时风控时，校验当前账号是否在名单中，或是否关联高风险节点，实现快速拦截。

举个落地示例：

-   离线：每天用连通分量算法聚合“账号-IP-设备-地址”强关联图，识别出节点数≥10的团伙，若团伙中恶意账号占比≥30%，标记为“高风险团伙”；
    
-   实时：用户下单时，校验该账号是否属于“高风险团伙”，或是否关联团伙中的IP/设备，若是则权益隐藏或拦截订单，提示“账号存在XX异常风险”。
    

# 四、总结经验

黑产作弊的核心本质，从来不是 “单个账号的孤立行为”，而是 “团伙化、批量化的协同操作”—— 他们通过换 IP、换设备、买号养号等手段切断单点关联，让传统规则难以追踪。而图算法的核心价值，正是**穿透这些 “断链伪装”，看透账号、IP、设备、地址背后的隐性关联**。

相较于传统规则 “头痛医头、脚痛医脚” 的单点防控，图算法实现了三大突破：

1.打破维度壁垒：不再局限于单一维度校验，而是将 “账号 - IP - 设备 - 地址 - 手机号” 等多主体联动分析，让分散的作弊行为 “串成线、聚成团”；

2.前移风控关口：即便单个账号未表现出任何恶意特征，也能通过其所属团伙的集体作弊痕迹（如共用黑产设备、关联恶意账号）提前预判风险，实现 “未发先防”；

3.直击黑产核心：精准锁定团伙的核心资源（如共用设备、批量注册 IP），避免黑产通过 “换号换 IP” 规避拦截，实现 “打一个、断一片” 的高效打击。

对风控从业者而言，图算法绝非高深莫测的数学工具，而是人人可落地的实战基操—— 只要理清 “节点（参与主体）\- 边（关联关系）” 的核心逻辑，就能快速应用于反作弊、反欺诈等核心场景，让风控从 “被动响应拦截” 升级为 “主动前置防御”。

---

NebulaGraph 风控案例

[基于知识图谱的 Web3 风控：普适智能一站式知识中台](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515978&idx=1&sn=079d22d3bf3f06b5d13e70598a081dd4&scene=21#wechat_redirect)

[风控利器：BlockSec 用图+标签破解 Crypto 合规难题](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515844&idx=1&sn=3a216c55323488cb5235f5194fa47ddd&scene=21#wechat_redirect)

[《稳定币条例》强监管，图技术如何抢占风控主动权？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515838&idx=1&sn=4301cd1dce294f75f13bac03bc13e647&scene=21#wechat_redirect)

[NebulaGraph 在 Airwallex 跨境金融风控的应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515804&idx=1&sn=82973a9f946708468e9fddfd52243ebd&scene=21#wechat_redirect)

[NebulaGraph + LLM 处理风控知识图谱的探索和实践](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515771&idx=1&sn=4c8c1c729b01ddc9eca5bf0f0ad60156&scene=21#wechat_redirect)

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

[中国移动：如何用 NebulaGraph 图数据库解决金融风控中的问题？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515545&idx=1&sn=eb0187e3b42fa355e19c81bf8f0de593&scene=21#wechat_redirect)



拆解风控领域最常用的3类图算法，结合电商场景讲清算法思路和落地应用。

得物风控：风控常用图算法及应用


> NebulaGraph v5.2.0 为企业版，社区最新版为 v3.8.0。社区用户可通过 [NebulaGraph Cloud ](https://cloud.nebula-graph.io/login )试用 v5.2.0，限时免费 14 天，并享专属企业折扣。

数据正成为 AI 重塑各行各业的关键力量，而数据的真正价值蕴藏于关系之中，而非孤立记录——现代AI需要的基础设施，不仅要能存储关联，更要能实时、大规模地对关系网络进行计算与推理。

为此，NebulaGraph 正式推出专为图智能演进的 v5.2.0，通过内置轻量级图计算引擎、100 倍提升的路径查询性能，以及图+向量+文本混合检索能力，v5.2.0 已超越传统存储层，演进为真正的 AI 原生引擎。

# 数据层：构建 AI 的统一数据模型  

AI 需要动态互联的数据以理解现实世界，NebulaGraph v5.2.0 应运而生。

## 统一多模态查询与架构简化  
v5.2.0 原生支持全文索引，与现有向量检索能力形成互补。开发者现可在单系统内通过一条查询，同步执行图遍历、语义向量匹配与关键词检索，无需再整合多套引擎，显著降低系统复杂性与人力成本。

## 超级节点治理与空间智能  
现实图谱中的超级节点会严重拖慢查询，v5.2.0 引入 SAMPLE 子句，可智能限制超级节点的遍历规模，确保稳定可预测的响应性能。

新增 GEO 数据类型与空间函数，让图数据库原生支持地理空间计算。这一特性为物流优化、零售选址、物联网拓扑分析等兼具关系与地理属性的场景开辟了新的可能性。

## 内置轻量级图计算引擎
传统图分析依赖重型批处理引擎，难以满足实时 AI 需求。v5.2.0 将轻量级图计算引擎嵌入数据层，支持动态创建与实时变更子图，使 AI 系统能够基于特定数据上下文进行即时运算。

以实时反欺诈为例，系统可将交易关联网络快速隔离为瞬态子图，即刻执行风险评分算法，在毫秒内生成洞察，且资源开销极低。

# 计算层：让图智能成为 AI 原生能力  

NebulaGraph v5.2.0，图计算全面升级，充分释放图数据库充当 AI 底座的强大潜力。

## 专注业务的图查询语言
全新的 GQL 支持控制流与可复用存储过程，并使用统一的 GQL Procedure 语法，大幅降低了图算法开发门槛，开发人员只需专注于业务逻辑本身，而不是底层工程细节，从而加速 AI 应用从原型到落地的全过程。

## 深度推理路径查询速度提升 100 倍 
v5.2.0 在最短路径、全路径遍历等关键算法上实现了 100 倍性能提升，这意味着即使在包含亿级别边的关系网络中，系统也能高效地执行超过五跳及以上的深度推理查询，并且查询深度越深，效率提升越大。

这对于需要多跳推理的 AI 应用具有变革意义，例如，在供应链风险分析、股权穿透追踪或影响力传播等场景中，AI 能够实时遍历海量复杂网络，发现以往难以触及的长程依赖与隐藏结构模式。

# 融合层：“图+向量”成为智能检索新标准  

## 图+向量+文本的混合检索
v5.2.0 支持真正的混合检索：无需外部引擎，单次查询即可融合图关系遍历、向量语义匹配与全文相关性排序。AI 不再返回零散的语义相似片段，而是遍历知识图谱构建事实准确、逻辑连贯的答案链，显著减少大模型幻觉，提升企业级 AI 输出的可信度。

## 计算结果直连 AI 工作流  
图计算产出的特征是训练 GNN 或传统机器学习模型的重要输入。v5.2.0 支持将结果直接写入图库、CSV 或 S3/HDFS，无缝对接特征平台或训练流水线，缩短数据—特征—模型的闭环周期。

# 强化企业级保障，确保 AI 业务平稳运行  

AI 应用已深度嵌入企业核心流程，高度依赖底层数据基础设施的高可用性与容灾能力。一旦图数据库因故障中断或响应延迟激增，不仅会影响用户体验，更可能导致错误决策甚至业务损失。v5.2.0 通过增量备份、热节点替换、高可用读扩展等特性强化企业级保障，确保生产环境 AI 服务永续运行，真正实现“7×24 小时不间断”的智能决策支持。

# 即刻开启多模图智能时代

* 构建智能的推荐或欺诈检测系统？利用 NebulaGraph v5.2.0 实时子图计算和 100 倍提速的遍历，获得更深、更快的洞察。
* 管理包含多模态数据的复杂知识图谱？通过 NebulaGraph v5.2.0 图+向量+全文检索简化技术栈。
* 开发下一代 RAG 应用？使用 NebulaGraph v5.2.0 混合检索将 LLM 的回答与现实世界和上下文绑定，消除幻觉。

**准备好了吗？从这一刻，开始探索图数据库为底座的多摸图智能时代。**

[NebulaGraph Cloud 14 天免费试用](https://cloud.nebula-graph.io/login )






NebulaGraph 正式推出专为图智能演进的 v5.2.0，通过内置轻量级图计算引擎、100 倍提升的路径查询性能，以及图+向量+文本混合检索能力，v5.2.0 已超越传统存储层，演进为真正的 AI 原生引擎。

从 NebulaGraph v5.2.0，开启多模图智能时代



在与社区的共同成长中，我们深知，最深度的产品需求洞察与用户体验反馈，往往源于一线的碰撞交流。

为此，NebulaGraph 核心团队首次启动 O2O（office to office）计划。

我们希望来到你的 office，深入你的业务场景，以纯粹的技术视角，为你面临的真实挑战提供定制化的深度技术支持与架构指导。

也希望在未来，你的团队来到 NebulaGraph office，与诸多社区用户一起交流 NebulaGraph 的使用经验。

我们期待与正处于图技术应用关键阶段的你，携手探求最优解。

> 星云仔号外：活动免费～只需为我们提供一个会议室，预留充足的交流时间即可。

# **01** 为何推出 O2O计划？

我们的目标简单而专注：

* **为你解忧：** 集中 NebulaGraph 交付专家与产品团队的力量，现场为你诊断架构、分析性能瓶颈，解决棘手的技术难题。

* **收集反馈：** 线下收集你对 NebulaGraph 产品的真实反馈，你的真知灼见将直接助力 NebulaGraph 的产品迭代。

* **共建共赢：** 与社区用户建立长期、可信赖的连接，共同推动 NebulaGraph 生态的繁荣。

# **02** 你将获得什么？

* **个性化系统诊断与优化建议报告：** 活动结束后，你将收到一份由 NebulaGraph 核心团队提供的技术报告，直指核心问题，并提供 actionable 的解决方案。

* **专属技术支持通道：** 拥有专属技术支持微信群，获得来自 NebulaGraph 的线上技术支持。

* **与核心团队面对面深度交流：** 关于 NebulaGraph 的一切问题，都将得到实施交付 leader 和 产品 VP 的解答。

* **社区大礼包：** 获得 n 个星云仔系列周边。

# **03** 期待这样的团队

为确保交流深度，我们将优先考虑符合以下条件的团队：

* 团队有专人或小组负责图技术相关工作的推进。

* 已在生产环境或核心测试环境中部署并使用 NebulaGraph.

* 正在面临性能、扩展性、运维等方面的具体技术挑战，并有强烈的意愿寻求突破。

* 愿意成为社区代言人，包括但不限于：分享用户案例/开发实战，积极参与代码共建与线下交流活动。

# **04** 活动时间

NebulaGraph O2O 计划长期有效，第一批招募时间为即日起至 11 月 17 日。

我们将每天对报名进行审核，审核通过后，根据双方时间，在 2 周内尽快安排专属技术支持。

# **05** 活动流程

1. **报名筛选：** 填写报名问卷，帮助我们初步了解当前的使用情况。

2. **会前沟通：** 3 个工作日内，我们将以电话形式与成功入选的团队沟通，并收集必要的技术资料以供技术团队提前研究。

3. **现场交流：** NebulaGraph 团队来到你的 office，进行技术研讨与技术支持。

4. **会后跟进：** 在活动后交付书面报告，并建立专属支持通道，确保活动价值得以延续。

# **06** 报名方式

名额非常有限～务必认真、全面地填写报名问卷。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/activity-O2O/qrcode-4.png)


扫码报名⬆️

我们相信，最合适的交流能创造最大的价值。

现场见～



集中 NebulaGraph 交付专家与产品团队的力量，现场为你诊断架构、分析性能瓶颈，解决棘手的技术难题

NebulaGraph O2O 招募｜为你提供免费现场技术支持

> 导读：在技术科普「Coding Agent」系列中，由 NebulaGraph GenAI Team @PsiACE 为大家带来多期 Coding Agent 实践经验，并分享 NebulaGraph GenAI 的最新工作。
> 
> 本期，@PsiACE 分享的是如何用 Python 实现一个能自举的 Coding Agent，并给出了避坑指南，希望给大家的 Coding Agent 带来启发。

Bub 的第一个 milestone：自动修类型注解。由 Moonshot K2 驱动。

> Bub: Successfully fixed the first mypy issue by adding the missing return type annotation -> Noneto the \_\_init\_\_method in src/bub/cli/render.py, reducing the error count from 24 to 23.

# **01** 为什么要自己造 Agent？

Coding Agent 现在已经是个红海赛道，市面上有不少优秀的产品，还有许多团队在 PPT 中绘制宏伟蓝图。

然而，Coding Agent 的“token 大力出奇迹”现象也很明显——动辄几十万 token 的消耗，真正有价值的部分却少之又少。

**这让我很好奇：如果自己动手造一个 Coding Agent，能不能找到更高效、更实用的解决方案？**

于是，我开始折腾一个叫 Bub 的 CLI 助手。它的目标很简单：做一个命令行下的实用助手，同时具备有限的自举能力。自举这个概念在编译器、操作系统领域早已不算新鲜，很多 Coding Agent 也喜欢宣传“AI 工程师贡献了多少代码”。

我希望 Bub 能迈出自己的第一步，解决它自身代码中的第一个实际问题。

# 02 最小可用：先跑起来再说

我的经验是，能跑起来的最小闭环最重要，别一上来就追求“完美架构”或者花太多时间做数据小偷。

Bub 的分层很简单：

-   **Agent**：主循环，负责 LLM 交互、工具调用、上下文管理。
    
-   **Tool**：每个工具一个类，参数用 Pydantic 校验。
    
-   **ToolRegistry**：注册所有工具，方便扩展。
    
-   **CLI**：Typer + Rich，命令行入口，支持展开中间状态。
    

Agent 的本质其实就是一个 while 循环。每次循环，Agent 会根据当前上下文判断是否需要调用工具，如果需要就调用，然后把工具的返回结果写回上下文。

## 主循环核心代码

```
class Agent:
    def chat(self, message: str) -> str:
        self.conversation_history.append(Message(role="user", content=message))
        while True:
            # Construct context: historical messages + tool list
            ...
            response = litellm.completion(...)
            assistant_message = str(response.choices[0].message.content)
            self.conversation_history.append(Message(role="assistant", content=assistant_message))
            tool_calls = self.tool_executor.extract_tool_calls(assistant_message)
            if tool_calls:
                for tool_call in tool_calls:
                    result = self.tool_executor.execute_tool(tool_call.name, **tool_call.parameters)
                    observation = f"Observation: {result.format_result()}"
                    self.conversation_history.append(Message(role="user", content=observation))
                continue
            else:
                return assistant_message
```

## **踩过的坑**

-   没有捕获，LLM 输出格式一变就死循环
    
-   工具参数没校验，LLM 乱传参数直接崩
    
-   Observation 反馈太长或缺乏有效信息，LLM 理解困难
    

# **03** 工具定义：扩展 LLM 的能力

工具是 LLM 和外部世界的桥梁，定义得好，模型才能真正“动手”。我的做法是：

-   工具参数全部用 Pydantic 校验，类型不对直接拒绝。
    
-   命令行工具有黑名单（比如 `rm`、`del`），遇到危险命令直接报错。
    
-   工具执行结果结构化返回，别让 LLM 猜。
    
-   操作命令行工具时，stdout 和 stderr 都很重要，不能只给 exit code.
    
-   工具之间要有明确边界，避免混淆。
    

```
class RunCommandTool(Tool):
    DANGEROUS_COMMANDS = {"rm", "del"}
    def _validate_command(self, base_cmd: str) -> Optional[str]:
        if base_cmd in self.DANGEROUS_COMMANDS:
            return f"Dangerous command blocked: {base_cmd}"
    def execute(self, context: Context) -> ToolResult:
        # Validate command, execute and return results
```

# **04** Prompt：让 LLM 按套路出牌

组织良好的提示词能显著提升 LLM 的输出质量。对于 Coding Agent 来说尤其重要，因为 LLM 的输出格式很容易失控。

我的经验

-   Prompt 里要列出所有工具和参数 schema。
    
-   多给几个调用示例，覆盖常见用法。
    
-   Observation 反馈要简洁，别堆无用信息。
    

## **Bub 的 ReAct Prompt 结构**

```
You are an AI assistant with access to tools. When you need to use a tool, follow this format:
Thought: ...
Action: run_command
Action Input: {"command": "ls"}
Observation: <output>
...
Final Answer: <your answer>
```

ReAct 的好处是简单直接，容易落地，虽然 token 消耗大，但能快速试错、跨模型迁移。

# **05** Milestone：自动修类型注解

定义好 Agent Loop、工具和 Prompt 后，Bub 的第一个 milestone 就是自动修复了一个 mypy 报错。

比如：

```
-    def __init__(self):
-        self.console = Console()
-        self._show_debug = False
+    def __init__(self) -> None:
+        self.console: Console = Console()
+        self._show_debug: bool = False
```

## 实际的 Agent Loop

-   只让 agent 改类型注解、格式化、重命名，别让它碰复杂逻辑。
    
-   先用命令行工具执行 `mypy`，拿到报错信息。
    
-   让 agent 生成修复建议，再用 file edit 工具应用到代码。
    
-   修完自动再跑一次 mypy，确保没新问题。
    

## **踩过的坑**

-   模型对代码上下文理解有限，经常修错。
    
-   不验证，bug 越修越多。
    

# **06** 进阶玩法与工程自查

随着功能扩展，踩的坑也越来越多。我的一些经验：

-   工具扩展时，建议单一职责，参数 schema 明确。
    
-   长对话要截断或摘要，别让 LLM 超窗。
    
-   生产环境建议沙箱/虚拟机，命令行工具默认禁危险命令。
    
-   LLM 输出格式不稳时要有 fallback 兜底。
    

# **07** 总结

Bub 还在早期，但已经能帮我自动修 bug、跑命令、读写文件。我希望这只是一个开始，然后得到更多有意思的反馈。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/coding-agent-2/Bub.webp)

Bub it. [Build.it](http://Build.it)

---

### 项目地址

[https://github.com/PsiACE/bub](https://github.com/PsiACE/bub)

### References

-   [https://ampcode.com/how-to-build-an-agent](https://ampcode.com/how-to-build-an-agent)
    
-   [https://huggingface.co/blog/tiny-agents](https://huggingface.co/blog/tiny-agents)

如何用 Python 实现一个能自举的 Coding Agent，并给出了避坑指南，希望给大家的 Coding Agent 带来启发。

技术科普｜如何用 Python 实现 Coding Agent

NebulaGraph  Graph 服务、Storage 服务和 Meta 服务扩容

NebulaGraph 扩容｜丝滑扩容Graph、Storage 与 Meta 服务

> 针对社区小伙伴们对 NebulaGraph 开源版与企业版的各种疑问，星云仔邀请了双方资深专家，来了一场 battle 式直播，从技术决策、企业 ROI 两大维度，对到底选 NebulaGraph 开源版还是 NebulaGraph 企业版展开辩论，并给出了专业的选型指南。如果你错过了这场精彩的直播，可以阅读本文，了解这两大版本的优势与差异～


在做图数据库选型时，我们总希望能找到一个“标准答案”，一劳永逸地选出那个“最好”的产品。

但当面对 NebulaGraph 这样的 DB-Engines 全球排名第二的开源图数据库，和基于 NebulaGraph 开发的企业级原生分布式数据库时，你会发现，这场对决更像是一场“神仙打架”，难分高下。

而真正的答案，早已藏在你的业务场景、团队能力和长期规划之中。

# NebulaGraph 开源版

## 关于 NebulaGraph 开源版

NebulaGraph 开源版是世界领先的原生分布式图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时。

自 2019 年 5 月开源以来，被多家互联网头部企业竞相采用，广泛应用于金融风控、实时推荐、知识图谱等业务场景。早期采用者包括腾讯、美团、京东、微众银行、小红书、知乎、快手、BOSS 直聘等知名互联网企业。

随着图数据库技术的日益普及以及业务场景的不断发掘，越来越多行业加入了 NebulaGraph 开源社区，包括中国移动、众安保险、Airwallex、BlockSec 等等。

-   官网：[https://www.nebula-graph.com.cn](https://www.nebula-graph.com.cn)
    
-   论坛：[https://discuss.nebula-graph.com.cn](https://discuss.nebula-graph.com.cn)
    
-   GitHub：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)
    
-   技术交流群：搜索微信号 NebulaGraphbot，星云仔邀请你进群
    

## 选择 NebulaGraph 开源版

选择开源版 ，就像是选择了一片充满无限可能的森林。你手握源代码这张地图，可以自由探索每一条小径，甚至开辟新路。这种深度可控带来的，是极大的灵活性和自主权。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-1.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-2.png)
对于技术实力雄厚、追求极客的团队来说，开源版的魅力是无法抗拒的。零许可证费用意味着极低的启动门槛，让你的想法可以快速落地验证。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-3.png)

开放的社区让你能与全球的开发者直接交流，技术视野往往更广阔，能紧跟最前沿的技术趋势。

更重要的是，你完全避免了供应商锁定的风险，技术路线可以随着业务需求灵活调整，未来的退出成本极低。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-4.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-5.png)
正如那句名言："Talk is cheap, show me the code", 开源版的透明，构建了最坚实的信任基础。

京东、阿里、美团、网易等大型互联网公司基于开源版构建的成熟案例，也充分证明了 NebulaGraph 开源版在高并发、复杂场景下的强大实力。

# NebulaGraph 企业版

## 关于 NebulaGraph 企业版

NebulaGraph 企业版原生分布式数据库，面向企业、机构，更快更稳更易用。

企业版有丰富的企业级特性，满足多业务场景需求，全面支持信创，全项通过可信数据库产品能力测试，并提供 SLA 服务支持，专业团队提供交付实施，并支持公有/私有化的部署方式，企业用户可以按需选择，轻松享受更便捷的一站式图数据库体验。

## 选择 NebulaGraph 企业版

选择 NebulaGraph 企业版，则像是入住了一座由顶级建筑师精心打造的现代化大厦。你不必关心地基有多深、管线如何铺设，只需专注于如何在这个稳定、安全、功能齐全的空间里，高效地开展你的业务。

NebulaGraph 企业版所做的，正是将 NebulaGraph 开源版的“优质原材料”，加工成稳定、安全、可靠、易于大规模部署的“工业成品”。这对于绝大多数追求业务稳定性的企业而言，价值巨大。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/vip-1.png)
企业版提供了明确的 SLA 保障，通过了各项合规与信创认证，内置了细粒度的权限管理、审计日志和全链路加密等企业级安全特性，让你在合规道路上后顾无忧。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/vip2.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/vip-3.png)
在性能上，企业版经过了更深度的优化，在测试中实现了性能提升 3 倍以上，内存开销降低近 90% 的惊人表现，这意味着更低的硬件成本和更强的业务支撑能力。

此外，官方提供的专业交付、培训和技术支持，能将你的团队从复杂的基础设施运维中解放出来，真正聚焦于业务创新，从而在长期范围内实现更可控、更优的总体投资回报。

# 选型指南
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/how-to-choose.drawio-2.png)

那么，究竟该如何抉择？与其纠结于哪个更好，不如回归本质，审视自身：

**1\. 你的业务需求是什么？**

如果你的业务场景对图数据库的功能需求较为标准，并发和数据量在可预估的范围内，且不要求企业级的监控、审计等高阶功能，NebulaGraph 开源版就足以支撑。反之，如果你的业务是像实时风控、供应链关系追溯等需要处理极端并发、复杂深度查询、并具备全面可观测性的核心场景，NebulaGraph 企业版所提供的完整功能栈和性能保障则至关重要。

**2\. 你的团队技术能力如何？**

如果你的团队有强大的运维和源码级定制能力，享受从零到一的构建过程，NebulaGraph 开源版是你的绝佳舞台。反之，如果你的团队希望更专注于业务逻辑，不愿在底层基础设施上投入过多精力，NebulaGraph 企业版能让你事半功倍。

**3\. 你的业务对稳定性和安全性的要求有多高？**

如果你的业务处于金融、政务等对稳定、安全、合规有严苛要求的领域，NebulaGraph 企业版提供的 SLA 保障和全面信创支持即是刚需。而对于尝试性项目或内部工具，开源版的灵活性和低成本则更具吸引力。

**4\. 你的长期规划是什么？**

是希望快速试错、小步快跑，还是计划打造一个需要长期服役、持续扩展的核心系统？前者或许更适合轻量级的开源起步，后者则更需要长期、稳定、专业的企业级支持。

归根结底，NebulaGraph 开源版与 NebulaGraph 企业版并非站在对立面，而是服务于不同阶段、不同需求用户的最佳实践方案。


# 合适的，才是最好的

读到这里，聪明的你一定 get 了重点：选 NebulaGraph 开源版 还是NebulaGraph 企业版，没有标准答案，所谓的 battle 也只是在还原大家在选型时的心路历程。

到底怎么选，取决于哪一个版本最适合你的业务场景，同时团队的定制开发能力，也会影响选型结果。

如果你参照了上述选型指南还是拿不定主意，可以先参照详细的文档，部署上手 NebulaGraph 开源版，尝试把它落地生产，在实践中再结合业务需要考虑是否升级为企业版

文档：[https://docs.nebula-graph.com.cn/3.8.0/](https://docs.nebula-graph.com.cn/3.8.0/)

**无论怎么选，都祝大家在图的世界里玩得开心～**

 NebulaGraph 开源版与企业版产品对比、选型参考

NebulaGraph 开源版与企业版选型指南

# 一、精准测试介绍

## 什么是精准测试？

目前业内尚未形成统一的精准测试实践方案，对其也有多种定义：

（1）精准测试是一套计算机测试辅助分析系统。精准测试的核心组件包含的软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统，这些功能完整的构成了精准测试技术体系。

（2）精准测试是一种测试方法，旨在通过优化测试过程和测试结果，提高软件质量和可靠性。该测试方法结合了自动化和手动化测试技术，以尽可能地覆盖所有的功能和边缘情况，从而减少潜在的缺陷和错误。

## 为什么要做精准测试？

精准测试是为了解决测试的质量和效率问题。

传统测试主要依赖测试人员的自身经验结合具体需求，分析出可能涉及的功能模块以和受影响的功能模块，从而评估出测试范围。如果想提高精准度，则需要沉浸到代码中去寻找答案，不仅提高了人力成本，更是对测试同学提出了更高的要求，更不适用于敏捷迭代中。

## 常见的精准测试方案

精准测试核心有两方面：精准推荐（用例推荐、接口、方法等）、测试度量（度量代码被测情况即代码覆盖率）

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph%20in%20Dewu/dewu-1.webp)


# 二、得物精准测试平台介绍

得物精准测试平台主要负责推荐精准测试范围，减少盲测、漏测、冗测现象。并将 “精准推荐 \+ 用例执行 \+ 结果度量”结合形成有机整体，在测试前、测试中、测试后帮助质量团队保质量、提效率。

目前平台已提供服务端 Java/Golang 应用和前端 H5 应用的精准推荐能力。

相比于上文提到的精准测试的定义，其实我们更关注它能给我们带来什么帮助，我们期望精准测试实现以下目标：

-   推荐测试范围，减少盲测、漏测、冗测，降低上线风险，提高测试准度和效率
    
-   测试前：评估影响面（增量影响面，风险影响面（如：资损、核心等），自动跑用例，前置发现问题
    
-   测试中：暴露未测代码，降低漏测风险，引导测试方向
    
-   测试后：度量测试覆盖度，找出卡点，保证上线质量
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph%20in%20Dewu/dewu-2.webp)



# 三、得物精准推荐平台的实现方案

得物精准测试平台主要由“精准测试平台”和“推荐引擎（链路分析器、差异分析器、知识库、推荐引擎）”两部分构成。

整体思路是建立由“代码行”反推“代码方法”并逆向追踪“API接口”，以“API接口”为枢纽，推荐“自动化用例、功能用例、资损用例等内容”的精准推荐体系。

我们建立完链路分析器后，会输出完整的方法调用链原数据和 API 入口方法标记信息，即建立了方法与方法、方法与类、类与类、类与接口（interface）、接口（interface）与接口（interface）之间的第一层关系，如：当前方法调用了哪些方法以及当前方法被哪些方法调用了。

但仅有原数据还不能进行变更接口推荐，因为原数据中只维护了一层调用关系，需要借助图数据库来把这些原数据串成一张调用链关系网。

## 为什么是图数据库？

一方面，由于得物精准测试平台“服务端”推荐技术底层是依赖“方法调用链”的，需要提供多版本推荐和实时查看能力。

另一方面，热点应用总方法量大、方法调用关系复杂、应用数量多、代码版本多、链路收集频率高，传统关系型数据库无法满足这种复杂场景，所以需要寻找一款合适的数据库。

经过调研，得物最终选择使用 NebulaGraph 图数据库来作为底层存储库。

## NebulaGraph

“图”在人们的日常生活中出现的频率非常高，开心时发个靓照到朋友圈、网购时看完卖家秀再去评论区看看买家秀，这些都涉及到“图”，也许你想象的图是这样的 ↓↓↓

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph%20in%20Dewu/dewu-3.webp)

但 NebulaGraph 的“图”并非日常生活中常指的“图”。日常说的图一般指的的图片（Image），这里所说的图（ Graph）其实是一种“关系图”，更侧重体现事物之间的关系。

一张图（Graph）由一些小圆点（称为顶点或节点，即 Vertex 或 Node）和连接这些圆点的直线或曲线（称为边，即 Edge 或 Relationship）组成。

用 NebulaGraph 探索《权力的关系》人物关系图谱，最终呈现效果这样的 ↓↓↓

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph%20in%20Dewu/dewu-4.webp)


NebulaGraph 是一款开源的分布式高性能图数据库，在 DB-Engines 排名中位列全球图数据库第二，专门用于存储和处理巨大规模的图数据，擅长处理千亿节点万亿条边的超大规模数据集，并且提供毫秒级查询：

-   采用了分布式架构，将图数据分片存储在多个服务器上，以实现水平扩展和高可用性
    
-   提供了丰富的功能，包括顶点和边的属性和索引管理、多层次的图模型、高效的图遍历算法等
    
-   支持查询语言 Cypher、GQL、nGQL
    

## 得物 NebulaGraph ORM

由于 NebulaGraph 对于 Python 没有提供符合我们预期的 ORM 库，返回的结果是原生的数据格式，使用起来比较麻烦，所以我们自研了轻量级的 NebulaGraph ORM.

我们的精准测试方法的调用链中，主要涉及到 2 种点类型和 4 种边类型，将方法和类（类或接口）设计成 2 种点类型，将方法与方法、类与类、方法与类、变更方法与类这四种关系设计成“边类型”，具体模型定义如下：

### class JMethodTag(Tag)：Java 方法-点类型，存储方法的相关属性信息

```
class JMethodTag(Tag):
    """
    Java方法-点类型
    """
    __NAME_PREFIX__ = 'tjm_'
    __VID_PREFIX__ = 'tjm_'   # vid前缀
    vid = Vid('vid', String, nullable=False, comment='点ID')
    name = Field('name', String, nullable=False, comment='简称')
    sign = Field('sign', String, nullable=False, comment='签名(全称)', index_len=50)
    type = Field('type', String, default='', nullable=False, comment='方法类型(method,constructor,static,get_set,field)')
    pkName = Field('pkName', String, default='', nullable=False, comment='包名')
    abs = Field('abs', Bool, default=False, nullable=False, comment='是否是抽象类')
    api = Field('api', Bool, default=False, nullable=False, comment='是否是API接口', index_len=None)
    aPtl = Field('aPtl', String, default='', nullable=False, comment='接口协议(http,dubbo,grpc)', index_len=20)
    aPath = Field('aPath', String, default='', nullable=False, comment='API接口路径(http: /xx/xx, dubbo: com.xx.xx.Cxx::mxx, /grpc.CntCenterService/MGetTrendInfo)', index_len=100)
    cName = Field('cName', String, default='', nullable=False, comment='所属类简称')
    cSign = Field('cSign', String, default='', nullable=False, comment='所属类签名', index_len=50)
    cType = Field('cType', String, default='', nullable=False, comment='所属类类型(class,interface,annotation,enum,unknown)')
    parNames = Field('parNames', String, default='', nullable=False, comment='参数名(多个";"分割)')
    parTypes = Field('parTypes', String, default='', nullable=False, comment='参数类型名(多个";"分割)')
    retType = Field('retType', String, default='', nullable=False, comment='返回类型名')
    calls = Field('calls', String, default='', nullable=False, comment='调用哪些方法调用(多个";"分割)')
    usages = Field('usages', String, default='', nullable=False, comment='被哪些方法调用(多个";"分割)')
    sLine = Field('sLine', Int, default=0, nullable=False, comment='开始行(从1开始)')
    eLine = Field('eLine', Int, default=0, nullable=False, comment='结束行')
    zsScan = Field('zsScan', String, default='', nullable=False, comment='资损字段')

```

### class JClassTag(Tag)：Java类-点类型，存储类/接口的相关属性信息

```
class JClassTag(Tag):
    """
    Java类-点类型
    """
    __NAME_PREFIX__ = 'tjc_'
    __VID_PREFIX__ = 'tjc'   # vid前缀
    vid = Vid('vid', String, nullable=False, comment='点ID')
    name = Field('name', String, nullable=False, comment='简称')
    sign = Field('sign', String, nullable=False, comment='签名(全称)', index_len=50)
    type = Field('type', String, default='', nullable=False, comment='类类型(class,interface,annotation,enum,unknown)')
    pkName = Field('pkName', String, default='', nullable=False, comment='包名')
    abs = Field('abs', Bool, default=False, nullable=False, comment='是否是抽象类')
    dApi = Field('dApi', Bool, default=False, nullable=False, comment='是否是dubbo接口类')
    dInf = Field('dInf', String, default='', nullable=False, comment='dubbo接口interface值')
    hPrefix = Field('hPrefix', String, default='', nullable=False, comment='http接口路径前')
    faces = Field('faces', String, default='', nullable=False, comment='被我实现的接口(多个";"分割)')
    impls = Field('impls', String, default='', nullable=False, comment='实现我的接口(多个";"分割)')
    p = Field('p', String, default='', nullable=False, comment='我继承的父类')
    subs = Field('subs', String, default='', nullable=False, comment='继承我的子类(多个";"分割)')
    sLine = Field('sLine', Int, default=0, nullable=False, comment='开始行(从1开始)')
    eLine = Field('eLine', Int, default=0, nullable=False, comment='结束行')
    zsScan = Field('zsScan', String, default='', nullable=False, comment='资损字段')

```

### class JClassClassEdge(Edge)：Java类->类-边类型

```
classJClassClassEdge(Edge):
"""
    Java类->类-边类型
    """
    __NAME_PREFIX__ = 'ejcc_'

    FACE_RELATION = 'face'
    PARENT_RELATION = 'parent'

    src_vid = Vid('src_vid', String, nullable=False, comment='起始点ID')
    dst_vid = Vid('dst_vid', String, nullable=False, comment='目的点ID')
    relation = Field('relation', String, default='', nullable=False, comment='类->类关系(face: 我实现的接口, parent: 我的父类)')

```

### class JMethodMethodEdge(Edge)：Java方法->方法-边类型

```
classJMethodMethodEdge(Edge):
"""
    Java方法->方法-边类型
    """
    __NAME_PREFIX__ = 'ejmm_'

    CALL_RELATION = 'call'
    REWRITE_RELATION = 'rewrite'
    HEAVY_LOD_RELATION = 'heavy_load'

    src_vid = Vid('src_vid', String, nullable=False, comment='起始点ID')
    dst_vid = Vid('dst_vid', String, nullable=False, comment='目的点ID')
    relation = Field('relation', String, default='', nullable=False, comment='方法->方法关系(call: 调用, rewrite: 重写，heavy_load：重载)')
    api = Field('api', Bool, default=False, nullable=False, comment='src(开始)点是否是接口')

```

### class JMethodClassEdge(Edge)：Java方法->类-边类型

```
classJMethodClassEdge(Edge):
"""
    Java方法->类-边类型
    """
    __NAME_PREFIX__ = 'ejmc_'

    MYC_RELATION = 'myc'

    src_vid = Vid('src_vid', String, nullable=False, comment='起始点ID')
    dst_vid = Vid('dst_vid', String, nullable=False, comment='目的点ID')
    relation = Field('relation', String, default='', nullable=False, comment='方法->类关系(myc: 我的类)')

```

### class JChangeClassMethodEdge(Edge)：Java变更(类->方法)-边类型

```
classJChangeClassMethodEdge(Edge):
"""
    Java变更(类->方法)-边类型
        - 推荐接口任务产生的增量方法和类
    """
    __NAME_PREFIX__ = 'ejccm_'

    src_vid = Vid('src_vid', String, nullable=False, comment='起始点ID')
    dst_vid = Vid('dst_vid', String, nullable=False, comment='目的点ID')
    contrast_v = Field('contrast_v', String, default='', nullable=False, comment='对比版本(commit)')

```

### 调用链展示

![image|690x195](upload://nOGphUAaRMSs093EnZeDPzs9Kbs.jpeg)


![image|690x448](upload://aUiGnhqJmlGXcvB6cNc5mWrHQRB.jpeg)


## 使用 NebulaGraph 获取调用链信息

### 获取到变更类下面的方法

（先获取目标点ID，再根据点ID查询点数据性能最佳），查询语句如下：

MATCH (v:{tag\_name}) WHERE v.{tag\_name}.cSign IN \[{cSignsStr}\] RETURN id(v);

MATCH (v:{tag\_name}) WHERE id(v) IN \[{tag\_name\_vid\_str}\] RETURN v;

使用点 ID 根据“JMethodMethodEdge 边”遍历找出调用链中是接口的入口方法

这里使用 GO 语句，并设置 1 到 50 跳来遍历（即从原始点开始找 50 层关系，如：a() -> b() -> c()，则a()到b()是 1 跳，b()到c()是 1 跳，a()到c() 是 2 跳

GO 1 TO 50 STEPS FROM {vid\_str} OVER {edge\_name} REVERSELY WHERE properties(edge).api == true YIELD DISTINCT src(edge);

### 查找增量类和增量方法

通过“JChangeClassMethodEdge 边”的属性“contrast_v”的值来判断哪些是目标增量边，根据增量边的起始点 ID 和结束点 ID 来获取最终的增量方法和增量类

MATCH (v\_c:{c\_tag\_name})-\[e:{ccme\_name}\]->(v\_m:{m\_tag\_name}) RETURN e, v\_m;

如：获取增量变更方法

```
defget_add_java_method(self, **kwargs) -> ResponseResult:
"""获取增量变更方法"""
    app_name = kwargs.get('app_name')
    current_version = kwargs.get('current_version')
    contrast_version = kwargs.get('contrast_version')
    zs_scan = kwargs.get('zs_scan')
    ...
    tag_handler = TagHandler(app_name, current_version)
    c_tag_name = tag_handler.get_tag_name(JClassTag)
    m_tag_name = tag_handler.get_tag_name(JMethodTag)
    edge_handler = EdgeHandler(app_name, current_version)
    ccme_name = edge_handler.get_edge_name(JChangeClassMethodEdge)

# 模版 MATCH (v_c:tag_name1)-[e:edge_name]->(v_m:tag_name2) RETURN e, v_m;
    n_gql = f"MATCH (v_c:{c_tag_name})-[e:{ccme_name}]->(v_m:{m_tag_name}) RETURN e, v_m;"
    _res = edge_handler.session.execute_json(n_gql)
if type(_res) is bytes:
        _res = _res.decode(encoding='utf-8')
# Nebula Graph Studio前端客户端工具报【-1009:SemanticError: PlanNode(Start) not support to append an input.】错是客
# 户端版本不匹配，代码里可以支持
    res: dict = json.loads(_res)
if res['errors'][0]['code'] != 0:
        err = f"{res['errors'][0]['code']}:{res['errors'][0].get('message')}"
return ResponseResult.fail_response(message='获取增量变更方法失败', err=err)

# 筛选&组装数据
    raws = res['results'][0]['data']
    res_class_zs = []
    res_method_rows = []
    class_zs_dict = {}
for raw in raws:
        _inner_row = raw['row']
# 对比版本commitID只取前8位
if _inner_row[0]['contrast_v'][:8] == contrast_version[:8]:
            _new_row = {
"meta": [{
"type": "vertex",
"id": raw['meta'][1]['id']
                }],
"row": [_inner_row[1]]
            }
            res_method_rows.append(_new_row)

    method_tags: List[JMethodTag] = tag_handler.convert_raw_to_tag_model(res_method_rows, JMethodTag)

# 获取类的资损标签
if zs_scan and method_tags:
        cSign_set = set()
# 获取增量类
for method_tag in method_tags:
            _fsr_cSign = String.fsr(method_tag.cSign)
if _fsr_cSign notin cSign_set:
                cSign_set.add(_fsr_cSign)
        n_gql = f'MATCH (v:{c_tag_name}) ' \
f'WHERE v.{c_tag_name}.zsScan != "" AND v.{c_tag_name}.sign IN [{",".join(cSign_set)}] ' \
f'RETURN v.{c_tag_name}.sign, v.{c_tag_name}.zsScan;'

        _res = edge_handler.session.execute_json(n_gql)
if type(_res) is bytes:
            _res = _res.decode(encoding='utf-8')
# 户端版本不匹配，代码里可以支持
        res: dict = json.loads(_res)
if res['errors'][0]['code'] != 0:
            err = f"{res['errors'][0]['code']}:{res['errors'][0].get('message')}"
return ResponseResult.fail_response(message='获取增量变更方法失败', err=err)
        raws = res['results'][0]['data']
for raw in raws:
            _row = raw['row']
            class_zs_dict[_row[0]] = {
'class_sign': _row[0],
'zs': _row[1]
            }

    class_infos = []
    class_tag_info_dict = {}
    class_n = 0

for method_tag in method_tags:
        class_tag_info = class_tag_info_dict.get(method_tag.cSign)
if class_tag_info isNone:
            class_tag_info = class_tag_info_dict[method_tag.cSign] = {
'class_sign': method_tag.cSign,
'class_zs': ''if class_zs_dict.get(method_tag.cSign) isNoneelse class_zs_dict.get(method_tag.cSign)['zs'],
'methods': []
            }
            class_infos.append(class_tag_info)
            class_n += 1

# 转化成JSON
        _method_tag = method_tag.__dict__.copy()
        _calls = _method_tag['calls']
        _method_tag['calls'] = _calls.split(';') if _calls else []
        _usages = _method_tag['usages']
        _method_tag['usages'] = _usages.split(';') if _usages else []
        class_tag_info['methods'].append(_method_tag)

return ResponseResult.success_response(data={'class_n': class_n, 'method_n': len(method_tags),
'class_infos': class_infos})

```

# 四、总结与展望  

精准测试是一套有效提高软件测试质量和效率的技术体系，可以有效解决传统测试中的盲测、漏测、冗测等现象提升测试效率和准确性，前置暴露风险，保障上线质量。

**精准测试从理念走向落地的关键，在于能否构建一条高效、可靠的“数据驱动链”，而 NebulaGraph，正是锻造这条链条的核心引擎** 。凭借其卓越存储与关联查询能力，NebulaGraph 将原本散落、静态的代码方法，编织成一张动态、立体的调用关系网。

未来，我们期待能与 NebulaGraph 开源社区更紧密地协同共建，将得物在复杂业务场景下的实战经验反哺社区，共同推动图技术的创新与应用。

---
**本文转自「得物技术」公众号⬇️**

[得物精准测试平台设计与实现](https://mp.weixin.qq.com/s?__biz=MzkxNTE3ODU0NA==&mid=2247534806&idx=1&sn=5d82dcb3ef99594da8d413fe80e9775e&scene=21#wechat_redirect)

**推荐阅读**

[NebulaGraph 全球图数据库排名第二](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21#wechat_redirect)

[复杂关系场景，图数据库为何是首选？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515828&idx=1&sn=eb22a1dd1b4f5ca4c1cf45dd20f6a543&scene=21#wechat_redirect)

[开源版、企业版怎么选？产品对比+选型指南奉上～](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516028&idx=1&sn=d4ee00718421cb63c480663e6f39640e&scene=21#wechat_redirect)

得物基于 NebulaGraph 构建精准测试平台

得物 App：基于 NebulaGraph 的精准测试平台

> 关于作者：兰后，平安壹账通，数据产品经理。6 年金融行业咨询工作经验，具备大数据分析挖掘、 数据中台、数据治理等方面专业知识。负责为金融行业客户提供以 AI 产品和数据中台为核心的解决方案和咨询服务，协助客户开展数字化转型规划和设计工作。




两年前，为了给数据资产管理平台构建数据血缘功能，我被前老板“扔”去研究图数据库，熬了几个大夜写完调研报告，以为这事就这么过去了。

没想到，命运的齿轮再次转动。最近在为一家保险巨头做数字化转型时，客户冷不丁地问我：“能不能用图数据库搞点创新，让我们在集团内部的科技比赛里拿个奖？”

于是，我重新翻出这份“压箱底的宝藏”…...

#  一、选型调研

## （一）粗筛

结合数据库选型经验，我们先从 DB-Engines 排名中分别筛选出国内外排名第一的 NebulaGraph 和 Neo4j.

## （二）细筛

我们从优缺点、使用成本、是否适配信创、性能等方面，对 Neo4j、NebulaGraph 进行进一步选型调研。

**综合考虑信创和保险同业案例等方面，建议优先选择 NebulaGraph.**


|维度 | Neo4j | NebulaGraph|
|--- | --- | ---|
|优缺点 | 1. 优点：成熟的图数据库，功能全面，Cypher 语法友好，生态丰富（Bloom 算法库）； 2. 缺点：社区版仅支持单机，企业版扩展受限，写性能依赖主节点，开源受限 | 1. 优点：分布式架构，水平扩展，支持万亿边，性能强劲（导入/查询均为业界领先），对大数据生态兼容； 2. 缺点：生态相对年轻，上手难度略高，高级功能需企业版|
|是否开源 | 部分开源：社区版 GPL v3 开源，企业版闭源需商业授权 | 完全开源：源码全开源，企业版增强功能收费|
|信创兼容 | 不兼容，无国产平台官方认证，主要支持 x86 Linux 环境 | 已通过华为鲲鹏、飞腾、海光、兆芯等国产 CPU 和操作系统兼容认证，全面支持信创，可自行编译安装包，以确保符合特定的软硬件环境，实现最佳性能|
|保险行业案例 | 1. 国外保险公司构建理赔知识图谱检测欺诈； 2. 国内案例较少 | 1.众安保险：风控反欺诈（手机号异常热点检测） 2.泰康在线：构建客户关系图用于精准推荐。支持理赔反欺诈、客户画像、裂变营销 （主要参考了两大保险行业案例，更多用户案例请查看本文文末链接）|
|权威性能测评 | 1. 在 LDBC SNB 基准测试中表现优异 2. 小规模图查询较优 | 1. 在 10 亿边测试中，单跳查询2ms（Neo4j 需数十秒）；多跳查询延迟低于 5 秒（Neo4j 数百秒） 2. 导入性能和扩展性均优于 Neo4j|
|适用场景 | 1. 深度图分析：Cypher 语言对复杂路径表达更简洁 2. 开发测试场景：社区版免费且生态成熟 3. 事务一致性要求极高：如金融交易反欺诈 | 1. 需支持 10 亿+ 级节点规模：如全国级供应链网络 2. 信创改造强需求：国产芯片/0S全栈认证 3. 高并发实时查询：如 IoT 设备状态追踪|


### 1. 架构与扩展能力

|维度|Neo4j|NebulaGraph|
| --- | --- | --- |
|架构类型|单机/因果集群（企业版支持水平扩展）|分布式存储计算分离架构（支持 10 亿+ 节点）|
|扩展能力|垂直扩展为主，企业版支持读写分离集群|水平扩展（存储/计算节点独立扩容）|
|信创适配|需手动验证 JDK/0S 兼容性（如达梦适配）|完成鲲鹏/麒麟/统信全栈兼容认证|

### 2. 数据模型与查询能力

|维度|Neo4j|NebulaGraph|
| --- | --- | --- |
|核心模型|原生属性图，Schema 可选|属性图模型，支持多跳索引与动态 Schema|
|查询语言|Cypher，专为图设计，复杂路径表达更灵活|nGQL，类 SQL 语法，支持图遍历 + SQL 混合查询|
|事务支持|单机强一致，企业版支持分布式事务|支持 ACID，Raft 协议保障分布式事务|

### 3. 大数据生态集成

|维度|Neo4j|NebulaGraph|
| --- | --- | --- |
|Hive对接|需通过 ETL 工具（如Apache NiFi）同步数据|提供 Spark Connector 实现 Hive 联邦查询|
|实时计算|Spark Connector 需额外转换图结构|原生集成 Flink CDC，支持毫秒级数据同步|
|数据质量|依赖外部工具实现 ETL 质量校验|支持 Schema 约束与数据版本控制|

### 4. 性能与适用场景

|维度|Neo4j|NebulaGraph|
| --- | --- | --- |
|写入性能|单机批量导入优化（约10kTPS）|分布式批量导入（TPS 可达 100k+）|
|查询场景|深度递归查询（如社交传播链挖掘）|高并发多跳查询（如供应链 5 层路径分析）|
|适用场景|实时推荐系统、知识图谱构建|金融风控、工业物联网、国产化替代|

### 5. 成本与运维

|维度|Neo4j|NebulaGraph|
| --- | --- | --- |
|授权费用|社区版免费，生产环境需商业授权|Apache 2.0开源协议（无商业授权限制）|
|运维寒杂度|单机部詈简单，集群需专业DBA支持|依赖Kubernetes管理分布式集群|
|国产化成本|-|预置信创适配清单（含JDK/0S兼容脚本）|

# 二、产品简介

## （一）Neo4j（3.4 版本）

Neo4j 是由 Neo4j Inc. 开发的原生图数据库，基于 Java 实现，采用事务型存储引擎和图数据模型。社区版仅支持单机部署，企业版支持多节点集群（需多数节点参与写入）。

### 1. 架构

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


### 2. 原生图存储引擎

基于节点-关系连接，支持无索引邻接访问（index-free adjacency），极大提高图遍历性能。

### 3. 产品特性

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

### 4. 数据模型

原生图数据库，采用属性图模型（Property Graph），节点（Node）、关系（Relationship）、属性（Property）构成核心元素。

### 5. 查询语言

* 使用 Cypher，语法简洁、强语义，有 OpenCypher 项目支持。

* 可视化与工具链。

* 提供 Neo4j Bloom 可视化工具、Graph Data Science 库、Neo4j Aura 云服务支持等。

## （二）、NebulaGraph（通用）

NebulaGraph 是在 2019 年推出的图数据库产品，底层数据模型是属性图，基于C++ 语言编写。采用 Apache 2.0 开源授权，强调性能、横向扩展与国产兼容特性。

### 1. 架构

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


采用存储计算分离的设计，包括三个核心组件：

* Meta Service：管理集群元数据和 schema 等。

* Storage Service：有状态节点负责持久存储，支持 RocksDB，使用 Raft 共识确保一致性。

* Graph (Query) Service：无状态节点处理查询请求，支持水平扩展。

### 2. 产品特性

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


* 数据模型：采用属性图模型（Property Graph），兼容图计算和图存储分离。

* 查询语言：使用 nGQL，类 SQL/Cypher 结构，并部分兼容 OpenCypher，方便 Neo4j 用户迁移。

* 生态系统：集成 Nebula Dashboard（可视化管理）、Nebula Studio（交互查询）、Nebula Algorithm（图算法库）。

---

**参考资料**

1、DB-Engines 图数据库排名

2、Neo4j 官方使用文档

3、NebulaGraph 官方使用文档

4、LDBC-SNB 数据集：关联数据基准委员会提供的评测数据集，包含 26 亿顶点、177 亿关系

5、NebulaGraph 同花顺选型测评

**相关阅读**

[NebulaGraph 全球图数据库排名第二](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21#wechat_redirect)

[复杂关系场景，图数据库为何是首选？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515828&idx=1&sn=eb22a1dd1b4f5ca4c1cf45dd20f6a543&scene=21#wechat_redirect)

[开源版、企业版怎么选？产品对比+选型指南奉上～](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516028&idx=1&sn=d4ee00718421cb63c480663e6f39640e&scene=21#wechat_redirect)

[同花顺知识图谱团队的图数据库选型——消息、基本、技术三面](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515319&idx=1&sn=9a7a900627fda88aa2d98775b168fd35&scene=21#wechat_redirect)

NebulaGraph 与 Neo4j 全方位选型测评