> 导读：作者黄春晖，震坤行大数据平台高级开发工程师，专注于工业 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 图数据库来存储关系数据。

博睿数据 x NebulaGraph ｜博睿数据在 NebulaGraph 的应用实践

> 关于波克城市和作者‍‍

  

波克城市，一家专注于研发精品休闲游戏的全球化公司，连续七年入选中国互联网综合实力百强，2023 年位列 17 位。波克城市旗下拥有《捕鱼达人》《猫咪公寓2》等精品休闲游戏，全球注册用户超 5 亿，月活 6000 万，其中 70% 来源于海外，产品发行范围覆盖全球 200 多个国家和地区。

作者潘长江，波克大数据团队成员，自 2022 年起专注于图数据分析，其在风控和数据血缘管理等关键业务场景的应用实践，有效推动了业务的显著增长和效率提升。

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E6%B3%A2%E5%85%8B%E5%9F%8E%E5%B8%82banner/0911banner-10.jpg)

**一、业务背景**

随着公司的持续发展和扩张，所涉及的项目日益增多，相应的数据积累也在持续上升。在这一过程中，数据表及其需要计算的数据指标数量也在急剧增加，数据结构变得愈加复杂和杂乱。

为了应对这一挑战，建立一个有效的数据血缘系统显得尤为必要。数据血缘系统能够追踪数据的来源、流向以及其间的变化过程，这对于维护数据质量、确保数据的可追溯性和透明性至关重要。通过构建数据血缘系统，我们能够实现对数据流转全过程的监控和管理，从而提高数据治理的效率和精确度。

*   数据血缘系统的建设有助于清晰地识别数据之间的依赖关系和影响范围。在数据出现问题时，可以快速定位问题源头，有效减少错误诊断和修复的时间，保证业务的连续性和数据的准确性。
    
*   数据血缘分析为数据管理提供了透明度，使得数据的利用更加合规，尤其是在遵守日益严格的数据保护法规（如 GDPR 或 CCPA）的背景下。
    
*   数据血缘系统通过详细记录数据的每一次处理和传输，增强了数据安全性，让我们能够对潜在的数据泄露和非授权访问进行有效预防。通过这种方式，数据血缘系统不仅提升了数据的可用性和可靠性，也增强了企业对数据资产的掌控能力，从而支撑了数据驱动决策的实施，提升了企业的竞争力。
    

  

**二、技术选型**

在深入的技术选型过程中，我们主要对比了两款领先的图数据库：Neo4j 和 NebulaGraph。两者都采用属性图数据模型，允许我们存储丰富的实体属性和关系信息。这种模型特别适合用于表现和查询复杂的数据关系，这是数据血缘追踪所必需的。

Neo4j 作为一款老牌图数据库，提供了强大的社区支持和成熟的技术生态，其查询语言 Cypher 也被广泛认可和使用。然而，Neo4j 在大规模数据处理和分布式扩展性方面存在一定的局限性。尽管最新的版本有所改进，但在面对极大规模数据时，其性能可能会受到影响。

相比之下，NebulaGraph 作为一款新兴的开源的分布式图数据库，展现出了在大规模数据集上的卓越性能。NebulaGraph 采用 shared-nothing 架构，提供了在线水平扩缩容的能力，这使得它在处理千亿节点和万亿条边的超大规模图时仍能保持低延迟的查询响应。

此外，NebulaGraph 的兼容性设计，如支持 openCypher 查询语言，使得在这方面的学习成本大大降低。

在综合考虑了性能、后续的扩展性、易用性以及成本效益之后，我们得出结论：NebulaGraph 更适合我们当前及未来的业务需求。

NebulaGraph 不仅在技术层面满足了我们对大规模图数据处理的需要，而且在成本控制和团队技能转移方面也显示出了明显的优势。

因此，我们选择 NebulaGraph 作为构建数据血缘系统的理想图数据库解决方案。

  

**三、踩坑总结**

  

**Part.01** **环境搭建阶段**

**问题**：搭完环境尝试执行 insert 语句时报错：Error: Storage Error: RPC failure, probably timeout.  

检查集群中各节点的状态，未发现任何异常

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%9B%BE%E7%89%871.jpg)

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%9B%BE%E7%89%87%E4%BA%8C.jpg)

  

在每个节点上分别查看 NebulaGraph 的运行状态，发现有两个节点的服务没有正常启动。

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%9B%BE%E7%89%873.jpg)

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%9B%BE%E7%89%87%E5%9B%9B.jpg)

进一步查看报错的执行日志，发现是接口被占用了，但 netstat 命令查看 占用接口的进程就是 Nebula。

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

**解决方案：**

手动终止进程，再重启 Nebula 服务，数据可以正常写入，并且各个节点状态正常。

因为我这个 Nebula 环境是卸载后重装的，推测是在卸载之前，原来的进程没有杀干净，导致占用了接口，新安装的无法正常启动。

NebulaGraph 一定要每个节点逐个关闭并卸载。

  

  

**Part.02数据写入阶段**

**问题1**：VID问题

在 NebulaGraph 中，点的唯一标识 VID，支持两种数据类型，分别是定长字符串 FIXED\_STRING()和 INT64。其中整数 VID 通常比字符串类型更高效，因为整数的处理速度更快，占用空间更少。在本数据血缘项目中，由于是表级别的数据血缘，所以是库名+表名 唯一确定一张表，很明显这是字符串类型。

在测试环境下，由于预装了 Spark 环境，所以考虑借助 NebulaGraph 提供的 Spark 连接器完成数据写入。对于 VID 问题，由于希望实现幂等写入，因此不考虑雪花 ID 等实现方案，而是考虑借助 Java 中自带的 hashCode() 方法生成 VID。

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

上述方案在测试环境中能行得通，但是在正式环境下却无法实现，正式环境下并没有预装的 Spark 环境，因而在正式环境下，考虑使用 Python 连接器，拼接 insert 语句，批量将数据写入图库。最开始考虑与 Spark 环境下相同的方案生成 VID，但经测试发现，Python 中的生成 Hash ID 的方法多次执行，生成的 Hash ID 不一样（Python 3.3及以上版本引入了 hash 随机化机制）。

**解决方案**：

考虑仿照 Java 中 hashCode 的生成方式在 Python 中实现类似功能：

```
def hashCode(value):
    h = 0
    for c in value:
        h = (31 * h + ord(c)) & 0xFFFFFFFF
    return h if h < 0x80000000 else h - 0x100000000
```

但执行上述代码发现，在 Python 中并没有类似 Java 中的截断机制，以上面生成的 ID 作为 VID 写入图库中时，会出现超出数据范围的错误。  
最终，在正式环境下，将 VID 类型修改为定长字符串 FIXED\_STRING(128)，以 库名+表名的拼接作为 VID。

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

**问题2**：SQL拼接问题  

使用拼接 insert 语句的方式进行数据写入时，最为关键的一环就是 SQL 语句的生成。在本系统中表的生成 SQL 将作为节点属性存入图库中，由于 SQL 中本身就会有一些特殊符号，如, " ’ \\ / $ 等等，这些特殊结构在 insert 语句的拼接过程中需要格外注意【PS：NebulaGraph 以后要是能多加一个 text 类型就好了，可以忽略字符串中本身存在的一些特殊格式，防止出现一些意外的错误】

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

并且一些空值也要注意，Python 中的空值用 None 表示而在 NebulaGraph 则使用 NULL 表示，如果不进行转换，对于字符串类型的字段还是可以正常写入的，但是对于数字类型的则会报错。

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

一些特殊格式如 datetime 类型，不能以字符串格式直接写入，需要在写入时增加手动转换操作。

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

  

  

  

**Part.03数据查询阶段**

**问题**：后端反应图库查询速度慢

**解决方案**：增加针对常用查询字段的联合索引+优化查询语句，把多条查询压缩为一条查询。

**最有效的优化方案**：增加针对常用查询字段的联合索引，增加之后**查询速度提高了100多倍。**

```
CREATE TAG INDEX IF NOT EXISTS database_index_0 on table_node(database_name(15), table_name(20));REBUILD TAG INDEX database_index_0;
```

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

速度提升非常明显。  

优化 nGQL 的写法，将多次查询优化为一条，如查询当前节点、当前节点的上游以及当前节点的下游，原来的三个查询可以压缩为一条查询，有效提高查询速度。

```
MATCH
  // 查询指定节点及其属性
  (n:table_node{database_name:"byhls_ods",table_name:"app_login_log"}) AS target_node,

  // 查询该节点的所有上游节点（边的起始点）
  (upstream:table_node)-[:has_consanguinity]->(n) AS upstream_nodes,

  // 查询该节点的所有下游节点（边的终点）
  (n)-[:has_consanguinity]->(downstream:table_node) AS downstream_nodes

RETURN
  target_node.database_name AS database_name,
  target_node.table_name AS table_name,
  COLLECT(DISTINCT upstream) AS upstream_nodes,
  COLLECT(DISTINCT downstream) AS downstream_nodes
```

  

**四、总结反思**

目前项目处在起步阶段，很多功能还没有加，后续考虑应用 NebulaGraph 中自带的图计算功能，增加最优路径检索，核心度计算等功能，充分挖掘 NebulaGraph 的潜力。

  

高效数据血缘系统在游戏领域的构建实战

波克城市 x NebulaGraph｜高效数据血缘系统在游戏领域的构建实战


> 作者周伟诚，来自携程风控研发团队，专注于风控系统及特征平台领域。 2021年开始深入探索图数据，并在风控场景下进行多次落地实践，取得了显著的业务增益。



**一、前言**

携程作为在线旅游代理（OTA）行业中的一家头部企业，处理着海量的在线实时交易订单。然而，随着订单数量的增加，潜在的欺诈风险也随之上升。为了更有效地识别团伙欺诈和黑产攻击，同时确保实时风控系统的高响应性，携程风控研发团队对多个图数据库进行了调研和试用，**最终选择了 NebulaGraph 数据库，并成功将其投入线上使用，从而实现业务增益 32%。**

**二、业务需求**

在某些业务场景中，风控系统需要对业务事件进行补充，以丰富其风险画像，从而更有效地识别风险和防范欺诈。

然而，常规技术手段，在识别新客的业务行为时存在一定的局限性。主要原因在于，新客的历史数据较少 ，其业务风险的背景信息往往不够完善，这增加了欺诈的可能性。统计数据显示，相较于存量用户的业务行为，新客业务行为的欺诈风险高达数倍。为应对这一挑战，携程风控团队**提出了利用图数据库构建实时动态图的设想，以丰富新客业务行为的风险画像，从而提高欺诈识别率。**

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

一笔新客的业务行为通常包含多个维度的信息 ，如下图中的U，V，W 这 3 种元素。通过这些相同的元素 ，我们可以关联出一阶邻居和二阶邻居。如下图的例子所示，通过相同的元素 V1 可以关联出当前业务事件的一阶邻居，再通过相同的元素 U3 可以关联到二阶邻居的 W2。这样，我们可以从新客业务的单一信息中关联出其多阶邻居，并综合这些关联信息，更好地识别该业务行为的风险。

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

基于上述业务模型，我们将每个元素构建为一个节点，并使用该节点的维度作为其标签（tag）。节点的唯一标识符（vid）设置为具体的元素值。为了便于追溯，点上添加了该元素所属的业务事件号和请求时间。对于同一个业务事件中的元素，我们会创建边将这些代表元素的节点关联起来，表示它们之间存在关联关系。

在当前的业务场景中，还有个需求是保持一年内的实时关联图，对于超过一年时间的数据，将不再参与图的关联。因此，我们利用了 NebulaGraph 图数据库的一个特性，即它允许为时间戳类型的属性设置有效期（TTL）。根据业务要求，我们为所有节点的请求时间设置了一年的 TTL。一年之后，这些节点将自动过期，不再参与实时图的关联。这样可以确保当前订单的关联数据仅限于一年内的时间窗口。

**三、查询逻辑**

在实际的构建关联过程中，我们遇到了两个问题。第一个问题是查询存在热点问题。如下图所示，例如从 U1 元素开始，它关联查询到 N 个 W 元素的节点，然后每个 W 元素又各自关联到 N 个 V 元素。这样会导致关联查询的数量急剧膨胀，甚至可能导致超时和服务器宕机。

对于这样的热点问题，我们需要加以排除，因为其数据价值不高，并且会因为查询超时而降低整体的关联率，进而影响风险识别的最终结果。

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

第二个问题是，如下图所示。当某笔业务事件刚进入风控系统时，由于图数据的写入是通过消息队列推送的方式进行的，可能会出现以下情况：当该业务事件中包含的 3 个元素（U1、W1、V1）尚未被写入图数据库时，系统就要求查询 U1 的关联信息。这时，系统无法查询到 V2 和 U2 的信息。

为了解决这个问题，我们提出了一个解决方案，即将单个关联改为群组关联 。这样，即使这些元素尚未被关联写入图数据库，也能在同一笔业务事件中查找到这些元素的二阶关联邻居。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/60398af42cd61b7eadccf35690a2ce49.png)

**四、解决方案**

以下是我们的解决方案。

首先，对于第一个热点问题，我们会根据节点的标签类型（tag）查询其关联节点。如果某类关联数据（例如 U 关联 W）超过了规定的阈值，我们将其舍弃，以确保实时风控的高响应速度。
如下图所示，如果 U1 查询到的 W 元素数量超过了规定的阈值 X，我们将这些 W 节点剔除，不再参与下一阶的关联过程。然后，我们将符合要求的一阶关联结果节点进行合并和去重，作为二阶关联的起始点。接下来，使用同样的策略查询二阶邻居，最后进行数据的整理和合并。这样可以用较小的代价剔除热点干扰。

针对上一节提到的第二个问题，即同一订单中的多个元素因关联写入延迟导致无法查询的情况，我们也提出了解决方案。具体而言，我们将同一订单中的多个元素（如 U1、W1、V1）作为一个整体，并行查询它们的关联邻居，然后将各自的结果去重合并，最终返回综合结果。此方案在下图中有所体现。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/66accb5eac613c7c9fefa29ed72bb359.jpeg)

在上图所示的流程中，我们使用了一个关键的 nGQL 查询语句，如下图所示。该语句的作用是从一组起始点开始，根据它们的关联点的标签（tag）类别进行关联查询。对于超过热点阈值的某类关联数据，我们会进行过滤和剔除。
例如，在下图的例子中，起始点关联到的 W 元素数量已经超过了热点阈值，形成了一个热点，符合剔除过滤的条件。因此，W 元素将返回一个空列表，表示不再参与下一阶的关联查询过程，从而避免了热点对风控系统性能的影响。

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

**五、业务收益**

我们借助 NebulaGraph 在对此风控业务场景进行落地实践的过程中，构建了一个实时图特征平台的应用逻辑闭环，结构如下图所示。
当一笔业务行为事件进入风控系统时，会同时异步写入到图特征平台和大数据平台。 风控系统在对当笔事件进行风险评估时，会实时调用图特征平台进行关联信息的补充，从而提高资质评估的准确性。
大数据平台则会定期对图特征平台进行补数操作，确保图库数据的完整性和一致性。 同时提升图特征平台的健壮性，可以在较短时间内快速恢复缺失的数据。

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

业务上线后，我们**额外获取了 55% 的关联业务信息**，通过这些新增的特征信息，使得**该场景下的覆盖率相对提升了32%** ，获得了良好的业务增益。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/37c11c8145d64cb79382663c6b8e17aa.png)

**六、未来规划**

图数据库是一个新兴的技术领域，因其天然的关联属性和查询优势，十分适合于风控场景，尤其是挖掘业务行为特征。携程集团在调研了多个图库之后，选定 NebulaGraph 作为主流支持的图数据库。

携程风控研发团队目前正在积极挖掘 NebulaGraph 的使用场景，后续会探索在血缘关系，欺诈团伙识别等场景的落地实践。

在此特别感谢 NebulaGraph 团队和开源社区的技术赋能，愿未来一路同行！

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
















携程使用 NebulaGraph 实现业务增益 32%

携程 x NebulaGraph｜业务增益 32%，NebulaGraph 在携程风控场景下的落地实践

![|](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/0715banner-05.jpg)
日前，金蝶征信泾渭云基于关系图谱技术和人工智能技术，推出产业图谱产品——“核企上下游名单查询”和“企业交易圈洞察”，将分别助力小微金融的获客营销和风控场景。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/jingweiyun0.jpg)
链上企业是一片待开发的蓝海。在真实的小微金融服务中，银行金融机构出于风险规避，偏好经营规模更大的企业。而最缺乏资金的尾部小微群体，作为中国经济的毛细血管，占比达企业总数 90%以上。

据新华信用《财税数据风控白皮书》调研分析显示，当一家企业与超过4家以上的大型企业存在稳定交易关系，其坏账率是普通客群的 51%；产业链上下游企业的平均风险比普通客群低 46%。

“我们在讨论小微金融服务时，常常会提及一个「不可能三角」理论，即同时实现「风险可控、成本可控、规模发展」三个目标。”产业图谱负责人表示，“**产业图谱有助于破解这个不可能三角。它就像一个雷达，通过关系链中的任意一家企业，可精准勾勒其产业链、关联核心企业以及其上下游企业画像，帮助银行金融机构从长尾小微群体中批量筛选优质企业、识别风险企业。**"

## 提供「核企上下游名单」查询，助力银行批量获取链上优质客户

从事产业链知识图谱研发，一方面要有大量企业授权交易数据积累，另一方面需要掌握较为扎实的算法技术。金蝶征信与百余家金融机构合作，累计服务数百万小微企业，基础大数据库已覆盖**全国 2 亿+工商司法数据库**、**4000 万+交易企业节点**，自研的“泾渭云”大数据征信云服务可以实现秒级响应千万量级计算。

在构建“产业+行业+企业”的知识图谱体系基础上，泾渭云引入**NebulaGraph** 分布式图数据库技术，提供多个产业链、行业分类和企业标签，通过对企业和上下游产业链关系紧密度的分析，批量筛选出符合银行小微金融业务要求的客户白名单，并为企业智能匹配银行供货贷、采购贷、订单贷等金融产品。据悉，“核企上下游名单”最高可识别与认定核心企业存在 6 层交易关系或股权关系的小微企业。以某商业银行为例，银行可识别到的与核心企业直接交易的优质小微企业，占到了白名单企业数的 10%

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

## 企业交易圈洞察，帮助透视隐藏的企业风险

管理学大师彼得·圣吉说：“所谓系统思考就是看见整体的修炼，看见相互关联而不是单一的事件，看见变化的形态。”在风控板块，产业图谱同样发挥着重要作用。

产业图谱的“企业交易圈洞察”服务，在获得查询企业的授权后，可根据该企业的发票购销交易关系及工商股权关联，构建企业网状产业知识图谱，评估企业之间交易的真实性、紧密性及连续性，包括关系企业是否有上市公司、企业本身是否存在失信等负面信息，构建更真实全面的小微信用画像，降低信贷投放风险。

近年来，国家提出梳理在产业链上发挥强链补链稳链作用的优质中小微企业，形成产业链图谱或链企名单，列出融资需求清单，倡导金融服务更多延伸到链上小微企业。

在普惠金融从“增量”迈向“提质”的新阶段，泾渭云推出的产业图谱系列产品，或许可为行业提供新的解题方向。目前，泾渭云针对不同业务需求为银行提供定制化解决方案。对于优质客户，提供提额方案，助力其实现更快速的发展；对于风险表现欠佳的客户，通过降额措施，帮助控制风险。

对图数据库 NebulaGraph 感兴趣？欢迎前往 **GitHub** ✨ 查看源码：**https://github.com/vesoft-inc/nebula**

泾渭云金蝶征信利用 NebulaGraph 技术，通过产业图谱助力银行挖掘企业关系链，实现批量获客和风控。

NebulaGraph 助力金蝶征信产业图谱深挖企业关系链，实现银行批量获客 

本文整理自 NebulaGraph 核心开发 Yee 在直播《聊聊执行计划这件事》中的主题分享。

 # Part 01.一条 Query 的一生
在开始正式地解读执行计划之前，我们先来了解在 NebulaGraph 中，一条查询语句（Query）是如何被校验、生成语法树，到最后被转为逻辑 / 物理的执行计划。而这个 Query 生命周期，无论是 NebulaGraph 原生查询语言 nGQL 或者是从 v2.x 开始兼容的 openCypher，都会经历从字符串到执行计划的过程。这个过程对应到编程语言，是一个编译的过程。

查询语句的生命周期大概有以下几个阶段：
![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-1.png)

同大多数的数据库类似，一个 Query 的字符串会经过 Parser（词法语法解析器），转成一个 AST（抽象语法树）。而抽象语法树中，不同的查询语句会转成不同的抽象语法树节点。再经过一道 Validator（校验器），进行语句的合法性校验。校验阶段，主要是根据创建点边元素的 Schema 信息（元数据信息）。**由于 NebulaGraph 查询语言设计之初是 schema-based 的设定，因此在语句查询时可（基于语句上下文关系）事先进行相关推导，比如某个查询会用到哪些（Schema）类型。**

这里插个知识点，在 NebulaGraph 中需要注意两个关键类型：EdgeType（Edge）和 Tag（Vertex），像每条 Edge 对应的边类型 EdgeType，其包含的边类型属性都是有具体的 Data Type。此外，便是每个点 Vertex 的属性，每个点的属性都会归类放到对应的 Tag 中，变成其对应的点类型属性 Tag property。类比关系型数据库的话，Tag 相当于是一张表。在 NebulaGraph 中，点和边的属性虽然受到 Schema 约束，但是对某个边的两端点对应的类型是不作约束。因此，插入点或者是修改点，是通过 ID（VID）进行相关操作，与点类型无关。

回到上面的 Query 生命周期，在进行语句校验之后，将之前的词法转成 NebulaGraph 中包含特定算子的执行计划 Execution Planner。随后，执行计划会经过一道优化，通过优化器 Optimizer 变成更优的执行计划，再交由调度器去执行。在传统的数据库中，执行计划分为逻辑计划和物理计划，但在 NebulaGraph 中目前只存在一种计划，便是物理计划，像上面流程图中，Optimizer 处理的计划便是一个物理计划。因此，经过 Optimizer 优化过的 optimized plan，其实是一个可直接执行的物理计划。

而执行计划的运行，主要是由上图的 Executor（其他数据库可能叫 Operator）完成。在执行这层，会涉及到接口交互，例如：同 storage 层“打交道”，会调用 rpc 接口；同 graph 层交互，会调用一些计算算子，像上图加粗的 Project、Filter 这种纯计算算子。除此之外，执行还会涉及到执行模型，比如多线程、Runtime 等问题。社区中大家遇到的一些执行性能问题，可能就同它们有关。

 # Part 02.执行计划示例

`GO 3 STEPS FROM "player100" OVER follow WHERE $$.player.age > 34 YIELD DISTINCT $$.player.name AS name, $$.player.age AS age | ORDER BY $-.age ASC, $-.name DESC;`

示例出处：《nGQL 简明教程 vol.02 执行计划详解与调优》🔗 网址：https://discuss.nebula-graph.com.cn/t/topic/12010

这是一个典型的 nGQL 查询语句，通过 GO 子句遍历，再通过 WHERE 子句进行过滤，最后经由 ORDER BY 排序输出。

下图是上面查询语句生成的执行计划：

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

如上所示，这个执行计划还是相对比较复杂的。它同大家见惯的关系型数据库的执行计划不大一样，像右下角的 Loop，左上角单依赖的 LeftJoin 可能同大家之前接触的都不大一样。

从结构上看，同 Neo4j 的树 Tree 结构不同，NebulaGraph 中的执行计划，不仅有方向，还有环。为什么 NebulaGraph 的执行计划结构如此不同呢？

`explain format="dot" {
 $a=go 2 steps from "Tim Duncan" over like yield like.likeness as c1;
 $b=go 1 steps from "Tony Parker" over like yield like.likeness as c1;
 $c=yield $a.c1 as c1 union yield $b.c1 as c1;
}`

我们来看一下上面这个例子，这里定义了 a、b、c 变量。a 和 b 之间不存在任何关系，都是几跳遍历之后，输出结果。而 c 则是对这两个变量进行了 union 操作。我们来看看这三条语句对应的执行计划：

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

可以看到，第一条语句跟第二条语句，还有第三条语句，在执行依赖上是一个顺序依赖：以上图黄色圈为分界线，黄色圈以下为 a 的 plan，黄色圈以上、Union_11 以下为 b 的 plan，Union_11 及其以上为 c 的 plan。

而数据依赖可以看箭头部分，Project_9 的数据依赖输入为 a，它是由 Project_4 提供的，而非顺序上下方的 PassThrough_13，同理，Project_10 数据依赖是 Project_8 的输出变量 b。

这里需要花点时间区分的是：执行依赖和数据依赖。执行依赖就是上图黑色箭头的顺序依赖，而数据依赖则要看算子对应的 inputVar 来自哪里。因此，数据依赖可能同执行依赖是同一个逻辑顺序，也可能是不同的顺序。

造成上述情况的原因是，nGQL 这个查询语言本身是非常灵活的。不同于 SQL 将 a、b、c 分别生成执行计划，生成 3 个执行计划，在 NebulaGraph 中，像上面这种 a、b 没有数据依赖关系，c 依赖 a、b，在生成 plan 的时候，会将其当成拥有一定顺序 subsequential 的语句进行处理。一条执行计划便可完成多条语句的执行，当然非常灵活，但也变相地增加了语句调优的难度。

再来看一个 openCypher 的例子：
`match (v:player)
with v.name as name
match (v:player)--(v2) where v2.name = name
with v2.age as age
match (v:player) where v.age>age
return v.name`

在这个多 MATCH 的例子中，每个 MATCH 都可以作为一个 Pattern。像这条语句中第一个 MATCH 的输出结果传递给下面的第二个 MATCH 变成过滤输入，而第三个 MATCH 的过滤输入则来源于第二个 MATCH 的输出。每个 MATCH 通过 WITH 进行连接，它不同 nGQL，存在 Subquery 的概念，在 openCypher 这里，数据依赖关系是线性，非常自然地通过一个个 WITH 传递给下一个 Pattern 的。如果第一个 WITH 没有将结果带到第二个 MATCH，第三个 MATCH 便无法完成。

正是因为这种线性关系，Neo4j 的执行计划是树状的；而 nGQL 因为查询灵活性的缘故，生成执行计划中有向有环图。

 # Part 03.执行计划的优化

目前，NebulaGraph 只做了 RBO 优化，即：Rule-Based Optimization 基于规则的优化。NebulaGraph 的 RBO 是基于业界流行的实现方法，有些许的差异化，用户可以基于之前的经验或者相关规则，进行 plan 的优化（变形）。

NebulaGraph 的 RBO 是以 memo + bottom up 方式进行的。

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

在 NebulaGraph 中，每个 plan 的 plan node 会放到一个小组 group 中，每个 group 中的 plan node 语义上等价，上一个 group node 连接到下一个 group，而下一个 group 中有多个 plan node 的话，便可变化出多个 plan。

整个优化的过程，其实是一个迭代的过程，优化器会找到每个 plan 中最叶子的 plan node，同规则集进行匹配，规则集可以查看这里：https://github.com/vesoft-inc/nebula/tree/master/src/graph/optimizer/rule。如果规则匹配上，则将两个 subplan 进行变形，生成新的 subplan，并插入到相关的 group 中。

比如上图左侧的 Filter 算子，它和 GetNeighbors 算子通过某个 rule 匹配上了，便会生成新的 GetNeighbors node，它带有 Filter。新的 GetNeighbors node 会插入到之前的 Filter 所在的 group，因为 memo 的原因，新的 GetNeighbors 便可同之前的 GetNeighbors 连接的 subplan Start 进行连接。

基于 RBO 默认如果匹配上规则，则匹配上规则之后生成的新的 plan 是优于之前的 plan，新的 plan 会直接替代旧的 plan。因此，这个执行计划最后会变成右侧这样。

# Part 04.几个执行计划调优的 flag

上文提到过，执行计划中会有个 Runtime 阶段，下面参数主要是影响 graph 这边 Runtime 阶段的执行效率。

- max_job_size: 每个算子内部并发的最大 job 数；

- min_batch_size: 算子内部并发执行时，切分任务时的最小 batch 行数；

- optimize_appendvertices：AppendVertices 算子内部的性能优化控制，当没有悬挂边时可以打开该项减少 RPC 调用。

max_job_size 主要控制 graph 部分算子的并发程度，同 min_batch_size 配合使用。这和 NebulaGraph 的物化模型有关，在 NebulaGraph 中每个算子在被执行完之后，其结果会被物化到内存中，在下一次迭代的时候去对应内存中捞取数据，而不是通过 Pipeline 的方式进行计算。max_job_size 和 min_batch_size 这两个 flag 控制了迭代过程中每个线程可处理的 batch 数量，从而达到优化的效果。

optimize_appendvertices 参数主要是用来服务 MATCH 语句的，当我们使用 MATCH 时，可能会常遇到一个情况：用 MATCH 去做路径查找时，希望这个路径中是不存在悬挂边的。假如，你知道你的数据中不存在悬挂边，可以设置 optimize_appendvertices 为 true，这样就无需再同 storage 交互去验证是否这条边的起始点存在，从而会节约执行时间。

 # Part 05.执行计划如何看
上面说了些原理，下面可以实操下，教你看懂执行计划，以及如何去优化它。

将 PROFILE 或者是 EXPLAIN 加在对应的语句前面，即可得到相关的执行计划。像这样：

`profile GET SUBGRAPH 5 STEPS FROM "Yao Ming" OUT like where like. likeness > 80 YIELD VERTICES AS nodes, EDGES AS relationshipis;`

`explain GET SUBGRAPH 5 STEPS FROM "Yao Ming" OUT Like where like. likeness > 80 YIELD VERTICES AS nodes, EDGES AS relationshipis;`

如果你不知道数据量的情况下，用 EXPLAIN 可查看对应的执行计划构成，它不包括该语句各个算子的执行时间。

在社区中，常会到一类问题：我通过 SUBGRAPH 进行条件过滤时，是不是每一跳都会应用到边过滤。相信通过这个例子，你就能知道是不是每跳都会应用到条件过滤了。

`Execution Plan (optimize time 41 us)`

生成在终端的这个执行计划是表结构的，通过 id 和 dependence 可查看到对应的依赖关系，从而解决之前提到过的执行计划中有环这种问题。

先看看当中 subgraph 算子信息，我们可以 edge_filter 中带有表达式，如果 edge_filter / tag_filter 中带有表达式，则表示该表达式被计算下推了。

下面是通过 PROFILE 查看到的更具体的执行计划。
![appendvertices](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-5.png)

DataCollect 算子有这些参数：

- execTime：graphd 的处理时间；

- rows：返回的数据条数；

- totalTime：从算子起始到到算子退出时间；

- version：像前面章节提到过的 LOOP，其实 LOOP 里面有一个 LOOP body，对应也是一个 subplan。而这个 subplan 则是会被重复执行，且数据放在同一个变量当中，而这个变量则会有多个版本，即 version。假如算子不在 LOOP body 内，则只有一个 verison。默认为 0；

Subgraph 算子有这些参数（同上面已讲解参数去重）：

- resp[]：每个 storage 节点执行的结果；

- exec：storaged 的处理时间，同上面的 graphd 处理时间的 execTime；

- storage_detail：storage 信息，由于 subgraph 需要同 storage 交互，因此由这个字段用来记录 storage 这边 plan node 的执行时间；

- total：storage client 接收到 graphd 请求到 storage client 发送请求的时间，即 storaged 本身的处理时间加上序列化和反序列化的时间；

- vertices：该语句涉及的点的数据；

- total_rpc_time：graphd 调用 storage client 发出请求到接收到请求时间；

 # Part 06.生成执行计划的格式

在刚开始的时候展示的执行计划和实操时展示的执行计划格式并不相同，profile format="" 来完成格式指定，默认为表结构，可通过格式指定，指定为 .dot 格式，在终端复制出来执行计划，前往在线网站：https://dreampuf.github.io/GraphvizOnline/#digraph 进行格式渲染。

以上，便是一个全方位的执行计划讲解。当然你可以通过阅读思为的《nGQL 简明教程 vol.02 执行计划详解与调优》，了解更多的例子从而掌握执行计划。

----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

同大多数的数据库类似，一个 Query 的字符串会经过 Parser（词法语法解析器），转成一个 AST（抽象语法树）。而抽象语法树中，不同的查询语句会转成不同的抽象语法树节点。

从真实案例出发，全方位解读 NebulaGraph 中的执行计划

> 本文整理自 五矿集团-五矿期货有限公司副总经理-张剑锋 在 NebulaGraph 2022 年度用户大会上的分享。现场视频如下——

大家好，我是五矿期货的张剑锋。今天十分感谢 NebulaGraph 能够提供这个跟各位专家，还有行业技术大拿们当面学习和交流的机会。

首先介绍一下期货行业。在中国的六大金融行业里面，银行，保险，还有信托，是银保监会体系下的，俗称大金融行业。期货行业属于证监会管辖下，有证券期货和基金，属于小金融行业。

我们这个行业有三大主要的功能：发现价格，管理风险，还有配置资源。发现价格重点给大家介绍一下，因为期货市场的参与者众多，除了有生产者、贸易商，还有我们消费者，以及市场上大量的投机者。因为有这样不同类型的大量的交易者在期货市场上通过多空博弈产生出来一个价格，是相对客观和真实的，所以可以用于指导这些产业客户和实体经济相关参与者安排自己的生产和经营活动。

期货行业最主要的作用是服务实体经济和产业客户，所以我们这个行业的特点也是和实体经济挂钩会比较紧密。这几年才兴起的像保险+期货、乡村振兴、场外期权等等都是直接服务产业客户的业务模式。

下面介绍下五矿期货的一些情况。 五矿期货是中国五矿集团旗下的金融企业，**五矿集团是 16 年五矿集团和中冶集团两家世界 500 强企业战略性重组，最新的世界 500 强排名是 58位**。五矿集团是国家的金属资源领域的冶金建设国家队，我们的控股股东是五矿资本有限公司，是 A 股的上市公司，也是隶属五矿集团的，然后我们也是一个 **A 股市场稀缺的全牌照的金融控股公司**。

# 为什么要搭建知识图谱平台？

## 知识图谱的价值

关于知识图谱的价值，我来谈一下我们的理解。

![知识图谱的价值](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/7.jpeg)

因为期货行业是一个信息高度密集的行业，我们日常的经营过程中会产生大量的结构化数据，数据类型也很多。除了像各种的客户的交易数据，还有一些像客户行为埋点数据、用户事件数据等等。同时还有很多非结构化的数据， 像各类研究报告，新闻资讯。

另外，由于监管对我们业务有特殊要求，比如客户开通特定品种要求的双录等会产生大量的音频视频数据，所以（拥有）大量多维的、多类型的数据是期货投资行业的一个特点。**我们认为利用知识图谱能够实现数据的汇集和治理、知识挖掘和应用，以及辅助业务分析和决策**。


另外，期货行业也是知识密集型行业，因为期货行业的业务规则很复杂还会经常变化，所以如何把知识沉淀到公司，作为公司知识的传承，还有在知识基础上做相应的智能化的应用都是非常重要的，所以我们认为知识图谱在我们这个行业会有很大的作用和意义。

## 知识图谱的优点

![知识图谱的优点](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/8.jpeg)

从技术方面，知识图谱的优点大概有四个方面——

**第一，灵活的多维数据叠加**

孤岛的数据其实是没有太多意义，也不利于数据的挖掘和分析。而图结构比较灵活，通过图的点面关系，可以把有价值的多维数据叠加和连接在一起，会有更大的意义。

**第二，依托经验分析可解释**

因为在图谱上模型设计和决策，它的计算路径和过程是很清晰的，可以使用图很方便地回溯推导过程，并可以和人的经验相互应证。

**第三，数据的高效直观表达**

图数据相对来说是比较容易可视化的，通过将知识图谱可视化展示给用户，可以使用户快速学习或者是发现新的知识。

**第四，增强现有模型准确率**

因为使用知识图谱技术把整个数据拉通之后，有助于数据的数据质量的提升，同时可以提高整个模型的准确率。

# 使用过程中面临的困境

![使用知识图谱面临的困境](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/9.jpeg)


在我们实践和探索过程中，我们也遇到了一些困难。总结起来主要有三点，第一个就是因为知识图谱技术相对来说比较新，在我们这个行业里应用几乎没有，所以我们只能去摸着石头过河去一步一步来，这个过程其实蛮艰辛的。


第二个就是人才，我们对传统的数据库还是有一些人才储备的，但是现有新的领域，招聘人员、储备人员、培养人员都需要很长的时间，这是第二个痛点。

第三个就是业务部门认知不到位，这也导致参与度不高，所以推进就没那么快，所以刚建的时候走走停停，推的过程就比较困难。

## 如何走出困境

![五矿期货是如何成功走出困境的](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/10.jpeg)

面临这种困境，我们很庆幸就是说找到两家很好的合作伙伴，一个是今天的东道主悦数科技，我们认为他们是一家很好、很可靠的公司，**NebulaGraph 图数据库除了稳定可靠、性能高效，另外还是国产的，而且是支持信创的。因为我们公司是证监会指定的信创试点单位，所以综合考虑我们认为 NebulaGraph 图数据库是最佳的选择方案**。

另外要感谢的就是普适智能，因为我们是缺乏技术储备的，我们就比较依赖厂商的支持。**普适智能是很专业地专注于知识图谱的应用，而且他们愿意深耕金融行业，对金融行业的业务模式有比较深的沉淀，所以他们可以给我们提供一站式的知识图谱平台的解决方案**。

我们很多的业务场景都是 NebulaGraph 和普适在驻场和我们业务部门、技术部门一起配合很长时间梳理清楚，把业务搬到知识平台上，帮我们一步一步搭建起到现在这样一个平台，所以在此十分感谢这两个公司。

# 知识图谱在期货行业的应用场景

## 场景一：辅助投研

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/15.jpeg)

这是我们投研平台知识图谱应用的一个逻辑图。首先我们公司会有很多的内部数据，包括一些非公开的数据、行业的数据，还有一些外部数据，包括我们购买的很多商业数据源、数据研报等等。内外部数据打通之后，我们**依托知识图谱平台实现了知识的沉淀复用，为后续产业链的研究，研报的生成，以及风险预测等等这些业务场景去赋能**。

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/16.jpeg)


这是我们整个投研过程的描绘：研究员从发现线索出发，然后整理相关资料，经过分析研究框架的判断，最终形成投资决策和应用。


传统来说以前就是数据纯粹的罗列，检索也比较简单，然后我们用知识图谱平台可以**实现自定义的投研主页，让用户每天高效获取他所需要的信息，而不需要去浪费过多时间去找线索**。另外就是我们优化了检索算法和信息展示的交互界面，形成了更加贴合用户习惯的页面，提升了信息获取的效率和用户的使用感受。


之前数据比较割裂，因为搜集数据的渠道来源很多，也很不方便，通过这个平台把多维的数据整合，加上自有数据的上传，还有指标编辑等功能，实现了数据收集效率的大幅提升。


然后我们底层使用的是批流一体的图谱技术，让数据更加及时，拓展性也更强了。以前的分析判断过程是研究人员分析判断完全依赖个人经验，分析工具也比较少，导致效率比较低。我们**通过机器学习来辅助数据的分析和挖掘，能够主动定位可能的分析方向，提高探索效率**。


在决策和应用阶段，以前研究人员仅是能够生成这个报告，但是写的报告一个是精度可能比较低，另外它的准确度有可能会比较模糊，所以**我们联通了用户的分析过程和报告产生的过程，然后能够快速获取研究分析所依赖的数据以及分析的流程，帮助他们去提升整个分析的逻辑，让数据和研究员的个人经验去做一个印证**。有可能他的知识或者他的框架可能有错误和偏差，通过这样的数据分析也可以优化。

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/17.jpeg)

具体来说，辅助投研场景是这样的——因为期货行业里面有很多品种是存在比较强的相关关系的。比如说原油，它的衍生品有燃料油、化纤、化工类产品、沥青等等。

一个品种的价格变动，对相关的品种都是有影响的，所以我们投研平台第一步就要先要找到对应关系，把它在这个平台上用图谱形式去展示出来，然后通过一些模型的训练，除了找到影响的关系之外，还要找到影响的程度，就是它的权重。

当然了，这要经过大量的模型训练或者验证，**通过找到一个品种价格变化传导到其他相关品种价格的关系，来辅助研究人员做相应的研判**。

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/18.jpeg)


除了品种之间有较强的相关性之外，期货行业有些相关品种的产业链是比较强的，因为上游可能有很多层级，下游消费方可能也有很多的节点，所以我们**以研究员的视角，在平台上绘制出整个产业链的结构图，目的是找到整个产业链的价格传导机制**。


图上展示的就是能源板块的一个产业链。比如煤炭，除了国家的政策会影响到煤炭的生产之外，衍生品的情况也有影响。煤炭的衍生品也就是产业链下游，就是焦煤、焦炭，还有动力煤。动力煤是用来发电的，焦煤焦炭是用来炼钢的，第一步先练成粗钢，然后粗钢再炼成螺纹钢和热轧卷板，同时钢这个黑色品种又和铁矿石有关系，铁矿石除了炼钢之外，它还有像锰铁锰硅之类的一些副产，研究人员在这个平台上可以把这个品种的整个上下游产业链和它的关联关系去描绘出来。

**对研究人员本身来说，他借助这个平台可以提升自己的知识，同时这个平台在使用过程中也会逐渐的增强自身的能力和价值**。



## 场景二：金融事件分析

![五矿期货知识图谱应用场景二：金融事件分析](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/20.jpeg)

第二个场景是金融事件分析。因为期货行业的价格影响，除了既有的产业链模型之外，还有很多突发性事件，类似于黑天鹅事件， 所以舆情或者资讯对商品的价格可能也会有很大的影响。

所以我们也做了这样一个模型，而且这个模型会持续地去打上时间的标签，因为时间对行情的影响是有很大的影响的，越老的资讯可能影响度就更低一些。

![五矿期货知识图谱应用场景二：金融事件分析](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/21.jpeg)

举个例子，年初的俄乌战争对期货市场上的行情影响比较大，主要影响是两个，一个是镍这个品种大家可能都知道或者都看到过。因为俄罗斯是镍主要的供应国，发生战争之后，俄罗斯的镍不能够给中国出口，所以导致镍出现了极端的行情。同时，下游产品像不锈钢主要是用镍去生产的，所以间接也影响到不锈钢这个品种的价格走势。

所以我们希望能够以关联这个数据为基础，从期货行业固有的逻辑和实时事件双管齐下，通过平台实时洞察不同事件组合对特定商品价格影响的强度，同时也随时观察期货相关联的历史事件。

## 场景三：合规风控

![五矿期货知识图谱应用场景三：合规风控](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/22.jpeg)

场景三是合规风控，因为期货行业是一个高风险行业，所以无论是监管机构，还是期货公司自身的风控要求都十分严格，合规风控能力也是我们一个核心竞争力。

一般来说，我们有两类风控模型，一个是不同的客户在同一个 MAC 地址下，买卖期货合约品种以及它的交易行为时间点高度一致，它可能会存在“拖拉机账户”，也就说是一个客户操控了多个账户，这在期货行业里是不允许的。**通过图上的交叉关系或者汇聚的密集程度，合规风控人员很容易地去判断出这类行为**。

另外一类就是同一个账户，同时存在多个交易的 IP 和 MAC 地址，这类行为可能是有配资嫌疑的，结合其他数据和模型，我们可以更加精准地判断它是否存在配资的嫌疑。这对合规风控来说，极大提高了它的判断能力，我们可以对这类交易进行提前的干预，有效避免合规风险。

## 场景四：客户洞察

![五矿期货知识图谱应用场景四：客户洞察](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/23.jpeg)


第四类场景是客户洞察，我们基于客户交易行为进行汇总，把他们进行一些社群划分，比如感兴趣交易哪些品种、感兴趣哪类研报，我们把这些作为划分依据，用于进行相对精准的一些推送。

因为期货行业服务的同质化比较严重，所以我们也希望能够通过数据来做数字化的运营，**给客户提供差异化的服务和精准营销，实现更好的客户体验**。

## 场景五：智能运维 AIOps

![五矿期货知识图谱应用场景五：智能运维AIOps](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/24.jpeg)

AIOps 是我们最近才梳理的一个场景。像我们公司有十几个机房部署在全国各地，可能有上千台服务器，整个交易系统会产生大量的数据和日志等，而且不同的机房不同的系统之间网络也都是通的，一些应用组件都是互相调用的关系，它其实本身就是一个巨大的网络。


所以我们把这些运维的数据，服务调用的数据，还有批量作业数据设备部署的数据以及系统运行的日志数据，整合到这个平台里，然后把他们的关系提取出来，实体也提取出来，构建这样一个智能运维的模型。


我们可以更加细化到具体的运维设计场景，比如说故障影响分析，当某个节点或设备出现故障时，和它有关联的系统或应用也可能会存在问题。接下来根据业务调用关系，它（故障）有可能会传达到别的系统，还有可能会影响到不同类型的客户，所以我们要把关系描绘出来，以进行一些系统切换或故障通知等等。


另外就是变更，因为业务系统 80% 的风险，或者说它的故障运维事件，都是因为这个系统升级变更造成的。升级某一个组件可能会影响到哪些系统、哪些客户需要哪些部门的人去做一些干预或协调、怎么更好地去应急等，我觉得在图谱上都可以实现，以便更好地指导我们的日常运营工作。

还有像系统架构的分析，像系统架构合不合理、有没有存在单点的故障，这些我觉得都可以在图谱这个平台上去实现。

## 场景六：网络安全

![五矿期货知识图谱应用场景六：网络安全](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/26.jpeg)

另外一个就是网络安全，这块我们觉得也是可以应用到的。因为我们现在有这样一个安全监控平台，它的规则是基于系统产生的日志，如果日志发生了或者是平台感受到它和现有的规则不匹配，系统会产生告警信息。但是告警信息是一种孤岛， 哪里出现问题哪里告警，但是**我们希望能够把整个安全模型构建出来，然后找出故障的传导机制，进而分析出它可能会对哪些系统或者说网络安全环境造成影响**。

另外一个就是攻击行为或者说病毒，通过知识图谱可以更加方便、有效地回溯它的路径或者预测攻击行为，这样能够更加智能化地去辅助我们的安全管理人员去做好安全管理工作。

所以安全知识图谱，我们认为是作为安全领域的一个专用知识图谱，**它可以结合安全知识经验和数据发挥知识整合的优势，将离散分布的多元异构的安全数据组织起来，加速安全领域的智能化和自动化**。

# 总结&期望

作为第一家和 NebulaGraph 合作的期货公司，我们很荣幸，也希望更多的技术专家能够关注到期货这个行业，能够输送人才去指导期货行业金融科技的发展。所以最后感谢悦数科技，谢谢大家。


---

- **相关推荐**：

[《美团：图数据库平台建设及业务实践》](https://www.nebula-graph.com.cn/posts/meituan-graph-database-platform-practice)

[《中国移动：NebulaGraph 图数据库在金融风控领域的落地应用》](https://www.nebula-graph.com.cn/posts/cmcc-financial-riskcontrol-practice)

[《快手：百亿级图数据在快手安全情报的应用与挑战》](https://www.nebula-graph.com.cn/posts/kuaishou-security-intelligence-platform-with-nebula-graph)

[《微众银行：NebulaGraph 在微众银行数据治理业务的实践》](https://www.nebula-graph.com.cn/posts/practicing-nebula-graph-webank)

[《泰康在线：图数据库在理赔反欺诈及数据治理中的实践》](https://www.nebula-graph.com.cn/posts/tk.cn-knowledge-graph-practice)


高性能的原生分布式图数据库 NebulaGraph 目前已被 1000+ 企业采纳并应用于金融风控、实时推荐、知识图谱等多个场景， 欢迎点击 [下载《图技术应用案例集》 PDF 版](https://www.nebula-graph.com.cn/download-white-book) 查看更多真实用户分享～








五矿期货是世界 500 强企业中国五矿集团旗下的金融企业，作为首家使用 NebulaGraph 图数据库的期货公司分享了知识图谱平台在期货投资领域的应用和未来实践方向的探索及心得。