
date: 2020-02-04

![data-migration](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance01.png)

在文章[《Nebula 架构剖析系列（一）图数据库的存储设计》](https://zhuanlan.zhihu.com/p/86811459)中，我们提过分布式图存储的管理由 Meta Service 来统一调度，它记录了所有 partition 的分布情况，以及当前机器的状态。当 DBA 增减机器时，只需要通过 console 输入相应的指令，Meta Service 便能够生成整个 Balance 计划并执行。而之所以没有采用完全自动 Balance 的方式，主要是为了减少数据搬迁对于线上服务的影响，Balance 的时机由用户自己控制。

在本文中我们将着重讲解在存储层如何实现数据和服务的负载平衡。

简单回顾一下，**NebulaGraph** 的服务可分为 graph，storage，meta。本文主要描述对于存储层（storage）的数据和服务的 balance。这些都是通过 Balance 命令来实现的：Balance 命令有两种，一种需要迁移数据，命令为 `BALANCE DATA` ；另一种不需要迁移数据，只改变 partition 的 raft-leader 分布（负载均衡），命令为 `BALANCE LEADER` 。

# 本文目录

- Balance 机制浅析
- 集群数据迁移
  - Step 1：准备工作
    - Step 1.1 查看现有集群状态
    - Step 1.2 创建图空间
  - Step 2 加入新实例
  - Step 3 迁移数据
  - Step 4 假如要中途停止 balance data
  - Step 5 查看数据迁移结果
  - Step 6 Balance leader
- 批量缩容
- 示例数据迁移

# Balance 机制浅析

在图数据库 NebulaGraph 中， Balance 主要用来 balance leader 和 partition，**只涉及 leader 和 partition 在机器之间转移，不会增加或者减少 leader 和 partition 的数量**。

上线新机器并启动相应的 Nebula 服务后，storage 会自动向 meta 注册。Meta 会计算出一个新的 partition 分布，然后通过 **remove partition** 和 **add partition** 逐步将数据从老机器搬迁到新的机器上。这个过程所对应的命令是 `BALANCE DATA` ，通常数据搬迁是个比较漫长的过程。

但 BALANCE DATA 仅改变了数据和副本在机器之间的均衡分布，leader（和对应的负载） 是不会改变的，因此还需要通过命令`BALANCE LEADER`来实现负载的均衡。这个过程也是通过 meta 实现的。

# 集群数据迁移

以下举例说明 `BALANCE DATA` 的使用方式。本例将从 3 个实例（进程）扩展到 8 个实例（进程）：

## Step 1：准备工作

部署一个 3 副本的集群，1个 graphd，1个 metad，3 个 storaged（具体部署方式请参考集群部署文：[https://zhuanlan.zhihu.com/p/80335605](https://zhuanlan.zhihu.com/p/80335605)），通过 `SHOW HOSTS`  命令可以看到集群的状态信息：

### Step 1.1 查看现有集群状态
按照集群部署文档部署好 3 副本集群之后，用 `SHOW HOSTS` 命令查看下现在集群情况：
```bash
nebula> SHOW HOSTS
================================================================================================
| Ip            | Port  | Status | Leader count | Leader distribution | Partition distribution |
================================================================================================
| 192.168.8.210 | 34600 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34700 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34500 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
Got 3 rows (Time spent: 5886/6835 us)
```

`SHOW HOSTS` 返回结果解释：

- _**IP**_，_**Port**_ 表示当前的 storage 实例。这个集群启动了 3 个 storaged 服务，并且还没有任何数据。(192.168.8.210:34600，192.168.8.210:34700，192.168.8.210:34500)
- _**Status**_ 表示当前实例的状态，目前有 online/offline 两种。当机器下线以后（metad 在一段间隔内收不到其心跳），将把其更改为 offline。 这个时间间隔可以在启动 metad 的时候通过设置 `expired_threshold_sec` 来修改，当前默认值是 10 分钟。
- _**Leader count**_：表示当前实例 Raft leader 数目。
- _**Leader distribution**_：表示当前 leader 在每个 space 上的分布，目前尚未创建任何 space。( space 可以理解为一个独立的数据空间，类似 MySQL 的 Database）
- _**Partition distribution**_：不同 space 中 partition 的数目。

![cluster](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance02.png)

可以看到  _Leader distribution_ 和 _Partition distribution_ 暂时都没有数据。

### Step 1.2 创建图空间

创建一个名为 test 的图空间，包含 100 个 partition，每个 partition 有 3 个副本。

```shell
nebula> CREATE SPACE test (PARTITION_NUM=100, REPLICA_FACTOR=3)
```

片刻后，使用 `SHOW HOSTS` 命令显示集群的分布。

```bash
nebula> SHOW HOSTS
================================================================================================
| Ip            | Port  | Status | Leader count | Leader distribution | Partition distribution |
================================================================================================
| 192.168.8.210 | 34600 | online | 0            | test: 0             | test: 100              |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34700 | online | 52           | test: 52            | test: 100              |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34500 | online | 48           | test: 48            | test: 100              |
------------------------------------------------------------------------------------------------
```

![cluster](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance03.png)

如上，创建包含 100 个 _partitio_n 和 3 个 _replica_ 图空间之后，3 个实例的 _Leader distribution_ 和 _Partition distribution _有了对应的数值，对应的 _Partition distribution _都为 100。当然，这样的 learder 分布还不均匀。

## Step 2 加入新实例

启动 5 个新 storaged 实例进行扩容。启动完毕后，使用 `SHOW HOSTS` 命令查看新的状态：

```bash
nebula> SHOW HOSTS
================================================================================================
| Ip            | Port  | Status | Leader count | Leader distribution | Partition distribution |
================================================================================================
| 192.168.8.210 | 34600 | online | 0            | test: 0             | test: 100              |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34900 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 35940 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34920 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 44920 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34700 | online | 52           | test: 52            | test: 100              |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34500 | online | 48           | test: 48            | test: 100              |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34800 | online | 0            | No valid partition  | No valid partition     |
------------------------------------------------------------------------------------------------
```

![add-hosts-cluster](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance04.png)

上新实例之后，集群由原来 3 个实例变成了 8 个实例。上图数据库 icon 为蓝色的图示为新增的 5 个实例，此时由于仅仅加入了集群，新实例的状态为 Online，但此时 _Leader distribution_ 和 _Partition distribution _并没有数值，说明还不会参与服务。

## Step 3 迁移数据

运行 `BALANCE DATA` 命令。

```bash
nebula> BALANCE DATA
==============
| ID         |
==============
| 1570761786 |
--------------
```

如果当前集群有新机器加入，则会生成一个新的计划 ID。对于已经平衡的集群，重复运行 `BALANCE DATA` 不会有任何新操作。如果当前有正在执行的计划，那会显示当前计划的 ID。

也可通过 `BALANCE DATA $id` 查看这个 balance 的具体执行进度。

```bash
nebula> BALANCE DATA 1570761786
===============================================================================
| balanceId, spaceId:partId, src->dst                           | status      |
===============================================================================
| [1570761786, 1:1, 192.168.8.210:34600->192.168.8.210:44920]   | succeeded   |
-------------------------------------------------------------------------------
| [1570761786, 1:1, 192.168.8.210:34700->192.168.8.210:34920]   | succeeded   |
-------------------------------------------------------------------------------
| [1570761786, 1:1, 192.168.8.210:34500->192.168.8.210:34800]   | succeeded   |
-------------------------------------------------------------------------------
...//这里省略一些。以下一行为例
-------------------------------------------------------------------------------
| [1570761786, 1:88, 192.168.8.210:34700->192.168.8.210:35940]  | succeeded   |
-------------------------------------------------------------------------------
| Total:189, Succeeded:170, Failed:0, In Progress:19, Invalid:0 | 89.947090%  |
-------------------------------------------------------------------------------
Got 190 rows (Time spent: 5454/11095 us)
```

`BALANCE DATA $id` 返回结果说明：

- 第一列 balanceId，spaceId:partId，src->dst 表示一个具体的 balance task。<br />
以 `1570761786, 1:88, 192.168.8.210:34700->192.168.8.210:35940` 为例：
  - 1570761786 为 balance ID
  - 1:88，1 表示当前的 spaceId（也就是 space test 的 ID），88 表示迁移的 partitionId
  - 192.168.8.210:34700->192.168.8.210:35940，表示数据从 _192.168.8.210:34700_ 搬迁至 _192.168.8.210:35940_。而原先 _192.168.8.210:34700_ 中的数据将会在**迁移完成后再 GC 删除**
- 第二列表示当前 task 的运行状态，有 4 种状态
  - Succeeded：运行成功
  - Failed：运行失败
  - In progress：运行中
  - Invalid：无效的 task

最后对所有 task 运行状态的统计，部分 partition 尚未完成迁移。

## Step 4 假如要中途停止 balance data
`BALANCE DATA STOP` 命令用于停止已经开始执行的 balance data 计划。如果没有正在运行的 balance 计划，则会返回错误提示。如果有正在运行的 balance 计划，则会返回计划对应的 ID。

> 由于每个 balance 计划对应若干个 balance task，`BALANCE DATA STOP` 不会停止已经开始执行的 balance task，只会取消后续的 task，已经开始的 task 将继续执行直至完成。


用户可以在 `BALANCE DATA STOP` 之后输入 `BALANCE DATA $id` 来查看已经停止的 balance 计划状态。

所有已经开始执行的 task 完成后，可以再次执行 `BALANCE DATA`，重新开始 balance。如果之前停止的计划中有失败的 task，则会继续执行之前的计划，如果之前停止的计划中所有 task 都成功了，则会新建一个 balance 计划并开始执行。

## Step 5 查看数据迁移结果

大多数情况下，搬迁数据是个比较漫长的过程。但是搬迁过程不会影响已有服务。现在可以通过 `SHOW HOSTS` 查看运行后的 partition 分布。

```bash
nebula> SHOW HOSTS
================================================================================================
| Ip            | Port  | Status | Leader count | Leader distribution | Partition distribution |
================================================================================================
| 192.168.8.210 | 34600 | online | 3            | test: 3             | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34900 | online | 0            | test: 0             | test: 38               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 35940 | online | 0            | test: 0             | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34920 | online | 0            | test: 0             | test: 38               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 44920 | online | 0            | test: 0             | test: 38               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34700 | online | 35           | test: 35            | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34500 | online | 24           | test: 24            | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34800 | online | 38           | test: 38            | test: 38               |
------------------------------------------------------------------------------------------------
Got 8 rows (Time spent: 5074/6488 us)
```

![partition-distribution](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance05.png)

_Partition distribution_ 相近，partition 总数 300 不变且 partition 已均衡的分布至各个实例。

如果有运行失败的 task，可再次运行 `BALANCE DATA` 命令进行修复。如果多次运行仍无法修复，请与社区联系 [GitHub](https://github.com/vesoft-inc/nebula/issues)。

## Step 6 Balance leader

`BALANCE DATA` 仅能 balance partition，但是 leader 分布仍然不均衡，这意味着**旧实例的服务较重，而新实例的服务能力未得到充分使用**。运行 `BALANCE LEADER` 重新分布 Raft leader：

```bash
nebula> BALANCE LEADER
```

片刻后，使用 `SHOW HOSTS` 命令查看，此时 Raft leader 已均匀分布至所有的实例。

```bash
nebula> SHOW HOSTS
================================================================================================
| Ip            | Port  | Status | Leader count | Leader distribution | Partition distribution |
================================================================================================
| 192.168.8.210 | 34600 | online | 13           | test: 13            | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34900 | online | 12           | test: 12            | test: 38               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 35940 | online | 12           | test: 12            | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34920 | online | 12           | test: 12            | test: 38               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 44920 | online | 13           | test: 13            | test: 38               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34700 | online | 12           | test: 12            | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34500 | online | 13           | test: 13            | test: 37               |
------------------------------------------------------------------------------------------------
| 192.168.8.210 | 34800 | online | 13           | test: 13            | test: 38               |
------------------------------------------------------------------------------------------------
Got 8 rows (Time spent: 5039/6346 us)
```

![balance-leader-result](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance06.png)

如上， `BALANCE LEADER` 成功执行后，新增的实例和原来的实例（对应上图 icon 蓝色和黑色图示）的 _Leader distribution _相近， 所有实例已均衡，此外，也可以看到 **Balance 命令只涉及 leader 和 partition 在物理机器上的转移，并没有增加或者减少 leader 和 partition。**

# 批量缩容

**NebulaGraph** 支持指定需要下线的机器进行批量缩容。语法为 `BALANCE DATA REMOVE $host_list`，例如：`BALANCE DATA REMOVE 192.168.0.1:50000,192.168.0.2:50000`，将指定移除 192.168.0.1:50000，192.168.0.2:50000 两台机器。

> 如果移除指定机器后，不满足副本数要求（例如剩余机器数小于副本数），NebulaGraph 将拒绝本次 balance 请求，并返回相关错误码。

# 示例数据迁移

上面讲了如何从 3 个实例变成 8个实例的集群，如果你对上文有疑问，记得在本文的评论区留言哈。我们现在看看上面迁移的过程，_192.168.8.210:34600_ 这个实例的状态变化。

![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/Balance07.png)

说明：有颜色为红色说明对应的数值发生变化，如果数值不变，则为黑色。

# 附录

最后是 Nebula 的 GitHub 地址，欢迎大家试用，有什么问题可以向我们提 issue。GitHub 地址：[https://github.com/vesoft-inc/nebula](https://0x7.me/zhihu2github)


在本文中我们将着重讲解在存储层如何实现数据和服务的负载平衡。

NebulaGraph 图数据库设计实践 | 存储服务的负载均衡和数据迁移

![Address-Sanitizer](https://www-cdn.nebula-graph.com.cn/nebula-blog/AddressSanitizer01.png)

作为 C/ C++ 工程师，在开发过程中会遇到各类问题，最常见便是**内存使用问题**，比如，**越界**，**泄漏**。过去常用的工具是 Valgrind，但使用 Valgrind 最大问题是它会极大地降低程序运行的速度，初步估计会降低 10 倍运行速度。而 Google 开发的 [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer) 这个工具很好地解决了 Valgrind 带来性能损失问题，它非常快，只拖慢程序 2 倍速度。

# AddressSanitizer 概述

AddressSanitizer 是一个基于编译器的测试工具，可在运行时检测 C/C++ 代码中的多种内存错误。严格上来说，AddressSanitizer 是一个编译器插件，它分为两个模块，一个是编译器的 instrumentation 模块，一个是用来替换 malloc/free 的动态库。

Instrumentation 主要是针对在 llvm 编译器级别对访问内存的操作（store，load，alloc等），将它们进行处理。动态库主要提供一些运行时的复杂的功能（比如 poison/unpoison shadow memory）以及将 malloc/free 等系统调用函数 hook 住。

## AddressSanitizer 基本使用

根据 AddressSanitizer Wiki 可以检测下面这些内存错误
- Use after free：访问堆上已经被释放的内存
- Heap buffer overflow：堆上缓冲区访问溢出
- Stack buffer overflow：栈上缓冲区访问溢出
- Global buffer overflow：全局缓冲区访问溢出
- Use after return：访问栈上已被释放的内存
- Use after scope：栈对象使用超过定义范围
- Initialization order bugs：初始化命令错误
- Memory leaks：内存泄漏

这里我只简单地介绍下基本的使用，详细的使用文档可以看官方的编译器使用文档，比如 [Clang](https://clang.llvm.org/docs/AddressSanitizer.html) 的文档：[https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)

### Use after free 实践例子
下面这段代码是一个很简单的 Use after free 的例子：

```cpp
//use_after_free.cpp
#include <iostream>
int main(int argc, char **argv) {
  int *array = new int[100];
  delete [] array;
  std::cout << array[0] << std::endl;
  return 1;
}
```

编译代码，并且运行，这里可以看到只需要在编译的时候带上 `-fsanitize=address`  选项就可以了。

```shell
clang++  -O -g -fsanitize=address ./use_after_free.cpp
./a.out
```

最终我们会看到如下的输出：

```
==10960==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x00010d471df0 bp 0x7ffee278e6b0 sp 0x7ffee278e6a8
READ of size 4 at 0x614000000040 thread T0
    #0 0x10d471def in main use_after_free.cpp:6
    #1 0x7fff732c17fc in start (libdyld.dylib:x86_64+0x1a7fc)

0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)
freed by thread T0 here:
    #0 0x10d4ccced in wrap__ZdaPv (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x51ced)
    #1 0x10d471ca1 in main use_after_free.cpp:5
    #2 0x7fff732c17fc in start (libdyld.dylib:x86_64+0x1a7fc)

previously allocated by thread T0 here:
    #0 0x10d4cc8dd in wrap__Znam (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x518dd)
    #1 0x10d471c96 in main use_after_free.cpp:4
    #2 0x7fff732c17fc in start (libdyld.dylib:x86_64+0x1a7fc)

SUMMARY: AddressSanitizer: heap-use-after-free use_after_free.cpp:6 in main
```

可以看到一目了然，非常清楚的告诉了我们在哪一行内存被释放，而又在哪一行内存再次被使用。

还有一个是内存泄漏，比如下面的代码，显然 p 所指的内存没有被释放。

```c
void *p;

int main() {
        p = malloc(7);
        p = 0; // The memory is leaked here.
        return 0;
}
```

编译然后运行

```
clang -fsanitize=address -g  ./leak.c
./a.out
```

可以看到如下的结果

```
=================================================================
==17756==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 7 byte(s) in 1 object(s) allocated from:
    #0 0x4ffc80 in malloc (/home/simon.liu/workspace/a.out+0x4ffc80)
    #1 0x534ab8 in main /home/simon.liu/workspace/./leak.c:4:8
    #2 0x7f127c42af42 in __libc_start_main (/usr/lib64/libc.so.6+0x23f42)

SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
```

不过这里要注意**内存泄漏的检测只会在程序最后退出之前进行检测**，也就是说如果你在运行时如果不断地分配内存，然后在退出的时候对内存进行释放，AddressSanitizer 将不会检测到内存泄漏，这种时候可能你就需要另外的工具了 JeMalloc / TCMalloc。

## AddressSanitizer 基本原理

这里简单介绍一下 AddressSanitizer 的实现，更详细的算法实现可以看《[AddressSanitizer: a fast address sanity checker](https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf)》：[https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf](https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf)

AddressSanitizer 会替换你的所有 malloc 以及 free，然后已经被分配（malloc）的内存区域的前后会被标记为 `poisoned` （主要是为了处理 overflow 这种情况)，而释放（free）的内存会被标记为 poisoned（主要是为了处理 Use after free）。你的代码中的每一次的内存存取都会被编译器做类似下面的翻译.

before:

```c
*address = ...;  // or: ... = *address;
```

after:

```c
shadow_address = MemToShadow(address);
if (ShadowIsPoisoned(shadow_address)) {
  ReportError(address, kAccessSize, kIsWrite);
}
*address = ...;  // or: ... = *address;
```

这里可以看到首先会对内存地址有一个翻译（MemToShadow）的过程，然后再来判断当所访问的内存区域是否为 poisoned，如果是则直接报错并退出。

这里之所以会有这个翻译是因为 AddressSanitizer 将虚拟内存分为了两部分：

1. Main application memory（Mem）也就是被当前程序自身使用的内存
1. Shadow memory 简单来说就是保存了主存元信息的一块内存，比如主存的那些区域被 posioned 都是在 Shadow memory 中保存的

## AddressSanitizer 和其他内存检测工具对比
[下图](https://github.com/google/sanitizers/wiki/AddressSanitizerComparisonOfMemoryTools#summary)是 AddressSanitizer 与其他的一些内存检测工具的对比:

![comparation-addresssanitizer-valgrind-mudflap](https://www-cdn.nebula-graph.com.cn/nebula-blog/AddressSanitizer02.png)

参数说明：

- _**DBI**_: dynamic binary instrumentation（动态二进制插桩）
- _**CTI**_: compile-time instrumentation （编译时插桩）
- _**UMR**_: uninitialized memory reads （读取未初始化的内存）
- _**UAF**_: use-after-free (aka dangling pointer) （使用释放后的内存）
- _**UAR**_: use-after-return （使用返回后的值）
- _**OOB**_: out-of-bounds （溢出）
- _**x86**_: includes 32- and 64-bit.

可以看到相比于 Valgrind，AddressSanitizer 只会拖慢程序 2 倍运行速度。当前 AddressSanitizer 支持 GCC 以及 Clang，其中 GCC 是从 4.8 开始支持，而 Clang 的话是从 3.1 开始支持。

## AddressSanitizer 的使用注意事项

1. AddressSanitizer 在发现内存访问违规时，应用程序并不会自动崩溃。这是由于在使用模糊测试工具时，它们通常都是通过检查返回码来检测这种错误。当然，我们也可以在模糊测试进行之前通过将环境变量 ASAN_OPTIONS 修改成如下形式来迫使软件崩溃：

```bash
export ASAN_OPTIONS='abort_on_error=1'/
```

2. AddressSanitizer 需要相当大的虚拟内存（大约 20 TB），不用担心，这个只是虚拟内存，你仍可以使用你的应用程序。但像 american fuzzy lop 这样的模糊测试工具就会对模糊化的软件使用内存进行限制，不过你仍可以通过禁用内存限制来解决该问题。唯一需要注意的就是，这会带来一些风险：测试样本可能会导致应用程序分配大量的内存进而导致系统不稳定或者其他应用程序崩溃。因此在进行一些重要的模糊测试时，不要去尝试在同一个系统上禁用内存限制。

# 在 NebulaGraph 中开启 AddressSanitizer

我们在 NebulaGraph 中也使用了 AddressSanitizer，它帮助我们发现了非常多的问题。而在 NebulaGraph 中开启 AddressSanitizer 很简单，只需要在 Cmake 的时候带上打开 ENABLE_ASAN 这个 Option 就可以，比如:

```
Cmake -DENABLE_ASAN=On
```

这里建议所有的开发者在开发完毕功能运行单元测试的时候都打开 AddressSanitizer 来运行单元测试，这样可以发现很多不容易发现的内存问题，节省很多调试的时间。

# 推荐阅读

- [Jepsen 测试框架在图数据库 NebulaGraph 中的实践](https://nebula-graph.com.cn/posts/practice-jepsen-test-framework-in-nebula-graph/)


作为 C/ C++ 工程师，在开发过程中会遇到各类问题，最常见便是内存使用问题，本文讲述了如何使用 Google 开源的 AddressSanitizer 来检测内存问题。

如何应用 AddressSanitizer 发现程序内存错误？

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink01.png)

# 前言

本文由 NebulaGraph 实习生@王杰贡献。

最近 @Yener 开源了史上最大规模的中文知识图谱——[OwnThink](https://www.ownthink.com/)（链接：[https://github.com/ownthink/KnowledgeGraphData](https://github.com/ownthink/KnowledgeGraphData) ），数据量为 1.4 亿条。

本文介绍如何将这份数据快速导入图数据库 NebulaGraph，全过程大约需要 30 分钟。

# 中文知识图谱 OwnThink 简介

## 思知（OwnThink）

知识图谱是由 Google 在 2012 年提出来的一个概念。主要是用来**描述真实世界中存在的各种实体和概念，以及他们之间的关系**。在搜索引擎、问答机器人、知识抽取等多个领域有着诸多应用。

最近 Yener 开源了史上最大规模的中文知识图谱—— [OwnThink](https://www.ownthink.com/)（链接：[https://github.com/ownthink/KnowledgeGraphData](https://github.com/ownthink/KnowledgeGraphData)），数据量为 1.4 亿条。数据以 `(实体, 属性, 值)` 和 `(实体, 关系, 实体)` 混合的**三元组**形式存储，数据格式为 csv。


## 查看原始文件

由于 ownthink_v2.csv 数据过多，摘录部分数据为例：

```
红色食品,描述,红色食品是指食品为红色、橙红色或棕红色的食品。

红色食品,是否含防腐剂,否
红色食品,主要食用功效,预防感冒，缓解疲劳
红色食品,用途,增强表皮细胞再生和防止皮肤衰老
大龙湫,描述,雁荡山景区分散，东起羊角洞，西至锯板岭；南起筋竹溪，北至六坪山。
大龙湫,中文名称,大龙湫
大龙湫,外文名称,big dragon autrum
大龙湫,门票价格,50元
大龙湫,著名景点,芙蓉峰
姚明[中国篮球协会主席、中职联公司董事长],妻子,叶莉
```

这里的 `(红色食品,是否含防腐剂,否)` 就是典型的 `(实体, 属性, 值)` 形式的三元组数据; 而 `(姚明[中国篮球协会主席、中职联公司董事长],妻子,叶莉)` 是典型的 `(实体, 关系, 实体)` 形式的三元组数据。

# Step 1. 数据建模与清洗准备

## 建模

NebulaGraph 是一个开源的分布式图数据库（链接：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)），相比 Neo4j 来说，它的主要特点是完全的分布式，因此**图数据库 NebulaGraph 适合处理数据量超过单机的场景**。

![github-nebula](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink02.png)

图数据库**通常支持的数据模型为有向属性图（directed property graph）**。图中的每个顶点（vertex）可以用标签（tag）来表示类型（Neo4j 叫做 Label），顶点和顶点之间的关系用边（edge）连接起来。每种 tag 和 edge 还可以带有属性。——然而，这些功能对于知识图谱的三元组数据没什么意义:

![modeling](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink03.png)

分析上图的三元组数据，发现无论是 `(实体, 属性, 值)` 形式的三元组数据，还是 `(实体, 关系, 实体)` 形式的三元组数据，每条三元组数据均可以建模成**两个点**和**一条边**的形式。前者三元组中的“**实体**”和“**值**”建模为**两个点**（起点、终点），“**属性**”建模为**一条边**，后者三元组中的两个“**实体**”也建模为**两个点**（起点、终点），“**关系**”建模为**一条边**.

而且，所有的点都是相同类型（取名叫`entity` ），只需要一个属性（叫 `name` )，所有的边也都是同一类型(取名叫 `relation` ），边上也只有一个属性（叫 `name` ）。

![modeling](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink04.png)

比如 `(大龙湫,著名景点,芙蓉峰)` 可以表示成下图这个样子：

![modeling](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink05.png)

## 数据清洗和预处理

按照前一节的分析，原始的每条**三元组数据**，还需要清洗**转换为两个点和一条边**才能变成属性图的模型。

### 下载清洗工具

本文测试的时候，使用的操作系统是 CentOS 7.5，工具由 Golang 语言编写而成。

你可以在这里（链接：[https://github.com/jievince/rdf-converter](https://github.com/jievince/rdf-converter)）下载这个简单的清洗工具源代码并编译使用。

该工具会把转换后的顶点的数据写入到 vertex.csv 文件、边数据写入到 edge.csv 文件。

说明：在测试过程中，发现有大量的重复点数据，所以工具里面也做了去重。完全去重后的点的数据大概是 4600 万条，完全去重后的边的数据大概是 1 亿 4000 万条。

清洗完的 `vertex.csv` 文件长这样：
```
-2469395383949115281,过度包装
-5567206714840433083,Over  Package
3836323934884101628,有的商品故意增加包装层数
1185893106173039861,很多采用实木、金属制品
3455734391170888430,非科学
9183164258636124946,教育
5258679239570815125,成熟市场
-8062106589304861485,"成熟市场是指低增长率,高占有率的市场。"
```

说明：每一行是一个顶点，第一列整型 `-2469395383949115281` 是顶点的 ID（叫做 `VID`），它是由第二列文字通过 `hash` 计算出来的，例如 `-2469395383949115281` 就是由 `std::hash("过度包装")` 计算出来的值。

清洗完的 `edge.csv` 文件:

```
3413383836870836248,-948987595135324087,含义
3413383836870836248,8037179844375033188,定义
3413383836870836248,-2559124418148243756,标签
3413383836870836248,8108596883039039864,标签
2587975790775251569,-4666568475926279810,描述
2587975790775251569,2587975790775251569,中文名称
2587975790775251569,3771551033890875715,外文名称
2587975790775251569,2900555761857775043,地理位置
2587975790775251569,-1913521037799946160,占地面积
2587975790775251569,-1374607753051283066,开放时间
```

说明：第一列是起点的 VID，第二列是终点的 VID，第三列是这条边的"**属性**"或者"**描述**"。

在本机完全去重的清洗程序运行时间大约是 6 分钟。

# Step 2. NebulaGraph 启动准备

## 下载和安装

登陆 GitHub 后，在这里（链接：[https://github.com/vesoft-inc/nebula/actions](https://github.com/vesoft-inc/nebula/actions)）找到 Nebula 的安装包。

![action](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink06.png)

找到你所用系统对应的下载链接：

![package](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink07.png)

笔者系统是 CentOS 7.5，下载 CentOS 7.5 最新的压缩包，解压后能找到 rpm 安装包 `nebula-5ace754.el7-5.x86_64.rpm`，注意 `5ace754` 是 git commit 号，使用时可能会有所不同。下载好后解压，输入下面命令进行安装，记得替换成新的 git commit：

```
$ rpm -ivh nebula-5ace754.el7-5.x86_64.rpm
```

### 启动 NebulaGraph 服务

在 `命令行 CLI` 输入下面命令启动服务

```
$ /usr/local/nebula/scripts/nebula.service start all
```

命令执行结果如下：

![result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink08.png)

可以执行以下命令检查服务是否成功启动

```
$ /usr/local/nebula/scripts/nebula.service status all
```

命令执行结果如下：

![result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink09.png)

## 连接 NebulaGraph 服务

输入下面命令连接 NebulaGraph：

```
$ /usr/local/nebula/bin/nebula -u user -p password
```

命令执行结果如下：

![result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink10.png)

## 准备 schema 等元数据

NebulaGraph 的使用风格有点接近 MySQL，需要先准备各种元信息。

### 新建图空间 space

create space 的概念接近 MySQL 里面 create database。在 nebula console 里面输入下面这个命令。

```
nebula> CREATE SPACE test;
```

### 进入 test space

```
nebula> USE test;
```

### 创建点类型（entity）

```
nebula> CREATE TAG entity(name string);
```

### 创建边类型 (relation)

```
nebula> CREATE EDGE relation(name string);
```

最后简单确认下元数据是不是正确。

**查看 entity 标签的属性**：

```
nebula> DESCRIBE TAG entity;
```

结果如下：

![result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink11.png)

**查看 relation 边类型的属性**：

```
nebula> DESCRIBE EDGE relation;
```

结果如下：

![result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink12.png)

# Step 3. 使用 nebula-importer 导入数据

登陆 GitHub 进入 [https://github.com/vesoft-inc/nebula-importer](https://github.com/vesoft-inc/nebula-importer) ，nebula-importer 这个工具也是 Golang 语言写的，在这里下载并编译源代码。

![importer](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink13.png)

另外，准备一个 YAML 配置文件，告诉这个 importer 工具去哪里找 csv 文件。（可直接复制下面这段）

```yaml
version: v1rc1
description: example
clientSettings:
  concurrency: 10 # number of graph clients
  channelBufferSize: 128
  space: test
  connection:
    user: user
    password: password
    address: 127.0.0.1:3699
logPath: ./err/test.log
files:
  - path: ./vertex.csv
    failDataPath: ./err/vertex.csv
    batchSize: 100
    type: csv
    csv:
      withHeader: false
      withLabel: false
    schema:
      type: vertex
      vertex:
        tags:
          - name: entity
            props:
              - name: name
                type: string
  - path: ./edge.csv
    failDataPath: ./err/edge.csv
    batchSize: 100
    type: csv
    csv:
      withHeader: false
      withLabel: false
    schema:
      type: edge
      edge:
        name: relation
        withRanking: false
        props:
          - name: name
            type: string
```

说明：测试时候发现 csv 数据文件中有大量转义字符 (\\) 和换行字符 (\\r)，nebula-importer 也做了处理。

最后：开始导入数据 👏👏

```
go run importer.go --config ./config.yaml
```

执行过程如下：

![result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink14.png)

可以看到, 本次导入 QPS 大约在 40 w/s。全部导入总耗时大约 15 min。

# Step 4. 随便读点什么试试

导入完毕后，我们可以使用 NebulaGraph 服务做一些简单的查询。回到 NebulaGraph 的`命令行 CLI` ：

```
$ /usr/local/nebula/bin/nebula -u user -p password
```

进入刚才导入的三元组数据的 test 空间：

```
nebula> USE test;
```

现在，我们可以做一些简单查询

- 例 1：与姚明有直接关联的边的类型和点的属性

```
(user@127.0.0.1) [test]> GO FROM hash("姚明[中国篮球协会主席、中职联公司董事长]") OVER relation  YIELD relation.name AS Name, $$.entity.name AS Value;
```

执行结果如下：

![command](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink15.png)

可以看到：本次查询返回 51 条数据，耗时 3 ms 左右；

- 例2：查询姚明和其妻子叶莉在三跳之内的所有路径

```
(user@127.0.0.1) [test]> FIND ALL PATH FROM hash("姚明[中国篮球协会主席、中职联公司董事长]")  TO hash("叶莉") OVER relation UPTO 3 STEPS; 
```

执行结果如下：

![command-result](https://www-cdn.nebula-graph.com.cn/nebula-blog/OwnThink16.png)

当数据量较大时，查找全路径/最短经之类的操作会比较耗时。可以看到：本次查询返回 8 条数据，说明姚明和其妻子叶莉在三跳之内共有 8 条直接或间接的关系。

# 总结

本篇文章涉及到的一些概念和链接：

- OwnThink 的中文知识图谱数据：[https://github.com/ownthink/KnowledgeGraphData](https://github.com/ownthink/KnowledgeGraphData)。它的数据以三元组形式保存为 csv
- NebulaGraph 是一个开源的图数据库，GitHub 地址：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)，和 Neo4j 相比，它是分布式的
- 数据清洗工具，GitHub 地址：[https://github.com/jievince/rdf-converter](https://github.com/jievince/rdf-converter)。因为原始的图谱 ownthink_v2.csv 数据以三元组形式保存，并和一般图数据库的属性图模型略微有些不同，所以写了一个 Go 语言工具将原始 ownthink_v2.csv 变成 vertex.csv 和 edge.csv
- 数据导入工具，GitHub 地址：[https://github.com/vesoft-inc/nebula-importer](https://github.com/vesoft-inc/nebula-importer)。将清洗完的 vertex.csv 和 edge.csv 批量写入到 NebulaGraph。

## 后面的工作

- 调整 Nebula 的参数。似乎默认的日志级别和内存都不是很好，可以用下面这个命令关闭日志，这样导入性能可以好很多。

```
curl "http://127.0.0.1:12000/set_flags?flag=minloglevel&value=4"
```

- 写个对应的 Python 版本示例

## 附录

NebulaGraph GitHub 地址：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) 

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

> NebulaGraph：一个开源的分布式图数据库。

> GitHub：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)

> 知乎：[https://www.zhihu.com/org/nebulagraph/posts](https://www.zhihu.com/org/nebulagraph/posts)

> 微博：[https://weibo.com/nebulagraph](https://weibo.com/nebulagraph)


本文介绍如何将知识图谱数据快速导入图数据库 Nebula Graph 中并做简单的 CRUD

使用图数据库 Nebula Graph 数据导入快速体验知识图谱 OwnThink

![权力的游戏](https://www-cdn.nebula-graph.com.cn/nebula-blog/game-of-thrones-01.png)

在[上一篇](https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/)[1]中，我们通过 NetworkX 和 Gephi 展示了<权力的游戏>中的人物关系。在本篇中，我们将展示如何通过 NetworkX 访问图数据库 [NebulaGraph](https://github.com/vesoft-inc/nebula)。

## NetworkX

NetworkX [2] 是一个用 Python 语言开发的图论与复杂网络建模工具，内置了大量常用的图与复杂网络分析算法，可以方便地进行复杂网络数据分析、仿真建模等工作，功能丰富，简单易用。

在 NetworkX 中，图是由顶点、边和可选的属性构成的数据结构。顶点表示数据，边是由两个顶点唯一确定的，表示两个顶点之间的关系。顶点和边也可以拥有更多的属性，以存储更多的信息。

NetworkX 支持 4 种类型的图：

- Graph：无向图
- DiGraph: 有向图
- MultiGraph: 多重无向图
- MultiDiGraph: 多重有向图

在 NetworkX 中创建一个无向图：
```python
import networkx as nx
G = nx.Graph()
```
添加顶点：
```python
G.add_node(1)
G.add_nodes_from([2,3,4])
G.add_node(2,name='Tom',age=23)
```
添加边：
```python
G.add_edge(2,3)
G.add_edges_from([(1,2),(1,3)])
g.add_edge(1, 2, start_year=1996, end_year=2019)
```

在上一篇文章（一）中，我们已经演示了 NetworkX 的 Girvan-Newman 社区发现算法。

## 图数据库 NebulaGraph

NetworkX 通常使用本地文件作为数据源，这在静态网络研究的时候没什么问题，但如果图网络经常会发生变化——例如某些中心节点已经不存在(Fig.1)或者引入了重要的网络拓扑变化(Fig.2)——每次生成全新的静态文件再加载分析就有些麻烦，最好整个变化过程可以持久化在一个数据库中，并且可以实时地直接从数据库中加载子图或者全图做分析。本文选用 NebulaGraph [3]作为存储图数据的图数据库。

![权力的游戏](https://www-cdn.nebula-graph.com.cn/nebula-blog/tv-game-thrones.png)
Fig. 1

![权力的游戏](https://www-cdn.nebula-graph.com.cn/nebula-blog/tv-game-thrones-02.png)
Fig. 2

NebulaGraph 提供了两种方式来获取图结构：

1. 编写一个查询语句，拉取一个子图；
1. 全量扫描底层存储，获取一个完整的全图。

第一种方式适合在一个大规模的图网络中通过精细的过滤和剪枝条件来获取符合需求的若干个点和边。第二种方式更适合于全图的分析，这通常是在项目前期对全图进行一些启发式探索，当有进一步认知后再用第一种方式做精细的剪枝分析。

分析完 NebulaGraph 两种获取图结构方式后，下面来查看 NebulaGraph 的 Python 客户端代码，nebula-python/nebula/ngStorage/StorageClient.py 与 nebula-python/nebula/ngMeta/MetaClient.py 就是和底层存储交互的 API, 里面有扫描点、扫描边、读取一堆属性等等一系列丰富的接口。

下面两个接口可以用来读取所有的点、边数据：

```python
def scan_vertex(self, space, return_cols, all_cols, limit, start_time, end_time)
def scan_edge(self, space, return_cols, all_cols, limit, start_time, end_time)
```

1. 初始化一个客户端，和一个 scan_edge_processor。scan_edge_processor 用来对读出来的边数据进行解码：
```python
meta_client = MetaClient([('192.168.8.16', 45500)])
meta_client.connect()
storage_client = StorageClient(meta_client)
scan_edge_processor = ScanEdgeProcessor(meta_client)
```
2. 初始化 scan_edge 接口的各项参数：
```python
space_name = 'nba' # 要读取的图空间名称
return_cols = {} # 要返回的边（或点）及其属性列
return_cols['serve'] = ['start_year', 'end_year']
return_cols['follow'] = ['degree']
allCols = False # 是否返回所有属性列，当该值为 False 时，仅返回在 returnCols 里指定的属性列，当为 True 时，返回所有属性列
limit = 100 # 最多返回的数据条数
start_time = 0 
end_time = sys.maxsize
```

3. 调用 scan_part_edge 接口，该接口会返回一个 scan_edge_response 对象的迭代器：
```python
scan_edge_response_iterator = storage_client.scan_edge(space_name, return_cols, all_cols, limit, start_time, end_time)
```

4. 不断读取该迭代器所指向的 scan_edge_response 对象中的数据，直到读取完所有数据：
```python
while scan_edge_response_iterator.has_next():
    scan_edge_response = scan_edge_response_iterator.next()
    if scan_edge_response is None:
        print("Error occurs while scaning edge")
        break
    process_edge(space, scan_edge_response)
```
其中，process_edge 是自定义的一个处理读出来边数据的函数，该函数可以先使用 scan_edge_processor 对 scan_edge_response 中的数据进行解码，解码后的数据可以直接打印出来，也可以做一些简单处理，另作他用，比如：将这些数据读入计算框架 NetworkX 里。

5. 处理数据。在这里我们将读出来的所有边都添加到 NetworkX 中的图G 里：
```python
def process_edge(space, scan_edge_response):
    result = scan_edge_processor.process(space, scan_edge_response)
    # Get the corresponding rows by edge_name
    for edge_name, edge_rows in result.rows.items():
        for row in edge_rows:
            srcId = row.default_properties[0].get_value()
            dstId = row.default_properties[2].get_value()
            print('%d -> %d' % (srcId, dstId))
            props = {}
            for prop in row.properties:
                prop_name = prop.get_name()
                prop_value = prop.get_value()
                props[prop_name] = prop_value
            G.add_edges_from([(srcId, dstId, props)]) # 添加边到 NetworkX 中的图G
```

读取顶点数据的方法和上面的流程类似。

此外，对于分布式的一些图计算框架[4]来说，NebulaGraph 还提供了根据分片 (partition) 并发地批量读取存储的功能，这会在之后的文章中演示。

## 在 NetworkX 中进行图分析

当我们把所有点和边数据都按照上述流程读入 NetworkX 后，我们还可以做一些基本的图分析和图计算：

1. 绘制图：
```python
nx.draw(G, with_labels=True, font_weight='bold')
import matplotlib.pyplot as plt
plt.show()
plt.savefig('./test.png')
```

绘制出来的图：

![NetworkX 绘制的图](https://www-cdn.nebula-graph.com.cn/nebula-blog/game-of-thrones-networkx.png)

2. 打印出图中的所有点和边:
```python
print('nodes: ', list(G.nodes))
print('edges: ', list(G.edges))
```
    输出的结果：
```python
nodes:  [109, 119, 129, 139, 149, 209, 219, 229, 108, 118, 128, 138, 148, 208, 218, 228, 107, 117, 127, 137, 147, 207, 217, 227, 106, 116, 126, 136, 146, 206, 216, 226, 101, 111, 121, 131, 141, 201, 211, 221, 100, 110, 120, 130, 140, 150, 200, 210, 220, 102, 112, 122, 132, 142, 202, 212, 222, 103, 113, 123, 133, 143, 203, 213, 223, 104, 114, 124, 134, 144, 204, 214, 224, 105, 115, 125, 135, 145, 205, 215, 225]
edges:  [(109, 100), (109, 125), (109, 204), (109, 219), (109, 222), (119, 200), (119, 205), (119, 113), (129, 116), (129, 121), (129, 128), (129, 216), (129, 221), (129, 229), (129, 137), (139, 138), (139, 212), (139, 218), (149, 130), (149, 219), (209, 123), (219, 130), (219, 112), (219, 104), (229, 147), (229, 116), (229, 141), (229, 144), (108, 100), (108, 101), (108, 204), (108, 206), (108, 214), (108, 215), (108, 222), (118, 120), (118, 131), (118, 205), (118, 113), (128, 116), (128, 121), (128, 201), (128, 202), (128, 205), (128, 223), (138, 115), (138, 204), (138, 210), (138, 212), (138, 221), (138, 225), (148, 127), (148, 136), (148, 137), (148, 214), (148, 223), (148, 227), (148, 213), (208, 127), (208, 103), (208, 104), (208, 124), (218, 127), (218, 110), (218, 103), (218, 104), (218, 114), (218, 105), (228, 146), (228, 145), (107, 100), (107, 204), (107, 217), (107, 224), (117, 200), (117, 136), (117, 142), (127, 114), (127, 212), (127, 213), (127, 214), (127, 222), (127, 226), (127, 227), (137, 136), (137, 213), (137, 150), (147, 136), (147, 214), (147, 223), (207, 121), (207, 140), (207, 122), (207, 134), (217, 126), (217, 141), (217, 124), (217, 144), (106, 204), (106, 212), (106, 113), (116, 141), (116, 126), (116, 210), (116, 216), (116, 121), (116, 113), (116, 105), (126, 216), (136, 210), (136, 213), (136, 214), (146, 202), (146, 210), (146, 215), (146, 222), (146, 226), (206, 123), (216, 144), (216, 105), (226, 140), (226, 112), (226, 114), (226, 144), (101, 100), (101, 102), (101, 125), (101, 204), (101, 215), (101, 113), (101, 104), (111, 200), (111, 204), (111, 215), (111, 220), (121, 202), (121, 215), (121, 113), (121, 134), (131, 205), (131, 220), (141, 124), (141, 205), (141, 225), (201, 145), (211, 124), (221, 104), (221, 124), (100, 125), (100, 204), (100, 102), (100, 113), (100, 104), (100, 144), (100, 105), (110, 204), (110, 220), (120, 150), (120, 202), (120, 205), (120, 113), (140, 114), (140, 214), (140, 224), (150, 143), (150, 213), (200, 142), (200, 104), (200, 145), (210, 124), (210, 144), (210, 115), (210, 145), (102, 203), (102, 204), (102, 103), (102, 135), (112, 204), (122, 213), (122, 223), (132, 225), (202, 133), (202, 114), (212, 103), (222, 104), (103, 204), (103, 114), (113, 104), (113, 105), (113, 125), (113, 204), (133, 114), (133, 144), (143, 213), (143, 223), (203, 135), (213, 124), (213, 145), (104, 105), (104, 204), (104, 215), (114, 115), (114, 204), (134, 224), (144, 145), (144, 214), (204, 105), (204, 125)]
```

3. 常见的，可以计算两个点之间的最短路径:
```python
p1 = nx.shortest_path(G, source=114, target=211)
print('顶点 114 到顶点 211 的最短路径: ', p1)
```
    输出的结果：
```shell
顶点 114 到顶点 211 的最短路径:  [114, 127, 208, 124, 211]
```

4. 也计算图中每个点的 PageRank 值，来看各自的影响力：
```python
print(nx.pagerank(G))
```
    输出的结果：
```shell
{109: 0.011507076520104863, 119: 0.007835838669313514, 129: 0.015304593799331218, 139: 0.007772926737873626, 149: 0.0073896601012629825, 209: 0.0065558926178649985, 219: 0.014100908598251508, 229: 0.011454115940170253, 108: 0.01645334474680034, 118: 0.01010598371500564, 128: 0.01594717876199238, 138: 0.01671097227127263, 148: 0.015898676579503977, 208: 0.009437234075904938, 218: 0.0153795416919104, 228: 0.005900393773635255, 107: 0.009745182763645681, 117: 0.008716335675518244, 127: 0.021565565312365507, 137: 0.011642680498867146, 147: 0.009721031073465738, 207: 0.01040504770909835, 217: 0.012054472529765329, 227: 0.005615576255373405, 106: 0.007371191843767635, 116: 0.020955704443679106, 126: 0.007589432032220849, 136: 0.015987209357117116, 146: 0.013922108926721374, 206: 0.008554794629575304, 216: 0.011219193251536395, 226: 0.013613173390725904, 101: 0.016680863106330837, 111: 0.010121524312495604, 121: 0.017545503989576015, 131: 0.008531567756846938, 141: 0.014598319866130227, 201: 0.0058643663430632525, 211: 0.003936285336338021, 221: 0.009587911774927793, 100: 0.02243017302167168, 110: 0.007928429795381916, 120: 0.011875669801396205, 130: 0.0073896601012629825, 140: 0.01205992633948699, 150: 0.010045605782606326, 200: 0.015289870550944322, 210: 0.017716629501785937, 220: 0.008666577509181518, 102: 0.014865431161046641, 112: 0.007931095811770324, 122: 0.008087439927630492, 132: 0.004659566123187912, 142: 0.006487446038191551, 202: 0.013579313206377282, 212: 0.01190888044566142, 222: 0.011376739416933006, 103: 0.013438110749144392, 113: 0.02458154500563397, 123: 0.01104978432213578, 133: 0.00743370900670294, 143: 0.008011123394996112, 203: 0.006883198710237787, 213: 0.020392557117890422, 223: 0.012345866520333572, 104: 0.024902235588979776, 114: 0.019369722463816744, 124: 0.017165705442951484, 134: 0.008284361176173354, 144: 0.019363506469972095, 204: 0.03507634139024834, 214: 0.015500649025348538, 224: 0.008320315540621754, 105: 0.01439975542831122, 115: 0.007592722237637133, 125: 0.010808523955754608, 135: 0.006883198710237788, 145: 0.014654713389044883, 205: 0.014660118545887803, 215: 0.01337467974572934, 225: 0.009909720748343093}
```

此外，也可以和上一篇中一样，接入Gephi [5]来得到更好的图可视化效果。

本文的代码可以参见[6].

## Reference
[1] [https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/](https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/)

[2] [https://networkx.github.io/](https://networkx.github.io/)

[3] [https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)

[4] [https://spark.apache.org/graphx/](https://spark.apache.org/graphx/)

[5] [https://gephi.org/](https://gephi.org/)

[6] [https://github.com/vesoft-inc/nebula-python/pull/31](https://github.com/vesoft-inc/nebula-python/pull/31)


喜欢这篇文章？来来来，给我们的 [GitHub](https://github.com/vesoft-inc/nebula-graph) 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

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

> 作者有话说：Hi，我是王杰，是图数据 NebulaGraph 研发工程师，希望本次的经验分享能给大家带来帮助，如有不当之处也希望能帮忙纠正，谢谢~

# 推荐阅读

- [用图机器学习探索 A 股个股相关性变化](https://nebula-graph.com.cn/posts/stock-interrelation-analysis-jgrapht-nebula-graph/)
- [用 NetworkX + Gephi + NebulaGraph 分析<权力的游戏>人物关系（上篇）](https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/)


上篇介绍了如何借助可视化工具—— Gephi 来可视化分析《权力的游戏》中的复杂的人物图谱关系，本文侧重展示如何通过 NetworkX 访问图数据库 NebulaGraph。

用 NetworkX + Gephi + NebulaGraph 分析<权力的游戏>人物关系（下篇）

![权力的游戏](https://www-cdn.nebula-graph.com.cn/nebula-blog/game-of-thrones-01.png)

我们都知道《权利的游戏》在全世界都很多忠实的粉丝，除去你永远不知道剧情下一秒谁会挂这种意外“惊喜”，当中复杂交错的人物关系也是它火爆的原因之一，而本文介绍如何通过 [NetworkX](https://networkx.github.io/) 访问开源的分布式图数据库 [NebulaGraph](https://github.com/vesoft-inc/nebula)，并借助可视化工具—— [Gephi](https://gephi.org/) 来可视化分析《权力的游戏》中的复杂的人物图谱关系。

# 数据集

本文的数据集来源：冰与火之歌第一卷(至第五卷)[1]

- 人物集 (点集）：书中每个角色建模为一个点，点只有一个属性：姓名
- 关系集（边集）：如果两个角色在书中发生过直接或间接的交互，则有一条边；边只有一个属性：权重，权重的大小代表交互的强弱。

这样的点集和边集构成一个图网络，这个网络存储在图数据库 [NebulaGraph](https://github.com/vesoft-inc/nebula) [2]中。

# 社区划分——Girvan-Newman 算法

我们使用 NetworkX [3] 内置的社区发现算法 Girvan-Newman 来为我们的图网络划分社区。

以下为「社区发现算法 Girvan-Newman」解释：

> 网络图中，连接较为紧密的部分可以被看成一个社区。每个社区内部节点之间有较为紧密的连接，而在两个社区间连接则较为稀疏。社区发现就是找到给定网络图所包含的一个个社区的过程。
> 

> Girvan-Newman 算法即是一种基于[介数](https://zh.wikipedia.org/wiki/%E4%BB%8B%E6%95%B0%E4%B8%AD%E5%BF%83%E6%80%A7)的社区发现算法，其基本思想是根据边介数中心性（edge betweenness）从大到小的顺序不断地将边从网络中移除直到整个网络分解为各个社区。因此，Girvan-Newman 算法实际上是一种分裂方法。
> 

> Girvan-Newman 算法的基本流程如下：
> （1）计算网络中所有边的边介数；
> （2）找到边介数最高的边并将它从网络中移除；
> （3）重复步骤 2，直到每个节点成为一个独立的社区为止，即网络中没有边存在。

概念解释完毕，下面来实操下。

1. 使用 Girvan-Newman 算法划分社区。NetworkX 示例代码如下

```python
comp = networkx.algorithms.community.girvan_newman(G)
k = 7
limited = itertools.takewhile(lambda c: len(c) <= k, comp)
communities = list(limited)[-1]
```

2. 为图中每个点添加一个 community 属性，该属性值记录该点所在的社区编号

```python
community_dict = {}
community_num = 0
for community in communities:
    for character in community:
        community_dict[character] = community_num
        community_num += 1
        nx.set_node_attributes(G, community_dict, 'community')
```

# 节点样式——Betweenness Centrality 算法

下面我们来调整下节点大小及节点上标注的角色姓名大小，我们使用 NetworkX 的 Betweenness Centrality 算法来决定节点大小及节点上标注的角色姓名的大小。

> 图中各个节点的重要性可以通过节点的中心性（Centrality）来衡量。在不同的网络中往往采用了不同的中心性定义来描述网络中节点的重要性。Betweenness Centrality 根据有多少最短路径经过该节点，来判断一个节点的重要性。

1. 计算每个节点的介数中心性的值
```python
betweenness_dict = nx.betweenness_centrality(G) # Run betweenness centrality
```

2. 为图中每个点再添加一个 betweenness 属性

```python
nx.set_node_attributes(G, betweenness_dict, 'betweenness')
```

# 边的粗细

边的粗细直接由边的权重属性来决定。

通过上面的处理，现在，我们的节点拥有 name、community、betweenness 三个属性，边只有一个权重 weight 属性。

下面显示一下：

```python
import matplotlib.pyplot as plt
color = 0
color_map = ['red', 'blue', 'yellow', 'purple', 'black', 'green', 'pink']
for community in communities:
    nx.draw(G, pos = nx.spring_layout(G, iterations=200), nodelist = community, node_size = 100, node_color = color_map[color])
    color += 1
plt.savefig('./game.png')
```

emmm，有点丑…

![NetworkX 可视化](https://www-cdn.nebula-graph.com.cn/nebula-blog/networkx.png)

虽然 NetworkX 本身有不少可视化功能，但 Gephi [4] 的交互和可视化效果更好。

# 接入可视化工具 Gephi

现在将上面的 NetworkX 数据导出为 game.gephi 文件，并导入 Gephi。

```python
nx.write_gexf(G, 'game.gexf')
```

![Gephi 界面](https://www-cdn.nebula-graph.com.cn/nebula-blog/gephi-01.jpeg)

# Gephi 可视化效果展示

在 Gephi 中打开刚才导出的 `game.gephi` 文件，然后微调 Gephi 中的各项参数，就以得到一张满意的可视化：

1. 将布局设置为 Force Atlas, 斥力强度改为为 500.0， 勾选上 `由尺寸调整` 选项可以尽量避免节点重叠：

Force Atlas 为力引导布局，力引导布局方法能够产生相当优美的网络布局，并充分展现网络的整体结构及其自同构特征。力引导布局即模仿物理世界的引力和斥力，自动布局直到力平衡。

![Gephi 界面](https://www-cdn.nebula-graph.com.cn/nebula-blog/gephi-02.png)

2. 给划分好的各个社区网络画上不同的颜色：

在外观-节点-颜色-Partition 中选择 community（这里的 community 就是我们刚才为每个点添加的社区编号属性）

![Gephi 界面](https://www-cdn.nebula-graph.com.cn/nebula-blog/gephi-03.png)

3. 决定节点及节点上标注的角色姓名的大小：

在外观-节点-大小-Ranking 中选择 betweenness（这里的 betweenness 就是我们刚才为每个点添加的 betweenness 属性)

![Gephi 界面](https://www-cdn.nebula-graph.com.cn/nebula-blog/gephi-04.png)

4. 边的粗细由边的权重属性来决定：

在外观-边-大小-Ranking 中选择边的权重

![Gephi 界面](https://www-cdn.nebula-graph.com.cn/nebula-blog/gephi-05.png)

5. 导出图片再加个头像效果

![权力的游戏](https://www-cdn.nebula-graph.com.cn/nebula-blog/game-of-thrones-02.png)

![权力的游戏](https://www-cdn.nebula-graph.com.cn/nebula-blog/game-of-thrones-03.png)

大功告成，一张权力游戏的关系谱图上线 :) 每个节点可以看到对应的人物信息。

# 下一篇

本篇主要介绍如何使用 NetworkX，并通过 Gephi 做可视化展示。下一篇将介绍如何通过 NetworkX 访问图数据库 [NebulaGraph](https://github.com/vesoft-inc/nebula) 中的数据。

本文的代码可以访问[5]。

**致谢：本文受工作 [6] 的启发**

# Reference

[1] [https://www.kaggle.com/mmmarchetti/game-of-thrones-dataset](https://www.kaggle.com/mmmarchetti/game-of-thrones-dataset)

[2] [https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)

[3] [https://networkx.github.io/](https://networkx.github.io/)

[4] [https://gephi.org/](https://gephi.org/)

[5] [https://github.com/jievince/nx2gephi](https://github.com/jievince/nx2gephi)

[6] [https://www.lyonwj.com/2016/06/26/graph-of-thrones-neo4j-social-network-analysis/](https://www.lyonwj.com/2016/06/26/graph-of-thrones-neo4j-social-network-analysis/)

喜欢这篇文章？来来来，给我们的 [GitHub](https://github.com/vesoft-inc/nebula-graph) 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

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

> 作者有话说：Hi，我是王杰，是图数据 NebulaGraph 研发工程师，希望本次的经验分享能给大家带来帮助，如有不当之处也希望能帮忙纠正，谢谢~

# 推荐阅读

- [用图机器学习探索 A 股个股相关性变化](https://nebula-graph.com.cn/posts/stock-interrelation-analysis-jgrapht-nebula-graph/)
- [用 NetworkX + Gephi + NebulaGraph 分析<权力的游戏>人物关系（下篇）](https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph-part-two/)


本文介绍如何通过 NetworkX 访问开源的分布式图数据库 NebulaGraph，并借助可视化工具—— Gephi 来可视化分析《权力的游戏》中的复杂的人物图谱关系。

用 NetworkX + Gephi + NebulaGraph 分析 <权力的游戏>人物关系（上篇）

![jepsen](https://www-cdn.nebula-graph.com.cn/nebula-blog/detect01.png)

NebulaGraph 是一个高性能、高可用、强一致的分布式图数据库。由于 NebulaGraph 采用的是存储计算分离架构，在存储层实际只是暴露了简单的 kv 接口，采用 RocksDB 作为状态机，通过 Raft 一致性协议来保证多副本数据一致的问题。Raft 协议虽然比 Paxos 更加容易理解，但在工程实现上还是有很多需要注意和优化的地方。

另外，如何测试基于 Raft 的分布式系统也是困扰业界的问题，目前 Nebula 主要采用了 Jepsen 作为一致性验证工具。之前我的小伙伴已经在《[Jepsen 测试框架在图数据库 NebulaGraph 中的实践](https://nebula-graph.com.cn/posts/practice-jepsen-test-framework-in-nebula-graph/)》中做了详细的介绍，对 Jepsen 不太了解的同学可以先移步这篇文章。

在这篇文章中将着重介绍如何通过 Jepsen 来对 NebulaGraph 的分布式 kv 进行一致性验证。

# 强一致的定义

首先，我们需要什么了解叫强一致，它实际就是 Linearizability，也被称为线性一致性。引用《Designing Data-Intensive Applications》里一书里的定义：

> In a linearizable system, as soon as one client successfully completes a write, all clients reading from the database must be able to see the value just written.

也就是说，强一致的分布式系统虽然其内部可能有多个副本，但对外暴露的就好像只有一个副本一样，客户端的任何读请求获取到的都是最新写入的数据。

# Jepsen 如何检查系统是否满足强一致

以一个 Jepsen 测试的 timeline 为例，采用的模型为 **single-register**，也就是整个系统只有一个寄存器（初始值为空），客户端只能对该寄存器进行 read 或者 write 操作（所有操作均为满足原子性，不存在中间状态）。同时有 4 个客户端对这个系统发出请求，图中每一个方框的上沿和下沿代表发出请求的时间和收到响应的时间。

![jepsen-timeline](https://www-cdn.nebula-graph.com.cn/nebula-blog/detect02.png)

从客户端的角度来看，对于任何一次请求，服务端处理这个请求可能发生在从客户端发出请求到接收到对应的结果这段时间的任何一个时间点。可以看到在时间上，客户端 1/3/4 的三个操作 write 1/write 4/read 1 在时间上实际上是存在 overlap 的，但我们可以通过不同客户端所收到的响应，确定系统真正的状态。

由于初始值为空，客户端 4 的读请求却获取到了 1，说明客户端 4 的 read 操作一定在客户端 1 的 write 1 之后，且 write 4 发生在 write 1 之前（否则会读出 4），则可以确认三个操作实际发生的顺序为 write 4 -> write 1 -> read 1。尽管从全局角度看，read 1 的请求最先发出，但实际却是最后被处理的。后面的几个操作在时间上是不存在 overlap，是依次发生的，最终客户端 2 最后读到了最后一次写入的 4，整个过程中没有违反强一致的定义，验证通过。

如果客户端 3 的那次 read 获取到的值是 4，那么整个系统就不是强一致的了，因为根据之前的分析，最后一次成功写入的值为 1，而客户端 3 却读到了 4，是一个过期的值，也就违背了线性一致性。事实上，Jepsen 也是通过类似的算法来验证分布式系统是否满足强一致的。

# 通过 Jepsen 的一致性验证找到对应问题

我们先简单介绍一下 Nebula Raft 里面处理一个请求的流程（以三副本为例），以便更好地理解后面的问题。读请求相对简单，由于客户端只会将请求发送给 leader，leader 节点只需要在确保自己是 leader 的前提下，直接从状态机获取对应结果返回给客户端即可。

写请求的流程则复杂一些，如 Raft Group 图所示：
1. Leader（图中绿色圈） 收到 client 发送的 request，写入到自己的 wal（write ahead log）中。
1. Leader将 wal 中对应的 log entry 发送给 follower，并进入等待。
1. Follower 收到 log entry 后写入自己的 wal 中(不等待应用到状态机)，并返回成功。
1. Leader 接收到至少一个 follower 返回成功后，应用到状态机，向 client 发送 response。

![nebula-raft](https://www-cdn.nebula-graph.com.cn/nebula-blog/detect03.png)

下面我将用示例来说明通过 Jepsen 测试在之前的Raft实现中发现的一致性问题：

如上图所示，ABC 组成一个三副本 raft group，圆圈为状态机（为了简化，假设其为一个 single-register），方框中则是保存的相应 log entry。
- 在初始状态，三个副本中的状态机中都为 1，Leader 为 A，term为 1
- 客户端发送了 write 2 的请求，Leader 根据上面的流程进行处理，在向 client 告知写入成功后被 kill。（step 4 完成后）
- 此后 C 被选为 term 2 的 leader，但由于 C 此时有可能还没有将之前 write 2 的 log entry 应用到状态机（此时状态机中仍为1）。如果此时 C 接受到客户端的读请求，那么 C 会直接返回 1。这违背了强一致的定义，之前已经成功写入 2，却读到了过期的结果。

这个问题是出在 C 被选为 term 2 的 leader 后，需要发送心跳来保证之前 term 的 log entry 被大多数节点接受，在这个心跳成功之前是不能对外提供读（否则可能会读到过期数据）。有兴趣的同学可以参考 raft parer 中的 Figure 8 以及 5.4.2 小节。

从上一个问题出发，通过 Jepsen 我们又发现了一个相关的问题：leader 如何确保自己还是 leader？这个问题经常出现在网络分区的时候，当 leader 因为网络问题无法和其他节点通信从而被隔离后，此时如果仍然允许处理读请求，有可能读到的就是过期的值。为此我们引入了 leader lease 的概念。

当某个节点被选为 leader 之后，该节点需要定期向其他节点发送心跳，如果心跳确认大多数节点已经收到，则获取一段时间的租约，并确保在这段时间内不会出现新的 leader，也就保证该节点的数据一定是最新的，从而在这段时间内可以正常处理读请求。

![raft-heartbeat](https://www-cdn.nebula-graph.com.cn/nebula-blog/detect04.png)

和 TiKV 的处理方法不同的是，我们没有采取心跳间隔乘以系数作为租约时间，主要是考虑到不同机器的时钟漂移不同的问题。而是保存了上一次成功的 heartbeat 或者 appendLog 所消耗的时间 cost，用心跳间隔减去 cost 即为租约时间长度。

当发生网络分区时， leader 尽管被隔离，但是在这个租约时间仍然可以处理读请求（对于写请求，由于被隔离，都会告知客户端写入失败）， 超出租约时间后则会返回失败。当 follower 在至少一个心跳间隔时间以上没有收到 leader 的消息，会发起选举，选出新 leader 处理后续的客户端请求。

# 结语

对于一个分布式系统，很多问题需要长时间的压力测试和故障模拟才能发现，通过 Jepsen 能够在不同注入故障的情况下验证分布式系统。之后我们也会考虑采用其他混沌工程工具来验证 NebulaGraph，在保证数据高可靠的前提下不断提高性能。

本文中如有错误或疏漏欢迎去 GitHub：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) issue 区向我们提 issue 或者前往官方论坛：https://discuss.nebula-graph.com.cn/ 的 `建议反馈` 分类下提建议 👏；交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

# 推荐阅读

- [Jepsen 测试框架在图数据库 NebulaGraph 中的实践](https://nebula-graph.com.cn/posts/practice-jepsen-test-framework-in-nebula-graph/)
- [Nebula 架构剖析系列（一）图数据库的存储设计](https://nebula-graph.com.cn/posts/nebula-graph-storage-engine-overview/)

> 作者有话说：Hi，我是 critical27，是 NebulaGraph 的研发工程师，目前主要从事存储相关的工作，希望能为图数据库领域带来一些自己的贡献。希望本文对你有所帮助，如果有错误或不足也请与我交流，不甚感激。


在这篇文章中将着重介绍如何通过 Jepsen 来对 NebulaGraph 的分布式 kv 进行一致性验证。

基于 Jepsen 来发现几个 Raft 实现中的一致性问题

在用户使用 NebulaGraph 的过程中，经常会遇到各种问题，通常我们都会建议先通过 `show hosts` 查看集群状态。可以说，整个 NebulaGraph 的集群状态都是靠心跳机制来构建的。本文将从心跳说起，帮助你了解 NebulaGraph 集群各个节点之间通信的机制。

# 什么是心跳？有什么作用？

![metad storaged graphd 通信](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-metad-storaged-graphd-v-r-family.png)

NebulaGraph 集群一般包含三种节点，graphd 作为查询节点，storaged 作为存储节点，metad 作为元信息节点。本文说的心跳，主要是指 graphd 和 storaged 定期向 metad 上报信息的这个心跳，借助心跳，整个集群完成了以下功能。（相关参数是 `heartbeat_interval_secs`）

> 在 NebulaGraph 中经常提及的 raft 心跳则是用于拥有同一个 partition 的多个 storaged 之间的心跳，和本文提的心跳并不相同。

## 1. 服务发现

当我们启动一个 NebulaGraph 集群时，需要在对应的配置文件中填写 `meta_server_addrs`。graphd 和 storaged 在启动之后，就会通过这个 `meta_server_addrs` 地址，向对应的 metad 发送心跳。通常来说，graphd 和 storaged 在连接上 metad 前是无法对外进行服务的。当 metad 收到心跳后，会保存相关信息（见下文第 2 点），此时就能够通过 show hosts 看到对应的 storaged 节点，在 2.x 版本中，也能够通过 `show hosts graph` 看到 graphd 节点。

## 2. 上报节点信息

在 metad 收到心跳时，会将心跳中的 ip、port、节点类型、心跳时间等等信息保存，以供后续使用（见下文）。

除此以外 storaged 在自身 leader 数量变化的时候也会上报 leader 信息，在 `show hosts` 中看到的 Leader count 和 Leader distribution 就是通过心跳汇报的。

## 3. 更新元信息

当客户通过 console 或者各种客户端，对集群的元信息进行更改之后（例如 `create/drop space`、`create/alter/drop tag/edge`、`update configs` 等等），通常在几秒之内，整个集群就都会更新元数据。

每次 graphd 和 storaged 在心跳的响应中会包含一个 `last_update_time`，这个时间是由 metad 返回给各个节点的，用于告知 metad 自身最后一次更新元信息的时间。当 graphd 或者 storaged 发现 metad 的元信息有更新，就会向 metad 获取相应信息（例如 space 信息、schema 信息、配置更改等等）。

> 我们以创建一个 tag 为例，如果在 graphd/storaged 获取到新创建的这个 tag 信息之前，我们无法插入这个 tag 数据（会报类似 **No schema found** 这样的错误）。而当通过心跳获取到对应信息并保存至本地缓存后，就能够正常写入数据了。

# 心跳上报的信息有什么用？

- `show hosts`、`show parts` 这类命令都是通过 metad 中保存的各个节点心跳信息，组合显示出来的。
- `balance data`、`balance leader` 等运维命令，需要通过获取当前集群内哪些 storaged 节点是在线状态，实际也是通过 metad 判断最近一次心跳时间是否在阈值之内。
- `create space`，当用户创建一个 space 时，metad 也需要获取 storaged 的状态，将这个 space 的各个 partition 分配到在线的 storaged 中。

> 以用户容易遇到的问题为例：假如我们启动一个 storaged 后，关掉并修改端口号，然后再启动 storaged。如果这个过程足够快，那么通过 `show hosts` 能看到两个在线的 storaged。此时，如果新建一个 space，例如 `CREATE space test(partition_num=10, replica_factor=1)`，这个 test space 就会分布在前后启动的两个 storage 上。但如果等到在 show hosts 中看到其中一个离线后，再执行 `CREATE space test(partition_num=10, replica_factor=1)`，即便离线的 storaged 再启动，也只有一个 storaged 拥有这个 space（创建 test space 时 online 的那个 storaged）。

![上线](https://www-cdn.nebula-graph.com.cn/nebula-blog/heart-beat-online.png)

![掉线](https://www-cdn.nebula-graph.com.cn/nebula-blog/heart-beat-offline.png)

# 心跳的演变历史

在 18-19 年的时候，当时的心跳机制没有这么完善。一方面，无论元信息是否更改，都会从 metad 获取最新的元信息。而通常来说，元信息改动不会很频繁，定期获取元信息有一定的资源浪费。另一方面，想要将一个 storaged 节点加入和移除都是通过类似 `add/delete hosts` 这样的命令，采取的是类似白名单的机制。对于其他没有认证过的节点，都无法对外服务，这样做固然也有一些优势，带来的最大问题就是不够友好。

因此，在 19 年底开始，我们对心跳做了一系列的改动，特别鸣谢社区用户 @zhanggguoqing。经过一段时间的验证踩坑后，基本就形成了现在的形式。

# 额外的补充

有关心跳还有一个涉及到的问题就是 _cluster.id_ 这个文件。它实际是为了防止 storaged 与错误的 metad 通信，大致原理如下：

- 首先，metad 在启动的时候会根据 `meta_server_addrs` 这个参数，生成一个 hash 值并保存在本地 kv 中。
- storaged 在启动的时候会尝试从 _cluster.id_ 这个文件中获取对应 metad 的 hash 值，并附送在心跳中发送（如果文件不存在，则第一次使用 0 代替。收到心跳响应时，将 metad 的 hash 值保存在 _cluster.id_ 这个文件中，后续一直使用该值）。
- 在心跳处理中，metad 会比较本地 hash 值和来自 storaged 心跳请求中的 hash 值，如果不匹配则拒绝。此时，storaged 是无法对外服务的，也就是 _Reject wrong cluster host_ 这个日志的由来。

以上就是心跳机制大致的介绍，感兴趣的你可以参考下源码实现，GitHub 传送门：[https://github.com/vesoft-inc/nebula-graph](https://github.com/vesoft-inc/nebula-graph)。

# 推荐阅读

- [分布式图数据库 NebulaGraph 的 Index 实践](https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/)
- [分布式图数据库 NebulaGraph 中的集群快照实践](https://nebula-graph.com.cn/posts/introduction-to-snapshot-in-nebula-graph/)


本文将从心跳说起，帮助你了解 NebulaGraph 集群各个节点之间通信的机制。

一文带你了解图数据库 NebulaGraph 集群通信机制

在海量数据、企业云、混合云的复杂基础设施运维场景下，利用图数据库图算法的能力做高效的辅助运维工作是一个十分值得的尝试与技术投资。NebulaGraph 作为高性能、开源、分布式的新一代云原生图数据库，是一个很值得考虑的图基础设施选型目标。

运维如何提效？手把手教你用 NebulaGraph 图技术搞定复杂运维系统

作为时下热门的数据库产品，图数据库（GraphDatabase）已经连续几年在 DB-Engines 榜单上蝉联增长最快的数据库类型，并在欺诈检测、社交网络、实时推荐、知识图谱、数据治理等多个领域都有丰富的落地。

那么，图数据库跟大众最熟知的 MySQL 关系型数据库相比有哪些区别？又在哪些场景中更具有优势呢？下面我们一起来探讨一下吧。

# 什么是图数据库

为了方便大家理解，先介绍下图数据库的基本概念。

图数据库是一种将关联数据的实体作为顶点，关系作为边来存储的特殊类型数据库，能够高效地对这些点边结构进行存储、检索和查询。

> 比如，当前为大家所熟知的企业知识图谱采用的就是这种点边类型的数据存储结构，类似于天眼查、[企查查](https://www.nebula-graph.com.cn/posts/qi-cha-cha-knowledge-graph-practice)——

![企业知识图谱](https://docs-cdn.nebula-graph.com.cn/books/images/enterprise-relations.png)

与传统的关系数据库相比，图数据库把数据间的关联关系也作为数据的一部分进行存储，关联上还可以添加标签、方向以及属性，因此可以帮助我们更好地理解和利用复杂的数据关系。

# 图数据库和关系数据库的主要区别

尽管图数据和关系模型都可以存储数据关系，但它们的做法并不相同，以下是详细的区别：

- **数据模型**：关系型数据库使用表格来组织和存储数据，其中每个表格有一定数量的列和行，每行代表一个记录。而图数据库使用点边结构来存储数据，其中节点代表实体，边代表实体之间的关系。

- **存储格式**：图数据库将实体存储为节点，将关系存储为边。关系数据库将数据存储在具有行和列的表中，通过 JOIN 操作进行查询。

- **查询语言**：关系型数据库通常使用 SQL（结构化查询语言）来查询数据。而图数据库使用类似于 Cypher、Gremlin 等查询语言，能更高效地支持复杂的图形遍历和查询。

- **索引**：图数据库通常使用无索引联结，这意味着每个节点都连接到数据库中的每个其他节点，而关系数据库则使用索引指针连接相关数据。

# 图数据库相较于关系数据库的优势

**1. 图数据库更擅长处理复杂的关系数据**

在许多应用场景中，数据往往是具有复杂的关联关系。例如社交网络中的人与人之间的关系、电商平台中商品与用户之间的关系等等，这些数据之间的关系非常复杂，传统的关系型数据库无法很好地处理和展示这些数据。

图数据库正是为了解决这类复杂的数据结构而设计的。图数据库将数据看做一个由节点和边构成的图形结构，这使得查找和理解数据变得更加容易，而毫秒级的查询速度也能在帮助企业快速作出决策、规避潜在风险时至关重要。

**2.图数据库的数据结构更灵活**

由于图数据库采用的是节点和边的数据结构，可以根据业务需求灵活地扩展节点和边的属性。这意味着数据不需要事先定义好结构，可以随时根据需要进行修改和扩展，这种灵活性使得图数据库更加适合处理需要频繁变更的夜晚数据。

**3.图数据库具有更高的查询效率**

传统的关系型数据库在处理复杂数据的时候，需要进行多次关联查询，这会导致查询效率的下降。而图数据库则采用基于图的查询方式，通过遍历节点和边来查找数据，可以大大减少查询的次数，从而提高查询的效率。

**4. 图数据库更具有灵活性**

相对于关系型数据库，图数据库的数据模型更加灵活。图数据库的数据模型不仅可以表示实体之间的简单关系，还可以表示更复杂的关系，如层次结构、网络和多对多关系等。这使得图数据库更适合处理非结构化和复杂数据。

**5.图数据库可以更好地支持非结构化数据**

在实际的应用场景中，很多数据并不是严格的结构化数据，而是半结构化数据和非结构化数据。例如，文本数据、图像数据、视频数据等等。传统的关系型数据库并不擅长处理这些半结构化数据和非结构化数据。而图数据库可以通过图模型来存储这些半结构化数据和非结构化数据，实现更加灵活和高效的数据管理和查询。

**5.图数据库更容易理解**

图数据库非常适合进行可视化展示，因为它是由节点和边构成的图形结构，每个节点和边都有自己的属性和关系。因此，可以使用各种可视化工具来展示和分析数据。

> 例如，我们可以使用图形界面展示社交网络中人与人之间的关系，也可以使用 3D 图形展示城市之间的交通网络，用地图展示物流网络中货物的运输路径等等。

这种可视化效果不仅能够让业务人员更加直观地理解数据，同时也可以帮助他们更好地进行数据分析和决策。

**6. 图数据库可以更好地支持知识图谱和人工智能应用**

由于图数据库的图模型可以很好地表示实体之间的关系，因此图数据库可以很好地支持知识图谱的构建和查询。

知识图谱是一种用于表示和存储知识的图形数据库，它可以用来支持各种人工智能应用，如智能搜索、智能推荐、智能问答等。此外，图数据库还可以与 AI 人工智能算法相结合，从而实现更加智能化的数据分析和挖掘。

# 总结：关系型数据库 vs 图数据库 应该如何选择？

图数据库和关系数据库之间的根本区别在于如何存储和处理关系。关系型数据库采用「行列」表格的形式存储数据，在各领域都有广泛应用，但遇到庞大、复杂、动态的数据场景时非常容易遇到性能瓶颈。而图数据库特殊的点边结构存储数据，在处理海量关联数据时有相当突出的性能优势——**以擅长超大规模数据集的 NebulaGraph 为例，即使处理亿万级别数据也只有毫秒级的查询时延，目前已被包括腾讯、美团、微众银行、小红书、快手等1000+ 知名企业应用于金融风控、实时推荐、知识图谱等业务场景**。

同样需要注意的是，图数据库与关系数据库并不是替代品，而是各自服务于不同的目的，选择合适的数据存储及展示方式将为更好地挖掘数据价值提供更好的帮助。

# 常见问题解答

## 图数据库与关系数据库有何不同？

图数据库使用图结构进行语义查询，并使用节点、边和属性来表示和存储数据。另一方面，关系数据库使用表和它们之间的关系来存储数据。图数据库用于查询复杂的关系，而关系数据库用于更简单的关系结构。此外，图形数据库通常比关系数据库需要更少的连接。因此，图数据库在处理复杂数据时可以更快、更高效。

## 图数据库比关系数据库好吗？

在很大程度上是的。图数据库优于关系数据库，因为它们更灵活，可以处理更复杂的数据关系。关系数据库是基于数据的表结构，数据一旦入库就很难改变。另一方面，图形数据库基于数据的图形结构，易于更改。考虑到数据变得越来越复杂，对于大多数优先考虑复杂数据操作的用例，图数据库要好得多。

## 什么时候可以考虑使用图数据库？

一般来说，**任何能够将数据表示为相互连接的节点网络的应用场景都可以考虑使用图数据库**，例如，在社交网络中，用户的朋友彼此也是朋友。图数据库可以快速找到用户好友的所有好友。相反，关系数据库需要执行多个连接才能找到相同的信息。通过对关系进行优先排序，图数据库可以提供对数据的更深入洞察。

## 图数据库不适合做什么？

图数据库非常适合存储具有复杂关系的数据，例如社交网络或财务数据。但是，图数据库不太适合存储可以轻松以表格格式表示的数据，例如产品目录或客户订单。

---
相关推荐：

[《越来越火的图数据库，到底是什么？｜NebulaGraph 星球说》](https://www.nebula-graph.com.cn/posts/what-is-graph-database)







图数据库相较于关系型数据库有什么区别？图数据库的优势是什么？一起跟随 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-zhangjianfeng-wukuang.mp4" type="video/mp4">
</video>


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

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

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

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

![五矿期货简介](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/4.jpeg)

下面介绍下五矿期货的一些情况。 五矿期货是中国五矿集团旗下的金融企业，**五矿集团是 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 图数据库在金融期货行业的应用与实践探索

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/aliyun/%E5%85%AC%E4%BC%97%E5%8F%B7.jpg)

大数据时代，数据价值水涨船高，却很少有人提及，对于企业来说，从如山一般增长的数据中挖掘价值，到底意味着什么。

这是各行各业都存在的需求痛点。传统的关系型数据库并不擅长进行关联查询，无论是从效率还是运算速度上考虑，表连接的查询成本都是巨大的，且具有结构性的安全隐患。

“所有技术的发展，都离不开业务的需求。”

国内图数据库头部服务商「NebulaGraph」CEO叶小萌告诉36氪，图数据库等NoSQL数据库的诞生，本身就是为了解决关系型数据库在业务表达中的原生缺陷。图数据库以点代表实体，边代表实体之间的关系，能够更直观、更高效地存储和处理海量关联数据，在金融风控、欺诈检测、社交推荐、知识图谱等场景中都有广泛应用。

「NebulaGraph」母公司「悦数科技」成立于2018年，是一家专注于分布式图数据库，并在移动大数据、数据存储管理等领域拥有丰富研发和项目管理经验的技术型企业。并推出了云上超大规模图数据库「NebulaGraph Cloud」，实现了产品的云化。

# 分布式图数据库：结构灵活，弹性极致

早在2011年，Neo Technology的开源数据库Neo4j就获得了1060万美元融资，宣告了图数据库的巨大价值潜力。而如今，使用图结构进行语义查询，已经被实践在更多的行业应用中。除了大众最为熟知的知识图谱和社交网络之外，个性化推荐、风险分析、身份验证、行业研究、AI、NLP（自然语言处理）等在大多数产业数字化过程中都至关重要的技术领域，也在见证图数据库的异军突起。

除了天然的多层关联关系分析能力之外，因为基于图模型，图数据库也具有天然的可解释性和更好的可视化能力。另一方面，由于点边分离，图数据库比关系型数据库更接近于人类直观的认知逻辑，并能够把这种关系思维更清晰地呈现出来。

技术迭代，一直都是一种朝着人性化迈进的主动选择。

从底层逻辑来分析数据库的核心原理，不难发现，数据库作为一种结构化的解决方案，其应用目的大多都是基于对现实世界中非结构化关系的高效表达。因此，在技术语言的简化、人性化趋势下，越能直接、自然地贴近现实场景下的节点关系网络，在插入更大数据量级的同时削弱计算本身的抽象化特性，也就越有机会迭代掉传统的主流框架，成为时下最流行的商业数据库。

不过，图数据库也存在一些痛点。比如，图查询语言的标准化（ISO-GQL）工作还在进行中。此外，尤其在国内市场，图数据库厂商多为初创型企业，在可规模化和多渠道打通能力上略显不足。在商业化阶段，「NebulaGraph」需要考虑的事情更多，包括更快速的部署实践用户体验和更高的安全标准。

为此，「NebulaGraph Cloud」似乎正在向我们印证，向云服务做集成，也许会是图数据库下一个发展阶段的答案。

作为国内分布式图数据库的标杆产品，「NebulaGraph」自身的一大优势来自于：采用了存储与计算分离的架构，支持终端用户计算层和存储层可以根据各自的情况弹性扩容。这使图数据库具有了云原生的特征，云端部署则能够有效地屏蔽了数据库部署、性能调优、运维等繁杂过程，同时带来“近乎无限”的极致弹性。

# 商业化阶段：开放与“云集成”

早在2005年左右，NebulaGraph 的核心研发团队就开始在国内外多个知名企业参与图数据库相关工作。2015 年，叶小萌正式加入蚂蚁金服，开始主导研发高性能分布式图数据库GeaBase。

彼时，一个令人兴奋的数据库世界开始生成。从Neo4j的成熟，到云数据仓库Snowflake的出现，尽管距离全球知名咨询机构Gartner宣布“图数据库已经成为当下数据分析的基础”还有六年左右的时间，但图数据库的市场早就已经准备好了随时爆发。

2019年，采用原生分布式架构的高性能图数据库「NebulaGraph」正式发布，继续在中国乃至全世界范围内推广图计算技术。根据中国信通院的预测，2025年，图分析在数据和分析创新中的占比将提升至80%。

在2013年开始成为数据库增速最快的子领域之前，图数据库已经经历了漫长的技术拓荒时期，而其真正的商业化历程也不过几年时间，还需要大量的时间和人为努力去给予想象力。

成立三年后，「NebulaGraph」开始做商业化，而在「NebulaGraph Cloud」上线阿里云计算巢后的短短几个月里，「NebulaGraph」已经增加了数十家试用用户，其中有相当一部分客户已经完成签约。

在国产图数据库等ToB软件走向商业化的过程中，前沿技术正在和云服务体验产生1+1>2的效果。无论是「NebulaGraph」所代表的新兴技术厂商，还是已经与各行各业的企服服务商展开了长期合作的阿里云计算巢，积极拥抱生态的开放性，既是顺应技术的结构性趋势，也是解决国内企服领域“圈地”现象的有效途径。

事实上，数据库本身就是一个开放程度很高的领域。随着技术应用的复杂化和行业人才流动加大，技术从业者对于框架的取舍直接决定着企业客户对于商业化解决方案的选择。叶小萌介绍道，「NebulaGraph」很多商业化的线索和实例都来自于社区。

开源降低了技术人员的体验成本，而对于更复杂、更大范围内的企业客户来说，最大的商业化成本在于初创厂商需要在长期的沟通和教育中，反复证明软件的安全性和可用性。同时，也能帮助有图数据库需求的企业实现应用人才的积累。从这一角度来说，阿里云作为国内最大的云服务平台，能够帮助「NebulaGraph」的目标客户通过自助服务的方式，来缩短从试用到购买的决策流程。

基于二者技术特点与服务特性的有机结合，「NebulaGraph Cloud」作为一款云原生图数据库产品可以为对于终端用户提供以下几个优势：

第一，自动化部署，大幅提升部署效率。阿里云提供了统一的基础设施，企业无需自行采购硬件，可以根据业务的灵活度和资源需求弹性调配云资源，实现快速上线。基于阿里云计算巢提供的ROS（资源编排），NebulaGraph实现了云上自动化部署，几分钟内即可交付一个图数据库集群，相比传统以天、甚至以周为单位的交付周期，有极大的提升。

第二，在计算巢平台上的高度集成，可以为最终用户提供更具性价比的方案。在用户私有部署的情况下，需要把数据库部署在一个具有强存储计算能力、价格昂贵的服务器上。但通过云的技术能力，利用阿里云提供的实例、对象存储等高性价比的云服务，能为最终客户提供一套极具性价比的解决方案。例如，基于全新的第四代AMD EPYC处理器打造的阿里云g8a实例，可以为终端客户提供强劲算力，帮助客户加速业务创新、降本增效，持续为客户创造价值。

另一方面，通过云的弹性能力和「NebulaGraph」分布式特性的有机结合，用户在数据量增长过程中对集群规模进行扩容，也能够得到高性价比和稳定的服务。

第三，为用户提供更短的软件试用和决策路径。计算巢的软件免费试用中心，可以很好解决传统软件试用流程冗长、高试错成本的痛点，提供快速、开箱即用的云上应用新体验。在计算巢软件免费试用中心，用户可以直接试用NebulaGraph产品，节省了数周的审批和对接时间，为用户带来了更方便、快捷的一体化试用和决策流程，试用体验大大提升。

第四，更强的可用性和安全性。传统模式下，企业采购硬件资源，数据库部署在自建IDC并由企业监管和运维。接入业务后，企业IT人员需要时刻关注数据库集群状态来保障可用性，而云计算作为技术载体，天然具备跨越时空的优势。「NebulaGraph Cloud」内置了多种角色，用户可以为指定图空间增加不同角色权限的数据库用户，保证业务数据安全。

# 数据价值挖掘：生于云，长于云

“云计算的本质是技术和开放。对于企业服务领域,云需要更加开放,通过技术手段成为伙伴发展的效率倍增器。”阿里云弹性计算产品线总经理张献涛表示，阿里云计算巢的愿景，是构建一个开放的企业服务应用生态，助力中国软件企业生于云、长于云，拥有持续的生命力。

这一生态性的目标，也与「NebulaGraph」的产品理念不谋而合。

“只有当软件分工越来越细化、标准化的时候，才能够更容易彼此集成在一起。”

同样地，在叶小萌看来，国内企服市场标准化、集成化的趋势必将来临。一致的前进方向成为了合作的驱动力，对软件应用生态的坚持也是「NebulaGraph」能够成为阿里云计算巢上第一家图数据库合作伙伴的重要原因。

如今，云计算正在从单一的计算能力发展为体系化的创新。对于企业来说，“上云”既是一个技术选择，也可以成为企业数字化的起点。

作为面向ISV（独立软件服务商）的云集成PaaS平台，阿里云计算巢致力于帮助技术厂商将产品和服务与云原生的能力相结合，从而提升软件服务在交付、部署、管理等环节的效率和用户体验。

Gartner研究显示，目前云服务的增速和渗透率十分可观，大量的商业软件正在从完全私有本地化服务逐步转向基于云服务的商业模式。对此，艾瑞数据亦有所证明：2021年，中国整体云服务市场规模达到了3280.2亿元 ，增速为45.4%。云服务目前在供给端已经形成较为稳固的市场格局，上云、用云也成为了需求侧的广泛共识。

在可以预见的未来，云原生图数据库能够从知识图谱、机器学习及模型优化、数据特征提取分析等多维的角度来与人工智能相结合，释放更大的数据力量，也是图数据库成为SaaS/DaaS产品的关键步骤。

“超出我们预期的是，对于「NebulaGraph Cloud」的用户，我们几乎没有像其他用户一样去深度参与他们的决策过程。”叶小萌着重强调了阿里云计算巢的高效试用及部署流程。在企业上云和企服软件云化的过程中，试用体验是最重要的指标之一。计算巢提供的POC免费试用中心，相比用户需要“手动提交申请、手动创建资源”的传统试用流程，更好地解决了试用流程冗长、高试错成本的痛点，真正做到了自动化部署下的开箱即用。 「NebulaGraph」作为计算巢上首批开通免费试用的服务商之一，也已经充分感受到了其作为企业云化“切入口”的效率与体验价值。

数据关联和价值挖掘的挑战，属于每一家企业。而「NebulaGraph Cloud」也将借助阿里云计算巢，一起帮助企业基于云构建新的数据价值机会，让数据更好地生于云，长于云。


---
本文转载自 36Kr ，原文参见：[《NebulaGraph：打造灵活弹性的云原生图数据库，与阿里云计算巢共同拥抱开放生态》](https://36kr.com/p/2159756734914567)

“超出我们预期的是，对于「NebulaGraph Cloud」的用户，我们几乎没有像其他用户一样去深度参与他们的决策过程。”

NebulaGraph x 36Kr 专访：如何打造灵活弹性的云原生图数据库

> 本文整理自 中国移动算法工程师 汪海涛 在 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上的精彩分享。