各位社区小伙伴大家好，2024 年第一站 nMeetup 来啦！速速与我们面基😄
本次 nMeetup 由 NebulaGraph、FastGPT、厦门创业中心联合主办走进厦门，与社区各位小伙伴进行交流分享。本场活动将聚焦“图数据库 + AI”方向。
此次活动，我们邀请到了厦门大学平潭研究院研究员、DataWhale 开源社区作者杨知铮，厦门巅峰科技有限公司技术负责人、《Llama 大模型实践指南》作者之一涂标松，独立开发者、NgBatis 发起人、NebulaGraph Committer叶伟城，FastGPT maintainer、FastGPT 开发者布道师，B 站科技区万粉博主王子俊，NebulaGraph 产品总监方扬等专家和大咖，为社区的小伙伴们带来精彩的技术分享。
活动免费！欢迎各位小伙伴报名参与！现在即可报名！
<h3 id="post-🕙时间、地点">🕙时间、地点</h3>
<ul>
<li>时间：2024 年 8 月 17 日 13:30-17:00</li>
<li>地点：厦门市湖里区新丰路176-180号火炬荟智空间A区二楼路演厅</li>
</ul>
<h3 id="post-🧾议程">🧾议程</h3>
<img src="https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/C34B6759-1BDF-42D8-8A98-ECDDC4269C3B.png" alt="" />
<h3 id="post-📮报名方式">📮报名方式</h3>
扫描上方海报中的二维码即可报名，<a href="https://www.slidestalk.com/NebulaGraph/xiamen">或点击🔗链接直接报名</a>
<h3 id="post-🎁互动礼品">🎁互动礼品</h3>
线下参与本次活动，现场可获得 NebulaGraph 和 FastGPT 社区周边礼品一份。

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

用户案例

周边工具

特性讲解

开发日志

技术分享

产品实践

社区动态

行业科普

新闻资讯

发版说明

安装部署

解决方案

架构系列

源码解读

NUC2022

性能报告

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

Nebula 架构剖析系列（零）图数据库的整体架构设计

NebulaGraph发布企业版 v3.4.0，深入探索数据价值

美团：主流图数据库厂商选型报告 NebulaGraph vs Dgraph vs JanusGraph

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

如何用 NebulaGraph 图技术搞定 7 个典型社交网络应用？

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

 

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