![权力的游戏](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 分析 <权力的游戏>人物关系（上篇）

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

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

一文带你了解 NebulaGraph 的图技术是怎样应用在附近好友、时空交集等常见社交网络场景中的。

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

NebulaGraph BR 开源已经有一段时间了，为了给社区用户提供一个更稳、更快、更易用的备份恢复工具，去年对其进行了比较大的重构。NebulaGraph BR（以下简称 BR）分为社区版和企业版两个版本，企业版在社区版功能的基础上，**额外提供了增量备份的能力**。而本文将以 BR 社区版为例，简单介绍 BR 的一些实现细节并通过上手练习来讲述如何使用 BR 进行 NebulaGraph 数据的备份恢复。

## 什么是 BR

BR 即 Backup & Restore 的简称，是一款对 NebulaGraph 集群数据（包括元信息和数据信息）备份到远端，并利用备份数据对集群进行恢复的工具。仓库地址在此：[https://github.com/vesoft-inc/nebula-br](https://github.com/vesoft-inc/nebula-br)。

## 什么是 NebulaGraph Agent

NebulaGraph Agent 是一个只关心本机的无状态的 RPC 服务，与 metad 通信，提供备份文件上传和下载、服务起停等接口供 BR 调用。在开始备份恢复前，需要确保集群的每个节点上部署了一个 agent，可以通过 `SHOW HOSTS AGENT` 查看 agent 的状态。仓库地址在此：[https://github.com/vesoft-inc/nebula-agent](https://github.com/vesoft-inc/nebula-agent)。

整体架构如下图所示：

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/nebula-br/nebula-agent-architecture.png)

由于 NebulaGraph Agent 分布在集群的各个节点上，**在备份恢复时，BR 带来的 CPU 和网络 IO 开销会分散到各台机器上**，使其可以轻松应对大规模集群的备份恢复场景。

## 上手 BR

为了能让大家更快的熟悉 BR 工具，让我们从零开始，做一个简单的实操练习，来体验目前 [nebula-br](https://github.com/vesoft-inc/nebula-br) 支持的所有功能。

### 环境准备

首先，我们需要创建一个 NebulaGraph 集群，**目前 BR 工具不支持在容器场景执行备份恢复**，可以通过下载安装包的方式在虚拟机上安装，参考文档：[https://docs.nebula-graph.com.cn/3.3.0/2.quick-start/3.quick-start-on-premise/2.install-nebula-graph/](https://docs.nebula-graph.com.cn/3.3.0/2.quick-start/3.quick-start-on-premise/2.install-nebula-graph/)。

在集群创建完成后，可以通过 [nebula-console](https://docs.nebula-graph.com.cn/3.3.0/nebula-console/)（NebulaGraph 的命令行工具）来连接它。

执行下面的命令，为集群导入一个 [basketballplayer](https://docs-cdn.nebula-graph.com.cn/dataset/dataset.zip) 的数据集：

```shell
(root@nebula) [(none)]> :play basketballplayer
Start loading dataset basketballplayer...
 
Load dataset succeeded!
```

在成功导入数据后，执行下面的命令来查看 basketballplayer 的点边统计

```shell
(root@nebula) [basketballplayer]> submit job stats
+------------+
| New Job Id |
+------------+
| 2          |
+------------+
...
 
(root@nebula) [basketballplayer]> show stats
+---------+------------+-------+
| Type    | Name       | Count |
+---------+------------+-------+
| "Tag"   | "player"   | 51    |
| "Tag"   | "team"     | 30    |
| "Edge"  | "follow"   | 81    |
| "Edge"  | "serve"    | 152   |
| "Space" | "vertices" | 81    |
| "Space" | "edges"    | 233   |
+---------+------------+-------+ 
...
```

接着，我们下载 BR 工具的二进制文件：

```shell
wget https://github.com/vesoft-inc/nebula-br/releases/download/v3.3.0/br-3.3.0-linux-amd64
```

### 部署 NebulaGraph Agent 服务

在准备好集群环境后，需要在每台机器上安装并启动 NebulaGraph Agent服务

#### 1. 下载 NebulaGrpah Agent 二进制文件

```
wget https://github.com/vesoft-inc/nebula-agent/releases/download/v0.2.0/agent-0.2.0-linux-amd64
```

#### 2. 启动 nebula-agent

```
nohup ./agent-0.2.0-linux-amd64 --agent="<agent_node_ip>:8888" --meta="<metad_node_ip>:9559" > nebula_agent.log 2>&1 &
```

该命令会启动一个监听 8888 端口的 nebula-agent 服务。`--agent` 的 port 可以自定义，`--meta` 的 ip、port 需要与集群 meta 保持一致。

可以在 nebula-console 中执行下面的命令查看 agent 的状态：

```
(root@nebula) [basketballplayer]> SHOW HOSTS AGENT
+-----------------+------+----------+---------+--------------+---------+
| Host            | Port | Status   | Role    | Git Info Sha | Version |
+-----------------+------+----------+---------+--------------+---------+
| "192.168.8.144" | 8888 | "ONLINE" | "AGENT" | "96646b8"    |         |
+-----------------+------+----------+---------+--------------+---------+
...
```

当集群中所有 agent 都 online 后，我们可以执行备份恢复命令：

### 使用 BR 备份数据

BR 目前支持备份 NebulaGraph 集群的数据到本地或者 S3 上。为了方便练习，我们采用本地备份的方式，在生产环境，我们推荐用户将数据备份到 S3 上。备份命令如下：

```
./br-3.3.0-linux-amd64 backup full --meta "192.168.8.144:9559" --storage "local:///home/nebula/backup"
```

该命令会对 Meta 服务的地址为 `192.168.8.144:9559` 的 NebulaGraph 集群进行全量备份，并将备份文件保存到本地的 `/home/nebula/backup` 目录下。

### 查看备份信息

备份完成后，我们可以通过下面的命令来查看备份信息：

```
./br-3.3.0-linux-amd64 show  --storage "local:///home/vesoft/backup"

+----------------------------+---------------------+------------------+-------------+------------+
|            NAME            |     CREATE TIME     | SPACES           | FULL BACKUP | ALL SPACES |
+----------------------------+---------------------+------------------+-------------+------------+
| BACKUP_2023_01_18_09_42_10 | 2023-01-18 17:42:10 | basketballplayer | true        | true       |
+----------------------------+---------------------+------------------+-------------+------------+ 
```

### 使用 BR 恢复数据

当集群数据出现问题时，我们可以使用 BR 基于之前备份的数据进行恢复。为了模拟数据丢失场景，可以执行下面的命令将 basketballplayer space 的数据清除。

```
(root@nebula) [basketballplayer]> DROP SPACE basketballplayer;
Execution succeeded (time spent 2253/3002 us)
...
```

将 space 删除后，执行下面命令进行数据恢复。

```
./br-3.3.0-linux-amd64 restore full --meta "192.168.8.144:9559" --storage "local:///home/vesoft/backup" --name BACKUP_2023_01_18_09_42_10
```

该命令会让 BR 从 `/home/vesoft/backup/BACKUP_2023_01_18_09_42_10` 读取备份数据，对 Meta 服务地址为 `192.168.8.144:9559` 的 NebulaGraph 集群进行恢复。

恢复完成后，我们可以通过 nebula-console 执行以下命令，查看恢复后的集群数据。理论上，此时的数据应该与备份之前的数据保持一致。

```
(root@nebula) [(none)]> use basketballplayer Execution succeeded (time spent 1130/1823 us)
...
 
(root@nebula) [basketballplayer]> submit job stats
+------------+
| New Job Id |
+------------+
| 3          |
+------------+
...
 
(root@nebula) [basketballplayer]> show stats
+---------+------------+-------+
| Type    | Name       | Count |
+---------+------------+-------+
| "Tag"   | "player"   | 51    |
| "Tag"   | "team"     | 30    |
| "Edge"  | "follow"   | 81    |
| "Edge"  | "serve"    | 152   |
| "Space" | "vertices" | 81    |
| "Space" | "edges"    | 233   |
+---------+------------+-------+ 
...
```

### 清理备份数据

在恢复完成后，我们可以执行下面的命令清理本次的备份数据。

```
./br-3.3.0-linux-amd64 cleanup  --meta "192.168.8.144:9559" --storage "local:///home/vesoft/backup" --name BACKUP_2023_01_18_09_42_10
```

以上为本次 NebulaGraph 备份工具 nebula-br 的介绍。

---

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

要来近距离体验一把 nebula-br 特性么？NebulaGraph 阿里云计算巢现 30 天免费使用中，[点击链接](http://c.nxw.so/dvdGf)来用用图数据库 NebulaGraph 和图数据备份 BR 吧~

想看 nebula-br 源码的小伙伴可以前往 GitHub 阅读、使用、(^з^)-☆ star 它 -> [GitHub](http://c.nxw.so/949Gz)；和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能，留下[「你的名片」](http://c.nxw.so/9jvQN)一起玩耍呢~

本文以 NebulaGraph Backup & Restore 社区版为例，简单介绍 BR 的一些实现细节并通过上手练习来讲述如何使用 BR 进行 NebulaGraph 数据的备份恢复。

一文上手图数据备份恢复工具 NebulaGraph BR

我们如何在表格源中对数据建模并将其 ETL 到 NebulaGraph？本文向我们展示了一个使用 dbt 的端到端示例。

如何使用 dbt 将多种数据类型转换为 NebulaGraph 中的图数据？

![青藤云安全：基于图数据库打造的下一代入侵检测系统](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/%E5%85%A5%E4%BE%B5%E6%A3%80%E6%B5%8B%E7%B3%BB%E7%BB%9F1.jpg)

> 青藤云安全是一家主机安全独角兽公司，看名字就知道当前很大一块方向专注云原生应用安全，目前主营的是主机万相/容器蜂巢产品，行业领先，累计支持 800万 Agent。当前公司基于 NebulaGraph 结合图技术开发的下一代实时入侵检测系统已经初步投入市场，参与了 2022 护网行动，取得了不错的反响。

本文将简单介绍基于图的入侵检测系统，抛砖引玉，期望能有更多优秀人才参与挖掘图与安全的结合应用。

## 入侵检测的现状与挑战

### 主流入侵检测系统

入侵检测一直是安全研究的一大方向，青藤的万相和蜂巢两套产品分别为基于主机和容器的主机入侵检测产品，它们的原理都类似，如下图。

![入侵检测系统架构图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-01.png)

Agent 埋在主机/容器侧，接收服务端下发的规则结合采集的原始事件（进程/网络连接/文件读写等），通过安全专家编写规则，比如：进程文件 MD5/文件 MD5/执行命令行/机器学习等特征，命中当做告警报出来，相关告警上报到服务端；另外全量的原始事件也上报给服务端日志收集系统，入库保存到 SIEM 系统。

这套系统一旦告警上报到服务端，安全人员会拿当前告警相关信息到 SIEM 中查询告警发生时刻前后相关的事件，必要时登录相关机器查看相关信息，综合判断当前攻击告警是否有效并做相关处置。

这套系统是当前入侵检测的主流架构，但是也存在诸多问题：

1. 基于单事件+规则做单点检测，可能造成大量误报（规则太松）或漏报（规则太严）
2. 同一次攻击触发的告警可能过多，安全分析人员分析溯源工作量巨大
3. 同一次告警相关原始事件需要借助 SIEM 人工分析，缺乏可视化手段

### 图与安全研究方向

其实，可以看到这里的几个问题点本质上都是独立去看待每个告警和事件，实际上一次攻击相关的告警/事件应该是彼此关联的，这里很自然想到用图去把这些原始事件/告警关联起来整体分析。事实上，这也是当前安全研究的一个热门方向——溯源图，借助溯源图我们做如下多方面的安全分析和检测：

#### 1.图检测

传统安全解决的类似 IOC 检测，也就是单点判断，针对进程/网络连接/文件等实体判断是不是安全的；实际攻击面临的问题，可能各个点都检测不出来，但实际行为是危险的——1 个规则写不全，就算规则能写出来，比如命中某个命令行，但是触发告警很多，最终也无法应用。也就是要综合判断各种组合关系，这是图擅长的事情，也就是安全中图检测的问题——把所有相关的事件放在一张图中来综合判断分析是否为有效攻击。

**图检测研究很早，但是面临计算量和算法的双重挑战，目前行业应用很少，基本上组合判断都还是序列检测方式**。问题是序列规则能写多少确定规则，规则太多也有问题，无法应用；刚才提到确定规则，无法很好模糊匹配，也就是挖掘，安全中规则太确定就可以被绕过，黑客很聪明且借助自动化攻击更容易绕过这些规则。

#### 2.图关联和溯源

刚才提到告警，也就是当前所有安全产品面临的另一个问题——要不是规则命中不了，要不就是规则命中太多，我们叫**告警淹没**，安全运营处理能力有限，可能一天 100 个告警还好，如果一天甚至一小时 10000 条告警就没法处理了，那和没告警没差别。

这其实是一个安全中关联分类和溯源的问题：

1. 一次攻击会产生很多告警，比如：暴力破解登录，用了恶意文件，执行了恶意命令等等，关联分类把一次攻击中相关的告警关联在一起，这是图擅长的事情。这些告警关联在一起，还可以综合评判也就是多个告警联合判断当前攻击是否有效；
2. 每个告警只会告诉你当前你是进程、文件、网络有问题，那这个问题是如何发生的，黑客是怎么进来的，文件是从哪里下载的，先干了什么后干了什么。安全产品需要帮助客户完成这个分析过程，目前行业是借助 SIEM/THP/SOC 等安全产品，所有原始事件都上传保存，找安全专家，从告警开始查原始事件日志，看告警前发生了什么，哪些有关系可能导致攻击，这个过程短则几分钟，长甚至数个小时。**安全是个对抗过程，早就是优**——越早发现越早对抗，封禁或隔离，否则就算发现也为时过晚。可以把相关的原始事件实体（进程/网络等）入图，借助图可以可视化探索和溯源整个攻击过程，这就是图溯源的过程，学术叫因果图、溯源图。

#### 3.图知识图谱和预测

我们知道**当前安全从根本上讲还是基于规则或者说先验知识**，每种漏洞/木马/攻击工具/攻击过程/攻击组织都有它的特征，前几种规则还比较好描述，攻击过程、攻击组织等就很难完整描述了。

目前的主流做法是基于安全框架构建知识库，当前主流有 Kill Chain/ATT&CK 等框架，这是美国国防部主导的网络攻击战争相关两家公司提出的安全分析框架，相当于划分了攻击的战术和具体攻击技术的映射，这个具体如何实施比较难。安全学术界，比如：伊利诺伊大学/普渡大学近两年都在研究类似问题，也就是安全知识库（安全知识图谱）的构建。有了这个完善的知识库，就可以完成安全的终极设想，比如：我知道你的攻击过程/攻击组织，是不是就可以在攻击真正开始前，好比你打仗刚拿起枪冲到阵地上，判断你是要朝我开枪，预判直接击毙。

### 国内外现状

目前基于图的入侵检测系统，真正率先投入到实战中的是美国的安全明星公司——Crowd Strike，它完全基于图构建安全系统，现在相当于做了图检测和图关联溯源这两块的事情，目前估值 670 亿美元。云计算巨头 AWS 和 Azure 都在跟进它的方法。国内基于图做入侵检测系统的，目前有公开资料的是微步在线和深信服，他们相当于做了部分图关联和溯源的工作。

青藤云安全的万相和蜂巢在入侵检测深耕多年，已经取得了行业认可的安全检测能力，所以选择**从图关联和溯源入手，基于 NebulaGraph 结合图技术开发的下一代实时入侵检测系统，先重点解决告警淹没和关联溯源的痛点问题**。

## 青藤云安全下一代入侵检测系统

### 检测原理架构图

如下，核心是上报的攻击告警和部分原始事件统一在图中实时关联。

![检测原理架构图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-02.png)

### 产品效果

经过关联引擎关联处理输出的就是攻击事件，一个攻击事件可能关联多个攻击告警并可视化呈现出来，当前产品效果图如下：

同一次攻击利用恶意文件和木马

![同一次攻击利用恶意文件和木马](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-03.png)

敏感容器挂载

![敏感容器挂载](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-04.png)

自定义脚本检测

![自定义脚本检测](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-05.png)

### NebulaGraph 的优势

选择 NebulaGraph 主要基于如下考虑：

1. 图查询的刚需，特别是关联和溯源时多级进程关系查询，借助 Cypher查询图数据库能够比借助 SQL 在关系数据库中查询多级关系容易多；
2. 大规模存储，涉及到大量事件和告警的存储；
3. 高性能查询场景需求，关联需要保证近实时，当前相关查询都在 ms 级别；

得益于 NebulaGraph 的良好性能，关联引擎以近实时的方式入图和计算关联，入图部分是青藤自己基于 Flink 打造的实时入图组件，只需要更改配置文件即可完成图点边映射入图。

## 下一步研究方向和计划

当前青藤云安全新入侵检测主要支持单机和部分多机场景的关联和溯源，下一步重点是借助图支持更多多机关联的场景，特别是一些典型的安全攻击场景（反弹/横移），进一步以图赋能安全，为客户提供更好的服务。

当然，当前在将 NebulaGraph 应用到图安全应用过程中，也遇到了很多问题，提一些建议供参考。

### 1.下推优化

在开发过程中，极关心查询效率问题。我们在使用过程中，最大的问题就是下推优化，比如一颗发散的进程树，同时指定根节点和叶子节点，语句书写顺序不同就可能导致查询从叶子节点开始还是根节点开始，查询效率千差万别，最后不得不只指定叶子节点条件强制从叶子节点开始查。

MATCH 性能本质上也是下推优化问题，这个问题遇到也很多，目前我们的做法是对于部分已经查询过语句维持一个缓存池，也注意到官方企业版其实提供了部分缓存功能，这个点要是能考虑加到社区版就好了，是一个实际应用刚需。

### 2.实时场景一些技术需求点

因为我们是基于 NebulaGraph 做实时关联，一个较大的问题是如何实现一致性和速度的平衡——因为目前 NebulaGraph 实现的是最终一致性，写入图后其实是不知道到底是否真实入图完成。在实际应用中，关联引擎需要在下游轮询等待判断当前的点边是否真正的入图完成。这个对于实际使用和性能都会造成一定影响，是否有更好的方式值得思考。

另一块其实还是效率相关的问题，我们可以看到一些竞品 TigerGraph/TuGraph 都提供了自定义匹配/遍历算法和能力，比如：在我们多机关联场景中就遇到这种需求，目前只能通过拆分多条路径然后拼接起来的实现方式，效率和速度无疑是打折扣的。

### 3.TOB 部署

另一个，感受较深的是 NebulaGraph 对 TOB 部署的痛点。安全这个行业，目前国内还是走现场部署的较多，特别是国企和政务相关对上 SaaS 相对敏感，那么面临的问题就是效率和成本的问题——

**第一个是单机部署**，默认生产版本是为云设计的存算分离分布式部署方式，对于 TOB 部署还是太繁琐，且资源占用相对也较其他数据库多。

**第二个是 HDD 部署**，成本考虑，很多公司特别中小公司安全预算有限，很难提供 SSD 环境，更别说官网要求的大容量 SSD 高配置机器，也就是针对 HDD 和低配机器的优化上需要考虑更多。

以上，为青藤云安全团队工程师文洲带来的分享。

---

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

要来近距离体验一把图数据库吗？现在可以用用 NebulaGraph Cloud 来搭建自己的图数据系统哟，快来节省大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天免费使用中，[点击链接](http://c.nxw.so/8gMXe)来用用图数据库吧~

想看源码的小伙伴可以前往 GitHub 阅读、使用、(^з^)-☆ star 它 -> [GitHub](http://c.nxw.so/8yTlk)；和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能，留下[「你的名片」](http://c.nxw.so/9jvQN)一起玩耍呢~

本文将介绍青藤云安全基于 NebulaGraph 图技术开发的下一代实时入侵检测系统，该系统目前已经初步投入市场，参与了 2022 护网行动，取得了不错的反响。

青藤云安全：基于 NebulaGraph 图数据库打造的下一代入侵检测系统

本文分享如何用开源、现代的 DataOps、ETL、Dashboard、元数据、数据血缘管理系统构建大数据治理基础设施。

如何轻松做数据治理？开源技术栈告诉你答案

本文将分享图算法在风控中的应用，包括图算法和风控简介、图算法在风控的演化、相应平台的使用心得以及未来展望。

图算法、图数据库在风控场景的应用

> 一次利用 chatGPT 给出数据抓取代码，借助 NebulaGraph 图数据库与图算法预测体育赛事的尝试。

![chatGPT 加图数据库 NebulaGraph 预测 2022 世界杯冠军球队](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/%E4%B8%96%E7%95%8C%E6%9D%AF%E6%B4%BB%E5%8A%A8-13.jpg)

# 蹭热度

最近因为世界杯进行时，被这篇 [Cambridge Intelligence](https://cambridge-intelligence.com/fifa-world-cup-2022-prediction/) 的文章启发（仅仅利用有限的信息量和条件，借助图算法的方法做合理的冠军预测），讨论到也可以试着用 NebulaGraph 玩玩冠军预测，还能顺道科普一波图库技术和图算法。

本来想着几个小时撸出来一个方案，被数据集的收集劝退了，我是是在懒得去 [wikepedia](https://en.wikipedia.org/wiki/2022_FIFA_World_Cup_squads) 里抓取出来需要的数据，索性就按下放了几天。

同时，另一个热潮是最近 OpenAI 发布了 chatGPT 服务，它可以实现各种语言可是实现的复杂任务设计包括：

- 随时帮你实现一段什么样的代码
- 模拟成任意一个 prompt 界面：shell、python、virtual machine、甚至你创造的语言
- 假设、带入你给定的人设，和你聊天
- 写诗歌、rap、散文
- 找出一段代码的 bug
- 解释一段复杂的正则表达式的含义

chatGPT 的上下文能力、理解力到的前所未有的程度以至于所有人都在讨论新的工作方式：如何掌握让机器帮助我们完成任务。

所以，当我试过让 chatGPT 帮我写复杂的图数据库查询语句、解释复杂图查询语句的含义、解释一大段 *Bison* 代码含义之后我才意识到：为什么不让 chatGPT 帮我写好抓取数据的代码呢？

# 抓取数据

我真试了一下，结果是：完全可以，而且似乎真的很容易。

整个过程基本上我像是一个代码考试的面试官、或者是一个产品经理，提出我的需求，chatGPT 给出代码的实现。我们再试着跑起来代码，找到代码中不合理的地方，指出来、给出建议，chatGPT 就真的能理解我指出的点，并给出相应的修正，像是：

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/chatGPT-correction-process.webp)

这一全过程我就不在这里列出来了，不过我把生成的代码和整个讨论的过程都分享在[这里](https://gist.github.com/wey-gu/78cb28bee130966e7d6e9d573b51deff)，感兴趣的同学可以去看看。

最终生成的数据是一个 CSV 文件：

- 代码生成的文件 [world_cup_squads.csv](https://github.com/siwei-io/talks/files/10152775/world_cup_squads.csv)

- 手动修改、分开了生日和年龄的列 [world_cup_squads_v0.csv](https://github.com/siwei-io/talks/files/10152923/world_cup_squads.csv)

  它像这样，包含的信息有：球队、小组、编号、位置、球员名字、生日、年龄、参加国际比赛场次、进球数、服役俱乐部。

```CSV
Team,Group,No.,Pos.,Player,DOB,Age,Caps,Goals,Club
Ecuador,A,1,1GK,Hernán Galíndez,(1987-03-30)30 March 1987,35,12,0,Aucas
Ecuador,A,2,2DF,Félix Torres,(1997-01-11)11 January 1997,25,17,2,Santos Laguna
Ecuador,A,3,2DF,Piero Hincapié,(2002-01-09)9 January 2002,20,21,1,Bayer Leverkusen
Ecuador,A,4,2DF,Robert Arboleda,(1991-10-22)22 October 1991,31,33,2,São Paulo
Ecuador,A,5,3MF,José Cifuentes,(1999-03-12)12 March 1999,23,11,0,Los Angeles FC
```

- 手动删除了 CSV 表头 [world_cup_squads_no_headers.csv](https://github.com/siwei-io/talks/files/10152974/world_cup_squads_no_headers.csv)

# 图方法预测2022世界杯

## 图建模

> 前提，本文使用 NebulaGraph 和 NebulaGraph Explorer，你可以在阿里云上免费申请半个月的试用，入口链接是👉🏻 http://c.nxw.so/d52oz ，不要被这个陌生的短链接域名吓到，它只是帮助我们统计有多少同学通过这里访问到 https://market.aliyun.com 而已。

图建模（Graph Modeling）是把真实世界信息以”点-->边“的图形式去抽象与表示。

这里，我们根据公共领域能够容易获得信息、把它映射成如下的点与边：

点：

- player（球员）
- team（球队）
- group（小组）
- club（俱乐部）

边：

- groupedin（球队属于哪一小组）
- belongto（队员属于国家队）
- serve（队员在俱乐部服役）

而队员的年龄、参加国际场次（caps）、进球数（goals）则很自然作为 player 这一类点的属性。

下图是这个 schema 在 NebulaGraph Studio/Explorer（后边称 Studio/Explorer） 中的截图：

![schema_fifa](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/schema_fifa.webp)

然后，我们可以在右上角把它保存，创建一个新的图空间，应用这个图建模到图空间里。

> 注：参考文档 https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/db-management/draft/

## 导入数据进 NebulaGraph

有了图建模，我们可以把之前的 CSV 文件（无表头版本）上传到 Studio 或者 Explorer 里，通过点、选关联不同的列到点边中的 vid 和属性：

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/importer_config_mapping.webp)

之后点击导入，就把整个图导入到 NebulaGraph 了，成功之后，我们还得到了整个csv --> Nebula Importer 的关联配置文件：[nebula_importer_config_fifa.yml](https://github.com/siwei-io/talks/files/10164014/config_fifa.yml.txt)，你可以直接拖拽整个配置，不用自己去配置它了。

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/importer_log.webp)

> 注：参考文档 https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/db-management/11.import-data/

导入之后，我们可以在 schema 界面里查看数据统计，我们可以看到有 831 名球员参加了 2022 卡塔尔世界杯，他们服役在 295 个不同的俱乐部：

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/data_stats.webp)

> 注：参考文档 https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/db-management/10.create-schema/#_6

## 探索数据

### 查询数据

下面，我们试着把所有的数据展示出来看看吧，首先，借助 NebulaGraph Explorer，我用拖拽的方式画出来任意类型的点（TAG）和任意类型点（TAG）之间的边，这里我们知道所有的点都是至少包含在一个边里的，所以不会漏掉任何孤立的点。

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/query-builder-0.webp)

让它帮我生成查询的语句，这里，它默认 LIMIT 100 了，我们手动改大一些（ LIMIT 10000），让它在 Console 里执行。

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/query-builder-1.webp)

### 初步观察数据

结果渲染出来是这样子，可以看到它天然形成了一簇一簇的模式。

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/bird_view.webp)

这些外围、形成的簇多是一些由非传统意义上的有全球影响力的俱乐部，和非传统的足球厉害的国家队的球员组成，因为通常这些俱乐部只有一两个球员，而且他们还集中在一个国家队、地区，所以没有和很多其他球员、国家队产生连接。

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/edge_teams.webp)

### 图算法辅助分析

在我点击了 Explorer 中的两个按钮之后（详细参考后边的文档链接），在浏览器里，我们可以看到整个图已经变成：

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/Barcelona.webp)

> 注：这部分功能可以参考文档 https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/graph-explorer/graph-algorithm/

这里，利用到了两个图算法来分析这里的洞察：

1. 利用点的出入度，改变他们的显示大小突出重要程度
2. 利用 Louvain 算法区分点的社区分割

可以看到红色的大点是鼎鼎大名的巴塞罗那，而它的球员们也被红色标记了。

### 预测冠军算法

为了能充分利用图的魔法（与图上的隐含条件、信息），我的思路是选择一种利用链接进行节点重要程度分析的图算法，找出拥有更高重要性的点，对他们全局迭代、排序，从而获得前几名的国家队排名。

这些方法其实就体现在厉害的球员同时拥有更大的社区、连接度，同时，为了增加传统强队之间的区分度，我准备把出场率、进球数的信息也考虑进来。

最终，我的算法是：

- 取出所有的 (球员)-服役->(俱乐部) 的关系，过滤其中进球数过少、单场进球过少的球员（以平衡一些弱队的老球员带来的过大影响）
- 从所有过滤之后的球员中向外探索，获得国家队
- 在以上的子图上运行 Betweenness Centrality 算法，计算节点重要度评分

### 算法过程

首先，我们取出所有进球数超过 10，场均进球超过 0.2 的 (球员)-服役->(俱乐部) 的子图：

```cypher
MATCH ()-[e]->()
WITH e LIMIT 10000
WITH e AS e WHERE e.goals > 10 AND toFloat(e.goals)/e.caps > 0.2
RETURN e
```

> 注：为了方便，我把进球数和出场数也作为了 serve 边上的属性了。

![](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/query_step0.webp)

然后，我们全选图上的所有点，点击左边的工具栏，选择出方向的 `belongto` 边，向外进行图拓展（遍历），同时选择将拓展得到的新点标记为旗帜的 icon：

![treversal_step1](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/treversal_step1.webp)

现在，我们获得了最终的子图，我们利用工具栏里的浏览器内的图算法功能，执行 BNC（Betweenness Centrality）

![bnc_step2](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/bnc_step2.webp)

然后，这个子图变成了这样子：

![bnc_predict](https://www.siwei.io/chatgpt-and-nebulagraph-predict-fifa-world-cup/bnc_predict.webp)

# 预测结果 🎉🎉

**最终，我们根据 Betweenness Centrality 的值，排序，可以得到最终的获胜球队应该是：巴西 🇧🇷**！

其次是比利时、德国、英格兰、法国、阿根廷，让我们等两个礼拜回来看看预测结果是否准确吧 :D。

注：排序数据（其中还有非参赛球队的点）

| Vertex                    | **Betweenness Centrality** |
| ------------------------- | -------------------------- |
| **Brazil**🇧🇷              | 3499                       |
| **Paris Saint-Germain**   | 3073.3333333333300         |
| **Neymar**                | 3000                       |
| **Tottenham Hotspur**     | 2740                       |
| **Belgium**🇧🇪             | 2587.833333333330          |
| **Richarlison**           | 2541                       |
| **Kevin De Bruyne**       | 2184                       |
| **Manchester City**       | 2125                       |
| **İlkay Gündoğan**        | 2064                       |
| **Germany**🇩🇪             | 2046                       |
| **Harry Kane (captain**   | 1869                       |
| **England**🏴󠁧󠁢󠁥󠁮󠁧󠁿              | 1864                       |
| **France**🇫🇷              | 1858.6666666666700         |
| **Argentina**🇦🇷           | 1834.6666666666700         |
| **Bayern Munich**         | 1567                       |
| **Kylian Mbappé**         | 1535.3333333333300         |
| **Lionel Messi (captain** | 1535.3333333333300         |
| **Gabriel Jesus**         | 1344                       |


一次利用 chatGPT 给出数据抓取代码，借助 NebulaGraph 图数据库与图算法预测体坛赛事的尝试。

谁能捧起大力神杯？用 chatGPT 加 NebulaGraph 图数据库预测 2022 世界杯冠军球队


![Springboot 撞上 NebulaGraph——NGbatis 初体验](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/NGbatis/NGbatis-1.jpg)

大家好，我是开源项目 NGbatis 的发起人大叶 (CorvusYe@GitHub)。目前 [NGbatis](https://github.com/nebula-contrib/ngbatis) 也已成为 NebulaGraph 开源生态项目之一。在过去的 4 个月里，NGbatis 从提交第一行代码以来，已经发布了 3 个版本，正在一步步变得越来越好。感谢一路同行的人们。这里给大家贴上仓库地址：[https://github.com/nebula-contrib/ngbatis](https://github.com/nebula-contrib/ngbatis)，欢迎大家在仓库下方留言提出建议反馈。

# 一、目前有哪些参与者？
![Springboot 撞上 NebulaGraph——NGbatis 初体验](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/NGbatis/NG-1.png)

其中，[Szt-1](https://github.com/Szt-1) 做了和 Springcloud 和 nacos 的兼容，[liuxiaocs7](https://github.com/liuxiaocs7) 完善了文档，[soul-gin](https://github.com/soul-gin) 做了 Java 与数据库之间属性别名的映射，[Nicole00](https://github.com/Nicole00) 做了项目自动化与代码规范，[wey-gu](https://github.com/wey-gu) 提了很多有利于项目发展的建议并做了国际化。[DawnZzzzz](https://github.com/DawnZzzzz)、[hejiahuichengxuyuan](https://github.com/hejiahuichengxuyuan)、[yarodai](https://github.com/yarodai)与[LiuTianyou](https://github.com/LiuTianyou)则提了不少 issues，issues 让人获得不少灵感。可以说现阶段的 NGbatis 是使用者与开发者想法碰撞后的共同产物。

# 二、什么是 NGbatis？
**NGbatis** 是一款针对 [NebulaGraph](https://github.com/vesoft-inc/nebula) + Springboot 的数据库 ORM 框架。借鉴于 [MyBatis](https://github.com/mybatis/mybatis-3) 的使用习惯进行开发。包含了一些类似于 [mybatis-plus](https://github.com/baomidou/mybatis-plus) 的单表操作，另外还有一些图特有的实体-关系基本操作。  

> 如果是 Java 后端服务的开发人员，相信看到这里，大家对 NGbatis 的用途有了比较清晰的理解。接下来会从几个问题出发，跟读者们介绍 NGbatis:
> - 关于 NGbatis 有哪些思考？
> - NGbatis 能做什么？
> - NGbatis 是怎么实现的？
> - NGbatis 怎么使用？

# 三、关于 NGbatis 有哪些思考？
- Q: 最原始的诉求是什么？  
- A: 与 MyBatis 相同，想实现 GQL 与 Java 代码的分离 。 
- Q: 为什么不直接使用 MyBatis 集成？  
- A: 
    - MyBatis 遵循 JDBC 规范，而 JDBC 规范更适合于传统数据库，图数据库存在与传统数据库不同的、图特有的结构，如果采用 JDBC 规范，会受到一定局限。 
    - 想为图数据库量身定制一款 ORM，随着图数据库的发展，方便拓展。
- Q: 是否可以基于 JDBC 拓展出 GJDBC 的规范？  
- A: 个人能力有限，不敢想，或许 NebulaGraph 官方可以考虑下。
- Q: 为什么版本号从 v1.1.0 开始，缺失了 v1.0.0 的版本号？  
- A: 
    - 最开始的版本是用来适配 Neo4j，后来选用了 NebulaGraph，保留了一个不曾发布的小版本。
    - 第一次接触的 NebulaGraph 是 v3.1.0，兼容性方面重点放在 v3.1.0+ 的版本

以上是开发之初对 NGbatis 的一些方案选择的思考，做了一些取舍，是好处多一些还是坏处多一些，我自己目前也还在纠结中。比如说放弃 JDBC 的规范后也意味着放弃其背后的生态，比如说优秀的第三方连接池方案。  
纠结归纠结，既然做了决定，路还是要往下走。开胃菜上完了，也该上正餐了。

# 四、NGbatis 能做什么？
一个项目诞生最恰当的理由是：想要用它解决一些问题。以解决问题为中心，可以让项目走得更远。NGbatis 的任务就是尽可能地减少日常开发中或重复或繁琐的工作。
- 在代码里频繁地做 “字符串”+”字符串”
- 一遍一遍地重复处理 ResultSet -> 业务对象
- 重复写单表基本的增、删、改、查
- 在集成时，做过多配置，为什么万事就一定是开头难，简单点，集成的方式简单点
- 需要关注与业务关系不是很密切的 Session 问题

我们生活在一个基础设施相对完善的时代，好处在于问题产生的同时，答案的模型也同时存在，我们需要做的只是在问题与答案之间做适配，这里真诚地对作出贡献的前辈们表示感谢。

以上问题就要求 NGbatis 需要做到以下几点：
- 开箱即用，实现与 Springboot、Springcloud 的快速集成
- 实现 GQL 与 Java 代码分离，使用 XML 统一管理
- 使用模板引擎，解决 GQL 参数拼接繁琐、容易写错的问题
- 实现 ResultSet 与 Java 对象根据属性名自动转换
- 单表基本增、删、改、查以及分页
- 本地 Session 管理，降低资源消耗

方向有了，剩下的就是工程问题了。

# 五、NGbatis 是怎么实现的？
我们最本质的要求就是：把 GQL 语句执行到 NebulaGraph 当中。我们以带参的 Hello Nebula 为例，即：
![Springboot 撞上 NebulaGraph——Ngbatis 初体验](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/NGbatis/NG-2.png)

根据最朴素的 Java 开发方法，可以想到的是：先通过 XML 给 GQL 定义一个坐标，再定义一个接口，最后编写一个实现类按坐标读取 GQL 语句，使用模板引擎替换参数。即：
- XML
```xml
<mapper namespace=
        "com.example.dao.TestDao">

    <select id="greet">
        RETURN 'Hello ${ p0 }'
    </select>

</mapper>
```
- DAO 接口
```java
package com.example.dao;

public interface TestDao {
  String greet(String who);
}
```

- DAO 实现（伪代码）
```java
package com.example.dao;

public class TestDaoImpl implements TestDao {

  @Override
  public String greet(String who) {
    Object[] var2 = new Object[]{who};
    String namespace = "com.example.dao.TestDao";
    String methodName = "greet";
    // 有一个函数，可以完成以下事情：
    // 1. 根据坐标读取 GQL
    // 2. 使用模板引擎完成参数拼接（Beetl）
    // 3. 执行到数据库
    // 4. 转换 ResultSet 形成 业务对象
    return foo( namespace, methodName, var2 );
  }
}
```

做到这里其实就剩下 foo 怎么编写的问题了。到这里，相信读者们都有自己的思路。大家有兴趣的话可以参考
`org.nebula.contrib.ngbatis.proxy.MapperProxy`。

但引入了另一个问题：每个 dao 的方法，写法基本是一样的，又带来了重复的工作，有悖于 NGbatis 的初衷。因此，使用动态代理，从 XML 与 DAO 信息中自动生成 `TestDao$Proxy`，这边使用的代理方案是基于字节码技术 ASM 来生成。上述的例子生成的字节码反编译后的结果如下：
```java
package com.example.dao;

import org.nebula.contrib.ngbatis.proxy.MapperProxy;

public class TestDao$Proxy implements TestDao {

  @Override
  public String greet(String var1) {
    Object[] var2 = new Object[]{var1};
    return (String) MapperProxy.invoke( "com.example.dao.TestDao", "greet", var2 );
  }
}
```

因此，开发者便不需要再重复编写诸多 `TestDaoImpl`，定义好 XML 与 DAO，剩下的工作可以放心地交给 NGbatis。

最后剩下一个问题，参数替换问题：这个问题应该是与开发者关系最为密切的问题。所以这里不得不提的模板引擎框架：[Beetl](https://www.kancloud.cn/) 是国内流行模板引擎，也是 NGbatis 一个重要的组成部分，链接是官网的 API。
- 在调用时，将入参 json 化成 nebula-java 可以接收的参数形式（List、Set、Map、字符串、基本类型...）:

    ```java
                                                      {
    String hello = dao.greet(“Nebula”);       -->       “p0”: “Nebula”
                                                      }
    ```

- 最后以 XML 内容为模板，进行替换：
    ```java
    RETURN 'Hello ${ p0 }'                  -->        RETURN 'Hello Nebula'
    ```

# 六、全局流程图

![Springboot 撞上 NebulaGraph——Ngbatis 初体验](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/NGbatis/NG-3.png)


# 七、NGbatis 该如何集成到自己的 Springboot 项目
1. 添加依赖
    ```xml
        <dependency>
            <groupId>org.nebula-contrib</groupId>
            <artifactId>ngbatis</artifactId>
            <version>1.1.0-rc</version>
        </dependency>
    ```

2. 配置 NebulaGrpah 数据库
    ```yml
    nebula:
      hosts: 127.0.0.1:19669, ip:port, ....
      username: root
      password: nebula
      space: test
      pool-config:
        min-conns-size: 0
        max-conns-size: 10
        timeout: 0
        idle-time: 0
        interval-idle: -1
        wait-time: 0
        min-cluster-health-rate: 1.0
        enable-ssl: false
    ```
3. 添加扫描包以引入 NGbatis bean
    ```java
    @SpringBootApplication(
      exclude={ DataSourceAutoConfiguration.class }, 
      scanBasePackages = {  "org.nebula.contrib", "your.domain" }  )
    public class YourSpringbootApplication {
    
    }
    ```

4. 声明主键生成器
    ```java
    import org.nebula.contrib.ngbatis.PkGenerator;
    @Component
    public class CustomPkGenerator implements PkGenerator {
    
        @Override
        public <T> T generate(String tagName, Class<T> pkType) {
            Object id = null; // 此处自行对 id 进行设值。
            return (T) id;
        }
    
    }
    ```


到此，对于集成工作来说，任务已经完成，剩下就是开发的工作了。
开发人员只需要做三件事：
1. 定义接口：
    ```java
    package your.domain;

    import  org.nebula.contrib.ngbatis.proxy.NebulaDaoBasic;
    
    public interface PersonDao extends NebulaDaoBasic<Person, String> {
        Person selectByName( @Param("name") String param );
    }
    ```
2. 在 resources/mapper/PersonDao.xml 中编写 GQL
    ```xml
    <mapper namespace="your.domain.PersonDao">
        <select id="selectByName">
            MATCH (n: person)
            WHERE n.person.name == $name
            RETURN n
            LIMIT 1
        </select>
    </mapper>
    ```
3. 调用
    1. 注入：
        ```java
            @Autowired private PersonDao dao;
        ```
    2. 调用自定义接口
        ```java
        Person tom = dao.selectByName("Tom");
        ```
        > 更多文档：[自定义 nGQL](https://corvusye.gitee.io/ngbatis-docs/#/?path=dev-example&file=custom-crud)
    
    3. 调用基类接口
        ```java
          // 不管属性是否为空，如果数据库中已有对应 id 的值，则覆盖
          public void insert( Person person ) {
            dao.insert( person );
          }
        
          // 仅写入非空属性
          public void insertSelective( Person preson ) {
            dao.insertSelective( person );
          }
        
          // 此处，Person 的主键栏 name 为 String ，则入参为 String
          public Person selectById( String id ) {
            return dao.selectById( id );
          }
        
          // 按属性查询
          public List<Person> selectBySelective( Person person ) {
            return dao.selectBySelective( person );
          }
          
        ```
        > 更多文档：[使用基类读写](https://corvusye.gitee.io/ngbatis-docs/#/?path=dev-example&file=dao-basic)

# 八、尾声
以上就是本次交流的全部内容。如果实现方式也是你喜欢的，issue、pr、star 都是 ok 的。如果对项目感兴趣，也可以参与到开发中来，从中获得成就感。仓库地址：[https://github.com/nebula-contrib/ngbatis](https://github.com/nebula-contrib/ngbatis)。最后也希望 NGbatis 能给越来越多的开发者带来开发上的便利。

---
- NebulaGraph Desktop，Windows 和 macOS 用户安装图数据库的绿色通道，10s 拉起搞定海量数据的图服务。通道传送门：[http://c.nxw.so/6TWJ0](http://c.nxw.so/6TWJ0)

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

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

NGbatis 是一款针对 NebulaGraph + Springboot 的数据库 ORM 框架。借鉴于 MyBatis 的使用习惯进行开发，目的是减少日常开发中重复或繁琐的工作。

Springboot 撞上 NebulaGraph——NGbatis 初体验






![复杂场景数据处理的 OLTP 与 OLAP 融合实践](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/TP%20%2B%20AP/wechat.jpg)
# Dag Controller 介绍

Dag Controller 是 NebulaGraph 企业版的系统，经过反复测试无误后进行了发布，它主要解决的是 OLTP 和 OLAP 的融合问题，以及复杂场景下的图计算问题。也欢迎大家来详细了解下：[https://docs.nebula-graph.com.cn/3.2.1/graph-computing/0.deploy-controller-analytics/](https://docs.nebula-graph.com.cn/3.2.1/graph-computing/0.deploy-controller-analytics/)。

下面是我对 Dag Controller 做的一些分享，欢迎大家留言一起探讨。

相信大家对 OLTP 和 OLAP 都不陌生，我这里再简单介绍下：** OLTP 是一种快速响应、实时在线的一种数据处理方式**。与之对应的** OLAP，是一种离线的、复杂场景的数据计算方式**。对 NebulaGraph 来说，OLTP 有多种多样的查询语句，如：go、match 等。OLAP 有各种各样的图算法，如：pagerank、louvian、wcc、kcore、jaccard 等。

OLTP 和 OLAP 并不是一个一个独立存在的，举例来说，我们可以将 match 跑出来的子图喂给 pagerank 算法，pagerank 跑出来的结果可以写入到 NebulaGraph，继续执行 match 语句或其它算法。就像拼积木一样，可以将各种各样的 OLTP 和 OLAP 组装起来，形成一种更加复杂场景的数据处理方式。

**Dag Controller 就是处理这种场景的系统，它负责 OLTP、OLAP 的串联和执行。**

![Dag Controller 介绍](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/TP%20%2B%20AP/TP%2BAP-01.png)

# 架构

![Dag Controller 架构](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/TP%20%2B%20AP/TP%2BAP-02.png)
Dag Controller 的职责：

1）向外部提供了 http 接口。

用于 Job 的提交、停止、删除等操作，以及系统环境的配置等。

2）DAG 的执行。

Dag Controller 在执行 DAG 时，OLAP 部分会调用 NebulaGraph Analytics 系统，OLTP 部分会调用 graphd 完成 nGQL 的执行。

NebulaGraph Analytics 是我们的图计算系统，支持 pagerank、wcc、louvain、jaccard 等图分析算法，支持 hdfs 和 NebulaGraph 数据源。

graphd、metad、storaged 是 NebulaGraph 中的组件，graphd 主要负责 nGQL 的解析，storaged 负责数据的存储，metad 负责元数据的存储。

# 案例

## 案例 1
![复杂场景数据处理的 OLTP 与 OLAP 融合实践](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/TP%20%2B%20AP/TP%2BAP-03.png)
上图是一个对子图跑 PageRank 算法的 DAG 模型，首先用 nGQL 语句获取一个子图，然后再对这个子图跑 PageRank 算法。

当我们的图规模特别大的情况下，且我们只想对部分图数据跑算法，就可以使用这种方式。




## 案例 2
![复杂场景数据处理的 OLTP 与 OLAP 融合实践](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/oltp-and-olap-case-2.png)

上图是一个对两类顶点计算最短路径的模型。

首先，分别用 nGQL 分别获取两个类别的顶点 ID。然后再把这两类顶点 ID 交给 ShortestPath 算法，ShortestPath 会在全图中计算这两类顶点之间的路径。

每个算法是可以设置基于全图跑算法，也可以基于子图跑算法。

DAG 模型有多种多样，可以根据不用的业务场景搭建不同的 DAG 模型。

# 技术实现


## DAG 模型

DAG（有向无环图）指的是一个没有回路的有向图。DAG 的一个实例看作是一个 Job，一个 Job 有多个 Task。

Dag Controller 中的 Task 可以是一个 nGQL，也可以是一个图算法，如 pagerank、louvain、sssp 等。

Job 执行时候需要先对 Task 排序，网上有很多相关的代码，这里不再赘述。


## 并行执行

为了保障 DAG 的执行效率，多个 DAG 需要做到并行执行。同时，在一个 DAG 的内部，无上下游依赖关系的Task也需要并行执行。

如何做到多个 DAG 并行执行以及 Task 的并行执行？简单的说，通过两个线程池分别处理 DAG 和 Task。

具体描述如下：

1）系统启动时，分配 Job 线程池和 Task 线程池，分别处理 Job 的执行和 Task 的执行。

2）定时地从数据库中获取未执行的 Job，交由 Job 线程池运行。

3）Job 执行时按照上下游的依赖关系对 Task 排序，然后依次判断每个 Task 的所有上游是否执行完成，上游执行完成后将此 Task 交给 Task 线程池执行，如果上游未执行完则等待。

4）在 Job 执行过程中，如果 Job 线程池满了之后，定时获取未执行 Job 时需要做等待处理。Task 线程池满了之后，也同样做等待处理。


## 类型校验

Task 之间的数据输入与输出存在数据类型校验问题，这里需要注意。比如：Task2 是 Task1 的下游，Task2 的输入需要的是 int 类型，而 Task1 输出也必须是 int 类型。


## DAG 停止

在停止 Job 的时候，需要对多个并行运行的 Task 进行停止。一个 Task 的有准备阶段、运行阶段，并且运行阶段会存在跨机器、多进程的情况。停止 Job 需要避免孤儿进程的问题。




## 自定义算法支持
我们支持将客户的算法当作一种 Task，用于 DAG 的搭建。首先，在系统中配置算法相关的参数信息。在执行 Job 时，由系统负责运行与 Task 相对应的算法。

___

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

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

Dag Controller，一款解决 OLTP 与 OLAP 融合问题的完美系统。

标签