> 导读：在金融风险管理与智能营销领域，传统的关系型数据库已难以应对日益复杂的关联分析需求。中证数智科技（深圳）有限公司通过引入 NebulaGraph 图数据库，构建了覆盖全市场的企业图谱，实现了从风险管控到智能营销的多维度突破。本文整理自中证数智胡新老师，在[香港 nMeetUp](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515842&idx=1&sn=96f371874253733aa197d37b59723cd3&scene=21#wechat_redirect) 上的分享。

>  胡新，英国杜伦大学硕士，FRM，拥有 10 年的金融行业风险管理与合规管理科技建设经验。专研于风险计量模型和智能图算法在金融机构风险管理与合规领域的应用，并为多家金融机构提供基于关联图谱的落地风控、合规应用。

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


# 一、背景

中证数智是中证信用旗下的科技企业，专注于金融机构信用风险管理领域，为监管机构、投资机构、中介机构等金融市场参与主体提供智能化的信用数据、信用评价、信用风险预警等信用科技服务。

中证数智的产品基座是海量的信用数据，通过实时信用数据关联与洞察，完成实控人识别、股权穿透、关联交易实时监控、风险传染管理等复杂任务。在传统的关系型数据库难以应对日益复杂的关联分析需求下，中证数智选择了 NebulaGraph，构建了覆盖全市场的企业图谱，显著了提升金融机构的风险管理能力和业务决策效率。

# 二、知识图谱构建

## 数据资源层：大规模、多维度整合

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


中证数智整合内外部资源，构建了覆盖全市场的企业金融知识图谱，包括：

* 企业工商与图谱数据：注册信息、股东高管、投资关系、分支机构、年报、抵押、异常经营、行政处罚等；

* 信息预警数据：新闻舆情、公告、司法数据、诚信数据、预警评分；

* 经营与金融产品数据：企业曝光、区域与财务数据、债券、股票、私募基金、ABS、REITs 等；

* 宏观与区域数据：行业经济、景气指数、国民经济核算、区域经济与债务等。

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


目前图谱已覆盖3 亿+点，包括 1.2 亿企业实体、1.4 亿自然人、200 万金融产品，4亿+边，包括控制、投资、任职、担保、诉讼等多种关系类型。

## 技术实现：基于 NebulaGraph 的图谱构建

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


在金融风控、企业关联分析、集团客户管理等场景中，如何高效地从结构化数据中构建出可供业务直接使用的知识图谱，是很多企业面临的核心挑战。

中证数智形成了一套系统化的企业图谱构建流程：以标准化接口为桥梁，将传统数据库中的企业信息转化为图数据库中的节点与关系，最终通过多种图谱应用接口支撑业务分析。

1. 数据提取

从传统数据库导出 CSV 格式的节点文件、节点属性文件、关系文件、关系属性文件。

* 企业基本信息（Company info）：包括企业名称、注册号、注册地、行业、成立日期、注册资本等基础属性。

* 企业股东信息（Company shareholders info）：记录股东名称、持股比例、出资日期、股东性质（企业/自然人）等。

* 企业高管信息（Company executive info）：包括董事、监事、高级管理人员的姓名、职位、任职日期等。

这些数据通常以表结构存储，虽能满足日常查询，但难以高效处理深层次的关联分析。

2. 图谱映射

通过图工具将数据批量导入 NebulaGraph，上述数据将变为符合图属性的元素。

* 点（Vertex）：表示实体，如企业、自然人、产品等；

* 标签（Tag）：描述点的属性特征，如企业名称、注册资本；

* 边 （Edge）：描述点间的关联，如投资、任职、担保；

* 边类型（Edge type）：描述关系的特征，如持股比例、任职日期。

3. 标准化接口

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


为方便业务系统调用，中证数智将常用的图谱查询与分析功能封装为标准化的图谱接口（Graph API），这些接口屏蔽了下层数据结构的复杂性，使业务人员可直接通过 API 调用获取关联分析结果，无需理解底层图数据库结构。

## 图谱应用：覆盖多元应用场景

在技术创新层面，显著提升了基于专家经验与企业历史数据的业务预测分析方法在准确性、覆盖范围及效率方面的表现。

从业务视角来看，它能将分析从传统的规则驱动转变为智能驱动：通过运用大数据和图技术，我们可以发现不同于传统规则的未知风险模式，并据此进行更深层次的分析。

图技术与大数据的结合，能够为金融机构的前台、中后台等多个场景提供支持。

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


前台应用侧重于客户管理，包括客户尽职调查、客户画像分析以及业务机会挖掘等。

中后台应用则聚焦于风险管理和合规管理。在风险管理方面，可以利用数据和图算法探查疑似关联关系、识别空壳公司、实现集团客户统一管理，并构建风险标签模型。基于分析结果，还可进一步实施集中度管理、风险传导分析和风险排查。

# 三、核心算法突破

## 业务挑战

金融机构在进行集团客户授信、关联交易核查、风险集中度管理时，需准确识别企业之间的控制关系。

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


1. 直接持股法

从 A 点向上找最大股东 D，再找 D 的最大股东 G，最终得出控制人为 G. 但结果错误，因为它忽略了 E 和 F 间由 H 控制的间接持股关系。

2. 累计持股法

从 A 向上找到所有股东 B、C、D、H，通过股权乘法，得出最大股东为 C，但该方法因股权乘稀释也造成错误结果。

以上两种传统方法存在三大局限：

* 方法缺陷：直接持股法忽略间接持股，累计持股法因股权稀释无法跨层比较；

* 穿透层级有限：通常不超过 10 层；

* 计算规模受限：仅能针对重点客户进行分析，无法覆盖全市场。

## 投票权迭代算法

中证数智研发的投票权逐层迭代算法，通过逐层比较股东控制权大小，精准识别企业实际控制人。

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

该算法已获国家发明专利，具有以下优势：

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


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


* 无限层级穿透：实测最深可穿透 50 层以上；

* 全量计算能力：支持超 4 亿节点全市场计算，生成超 100 万个资本系，最大集团成员数达 9,084 家；

* 高效计算：10 万成员规模的集团计算时间约 2 分钟，全市场计算在 20 小时内完成。

## 四大业务调整机制

在实际应用中，团队针对四类复杂场景做了专项优化：

1. 自然人合并

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


对同名自然人的控制企业进行概率合并，如“Bai Yu”控制四家企业，经图谱结构计算后合并为同一实控人。

2. 交叉持股处理

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


在循环持股中按持股比例、注册资本、名称排序等优先级确定实控人。

3. 实控人人工修正

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


支持基于尽调信息的实控人手动调整，优先级为：自建实控人 > 公开实控人 > 疑似实控人。

4. 政府实体处理

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


将政府单位（如国资委）退回至第一层非政府企业股东，便于集团管理。

可视化展示：2D/3D实控路径图谱

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



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



通过可视化展示优化，提供直观的资本系树状图和实控路径展示，极大提升了业务人员的分析效率。

# 四、从风险管控到智能营销的全链路赋能

## 风险管控

中证数智构建了一套完整的风险信号识别与管理机制：

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


* 信号来源：系统监控、人工上报、定期检查；

* 风险分层：根据阈值进行分类、分层、分主体管理；

* 处置流程：风险识别 → 应急处理 → 调查评估 → 化解处置 → 持续跟踪。

## 场景示例

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


对风险主体与客户关系的定期排查，输入风险企业群、我的客户/投资组合及关联关系配置，输出图谱显示：有 9 个与风险主体相关的客户群主体需进一步排查。该算法还可用于供应商投标、业务新主体验证、关联交易核查等场景。

## 智能营销

此外，中证数智还利用大模型+图谱实现智能营销。

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


* 信息源：公开市场信息（新闻、公告、研报、工商信息等） + 内部信息（项目文档、周报等）；

* 商机标签：上市公司增减持、回购、融资融券；私募机构备案、优秀基金经理等；

1. 技术实现

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


* 标签识别：BERT + 分类器，从金融文本中提取商机标签；

* 信息抽取：GRU + CRF 进行实体识别，BERT + 分类器进行关系抽取；

* 图谱构建：将商机标签、实体、关系存入知识图谱；

* 部门画像：通过大模型解析历史文档，生成业务部门偏好画像；

* 推荐匹配：基于协同过滤、内容推荐等算法，向部门推送个性化商机。

系统还能分析客户资金属性、投资偏好、风险承受能力、合规准入等维度，实现：

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


* 投资融资需求：股权投资、资产管理、衍生品业务；

* 融资需求：信贷业务、融资融券；

* 服务中介需求：投资咨询、托管外包、产品销售；

2. 场景示例

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


在客户关联图谱平台下的关系图谱中，中心节点是现有客户或商机实体，通过关联方和业务层级筛选潜在客户，降低获客成本。

# 五、图技术驱动金融智能未来

中证数智通过深度融合 NebulaGraph 与自研算法，实现了从实控人识别，到风险管控再到智能营销的全链路赋能，目前已被中国银河证券、东吴证券 、招商证券、国投证券等证券公司，中国大地保险、远东租赁、越秀集团等金融机构深度应用。

中证数智的实践表明，图技术不仅能提升传统风控的精度与效率，更能打开新的业务增长点，推动金融机构向数据驱动、智能决策的新阶段迈进。


中证数智科技（深圳）有限公司通过引入 NebulaGraph 图数据库，构建了覆盖全市场的企业图谱，实现了从风险管控到智能营销的多维度突破。

图谱的 N 重业务价值：中证数智的一图多用

> 导读：传统风控系统基于规则引擎和统计分析，在处理简单欺诈模式时表现尚可，但当面对欺诈者采用多设备、虚拟身份、链上链下混合操作等手法，构建起复杂的交易网络时却显得力不从心。普适智能核心团队具有数十年知识图谱研发经验，基于 NebulaGraph, 构建了一站式知识中台，为 Web3 行业提供“一个中台 + N 种应用”的高效模式。本文整理自陈啸翔老师在[香港 nMeetUp](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515842&idx=1&sn=96f371874253733aa197d37b59723cd3&scene=21#wechat_redirect) 上的分享。

> 陈啸翔，北京大学学士，悉尼新南威尔士大学硕士。海南省大数据产业联盟认证专家，前世界 500 强企业人工智能中心负责人，10 年知识图谱及人工智能解决方案开发与实施经验。

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


# 一、背景

普适智能作为一家专注于图计算与知识图谱技术的人工智能企业，自 2015 年起在财富 500 强企业的研发实验室开始技术探索，2018 年正式成立并推出第一代知识图谱平台。如今，结合最新的 AI+图技术，已迭代至第五代，在金融监管（反洗钱、欺诈检测）、能源管理（智能电站决策系统）、公共安全（智能案件分析）等领域成功落地多项应用，服务超过 30 家知名企业，并正通过华为、信创等生态伙伴加速全球化布局。

## 业务痛点

普适智能的许多客户，无论是风险管理、市场营销还是反洗钱，他们都有许多共同的业务痛点。

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


**风险管理**

* 欺诈升级：传统基于孤立实体的规则模型难以应对日益复杂的联合欺诈行为，如信用卡诈骗和贷款骗局。

* 隐蔽风险传播：风险通过复杂网络（如企业集团、供应链等）快速扩散和传播。

**精准营销**

* 客户洞察转化率低：基于推荐机制的策略缺乏高效触达渠道，难以实现有效转化。

**反洗钱（AML）**

* 交易网络隐匿化：需通过动态多层资金流分析以识别洗钱行为模式。

解决以上业务痛点，关键在于支持多层、动态连接的高级关系网络分析，追踪实时风险传导，并智能识别欺诈团伙。

然而，传统技术存在以下局限性，无法满足业务需求：

* 性能瓶颈：涉及三层及以上关系链的查询出现显著延迟

* 开发成本高：需针对多源数据和规则进行定制化编码

* 实施落地难：缺乏高效的欺诈团伙检测及动态网络挖掘工具

## 知识图谱

普适智能选择用 NebulaGraph 构建知识图谱，打造一站式知识中台，根本原因是与传统技术相比，知识图谱更适合分析复杂关系，进行实施决策，高效解决上述问题。

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


首先，知识图谱技术运用图数据库（点/边结构）构建动态语义网络，实现实时关系分析，并支持超越传统关系型数据表约束的灵活数据建模，并且这种点-边架构本身构成语义框架，通过结构化整合与上下文关联，高效实现业务数据全生命周期的统一标准化。

其次，知识图谱利用图算法，如最短路径优化、Louvain 社区发现及连通分量识别等，将数据转化为关系网络，显著提升群体检测分析能力。

最后，通过将实体间的关联上下文融入模型训练，知识图谱还弥补了传统机器学习模型仅聚焦孤立统计属性的局限。

# 二、知识图谱在 Web3 的风控应用

## Web3 的风控挑战

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


随着 Web3 时代的到来，数字货币交易所等新型金融平台面临着前所未有的风控挑战。Web3 强调去中心化、用户主权与隐私保护，但其匿名性、跨链交易与高频流动性也带来了新的风险形态：

* 百亿级数据整合难题：链上与链下数据规模庞大、结构异构，传统关系型数据库难以高效融合与查询。

* 犯罪网络隐匿性强：犯罪分子通过多地址、跨链跳转、分层交易等手段隐藏身份与资金流向。

* 实时性要求极高：高并发交易、高频交易、批量注册等场景下，传统风控系统响应延迟高，误报与漏报率居高不下。

这些挑战使得传统基于规则和统计模型的风控系统显得力不从心，亟需新一代技术架构的支持。

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


知识图谱技术通过图结构构建动态语义网络，天然适合表达复杂关系网络。相比传统表结构，NebulaGraph 图数据库在多层次关系查询、实时关联分析、动态网络挖掘等方面具有显著优势。例如，作为一个数字货币交易所，其客户的生命周期，从客户获取、注册到提现，有很多知识图谱可以发挥价值的地方，比如反洗钱、客户推荐、批量注册检测等等。

## 图智能风控解决方案

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


普适智能基于 NebulaGraph 图数据库构建了图智能风控平台，涵盖数据集成、图建模、实时计算、可视化分析与智能决策等功能模块。

以 NebulaGraph 为底层支撑，整合链上/链下多源数据（设备指纹、KYC 信息、交易行为等），通过图建模构建实体关系网络。中台提供实时图查询、多跳分析、社区发现等能力，支撑上层批量注册检测、洗钱路径追踪、团伙欺诈识别等场景，最终实现从数据接入到实时决策、可视化调查的一体化风控闭环。

**知识图谱构建**

在将知识图谱部署到特定场景时，我们首先需要构建一个本体，这相当于传统数据库中的表结构模式。

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


如上图所示，我们以数字货币交易所的用户为中心节点，其他节点则包括客户注册时使用的各类信息：登录IP、设备指纹、链上地址、手机号码等，连接这些节点的边则代表了各种关联关系。

这种本体设计使我们能够将多维度数据按其内在结构加载到 NebulaGraph 图数据库中，为后续的复杂分析奠定基础。与传统关系型数据库相比，NebulaGraph 在处理高度互联数据时表现出色，特别适合用于发现隐藏在大数据中的复杂模式。

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

以批量注册风险分析场景为例。羊毛党会使用机器人或脚本，模拟多设备和合成身份完成批量注册。传统解决方案主要依赖分析独立的数据指标，如注册信息相似度、IP地址信誉、设备指纹等。然而，这些方法存在明显局限性：

* 维度单一：无法动态关联所有节点行为数据

* 检测滞后：往往在风险发生后才能识别

* 漏报率高：难以发现精心组织的协同欺诈行为

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


而基于知识图谱的解决方案是：构建好知识图谱本体并将数据加载到 NebulaGraph 后，数据可以被可视化地关联起来，实现高效风险管理。

例如，通过图谱，我们可以直观地发现 ，四个不同的设备连接到同一个IP, 这意味着所有这些设备、对应的加密货币地址和账户很可能由同一个人持有。

再比如，在图谱中，风险可以通过链接传播，且传播距离越远，影响程度越小。这一特性使得我们能够实施更加精准的风险评估：如果一个节点与已知黑名单节点存在关联，那么该节点也存在风险可能性，我们可以根据距离远近分配不同的风险权重。

**批量注册风险分析**

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


如果我们不使用知识图谱，风控系统可能只会看到孤立的、直接的连接，从而漏掉隐藏在复杂关系背后的整体风险。但由于我们基于预设的本体构建了知识图谱，就能够从更高维的视角审视这些关系。

当一个账户通过多条边与其他节点（如IP、设备、地址）紧密关联时，这些多重连接本身就构成了高风险信号，系统可以据此实时阻止该账户的功能。如果这些连接指向已知的可疑或恶意节点，那么这个新账户甚至可能被直接拒绝注册。

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


此外，我们可以运用图算法（如 Louvain 社区发现算法）将整个图谱数据划分为不同的社区。通过制定一系列群体行为规则——例如，在特定时间窗口内，某个社区内部是否发生了多个账户的同步操作，来精准识别有组织的欺诈团伙。再通过综合分析这些社群的拓扑特征和统计指标（如内部连接密度、中心性节点、资金汇聚程度等），我们可以判断整个社群存在的风险概率。

因此，以知识图谱为核心的风控方案能使我们从“处理单个风险点”升级为“一次性端掉整个犯罪网络”，从而更加高效、彻底地防御针对数字交易平台的大规模协同欺诈活动。

**交易风险分析**

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


在传统的风控体系中，虽然我们同样会监测诸如异常登录地点、设备指纹、高频操作序列等指标，但仍然面临几大核心挑战：黑客通过多跳转账混淆资金路径，使得追踪异常困难；资金最终汇聚至聚合钱包，难以识别和溯源；同时，极高的实时性要求也让传统规则引擎难以应对。

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


依托 NebulaGraph ，我们能够在毫秒级时间内对大规模复杂关系进行实时计算，并运用图规则动态识别异常资金流和行为模式。例如，通过内置的图算法，我们可以将交易图谱自动划分为多个社区，分别进行风险检测与评估。

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


在系统架构层面，我们提供实时与离线一体化处理集群。NebulaGraph 同时支持高性能在线查询集群和高吞吐离线计算集群，在线集群可提供高并发、低延迟的实时风险决策，离线集群则适用于大规模批量图计算与深度挖掘。两类集群之间保持数据同步，在提供极致性能的同时，也保障了数据的一致性与系统的稳定性。

**NebulaGraph vs 关系型数据库**

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


在用百亿级反欺诈数据中，在进行四度关系查询时，关系型数据库需要长达 154 秒，而 NebulaGraph 仅需约 0.14 秒，耗时相差超过一千倍。对于五度或更深度的查询，关系型数据库甚至难以完成。

这种性能上的差异，正是我们在 Web3 行业选择 NebulaGraph 的核心原因。该行业需要处理动辄十亿级别实体和交易的超大规模图谱数据，并要求毫秒级的实时风险研判。

传统关系型数据库无法在此类深度关联查询场景下提供可用的性能，而 NebulaGraph 凭借其为关系查询优化的存储和计算引擎，能够轻松应对，从而为实时反欺诈、资金链追踪、社区发现等关键业务提供了坚实的技术基础。

**图特征**

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


在传统的机器学习方法中，模型通常仅依赖于账户本身的静态属性（如注册时间、交易频率等）进行学习，视角相对孤立。

而通过引入知识图谱，我们可以从庞大的关系网络中提取出深层的关联特征。例如，可以为每个账户节点计算其所在子图的各类统计指标——如关联设备的数量、二度邻居中高风险节点的比例、在整个交易网络中的中心性指标等，并将这些图特征作为新的维度加入模型训练。

# 三、应用案例

## 数字货币交易所

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

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


面对全球监管趋严和每日数十亿美元的交易量，某头部交易所亟需解决海量数据下的实时风险监控与合规审计难题。在引入普适智能的风控平台后，整合链下数据、链上数据、用户画像和交易记录，形成包含 40 亿节点、400 亿边的大规模风险图谱，实现了：

* 实时风险拦截：在注册环节即识别出多设备、多账户关联的批量注册行为，显著提升拦截率；

* 资金路径追踪：支持多跳交易路径分析，揭示洗钱链条与聚合地址；

* 合规透明度提升：实现合规数据汇总和报告自动化，确保审计和监管审查的合规性清晰、可解释且可追溯。

## 区块链数据服务商

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



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


某区块链数据服务商标记超过 30 亿个地址，并实时传输链上数据，如何从海量数据中洞察业务价值？通过普适智能提供的知识图谱解决方案，可以进行图谱建模、实时图计算、图算法、图谱可视化以及 Graph + AI，实现了：

* 广泛的资产覆盖：将地址和交易分析从比特币、以太坊等主流资产扩展至更多类型的数字资产，显著提升监控系统的覆盖范围。

* 精准的地址风险画像：通过图规则、复杂指标及算法模型，有效识别可疑交易模式，实现对地址“健康度”的多维评估与动态风险评级。

* 深度链上图谱分析：依托强大的图计算与多跳查询能力，支持对复杂转账路径进行深度追溯与调查，提升对隐蔽资金流向的发现和溯源效率。

# 四、总结与展望

普适智能通过深度融合 NebulaGraph +知识图谱技术，为 Web3 行业提供了从前沿技术到落地应用的全栈式风控解决方案。其核心价值在于：

* 从关系挖掘到价值创造：将复杂的网络关系转化为可操作的业务洞察；

* 从被动防御到主动预警：实现从事后审计到实时拦截的跨越。

未来，普适智能将继续深化图计算大模型与 AI 智能体技术的融合，推动知识图谱在更多行业中的部署与应用，助力企业在数字经济时代实现智能化升级。


---

直播预约：开源版、企业版怎么选？🔥

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/zhibo-924.png)


香港活动报名：[共话 Web3 基础设施](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515897&idx=1&sn=a4ba1125236304832e1bcb6e94d1ac50&scene=21#wechat_redirect)🔥

欢迎对 Web3 感兴趣的小伙伴们报名～👏

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

普适智能核心团队具有数十年知识图谱研发经验，基于 NebulaGraph, 构建了一站式知识中台，为 Web3 行业提供“一个中台 + N 种应用”的高效模式。

基于知识图谱的 Web3 风控：普适智能一站式知识中台

一份权威的行业排名，见证了 NebulaGraph 的飞速成长。

> **2019 年 12 月**
> 
> NebulaGraph 首次进入 DB-Engines 图数据库管理系统排名，排名最末。
> 
> **2022 年 9 月**
> 
> NebulaGraph 位列第十四名。
> 
> **2023 年 4 月**
> 
> NebulaGraph 跻身 Top 10，名列第九，在 Graph 类别下排名第三。
> 
> **2025 年 9 月**
> 
> NebulaGraph 在 Graph 类别荣登第二 ，仅次于 Neo4j.

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/DB-Engines-No.2/ranking.png)


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

# **01 DB-Engines 排名**

DB-Engines 排名由奥地利技术专家 Matthias Gelbmann 和 Paul Andlinger 于 2012 年联合创立，这是一个客观、数据驱动的排行榜，通过量化指标、多维度数据评估反映全球数据库技术的全球热度与趋势。

DB-Engines 每月发布综合排名，覆盖关系型、NoSQL、图数据库等 489 个数据库。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/DB-Engines-No.2/DB-Engines.jpeg)


由上述指标可知，DB-Engines 排名反映的是数据库的“受关注度”或“流行度”，不能直接等同于技术先进性或市场占有率，但已成为行业技术选型中的重要参考依据。

在 NebulaGraph 社区，许多企业都是先通过 DB-Engines 排名，初步筛选出符合业务场景需求的多款数据库，再通过性能测试等多维考察，成为 NebulaGraph 用户。

NebulaGraph 排名持续攀升至全球第二的过程，恰恰反映了我们在技术社区认可度、企业采用率和生态建设等方面取得的实质性进展，因为排名背后不仅是高曝光度，更代表着产品成熟度与社区生态已经达到了新的水平，能够为选型决策提供切实的参考价值。

# **02 关于 NebulaGraph**

NebulaGraph 的诞生源于一个清晰的愿景：打造一款开源的、分布式的、支持线性扩容的世界级图数据库，能够容纳千亿顶点和万亿边。

> 2018 年 8 月 31 日，@Sherman-the-tank 在 nebula 仓库中提出第一个 issue ‘Create a parser framework to process GQL.’

> 2018 年 9 月 5 日，@dutor提交了第一个 PR ‘Added some concurrent utilities, GenericThreadPool, etc.’

> 2019 年 5 月 15 日，遵循 Apache 2.0 开源协议，在 GitHub 正式开源。

汇聚开源力量，六年来，NebulaGraph 在 GitHub 的 Star 数早已突破 12,000，成为全球备受关注的开源图数据库项目之一，用户覆盖金融、互联网、通信、电商、保险、安全等多个行业，为阿里、京东、美团、网易、携程等企业解决业务痛点。

# **03 NebulaGraph 的最新应用**
**🔍点击图片，查看案例详情**

✨加密货币风控

[![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Blocksec-hongkong/blocksec-banner.jpg)](https://www.nebula-graph.com.cn/posts/usecase-BlockSec)


面对将链上地址与真实身份绑定、构建资金流动态分析系统、实现实时交易审查和洗钱模式的全新监管要求，BlockSec 利用 NebulaGraph 构建了安全合规的加密货币风控系统。通过标签，给复杂的链上地址与交易标记漏洞利用、洗钱、混币器等多种威胁类型，形成风险图谱，在毫秒级时间内完成百亿级别的图遍历分析，从而建立可计算的风险量化模型，为高风险交易的归因提供量化依据。

## ✨大数据平台

[![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-JD/JD-banner.jpg)](https://www.nebula-graph.com.cn/posts/Nebulagraph-use-case-JD-Logistics)


面对日均数万人参与、月均百万级 Excel 处理、百万工时消耗的“做数”困境，以及复杂的数据权限与血缘关系挑战， NebulaGraph 落地京东物流智能化大数据分析平台 UData 后，实现了代码量减少 80%，查询延迟降低 30%，整体查询性能提升 5 倍，权限校验响应时间 <100ms 等显著成效。

✨供应链

[![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/NebulaGraph-use-case-BOSS/nebulagraph-use-case-boss-zhipin.jpg)](https://www.nebula-graph.com.cn/posts/ZKH-NebulaGraph-use-case)


随着震坤行业务极速扩展，导致客户-供应商关系、客户行为等复杂关系数据快速增长，传统数据库已无法满足高效存储、查询与实时分析的需求。使用 NebulaGraph 后，震坤行对推荐、搜索及交付进行优化，点击率提升 15%，下单转化率提升 5%；基于 NebulaGraph 的图算法，实现了多环节自动优化，有货率提升 15%，呆滞库存减少 10%，有效降低运营成本；同时优化了配送路线，确保客户极速的物流体验，客户售后工单数减少 20%。

## ✨智能运维

[[![image|690x293](upload://ui4vWgtaiL8IurAzc5o4HOGaClS.jpeg)](https://discuss.nebula-graph.com.cn/t/topic/16928)](https://www.nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin)


BOSS 直聘选择基于 NebulaGraph 构建了创新的异常调用分析与根因定位平台。BOSS 直聘通过统一的属性富化、聚合与点边建模，将运维数据转化为包含属性和时间的 NebulaGraph 图谱结构，再结合 PageRank 算法，找出导致业务故障的“风暴中心”，最终实现故障发现阶段平均收敛时间 20s 、故障处理阶段平均响应时间 40s 的智能运维。

# **04 加入 NebulaGraph**

NebulaGraph 能成为一款世界级的图数据库，离不开社区的巨大贡献。社区用户不仅积极反馈问题，还分享最佳实践、源码解读，甚至直接参与代码共建和工具开发。

正是这种集体智慧加快了 NebulaGraph 的迭代，使其能够不断完善与优化，社区用户的每一次提问、每一个分享、每一行代码提交，都是 NebulaGraph 成长道路上不可或缺的动力。

如果你也对图数据库技术充满热情与期待，欢迎加入 NebulaGraph～

* 官网：https://www.nebula-graph.com.cn
* 项目地址：https://github.com/vesoft-inc/nebula
* 社区论坛：https://discuss.nebula-graph.com.cn

添加 NebulaGraphbot，星云仔会邀请你进技术交流群～

> **本文首发于[「NebulaGraph」公众平台](https://mp.weixin.qq.com/s/Z3vBb4FJdF7c-Gbgjk65Ug)，更多产品资讯请访问[「NebulaGraph 官网」](https://www.nebula-graph.com.cn/)**

---

香港活动报名：[共话 Web3 基础设施](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515897&idx=1&sn=a4ba1125236304832e1bcb6e94d1ac50&scene=21#wechat_redirect)🔥

欢迎对 Web3 感兴趣的小伙伴们报名～👏

![HongKong-Meetup|227x500](upload://yBHcxZ2MVMAqVF5H3U1ZzO6hGDU.jpeg)

NebulaGraph 在 Graph 类别荣登第二 ，仅次于 Neo4j.

NebulaGraph 全球图数据库排名第二！

BlockSec 是全球领先的区块链安全公司，基于 NebulaGraph 构建了强⼤的加密⻛险控制系统，确保从数据捕获到⻛险洞察的全链条⾼效运作。

风控利器：BlockSec 用图+标签破解 Crypto 合规难题


> 导读：本文整理自 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 跨境金融风控的应用