
> 导读：本文整理自 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 赋能淘宝天猫精准营销

> **导读**
> 
> 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 国产化？

作者万佳飞，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 等显著成效。

代码量降低 80%，告别百万工时浪费：NebulaGraph 在京东物流的应用

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

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

# 一、业务痛点

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

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

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

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


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

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

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

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

# 二、NebulaGraph 选型与架构

## （一）Why NebulaGraph？

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

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

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

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

## （二）技术架构

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

1.**数据采集**

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

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

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

2.**数据加工**

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

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

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

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

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

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

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

4.**数据服务**

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

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

# 三、应用实践

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**成果与规划**

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

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

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

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


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

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

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

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

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

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

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

1.**采购决策**

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

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

2.**库存管理**

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


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

3.**智能履约**

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


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

4.**精准交付**

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


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

**成果**

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

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

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

#  四、未来规划

## （一）企业级知识库

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


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


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

## （二）智能风控体系

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

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


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

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

# 五、总结

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

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

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

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

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

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

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



# 一、背景

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

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

# 二、NebulaGraph 平台架构

## （一）架构概览

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

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

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

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

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

##  （二）隔离级别

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


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

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

##  （三）部署策略

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

1. 单机房部署策略

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


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

2. 三中心部署策略

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


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

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

3. 跨域多活部署

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


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

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

##  （四）部署成效

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


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

# 三、NebulaGraph 客户端改造

##  （一）读写分离

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


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

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

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

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

##  （二）故障切换

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


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

##  （三）Session 管理

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


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

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

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

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

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

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

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

# 四、调优实践

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

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

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

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

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

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

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

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

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

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

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

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

# 五、未来展望

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


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

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

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

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

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

---

推荐阅读⬇️

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

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

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

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

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


# 一、Airwallex 空中云汇 

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

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

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

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


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

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

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

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


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

# 二、NebulaGraph 的应用场景

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 三、Why NebulaGraph？


# **（一）背景**


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

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

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


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

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

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

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

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


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

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

# **（三）NebulaGraph 选型**

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

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

# 四、系统架构设计

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


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


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

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

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

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

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

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

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

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

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

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

### **系统架构**


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


**1. 数据写入**

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

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

**2. Schema First**

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

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

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

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

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

**2. 规则引擎**

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

**3. 业务服务**

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

**4. 可视化**

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


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


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

1. Schema复杂且易变

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

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

2. 数据逻辑变更与清洗

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



###  **应对策略**



1. 一处定义，动态生成

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

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

2. TTL + 全量写入

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

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


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

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

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

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

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

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

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

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


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

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

# 五、未来展望

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

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

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

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

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

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

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




# **一、引言**

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

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

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

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

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

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

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

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

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


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

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

# **二、整体架构**

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

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


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

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

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

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

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

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

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


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

**管控面**

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

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

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

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

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

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

**运行面**

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

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

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

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

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

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

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

**NebulaGraph 管理台**

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

**SDK 配置管理台**

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

1. 权限最小化

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

* 账号管理：

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

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

2. 管理操作工具化

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

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

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

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

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

**事中拦截**

1. 版本测试与发布评估

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

2. 软删除机制

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

**事后恢复**

1. 快速恢复能力

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

2. 定期快照与备份

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

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

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

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

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


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

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

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


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

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

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


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

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

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

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

双云切换流程

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

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

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

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

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

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

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

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

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

# **七、未来规划**

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

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

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

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

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

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

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

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


> 导读：奇富科技，作为中国领先的人工智能驱动的信贷服务平台，面临着业务快速扩张和数据量激增的挑战。为了提升金融服务的安全性和效率，自 2020 年起，奇富科技选择了 NebulaGraph 作为其金融风控体系的图数据解决方案，包括反欺诈、图挖掘、图+大模型、策略血缘、大数据血缘等多个场景。本文整理自奇富科技风控平台技术负责人@李权，在 NebulaGraph 深圳站 nMeetup 上的演讲。

‍‍‍‍

# 一、公司背景

奇富科技（原 360 数科）2016 年成立，2018 年在纳斯达克上市，2022 年在香港挂牌上市，帮助金融机构为广大小微企业和个人用户提供普惠金融服务。奇富科技拥有 2.5 亿注册用户、5500 万授信用户，并与 162 家金融机构建立了合作关系，凭借智能服务、AI研究及应用、安全科技，赋能金融机构提质增效，助推普惠金融高质量发展，让更多人享受到安全便捷的金融科技服务。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/gs.jpg)


# 二、业务背景与图数据库迁移


## 1.业务背景

随着业务量激增，奇富科技的关系数据量级迅速增长，对安全欺诈、信用风险的严格管控，对图数据库的性能和可靠性也提出了更高要求。公司经历了从基于 Neo4j 的单机部署到 NebulaGraph 的分布式存储架构做完整风控体系的升级历程。

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


## 2.图数据迁移史


***2017 年 6 月***：使用 **Neo4j**, 适用于业务量较小时的轻便部署。当时使用的是非商业单机版，随着数据量的增长，单机部署模式的局限性显现：一是缺乏主备服务，二是集群部署能力受限，有单点故障的风险。

***2018 年 3 月***：使用** AgensGraph**, 它是基于 PostgreSQL 实现一主多从架构。当业务数据量增长至 10 亿点和 60 亿边时，AgensGraph 无法满足业务需求：其数据存储是非分布式的，数据都存在一台机器上；数据量越大，查询性能越低，严重影响了查询效率。

***2019 年 8 月***：为解决存储能力和查询性能的痛点，更换为 **JanusGraph**. 它的数据存储基于 HBase, 查询基于 ES, 实现了分布式数据存储和水平扩展。使用快一年后遇到了两个主要问题：首先，作为实时风控系统，业务需要短时间内计算用户特征并将其应用于策略执行，但是 JanusGraph 在查询关系网时性能不足，导致特征计算组装缓慢，影响了业务流程。其次 JanusGraph 的查询无法下推，需要先通过 ES 索引到具体节点，再从 HBase 查询所有数据，这导致了巨大的网络传输开销。此外，当查询触及超级节点时，由于底层缺乏过滤机制，需要从 HBase 查询并加载所有相关数据到内存中进行计算和过滤。这些问题促使我们寻求更优的图数据库解决方案。

***2020 年 6 月***：为了解决刚提到的 IO 无法下推和超级节点的问题，我们开始寻找新的图数据库解决方案。这时候 **NebulaGraph** v1.0 发布，我们邀请了 NebulaGraph 的同学到奇富科技分享，了解到 NebulaGraph 是一个主从分布式的存储架构，支持存算分离和信息扩容。与 JanusGraph 相比，不仅可以大大降低我们的数据存储成本，还能解决 IO 无法下推和超级节点的问题。另外 NebulaGraph 支持我们的一些过滤条件在底层计算的时候就过滤掉，并且通过超级节点底层优化，在底层配置了一个特殊的参数，我们可以设置点关联最大的一个边，或者点的最大数量，去解决超级节点膨胀的问题。因此，我们选择了 NebulaGraph 作为金融风控业务的最佳解决方案。

‍‍‍![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/hs.jpg)

回顾我们图数据库使用和升级的历程，其实就是复盘我们业务发展与扩张，一路发现问题，一路解决问题的过程。



# 三、图平台架构

奇富科技使用 NebulaGraph 构建了一个高效、稳定的图平台架构，以支持金融风控业务及一般业务需求。从 2020 年 6 月开始投入奇富科技多个业务使用，经过四年多的实践， NebulaGraph 已被证明在服务稳定性和查询性能上能够很好地支撑业务发展。



奇富科技的图平台架构从底层到顶层分为以下几个层次：
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/in.jpg)
1. **图数据库层**：部署了两套 NebulaGraph 集群，分别位于机房 A 和机房 B, 实现了跨机房的高可用性。A、B 集群的数据存储量分别达到了 400 亿+ 和 100 亿+。
2. **中间组件层**：包括 Kafka、Spark、GPU 等，用于数据同步和处理。Kafka 用于主从数据同步，而 Spark 和 GPU 则用于大规模数据处理和机器学习任务。
3. **数据挖掘层**：在这一层，我们利用图算法进行数据发现、重要节点、标签传播等。另一方面，会将图数据导入到我们的大数据集群进行机器学习，如图神经网络、模型训练、图特征挖掘等。
4. **业务应用层**：利用 NebulaGraph 支持风控业务，如风险社区、风险节点、B卡评分、逾期评估、反欺诈等，也用于支持一般业务，如大数据血缘、黑名单溯源、特征血缘等。
5. **监控运维层**：使用 Prometheus、CAT、Falcon 和 Nebula-Dashboard 等工具进行监控和运维，确保实时监控系统稳定的运行。


# ‍‍四、NebulaGraph 的应用实践


## 1.反欺诈

我们利用 NebulaGraph 构建了多维度的风控模型，包括设备关联风险、身份信息关联风险、社交关系风险和名单关联风险，使我们能够及时发现团伙作案或传销案件中的异常行为模式。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/f.jpg)
* **设备关联风险**：监控设备使用情况，识别多人短时间内使用同一设备进行申请的异常行为。
* **身份信息关联风险**：检测身份信息的急剧变动，以发现潜在的身份伪冒风险。
* **社交关系风险**：通过分析用户的社交网络，评估用户可能所处的行业，从而侧面评估其信用风险。
* **名单关联风险**：通过用户与风险名单的关联程度，评估用户的风险概率。

同时我们构建了风险传播路径，实现了以下功能：

* 爆发式传播预警拦截：在风险行为呈现爆发式传播时，及时发出预警并进行拦截。
* 风险人库溯源：通过图数据库的查询能力，快速追溯风险行为的源头，实现风险的精准定位。

通过以上方式，NebulaGraph 在反欺诈场景中，帮助我们快速识别和响应欺诈行为，**累计报送涉骗阻断预警 59 万次，拦截潜在被骗者 9.5 万人，帮助用户避免损失 11.35 亿元。**

## 2.图挖掘

图挖掘主要通过两种方式进行：

* **一阶二阶关联聚合**：通过分析客户的直接和间接关联，衍生出图特征指标。这种方法已经帮助公司计算出上千个图指标，这些指标被应用于 100 多个模型和策略中。然而，随着新指标的发掘，其边际收益呈现出递减的趋势。
* **大数据平台结合图算法**：为了克服边际收益递减的问题，我们将图数据同步到 HIVE, 并利用大数据集群运行全图算法，如 PAGERANK（网页排名算法）、LOUVAIN、GAT（图注意力网络）、GNN（图神经网络）等，**帮助公司发现了 92 万个风险社区和超过 100 万个风险节点。**
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/w.jpg)


## 3.图+大模型

通过结合大模型和金融知识图谱，实现了对企业经营变化的快速掌握和深入理解。这一创新方法在处理非结构化数据和提升业务理解方面展现了显著优势。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/tu.jpg)


* **信息提取与情感分析**：我们利用大模型对财报、用户经营数据、图片等非结构化数据进行信息提取，并通过持续的用户对话进行情感分析，识别用户的具体诉求。
* **知识图谱与图计算**：通过过大模型提取的关键信息，进一步对图的点边进行建模，构建了金融知识图谱。这一图谱不仅加深了大模型对业务的理解，而且通过提示词优化和语料训练，使得大模型能帮助我们快速地掌握小微企业的经营变化和行业信息背景，对业务进行全方位的深入理解。

## 4.特征、策略血缘

在特征管理和策略血缘方面的实践，充分利用了图数据库的天然可解释性，为风控领域提供了一种直观且高效的特征追溯和管理方法。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/tz.jpg)

### 特征血缘管理


* **特征变量管理**：我们已经积累了超过 40 万个特征变量，每个特征都有明确的取数来源和加工逻辑，以及应用的业务场景。
* **直观表达**：通过 NebulaGraph, 构建一个直观的表达方式，快速识别每个特征所属的领域和链路，这在传统关系数据库中往往需要多表关联查询，且不够直观。
* **无效特征管理**：NebulaGraph 使得识别和管理无效或需要下线的特征变得更加有效。


### 策略血缘分析


* **变量关系构建**：通过图谱构建了输入变量、中间变量和最终输出变量之间的关系，这对于理解策略的内部计算和结果输出至关重要。
* **影响归因**：当策略输出出现波动时，图谱能够快速进行影响归因分析，帮助团队迅速定位问题原因。


## 5.大数据血缘&应用拓扑‍‍‍‍

在大数据血缘和应用拓扑管理方面，通过 NebulaGraph 实现了对数据资产和工作流的高效监控与管理。不仅提高了数据处理的透明度，还增强了对运维异常的快速响应能力。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/qifukeji/dsj.jpg)

### 大数据血缘


* **数据资产表管理**：我们管理着 8 万张数据资产表，这些表通过每日 1000+ 的离线工作流进行更新和迭代。
* **工作流异常影响分析**：当数据同步出现问题时，可以快速定位受影响的下游表和业务，实现一阶、二阶甚至多阶的链路影响分析。
* **工作流下线依赖检测**：在调整或下线工作流时，评估其对其他工作流或业务的在影响，确保变更管理的安全性。


### 应用拓扑管理

* **应用调用链路拓扑**：通过 NebulaGraph 展示应用间的调用关系，帮助理解和分析应用间的交互和依赖。

* **运维异常根因分析**：在发生运维异常时，NebulaGraph 能我们快速定位问题根源，提高故障恢复的效率。




# 五、未来展望

‍我们未来规划和展望集中在两个主要方向：集成图计算和机器学习解决方案，以及 GraphRAG 研究实践。

目前在图计算和机器学习领域的成本很高，计划利用图的关系建模、结合图算法做计算，再将图计算的结果通过机器学习理解图。如果能整合到一个统一的平台上，能提高效率和降低成本。这样的集成解决方案有利于多个团队更高效地协作，提高业务流程的流畅性。

其次，我们正在探索 GraphRAG 技术，NebulaGraph 也推出了自己的 GraphRAG 服务，希望通过 NebulaGraphRAG 能更深入地利用现有的图数据，结合大模型技术，为业务提供更多的赋能。


奇富科技选择 NebulaGraph 作为其金融风控体系的图数据解决方案，包括反欺诈、图挖掘、图+大模型、策略血缘、大数据血缘等多个场景。

奇富科技 x NebulaGraph｜金融风控最佳解决方案

语势科技‍‍‍‍‍‍

语势科技专注于结合大模型和知识图谱的能力，构建以主题投资理论为核心的 2B 智能投顾平台，核心产品为“主题蜂 [https://themepica.com](https://themepica.com)”。产品体系对标成立于 2003 年的美国 AI 巨头 Palantir。Palantir 初期服务于 FBI/CIA，于 2020 年纽交所上市。



# **前言**

语势科技的产品核心围绕动态本体(Dynamic Ontology)构建，其区别于传统的概念建模方式，强调在事件驱动的背景下，如何快速发现对象之间的关系并动态构建本体并建立关系，以适应当前信息爆炸的背景下数据分析的需求。

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

在产品建设过程中，除了传统的数据处理和分析技术，我们也使用了大模型进行数据处理和分析，因此也难免遇到了使用大模型构建金融服务产品时的一些通用问题。

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

众所周知，大模型的黑盒和幻觉特性来自其原理设计，无法根除。但是，如果能基于现有信息，结合业务分析框架进行推理分析，那就可以从应用层面一定程度上解决可解释等合规问题，因此构建一个分析师可以参与，可结合场景定制的分析推理框架就成为了我们的首要任务。

# **从 Baseline RAG 到 GraphRAG‍‍‍‍**

最初，基于我们在非结构化数据处理的已有框架上进行了改造，引入大模型的 Embedding 结果参与到向量匹配中。但是最终发现，基于大模型的向量检索相比传统方式小幅度提高正确概率，但同样**无法提供确定性答案，且缺乏上下文和解释性。**

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

因此，我们考虑给大模型更多的上下文信息，直接通过大模型的推理来代替本地的向量匹配方式，即 Baseline RAG 的方式。但是效果仍然不够理想，且 **RAG 方案成本高，响应速度不能满足需要。**

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

因为从理论上来讲，大模型是一个概率模型，对世界的表示就是向量。相比而言，知识图谱体现的是人对世界的结构性知识，在实现复杂的推理过程方面应该更具有优势。

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

在 AI 领域，概率模型属于连接主义流派，利用计算机来模拟人类的生理结构，也就是神经网络的路线。包括神经网络在内的深度学习更多的是解决感知层面的问题，比如识别、判断等；

另外一个流派就是符号主义，利用计算机来模拟人类的认知思维，更多的是解决推理层面的问题。由此发展出知识工程、专家系统。知识图谱就是这一类学术思想的延续。

如下图所示，连接主义流派首先伴随 AI 概念诞生而产生，但是遇到瓶颈而推动了符号主义发展。两个流派此消彼长，也已将近几十年。

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

在当下，LLM 如日中天，但是如前边所分析，单纯使用 LLM 并不能很好的解决我们所面临的业务需求，需要将两个流派的技术结合使用。

**“神经”与“符号”的结合有如下几种方案：**

-   **利用神经网络执行符号推理任务**

包括目前流行的图神经网络、图卷积神经网络等。在这类方法中，神经网络基于统计建模从数据中抽象提取出符号，赋予符号对数据噪声的“弹性”并显著减少符号系统的搜索空间，从而加速学习过程。但本质上来说，该类方法中规则被弱化了，即更侧重统计上的推理，而不是逻辑上的演绎推理。

-   **将符号知识注入神经网络**

利用符号系统来支持神经网络学习过程，同时将符号知识纳入训练。其目的是从知识图谱中推导出一般的逻辑规则，例如损失函数设计、进行一些正则化约束等。

-   **融合神经网络与符号系统**

在该方法中神经系统和符号系统扮演着“平等”的角色，神经系统的输出作为符号系统的输入，符号系统的输出又作为神经系统的输入，在迭代中完成两个系统的信息交互，从而实现更深层次的神经符号系统集成。

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

对于初创团队，前边两个方案都涉及到模型的 SFT，时间和开发成本过高，因此我们考虑**选择第三种融合方案，引入知识图谱，使用 GraphRAG 来解决面临的业务问题。**

# **选型过程‍‍‍‍**

既然选择了 GraphRAG 路线，首先要解决的就是图数据库的选型。首先选择了 DB-Engines Ranking 的列表作为备选产品列表。

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

基于我们的实际情况，选择了其中红色圈出的产品进行考察。

同时，设定了一些需要考察的指标。

   **查询语言阵营选择**
    
-   倾向于有商业机构支持的开放标准，因为笔者在多年前做云计算时在 OpenStack 领域的前车之鉴，这一点作为产品在生态圈可持续发展的重要因素，被放在了首位。
    
  **易上手**
    
-   GUI
    
-   玩不死，玩不坏
    
   **易部署管理**
    
-   开箱即用
    
-   具备一定 HA 能力
    
-   监控指标全，易集成
    
-   不需要太多第三方组件支持
    
   **易集成**
    
-   模式设计灵活
    
-   多图支持
    
-   易于和常见开发框架集成
    
-   具备和 LLMs 集成能力和案例支撑
    
-   最好能内置常见文本相关算法库
    
   **性能**
    
-   后边考察的除了性能，就是一个词，**易用**。这一点对于初创团队来讲太重要了。
    

**我们最终选择了 NebulaGraph，原因如下：**

-   **功能完整度高，产品成熟度高**：NebulaGraph 作为一个功能完整且成熟的图数据库，能够提供稳定和可靠的服务，这对接入 GraphRAG 这种需要高效数据处理和分析的技术尤为重要。
    
-   **社区活跃，案例丰富**：一个活跃的社区意味着有更多的资源和支持，丰富的案例也表明 NebulaGraph 在实际应用成绩中得到了成功的验证，可以减少我们的试错成本，加快项目进展。
    
-   **易于集成**：NebulaGraph 支持与 LLMs（Large Language Models）和 Spring 等技术的集成，这表明它具有良好的灵活性和扩展性。
    

# **初步成果‍‍‍‍**

图数据库选型完成后，我们也参考了 NebulaGraph 社区的很多文章，围绕主题、投资标的数据设计了我们包括主题、商品、技术、机构等在内的根概念。另外对于事件类型数据的处理还在研究。

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

下图即为我们构建的某投资主题图谱。

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

‍

# **未来规划**

下一步我们还需要继续丰富图谱的数据，这就需要脱离人工，使用 LLM 来帮助我们进行语料的分析，提高 NER 效率和准确性。进一步的，直接使用大模型构建本体及建立关系。

另外，最近 OpenAI o1 的推出，让大家更加重视 CoT，我们也考虑将 CoT 纳入到我们的数据处理流程中，以提高推理的准确性和可解释性。

如下是 Palantir 公司的产品的流程中 CoT 设计界面。

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

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

作为一个初创公司，我们在整个图谱建设过程中遇到了很多的具体问题，比如同义不同形，同形不同义的情景处理；事件图谱的构建和使用；自定义关系，新词热词识别等等。也期待业内专家能够给与我们帮助和指导。

语势科技利用 GraphRAG 提升金融信息产品能力

语势科技 x NebulaGraph｜利用 GraphRAG 提升金融信息产品能力

**博睿数据**：博睿数据是中国 IT 运维监控和可观测性领域领导者，中国应用性能监控及可观测性领域首个 A 股上市公司，同时蝉联市场份额排名第一，目前已经获得中国银行、中国建设银行、光大银行等1000+ 头部客户的选择和信赖。‍



# **背景‍‍‍‍**

2022 年博睿数据开始强化可观测性的能力，要建设一个快速可靠的可观测性平台需要具备多样的技术能力及高质量的数据支持。同时要对这些数据进行分类分层，并将这些复杂的分层数据做大量的特征关联、上下文洞察、信息整合等工作。**故需要依赖关系拓扑和 AI 的能力来辅助这些场景的落地，从而引入 NebulaGraph 图数据库来存储关系数据。**

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

本文主要分享博睿数据在 NebulaGraph 的实践，希望能给大家一些实践和启发。主要从以下几个部分进行介绍：

-   架构介绍
    
-   业务场景简单介绍
    
-   实践及优化
    
-   总结与展望
    

**架构介绍‍‍‍‍**

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

从上图可以看出，ingest 客户端集成在业务中，业务通过 ingest 统一写入数据，其中涉及三个 space 的数据,权限空间：用于存放权限相关核心数据；实体关系空间：存放完整数据模型，为 cmdb 和 ai 提供数据支撑；根因空间：存放根因分析结果，用于展示根因拓扑与故障回放。manager 组件服务调度策略，用于对写入链路与查询进行动态控制，业务通过上层 one-service 服务进行查询，one-service 对外提供统一的查询语法，用于屏蔽存储使用的不同数据库，使上层业务更轻松的使用不同存储介质并对不同存储介质进行关联查询。

**写入链路介绍**

下面以一个 space 的数据举例：manager 会一实时监测 nebula 服务状态，用于进行调度策略的更新。当业务数据写入时，会先按照 manager 服务实时更新的调度策略，对数据进行数据预去重，同时攒批，会根据数据条数、大小、时间(manager 提供)来进行攒批控制。当数据攒批完成会根据 manager 实时更新的调度策略来选择对应 graphd 节点来执行写入操作，例如：

-   节点 1 正在执行一个大查询，导致节点 1 负载比较高，此时数据写入过去可能会因为内存过高或者线程不够用而导致写入延迟或写入失败，此时会在节点 2 与节点 3 中选择一台执行，而不会发送到节点1；
    
-   当所有 storaged 节点均不可接受写入请求，则不会执行写入操作并在业务侧积压，直至达到配置指定内存大小则阻塞业务写入策略，或在收到程序终止信号将内存中数据返回给业务。
    

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

**查询链路介绍**  
查询链路对于 sessionpool 的使用策略其实和写入链路一致，核心思想是为了实现负载均衡。此外为了防止超大查询对部分小查询造成影响，主要是做了一些二开工作，后续会详细介绍。

# **业务场景‍‍‍‍‍‍‍‍**

**CMDB数据模型**

预置 5 层模型共计 146 种实体、113 种关系。对应实体关系空间 space，是整个可观测性平台的底层基座，管控了整体的数据模型，并为根因分析提供数据支持。

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

**权限管理**

并对数据做出相应的版本管理。需要包含类似 sql 语句，网络请求等高基数的数据和联查除 nebula 外其他数据库。

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

**AI 根因拓扑和回放**

此业务场景是指使用实体关系空间 space 中的数据结合 clickhouse 等数据库中的时序数据进行根因分析，将中间结果存储到根因 space，并更新故障树直至产生最终结果，同时支持故障回放能力。

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

# **实践及优化‍‍‍‍‍‍‍‍**

在我们场景实际落地中遇到过一些问题，下面会简单介绍下，希望可以给其他同学提供一些帮助。

**写入流量太大，导致内核压力较大**

在我们的早期版本，我们只是无脑攒批，然后写入。同时由于我们的业务场景属于大量自有探针采集的数据，对于图来说都是同样的点，所以存在大量重复数据。内核的压力很大，同时网络带宽占用也很高，因为这些大量重复的数据，业务场景上是不需要那么实时的。所以我们在内存中根据表结构定义的时间，进行了预去重操作，整体写入性能提升了 50%+，同时带宽降低为原来的五分之一。对于实时性要求比较高的数据，则会走另一条链路直接写入，不存在攒批与去重。

**负载不均衡**

因为 graphd 存在单点问题，所以有些时候我们使用 sessionPool 时会遇到负载不均衡的问题，尤其是我们存在根因分析这种混沌的查询场景，所以单点问题被进一步扩大，所以我们在 nebula-java 客户端外层自己做了负载均衡。具体实现就是通过一些监控手段来定位到哪些节点比较空闲，然后通过分别初始化不同节点的 sessionPool，来控制具体可以发送到那台节点执行。

**大查询影响小查询**

上面提到过，我们存在根因分析这种混沌的查询场景，所以在早期常常遇到一个很简单的查询查询耗时很长甚至查询失败的情况，而我们的权限场景又属于入口服务，这样就会导致客户体验非常不好。所以经历了两次改动：

1.  查询文档发现，可以 kill 大查询。但是实际使用时发现需要知道具体的 id 来确定这条查询，同时这个 id 的记录还是依赖 graphd 定时上报给 metad，然后查询 metad 服务来获取。
    
2.  故第一次尝试，将上报周期改短，但是发现无法区分写入请求与查询请求，导致 meta 服务使用内存与 cpu 飙升；‍
    
3.  第二次则决定修改内核，将 SHOW LOCAL QUERIES 拓展为查询此节点的所有查询，从而实时获取 id 来进行 kill 操作；
    
4.  所以在 manger 层做了超时 kill 的操作。‍
    
5.  但是我们在部分私有化场景还是遇到了问题，当一个查询将内存占用超过机器内存限制比例时，甚至无法执行 SHOW LOCAL QUERIES 和 kill 操作，于是我们经常了第二次改动，
    
6.  二开了内核，支持在查询语句中传入超时时间，从而可以灵活的控制单个查询整体的超时时间。但是再我们自己的测试中发现，有一些查询可以在很短的时间内占用大量的内存；‍
    
7.  我们又加上了单条语句的内存限制，进一步防止大查询对小查询的影响。
    

但是这还没有真正解决我们的问题，所以我们在计划第三次改动，准备实现租户资源隔离，space 资源隔离。来真正消除业务之间的影响。

**最后一次完整关系的获取**

我们有一个需求时获取最新的关系，因为我们存在一些无法确定时间的关系查询。举个例子：a->b, b->c,假设存在这样的数据，a 和 b 之间一直每秒写入一条边，其中边上的 rank 则记录为写入时的时间戳，但是b和c的数据写入是无法确认的，可能是 1 秒，也可能是 1 天。这种场景下，我们想获取整个拓扑的最后一次完整拓扑时，就没法很好的确定过滤条件。我们选择在写入时冗余了一份数据，rank 除了记录数据时间外，还使用 0 表示最后一次数据，就是在写入时同时写入 rank 为 0 和 rank 为当前时间的边数据，所以我们在查询最后一次完整拓扑时过滤 rank 为 0 的数据即可。同时假设需要查最近十分钟的最新拓扑，也可以在此基础上在进行过滤，可以减少查询耗时(取决于数据模型)。

**数据建模优化**

-   我们优化了数据建模，最开始我们有一个 type 类型，用来区分不同类型的数据，然后都存在一个 tag 中，在实际使用情况发现有些查询场景无法将过滤条件下推，导致查询性能不好。所以我们将不同的 type 类型拆成了不同的 tag。
    
-   缩减属性个数，只保留必须的属性，其他属性存放在 clickhouse 中。实际使用场景中发现大量属性存在 nebula 中，效果并没有一些其他数据库好，包括存储的消耗，属性过滤，查询计算。所以可以考虑结合其他数据库共同使用。
    
-   优化 vid，将部分关键信息存储在 vid 中，因为图的查询无法避免查询 vid，但是可以避免查询属性，所以当 vid 中包含一些关键信息时，可以节省掉属性这部分开销，可以进一步加速查询与节省资源。
    

‍

# **总结与展望‍‍‍‍**

NebulaGraph 社区提供了丰富的工具及基础能力，并且社区群与论坛也比较活跃，博睿从最开始的 3.0 到现在的 3.8 ，社区提供了很大的帮助。大家在使用 NebulaGraph 时，建议不要仅仅只关注 NebulaGraph 用于查询，也应当多关注关注 NebulaGraph 提供的工具和其他的一些能力。

希望社区增加一些查询的记录，包括耗时、使用内存，扫描行数等监控或留痕能力来帮助我们进行查询或数据建模优化；增加一些 3.X 迁移后续大版本的工具，让我们可以方便的升级；同时我希望我自己可以有时间更多的参与到社区的建设中，后面有时间也会给社区多提 pr。

博睿数据需要依赖关系拓扑和 AI 的能力来辅助业务场景的落地，引入 NebulaGraph 图数据库来存储关系数据。