语势科技‍‍‍‍‍‍

语势科技专注于结合大模型和知识图谱的能力，构建以主题投资理论为核心的 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 图数据库的期货公司分享了知识图谱平台在期货投资领域的应用和未来实践方向的探索及心得。

五矿期货：NebulaGraph 图数据库在金融期货行业的应用与实践探索

> 本文整理自 中国移动算法工程师 汪海涛 在 NebulaGraph 2022 年度用户大会上的分享，现场视频如下——

<video width="100%" height="500" controls>
  <source src="https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/videos/nuc-2022/speaker-wanghaitao-chinamobile.mp4" type="video/mp4">
</video>

各位朋友上午好，我是来自中国移动的算法工程师汪海涛。接下来我主要聊一聊图数据库在中国移动，特别是金融风控场景的落地应用。

# 为什么中国移动要建设图平台？

## 「全国 9 亿用户，每天产生大量数据」

中国移动有非常多的数据，全国的用户每天都会产生海量的数据。**如何从这么大数据量里面挖掘出有用的信息，然后用到金融风控场景？这就是我们需要做的事情**。

之前，我们是以手机号为维度去提取特征，然后去做一些模型或规则判断一个手机号是否是有违约风险。但仅仅基于手机号很难综合去考虑风险情况，因此我们就想采用图计算技术去综合看一个手机号以及周围的其他手机号的信息，然后共同评判它的风险。

最开始是基于消费金融的场景，从比如说像蚂蚁金服、微信以及京东白条这样一些产品切入，通过用户通话数据、短信数据、设备等多维度的一些信息，去判断用户风险。但中国移动数据量这么大，**不管我们要做什么，最大的诉求就是需要有一个非常高性能的平台去支撑数据分析**。

# 为什么选择 NebulaGraph 图数据库？

## 「JanusGraph vs TigerGraph vs NebulaGraph」

我们最早是采用了 JanusGraph 加上 Spark 去建设我们平台，但是通过一些测试，我们发现 JanusGraph 的查询性能以及导入性能都比较一般，然后 GraphX 的话，它的计算性能其实也比较一般，特别是它需要的内存量特别大，因此我们后来又开始去调研了市场上很多的图产品，并且对一些图产品做了测试，包括国外的产品，像 TigerGraph 之类的等等，但是因为一些特殊原因，中国移动是在美国商务部的实体清单上，所以很多外国的产品我们是没法去采购和使用的。

因此最后，我们是选择国内的几家厂商进行了一些测试和比较，**最后选择了以 NebulaGraph 作为图数据库，然后以 Plato 作为图计算引擎这样一个整体的架构**。


# 中国移动是如何搭建图平台的？

## 图平台建设概况

![中国移动_以NebulaGraph为底座的图数据库平台概览图](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/4.jpeg)

我们整体的架构大概是这样的——

**最底层是我们的数据源**，中国移动建设有一个全国大数据中心，主要包括通话数据、位置数据、消费数据、设备数据、用户数据和 APP 数据等等，我们每月把这些数据抽取到 HDFS 里面，然后把其中有用的数据抽取到 NebulaGraph 数据库里面，那么这里用的就是 Nebula 的一个导入工具，这是我们图数据存储这一层。

**再上一层是计算分析层**，这也是我们建模和业务分析人员主要使用的一些框架。首先第一个是 Plato，它是腾讯之前开源的一个图计算引擎，但是据我所知腾讯现在已经不维护这一套引擎了，因此我们也是专门找一些工程师，然后去维护这里面的一套框架，以及修复一些小 bug 之类的。

那么它包含的算法其实很多的，这里我主要是列举了两个社区发现算法、Louvain 算法和 HANP 算法。它里面还包含一个 LPA 算法，因为LPA 算法的话是 HANP 算法一个简化版，所以这里我没有列出来。

然后里面还有一个我们有可能后面会用到的关于随机游走类的算法，主要是基于随机游走得到一个节点序列，会为我们后面用于图神经网络训练做一个前期数据预处理的工作。

第三个是 GNN，就是图神经网络。图神经网络是最近几年兴起的一个领域，我们现在主要是基于这些模型做一些简单的产品，看看能不能取得比以往的方法更好的一些效果。最后就是基于 NebulaGraph 查询语言，主要就是 go 语句和 fetch 语句做一些简单查询。

**再上一层的话就是应用层**。首先是关联风险分，关联风险分主要是基于配套的社区发现算法来做的。第二个号码风险分和最后一个催收分析主要是基于 Nebula 的查询语句来做的，主要就是查询用户跟一度、二度联系人以及一些违约用户，或是催收专用号码进行一些主动或被动的呼叫。第三个信用评分卡是基于图神经网络来做的，主要是用逻辑回归或者决策树之类的模型，希望通过图神经网络做一些提高。

## 图数据结构介绍

![中国移动_导入图数据库的点边数据结构](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/7.jpeg)

- **点数据**

点数据主要是有四类，第一个是手机号，手机号也是我们最重要的点数据，主要是包括比如这手机号它是属于哪个市的，是否发生过停机等等，还有一些消费信息。第二个是地理位置，主要基于基站。第三个身份证，作为唯一身份证识别，可能也会有年龄或学历之类的标志。最后是设备信息，一般手机会有一个设备值，有对应的型号、设备系统等。

- **边数据**

目前边数据的话，一个是用户跟用户的通话数据，第二个是手机号和身份之间的对应关系，第三个是手机号和设备之间对应关系，第四个是手机号跟地理位置之间对应关系，那么这些是我们在图数据库里面保存的一些数据。


# 图技术在中国移动有哪些应用？

## 应用1：号码风险分

![中国移动_怎样建立号码风险分模型](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/8.jpeg)

首先是号码风险分模型，**主要用在羊毛党识别这个场景**。我们会根据用户的通话流量位置以及手机行为信息去判断一个号码有没有可能是个羊毛党，主要通过四个模块——

第一个是接码模块，我们会跟一些外面数据公司合作，判断一个号码有没有可能是一个接码号码，如果是，我们会认为这个号码是薅羊毛的可能性就很大。

第二个行为异常号码，比如说这个手机号是否当月一次通话都没有，然后是不是每月都基本只有固定的月租这样的消费。这种号码我们认为它可能是一个小号，或者是专门用来去薅羊毛的号码。

第三个是位置异常，比如说这个手机是否一个月下来就是在一个位置从来没有动过，可能只是放在家里偶尔用一下，不会带出去这种。对于这种号码的话，我们认为它的风险也是相对比较大的。

![染灰模块是什么、怎样实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/9.jpeg)

**第四个是染灰模块，图技术主要就是用于这个模型**。基于前三个模块的结果，我们首先获得了一批已经确定的羊毛党用户，那么我们可不可以发现他的一些共同特征？比如说可能有几个羊毛党（号码）是属于同一个用户的，那么我们是不是可以看看这个用户下面其他手机号是不是也可能是羊毛党？

另外，如果发现有一堆手机号是之前在同一个设备上使用过，我们可能也会认为这个设备上对应的其他手机号也可能会是一些羊毛党。专业的羊毛党会采用卡池这种设备专门去薅羊毛，用图技术就可以快速发现并识别。


## 应用2 ：关联风险分

![关联风险分是什么以及应用场景](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/10.jpeg)

然后是关联风险分，通俗来说就是「近朱者赤近墨者黑」。

在平时交际圈，如果你的违约可能性比较低，那么周围人可能违约性也会比较低。基于这样一种想法，我们主要做法就是首先基于移动所有用户构建一个关系网络，然后采用一些社区发现类的算法去挖掘这个社区中个人的评分以及个人之间的关系，通过对这个社区打分，去识别出这个社区是否是欺诈或低信用社区。

**关联风险分的主要应用场景就是欺诈领域，比如信贷欺诈、交易欺诈、营销欺诈、支付欺诈以及账户欺诈等等多个方面**。

## 应用3：图神经网络（GNN）

![图神经网络在中国移动的应用](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/12.jpeg)

最后是关于图神经网络的一些应用，**主要是用于金融风控信用评分卡的场景**。过去我们用做信用评分卡大部分都是先提取用户特征，再然后训练一个逻辑回归模型或者是角色数字类的模型。

那么现在，我们想通过图神经网络做一些模型，通过用户之间通话数据，比如近三个月主动通话、被动通话以总通话次数是否达到要求，去判断要不要保留这样一条边。

我们大概提取 100 多个主要的特征去录模，这里的模型相对来说比较简单，目前是尝试了一个双塔的模型，左边的是关于图神经网络聚合的这样一个模型，右边用户特征本身的一个全连接网络做了这样 MLP 的模型。左边的神经网络聚合，是比较简单也是最常用的——GCN、GrapSAGE 和 GAT 这三个模型。

另外我们现在采用的是一个同构图的网络建模，后面可能会考虑异构图，比如说考虑用 HAN 这样的一些异构图的模型去建模，把用户的身份证和设备以及位置信息这些点都归纳进来，然后一起进行建模。

# 图数据应用的未来展望

![中国移动_图数据库平台的未来展望](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/14.jpeg)

## 1.数据血缘

中国移动大数据中心会提供给大概 30 多家客户的 50 多个项目进行共同的建模，建模工作里包含的数据维表会特别多，因为我们会给每个用户都匹配数据，然后帮他们生成特征，最后会把结果表也保存在数据库里面，大概现在有 1000 多张数据表，平时基本靠人工管理，后面看看能不能通过数据血缘的方式去做一个归纳。

## 2.图神经网络

中国移动除了大数据中心，还有人工智能中心，那里有很多的 GPU 资源进行人工神经网络的训练，但是目前模型训练效率比较低下，所以后面看看怎么用图数据技术去解决这个问题。


- **相关推荐**：

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

[《五矿期货：图数据库在金融期货行业的应用与实践探索》](https://www.nebula-graph.com.cn/posts/wukuang-graph-database-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 企业版的最新特性？
点击 [链接](https://www.nebula-graph.com.cn/contact)，立刻开启您的图数据库之旅！


拥有9亿多用户的中国移动基于NebulaGraph 图数据库搭建的图平台在金融风控领域有哪些落地应用？一起来看中国移动的算法工程师汪海涛在NUC2022上的精彩分享。

中国移动：NebulaGraph 图数据库在金融风控领域的落地应用

同盾科技是一家专注决策智能的人工智能企业，其基于 NebulaGraph 图数据库技术打造的知识图谱平台在金融保险、政府公安、互联网等行业有广泛应用，一起来了解下这套全栈式解决方案的优势以及NebulaGraph 在其中发挥的重要作用吧。

同盾科技：聊聊知识图谱在金融风控场景中的应用｜NUC2022



![58 同城基于 NebulaGraph 一键部署运维架构的实践](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58%E5%90%8C%E5%9F%8E_%E7%94%BB%E6%9D%BF%201.jpg)

# 图计算业务背景介绍

## 我们为什么选择 NebulaGraph？

在公司各个业务线中，有不少部门都有着关系分析等图探索场景，随着业务发展，相关的需求越来越多。大量需求使用多模数据库来实现，开发成本和管理成本相对较高。

随着图数据库的发展，相关系统应用越来越成熟，于是引入专业图数据库来满足这部分业务需求的事务也提上日程。接下来要考虑的问题就是图数据库选型了。

首先，NebulaGraph 有大量互联网大厂应用案例，说明 NebulaGraph 可以应对海量数据的图探索场景。另外，目前 NebulaGraph 在 DB-Engines 在图数据库领域排名 14，而且增长势头强劲。排名靠前的图数据库，部分不开源或者单机版开源，场景受限。

![图计算业务背景介绍](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-1.png)

## NebulaGraph 实际测试表现如何

在导入性能上，数据量小的时候 NebulaGraph 的导入效率稍慢于 neo4j，但在大数据量的时候 Nebula Graph 的导入明显优于其他两款图数据库。在 3 种查询场景下，NebulaGraph 的效率都明显高于 neo4j，与 HugeGraph 相比也有一定的优势。

![图计算业务背景介绍](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-2.png)

## 适用场景有哪些

公司有多种线上业务，工程复杂度和架构复杂度都较高，各个业务部门都需要专门的图数据库来实现对实体关系数据的处理和探索。

通过图数据库实现对任务依赖的运行时间进行监控，及时获取延迟任务、销售激励平台任务血缘关系处理、分析应用内部的类/方法级调用关系、业务风险数据分析、记录企业高管、法人、股东关系，用于签单业务等场景。

## 资源申请和集群管理方式

为了更好的管理和维护，图数据库在运维部门集中运维管理。用户按需在工单平台中提交申请即可，工单中填写详细的资源需求数据和性能需求指标，由运维同学统一审核交付集群资源。

公司目前服务器环境是自建机房，采用高配物理机，单机多实例混部数据库服务。为了实现规模化管理和维护，需要提前制定好实例标准和规则。

## 集群规模

得益于NebulaGraph良好的图计算能力，我们已经持续交付集群接近20套，目前还有业务部门在持续申请相关集群服务资源。


# NebulaGraph 规范和架构设计

由于需要满足大量业务需求，未来会有大量的集群需要交付和维护。为了高效管理和运维规模化的集群，需要提前规划和制定规范。

## 版本规范

目前使用版本为 2.0.1

## 路径规范

1）、程序路径为 /opt/soft/nebula201,该路径下有 bin、scripts、share 等，作为公共的服务依赖路径，从服务路径中抽离出来

同样，升级为 3.X 版本，只需要将程序路径抽离出来作为公共的服务依赖路径即可。

2）、服务路径为 /work/nebulagraph+graph 端口，该路径下有 data、etc、logs、pids

## 端口规范

1）、集群之间端口递增 5，因为 storage 副本需要端口通信，通常是 storage 端口 -1，例如两套集群 graph 端口分别是 60000 和 60005;

2）、每种服务端口和 http、http2 端口之间步长为 10000，例如 graph 端口是 60000，ws_http_port 就是 50000 ，ws_h2_port 就是 40000；

3）、三种服务端口之间相差 1000，例如 graph 端口是 60000，meta 端口就是 61000，storage 端口就是 62000；

60000 graph 端口；  50000 ws_http_port；40000 ws_h2_port

61000 meta 端口；   51000 ws_http_port；41000 ws_h2_port

62000 storage 端口；52000 ws_http_port；42000 ws_h2_port

## 运维规范

1）、创建 space 需用 ngdb_ 左前缀，分片默认是节点数的 2 倍，副本数默认为 2，参考 CREATE SPACE `ngdb_demo` (partition_num=6,replica_factor=2,charset=utf8,collate=utf8_bin,vid_type=FIXED_STRING(128),atomic_edge=false) ON default;

2）、授予业务账号 DBA 角色：GRANT ROLE DBA ON ngdb_demo TO demo_wr;

3）、搭建一套 NebulaGraph 集群后，将内置账号 root的 密码重置，之后将 /work/nebulagraph+graph 端口路径打包生成 rpm，作为标准安装包

![NebulaGraph 规范和架构设计](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-3.png)

服务请求直接通过 DNS 和网关服务到 Graph，方便计算和存储服务直接交互，由于是通过 DNS 访问，不对外暴露 Meta 节点信息，可以更灵活的运维，较少服务绑定 Meta 节点 ip 带来的运维代价。

这种架构限制了Java 等驱动的访问，需要用其他驱动替代。

4）、基础集群套餐是 3 个 Graph 节点、3 个 Meta 节点、3 个 Storage 节点，在保证高可用的同时也能保证足够的处理能力。

基础集群分布在 3 台物理机上，存储和计算不需要过多的网络交互。

![NebulaGraph 规范和架构设计](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-4.png)

# 集群部署自动化实现

为了能够一键部署服务，集中式管理服务，我们需要借助远程管理工具 Ansible，能帮我们做到快速部署。依据三种角色服务的端口规范，生成 ansible 的配置文件。

![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-5.png)

* 由于将版本信息写到了配置文件中，在兼容多版本场景下，只需要在bootstrap.yml文件中增加相应判断即可，主程序兼容多版本成本非常有限。

部署实例时，根据 graph 角色分发文件，也可以每个节点单独分发文件。

* 依据三种角色，分别分发配置文件到目的路径下，并且按照文件命名规则生成最终配置文件。


```
more bootstrap.yml
- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init elasticsearch file on data
      command: cp -r /opt/soft/nebulagraph201 {{ nebula_home }}

- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init config graphfile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201graph dest="{{ nebula_etc }}nggraphd.conf" owner=root group=root mode=0755
- hosts: meta
  become: yes
  remote_user: root
  tasks:
    - name: init config metafile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201meta dest="{{ nebula_etc }}ngmetad.conf" owner=root group=root mode=0755
- hosts: storage
  become: yes
  remote_user: root
  tasks:
    - name: init config storagefile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201storage dest="{{ nebula_etc }}ngstoraged.conf" owner=root group=root mode=0755
```

配置文件的分发最为关键，有较多变量需要处理，这些变量需要提前在 ansible 的配置文件中定义，nebulagraphd 路径规范和服务端口需要使用 graphport、meta_server_addrs 需要用到 for 循环语法实现。

```
more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{ graphport }}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{ graphport }}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{ graphport }}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{ graph_h1_port }}
--ws_h2_port={{ graph_h2_port }}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password
```

同样，nebulametad 服务配置文件路径规范和服务端口需要使用 metahport、meta_server_addrs 需要用到 for 循环语法实现。
```
more templates/201meta 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{graphport}}/pids/nebula-metad.pid
########## logging ##########
--log_dir=/work/nebulagraph{{graphport}}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=metad-stdout.log
--stderr_log_file=metad-stderr.log
--stderrthreshold=2

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--port={{metaport}}
--ws_ip={{inventory_hostname}}
--ws_http_port={{meta_h1_port}}
--ws_h2_port={{meta_h2_port}}
########## storage ##########
--data_path=/work/nebulagraph{{graphport}}/data/meta

########## Misc #########
--default_parts_num=100
--default_replica_factor=1
--heartbeat_interval_secs=10
--timezone_name=CST-8
```

同样，nebulastoraged 服务配置文件路径规范和服务端口需要使用 storageport、meta_server_addrs 需要用到 for 循环语法实现。

```
more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{ graphport }}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{ graphport }}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{ graphport }}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{ graph_h1_port }}
--ws_h2_port={{ graph_h2_port }}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password
```

需要部署新集群时，需要按照规则和目的服务器信息生成 ansible 的配置文件，然后调用 ansible-playbook，按照 bootstrap.yml 定义的行为执行即可。

![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-10.png)

部署完毕之后，需要按照服务角色依次启动 start.yml 的脚本文件提前定义好三种服务的启动命令和配置文件。

![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-11.png)

调用 ansible-playbook，根据 start.yml 的脚本文件依次执行三种服务的启动命令即可。
![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-15.png)

# 可视化图探索平台

有赖于将目标 host 前置于 web 平台的设置，我们只需要对多个项目的开发提供一套公共的 web 平台即可，减少了 NebulaGraph 集群的组件数量，有别于 ELK 的标准架构。

![可视化图探索平台](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-12.png)

开发可以通过 NebulaGraph Studio实现可视化管理数据，轻松实现数据导入和导出，便于用户探索数据关系。直接呈现出点边关系，使探索图数据之间的关系更为直观。

 ![可视化图探索平台](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-13.png)

以上是我们在规模化管理维护 NebulaGraph 集群过程中的一些经验，希望对大家有些帮助。

___
交流图数据库技术？加入 NebulaGraph 交流群[请先填写下你的 NebulaGraph 名片](https://wj.qq.com/s2/8321168/8e2f)，NebulaGraph 小助手会拉你进群~~

NebulaGraph 的开源地址：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) 
觉得使用体验还不错的话，给我们的 GitHub 点个 ❤️ 鼓励下开源路上的我们呢~




58 同城在应对业务所需的关系分析等图探索场景时，经过多个图数据库产品的对比后，选择 NebulaGraph 部署其运维架构。

58 同城基于 NebulaGraph 一键部署运维架构的实践

携程经过多个图数据库产品的调研，最终选择 NebulaGraph 用于其运维治理的解决方案，主要基于 NebulaGraph 的横向扩展能力、自研的原生存储层、兼容主流的图技术语言 openCypher、社区活跃且用户知名度高等因素。

携程：基于分布式图数据库 NebulaGraph 的运维治理实践

苏宁通过 CMDB、调用链等数据构建软硬件知识图谱，在此基础上通过历史告警数据构建告警知识图谱，并最终应用知识图谱进行告警收敛和根因定位。本文主要包括运维知识图谱构建、知识图谱存储、告警收敛及根因定位等内容。