语势科技‍‍‍‍‍‍

语势科技专注于结合大模型和知识图谱的能力，构建以主题投资理论为核心的 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 的应用实践

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%90%88%E7%85%A7.jpg)

**背景 💻**

9 月 21 日，北京站 nMeetup 如期而至，一场以 GraphRAG 和人工智能技术融合为主题的开发者聚会，在金秋的首都拉开帷幕。这一天，我们与 8 位讲师和 140 多位来自五湖四海的行业伙伴们相聚一堂，共同探讨 GraphRAG & AI 的最新发展和应用实践，见证了一场关于智慧与未来的深入对话。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

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

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

未能到场的小伙伴们可查阅本次 nMeetup 精彩回顾、 PPT 及直播回放⬇️

**Topic 回顾 ⏰**

FastGPT Maintainer @杨道升，介绍了 FastGPT 在降低 AI 技术门槛、提升企业效率方面的优势，并分享了 FastGPT 在多个行业的应用案例。  

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

NebulaGraph GenAI Team Leader @古思为，带来了 GraphRAG 在 NebulaGraph 中的最新进展：构建了开箱即用的 GenAI Suite，使 GraphRAG 更易用，且性能更强大。不仅展现了 NebulaGraph 在 GraphRAG 领域的深厚积累，也激发了现场观众对 GenAI Suite 未来发展的极大期待，纷纷积极提问，现场讨论火热。‍

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

微软 MVP 大中华区负责人 @Christina Liang , 借本次 nMeetup 为大家介绍了微软 MVP（Microsoft Most Valuable Professional）的项目背景及选拔标准，期待更多乐于分享知识的行业专家们加入。（如需了解更多详情，请见_mvp.microsoft.com）

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

53 AI 创始人@杨芳贤，分享了 AI Agent 在企业落地的案例，细剖析了 Chat Agent 和 Data Agent 两个主要场景下的应用实践，并指出了当前 RAG 方案在企业内部落地时面临的挑战。  

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

博睿数据大数据开发工程师@姚成耀，带来 NebulaGraph 在博睿数据实际生产环境中的应用案例，详述了在使用 NebulaGraph 过程中遇到的问题、解决方案以及二次开发的经验，让大家对 NebulaGraph 的实战能力有了更直观的认识。

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

Eigent AI Founding Engineer @范文栋，聚焦于将知识图谱与基于 RAG 模型的 Agent 相结合的应用，展示了如何通过图结构的数据进行增强的推理和知识检索，以提升 Agent 的回答质量和推理能力，并介绍了 CAMEL AI 集成 NebulaGraph 的进展。感谢@Wendong @Asuka @Ray @赵越 的贡献～  

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

微软高级云技术布道师@卢建晖，带来了 GraphRAG 优化的实用技巧，详细讲解了如何在 Graph 的构建过程中利用 SLM 来优化 GraphRAG 应用。  

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

语势科技技术负责人@岳洋，从金融领域的实际需求出发，阐述了传统大模型在复杂推理方面的不足，以及图谱技术如何成为解决这一问题的关键。此外，对比了当前各图数据库的优劣势，还从易用性、社区活跃程度等角度，分析为何选择 NebulaGraph 作为 GraphRAG 适合中小企业当前最佳解决方案，为金融行业数据库选型提供了新思路。

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

**社区结语 🎙️**  

此次 nMeetup 不仅是一场技术交流的盛会，更是一个启迪思维、激发创新的平台。它让我们看到了 GraphRAG 与人工智能技术融合的巨大潜力，也让我们对未来科技发展的方向充满了期待。NebulaGraph 将持续推动 GraphRAG 的技术革新与迭代，为行业提供更高效更智能的解决方案，我们也热切期待与更多志同道合的伙伴携手并肩，共同探索更深入的技术领域。

未来，我们将会有更多的机会与大家见面交流，分享更多的技术心得和实战经验。期待在下一站 nMeetup 中，再次见到熟悉的面孔，结识更多新的朋友！

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


**回放+PPT🔗**

直播回放：[北京站回放](https://www.bilibili.com/video/BV1pDsUe8EcF/?spm_id_from=333.999.0.0&vd_source=817871e38f2f5dbaed653bece6b00ecf)

PPT获取方式：关注[「NebulaGraph 技术社区」](https://mp.weixin.qq.com/s/Eg-U3H48TsT7vSt6rGaJRA)，后台回复「北京站」。

GraphRAG Meets AI ｜NebulaGraph Meetup 北京站

【nMeetup 北京站】活动精彩回顾（附 PPT+回放）

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

  

波克城市，一家专注于研发精品休闲游戏的全球化公司，连续七年入选中国互联网综合实力百强，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 在携程风控场景下的落地实践

**一、简介**

NebulaGraph 是一款开源的、分布式的、易扩展的原生图数据库，能够承载包含数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查询。

图数据库在许多业务场景中扮演着重要角色，得益于其独特的数据模型和高效的查询性能。以下是一些常见的图数据库业务应用场景：

-   知识图谱：企业和组织需要从各种数据孤岛中构建领域知识图谱，支持智能问答和语义搜索。
    
-   社交网络分析：社交网络平台需要分析用户之间的关系、兴趣、互动等信息，以提供个性化推荐、广告定向投放。
    
-   金融风控：金融机构需要监测异常交易活动、识别潜在的欺诈行为、评估信用风险。
    
-   推荐系统：电子商务、媒体平台需要根据用户的浏览历史、购买记录等信息，提供个性化的商品或内容推荐。
    

NebulaGraph Cloud 是为 NebulaGraph 设计的全托管云服务，**本文将结合亚马逊云科技的产品，详细介绍如何实现降本增效。**


**二、NebulaGraph Cloud**

**平台架构**

![image|561x499](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/9da20f7acfd239dc38ee3ecc5f3bd1be4ceac701_2_561x499.jpeg)

NebulaGraph Cloud 基于 K8S 设计和构建 ，背后有以下因素：

-   K8S 的 Opertor 模式使得集群内部发生的一切可以被自动化，降低开发成本。
    
-   K8S 提供了一系列抽象能力，用于简化计算、存储和网络资源的管理，可以帮助用户避险厂商锁定，做到 100% Cloud agnostic。
    
-   K8S 内置的扩缩容、调度框架、资源监控、服务发现等能力，可以将各种管理操作变的更容易。
    

**服务组件**

NebulaGraph Cloud 由两部分构成：

**控制平面（Control Plane）**

提供用户控制台访问，包括组织管理、用户权限控制、数据库管理、网络安全设置、监控、告警等功能，帮助用户管理他们的 NebulaGraph 集群。

**数据平面（Data Plane）**

接收控制平面下发的指令，包括资源调度、配置、版本更新、水平扩缩容、规格调整、备份和恢复、可观测性、计量等功能。

**成本优化设计**

以数据库的配置示例来说明：


```
apiVersion: apps.nebula-cloud.io/v1alpha1
kind: Database
metadata:
  name: db123456
  namespace: db123456
spec:
  provider: aws
  region: "us-east-2"
  k8sRef:
     name: "k8s-ml65nmjg"
     namespace: "k8s-ml65nmjg"
  tier: standard
  graphInstanceType: NG.C4.M32.D0
  graphNodes: 1
  StorageInstanceType: NG.C4.M32.D50
  StorageNodes: 1
  version: v3.8.2c
```


数据库实例使用 CRD Database 定义，它在数据平面的管理操作由控制器 database-controller 负责。

对于依赖的计算资源通过 CRD NodePool 定义，**NodePool 是对各个云厂商计算资源的抽象，在 Amazon EKS 中用于管理 NodeGroup。**

前文提到 NebulaGraph 是计算-存储分离的架构，所以一个数据库实例会对应两个 NodePool 对象。

```
# Graph 资源池
apiVersion: apps.nebula-cloud.io/v1alpha1
kind: NodePool
metadata:
  name: gnp-7d0b156e
  namespace: db123456
spec:
  databaseRef:
    name: db123456
    namespace: db123456
  instanceCount: 1
  instanceType: x
  k8sRef:
    name: k8s-ml65nmjg
    namespace: k8s-ml65nmjg
  labels:
    platform.nebula-cloud.io/database-name: db123456
    platform.nebula-cloud.io/graph-pool: db123456-f24a
  provider: aws
  region: us-east-2
  zoneIndex: 0
  
# Storage 资源池
apiVersion: apps.nebula-cloud.io/v1alpha1
kind: NodePool
metadata:
  name: snp-59e9cc63
  namespace: db123456
spec:
  databaseRef:
    name: db123456
    namespace: db123456
  instanceCount: 1
  instanceType: x
  k8sRef:
    name: k8s-ml65nmjg
    namespace: k8s-ml65nmjg
  labels:
    platform.nebula-cloud.io/database-name: db123456
    platform.nebula-cloud.io/Storage-pool: db123456-un6g
  provider: aws
  region: us-east-2
  zoneIndex: 0
```

**规格调整**

选择合适的实例规格对用户和服务商都是一个比预期更具挑战性的任务。用户通常不清楚他们需要多大的实例，例如，当用户的数据从100 GB 逐渐增长到 1 TB 时，他们可能不清楚这些数据在每个阶段需要多少 CPU 核心或多大内存。这就需要用户和 SA 共同努力来找出答案。

在使用全托管云服务时，我们提供实例规格调整功能，支持对 Query 节点或者 Storage 节点单独调整，以满足用户在成本控制和性能达标方面的需求。用户可以根据监控面板的历史曲线判断是否达到单节点处理瓶颈，同时云平台也会发出站内告警。

![image|690x225](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/f5f5f6a57a63973e531106af4a1391e834c63d09_2_690x225.png)


**水平扩缩容**

水平扩缩容支持对 Query 节点或者 Storage 节点单独调整。**Query 节点可视为无状态服务，在处理查询流量波动时可通过扩缩容来解决。**

Storage 节点负责存储图数据并提供读写能力，每个 Storage 节点上都分布一定数量的数据分片。每次进行扩缩容都会涉及数据迁移及数据分片再均衡，因此需要谨慎操作。

节点扩容前需要准备相应的计算资源，控制器 database-controller 会将当前期望的节点数下发给 infra-controller 触发 Amazon EKS 的 NodeGroup 扩容，这里我们**没有启用 CA 或者 Karpenter 有以下原因：**

-   扩缩容决策依赖于特定的集群条件和资源请求，如果这些条件没有得到满足，它可能不会执行预期的扩缩容操作。
    
-   跨可用区场景下无法保证指定区域的扩缩容。
    
-   基于 Pending Pod 的模式跟我们的业务系统无法紧密集成。
    
![image|690x216](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/753847db27e05d64ab3f647df0523610bdbbb87c_2_690x216.png)


**自动弹性伸缩**

通过自动扩容/缩容支持不同的工作负载是我们的一个重要目标。由于计算和存储是分离的，我们可以根据每个服务节点的利用率来增加或减少 CPU 和内存资源。

弹性伸缩服务架构如下：

![image|690x278](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/c8ff42ffa7adc0f30c46e9d1618dd8a09d92748b_2_690x278.jpeg)


每隔 10 分钟，弹性伸缩服务就会根据监控数据的历史和当前值计算数据库实例应分配的资源量，最终确定是否应增加或缩减计算资源。

**它可以驱动水平扩缩容和垂直扩缩容（调整实例规格），确保业务高峰时能提前弹出来。** 我们在此基础上将继续不断改进，通过纳入更多指标和主动预测策略来缩短扩缩容的时间。

**三、效率提升设计**

**网络安全访问**

![image|690x228](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/b49d9f8193e3bde0f05041a65507764da8955fea_2_690x228.png)


**目前我们为用户提供两种网络连接方式：网络白名单和 Privatelink 私网连接。**

为了确保网络安全并简化配置步骤，我们在数据库实例与网络负载均衡（NLB）之间引入了代理服务 ngproxy，充分利用了 NLB 提供的功能。NLB 支持在通过的每个报文上设置 PPv2 header，ngproxy通过解析报文可以知晓用户端的 endpoint ID 与在控制台设置的 ID 是否一致，不匹配则会拒绝请求。同样的原理也适用于公网访问的白名单，只有当源地址与白名单中的地址匹配时，才会被允许通过。

**备份和恢复**

**数据备份是防止数据丢失的第一道防线。** 无论是因为硬件故障、软件错误、数据损坏还是人为操作失误，备份都可以确保数据的安全。

我们为用户提供手动备份和定时备份两种方式，将备份数据上传到亚马逊云科技的对象存储Amazon S3。我们没有采用基于云存储快照的备份恢复方案，因为基于 SST 的备份恢复速度比云存储快照更快，而且不需要依赖云厂商的基础服务。需要注意的是，在进行数据备份时 DDL 和 DML 语句将会被阻塞，因此建议在业务低峰期执行备份操作。

备份数据目录结构：

```
backup_root_url/
- BACKUP_2024_08_20_16_31_43
├── BACKUP_2024_08_20_16_31_43.meta
├── data
│   └── 10.0.0.12:9779
│       └── data0
│           └── 5
│               ├── data
│               │   ├── 000009.sst
│               │   ├── 000011.sst
│               │   ├── 000013.sst
│               │   ├── CURRENT
│               │   ├── MANIFEST-000004
│               │   └── OPTIONS-000007
│               └── wal
│                   ├── 1
│                   │   ├── 0000000000000000001.wal
│                   │   └── 0000000000000000005.wal
.....
│                   ├── 30
│                   │   ├── 0000000000000000001.wal
│                   │   ├── 0000000000000000004.wal
│                   │   └── 0000000000000000005.wal
└── meta
    ├── __disk_parts__.sst
    ├── __edges__.sst
    ├── __id__.sst
    ├── __indexes__.sst
    ├── __index__.sst
    ├── __last_update_time__.sst
    ├── __local_id__.sst
    ├── __parts__.sst
    ├── __roles__.sst
    ├── __spaces__.sst
    └── __tags__.sst
- BACKUP_2024_08_20_19_02_35
```

恢复数据时采用恢复至新实例的方案，这样可以充分利用云上资源弹性扩展的优势，在指定某个时间点的备份集后快速拉起一个新的数据库实例，用户在验证新的数据库实例工作正常后可以释放掉旧实例。

**高可用性**

针对那些对服务可靠性要求极高的用户，我们提供了跨可用区容灾解决方案。

在 NebulaGraph 中 Zone 是服务节点的集合，它将多个 Storage 节点划分成可管理的逻辑区域，实现资源隔离。同时，平台服务会控制 Query 节点访问指定的 Zone 内的副本数据，从而降低跨可用区通信产生的网络延时与流量成本。

管理有状态服务跨可用区的一个主要挑战是存储卷的区域亲和性问题。为了解决这个问题，我们采取了在每个可用区放置一个 NodeGroup 的方法。这样一来，就可以避免新扩容的 Node 可能被错误地安排在不正确的可用区中，从而导致 Pod 无法被调度的情况发生。

根据过往用户案例中的经验，我们还支持在某个可用区单独扩容的方案。云原生社区类似 HPA 的方案，只解决了扩容后的数量问题，但是无法扩容到指定区域。根据每个区域承载的业务流量进行扩展，可以有效地提高服务质量。如果某个区域观察到 QPS 突然激增，数据平面的弹性伸缩服务将允许在此区域缩放 Query 节点。

![image|690x309](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/ead9f0ff2d6e68afb9a05dbdc2ec418e60590178_2_690x309.png)


**四、云上实战**

在开通订阅后开始创建数据库，接下来演示访问数据库的几种方式：

**可视化工具**

从 Database 列表选中某个实例，进入 Data->Graph 图空间管理，点击 Explorer Graph 进入可视化应用。

![image|690x198](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/ce7ed2c9cfab7106e383bd3424e40c8237588324_2_690x198.png)


点击右上角的 Console 打开控制台便可以执行 GQL 语句的查询。

![image|690x359](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/b097fa13dfc3ad0490e89138ee5c00e68c4d585f_2_690x359.png)


**网络白名单**

在数据库实例的 Overview 页面点击 Connect，选中 Public 方式。

![image|644x499](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/90dc038f3a3e9714718599fc876fdfead128eb83_2_644x499.jpeg)


在没有配置网络白名单时，数据库实例无法直接从公网访问。

```
$ ./nebula-console -addr nebula-graph-ncqqo19eh0aus73e4un6g.aws.cloud.nebula-graph.io -port 9669 -u dbaas-test@vesoft.com -p $PASSWORD -enable_ssl

Welcome!

(dbaas-test@vesoft.com@nebula) [(none)]> show spaces;
+------------------------+
| Name                   |
+------------------------+
| "genshin"              |
| "hanxiaotest"          |
| "movie_recommendation" |
| "nba"                  |
+------------------------+
Got 4 rows (time spent 602µs/222.883326ms)

Mon, 02 Sep 2024 16:52:39 CST
```


**Privatelink 私网连接**

按照 Create Private Link Endpoint 的配置步骤，确定业务所在的 VPC ID 和 Subnet ID。

运行命令创建 Endpoint：
```
aws ec2 create-vpc-endpoint --vpc-id <YOUR-VPC-ID>  --region us-east-2 --service-name com.amazonaws.vpce.us-east-2.vpce-svc-04f25889c855f891b --vpc-endpoint-type Interface --subnet-ids  <YOUR-SUBNET-IDs>
```

登录亚马逊云科技控制台查看 Endpoint 状态：

![image|690x212](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/1fe27de7e96f4deb53862da71dbcbbe02a8f6afb_2_690x212.png)


在业务 VPC 内测试访问是否正常。

![image|690x146](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/cb5260250eb6c4b416f9578ffa1d4106d5be1291_2_690x146.png)


接下来大家可以按照自己的业务需求通过官方生态工具在云上进行数据维护。

**五、总结与展望**

本文介绍了基于云原生理念在亚马逊云科技上的服务落地 NebulaGraph 全托管云服务的架构细节，**着重阐述如何通过亚马逊云科技的产品为用户带来实质利益，为用户在云端使用 NebulaGraph 提供兼具成本和弹性优势的全新解决方案。**

在确保服务质量的同时，我们将继续探索各种可能性，降低用户成本并提高易用度。我们的目标是让用户只需为其使用的资源付费，将成本概念贯彻到每一个细节中。

**目前 NebulaGraph Cloud Beta 版本试用活动正在火热进行中，** 每月最高消费控制在1美元以内，大家可以通过以[下链接注册账号](ttps://aws.amazon.com/marketplace/pp/prodview-wctboqxrwqkjy?sr=0-1&ref_=beagle&applicationId=AWSMPContessa) 或[直接访问注册账号](https://cloud.nebula-graph.io)。

欢迎对 **NebulaGraph Cloud** 感兴趣的小伙伴添加小助手 NebulaGraphbot(wechat) 解锁更多 DBaaS 相关内容。

只要1$ 解锁 NebulaGraph on AWS，通通1$

全托管 NebulaGraph 试用活动进行中！解锁成本优化与效率提升的实践指南

![image|690x387, 100%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/d709b2dd5b59dc1282c210a4a72a956bb2f72b9c.jpeg)


> **听说没人能拒绝一根棍子、一只猴子？**
> 
> **NebulaGraph 送《黑神话：悟空》啦！**

历时 6 年，承载着全球玩家的期待，《黑神话：悟空》已正式上线发售。它早已超越游戏本身，成为一段文化之旅，一次情怀共鸣，一场从儿时就开始做的英雄梦。

正如悟空在混沌世界中披荆斩棘、闯荡四方，每一个使用 NebulaGraph 的你，都是数据世界中的天命人，勇敢探索未知，发现隐藏的价值，追寻数据的英雄梦。无论是在复杂的社交网络分析中揭示隐藏的关系，还是让数据价值最大化，你的每一个使用案例都值得被分享和赞扬。

我们诚挚地邀请您参与 NebulaGraph 用户案例征文活动，畅谈您在实际应用中使用 NebulaGraph 的宝贵经验和成功案例。您的实践，不仅是我们版本迭代的动力，也是其他 NebulaGraph 用户打怪升级的通关攻略。



**【征文要求】**

-   主题：用户案例；
    
-   内容：文章结构完整、逻辑清晰、文字通顺，图文并茂；
    
-   结构：包括但不限于，公司及业务介绍、业务挑战与产品选型、NebulaGraph 的使用场景与解决方案、经验分享 or 踩坑总结；
    
-   发布：进入 NebulaGraph 论坛，在【文章】 分类下撰写文章并发布。
    

**【评奖方式】**

本次征文采用文章积分来评选得分 Top5，公式如下：‍‍

```
文章得分 = 浏览量 + 点赞（ ❤ ）数 x 2 + 评论数 x 5

```

（说明：公式优化了点赞权重过高的问题，提升了浏览量的优先级。即，你越早发文章，优势越突出）

**【征文奖品】**

Top5 皆可赢取《黑神话：悟空》标准版，此外，按名次排序，我们送出不同等级的社区周边礼包。

**【征文时间】**

即刻起至 9 月 30 日。


————————————————————————————————
**🎉我是小彩蛋**

我们欢迎新朋友加入 NebulaGraph 社区，如果您无法提供用户案例，但是《黑神话：悟空》忠实玩家，且对图数据库感兴趣，可以投稿「使用 NebulaGraph 分析《黑神话：悟空》」。

如通过 NebulaGraph 预测终极 boss、推荐最佳合作伙伴、可视化人物关系图谱、分析角色关系网络中隐藏任务触发的影响因素......我们将随机送出周边大礼包 n 份🐒

听说没人能拒绝一根棍子、一只猴子？
NebulaGraph 送《黑神话：悟空》啦！

来领《黑神话：悟空》！NebulaGraph 用户案例征集 ing

![image|690x352, 100%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/WechatIMG300.jpg)

**背景 💻**

8 月 17 日，NebulaGraph Meetup 厦门站以“图数据库+AI”为主题，汇聚行业专家与技术爱好者，共同探讨了 AI 的最新实践与 GraphRAG 的创新解决方案。厦门风光旖旎，相信现场小伙伴们亦满载而归。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

![image|690x426, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(1).jpg)
![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(2).jpg)

未能到场的小伙伴们可查阅本次 nMeetup 精彩回顾及直播回放⬇️‍‍‍‍‍‍‍‍‍‍‍‍‍‍

「NebulaGraph GenAI Team @BeautyyuYanli 压轴，NebulaGraph RAG 受到不少社区朋友们关注，欢迎大家加入 NebulaGraph RAG 技术交流群，一同探索更多可能🌟」
![image|506x500, 50%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(3).jpg)


**Topic 回顾 ⏰**

**Part 1 聚焦 AI 的最新实践**。FastGPT 开发者 & 布道师王子俊深入介绍了 FastGPT 的高级编排功能，帮助大家如何构建高效的 AI 工作流；厦门巅峰科技有限公司技术负责人涂标松分享了 AI 助力客服中心录音质检的应用，为录音质检私有化部署提供了解决方案。  

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(4).jpg)

![image|690x467, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(5).jpg)


**Part 2 聚焦 GQL**。NebulaGraph Committer 大叶老师 以 ISO-GQL 标准为引，分析了图数据库驱动程序现状，提倡建立统一的调用方式的标准；NebulaGraph 产品经理方扬 @MuYi ，对 ISO-GQL 作出深入解析，并介绍  GQL 在图数据库中的重要性。

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(6).jpg)

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(7).jpg)

大叶老师不仅是 NebulaGraph 的 Committer ，陪伴 NebulaGraph 走过多个版本的迭代，也积极承担了社区布道的重大责任。本次 nMeetup 选址大叶老师所在地——厦门，亦是我们与大叶老师的双向奔赴。借此机会，NebulaGraph 社区聘请其为「厦门城市站站长」，再次感谢大叶老师的支持～！

![image|666x500, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(8).jpg)


**Part 3 聚焦 GraphRAG**。厦门大学平潭研究院研究员杨知铮，以对话诗仙李白为例，分享了如何将 GraphRAG 引入传统文化教育，引发了现场小伙伴们的强烈共鸣和热烈讨论，纷纷表达对 GraphRAG 在传统文化教育中应用的期待。

NebulaGraph 研发 @BeautyyuYanli ，介绍了 NebulaGraph GenAI 团队在 GraphRAG 的探索与尝试。**（GraphRAG 由 NebulaGraph 和 LlamaIndex 共同推出，能够将知识图谱与大语言模型结合，为搜索引擎提供更全面的上下文理解，带来更智能的搜索结果。）**GraphRAG 推出后，NebulaGraph 构建了 GenAI Suite，帮助更多企业和开发者更加高效地探索与使用 GraphRAG。本次 nMeetup 还进行了 live demo，更加直观地让大家理解 NebulaGraph 的 GraphRAG 解决方案。‍‍‍‍

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(9).jpg)

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(10).jpg)

**社区结语 🎙️**  

本次 nMeetup 不仅是一次技术分享的盛会，也是一场开发者社区的聚会，相信每一位参与者都在这里有所收获，碰撞出思维的火花。未来，我们将会有更多的机会与大家见面交流，分享更多的技术心得和实战经验。期待在下一站 nMeetup 中，再次见到熟悉的面孔，结识更多新的朋友！

（留言猜猜我们下一站去哪儿？随机掉落精美周边😄）

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(11).jpg)

![image|690x459, 75%](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/image%20(12).jpg)

**回放+PPT🔗**

回放地址：[https://www.bilibili.com/video/BV1X3WpeTEpx/?spm_id_from=333.999.0.0&vd_source=817871e38f2f5dbaed653bece6b00ecf](https://www.bilibili.com/video/BV1X3WpeTEpx/?spm_id_from=333.999.0.0&vd_source=817871e38f2f5dbaed653bece6b00ecf)

PPT 获取方式：关注「NebulaGraph技术社区」公众号，后台回复「厦门站」

8 月 17 日，NebulaGraph Meetup 厦门站以“图数据库+AI”为主题，汇聚行业专家与技术爱好者，共同探讨了 AI 的最新实践与 GraphRAG 的创新解决方案。厦门风光旖旎，相信现场小伙伴们亦满载而归。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

【nMeetup 厦门站】活动精彩回顾（附ppt+回放）

各位社区小伙伴大家好，2024 年第一站 **nMeetup** 来啦！速速与我们面基😄

本次 nMeetup 由 **NebulaGraph**、**FastGPT**、**厦门创业中心**联合主办走进厦门，与社区各位小伙伴进行交流分享。本场活动将聚焦“**图数据库 + AI**”方向。

此次活动，我们邀请到了厦门大学平潭研究院研究员、DataWhale 开源社区作者杨知铮，厦门巅峰科技有限公司技术负责人、《Llama 大模型实践指南》作者之一涂标松，独立开发者、NgBatis 发起人、NebulaGraph Committer叶伟城，FastGPT maintainer、FastGPT 开发者布道师，B 站科技区万粉博主王子俊，NebulaGraph 产品总监方扬等专家和大咖，为社区的小伙伴们带来精彩的技术分享。

**活动免费！欢迎各位小伙伴报名参与！现在即可报名！**

## **🕙时间、地点**

-   时间：2024 年 8 月 17 日 13:30-17:00
    
-   地点：厦门市湖里区新丰路176-180号火炬荟智空间A区二楼路演厅
    

## **🧾议程**

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/C34B6759-1BDF-42D8-8A98-ECDDC4269C3B.png)


## **📮报名方式**

**扫描上方海报中的二维码即可报名，[或点击🔗链接直接报名](https://www.slidestalk.com/NebulaGraph/xiamen)**

## **🎁互动礼品**

线下参与本次活动，现场可获得 NebulaGraph 和 FastGPT 社区周边礼品一份。

各位社区小伙伴大家好，2024 年第一站 nMeetup 来啦！速速来面基😄

【nMeetup厦门站】图数据库 + AI 厦门站 Meetup 与你相约 8 月 17 日


自 2023 年 8 月 **NebulaGraph** 和 **LlamaIndex** 共同推出 [Graph RAG](http://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247508410&idx=1&sn=a0432b3bbeac4e60a43c320f88201e81&chksm=cfe75b6ef890d278dedc9685b25459aa6bd7186ae06ea76f861f9c92964a4a0177cd1f818741&scene=21#wechat_redirect) 以来，凭借着 **LLM（大语言模型)**  和 **RAG（检索增强生成）** 的发展势头，在业界掀起了一场革命。通过本文，我们将向你介绍什么是 Graph RAG，为什么它具有革命性，以及如何构建你的Graph RAG，来利用数据的上下文与 NebulaGraph 回答复杂的多部分问题。

## 了解日益流行的 Graph RAG

Graph RAG 能够将知识图谱与大语言模型（LLM）结合使用，从而为搜索引擎提供更全面的上下文理解。由于其带来了更具成本效益、更智能且精确的搜索结果，这项技术已引起了广泛的关注。除了提供更准确的回答以建立用户信任外，Graph RAG 还克服了传统搜索增强技术的主要障碍：缺乏上下文理解和数据训练。因此，这些先进的检索增强技术有望扩展到各个行业，如医疗诊断辅助、内容创作和推荐、互动游戏以及知识图谱构建。

微软在由高级首席数据架构师 Jonathan Larson 和首席项目经理 Steven Truitt 撰写的博客文章《GraphRAG: Unlocking LLM Discovery on Narrative Private Data》中强调了 Graph RAG 的重要性。他们通过将 Graph RAG 与基线 RAG 系统进行对比，展示了 Graph RAG 的有效性，得出结论认为 Graph RAG 方法使LLM能够在图谱中找到支点，从而提供包含原始支持文本的更优答案。而基线 RAG 在处理需要跨数据集汇总信息以形成答案的查询时则显得力不从心。
**NebulaGraph 数据库已经集成了 LlamaIndex 和 LangChain 等大语言模型（LLM）框架** ；你只需专注于 LLM 编排逻辑和管道设计，无需担心复杂的实现。你可以通过简单的四个步骤进行试用，检查 Graph RAG 是否如传言般出色，然后再进一步将其集成到应用程序或其他场景中。

**注意：**

由于 LlamaIndex 的快速发展，最近的重构/重大变更导致一些 Graph RAG 教程无法运行。本文提供了更新后的 Graph RAG 教程，以便你可以无误地进行操作。

我们在上游发布之前已经探索了许多内部方法。我们相信 LlamaIndex 中Graph + RAG 的基本概念值得探索，因此我们将原始的工作坊和笔记本放在参考章节中。

**设置你的 NebulaGraph 集群**

* 通过 Google Colab 中的 NebulaGraph Lite 启动 NebulaGraph 集群
* 使用 Docker 扩展部署集群
* 实例化一个 NebulaGraphStore
## 使用 NebulaGrpah 构建你的 Graph RAG
~~~
import os
from llama_index.core import KnowledgeGraphIndex, SimpleDirectoryReader
from llama_index.core import StorageContext
from llama_index.graph_stores.nebula import NebulaGraphStore

os.environ["NEBULA_USER"] = "root"
os.environ["NEBULA_PASSWORD"] = "nebula"
os.environ["NEBULA_ADDRESS"] = "127.0.0.1:9669"


space_name = "paul_graham_essay"
edge_types, rel_prop_names = ["relationship"], ["relationship"]  # default, could be omit if create from an empty kg
tags = ["entity"]  # default, could be omit if create from an empty kg

graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags)

storage_context = StorageContext.from_defaults(graph_store=graph_store)
~~~
现在，随着你的 NebulaGraph 集群的设置，可以动手进行知识图谱构建部分。**请确保在 Jupyter 环境中运行以下所有步骤。**

**依赖关系**

Graph RAG 的实现需要以下依赖项：
~~~
pip install llama-index
pip install llama-index-llms-ollama
pip install llama-index-graph-stores-nebula
pip install ipython-ngql
pip install llama-index-embeddings-huggingface
~~~
**创建 LlamaIndex 知识图谱索引**

KnowledgeGraphIndex 可从非结构化文本中自动构建知识图谱，也可基于实体的查询。在创建图 RAG 查询引擎之前，你需要设置 LlamaIndex 知识图谱索引。在这个示例中，我们将演示如何通过创建文档对象来从文本数据构建知识图谱，然后再创建索引。
~~~
from llama_index.core import (
    VectorStoreIndex,
    SimpleDirectoryReader,
    KnowledgeGraphIndex,
)

graph_store.query("SHOW HOSTS")

Settings.chunk_size = 512

documents = SimpleDirectoryReader(
    "data"
).load_data()
~~~
~~~
kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
    max_knowledge_sequence=15,
)
~~~
### 创建一个朴素图 RAG 检索器

最后一步是创建 Graph RAG 检索器，在其基础上构建查询引擎，以便您可以使用自然语言问题进行查询。
~~~
from llama_index.core.query_engine import RetrieverQueryEngine
from llama_index.core.retrievers import KnowledgeGraphRAGRetriever

graph_rag_retriever = KnowledgeGraphRAGRetriever(
    storage_context=storage_context,
    verbose=True,
)

query_engine = RetrieverQueryEngine.from_args(
    graph_rag_retriever,
)
response = query_engine.query("What's the relationship between Bob and Alice")
~~~
现在，您已经尝试了 Graph RAG，如果您想进一步了解如何通过 GraphStore 和 VectorStore 进行检索，您可以在此处找到更多演示示例：https://www.siwei.io/tutors/GraphRAG/101.html。

[欢迎加入社区官方 Slack 群](https://join.slack.com/t/nebulagraph/shared_invite/zt-2h51ct4t0-IlXFaU01mpb3t2WgQ8qqNA)。

参考：

* https://bit.ly/graph-rag-workshop
* https://siwei.io/graph-enabled-llama-index/kg_and_vector_RAG.html
* https://siwei.io/demo-dumps/graph-rag/GraphRAG.html

通过本文，我们将向你介绍什么是 Graph RAG，为什么它具有革命性，以及如何构建你的Graph RAG，来利用数据的上下文与 NebulaGraph 回答复杂的多部分问题。

基于 NebulaGraph ，构建属于你的 Graph RAG 

![|](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 助力金蝶征信产业图谱深挖企业关系链，实现银行批量获客 

![图数据库和知识图谱](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-1.jpg)

图数据库和知识图谱是管理图结构数据（包括节点（实体）和边（关系））的两大主流方案。图数据库利用基于图的数据模型存储信息，支持通过专用的图查询语言实现对图数据的查询和遍历；知识图谱通过整合推理和派生新知识的机制，增强了图数据库的功能。这种增强的表达力不仅让你能进行更高级的数据分析，还能从图中相互连接的数据点中提取洞察力。

本文将简要介绍知识图谱，再探讨使用 llamaindex 和 NebulaGraph-lite 生成知识图谱。

## 知识图谱是什么

知识图谱是一种图形化的知识表示方法，它将相关联的概念、事物及其关系描绘成一个网络。它涵盖了现实世界中的实体，如物体、人物、地点和事件。知识图谱的核心通常依赖图数据库，图数据库专注于通过存储离散的信息片段及其之间的关联来管理数据。

知识图谱的核心组成部分包括：**实体**是现实世界中的事物或概念，包括人、地点、活动和思想总结。在图型表达中，这是一种可视化数据集之间关系的方式，实体在图中表示为节点。

实体的例子包括：
- 人物：巴拉克·奥巴马、塞雷娜·威廉姆斯
- 地点/位置：纽约市、金字塔
- 事件：第二次世界大战、2008 年经济危机
- 抽象/意识形态：民主、重力

**关系**描述了对象之间的相互作用或联系方式，且展示了它们是如何联系在一起的。在知识图谱中，关系通过边来表示，这些边连接相应的节点。而边的流动方向可以是单向，也可以是双向，这取决于实体关系的性质。

### 知识图谱的分类

知识图谱拥有以下能力：
- 有效管理和可视化异构信息：能够在统一的框架内处理不同系统的数据，实现清晰且深具洞察力的信息展示。
- 集成新的数据资源：知识图谱固有的灵活性，能很好地同新数据源融合，支持知识库的持续扩充。
- 理解并阐释任何存储信息中的关系：能够发现并展示不同信息库中实体之间的关系，从而全面理解潜在的关联关系。

图谱的主要类型：

- RDF（资源描述框架）三元组存储：专注于存储和处理基于 RDF 框架的信息，该框架通过三元组（主体、谓语、客体）来表示知识。
带标签的属性图：专门研究节点和边附带信息标签的图，提供了更为丰富和细致的数据表现。

### RDF（资源描述框架）图

RDF 图，全称资源描述框架图，是用来表示类似网络结构的网络信息的一种方式。基本上，它是一系列围绕主题、谓词和客体组成的声明。以“巴黎是法国的首都”这句话为例，在 RDF 图中，“巴黎”作为主题，“是……的首都”作为谓词，“法国”作为对象（客体）。而这三个元素共同构成了一个“三元组”，代表了一个事实。一个 RDF 图可以包含众多这样的三元组，从而构建成一个互连的信息网络。 

资源描述框架（RDF）三元组存储是一种标准化的知识表示数据模型。在这个模型中，每个元素都通过统一资源标识符（URI）被赋予一个独一无二的标识符。这种机制确保主题、谓词和客体的机器可读性。此外，RDF 三元组存储采用了一种名为 SPARQL 的标准化查询语言，该语言支持从存储中检索数据。得益于数据表示和查询的标准化，RDF 三元组存储能够与其他遵循 RDF 框架的知识图谱实现互操作。

![SPARQL](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-2.png)

上图展示了一个社交网络中的个体（圆形节点 Jack、Joe、Jane），和他们之间的友谊关系（有向连接线 knows）。此外，每个有深色边缘的节点都表示该个体有收入（有向连接线 hasIncome）。菱形节点显示了网络中可能存在的额外数据（三元组）。

RDF 图的优点：

- 互操作性：RDF 是 W3C 的标准，意味着不同的系统可以理解并交换存储在 RDF 图中的数据。这使得它非常适合跨平台和应用程序之间的数据共享。

- 标准化：由于其标准化的格式，RDF 图支持标准查询语言 SPARQL 来探索和分析图中存储的数据。

- 推理与推导：RDF 图能够利用本体（可以视为对概念的正式描述）来进行数据推理。这使系统能够推导出图中没有直接表述的新信息。

- 灵活：RDF 图能够表述多种数据类型和关系，适合模拟复杂的领域和整合不同来源的数据。

### RDF 图的缺点：

- 深度搜索复杂：在大型 RDF 图中进行深度搜索的计算成本可能很高，这可能拖慢需要探索多个连接的查询的速度。

- 结构严格：RDF 数据以“三元组”（主体、谓语、客体）的形式存储，这种结构可能不如其他图模型那样灵活，后者允许对实体或关系本身添加属性。

- 学习曲线陡峭：理解和使用 RDF 需要良好地掌握其基本概念及 SPARQL 查询语言，这对新用户来说可能是一个挑战。

### 带标签的属性图 (LPG)

带标签的属性图（LPG）是一种用于表现具有相互连接的服务及其关系的特殊图数据库模型。以下是其主要特点的详细解释：

- 节点：可表示现实中的男性或女性特征。每个节点都具有独特的描述，并可被赋予一个或多个标签以表明其类型或大小（例如，“人物”、“产品”）。

- 属性：节点可能拥有键值对，用以存储关于该实体的额外信息。这些属性允许对图中的元素进行基本描述。

- 边：表示节点之间的联系，并展示实体间的关系。边与节点类似，可以用多种方式标记（例如，“认识”、“购买”），同时也可以拥有自己的属性。

LPG 的主要特性：

- 丰富的数据结构：节点和边都能拥有属性，与其他模型如 RDF 相比，允许更密集和信息量更大的数据表现。

- 高效的存储与查询：LPG 结构通常能带来高效的存储方式和更快速的图内连接遍历，便于进行查询。

- 灵活：LPG 由于没有预定义的模式，具备很高的灵活性，允许模拟多种数据关系。

### RDF vs 属性图

![RDF vs 属性图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-3.png)

### 属性图与 LLM 模型结合的智能问答

属性图和大型语言模型（LLM）是两个强大的工具，可以结合使用，从数据中挖掘出新线索。以下是它们如何协作的具体方式：

**数据增强：dou bao z**

- LLM 可用于生成属性图中点和边的文本描述，这样不仅可以丰富数据内容，还能帮助其他工具或用户更加容易地理解各项关系。

- LLM 还可以基于图中已有的数据生成新的点和边，这对于进行异常检测或预测欺诈行为等任务非常有用。

**查询与探索：**

- LLM 可以用来创建查询属性图的自然语言接口，允许用户以比传统的图查询语言更为直观的方式（例如自然语言）对数据进行提问。

- LLM 也能够汇总图查询结果，并为这些发现生成解释。

**推理和推断：**

LLM 可以用于执行属性图上的推理任务，这可能包括基于现有数据推断节点间新的关系，或识别图中存在的不一致。

![LLM](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-4.png)

示例演示：

以下展示了使用 Llamaindex KnowledgeGraphIndex 和 NebulaGraph Lite Reference 结合 Google Gemini LLM 和 Collab 分步实现知识图谱的过程。

### 为 Gemini 生成 API 密钥

前往 https://aistudio.google.com/app/prompts/new_chat 并生成一个新的 API 密钥。

### 加载 PDF 文档

```
! mkdir ad && cd ad
! curl https://arxiv.org/pdf/2106.07178.pdf --output AD1.pdf
! mv *.pdf ad/
! pip install -q transformers

%pip install llama_index pyvis Ipython langchain pypdf  llama-index-llms-huggingface  llama-index-embeddings-langchain llama-index-embeddings-huggingface
%pip install --upgrade --quiet llama-index-llms-gemini  google-generativeai
%pip install --upgrade --quiet llama-index-graph-stores-nebula nebulagraph-lite
```

### 导入谷歌 API 密钥

```
import os

from google.colab import userdata
GOOGLE_API_KEY = userdata.get('GOOGLE_API_KEY')
os.environ["GOOGLE_API_KEY"] = GOOGLE_API_KE

```

### 导入必要的模块和库

```
import logging
import sys

logging.basicConfig(stream=sys.stdout, level=logging.INFO)
logging.getLogger().addHandler(logging.StreamHandler(stream=sys.stdout))
from llama_index.core import (
                         ServiceContext,
                         KnowledgeGraphIndex)
from llama_index.core import SimpleDirectoryReader
from llama_index.core.storage.storage_context import StorageContext
from pyvis.network import Network

from llama_index.llms.huggingface import HuggingFaceLLM
检查支持的 Gemini 模型。本例中，我们将使用 Gemini 1.0 专业版。

import google.generativeai as genai

for m in genai.list_models():
    if "generateContent" in m.supported_generation_methods:
        print(m.name)
        print(m)

from llama_index.llms.gemini import Gemini

llm = Gemini(model="models/gemini-1.0-pro-latest")

```
### 导入 BGE 嵌入

```
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from llama_index.core import ServiceContext


embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-small-en-v1.5")

```

### 加载广告目录内容

```

documents = SimpleDirectoryReader("/content/ad").load_data()
print(len(documents))

```
###  在本地启动 Nebula 图数据库精简版的 Docker 实例

```
from nebulagraph_lite import nebulagraph_let
n = nebulagraph_let(debug=False)
n.start()

```

### 在 Nebula 存储中设置名为“nebula_ad”的命名空间和节点

```
%ngql --address 127.0.0.1 --port 9669 --user root --password nebula

# If not, create it with the following commands from NebulaGraph's console:
%ngql CREATE SPACE nebula_ad(vid_type=FIXED_STRING(256), partition_num=1, replica_factor=1)

```


```
import time

print("Waiting...")

# Delay for 10 seconds
time.sleep(10)

%ngql --address 127.0.0.1 --port 9669 --user root --password nebula
%ngql USE nebula_ad;
%ngql CREATE TAG entity(name string);
%ngql CREATE EDGE relationship(relationship string);

```
### 将文档数据加载到图数据库中

```
import os
os.environ["NEBULA_USER"] = "root"
os.environ["NEBULA_PASSWORD"] = "nebula"  # default is "nebula"
os.environ[
    "NEBULA_ADDRESS"
] = "127.0.0.1:9669"  # assumed we have NebulaGraph installed locally

space_name = "nebula_ad"
edge_types, rel_prop_names = ["relationship"], [
    "relationship"
]  # default, could be omit if create from an empty kg
tags = ["entity"]  # default, could be omit if create from an empty kg

from llama_index.core import StorageContext
from llama_index.graph_stores.nebula import NebulaGraphStore

graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
)
storage_context = StorageContext.from_defaults(graph_store=graph_store)

from llama_index.core import Settings

Settings.llm = llm
Settings.embed_model = embed_model
Settings.chunk_size = 512

```

### 更新图数据库中的节点数据


```

# NOTE: can take a while!
index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
    include_embeddings=True
)

```

### 检查 Nebula 存储中已插入的图数据

```

# Query some random Relationships with Cypher
%ngql USE nebula_ad;
%ngql MATCH ()-[e]->() RETURN e LIMIT 10

```

### 数据查询与输出：

![v](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-5.png)

### 现在开始查询索引数据

`query_engine = index.as_query_engine()`

```

from IPython.display import display, Markdown

response = query_engine.query(
    "Tell me about Anomaly?",
)
display(Markdown(f"<b>{response}</b>"))

```

**异常现象（Anomaly），在不同应用领域也可能被称作异常值、例外、特殊情况、稀有现象或新奇现象，它们指的是与常规、标准或预期显著不同的异常对象。**

```
from IPython.display import display, Markdown

response = query_engine.query(
    "What are graph anomolies?",
)
display(Markdown(f"<b>{response}</b>"))

```

图异常可以被定义为结构性异常。

## 小结

这些简单的知识图谱有效地捕捉了实体间的复杂关系，这种能力显著提高了查询和推理的精确性、多样性和复杂性。此外，这些知识图谱还可以扩展应用到基于 RDF 的复杂本体图。欢迎大家动手尝试～👏
参考：

[https://link.springer.com/chapter/10.1007/978-3-642-21295-6_13](https://link.springer.com/chapter/10.1007/978-3-642-21295-6_13)

[https://github.com/nebula-contrib/nebulagraph-lite](https://github.com/nebula-contrib/nebulagraph-lite)

[https://docs.llamaindex.ai/en/stable](https://docs.llamaindex.ai/en/stable)

本文由 Rajesh K 原文发布在 Medium

图数据库和知识图谱是管理图结构数据（包括节点（实体）和边（关系））的两大主流方案。图数据库利用基于图的数据模型存储信息，支持通过专用的图查询语言实现对图数据的查询和遍历；知识图谱通过整合推理和派生新知识的机制，增强了图数据库的功能。