NebulaGraph (NebulaGraph)

集群通信：从心跳说起

NebulaGraph — Thu, 01 Apr 2021 18:25:49 +0800

> 本文首发 Nebula Graph 官网：https://nebula-graph.com.cn/posts/cluster-communication-heartbeat/

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

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

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

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

1. 服务发现

当我们启动一个 Nebula Graph 集群时，需要在对应的配置文件中填写 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 这样的错误）。而当通过心跳获取到对应信息并保存至本地缓存后，就能够正常写入数据了。

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

how 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）。

心跳的演变历史

在 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。

[北京 / 上海 / 深圳 / 杭州] 技术布道师 20k-40k 15 薪

NebulaGraph — Mon, 22 Feb 2021 15:19:41 +0800

Nebula Graph 社区布道师

作为一款开源的数据库产品，社区对 Nebula Graph 团队至关重要。用户和贡献者为社区提供了大量的支持和帮助，使得 Nebula Graph 作为一款数据库产品更稳、更快，同时产品生态更丰富。社区布道师的加入，将使得 Nebula Graph 社区更具活力，更富创造力。

我们在寻找可以和 Nebula Graph 社区一同成长的你，一起撸起袖子，接受挑战，用你的知识、技能、态度创造出属于你的社区影响力。

关于布道师

作为 Nebula Graph 社区布道师，你的职责是帮助社区开发者使用 Nebula Graph，提升他们的使用体验。目前疫情期间，线下交流较少，你将通过线上渠道跟社区保持联系，同时生产社区需要的优质内容，如技术分享类文章、操作类视频、用户案例等。你的终极目标是帮助 Nebula Graph 使用者，达成我们的使命，即数据智能技术让世界更清晰。

岗位职责

作为 Nebula Graph 社区布道者，你将：

通过线上线下的方式跟世界各地的图数据库技术开发者、用户、爱好者交流，帮助他们更好地在各自的应用场景中使用图数据库技术
编写代码示例，准备大会演讲，制作教学视频，撰写优质的相关技术内容
在相关的会议和线下分享活动中做主题演讲
在各个 Nebula Graph 用户交流渠道答疑解惑，帮助用户，包括：官方论坛、Slack、微信群、GitHub、Twitter、Stack Overflow，或用户使用的其他渠道
向 Nebula Graph dev 团队反馈社区需求和建议，参与产品 roadmap 讨论和制定

岗位要求

我们寻找的你：

是一名资深软件工程师
擅长写作，能创作出受社区欢迎的技术文章
能基于你想布道的技术，写出高质量的代码示例和迷你应用
能根据你的演讲和文章，制作出相应的教学视频
是一位风趣、自信的演讲者，无论线上还是线下
具备产品经理对产品的敏锐度，对产品演进方向有自己的想法，并会积极争取主要决策者的支持
对分布式数据库、图数据库技术了解者优先
能熟练使用 C++ 者优先
对分布式图数据库相关技术动态保持关注者优先

联系我们

有意向的小伙伴可以通过以下方式联系我们：

email: hire@vesoft.com

电话：057128120658 转 1

薪酬区间：20-40k

Base 地：北京 /上海 /深圳 /杭州任选

欢迎你来！

图数据库 Nebula Graph 在 Boss 直聘的应用

NebulaGraph — Wed, 23 Dec 2020 14:34:50 +0800

本文首发于 Nebula Graph 官方博客：https://nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin/

摘要：在本文中，BOSS 直聘大数据开发工程师主要分享一些他们内部的技术指标和选型，以及很多小伙伴感兴趣的 Dgraph 对比使用经验。

业务背景

在 Boss 直聘的安全风控技术中，需要用到大规模图存储和挖掘计算，之前主要基于自建的高可用 Neo4j 集群来保障相关应用，而在实时行为分析方面，需要一个支持日增 10 亿关系的图数据库，Neo4j 无法满足应用需求。

针对这个场景，前期我们主要使用 Dgraph，踩过很多坑并和 Dgraph 团队连线会议，在使用 Dgraph 半年后最终还是选择了更贴合我们需求的 Nebula Graph。具体的对比 Benchmark 已经有很多团队在论坛分享了，这里就不再赘述，主要分享一些技术指标和选型，以及很多小伙伴感兴趣的 Dgraph 对比使用经验。

技术指标

硬件

配置如下：

处理器：Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz 80(cores)
内存：DDR4，128G
存储：1.8T SSD
网络：万兆

Nebula Graph 部署 5 个节点，按官方建议 3 个 metad / 5 个 graphd / 5 个 storaged

软件

Nebula Graph 版本：V1.1.0
操作系统：CentOS Linux release 7.3.1611 (Core)

配置

主要调整的配置和 storage 相关
# 按照文档建议，配置内存的 3 分之 1
--rocksdb_block_cache=40960

# 参数配置减小内存使用
--enable_partitioned_index_filter=true
--max_edge_returned_per_vertex=100000

指标

目前安全行为图保存 3 个月行为，近 500 亿边，10 分钟聚合写入一次，日均写入点 3,000 万，日均写入边 5.5 亿，插入延时 <=20 ms。

读延时 <= 100 ms，业务侧接口读延时 <= 200 ms，部分超大请求 < 1 s

当前磁盘空间占用 600G * 5 左右

CPU 耗用 500% 左右，内存使用稳定在 60 G 左右

Dgraph 使用对比

目前来说原生分布式图数据库国内选型主要比对 Dgraph 和 Nebula Graph，前者我们使用半年，整体使用对比如下，这些都是我们踩过坑的地方。

就我们使用经验，Dgraph 设计理念很好，但是目前还不太满足我们业务需求，GraphQL 的原生支持还是有很大吸引力，但是存储结构决定容易 OOM（边存储也分组的话会优化很多，官方之前计划优化）；另外，采用自己编写的 badger 和 ristretto，目前最大的问题是从官方释放的使用案例来看，未经大规模数据场景验证，在我们实际使用中，大数据量和高 QPS 写入场景下容易出现崩溃和 OOM，且如果采用 SSD 存储海量数据，Dgraph 的磁盘放大和内存占用也需要优化。

如果没有高 QPS 写入，目前 Dgraph 还是值得一试，对于很多快速原型的场景，作为 GraphQL 原生图数据库使其非常适合做基于图的数据中台，这是目前的一个大趋势，它也上线了自己的云服务，业内标杆 TigerGraph 也在做相关探索，另外事务的完善支持也是它的优势，这块暂时用不到，所以没做相关评测。实测 Dgraph 在线写入并发不高或只是离线导入数据使用的情况下还是很稳定的，如果想借助它的高可用和事务功能，可以尝试下。

对比来说，Nebula Graph 很优秀，特别是工程化方面，体现在很多细节，可以看出开发团队在实际使用和实现上做较了较好的平衡：

1.支持手动控制数据平衡时机，自动固然很好，但是容易导致很多问题
2.控制内存占用（enable_partitioned_index_filter 优化和设置单次最大返回边数目），都放在内存固然快，但有时候也需要考虑数据量和性能的平衡
3.多图物理隔离，多张图实在太有必要
4.nGQL 最大程度接近最常用 MySQL 语句，2 期兼容 Cypher 更加完美；对比 GraphQL 固然香，但写起复杂图查询真的让人想爆炸，可能还是更加适合做数据中台查询语言
5.和图计算框架的结合，最近释放的 Spark GraphX 结合算法非常有用，原先我们的图计算都是基于 GraphX 从 Neo4j 抽取后离线计算团伙，后续打算尝试 Nebula Graph 抽取

这里主要从实际经验对比分享，二者都在持续优化，都在快速迭代，建议使用前多看看最新版本 release 说明。

建议

当前 Nebula Graph 做得很优秀，结合我们现在的需求也提一点点建议：

1.更多离线算法，包括：现有的图神经网络这块的支持，图在线查询多用在分析，真正线上应用目前很多还是图计算离线算完后入库供查询
2.Plato 框架的合并支持，Spark GraphX 相对计算效率还是低一些，如果能整合腾讯的 Plato 框架更好
3.借鉴 TigerGraph 和 Dgraph，支持固化 nGQL 查询语句直接生成服务 REST 端点，HTTP 传入参数即可查询，这样可快速生成数据查询接口，不用后台再单独连接数据库写 SQL 提供数据服务

目前 Boss 直聘将 Nebula Graph 图数据库应用在安全业务，相关应用已经线上稳定运行大半年，本文分享了一点经验，抛砖引玉，期望更多技术伙伴来挖掘 Nebula 这座宝库。

Dgraph 遇到的一些问题，供有需要小伙伴参考

给 Dgraph 一些 issues
给 Dgraph 提交的 PRs

参考文章

360 的 JanusGraph 到 Nebula Graph 数据迁移

本文系 Boss 直聘·安全技术中心文洲撰写

Spark Connector Reader 原理与实践

NebulaGraph — Thu, 17 Dec 2020 16:00:29 +0800

本文主要讲述如何利用 Spark Connector 进行 Nebula Graph 数据的读取。

Spark Connector 简介

Spark Connector 是一个 Spark 的数据连接器，可以通过该连接器进行外部数据系统的读写操作，Spark Connector 包含两部分，分别是 Reader 和 Writer，而本文侧重介绍 Spark Connector Reader，Writer 部分将在下篇和大家详聊。

Spark Connector Reader 原理

Spark Connector Reader 是将 Nebula Graph 作为 Spark 的扩展数据源，从 Nebula Graph 中将数据读成 DataFrame，再进行后续的 map、reduce 等操作。

Spark SQL 允许用户自定义数据源，支持对外部数据源进行扩展。通过 Spark SQL 读取的数据格式是以命名列方式组织的分布式数据集 DataFrame，Spark SQL 本身也提供了众多 API 方便用户对 DataFrame 进行计算和转换，能对多种数据源使用 DataFrame 接口。

Spark 调用外部数据源包的是 org.apache.spark.sql，首先了解下 Spark SQL 提供的的扩展数据源相关的接口。

Basic Interfaces

BaseRelation：表示具有已知 Schema 的元组集合。所有继承 BaseRelation 的子类都必须生成 StructType 格式的 Schema。换句话说，BaseRelation 定义了从数据源中读取的数据在 Spark SQL 的 DataFrame 中存储的数据格式的。
RelationProvider：获取参数列表，根据给定的参数返回一个新的 BaseRelation。
DataSourceRegister：注册数据源的简写，在使用数据源时不用写数据源的全限定类名，而只需要写自定义的 shortName 即可。

Providers

RelationProvider：从指定数据源中生成自定义的 relation。 createRelation() 会基于给定的 Params 参数生成新的 relation。
SchemaRelationProvider：可以基于给定的 Params 参数和给定的 Schema 信息生成新的 Relation。

RDD

RDD[InternalRow]: 从数据源中 Scan 出来后需要构造成 RDD[Row]

要实现自定义 Spark 外部数据源，需要根据数据源自定义上述部分方法。

在 Nebula Graph 的 Spark Connector 中，我们实现了将 Nebula Graph 作为 Spark SQL 的外部数据源，通过 sparkSession.read 形式进行数据的读取。该功能实现的类图展示如下：

定义数据源 NebulaRelatioProvider，继承 RelationProvider 进行 relation 自定义，继承 DataSourceRegister 进行外部数据源的注册。
定义 NebulaRelation 定义 Nebula Graph 的数据 Schema 和数据转换方法。在 getSchema() 方法中连接 Nebula Graph 的 Meta 服务获取配置的返回字段对应的 Schema 信息。
定义 NebulaRDD 进行 Nebula Graph 数据的读取。 compute() 方法中定义如何读取 Nebula Graph 数据，主要涉及到进行 Nebula Graph 数据 Scan、将读到的 Nebula Graph Row 数据转换为 Spark 的 InternalRow 数据，以 InternalRow 组成 RDD 的一行，其中每一个 InternalRow 表示 Nebula Graph 中的一行数据，最终通过分区迭代的形式将 Nebula Graph 所有数据读出组装成最终的 DataFrame 结果数据。

Spark Connector Reader 实践

Spark Connector 的 Reader 功能提供了一个接口供用户编程进行数据读取。一次读取一个点/边类型的数据，读取结果为 DataFrame。

下面开始实践，拉取 GitHub 上 Spark Connector 代码：

git clone -b v1.0 git@github.com:vesoft-inc/nebula-java.git
cd nebula-java/tools/nebula-spark
mvn clean compile package install -Dgpg.skip -Dmaven.javadoc.skip=true

将编译打成的包 copy 到本地 Maven 库。

应用示例如下：

在 mvn 项目的 pom 文件中加入 nebula-spark 依赖

<dependency>
  <groupId>com.vesoft</groupId>
  <artifactId>nebula-spark</artifactId>
  <version>1.1.0</version>
</dependency>

在 Spark 程序中读取 Nebula Graph 数据：

// 读取 Nebula Graph 点数据
val vertexDataset: Dataset[Row] =
      spark.read
        .nebula("127.0.0.1:45500", "spaceName", "100")
        .loadVerticesToDF("tag", "field1,field2")
vertexDataset.show()

// 读取 Nebula Graph 边数据
val edgeDataset: Dataset[Row] =
      spark.read
        .nebula("127.0.0.1:45500", "spaceName", "100")
        .loadEdgesToDF("edge", "*")
edgeDataset.show()

配置说明：

nebula(address: String, space: String, partitionNum: String)

address：可以配置多个地址，以英文逗号分割，如“ip1:45500,ip2:45500”
space: Nebula Graph 的 graphSpace
partitionNum： 设定spark读取Nebula时的partition数，尽量使用创建 Space 时指定的 Nebula Graph 中的 partitionNum，可确保一个Spark的partition读取Nebula Graph一个part的数据。

loadVertices(tag: String, fields: String)

tag：Nebula Graph 中点的 Tag
fields：该 Tag 中的字段，，多字段名以英文逗号分隔。表示只读取 fields 中的字段，* 表示读取全部字段

loadEdges(edge: String, fields: String)

edge：Nebula Graph 中边的 Edge
fields：该 Edge 中的字段，多字段名以英文逗号分隔。表示只读取 fields 中的字段，* 表示读取全部字段

其他

Spark Connector Reader 的 GitHub 代码：https://github.com/vesoft-inc/nebula-java/tree/master/tools/nebula-spark

在此特别感谢半云科技所贡献的 Spark Connector 的 Java 版本

参考资料

[1] Extending Spark Datasource API: write a custom spark datasource [2] spark external datasource source code

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

记一起由 Clang 编译器优化触发的 Crash

NebulaGraph — Thu, 10 Dec 2020 09:58:39 +0800

摘要：一个有意思的 Crash 探究过程，Clang 有 GCC 没有

本文首发于 Nebula Graph 官方博客：https://nebula-graph.com.cn/posts/troubleshooting-crash-clang-compiler-optimization/

如果有人告诉你，下面的 C++ 函数会导致程序 crash，你会想到哪些原因呢？

std::string b2s(bool b) {
    return b ? "true" : "false";
}

如果再多给一些描述，比如：

Crash 以一定的概率复现
Crash 原因是段错误（SIGSEGV）
现场的 Backtrace 经常是不完整甚至完全丢失的。
只有优化级别在 -O2 以上才会（更容易）复现
仅在 Clang 下复现，GCC 复现不了

好了，一些老鸟可能已经有线索了，下面给出一个最小化的复现程序和步骤：

// file crash.cpp
#include <iostream>
#include <string>

std::string __attribute__((noinline)) b2s(bool b) {
    return b ? "true" : "false";
}

union {
    unsigned char c;
    bool b;
} volatile u;

int main() {
    u.c = 0x80;
    std::cout << b2s(u.b) << std::endl;
    return 0;
}

$ clang++ -O2 crash.cpp
$ ./a.out
truefalse,d$x4DdzRx

Segmentation fault (core dumped)

$ gdb ./a.out core.3699
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000012cfffff0d4 in ?? ()
(gdb) bt
#0  0x0000012cfffff0d4 in ?? ()
#1  0x00000064fffff0f4 in ?? ()
#2  0x00000078fffff124 in ?? ()
#3  0x000000b4fffff1e4 in ?? ()
#4  0x000000fcfffff234 in ?? ()
#5  0x00000144fffff2f4 in ?? ()
#6  0x0000018cfffff364 in ?? ()
#7  0x0000000000000014 in ?? ()
#8  0x0110780100527a01 in ?? ()
#9  0x0000019008070c1b in ?? ()
#10 0x0000001c00000010 in ?? ()
#11 0x0000002ffffff088 in ?? ()
#12 0xe2ab001010074400 in ?? ()
#13 0x0000000000000000 in ?? ()

因为 backtrace 信息不完整，说明程序并不是在第一时间 crash 的。面对这种情况，为了快速找出第一现场，我们可以试试 AddressSanitizer（ASan）：

$ clang++ -g -O2 -fno-omit-frame-pointer -fsanitize=address crash.cpp
$ ./a.out
=================================================================
==3699==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000552805 at pc 0x0000004ff83a bp 0x7ffd7610d240 sp 0x7ffd7610c9f0
READ of size 133 at 0x000000552805 thread T0
    #0 0x4ff839 in __asan_memcpy (a.out+0x4ff839)
    #1 0x5390a7 in b2s[abi:cxx11](bool) crash.cpp:6
    #2 0x5391be in main crash.cpp:16:18
    #3 0x7faed604df42 in __libc_start_main (/usr/lib64/libc.so.6+0x23f42)
    #4 0x41c43d in _start (a.out+0x41c43d)

0x000000552805 is located 59 bytes to the left of global variable '<string literal>' defined in 'crash.cpp:6:25' (0x552840) of size 6
  '<string literal>' is ascii string 'false'
0x000000552805 is located 0 bytes to the right of global variable '<string literal>' defined in 'crash.cpp:6:16' (0x552800) of size 5
  '<string literal>' is ascii string 'true'
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/dutor.hou/Wdir/nebula-graph/build/bug/a.out+0x4ff839) in __asan_memcpy
Shadow bytes around the buggy address:
…
...

从 ASan 给出的信息，我们可以定位到是函数 b2s(bool) 在读取字符串常量 "true" 的时候，发生了“全局缓冲区溢出”。好了，我们再次以上帝视角审视一下问题函数和复现程序，“似乎”可以得出结论：因为 b2s 的布尔类型参数 b 没有初始化，所以 b 中存储的是一个 0 和 1 之外的值 [1]。那么问题来了，为什么 b 的这种取值会导致“缓冲区溢出”呢？感兴趣的可以将 b 的类型由 bool 改成 char 或者 int，问题就可以得到修复。

想要解答这个问题，我们不得不看下 clang++ 为 b2s 生成了怎样的指令（之前我们提到 GCC 下没有出现 crash，所以问题可能和代码生成有关）。在此之前，我们应该了解：

样例程序中，b2s 的返回值是一个临时的 std::string 对象，是保存在栈上的
C++ 11 之后，GCC 的 std::string 默认实现使用了 SBO（Small Buffer Optimization），其定义大致为 std::string{ char *ptr; size_t size; union{ char buf[16]; size_t capacity}; }。对于长度小于 16 的字符串，不需要额外申请内存。

OK，那我们现在来看一下 b2s 的反汇编并给出关键注解：

(gdb) disas b2s
Dump of assembler code for function b2s[abi:cxx11](bool):
   0x00401200 <+0>:     push   %r14
   0x00401202 <+2>:     push   %rbx
   0x00401203 <+3>:     push   %rax
   0x00401204 <+4>:     mov    %rdi,%r14         # 将返回值(string)的起始地址保存到 r14
   0x00401207 <+7>:     mov    $0x402010,%ecx    # 将 "true" 的起始地址保存至 ecx
   0x0040120c <+12>:    mov    $0x402015,%eax    # 将 "false" 的起始地址保存至 eax
   0x00401211 <+17>:    test   %esi,%esi         # “测试” 参数 b 是否非零
   0x00401213 <+19>:    cmovne %rcx,%rax         # 如果 b 非零，则将 "true" 地址保存至 rax
   0x00401217 <+23>:    lea    0x10(%rdi),%rdi   # 将 string 中的 buf 起始地址保存至 rdi
                                                 # （同时也是后面 memcpy 的第一个参数）
   0x0040121b <+27>:    mov    %rdi,(%r14)       # 将 rdi 保存至 string 的 ptr 字段，即 SBO
   0x0040121e <+30>:    mov    %esi,%ebx         # 将 b 的值保存至 ebx
   0x00401220 <+32>:    xor    $0x5,%rbx         # 将 0x5 异或到 rbx（也即 ebx）
                                                 # 注意，如果 rbx 非 0 即 1，那么 rbx 保存的就是 4 或 5，
                                                 # 即 "true" 或 "false" 的长度 
   0x00401224 <+36>:    mov    %rax,%rsi         # 将字符串起始地址保存至 rsi，即 memcpy 的第二个参数
   0x00401227 <+39>:    mov    %rbx,%rdx         # 将字符串的长度保存至 rdx，即 memcpy 的第三个参数
   0x0040122a <+42>:    callq  <memcpy@plt>      # 调用 memcpy
   0x0040122f <+47>:    mov    %rbx,0x8(%r14)    # 将字符串长度保存到 string::size
   0x00401233 <+51>:    movb   $0x0,0x10(%r14,%rbx,1)  # 将 string 以 '\0' 结尾
   0x00401239 <+57>:    mov    %r14,%rax         # 将 string 地址保存至 rax，即返回值
   0x0040123c <+60>:    add    $0x8,%rsp
   0x00401240 <+64>:    pop    %rbx
   0x00401241 <+65>:    pop    %r14
   0x00401243 <+67>:    retq
End of assembler dump.

到这里，问题就无比清晰了：

clang++ 假设了 bool 类型的值非 0 即 1
在编译期，”true” 和 ”false” 长度已知
使用异或指令（ 0x5 ^ false == 5, 0x5 ^ true == 4）计算要拷贝的字符串的长度
当 bool 类型不符合假设时，长度计算错误
因为 memcpy 目标地址在栈上（仅对本例而言），因此栈上的缓冲区也可能溢出，从而导致程序跑飞，backtrace 缺失。

注：

C++ 标准要求 bool 类型至少能够表示两个状态： true 和 false ，但并没有规定 sizeof(bool) 的大小。但在几乎所有的编译器实现上， bool 都占用一个寻址单位，即字节。因此，从存储角度，取值范围为 0x00-0xFF，即 256 个状态。

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

GraphX 在图数据库 Nebula Graph 的图计算实践

NebulaGraph — Wed, 11 Nov 2020 18:12:19 +0800

不同来源的异构数据间存在着千丝万缕的关联，这种数据之间隐藏的关联关系和网络结构特性对于数据分析至关重要，图计算就是以图作为数据模型来表达问题并予以解决的过程。

一、背景

随着网络信息技术的飞速发展，数据逐渐向多源异构化方向发展，且不同来源的异构数据之间也存在的千丝万缕的关联，这种数据之间隐藏的关联关系和网络结构特性对于数据分析至关重要。但传统关系型数据库在分析大规模数据关联特性时存在性能缺陷、表达有限等问题，因此有着更强大表达能力的图数据受到业界极大重视，图计算就是以图作为数据模型来表达问题并予以解决的过程。图可以融合多源多类型的数据，除了可以展示数据静态基础特性之外，还可通过图计算展示隐藏在数据之间的图结构特性和点对关联关系，成为社交网络、推荐系统、知识图谱、金融风控、网络安全、文本检索等领域重要的分析手段。

二、算法应用

为了支撑大规模图计算的业务需求，Nebula Graph 基于 GraphX 提供了 PageRank 和 Louvain 社区发现的图计算算法，允许用户通过提交 Spark 任务的形式执行算法应用。此外，用户也可以通过 Spark Connector 编写 Spark 程序调用 GraphX 自带的其他图算法，如 LabelPropagation、ConnectedComponent 等。

PageRank

PageRank 是谷歌提出的用于解决链接分析中网页排名问题的算法，目的是为了对互联网中数以亿计的网页进行排名。

PageRank 简介

美国斯坦福大学的 Larry Page 和 Sergey Brin 在研究网页排序问题时采用学术界评判论文重要性的方法，即看论文的引用量以及引用该论文的论文质量，对应于网页的重要性有两个假设：

数量假设：如果一个网页 A 被很多其他网页链接到，则该网页比较重要；
质量假设：如果一个很重要的网页链接到网页 A，则该网页的重要性会被提高。

并基于这两个假设提出 PageRank 算法。

PageRank 应用场景

社交应用的相似度内容推荐

在对微博、微信等社交平台进行社交网络分析时，可以基于 PageRank 算法根据用户通常浏览的信息以及停留时间实现基于用户的相似度的内容推荐；

分析用户社交影响力

在社交网络分析时根据用户的 PageRank 值进行用户影响力分析；

文献重要性研究

根据文献的 PageRank 值评判该文献的质量，PageRank 算法就是基于评判文献质量的想法来实现设计。

此外 PageRank 在数据分析和挖掘中也有很多的应用。

算法思路

GraphX 的 PageRank 算法是基于 Pregel 计算模型的，该算法流程包括 3 步骤：

为图中每个节点（网页）设置一个同样的初始 PageRank 值；
第一次迭代：沿边发送消息，每个节点收到所有关联边上对点的信息，得到一个新的 PageRank 值；
第二次迭代：用这组新的 PageRank 按不同算法模式对应的公式形成节点自己新的 PageRank。

Louvain 社区发现

Louvain 是用来进行社会网络挖掘的社区发现算法，属于图的聚类算法。

Louvain 算法介绍

Louvain 是基于模块度（Modularity）的社区发现算法，通过模块度来衡量一个社区的紧密程度。如果一个节点加入到某一社区中会使得该社区的模块度相比其他社区有最大程度的增加，则该节点就应当属于该社区。如果加入其它社区后没有使其模块度增加，则留在自己当前社区中。

模块度

模块度公式

模块度 Q 的物理意义：社区内节点的连边数与随机情况下的边数之差，定义函数如下：

其中

：节点 i 和节点 j 之间边的权重：所有与节点 i 相连的边的权重之和：节点 i 所属的社区：图中所有边的权重之和

模块度公式变形

在此公式中，只有节点 i 和节点 j 属于同一社区，公式才有意义，所以该公式是衡量的某一社区内的紧密度。对于该公式的简化变形如下：

表示：社区 c 内的边的权重之和表示：所有与社区 c 内节点相连的边的权重之和（因为 i 属于社区 c）包括社区内节点与节点 i 的边和社区外节点与节点 i 的边。表示：所有与社区 c 内节点相连的边的权重之和（因为 j 属于社区 c）包括社区内节点与节点 j 的边和社区外节点与节点 j 的边。代替和。（即社区 c 内边权重和 + 社区 c 与其他社区连边的权重和）

求解模块度变化

在 Louvain 算法中不需要求每个社区具体的模块度，只需要比较社区中加入某个节点之后的模块度变化，所以需要求解 △Q。

将节点 i 分配到某一社区中，社区的模块度变化为：

其中

：社区内所有节点与节点 i 连边权重之和（对应新社区的实际内部权重和乘以 2，因为对于社区内所有的顶点 i，每条边其实被计算了两次）：所有与节点 i 相连的边的权重之和故实现算法时只需求即可。

Louvain 应用场景

金融风控

在金融风控场景中，可以根据用户行为特征进行团伙识别；

社交网络

可以基于网络关系中点对之间关联的广度和强度进行社交网络划分；对复杂网络分析、电话网络分析人群之间的联系密切度；

推荐系统

基于用户兴趣爱好的社区发现，可以根据社区并结合协同过滤等推荐算法进行更精确有效的个性化推荐。

Louvain 算法思路

Louvain 算法包括两个阶段，其流程就是这两个阶段的迭代过程。

阶段一：不断地遍历网络图中的节点，通过比较节点给每个邻居社区带来的模块度的变化，将单个节点加入到能够使 Modularity 模块度有最大增量的社区中。（比如节点 v 分别加入到社区 A、B、C 中，使得三个社区的模块度增量为 -1，1，2，则节点 v 最终应该加入到社区 C 中）

阶段二：对第一阶段进行处理，将属于同一社区的顶点合并为一个大的超点重新构造网络图，即一个社区作为图的一个新的节点。此时两个超点之间边的权重是两个超点内所有原始顶点之间相连的边权重之和，即两个社区之间的边权重之和。

下面是对第一二阶段的实例介绍。

第一阶段遍历图中节点加入到其所属社区中，得到中间的图，形成四个社区；

第二节点对社区内的节点进行合并成一个超级节点，社区节点有自连边，其权重为社区内部所有节点间相连的边的权重之和的 2 倍，社区之间的边为两个社区间顶点跨社区相连的边的权重之和，如红色社区和浅绿色社区之间通过（8,11）、（10，11）、（10,13）相连，所以两个社区之间边的权重为 3。

注：社区内的权重为所有内部结点之间边权重的两倍，因为 Kin 的概念是社区内所有节点与节点 i 的连边和，在计算某一社区的 Kin 时，实际上每条边都被其两端的顶点计算了一次，一共被计算了两次。

整个 Louvain 算法就是不断迭代第一阶段和第二阶段，直到算法稳定（图的模块度不再变化）或者到达最大迭代次数。

三、算法实践

演示环境

三台虚拟机，环境如下：
- Cpu name: Intel(R) Xeon(R) Platinum 8260M CPU @ 2.30GHz
- Processors：32
- CPU Cores: 16
- Memory Size: 128G
软件环境
- Spark：spark-2.4.6-bin-hadoop2.7 三个节点集群
- yarn V2.10.0：三个节点集群
- Nebula Graph V1.1.0：分布式部署，默认配置

测试数据

创建图空间

CREATE SPACE algoTest(partition_num=100, replica_factor=1);

创建点边 Schema

CREATE TAG PERSON()
CREATE EDGE FRIEND(likeness double);

导入数据

利用 Exchange 工具将数据离线导入 Nebula Graph。

测试结果

Spark 任务的资源分配为 --driver-memory=20G --executor-memory=100G --executor-cores=3

PageRank 在一亿数据集上的执行时间为 21min（PageRank 算法执行时间）
Louvain 在一亿数据集上的执行时间为 1.3h（Reader + Louvain 算法执行时间）

如何使用 Nebula Graph 的算法

下载 nebula-algorithm 项目并打成 jar 包

$ git clone git@github.com:vesoft-inc/nebula-java.git
$ cd nebula-java/tools/nebula-algorithm
$ mvn package -DskipTests

配置项目中的 src/main/resources/application.conf

{
  # Spark relation config
  spark: {
    app: {
        # not required, default name is the algorithm that you are going to execute.
        name: PageRank

        # not required
        partitionNum: 12
    }

    master: local

    # not required
    conf: {
        driver-memory: 8g
        executor-memory: 8g
        executor-cores: 1g
        cores-max:6
    }
  }

  # Nebula Graph relation config
  nebula: {
    # metadata server address
    addresses: "127.0.0.1:45500"
    user: root
    pswd: nebula
    space: algoTest
    # partition specified while creating nebula space, if you didn't specified the partition, then it's 100.
    partitionNumber: 100
    # nebula edge type
    labels: ["FRIEND"]

    hasWeight: true
    # if hasWeight is true，then weightCols is required， and weghtCols' order must be corresponding with labels.
    # Noted: the graph algorithm only supports isomorphic graphs,
    #        so the data type of each col in weightCols must be consistent and all numeric types.
    weightCols: [“likeness”]
  }

  algorithm: {
    # the algorithm that you are going to execute，pick one from [pagerank, louvain]
    executeAlgo: louvain
    # algorithm result path
    path: /tmp

    # pagerank parameter
    pagerank: {
        maxIter: 20
        resetProb: 0.15  # default 0.15

    }

    # louvain parameter
    louvain: {
        maxIter: 20
        internalIter: 10
        tol: 0.5
   }
  }
}

确保用户环境已安装 Spark 并启动 Spark 服务
提交 nebula-algorithm 应用程序：

spark-submit --master xxx --class com.vesoft.nebula.tools.algorithm.Main /your-jar-path/nebula-algorithm-1.0.1.jar -p /your-application.conf-path/application.conf

如果你对上述内容感兴趣，欢迎用 nebula-algorithm 试试^^

References

Nebula Graph:https://github.com/vesoft-inc/nebula
GraphX：https://github.com/apache/spark/tree/master/graphx
Spark-connector：https://github.com/vesoft-inc/nebula-java/tree/master/tools/nebula-spark
Exchange：https://github.com/vesoft-inc/nebula-java/blob/master/doc/tools/exchange/ex-ug-toc.md
nebula-algorithm：https://github.com/vesoft-inc/nebula-java/tree/master/tools/nebula-algorithm

作者有话说：Hi，我是安祺，Nebula Graph 研发工程师，如果你对本文有任何疑问，欢迎来论坛和我交流：https://discuss.nebula-graph.com.cn/

调试 Docker 容器内部进程

NebulaGraph — Wed, 28 Oct 2020 11:47:02 +0800

首发于官方博客：https://nebula-graph.com.cn/posts/debug-nebula-graph-processes-docker/

摘要：本文以 Nebula Graph 进程为例，讲解如何不破坏原有容器的内容，也不用在其中安装任何的工具包前提下，像在本地一样来调试进程

需求

在开发或者测试过程中，我们经常会用到 vesoft-inc/nebula-docker-compose 这个 repo 下的部署方式，因为当初为了尽可能的压缩每个 Nebula Graph 服务的 docker 镜像的体积，所以开发过程中常用的一切工具都没有安装，甚至连编辑器 VIM 都没有。

这给我们在容器内部定位问题带来一定的难度，因为每次只能去 install 一些工具包，才能开展接下来的工作，甚是费事。其实调试容器内部的进程还有另外一种方式，不需要破坏原有容器的内容，也不用在其中安装任何的工具包就能像在本地一样来调试。

这种技术在 k8s 环境下其实已经挺常用，就是 sidecar 模式。原理也比较朴素就是再起一个容器然后让这个容器跟你要调试的容器共享相同的 pid/network 的 namespace。这样原容器中的进程和网络空间在调试容器中就能“一览无余”，而在调试容器中安装了你想要的一切顺手工具，接下来的舞台就是留于你发挥了。

演示

接下来我就演示一下如何操作：

我们先用上述的 docker-compose 方式在本地部署一套 Nebula Graph 集群，教程见 repo 中的 README。部署好后的结果如下：

$ docker-compose up -d
Creating network "nebula-docker-compose_nebula-net" with the default driver
Creating nebula-docker-compose_metad1_1 ... done
Creating nebula-docker-compose_metad2_1 ... done
Creating nebula-docker-compose_metad0_1 ... done
Creating nebula-docker-compose_storaged2_1 ... done
Creating nebula-docker-compose_storaged1_1 ... done
Creating nebula-docker-compose_storaged0_1 ... done
Creating nebula-docker-compose_graphd_1    ... done
$ docker-compose ps
              Name                             Command                       State                                             Ports
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
nebula-docker-compose_graphd_1      ./bin/nebula-graphd --flag ...   Up (health: starting)   0.0.0.0:32907->13000/tcp, 0.0.0.0:32906->13002/tcp, 0.0.0.0:3699->3699/tcp
nebula-docker-compose_metad0_1      ./bin/nebula-metad --flagf ...   Up (health: starting)   0.0.0.0:32898->11000/tcp, 0.0.0.0:32896->11002/tcp, 45500/tcp, 45501/tcp
nebula-docker-compose_metad1_1      ./bin/nebula-metad --flagf ...   Up (health: starting)   0.0.0.0:32895->11000/tcp, 0.0.0.0:32894->11002/tcp, 45500/tcp, 45501/tcp
nebula-docker-compose_metad2_1      ./bin/nebula-metad --flagf ...   Up (health: starting)   0.0.0.0:32899->11000/tcp, 0.0.0.0:32897->11002/tcp, 45500/tcp, 45501/tcp
nebula-docker-compose_storaged0_1   ./bin/nebula-storaged --fl ...   Up (health: starting)   0.0.0.0:32901->12000/tcp, 0.0.0.0:32900->12002/tcp, 44500/tcp, 44501/tcp
nebula-docker-compose_storaged1_1   ./bin/nebula-storaged --fl ...   Up (health: starting)   0.0.0.0:32903->12000/tcp, 0.0.0.0:32902->12002/tcp, 44500/tcp, 44501/tcp
nebula-docker-compose_storaged2_1   ./bin/nebula-storaged --fl ...   Up (health: starting)   0.0.0.0:32905->12000/tcp, 0.0.0.0:32904->12002/tcp, 44500/tcp, 44501/tcp

这时我们分两个场景来演示，一个是进程空间，一个是网络空间。首先我们要先有一个顺手的调试镜像，我们就不自己构建了，从 docker hub 中找个已经打包好的用作演示，后期觉得不够用，我们可以维护一份 nebula-debug 的镜像，安装我们想要的所有调试工具，此处先借用社区内的方案 nicolaka/netshoot。我们先把镜像拉取到本地：

$ docker pull nicolaka/netshoot
$ docker images
REPOSITORY               TAG                 IMAGE ID            CREATED             SIZE
vesoft/nebula-graphd     nightly             c67fe54665b7        36 hours ago        282MB
vesoft/nebula-storaged   nightly             5c77dbcdc507        36 hours ago        288MB
vesoft/nebula-console    nightly             f3256c99eda1        36 hours ago        249MB
vesoft/nebula-metad      nightly             5a78d3e3008f        36 hours ago        288MB
nicolaka/netshoot        latest              6d7e8891c980        2 months ago        352MB

我们先看看直接执行这个镜像会是什么样：

$ docker run --rm -ti nicolaka/netshoot bash
bash-5.0# ps
PID   USER     TIME  COMMAND
    1 root      0:00 bash
    8 root      0:00 ps
bash-5.0#

上面显示这个容器看不到任何 Nebula Graph 服务进程的内容，那么我们给其加点参数再看看：

$ docker run --rm -ti --pid container:nebula-docker-compose_metad0_1 --cap-add sys_admin nicolaka/netshoot bash
bash-5.0# ps
PID   USER     TIME  COMMAND
    1 root      0:03 ./bin/nebula-metad --flagfile=./etc/nebula-metad.conf --daemonize=false --meta_server_addrs=172.28.1.1:45500,172.28.1.2:45500,172.28.1.3:45500 --local_ip=172.28.1.1 --ws_ip=172.28.1.1 --port=45500 --data_path=/data/meta --log_dir=/logs --v=15 --minloglevel=0
  452 root      0:00 bash
  459 root      0:00 ps
bash-5.0# ls -al /proc/1/net/
total 0
dr-xr-xr-x    6 root     root             0 Sep 18 07:17 .
dr-xr-xr-x    9 root     root             0 Sep 18 06:55 ..
-r--r--r--    1 root     root             0 Sep 18 07:18 anycast6
-r--r--r--    1 root     root             0 Sep 18 07:18 arp
dr-xr-xr-x    2 root     root             0 Sep 18 07:18 bonding
-r--r--r--    1 root     root             0 Sep 18 07:18 dev
...
-r--r--r--    1 root     root             0 Sep 18 07:18 sockstat
-r--r--r--    1 root     root             0 Sep 18 07:18 sockstat6
-r--r--r--    1 root     root             0 Sep 18 07:18 softnet_stat
dr-xr-xr-x    2 root     root             0 Sep 18 07:18 stat
-r--r--r--    1 root     root             0 Sep 18 07:18 tcp
-r--r--r--    1 root     root             0 Sep 18 07:18 tcp6
-r--r--r--    1 root     root             0 Sep 18 07:18 udp
-r--r--r--    1 root     root             0 Sep 18 07:18 udp6
-r--r--r--    1 root     root             0 Sep 18 07:18 udplite
-r--r--r--    1 root     root             0 Sep 18 07:18 udplite6
-r--r--r--    1 root     root             0 Sep 18 07:18 unix
-r--r--r--    1 root     root             0 Sep 18 07:18 xfrm_stat

这次有点不一样了，我们看到 metad0 的进程了，并且其 pid 还是 1。看到这个进程再想对其做点啥就好办了，比如能不能直接在 gdb 中 attach 它，由于手边没有带 nebula binary 的对应 image，就留给大家私下探索吧。

我们已经看到 pid 空间通过指定 --pid container:<container_name|id> 可以共享了，那么我们接下来看看网络的情况，毕竟有时候需要抓个包，执行如下的命令：

bash-5.0# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

啥也没有，跟预想的有点不一样，我们有 metad0 这个进程不可能一个连接都没有。要想看到这个容器内的网络空间还要再加点参数，像如下方式再启动调试容器：

$ docker run --rm -ti --pid container:nebula-docker-compose_metad0_1 --network container:nebula-docker-compose_metad0_1 --cap-add sys_admin nicolaka/netshoot bash
bash-5.0# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 172.28.1.1:11000        0.0.0.0:*               LISTEN      -
tcp        0      0 172.28.1.1:11002        0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:45500           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:45501           0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.11:33249        0.0.0.0:*               LISTEN      -
udp        0      0 127.0.0.11:51929        0.0.0.0:*                           -

这回就跟上面的输出不一样了，加了 --network container:nebula-docker-compose_metad0_1 运行参数后，metad0 容器内的连接情况也能看到了，那么想抓包调试就都可以了。

总结

通过运行另外一个容器，并让其跟想要调试的容器共享 pid/network namespace 是我们能像本地调试的关键。社区里甚至还有人基于上述想法开发了一些小工具进一步方便使用：

Docker-debug

主流开源分布式图数据库 Benchmark

NebulaGraph — Wed, 21 Oct 2020 10:47:59 +0800

本文由美团 NLP 团队高辰、赵登昌撰写首发于 Nebula Graph 官方论坛：https://discuss.nebula-graph.com.cn/t/topic/1377

1. 前言

近年来，深度学习和知识图谱技术发展迅速，相比于深度学习的“黑盒子”，知识图谱具有很强的可解释性，在搜索推荐、智能助理、金融风控等场景中有着广泛的应用。美团基于积累的海量业务数据，结合使用场景进行充分地挖掘关联，逐步建立起包括美食图谱、旅游图谱、商品图谱在内的近十个领域知识图谱，并在多业务场景落地，助力本地生活服务的智能化。

为了高效存储并检索图谱数据，相比传统关系型数据库，选择图数据库作为存储引擎，在多跳查询上具有明显的性能优势。当前业界知名的图数据库产品有数十款，选型一款能够满足美团实际业务需求的图数据库产品，是建设图存储和图学习平台的基础。我们结合业务现状，制定了选型的基本条件：

开源项目，对商业应用友好
- 拥有对源代码的控制力，才能保证数据安全和服务可用性。
支持集群模式，具备存储和计算的横向扩展能力
- 美团图谱业务数据量可以达到千亿以上点边总数，吞吐量可达到数万 qps，单节点部署无法满足存储需求。
能够服务 OLTP 场景，具备毫秒级多跳查询能力
- 美团搜索场景下，为确保用户搜索体验，各链路的超时时间具有严格限制，不能接受秒级以上的查询响应时间。
具备批量导入数据能力
- 图谱数据一般存储在 Hive 等数据仓库中。必须有快速将数据导入到图存储的手段，服务的时效性才能得到保证。

我们试用了 DB-Engines 网站上排名前 30 的图数据库产品，发现多数知名的图数据库开源版本只支持单节点，不能横向扩展存储，无法满足大规模图谱数据的存储需求，例如：Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。经过调研比较，最终纳入评测范围的产品为：NebulaGraph（原阿里巴巴团队创业开发）、Dgraph（原 Google 团队创业开发）、HugeGraph（百度团队开发）。

2. 测试概要

2.1 硬件配置

数据库实例：运行在不同物理机上的 Docker 容器。
单实例资源：32 核心，64GB 内存，1TB SSD 存储。【Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz】
实例数量：3

2.2 部署方案

Nebula v1.0.1

Metad 负责管理集群元数据，Graphd 负责执行查询，Storaged 负责数据分片存储。存储后端采用 RocksDB。

实例 1	实例 2	实例 3
Metad	Metad	Metad
Graphd	Graphd	Graphd
Storaged[RocksDB]	Storaged[RocksDB]	Storaged[RocksDB]

Dgraph v20.07.0

Zero 负责管理集群元数据，Alpha 负责执行查询和存储。存储后端为 Dgraph 自有实现。

实例 1	实例 2	实例 3
Zero	Zero	Zero
Alpha	Alpha	Alpha

HugeGraph v0.10.4

HugeServer 负责管理集群元数据和查询。HugeGraph 虽然支持 RocksDB 后端，但不支持 RocksDB 后端的集群部署，因此存储后端采用 HBase。

实例 1	实例 2	实例 3
HugeServer[HBase]	HugeServer[HBase]	HugeServer[HBase]
JournalNode	JournalNode	JournalNode
DataNode	DataNode	DataNode
NodeManager	NodeManager	NodeManager
RegionServer	RegionServer	RegionServer
ZooKeeper	ZooKeeper	ZooKeeper
NameNode	NameNode[Backup]	-
-	ResourceManager	ResourceManager[Backup]
HBase Master	HBase Master[Backup]	-

3. 评测数据集

社交图谱数据集：https://github.com/ldbc011
- 生成参数：branch=stable, version=0.3.3, scale=1000
- 实体情况：4 类实体，总数 26 亿
- 关系情况：19 类关系，总数 177 亿
- 数据格式：csv
- GZip 压缩后大小：194 G

4. 测试结果

4.1 批量数据导入

4.1.1 测试说明

批量导入的步骤为：Hive 仓库底层 csv 文件 -> 图数据库支持的中间文件 -> 图数据库。各图数据库具体导入方式如下：

Nebula：执行 Spark 任务，从数仓生成 RocksDB 的底层存储 sst 文件，然后执行 sst Ingest 操作插入数据。
Dgraph：执行 Spark 任务，从数仓生成三元组 rdf 文件，然后执行 bulk load 操作直接生成各节点的持久化文件。
HugeGraph：支持直接从数仓的 csv 文件导入数据，因此不需要数仓 - 中间文件的步骤。通过 loader 批量插入数据。

4.1.2 测试结果

4.1.3 数据分析

Nebula：数据存储分布方式是主键哈希，各节点存储分布基本均衡。导入速度最快，存储放大比最优。
Dgraph：原始 194G 数据在内存 392G 的机器上执行导入命令，8.7h 后 OOM 退出，无法导入全量数据。数据存储分布方式是三元组谓词，同一种关系只能保存在一个数据节点上，导致存储和计算严重偏斜。
HugeGraph：原始 194G 的数据执行导入命令，写满了一个节点 1,000G 的磁盘，造成导入失败，无法导入全量数据。存储放大比最差，同时存在严重的数据偏斜。

4.2 实时数据写入

4.2.1 测试说明

向图数据库插入点和边，测试实时写入和并发能力。
- 响应时间：固定的 50,000 条数据，以固定 qps 发出写请求，全部发送完毕即结束。取客户端从发出请求到收到响应的 Avg、p99、p999 耗时。
- 最大吞吐量：固定的 1,000,000 条数据，以递增 qps 发出写请求，Query 循环使用。取 1 分钟内成功请求的峰值 qps 为最大吞吐量。
插入点
- Nebula

INSERT VERTEX t_rich_node (creation_date, first_name, last_name, gender, birthday, location_ip, browser_used) VALUES ${mid}:('2012-07-18T01:16:17.119+0000', 'Rodrigo', 'Silva', 'female', '1984-10-11', '84.194.222.86', 'Firefox')

Dgraph

{
    set {
        <${mid}> <creation_date> "2012-07-18T01:16:17.119+0000" .
        <${mid}> <first_name> "Rodrigo" .
        <${mid}> <last_name> "Silva" .
        <${mid}> <gender> "female" .
        <${mid}> <birthday> "1984-10-11" .
        <${mid}> <location_ip> "84.194.222.86" .
        <${mid}> <browser_used> "Firefox" .
    }
}

HugeGraph

g.addVertex(T.label, "t_rich_node", T.id, ${mid}, "creation_date", "2012-07-18T01:16:17.119+0000", "first_name", "Rodrigo", "last_name", "Silva", "gender", "female", "birthday", "1984-10-11", "location_ip", "84.194.222.86", "browser_used", "Firefox")

插入边
- Nebula

INSERT EDGE t_edge () VALUES ${mid1}->${mid2}:();

Dgraph

{
    set {
        <${mid1}> <link> <${mid2}> .
    }
}

HugeGraph

g.V(${mid1}).as('src').V(${mid2}).addE('t_edge').from('src')

4.2.2 测试结果

实时写入

4.2.3 数据分析

Nebula：如 4.1.3 节分析所述，Nebula 的写入请求可以由多个存储节点分担，因此响应时间和吞吐量均大幅领先。
Dgraph：如 4.1.3 节分析所述，同一种关系只能保存在一个数据节点上，吞吐量较差。
HugeGraph：由于存储后端基于 HBase，实时并发读写能力低于 RocksDB（Nebula）和 BadgerDB（Dgraph），因此性能最差。

4.3 数据查询

4.3.1 测试说明

以常见的 N 跳查询返回 ID，N 跳查询返回属性，共同好友查询请求测试图数据库的读性能。
- 响应时间：固定的 50,000 条查询，以固定 qps 发出读请求，全部发送完毕即结束。取客户端从发出请求到收到响应的 Avg、p99、p999 耗时。
- 60s 内未返回结果为超时。
- 最大吞吐量：固定的 1,000,000 条查询，以递增 qps 发出读请求，Query 循环使用。取 1 分钟内成功请求的峰值 qps 为最大吞吐量。
- 缓存配置：参与测试的图数据库都具备读缓存机制，默认打开。每次测试前均重启服务清空缓存。
N 跳查询返回 ID
- Nebula

GO ${n} STEPS FROM ${mid} OVER person_knows_person

Dgraph

{
 q(func:uid(${mid})) {
   uid
   person_knows_person { #${n}跳数 = 嵌套层数
     uid
   }
 }
}

HugeGraph

g.V(${mid}).out().id() #${n}跳数 = out()链长度

N 跳查询返回属性
- Nebula

GO ${n} STEPS FROM ${mid} OVER person_knows_person YIELDperson_knows_person.creation_date, $$.person.first_name, $$.person.last_name, $$.person.gender, $$.person.birthday, $$.person.location_ip, $$.person.browser_used

Dgraph

{
  q(func:uid(${mid})) {
    uid first_name last_name gender birthday location_ip browser_used
    person_knows_person { #${n}跳数 = 嵌套层数
      uid first_name last_name gender birthday location_ip browser_used
    }
  }
}

HugeGraph

g.V(${mid}).out()  #${n}跳数 = out()链长度

共同好友查询语句
- Nebula

GO FROM ${mid1} OVER person_knows_person INTERSECT GO FROM ${mid2} OVER person_knows_person

Dgraph

{
  var(func: uid(${mid1})) {
    person_knows_person {
      M1 as uid
    }
  }
  var(func: uid(${mid2})) {
    person_knows_person {
      M2 as uid
    }
  }
  in_common(func: uid(M1)) @filter(uid(M2)){
    uid
  }
}

HugeGraph

g.V(${mid1}).out().id().aggregate('x').V(${mid2}).out().id().where(within('x')).dedup()

4.3.2 测试结果

N 跳查询返回 ID

N 跳查询返回属性

单个返回节点的属性平均大小为 200 Bytes。

共同好友本项未测试最大吞吐量。

4.3.3 数据分析

在 1 跳查询返回 ID「响应时间」实验中，Nebula 和 DGraph 都只需要进行一次出边搜索。由于 DGraph 的存储特性，相同关系存储在单个节点，1 跳查询不需要网络通信。而 Nebula 的实体分布在多个节点中，因此在实验中 DGraph 响应时间表现略优于 Nebula。
在 1 跳查询返回 ID「最大吞吐量」实验中，DGraph 集群节点的 CPU 负载主要落在存储关系的单节点上，造成集群 CPU 利用率低下，因此最大吞吐量仅有 Nebula 的 11%。
在 2 跳查询返回 ID「响应时间」实验中，由于上述原因，DGraph 在 qps=100 时已经接近了集群负载能力上限，因此响应时间大幅变慢，是 Nebula 的 3.9 倍。
在 1 跳查询返回属性实验中，Nebula 由于将实体的所有属性作为一个数据结构存储在单节点上，因此只需要进行【出边总数 Y】次搜索。而 DGraph 将实体的所有属性也视为出边，并且分布在不同节点上，需要进行【属性数量 X * 出边总数 Y】次出边搜索，因此查询性能比 Nebula 差。多跳查询同理。
在共同好友实验中，由于此实验基本等价于 2 次 1 跳查询返回 ID，因此测试结果接近，不再详述。
由于 HugeGraph 存储后端基于 HBase，实时并发读写能力低于 RocksDB（Nebula）和 BadgerDB（Dgraph），因此在多项实验中性能表现均落后于 Nebula 和 DGraph。

5. 结论

参与测试的图数据库中，Nebula 的批量导入可用性、导入速度、实时数据写入性能、数据多跳查询性能均优于竞品，因此我们最终选择了 Nebula 作为图存储引擎。

6. 参考资料

NebulaGraph Benchmark:https://discuss.nebula-graph.com.cn/t/topic/782
NebulaGraph Benchmark 微信团队：https://discuss.nebula-graph.com.cn/t/topic/1013
DGraph Benchmark:https://dgraph.io/blog/tags/benchmark/
HugeGraph Benchmark:https://hugegraph.github.io/hugegraph-doc/performance/hugegraph-benchmark-0.5.6.html
TigerGraph Benchmark:https://www.tigergraph.com/benchmark/
RedisGraph Benchmark:https://redislabs.com/blog/new-redisgraph-1-0-achieves-600x-faster-performance-graph-databases/

本次性能测试系美团 NLP 团队高辰、赵登昌撰写，如果你对本文有任意疑问，欢迎来原贴和作者交流：https://discuss.nebula-graph.com.cn/t/topic/1377

用 Docker swarm 快速部署分布式图数据库 Nebula Graph 集群

NebulaGraph — Wed, 14 Oct 2020 11:23:42 +0800

本文作者系：视野金服工程师｜吴海胜首发于 Nebula Graph 论坛：https://discuss.nebula-graph.com.cn/t/topic/1388

一、前言

本文介绍如何使用 Docker Swarm 来部署 Nebula Graph 集群，并部署客户端负载均衡和高可用。

二、nebula 集群搭建

2.1 环境准备

机器准备

ip	内存 (Gb)	cpu(核数)
192.168.1.166	16	4
192.168.1.167	16	4
192.168.1.168	16	4

在安装前确保所有机器已安装 Docker

2.2 初始化 swarm 集群

在 192.168.1.166 机器上执行

$ docker swarm init --advertise-addr 192.168.1.166
Swarm initialized: current node (dxn1zf6l61qsb1josjja83ngz) is now a manager.
To add a worker to this swarm, run the following command:
 docker swarm join \
 --token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
 192.168.1.166:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

2.3 加入 worker 节点

根据 init 命令提示内容，加入 swarm worker 节点，在 192.168.1.167 192.168.1.168 分别执行

docker swarm join \
 --token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
 192.168.1.166:2377

2.4 验证集群

docker node ls

ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
h0az2wzqetpwhl9ybu76yxaen *   KF2-DATA-166        Ready               Active              Reachable           18.06.1-ce
q6jripaolxsl7xqv3cmv5pxji     KF2-DATA-167        Ready               Active              Leader              18.06.1-ce
h1iql1uvm7123h3gon9so69dy     KF2-DATA-168        Ready               Active                                  18.06.1-ce

2.5 配置 docker stack

vi docker-stack.yml

配置如下内容

version: '3.6'
services:
  metad0:
    image: vesoft/nebula-metad:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --local_ip=192.168.1.166
      - --ws_ip=192.168.1.166
      - --port=45500
      - --data_path=/data/meta
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-166
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.166:11000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 11000
        published: 11000
        protocol: tcp
        mode: host
      - target: 11002
        published: 11002
        protocol: tcp
        mode: host
      - target: 45500
        published: 45500
        protocol: tcp
        mode: host
    volumes:
      - data-metad0:/data/meta
      - logs-metad0:/logs
    networks:
      - nebula-net

  metad1:
    image: vesoft/nebula-metad:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --local_ip=192.168.1.167
      - --ws_ip=192.168.1.167
      - --port=45500
      - --data_path=/data/meta
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-167
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.167:11000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 11000
        published: 11000
        protocol: tcp
        mode: host
      - target: 11002
        published: 11002
        protocol: tcp
        mode: host
      - target: 45500
        published: 45500
        protocol: tcp
        mode: host
    volumes:
      - data-metad1:/data/meta
      - logs-metad1:/logs
    networks:
      - nebula-net

  metad2:
    image: vesoft/nebula-metad:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --local_ip=192.168.1.168
      - --ws_ip=192.168.1.168
      - --port=45500
      - --data_path=/data/meta
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-168
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.168:11000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 11000
        published: 11000
        protocol: tcp
        mode: host
      - target: 11002
        published: 11002
        protocol: tcp
        mode: host
      - target: 45500
        published: 45500
        protocol: tcp
        mode: host
    volumes:
      - data-metad2:/data/meta
      - logs-metad2:/logs
    networks:
      - nebula-net

  storaged0:
    image: vesoft/nebula-storaged:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --local_ip=192.168.1.166
      - --ws_ip=192.168.1.166
      - --port=44500
      - --data_path=/data/storage
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-166
    depends_on:
      - metad0
      - metad1
      - metad2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.166:12000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 12000
        published: 12000
        protocol: tcp
        mode: host
      - target: 12002
        published: 12002
        protocol: tcp
        mode: host
    volumes:
      - data-storaged0:/data/storage
      - logs-storaged0:/logs
    networks:
      - nebula-net
  storaged1:
    image: vesoft/nebula-storaged:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --local_ip=192.168.1.167
      - --ws_ip=192.168.1.167
      - --port=44500
      - --data_path=/data/storage
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-167
    depends_on:
      - metad0
      - metad1
      - metad2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.167:12000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 12000
        published: 12000
        protocol: tcp
        mode: host
      - target: 12002
        published: 12004
        protocol: tcp
        mode: host
    volumes:
      - data-storaged1:/data/storage
      - logs-storaged1:/logs
    networks:
      - nebula-net

  storaged2:
    image: vesoft/nebula-storaged:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --local_ip=192.168.1.168
      - --ws_ip=192.168.1.168
      - --port=44500
      - --data_path=/data/storage
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-168
    depends_on:
      - metad0
      - metad1
      - metad2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.168:12000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 12000
        published: 12000
        protocol: tcp
        mode: host
      - target: 12002
        published: 12006
        protocol: tcp
        mode: host
    volumes:
      - data-storaged2:/data/storage
      - logs-storaged2:/logs
    networks:
      - nebula-net
  graphd1:
    image: vesoft/nebula-graphd:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --port=3699
      - --ws_ip=192.168.1.166
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-166
    depends_on:
      - metad0
      - metad1
      - metad2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.166:13000/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 3699
        published: 3699
        protocol: tcp
        mode: host
      - target: 13000
        published: 13000
        protocol: tcp
#        mode: host
      - target: 13002
        published: 13002
        protocol: tcp
        mode: host
    volumes:
      - logs-graphd:/logs
    networks:
      - nebula-net

  graphd2:
    image: vesoft/nebula-graphd:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --port=3699
      - --ws_ip=192.168.1.167
      - --log_dir=/logs
      - --v=2
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-167
    depends_on:
      - metad0
      - metad1
      - metad2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.167:13001/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 3699
        published: 3640
        protocol: tcp
        mode: host
      - target: 13000
        published: 13001
        protocol: tcp
        mode: host
      - target: 13002
        published: 13003
        protocol: tcp
#        mode: host
    volumes:
      - logs-graphd2:/logs
    networks:
      - nebula-net
  graphd3:
    image: vesoft/nebula-graphd:nightly
    env_file:
      - ./nebula.env
    command:
      - --meta_server_addrs=192.168.1.166:45500,192.168.1.167:45500,192.168.1.168:45500
      - --port=3699
      - --ws_ip=192.168.1.168
      - --log_dir=/logs
      - --v=0
      - --minloglevel=2
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.hostname == KF2-DATA-168
    depends_on:
      - metad0
      - metad1
      - metad2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://192.168.1.168:13002/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - target: 3699
        published: 3641
        protocol: tcp
        mode: host
      - target: 13000
        published: 13002
        protocol: tcp
#        mode: host
      - target: 13002
        published: 13004
        protocol: tcp
        mode: host
    volumes:
      - logs-graphd3:/logs
    networks:
      - nebula-net
networks:
  nebula-net:
    external: true
    attachable: true
    name: host
volumes:
  data-metad0:
  logs-metad0:
  data-metad1:
  logs-metad1:
  data-metad2:
  logs-metad2:
  data-storaged0:
  logs-storaged0:
  data-storaged1:
  logs-storaged1:
  data-storaged2:
  logs-storaged2:
  logs-graphd:
  logs-graphd2:
  logs-graphd3:

编辑 nebula.env，加入如下内容

TZ=UTC
USER=root

2.6 启动 nebula 集群

docker stack deploy nebula -c docker-stack.yml

三、集群负载均衡及高可用配置

Nebula Graph 的客户端目前（1.X）没有提供负载均衡的能力，只是随机选一个 graphd 去连接。所以生产使用的时候要自己做个负载均衡和高可用。

图 3.1

将整个部署架构分为三层，数据服务层，负载均衡层及高可用层。如图 3.1 所示

负载均衡层：对 client 请求做负载均衡，将请求分发至下方数据服务层

高可用层：这里实现的是 haproxy 的高可用，保证负载均衡层的服务从而保证整个集群的正常服务

3.1 负载均衡配置

haproxy 使用 docker-compose 配置。分别编辑以下三个文件

Dockerfile 加入以下内容

FROM haproxy:1.7
COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg
EXPOSE 3640

docker-compose.yml 加入以下内容

version: "3.2"
services:
  haproxy:
    container_name: haproxy
    build: .
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg
    ports:
      - 3640:3640
    restart: always
    networks:
      - app_net
networks:
  app_net:
    external: true

haproxy.cfg 加入以下内容

global
    daemon
    maxconn 30000
    log 127.0.0.1 local0 info
    log 127.0.0.1 local1 warning

defaults
    log-format %hr\ %ST\ %B\ %Ts
    log  global
    mode http
    option http-keep-alive
    timeout connect 5000ms
    timeout client 10000ms
    timeout server 50000ms
    timeout http-request 20000ms

# custom your own frontends && backends && listen conf
# CUSTOM

listen graphd-cluster
    bind *:3640
    mode tcp
    maxconn 300
    balance roundrobin
    server server1 192.168.1.166:3699 maxconn 300 check
    server server2 192.168.1.167:3699 maxconn 300 check
    server server3 192.168.1.168:3699 maxconn 300 check

listen stats
    bind *:1080
    stats refresh 30s
    stats uri /stats

3.2 启动 haproxy

docker-compose up -d

3.3 高可用配置

注：配置 keepalive 需预先准备好 vip（虚拟 ip），在以下配置中 192.168.1.99 便为虚拟 ip

在 192.168.1.166、192.168.1.167、192.168.1.168 上均做以下配置

安装 keepalived

apt-get update && apt-get upgrade && apt-get install keepalived -y

更改 keepalived 配置文件 /etc/keepalived/keepalived.conf（三台机器中做如下配置，priority 应设置不同值确定优先级）

192.168.1.166 机器配置

global_defs {
    router_id lb01 # 标识信息，一个名字而已；
}
vrrp_script chk_haproxy {
    script "killall -0 haproxy"    interval 2
}
vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 52
    priority 999
    # 设定 MASTER 与 BACKUP 负载均衡器之间同步检查的时间间隔，单位是秒
    advert_int 1
    # 设置验证类型和密码
    authentication {
    # 设置验证类型，主要有 PASS 和 AH 两种
        auth_type PASS
    # 设置验证密码，在同一个 vrrp_instance 下，MASTER 与 BACKUP 必须使用相同的密码才能正常通信
        auth_pass amber1
    }
    virtual_ipaddress {
        # 虚拟 IP 为 192.168.1.99/24; 绑定接口为 ens160; 别名 ens169:1，主备相同
        192.168.1.99/24 dev ens160 label ens160:1
    }
    track_script {
        chk_haproxy
    }
}

167 机器配置

global_defs {
    router_id lb01 # 标识信息，一个名字而已；
}
vrrp_script chk_haproxy {
    script "killall -0 haproxy"    interval 2
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens160
    virtual_router_id 52
    priority 888
    # 设定 MASTER 与 BACKUP 负载均衡器之间同步检查的时间间隔，单位是秒
    advert_int 1
    # 设置验证类型和密码
    authentication {
    # 设置验证类型，主要有 PASS 和 AH 两种
        auth_type PASS
    # 设置验证密码，在同一个 vrrp_instance 下，MASTER 与 BACKUP 必须使用相同的密码才能正常通信
        auth_pass amber1
    }
    virtual_ipaddress {
        # 虚拟 IP 为 192.168.1.99/24; 绑定接口为 ens160; 别名 ens160:1，主备相同
        192.168.1.99/24 dev ens160 label ens160:1
    }
    track_script {
        chk_haproxy
    }
}

168 机器配置

global_defs {
    router_id lb01 # 标识信息，一个名字而已；
}
vrrp_script chk_haproxy {
    script "killall -0 haproxy"    interval 2
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens160
    virtual_router_id 52
    priority 777
    # 设定 MASTER 与 BACKUP 负载均衡器之间同步检查的时间间隔，单位是秒
    advert_int 1
    # 设置验证类型和密码
    authentication {
    # 设置验证类型，主要有 PASS 和 AH 两种
        auth_type PASS
    # 设置验证密码，在同一个 vrrp_instance 下，MASTER 与 BACKUP 必须使用相同的密码才能正常通信
        auth_pass amber1
    }
    virtual_ipaddress {
        # 虚拟 IP 为 192.168.1.99/24;绑定接口为 ens160; 别名 ens160:1，主备相同
        192.168.1.99/24 dev ens160 label ens160:1
    }
    track_script {
        chk_haproxy
    }
}

keepalived 相关命令

# 启动 keepalived
systemctl start keepalived
# 使 keepalived 开机自启
systemctl enable keeplived
# 重启 keepalived
systemctl restart keepalived

四、其他

离线怎么部署？把镜像更改为私有镜像库就成了，有问题欢迎来勾搭啊。

我的小鱼你醒了还认识早晨吗昨夜你曾经说愿夜幕永不开启

如果你对本文有任何疑问，欢迎来论坛和原作者聊聊~~ 原帖地址：https://discuss.nebula-graph.com.cn/t/topic/1388

一文了解 Nebula Graph DBaaS 服务——Nebula Graph Cloud Service

NebulaGraph — Fri, 25 Sep 2020 11:15:31 +0800

Nebula Graph DBaaS

作为一款 DBaaS（DataBase as s Service）的产品，Nebula Graph Cloud Service 极大地降低了研发人员使用 Nebula Graph 的成本，更专注于使用 Nebula Graph 挖掘、分析数据背后的关联价值。

Nebula Graph Cloud Service Trial 版本已于近期开始公测试用，本篇文章主要帮助感兴趣的朋友快速了解我们云服务 Trial 版本的主要功能及开放范围。

主要功能

一键创建 Nebula Graph 云服务实例
- 权限管理 - 可邀请其他 Nebula Graph Cloud Service 注册用户一起使用实例
- 日志记录 - 记录查看实例有关操作记录

提供在线 Nebula Graph Studio——图数据库可视化工具：
- 控制台 - 快速尝试 nebula 语句的基本功能
- 图探索 - 通过图可视化发掘数据之间的联系
- 导数据 - 通过可视化配置将数据导入 nebula
- 可视化构图 - 通过可视化操作，迅速完成点/边构图建模（近期发布）

服务监控 - 实时洞察机器运行的基本情况

团队管理 - 简单的团队创建及成员添加，方便实例所属权的转移和交接

公测范围

初次了解 Nebula Graph 图数据库，想要快速无障碍体验 Nebula Graph 产品服务
有图数据库使用需求的用户，诸如金融风控、实时推荐、知识图谱等应用场景
企业用户：最好使用公司邮箱注册，有限的试用资源能帮助真正需要尝试的朋友

Trial 版本限制

试用期间无法提供独立 IP 供业务客户端直连，一切侧重产品功能体验为主，商用版本会提供。
试用期提供的实例服务均为单副本的统一资源：
- 1G 内存
- 单核
- 40G 磁盘大小
- 其他：商用版本会通过资源配置选择。
数据导入时上传的数据集单个文件大小不能超过 100M，总文件大小限制 1G。

试用链接及官方联系方式

欢迎感兴趣的朋友前来申请试用：https://cloud.nebula-graph.com.cn/，有更多需求和问题咨询的朋友，也欢迎联系我们🤝。

邮箱联系：cloud-support@vesoft.com

论坛提问：https://discuss.nebula-graph.com.cn/c/users/DBaas/36

用图机器学习探索 A 股个股相关性变化

NebulaGraph — Thu, 24 Sep 2020 10:49:00 +0800

在本系列的前文 [1,2] 中，我们介绍了如何使用 Python 语言图分析库 NetworkX [3] + Nebula Graph [4] 来进行<权力的游戏>中人物关系图谱分析。

在本文中我们将介绍如何使用 Java 语言的图分析库 JGraphT [5] 并借助绘图库 mxgraph [6] ，可视化探索 A 股的行业个股的相关性随时间的变化情况。

数据集的处理

本文主要分析方法参考了 [7,8]，有两种数据集：

股票数据（点集）

从 A 股中按股票代码顺序选取了 160 只股票（排除摘牌或者 ST 的）。每一支股票都被建模成一个点，每个点的属性有股票代码，股票名称，以及证监会对该股票对应上市公司所属板块分类等三种属性；

表 1：点集示例

顶点 id	股票代码	股票名称	所属板块
1	SZ0001	平安银行	金融行业
2	600000	浦发银行	金融行业
3	600004	白云机场	交通运输
4	600006	东风汽车	汽车制造
5	600007	中国国贸	开发区
6	600008	首创股份	环保行业
7	600009	上海机场	交通运输
8	600010	包钢股份	钢铁行业

股票关系（边集）

边只有一个属性，即权重。边的权重代表边的源点和目标点所代表的两支股票所属上市公司业务上的的相似度——相似度的具体计算方法参考 [7,8]：取一段时间（2014 年 1 月 1 日 - 2020 年 1 月 1 日）内，个股的日收益率的时间序列相关性再定义个股之间的距离为 (也即两点之间的边权重）：

通过这样的处理，距离取值范围为 [0,2]。这意味着距离越远的个股，两个之间的收益率相关性越低。

表 2：边集示例

边的源点 ID	边的目标点 ID	边的权重
11	12	0.493257968
22	83	0.517027513
23	78	0.606206233
2	12	0.653692415
1	11	0.677631482
1	27	0.695705171
1	12	0.71124344
2	11	0.73581915
8	18	0.771556458
12	27	0.785046446
9	20	0.789606527
11	27	0.796009627
25	63	0.797218349
25	72	0.799230001
63	115	0.803534952

这样的点集和边集构成一个图网络，可以将这个网络存储在图数据库 Nebula Graph 中。

JGraphT

JGraphT 是一个开放源代码的 Java 类库，它不仅为我们提供了各种高效且通用的图数据结构，还为解决最常见的图问题提供了许多有用的算法：

支持有向边、无向边、权重边、非权重边等；
支持简单图、多重图、伪图；
提供了用于图遍历的专用迭代器（DFS，BFS）等；
提供了大量常用的的图算法，如路径查找、同构检测、着色、公共祖先、游走、连通性、匹配、循环检测、分区、切割、流、中心性等算法；
可以方便地导入 / 导出 GraphViz [9]。导出的 GraphViz 可被导入可视化工具 Gephi[10] 进行分析与展示；
可以方便地使用其他绘图组件，如：JGraphX，mxGraph，Guava Graphs Generators 等工具绘制出图网络。

下面，我们来实践一把，先在 JGraphT 中创建一个有向图：

import org.jgrapht.*;
import org.jgrapht.graph.*;
import org.jgrapht.nio.*;
import org.jgrapht.nio.dot.*;
import org.jgrapht.traverse.*;

import java.io.*;
import java.net.*;
import java.util.*;

Graph<URI, DefaultEdge> g = new DefaultDirectedGraph<>(DefaultEdge.class);

添加顶点：

URI google = new URI("http://www.google.com");
URI wikipedia = new URI("http://www.wikipedia.org");
URI jgrapht = new URI("http://www.jgrapht.org");

// add the vertices
g.addVertex(google);
g.addVertex(wikipedia);
g.addVertex(jgrapht);

添加边：

// add edges to create linking structure
g.addEdge(jgrapht, wikipedia);
g.addEdge(google, jgrapht);
g.addEdge(google, wikipedia);
g.addEdge(wikipedia, google);

图数据库 Nebula Graph Database

JGraphT 通常使用本地文件作为数据源，这在静态网络研究的时候没什么问题，但如果图网络经常会发生变化——例如，股票数据每日都在变化——每次生成全新的静态文件再加载分析就有些麻烦，最好整个变化过程可以持久化地写入一个数据库中，并且可以实时地直接从数据库中加载子图或者全图做分析。本文选用 Nebula Graph 作为存储图数据的图数据库。

Nebula Graph 的 Java 客户端 Nebula-Java [11] 提供了两种访问 Nebula Graph 方式：一种是通过图查询语言 nGQL [12] 与查询引擎层 [13] 交互，这通常适用于有复杂语义的子图访问类型; 另一种是通过 API 与底层的存储层（storaged）[14] 直接交互，用于获取全量的点和边。除了可以访问 Nebula Graph 本身外，Nebula-Java 还提供了与 Neo4j [15]、JanusGraph [16]、Spark [17] 等交互的示例。

在本文中，我们选择直接访问存储层（storaged）来获取全部的点和边。下面两个接口可以用来读取所有的点、边数据：

// space 为待扫描的图空间名称，returnCols 为需要读取的点/边及其属性列，
// returnCols 参数格式：{tag1Name: prop1, prop2, tag2Name: prop3, prop4, prop5}
Iterator<ScanVertexResponse> scanVertex(
            String space, Map<String, List<String>> returnCols);
Iterator<ScanEdgeResponse> scanEdge(
            String space, Map<String, List<String>> returnCols);

第一步：初始化一个客户端，和一个 ScanVertexProcessor。ScanVertexProcessor 用来对读出来的顶点数据进行解码：

MetaClientImpl metaClientImpl = new MetaClientImpl(metaHost, metaPort);
metaClientImpl.connect();
StorageClient storageClient = new StorageClientImpl(metaClientImpl);
Processor processor = new ScanVertexProcessor(metaClientImpl);

第二步：调用 scanVertex 接口，该接口会返回一个 scanVertexResponse 对象的迭代器：

Iterator<ScanVertexResponse> iterator =
                storageClient.scanVertex(spaceName, returnCols);

第三步：不断读取该迭代器所指向的 scanVertexResponse 对象中的数据，直到读取完所有数据。读取出来的顶点数据先保存起来，后面会将其添加到到 JGraphT 的图结构中：

while (iterator.hasNext()) {
  ScanVertexResponse response = iterator.next();
  if (response == null) {
    log.error("Error occurs while scan vertex");
    break;
  }

  Result result =  processor.process(spaceName, response);
  results.addAll(result.getRows(TAGNAME));
}

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

在 JGraphT 中进行图分析

第一步：在 JGraphT 中创建一个无向加权图 graph：

Graph<String, MyEdge> graph = GraphTypeBuilder
                .undirected()
    .weighted(true)
    .allowingMultipleEdges(true)
    .allowingSelfLoops(false)
    .vertexSupplier(SupplierUtil.createStringSupplier())
    .edgeSupplier(SupplierUtil.createSupplier(MyEdge.class))
    .buildGraph();

第二步：将上一步从 Nebula Graph 图空间中读出来的点、边数据添加到 graph 中：

for (VertexDomain vertex : vertexDomainList){
    graph.addVertex(vertex.getVid().toString());
    stockIdToName.put(vertex.getVid().toString(), vertex);
}

for (EdgeDomain edgeDomain : edgeDomainList){
    graph.addEdge(edgeDomain.getSrcid().toString(), edgeDomain.getDstid().toString());
    MyEdge newEdge = graph.getEdge(edgeDomain.getSrcid().toString(), edgeDomain.getDstid().toString());
    graph.setEdgeWeight(newEdge, edgeDomain.getWeight());
}

第三步：参考 [7,8] 中的分析法，对刚才的图 graph 使用 Prim 最小生成树算法（minimun-spanning-tree），并调用封装好的 drawGraph 接口画图：

普里姆算法（Prim's algorithm），图论中的一种算法，可在加权连通图里搜索最小生成树。即，由此算法搜索到的边子集所构成的树中，不但包括了连通图里的所有顶点，且其所有边的权值之和亦为最小。

SpanningTreeAlgorithm.SpanningTree pMST = new PrimMinimumSpanningTree(graph).getSpanningTree();

Legend.drawGraph(pMST.getEdges(), filename, stockIdToName);

第四步：drawGraph 方法封装了画图的布局等各项参数设置。这个方法将同一板块的股票渲染为同一颜色，将距离接近的股票排列聚集在一起。

public class Legend {

...

  public static void drawGraph(Set<MyEdge> edges, String filename, Map<String, VertexDomain> idVertexMap) throws IOException {
     // Creates graph with model
     mxGraph graph = new mxGraph();
     Object parent = graph.getDefaultParent();

     // set style
     graph.getModel().beginUpdate();
     mxStylesheet myStylesheet =  graph.getStylesheet();
     graph.setStylesheet(setMsStylesheet(myStylesheet));

     Map<String, Object> idMap = new HashMap<>();
     Map<String, String> industryColor = new HashMap<>();

     int colorIndex = 0;

     for (MyEdge edge : edges) {
       Object src, dst;
       if (!idMap.containsKey(edge.getSrc())) {
         VertexDomain srcNode = idVertexMap.get(edge.getSrc());
         String nodeColor;
         if (industryColor.containsKey(srcNode.getIndustry())){
           nodeColor = industryColor.get(srcNode.getIndustry());
         }else {
           nodeColor = COLOR_LIST[colorIndex++];
           industryColor.put(srcNode.getIndustry(), nodeColor);
         }
         src = graph.insertVertex(parent, null, srcNode.getName(), 0, 0, 105, 50, "fillColor=" + nodeColor);
         idMap.put(edge.getSrc(), src);
       } else {
         src = idMap.get(edge.getSrc());
       }

       if (!idMap.containsKey(edge.getDst())) {
         VertexDomain dstNode = idVertexMap.get(edge.getDst());

         String nodeColor;
         if (industryColor.containsKey(dstNode.getIndustry())){
           nodeColor = industryColor.get(dstNode.getIndustry());
         }else {
           nodeColor = COLOR_LIST[colorIndex++];
           industryColor.put(dstNode.getIndustry(), nodeColor);
         }

         dst = graph.insertVertex(parent, null, dstNode.getName(), 0, 0, 105, 50, "fillColor=" + nodeColor);
         idMap.put(edge.getDst(), dst);
       } else {
         dst = idMap.get(edge.getDst());
       }
       graph.insertEdge(parent, null, "", src, dst);
     }


     log.info("vertice " + idMap.size());
     log.info("colorsize " + industryColor.size());

     mxFastOrganicLayout layout = new mxFastOrganicLayout(graph);
     layout.setMaxIterations(2000);
     //layout.setMinDistanceLimit(10D);
     layout.execute(parent);

     graph.getModel().endUpdate();

     // Creates an image than can be saved using ImageIO
     BufferedImage image = createBufferedImage(graph, null, 1, Color.WHITE,
                                               true, null);

     // For the sake of this example we display the image in a window
     // Save as JPEG
     File file = new File(filename);
     ImageIO.write(image, "JPEG", file);

   }

  ...

}

第五步：生成可视化：

图 1 中每个顶点的颜色代表证监会对该股票所属上市公司归类的板块。

可以看到，实际业务近似度较高的股票已经聚拢成簇状（例如：高速板块、银行版本、机场航空板块），但也会有部分关联性不明显的个股被聚类在一起，具体原因需要单独进行个股研究。

图 1：基于 2015-01-01 至 2020-01-01 的股票数据计算出的聚集性

第六步：基于不同时间窗口的一些其他动态探索

上节中，结论主要基于 2015-01-01 到 2020-01-01 的个股聚集性。这一节我们还做了一些其他的尝试：以 2 年为一个时间滑动窗口，分析方法不变，定性探索聚集群是否随着时间变化会发生改变。

图 2：基于 2014-01-01 至 2016-01-01 的股票数据计算出的聚集性

图 3：基于 2015-01-01 至 2017-01-01 的股票数据计算出的聚集性

图 4：基于 2016-01-01 至 2018-01-01 的股票数据计算出的聚集性

图 5：基于 2017-01-01 至 2019-01-01 的股票数据计算出的聚集性

图 6：基于 2018-01-01 至 2020-01-01 的股票数据计算出的聚集性

粗略分析看，随着时间窗口变化，有些板块（高速、银行、机场航空、房产、能源）的板块内部个股聚集性一直保持比较好——这意味着随着时间变化，这个版块内各种一直保持比较高的相关性；但有些板块（制造）的聚集性会持续变化——意味着相关性一直在发生变化。

Disclaim

本文不构成任何投资建议，且作者不持有本文中任一股票。

受限于停牌、熔断、涨跌停、送转、并购、主营业务变更等情况，数据处理可能有错误，未做一一检查。

受时间所限，本文只选用了 160 个个股样本过去 6 年的数据，只采用了最小扩张树一种办法来做聚类分类。未来可以使用更大的数据集（例如美股、衍生品、数字货币），尝试更多种图机器学习的办法。

本文代码可见 [18]

Reference

[1] 用 NetworkX + Gephi + Nebula Graph 分析<权力的游戏>人物关系（上篇）https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/

[2] 用 NetworkX + Gephi + Nebula Graph 分析<权力的游戏>人物关系（下篇） https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph-part-two/

[3] NetworkX: a Python package for the creation, manipulation, and study of the structure, dynamics, and functions of complex networks. https://networkx.github.io/

[4] Nebula Graph: A powerfully distributed, scalable, lightning-fast graph database written in C++. https://nebula-graph.io/

[5] JGraphT: a Java library of graph theory data structures and algorithms. https://jgrapht.org/

[6] mxGraph: JavaScript diagramming library that enables interactive graph and charting applications. https://jgraph.github.io/mxgraph/

[7] Bonanno, Giovanni & Lillo, Fabrizio & Mantegna, Rosario. (2000). High-frequency Cross-correlation in a Set of Stocks. arXiv.org, Quantitative Finance Papers. 1. 10.1080/713665554.

[8] Mantegna, R.N. Hierarchical structure in financial markets. Eur. Phys. J. B 11, 193–197 (1999).

[9] https://graphviz.org/

[10] https://gephi.org/

[11] https://github.com/vesoft-inc/nebula-java

[12] Nebula Graph Query Language (nGQL). https://docs.nebula-graph.io/manual-EN/1.overview/1.concepts/2.nGQL-overview/

[13] Nebula Graph Query Engine. https://github.com/vesoft-inc/nebula-graph

[14] Nebula-storage: A distributed consistent graph storage. https://github.com/vesoft-inc/nebula-storage

[15] Neo4j. www.neo4j.com

[16] JanusGraph. janusgraph.org

[17] Apache Spark. spark.apache.org.

[18] https://github.com/Judy1992/nebula_scan

从 Neo4j 导入 Nebula Graph 实践见 SPark 数据导入原理

NebulaGraph — Wed, 16 Sep 2020 09:53:42 +0800

本文主要讲述如何使用数据导入工具 Nebula Graph Exchange 将数据从 Neo4j 导入到 Nebula Graph Database。在讲述如何实操数据导入之前，我们先来了解下 Nebula Graph 内部是如何实现这个导入功能的。

Nebula Graph Exchange 的数据处理原理

我们这个导入工具名字是 Nebula Graph Exchange，采用 Spark 作为导入平台，来支持海量数据的导入和保障性能。Spark 本身提供了不错的抽象——DataFrame，使得可以轻松支持多种数据源。在 DataFrame 的支持下，添加新的数据源只需提供配置文件读取的代码和返回 DataFrame 的 Reader 类，即可支持新的数据源。

DataFrame 可以视为一种分布式存表格。DataFrame 可以存储在多个节点的不同分区中，多个分区可以存储在不同的机器上，从而支持并行操作。Spark 还提供了一套简洁的 API 使用户轻松操作 DataFrame 如同操作本地数据集一般。现在大多数数据库提供直接将数据导出成 DataFrame 功能，即使某个数据库并未提供此功能也可以通过数据库 driver 手动构建 DataFrame。

Nebula Graph Exchange 将数据源的数据处理成 DataFrame 之后，会遍历它的每一行，根据配置文件中 fields 的映射关系，按列名获取对应的值。在遍历 batchSize 个行之后，Exchange 会将获取的数据一次性写入到 Nebula Graph 中。目前，Exchange 是通过生成 nGQL 语句再由 Nebula Client 异步写入数据，下一步会支持直接导出 Nebula Graph 底层存储的 sst 文件，以获取更好的性能。接下来介绍一下 Neo4j 数据源导入的具体实现。

Neo4j 数据导入具体实现

虽然 Neo4j 官方提供了可将数据直接导出为 DataFrame 的库，但使用它读取数据难以满足断点续传的需求，我们未直接使用这个库，而是使用 Neo4j 官方的 driver 实现数据读取。Exchange 通过在不同分区调取 Neo4j driver 执行不同 skip 和 limit 的 Cypher 语句，将数据分布在不同的分区，来获取更好的性能。这个分区数量由配置项 partition 指定。

Exchange 中的 Neo4jReader 类会先将用户配置中的 exec Cypher 语句，return 后边的语句替换成 count(*) 执行获取数据总量，再根据分区数计算每个分区的起始偏移量和大小。这里如果用户配置了 check_point_path 目录，会读取目录中的文件，如果处于续传的状态，Exchange 会计算出每个分区应该的偏移量和大小。然后每个分区在 Cypher 语句后边添加不同的 skip 和 limit，调用 driver 执行。最后将返回的数据处理成 DataFrame 就完成了 Neo4j 的数据导入。

过程如下图所示：

Neo4j 数据导入实践

我们这里导入演示的系统环境如下：

cpu name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
cpu cores: 14
memory size: 251G

软件环境如下：

Neo4j：3.5.20 社区版
Nebula graph：docker-compose 部署，默认配置
Spark：单机版，版本为 2.4.6 pre-build for hadoop2.7

由于 Nebula Graph 是强 schema 数据库，数据导入前需先进行创建 Space，建 Tag 和 Edge 的 schema，具体的语法可以参考这里。

这里建了名为 test 的 Space，副本数为 1。这里创建了两种 Tag 分别为 tagA 和 tagB，均含有 4 个属性的点类型，此外，还创建一种名为 edgeAB 的边类型，同样含有 4 个属性。具体的 nGQL 语句如下所示：

# 创建图空间
CREATE SPACE test(replica_factor=1);
# 选择图空间 test
USE test;
# 创建标签 tagA
CREATE TAG tagA(idInt int, idString string, tboolean bool, tdouble double);
# 创建标签 tagB
CREATE TAG tagB(idInt int, idString string, tboolean bool, tdouble double);
# 创建边类型 edgeAB
CREATE EDGE edgeAB(idInt int, idString string, tboolean bool, tdouble double);

同时向 Neo4j 导入 Mock 数据——标签为 tagA 和 tagB 的点，数量总共为 100 万，并且导入了连接 tagA 和 tagB 类型点边类型为 edgeAB 的边，共 1000 万个。另外需要注意的是，从 Neo4j 导出的数据在 Nebula Graph 中必须存在属性，且数据对应的类型要同 Nebula Graph 一致。

最后为了提升向 Neo4j 导入 Mock 数据的效率和 Mock 数据在 Neo4j 中的读取效率，这里为 tagA 和 tagB 的 idInt 属性建了索引。关于索引需要注意 Exchange 并不会将 Neo4j 中的索引、约束等信息导入到 Nebula Graph 中，所以需要用户在执行数据写入在 Nebula Graph 之后，自行创建索引和 REBUILD 索引（为已有数据建立索引）。

接下来就可以将 Neo4j 数据导入到 Nebula Graph 中了，首先我们需要下载和编译打包项目，项目在 nebula-java 这个仓库下 tools/exchange 文件夹中。可执行如下命令：

git clone https://github.com/vesoft-inc/nebula-java.git
cd nebula-java/tools/exchange
mvn package -DskipTests

然后就可以看到 target/exchange-1.0.1.jar 这个文件。

接下来编写配置文件，配置文件的格式为：HOCON（Human-Optimized Config Object Notation），可以基于 src/main/resources/server_application.conf 文件的基础上进行更改。首先对 nebula 配置项下的 address、user、pswd 和 space 进行配置，测试环境均为默认配置，所以这里不需要额外的修改。然后进行 tags 配置，需要 tagA 和 tagB 的配置，这里仅展示 tagA 配置，tagB 和 tagA 配置相同。

{
    # ======neo4j连接设置=======
    name: tagA
    # 必须和 Nebula Graph 的中 tag 名字一致，需要在 Nebula Graph 中事先建好 tag
    server: "bolt://127.0.0.1:7687"
    # neo4j 的地址配置
    user: neo4j
    # neo4j 的用户名
    password: neo4j
    # neo4j 的密码

    encryption: false
    # (可选): 传输是否加密，默认值为 false
    database: graph.db
    # (可选): neo4j database 名称，社区版不支持

    # ======导入设置============
    type: {
        source: neo4j
        # 还支持 PARQUET、ORC、JSON、CSV、HIVE、MYSQL、PULSAR、KAFKA...
        sink: client
        # 写入 Nebula Graph 的方式，目前仅支持 client，未来会支持直接导出 Nebula Graph 底层数据库文件
    }

    nebula.fields: [idInt, idString, tdouble, tboolean]
    fields       : [idInt, idString, tdouble, tboolean]
    # 映射关系 fields，上方为 nebula 的属性名，下方为 neo4j 的属性名，一一对应
    # 映射关系的配置是 List 而不是 Map，是为了保持 fields 的顺序，未来直接导出 nebula 底层存储文件时需要

    vertex: idInt
    # 作为 nebula vid 的 neo4j field，类型需要是整数(long or int)。

    partition: 10
    # 分区数
    batch: 2000
    # 一次写入 nebula 多少数据

    check_point_path: "file:///tmp/test"
    # (可选): 保存导入进度信息的目录，用于断点续传

    exec: "match (n:tagA) return n.idInt as idInt, n.idString as idString, n.tdouble as tdouble, n.tboolean as tboolean order by n.idInt"
}

边的设置大部分与点的设置无异，但由于边在 Nebula Graph 中有起点的 vid 和终点的 vid 标识，所以这里需要指定作为边起点 vid 的域和作为边终点 vid 的域。

下面给出边的特别配置。

source: {
  field: a.idInt
  # policy: "hash"
}
# 起点的 vid 设置
target: {
  field: b.idInt
  # policy: "uuid"
}
# 终点的 vid 设置

ranking: idInt
# (可选): 作为 rank 的 field

partition: 1
# 这里分区数设置为 1，原因在后边

exec: "match (a:tagA)-[r:edgeAB]->(b:tagB) return a.idInt, b.idInt, r.idInt as idInt, r.idString as idString, r.tdouble as tdouble, r.tboolean as tboolean order by id(r)"

点的 vertex 和边的 source、target 配置项下都可以设置 policy hash/uuid，它可以将类型为字符串的域作为点的 vid，通过 hash/uuid 函数将字符串映射成整数。

上面的例子由于作为点的 vid 为整数，所以并不需要 policy 的设置。hash/uuid 的区别请看这里。

Cypher 标准中如果没有 order by 约束的话就不能保证每次查询结果的排序一致，虽然看起来即便不加 order by Neo4j 返回的结果顺序也是不变的，但为了防止可能造成的导入时数据丢失，还是强烈建议在 Cypher 语句中加入 order by，虽然这会增加导入的时间。为了提升导入效率， order by 语句最好选取有索引的属性作为排序的属性。如果没有索引，也可观察默认的排序，选择合适的排序属性以提高效率。如果默认的排序找不到规律，可以使用点/关系的 ID 作为排序属性，并且将 partition 的值尽量设小，减少 Neo4j 的排序压力，本文中边 edgeAB 的 partition 就设置为 1。

另外 Nebula Graph 在创建点和边时会将 ID 作为唯一主键，如果主键已存在则会覆盖该主键中的数据。所以假如将某个 Neo4j 属性值作为 Nebula Graph 的 ID，而这个属性值在 Neo4j 中是有重复的，就会导致“重复 ID”对应的数据有且只有一条会存入 Nebula Graph 中，其它的则会被覆盖掉。由于数据导入过程是并发地往 Nebula Graph 中写数据，最终保存的数据并不能保证是 Neo4j 中最新的数据。

这里还要留意下断点续传功能，在断点和续传之间，数据库不应该改变状态，如添加数据或删除数据，且 partition 数量也不能更改，否则可能会有数据丢失。

最后由于 Exchange 需要在不同分区执行不同 skip 和 limit 的 Cypher 语句，所以用户提供的 Cypher 语句不能含有 skip 和 limit 语句。

接下来就可以运行 Exchange 程序导数据了，执行如下命令：

$SPARK_HOME/bin/spark-submit  --class com.vesoft.nebula.tools.importer.Exchange --master "local[10]" target/exchange-1.0.1.jar -c /path/to/conf/neo4j_application.conf

在上述这些配置下，导入 100 万个点用时 13s，导入 1000 万条边用时 213s，总用时是 226s。

附：Neo4j 3.5 Community 和 Nebula Graph 1.0.1 的一些比较

Neo4j 和 Nebula Graph 在系统架构、数据模型和访问方式上都有一些差异，下表列举了常见的异同

作者有话说：Hi，我是李梦捷，图数据库 Nebula Graph 的研发工程师，如果你对此文有疑问，欢迎来我们的 Nebula Graph 论坛交流下心得~~

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

360 数科实践：JanusGraph 到 NebulaGraph 迁移

NebulaGraph — Wed, 09 Sep 2020 09:57:11 +0800

摘要：在本文中 360 数科的周鹏详细讲解了业务从 JanusGraph 迁移到 Nebula Graph 带来的性能提升，在机器资源不到之前 JanusGraph 配置三分之一的情况下，业务性能提升至少 20 倍。

本文作者系 360 数科开发工程师：周鹏

迁移背景

我们之前图数据用的是单机版的 AgensGraph, 后面因为单机带来的性能限制问题，迁移到了分布式数据库 JanusGraph，详细的迁移信息可以看我之前的一篇文章《百亿级图数据 JanusGraph 迁移之旅》。但是随着数据量和业务调用量的增加，新的问题又出现了——单次查询的耗时很高个别业务场景已经到了 10s，数据量稍微多点，逻辑复杂点的查询耗时也在 2~3s 左右，这严重影响了整个业务流程的性能和相关业务的发展。

JanusGraph 的架构决定了单次耗时高，核心的原因在于它的存储依赖外部，自身不能很好地控制外部存储，我们生产环境用的便是 HBase 集群，这导致所有的查询没法下推到存储层进行处理，只能把数据从 HBase 查询到 JanusGraph Server 内存再做相应的过滤。

举个例子，查询一层关联关系年龄大于 50 岁的用户，如果一层关联有 1,000 人，年龄大于 50 岁的只有 2 个人。介于 JanusGraph 查询请求发送到 HBase 时做不了一层关联顶点属性的过滤，我们不得不通过并发请求去查询 HBase 获取这 1,000 人的顶点属性，再在 JanusGraph Server 的内存做过滤，最后返回给客户端满足条件的 2 个用户。

这样做的问题就是磁盘 IO、网络 IO 浪费很大，而且查询返回的大多数据在而后查的查询并未用到。我们生产环境用的 HBase 为 19 台高配 SSD 服务器的，具体的网络 IO、磁盘 IO 使用情况如下图：

我们对比相同的业务场景，但是只有 6 台相同配置的 SSD 服务器 Nebua Graph 的磁盘 IO 和网络 IO 情况如下：

Nebula Graph 性能确实优秀太多，而且是在机器资源只有之前 Hbase 集群 30% 的情况下。我们再来看下业务场景下的耗时情况，之前业务场景中查询耗时需要 2~3s 情况的在 Nebula Graph 这边 100ms 左右返回了，之前需要 10~20s 情况的业务场景现在也基本在 2s 就能返回，并且平均耗时也基本在 500ms 左右就能搞定，性能提升至少 20 倍以上 :)

就冲上面的这些数据，如果你还在用 JanusGraph，就应该立马把这篇文章转发给你的领导，并立个项开始迁移到 Nebua Graph 👏

历史数据迁移

数据迁移这块，因为我们的数据量比较大，20 亿左右的顶点，200 亿左右的边，好在 Nebula Graph 提供 Spark 导入工具——Spark Writer，整个数据导入过程还算比较流畅。这里有个可分享经验，当时使用 Spark 导入工具采用异步方式导入导致了不少 error，稍微改下导入方式换成同步写入就没问题了。另外一个经验是关于 Spark 的，如果导入的数据量比较大，对应的 partitions 需要设置大一点，我们就设置过 8w 个 patitions。如果你设置的 partitions 比较小，单个 partition 的数据量便会比较大，容易导致 Spark 任务 OOM Fail。

查询调优

我们现在生产环境 Nebula Graph 用的是 1.0 的版本，生产环境上 ID 生产我们用的是 hash 函数，uuid 导入数据会很慢，后面官方也不会再支持 uuid。

在我们的生产环境主要参数调优配置如下，主要是 nebula-storage 需要调优

# The default reserved bytes for one batch operation
--rocksdb_batch_size=4096
# The default block cache size used in BlockBasedTable.
# The unit is MB. 我们生产服务器内存为128G
--rocksdb_block_cache=44024

############## rocksdb Options ##############
--rocksdb_disable_wal=true
# rocksdb DBOptions in json, each name and value of option is a string, given as "option_name":"option_value" separated by comma
--rocksdb_db_options={"max_subcompactions":"3","max_background_jobs":"3"}
# rocksdb ColumnFamilyOptions in json, each name and value of option is string, given as "option_name":"option_value" separated by comma
--rocksdb_column_family_options={"disable_auto_compactions":"false","write_buffer_size":"67108864","max_write_buffer_number":"4","max_bytes_for_level_base":"268435456"}
# rocksdb BlockBasedTableOptions in json, each name and value of option is string, given as "option_name":"option_value" separated by comma
--rocksdb_block_based_table_options={"block_size":"8192"}

--max_handlers_per_req=10
--heartbeat_interval_secs=10

# 新添加参数
--raft_rpc_timeout_ms=5000
--raft_heartbeat_interval_secs=10
--wal_ttl=14400
--max_batch_size=512
# 参数配置减小内存使用
--enable_partitioned_index_filter=true
--max_edge_returned_per_vertex=10000

Linux 机器的调优主要就是把服务的 swap 关闭掉，开启后会因为磁盘 IO 影响查询性能。另外关于 minor compact 和 major compact 调优，我们生产环境是开启 minor compact 关闭 major compact。关闭 major compact 主要是因为这个操作很占磁盘 IO，并且很难通过线程数（--rocksdb_db_options={"max_subcompactions":"3","max_background_jobs":"3"}）控制，后续 Nebula Graph 官方有计划优化这块。

最后，来重点提下 max_edge_returned_per_vertex 这个参数，能想到这个参数 Nebula Graph 不愧是图数据行业的老司机——我们之前的图查询一直受到超级节点的困扰，线上环境如果查询遇到这种关联几百万数据的超级节点能直接把 JanusGraph 的 HBase 集群查崩掉（我们生产环境出现过几次）。之前在查询 JanusGraph 的 Gremlin 语句上加各种 limit 限制都没能很好的解决这个问题，在 Nebula Graph 有了这个 max_edge_returned_per_vertex 参数，数据在最底层存储层直接做了过滤，生产环境就不会再有这种超级节点的困扰，就这一点就应该给 NebulaGraph 一个 FIVE STAR！

本文首发于 Nebula Graph 论坛，阅读本文的你有任何疑问，欢迎前往论坛和作者进行讨论，原帖传送门：https://discuss.nebula-graph.com.cn/t/topic/1172

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

NebulaGraph — Wed, 02 Sep 2020 16:53:03 +0800

在上一篇[1] 中，我们通过 NetworkX 和 Gephi 展示了<权力的游戏>中的人物关系。在本篇中，我们将展示如何通过 NetworkX 访问图数据库 Nebula Graph。

NetworkX

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

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

NetworkX 支持 4 种类型的图：

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

在 NetworkX 中创建一个无向图：

import networkx as nx
G = nx.Graph()

添加顶点：

G.add_node(1)
G.add_nodes_from([2,3,4])
G.add_node(2,name='Tom',age=23)

添加边：

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 社区发现算法。

图数据库 Nebula Graph

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

Fig. 1

Fig. 2

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

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

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

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

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

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 用来对读出来的边数据进行解码：

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 接口的各项参数：

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 对象的迭代器：

scan_edge_response_iterator = storage_client.scan_edge(space_name, return_cols, all_cols, limit, start_time, end_time)

4) 不断读取该迭代器所指向的 scan_edge_response 对象中的数据，直到读取完所有数据：

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 里：

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] 来说，Nebula Graph 还提供了根据分片 (partition) 并发地批量读取存储的功能，这会在之后的文章中演示。

在 NetworkX 中进行图分析

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

1) 绘制图：

nx.draw(G, with_labels=True, font_weight='bold')
import matplotlib.pyplot as plt
plt.show()
plt.savefig('./test.png')

绘制出来的图：

2) 打印出图中的所有点和边：

print('nodes: ', list(G.nodes))
print('edges: ', list(G.edges))

输出的结果：

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) 常见的，可以计算两个点之间的最短路径：

p1 = nx.shortest_path(G, source=114, target=211)
print('顶点 114 到顶点 211 的最短路径: ', p1)

输出的结果：

顶点 114 到顶点 211 的最短路径:  [114, 127, 208, 124, 211]

4) 也计算图中每个点的 PageRank 值，来看各自的影响力：

print(nx.pagerank(G))

输出的结果：

{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/

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

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

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

[5] https://gephi.org/

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

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

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

图数据库对比：Neo4j vs Nebula Graph vs HugeGraph

NebulaGraph — Thu, 27 Aug 2020 16:14:36 +0800

本文系腾讯云安全团队李航宇、邓昶博撰写

图数据库在挖掘黑灰团伙以及建立安全知识图谱等安全领域有着天然的优势。为了能更好的服务业务，选择一款高效并且贴合业务发展的图数据库就变得尤为关键。本文挑选了几款业界较为流行的开源图数据库与 Nebula Graph 进行了多角度的对比。

图数据库介绍

Neo4j

Neo4j 是目前业界广泛使用的图数据库，包含社区版本和商用版本，本文中使用社区版本。

HugeGraph

HugeGraph 是百度基于 JanusGraph 改进而来的分布式图数据库，主要应用场景是解决百度安全事业部所面对的反欺诈、威胁情报、黑产打击等业务的图数据存储和图建模分析需求。具有良好的读写性能。

Nebula Graph

Nebula Graph 是一款开源的分布式图数据库，采用 shared-nothing 分布式架构，擅长处理千亿节点万亿条边的超大规模数据集，从而更好地服务企业级应用。

测试硬件环境

性能对比

我们使用不同量级的图从入库时间，一度好友查询，二度好友查询，共同好友查询几个方面进行了对比，结果如下：

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

查询语言对比

从查询语句的角度出发，Gremlin 比较复杂，nGQL 和 Cypher 比较简练，从可读性角度出发，nGQL 比较类 SQL 化，比较符合大家的使用习惯。

可视化对比

在可视化方面，所有的平台都还只处于可用状态，Nebula Graph 的选择性扩展在团伙挖掘中是一个加分项，但是在二度结果展示流畅度，展示结果自定义展示方面还有优化空间。

在比较了多款业内主要使用的开源数据库后，我们从性能，学习成本和与业务的贴合程度多个角度考虑，最终选择了性能出众，上手简单，能大幅提高业务效率的 Nebula Graph 图数据库。

本文首发于 Nebula Graph 论坛，阅读本文的你有任何疑问，欢迎前往论坛和作者进行讨论，原帖传送门：https://discuss.nebula-graph.com.cn/t/topic/1013

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

NebulaGraph — Wed, 19 Aug 2020 15:02:05 +0800

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

数据集

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

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

这样的点集和边集构成一个图网络，这个网络存储在图数据库 Nebula Graph [2] 中。

社区划分——Girvan-Newman 算法

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

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

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

Girvan-Newman 算法即是一种基于介数的社区发现算法，其基本思想是根据边介数中心性（edge betweenness）从大到小的顺序不断地将边从网络中移除直到整个网络分解为各个社区。因此，Girvan-Newman 算法实际上是一种分裂方法。

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

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

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

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

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

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 根据有多少最短路径经过该节点，来判断一个节点的重要性。

计算每个节点的介数中心性的值

betweenness_dict = nx.betweenness_centrality(G) # Run betweenness centrality

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

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

边的粗细

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

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

下面显示一下：

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 本身有不少可视化功能，但 Gephi [4] 的交互和可视化效果更好。

接入可视化工具 Gephi

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

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

Gephi 可视化效果展示

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

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

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

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

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

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

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

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

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

导出图片再加个头像效果

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

本篇主要介绍如何使用 NetworkX，并通过 Gephi 做可视化展示。下一篇将介绍如何通过 NetworkX 访问图数据库 Nebula Graph 中的数据。

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

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

Reference

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

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

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

[4] https://gephi.org/

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

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

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

新手阅读 Nebula Graph 源码的姿势

NebulaGraph — Wed, 05 Aug 2020 10:44:47 +0800

摘要：在本文中，我们将通过数据流快速学习 Nebula Graph，以用户在客户端输入一条 nGQL 语句 SHOW SPACES 为例，使用 GDB 追踪语句输入时 Nebula Graph 是怎么调用和运行的。

首发于 Nebula Graph 博客：https://nebula-graph.com.cn/posts/how-to-read-nebula-graph-source-code/

导读

对于一些刚开始接触开源的分布式图数据库 Nebula Graph 开源库的小伙伴来说，刚开始可能和我一样，想要提高自己，看看大神们的代码然后试着能够做点什么，或许能够修复一个看起来并不是那么困难的 Bug。但是面对如此多的代码，我裂开了，不知道如何下手。最后硬着头皮，再看了一遍又一遍代码，跑了一个又一个用例之后终于有点眉目了。

下面就分享下个人学习 Nebula Graph 开源代码的过程，也希望刚接触 Nebula Graph 的小伙伴能够少走弯路，快速入门。另外 Nebula Graph 本身也用到了一些开源库，详情可以见附录。

在本文中，我们将通过数据流快速学习 Nebula Graph，以用户在客户端输入一条 nGQL 语句 SHOW SPACES 为例，使用 GDB 追踪语句输入时 Nebula Graph 是怎么调用和运行的。

整体架构

一个完整的 Nebula Graph 包含三个服务，即 Query Service，Storage Service 和 Meta Service。每个服务都有其各自的可执行二进制文件。

Query Service 主要负责

客户端连接的管理
解析来自客户端的 nGQL 语句为抽象语法树 AST，并将抽象树 AST 解析成一系列执行动作。
对执行动作进行优化
执行优化后的执行计划

Storage Service 主要负责

数据的分布式存储

Meta Service 主要负责

图 schema 的增删查改
集群的管理
用户鉴权

这次，我们主要对 Query Service 进行分析

目录结构

刚开始，可以拿到一个 source 包，解压，可以先看看代码的层级关系，不同的包主要功能是干什么的下面只列出 src 目录：

|--src
    |--client // 客户端代码
    |--common // 提供一些常用的基础组件
    |--console
    |--daemons
    |--dataman
    |--graph // 包含了Query Service的大部分代码                         
    |--interface // 主要是一些 meta、storage 和 graph 的通讯接口定义     
    |--jni
    |--kvstore
    |--meta // 元数据管理相关 
    |--parser // 主要负责词法和语法分析       
    |--storage // 存储层相关
    |--tools
    |--webservice

代码跟踪

通过 scripts 目录下的脚本启动 metad 和 storaged 这两个服务：

启动后通过 nebula.service status all 查看当前的服务状态

然后 gdb 运行 bin 目录下的 nebula-graphd 二进制程序

gdb> set args --flagfile  /home/mingquan.ji/1.0/nebula-install/etc/nebula-graphd.conf   //设置函数入参
gdb> set follow-fork-mode child   // 由于是守护进程，所以在 fork 子进程后 gdb 继续跟踪子进程
gdb> b main         // 在 mian 入口打断点

在 gdb 中输入 run 开始运行 nebula-graphd 程序，然后通过 next 可以一步一步运行，直到遇到 gServer->serve(); // Blocking wait until shut down via gServer->stop()，此时 nebula-graphd 的所有线程阻塞，等待客户端连接，这时需要找到客户端发起请求后由哪个函数处理。

由于 Nebula Graph 使用 FBThrift 来定义生成不同服务的通讯代码，在 src/interface/graph.thrift 文件中可以看到 GraphService 接口的定义如下：

service GraphService {
    AuthResponse authenticate(1: string username, 2: string password)
    oneway void signout(1: i64 sessionId)
    ExecutionResponse execute(1: i64 sessionId, 2: string stmt)
}

在 gServer->serve() 之前有

auto interface = std::make_shared<GraphService>();
status = interface->init(ioThreadPool);
gServer->setInterface(std::move(interface));
gServer->setAddress(localIP, FLAGS_port);

可以知道是由 GraphService 对象来处理客户端的连接和请求，因此可以在 GraphService.cpp:future_execute 处打断点，以便跟踪后续处理流程。

此时重新打开一个终端进入 nebula 安装目录，通过 ./nebule -u=root -p=nebula 来连接 nebula 服务，再在客户端输入 SHOW SPACES ，此时客户端没有反应，是因为服务端还在阻塞调试中，回到服务端输入 continue，如下所示：

经过 session 验证后，进入 executionEngine->execute() 中，step 进入函数内部

auto plan = new ExecutionPlan(std::move(ectx));
plan->execute();

继续 step 进入ExecutionPlan 的 execute 函数内部，然后执行到

auto result = GQLParser().parse(rctx->query());

parse 这块主要使用 flex & bison，用于词法分析和语法解析构造对象到抽象语法树，其词法文件是 src/parser/scanner.lex，语法文件是 src/parser/parser.yy，其词法分析类似于正则表达式，语法分析举例如下：

go_sentence
    : KW_GO step_clause from_clause over_clause where_clause yield_clause {
        auto go = new GoSentence();
        go->setStepClause($2);
        go->setFromClause($3);
        go->setOverClause($4);
        go->setWhereClause($5);
        if ($6 == nullptr) {
            auto *cols = new YieldColumns();
            for (auto e : $4->edges()) {
                if (e->isOverAll()) {
                    continue;
                }
                auto *edge  = new std::string(*e->edge());
                auto *expr  = new EdgeDstIdExpression(edge);
                auto *col   = new YieldColumn(expr);
                cols->addColumn(col);
            }
            $6 = new YieldClause(cols);
        }
        go->setYieldClause($6);
        $$ = go;
    }

其在匹配到对应到 go 语句时，就构造对应的节点，然后由 bison 处理，最后生成一个抽象的语法树。

词法语法分析后开始执行模块，继续 gdb，进入 excute 函数，一直 step 直到进入ShowExecutor::execute 函数。

继续 next 直到 showSpaces()，step 进入此函数

auto future = ectx()->getMetaClient()->listSpaces();
auto *runner = ectx()->rctx()->runner();
'''
'''
std::move(future).via(runner).thenValue(cb).thenError(error);

此时 Query Service 通过 metaClient 和 Meta Service 通信拿到 spaces 数据，之后通过回调函数 cb 回传拿到的数据，至此 nGQL 语句 SHOW SPACES; 已经执行完毕，而其他复杂的语句也可以以此类推。

如果是正在运行的服务，可以先查出该服务的进程 ID，然后通过 gdb attach PID 来调试该进程；
如果不想启动服务端和客户端进行调试，在 src 目录下的每个文件夹下都有一个 test 目录，里面都是对对应模块或者功能进行的单元测试，可以直接编译对应的单元模块，然后跟踪运行。方法如下:
1. 通过对应目录下的 CMakeLists.txt 文件找到对应的模块名
2. 在 build 目录下 make 模块名，在 build/bin/test 目录下生成对应的二进制程序
3. gdb 跟踪调试该程序

附录

阅读 Nebula Graph 源码需要了解的一些库：

flex & bison：词法分析和语法分析工具，将客户端输入的 nGQL 语句解析为抽象语法树
FBThrift：Facebook 开源的 RPC 框架，定义并生成了 Meta 层、Storage 层和 Graph 层的通讯过程代码
folly：Facebook 开源的 C++14 组件库，提供了类似 Boost 和 std 库的功能，在性能上更加优化
Gtest：Google 开源的 C++ 单元测试框架

其中数据库资料可以参考：

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

作者有话说：Hi，我是明泉，是图数据 Nebula Graph 研发工程师，主要工作和数据库查询引擎相关，希望本次的经验分享能给大家带来帮助，如有不当之处也希望能帮忙纠正，谢谢~

关系型数据库查询语言 SQL 和图数据库查询语言 nGQL 对比

NebulaGraph — Thu, 23 Jul 2020 10:54:48 +0800

摘要：这篇文章将介绍图数据库 Nebula Graph 的查询语言 nGQL 和 SQL 的区别。

本文首发于 Nebula Graph 官方博客：https://nebula-graph.com.cn/posts/sql-vs-ngql-comparison/

虽然本文主要介绍 nGQL 和 SQL 的区别，但是我们不会深入探讨这两种语言，而是将这两种语言做对比，以帮助你从 SQL 过渡到 nGQL。

SQL (Structured Query Language) 是具有数据操纵和数据定义等多种功能的数据库语言，这种语言是一种特定目的编程语言，用于管理关系数据库管理系统（RDBMS），或在关系流数据管理系统（RDSMS）中进行流处理。

nGQL 是一种类 SQL 的声明型的文本查询语言，相比于 SQL，nGQL 为可扩展、支持图遍历、模式匹配、分布式事务（开发中）的图数据库查询语言。

概念对比

语法对比

数据定义语言 (DDL)

数据定义语言（DDL）用于创建或修改数据库的结构，也就是 schema。

索引

数据操作语言（DML）

数据操作语言（DML）用于操作数据库中的数据。

数据查询语言（DQL）

数据查询语言（DQL）语句用于执行数据查询。本节说明如何使用 SQL 语句和 nGQL 语句查询数据。

SELECT
 [DISTINCT]
 select_expr [, select_expr] ...
 [FROM table_references]
 [WHERE where_condition]
 [GROUP BY {col_name | expr | position}]
 [HAVING  where_condition]
 [ORDER BY {col_name | expr | position} [ASC | DESC]]

GO [[<M> TO] <N> STEPS ] FROM <node_list>
 OVER <edge_type_list> [REVERSELY] [BIDIRECT]
 [WHERE where_condition]
 [YIELD [DISTINCT] <return_list>]
 [| ORDER BY <expression> [ASC | DESC]]
 [| LIMIT [<offset_value>,] <number_rows>]
 [| GROUP BY {col_name | expr | position} YIELD <col_name>]

<node_list>
   | <vid> [, <vid> ...]
   | $-.id

<edge_type_list>
   edge_type [, edge_type ...]

<return_list>
    <col_name> [AS <col_alias>] [, <col_name> [AS <col_alias>] ...]

数据控制语言（DCL）

数据控制语言（DCL）包含诸如 GRANT 和 REVOKE 之类的命令，这些命令主要用来处理数据库系统的权限、其他控件。

数据模型

查询语句基于以下数据模型：

RDBMS 关系结构图

Nebula Graph 最小模型图

本文将使用 NBA 数据集。该数据集包含两种类型的点，也就是两个标签，即 player 和 team ；两种类型的边，分别是 serve 和 follow。

在关系型数据管理系统中（RDBMS）中，我们用表来表示点以及与点相关的边（连接表）。因此，我们创建了以下表格：player、team、serve 和 follow。在 Nebula Graph 中，基本数据单位是顶点和边。两者都可以拥有属性，相当于 RDBMS 中的属性。

在 Nebula Graph 中，点之间的关系由边表示。每条边都有一种类型，在 NBA 数据集中，我们使用边类型 serve 和 follow 来区分两种类型的边。

示例数据

在 RDBMS 插入数据

首先，让我们看看如何在 RDBMS 中插入数据。我们先创建一些表，然后为这些表插入数据。

CREATE TABLE player (id INT, name VARCHAR(100), age INT);
CREATE TABLE team (id INT, name VARCHAR(100));
CREATE TABLE serve (player_id INT, team_id INT, start_year INT, end_year INT);
CREATE TABLE follow (player_id1 INT, player_id2 INT, degree INT);

然后插入数据。

INSERT INTO player
VALUES
   (100, 'Tim Duncan', 42),
   (101, 'Tony Parker', 36),
   (102, 'LaMarcus Aldridge', 33),
   (103, 'Rudy Gay',32),
   (104, 'Marco Belinelli', 32),
   (105, 'Danny Green', 31),
   (106, 'Kyle Anderson', 25),
   (107, 'Aron Baynes', 32),
   (108, 'Boris Diaw', 36),
   (109, 'Tiago Splitter', 34),
   (110, 'Cory Joseph', 27);

INSERT INTO team
VALUES
   (200, 'Warriors'),
   (201, 'Nuggets'),
   (202, 'Rockets'),
   (203, 'Trail'),
   (204, 'Spurs'),
   (205, 'Thunders'),
   (206, 'Jazz'),
   (207, 'Clippers'),
   (208, 'Kings');

INSERT INTO serve
VALUES
   (100,200,1997,2016),
   (101,200,1999,2010),
   (102,200,2001,2005),
   (106,200,2000,2011),
   (107,200,2001,2009),
   (103,201,1999,2018),
   (104,201,2006,2015),
   (107,201,2007,2010),
   (108,201,2010,2016),
   (109,201,2011,2015),
   (105,202,2015,2019),
   (109,202,2017,2019),
   (110,202,2007,2009);

INSERT INTO follow
VALUES
   (100,101,95),
   (100,102,91),
   (100,106,90),
   (101,100,95),
   (101,102,91),
   (102,101,75),
   (103,102,70),
   (104,103,50),
   (104,105,60),
   (105,104,83),
   (105,110,87),
   (106,100,88),
   (106,107,81),
   (107,106,92),
   (107,108,97),
   (108,109,95),
   (109,110,78),
   (110,109,72),
   (110,105,85);

在 Nebula Graph 插入数据

在 Nebula Graph 中插入数据与上述类似。首先，我们需要定义好数据结构，也就是创建好 schema。然后可以选择手动或使用 Nebula Graph Studio （Nebula Graph 的可视化工具）导入数据。这里我们手动添加数据。

在下方的 INSERT 插入语句中，我们向图空间 NBA 插入了球员数据（这和在 MySQL 中插入数据类似）。

INSERT VERTEX player(name, age) VALUES
100: ('Tim Duncan', 42),
101: ('Tony Parker', 36),
102: ('LaMarcus Aldridge', 33),
103: ('Rudy Gay', 32),
104: ('Marco Belinelli', 32),
105: ('Danny Green', 31),
106: ('Kyle Anderson', 25),
107: ('Aron Baynes', 32),
108: ('Boris Diaw', 36),
109: ('Tiago Splitter', 34),
110: ('Cory Joseph', 27);

考虑到篇幅限制，此处我们将跳过插入球队和边的重复步骤。你可以点击此处下载示例数据亲自尝试。

增删改查（CRUD）

本节介绍如何使用 SQL 和 nGQL 语句创建（C）、读取（R）、更新（U）和删除（D）数据。

插入数据

mysql> INSERT INTO player VALUES (100, 'Tim Duncan', 42);

nebula> INSERT VERTEX player(name, age) VALUES 100: ('Tim Duncan', 42);

查询数据

查找 ID 为 100 的球员并返回其 name 属性：

mysql> SELECT player.name FROM player WHERE player.id = 100;

nebula> FETCH PROP ON player 100 YIELD player.name;

更新数据

mysql> UPDATE player SET name = 'Tim';

nebula> UPDATE VERTEX 100 SET player.name = "Tim";

删除数据

mysql> DELETE FROM player WHERE name = 'Tim';

nebula> DELETE VERTEX 121;
nebula> DELETE EDGE follow 100 -> 200;

建立索引

返回年龄超过 36 岁的球员。

SELECT player.name
FROM player
WHERE player.age < 36;

使用 nGQL 查询有些不同，因为您必须在过滤属性之前创建索引。更多信息请参见索引文档。

CREATE TAG INDEX player_age ON player(age);
REBUILD TAG INDEX player_age OFFLINE;
LOOKUP ON player WHERE player.age < 36;

示例查询

本节提供一些示例查询供您参考。

示例 1

在表 player 中查询 ID 为 100 的球员并返回其 name 属性。

SELECT player.name
FROM player
WHERE player.id = 100;

接下来使用 Nebula Graph 查找 ID 为 100 的球员并返回其 name 属性。

FETCH PROP ON player 100 YIELD player.name;

Nebula Graph 使用 FETCH 关键字获取特定点或边的属性。本例中，属性即为点 100 的名称。nGQL 中的 YIELD 关键字相当于 SQL 中的 SELECT。

示例 2

查找球员 Tim Duncan 并返回他效力的所有球队。

SELECT a.id, a.name, c.name
FROM player a
JOIN serve b ON a.id=b.player_id
JOIN team c ON c.id=b.team_id
WHERE a.name = 'Tim Duncan'

使用如下 nGQL 语句完成相同操作：

CREATE TAG INDEX player_name ON player(name);
REBUILD TAG INDEX player_name OFFLINE;
LOOKUP ON player WHERE player.name == 'Tim Duncan' YIELD player.name AS name | GO FROM $-.VertexID OVER serve YIELD $-.name, $$.team.name;

这里需要注意一下，在 nGQL 中的等于操作采用的是 C 语言风格的 ==，而不是 SQL 风格的 =。

示例 3

以下查询略复杂，现在我们来查询球员 Tim Duncan 的队友。

SELECT a.id, a.name, c.name
FROM player a
JOIN serve b ON a.id=b.player_id
JOIN team c ON c.id=b.team_id
WHERE c.name IN (SELECT c.name
FROM player a
JOIN serve b ON a.id=b.player_id
JOIN team c ON c.id=b.team_id
WHERE a.name = 'Tim Duncan')

nGQL 则使用管道将前一个子句的结果作为下一个子句的输入。

GO FROM 100 OVER serve YIELD serve._dst AS Team | GO FROM $-.Team OVER serve REVERSELY YIELD $$.player.name;

您可能已经注意到了，我们仅在 SQL 中使用了 JOIN。这是因为 Nebula Graph 只是使用类似 Shell 的管道对子查询进行嵌套，这样更符合我们的阅读习惯也更简洁。

参考资料

我们建议您亲自尝试上述查询语句，这将帮您更好地理解 SQL 和 nGQL，并节省您上手 nGQL 的学习时间。以下是一些参考资料：

作者有话说：Hi，Hi，大家好，我是 Amber，Nebula Graph 的文档工程师，希望上述内容可以给大家带来些许启发。限于水平，如有不当之处还请斧正，在此感谢^^

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

浅析图数据库 Nebula Graph 数据导入工具——Spark Writer

NebulaGraph — Fri, 17 Jul 2020 10:10:09 +0800

从 Hadoop 说起

近年来随着大数据的兴起，分布式计算引擎层出不穷。Hadoop 是 Apache 开源组织的一个分布式计算开源框架，在很多大型网站上都已经得到了应用。Hadoop 的设计核心思想来源于 Google MapReduce 论文，灵感来自于函数式语言中的 map 和 reduce 方法。在函数式语言中，map 表示针对列表中每个元素应用一个方法，reduce 表示针对列表中的元素做迭代计算。通过 MapReduce 算法，可以将数据根据某些特征进行分类规约，处理并得到最终的结果。

再谈 Apache Spark

Apache Spark 是一个围绕速度、易用性构建的通用内存并行计算框架。在 2009 年由加州大学伯克利分校 AMP 实验室开发，并于 2010 年成为 Apache 基金会的开源项目。Spark 借鉴了 Hadoop 的设计思想，继承了其分布式并行计算的优点，提供了丰富的算子。

Spark 提供了一个全面、统一的框架用于管理各种有着不同类型数据源的大数据处理需求，支持批量数据处理与流式数据处理。Spark 支持内存计算，性能相比起 Hadoop 有着巨大提升。Spark 支持 Java，Scala 和 Python 三种语言进行编程，支持以操作本地集合的方式操作分布式数据集，并且支持交互查询。除了经典的 MapReduce 操作之外，Spark 还支持 SQL 查询、流式处理、机器学习和图计算。

弹性分布式数据集（RDD，Resilient Distributed Dataset）是 Spark 最基本的抽象，代表不可变的分区数据集。RDD 具有可容错和位置感知调度的特点。操作 RDD 就如同操作本地数据集合，而不必关心任务调度与容错等问题。RDD 允许用户在执行多个查询时，显示地将工作集合缓存在内存中，后续查询能够重用该数据集。RDD 通过一系列的转换就就形成了 DAG，根据 RDD 之间的依赖关系的不同将 DAG 划分成不同的 Stage。

与 RDD 相似，DataFrame 也是一个不可变分布式数据集合。区别于 RDD，DataFrame 中的数据被组织到有名字的列中，就如同关系型数据库中的表。设计 DataFrame 的目的就是要让对大型数据集的处理变得更简单，允许开发者为分布式数据集指定一个模式，便于进行更高层次的抽象。

DataSet 是一个支持强类型的特定领域对象，这种对象可以函数式或者关系操作并行地转换。DataSet 就是一些有明确类型定义的 JVM 对象的集合，可以通过 Scala 中定义的 Case Class 或者 Java 中的 Class 来指定。DataFrame 是 Row 类型的 Dataset，即 Dataset[Row]。DataSet 的 API 是强类型的；而且可以利用这些模式进行优化。

DataFrame 与 DataSet 只在执行行动操作时触发计算。本质上，数据集表示一个逻辑计划，该计划描述了产生数据所需的计算。当执行行动操作时，Spark 的查询优化程序优化逻辑计划，并生成一个高效的并行和分布式物理计划。

基于 Spark 的数据导入工具

Spark Writer 是 Nebula Graph 基于 Spark 的分布式数据导入工具，基于 DataFrame 实现，能够将多种数据源中的数据转化为图的点和边批量导入到图数据库中。

目前支持的数据源有：Hive 和 HDFS。

Spark Writer 支持同时导入多个标签与边类型，不同标签与边类型可以配置不同的数据源。

Spark Writer 通过配置文件，从数据中生成一条插入语句，发送给查询服务，执行插入操作。Spark Writer 中插入操作使用异步执行，通过 Spark 中累加器统计成功与失败数量。

获取 Spark Writer

编译源码

git clone https://github.com/vesoft-inc/nebula.git  
cd nebula/src/tools/spark-sstfile-generator  
mvn compile package

标签数据文件格式

标签数据文件由一行一行的数据组成，文件中每一行表示一个点和它的属性。一般来说，第一列为点的 ID ——此列的名称将在后文的映射文件中指定，其他列为点的属性。例如 Play 标签数据文件格式：

{"id":100,"name":"Tim Duncan","age":42}  
{"id":101,"name":"Tony Parker","age":36}  
{"id":102,"name":"LaMarcus Aldridge","age":33}

边类型数据文件格式

边类型数据文件由一行一行的数据组成，文件中每一行表示一条边和它的属性。一般来说，第一列为起点 ID，第二列为终点 ID，起点 ID 列及终点 ID 列会在映射文件中指定。其他列为边属性。下面以 JSON 格式为例进行说明。

以边类型 follow 数据为例：

{"source":100,"target":101,"likeness":95}  
{"source":101,"target":100,"likeness":95}  
{"source":101,"target":102,"likeness":90}  
{"source":100,"target":101,"likeness":95,"ranking":2}  
{"source":101,"target":100,"likeness":95,"ranking":1}  
{"source":101,"target":102,"likeness":90,"ranking":3}

配置文件格式

Spark Writer 使用 HOCON 配置文件格式。HOCON（Human-Optimized Config Object Notation）是一个易于使用的配置文件格式，具有面向对象风格。配置文件由 Spark 配置段，Nebula 配置段，以及标签配置段和边配置段四部分组成。

Spark 信息配置了 Spark 运行的相关参数，Nebula 相关信息配置了连接 Nebula 的用户名和密码等信息。tags 映射和 edges 映射分别对应多个 tag/edge 的输入源映射，描述每个 tag/edge 的数据源等基本信息，不同 tag/edge 可以来自不同数据源。

Nebula 配置段主要用于描述 nebula 查询服务地址、用户名和密码、图空间信息等信息。

nebula: {  
  # 查询引擎 IP 列表  
  addresses: ["127.0.0.1:3699"]  
  
  # 连接 Nebula Graph 服务的用户名和密码  
  user: user  
  pswd: password  
  
  # Nebula Graph 图空间名称  
  space: test  
  
  # thrift 超时时长及重试次数，默认值分别为 3000 和 3  
  connection {  
    timeout: 3000  
    retry: 3  
  }  
  
  # nGQL 查询重试次数，默认值为 3  
  execution {  
    retry: 3  
  }  
}

Nebula 配置段

标签配置段用于描述导入标签信息，数组中每个元素为一个标签信息。标签导入主要分为两种：基于文件导入与基于 Hive 导入。

基于文件导入配置需指定文件类型
基于 Hive 导入配置需指定执行的查询语言。

# 处理标签  
tags: [  
  
  # 从 HDFS 文件加载数据， 此处数据类型为 Parquet tag 名称为 ${TAG_NAME}  
  #  HDFS Parquet 文件的中的 field_0、field_1将写入 ${TAG_NAME}  
  # 节点列为 ${KEY_FIELD}
  {  
    name: ${TAG_NAME}  
    type: parquet  
    path: ${HDFS_PATH}  
    fields: {  
      field_0: nebula_field_0,  
      field_1: nebula_field_1  
    }  
    vertex: ${KEY_FIELD}  
    batch : 16  
  }  
  
  # 与上述类似  
  # 从 Hive 加载将执行命令 $ {EXEC} 作为数据集  
  {  
    name: ${TAG_NAME}  
    type: hive  
    exec: ${EXEC}  
    fields: {  
      hive_field_0: nebula_field_0,  
      hive_field_1: nebula_field_1  
    }  
    vertex: ${KEY_FIELD}
  }  
]

说明：

name 字段用于表示标签名称
fields 字段用于配置 HDFS 或 Hive 字段与 Nebula 字段的映射关系
batch 参数意为一次批量导入数据的记录数，需要根据实际情况进行配置。

边类型配置段用于描述导入标签信息，数组中每个元素为一个边类型信息。边类型导入主要分为两种：基于文件导入与基于 Hive 导入。

基于文件导入配置需指定文件类型

基于 Hive 导入配置需指定执行的查询语言

# 处理边  
edges: [  
  # 从 HDFS 加载数据，数据类型为 JSON  
  # 边名称为 ${EDGE_NAME}  
  # HDFS JSON 文件中的 field_0、field_1 将被写入${EDGE_NAME}  
  # 起始字段为 source_field，终止字段为 target_field ，边权重字段为 ranking_field。  
  {  
    name: ${EDGE_NAME}  
    type: json  
    path: ${HDFS_PATH}  
    fields: {  
      field_0: nebula_field_0,  
      field_1: nebula_field_1  
    }  
    source:  source_field  
    target:  target_field  
    ranking: ranking_field  
  }  
  
  # 从 Hive 加载将执行命令 ${EXEC} 作为数据集  
  # 边权重为可选  
  {  
    name: ${EDGE_NAME}  
    type: hive  
    exec: ${EXEC}  
    fields: {  
      hive_field_0: nebula_field_0,  
      hive_field_1: nebula_field_1  
    }  
    source:  source_id_field  
    target:  target_id_field  
  }  
]

说明：

name 字段用于表示边类型名称
fields 字段用于配置 HDFS 或 Hive 字段与 Nebula 字段的映射关系
source 字段用于表示边的起点
target 字段用于表示边的终点
ranking 字段用于表示边的权重
batch 参数意为一次批量导入数据的记录数，需要根据实际情况进行配置。

导入数据命令

bin/spark-submit \  
 --class com.vesoft.nebula.tools.generator.v2.SparkClientGenerator \  
 --master ${MASTER-URL} \  
 ${SPARK_WRITER_JAR_PACKAGE} -c conf/test.conf -h -d

说明：

-c：config 用于指定配置文件路径
-h：hive 用于指定是否支持 Hive
-d：dry 用于测试配置文件是否正确，并不处理数据。

作者有话说：Hi，大家好，我是 darion，Nebula Graph 的软件工程师，对分布式系统方面有些小心得，希望上述文章可以给大家带来些许启发。限于水平，如有不当之处还请斧正，在此感谢^^

喜欢这篇文章？来来来，给我们的 GitHub 点个 star 表鼓励啦~~ 🙇‍♂️🙇‍♀️ [手动跪谢]

交流图数据库技术？交个朋友，Nebula Graph 官方小助手微信：NebulaGraphbot 拉你进交流群~~

暗黑模式的 Ruby China 好酷炫

NebulaGraph — Thu, 16 Jul 2020 18:00:23 +0800

一周上一次 Ruby China 的选手路过，打开发现是个黑色界面，感觉好酷炫，找了下没有找到对应的官方帖子可以进去戳个小爱心的，😂 开了个新帖

暗黑模式 💯 😍

NebulaGraph (NebulaGraph)

集群通信：从心跳说起

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

1. 服务发现

2. 上报节点信息

3. 更新元信息

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

心跳的演变历史

额外的补充

推荐阅读

[北京 / 上海 / 深圳 / 杭州] 技术布道师 20k-40k 15 薪

Nebula Graph 社区布道师

关于布道师

岗位职责

岗位要求

联系我们

图数据库 Nebula Graph 在 Boss 直聘的应用

业务背景

技术指标

硬件

软件

配置

指标

Dgraph 使用对比

建议

参考文章

推荐阅读

Spark Connector Reader 原理与实践

Spark Connector 简介

Spark Connector Reader 原理

Basic Interfaces

Providers

RDD

Spark Connector Reader 实践

其他

参考资料

记一起由 Clang 编译器优化触发的 Crash

推荐阅读

GraphX 在图数据库 Nebula Graph 的图计算实践

一、背景

二、算法应用

PageRank

PageRank 简介

PageRank 应用场景

社交应用的相似度内容推荐

分析用户社交影响力

文献重要性研究

算法思路

Louvain 社区发现

Louvain 算法介绍

模块度

Louvain 应用场景

Louvain 算法思路

三、算法实践

演示环境

测试数据

如何使用 Nebula Graph 的算法

References

推荐阅读

调试 Docker 容器内部进程

需求

演示

总结

推荐阅读

主流开源分布式图数据库 Benchmark

1. 前言

2. 测试概要

2.1 硬件配置

2.2 部署方案

3. 评测数据集

4. 测试结果

4.1 批量数据导入

4.1.1 测试说明

4.1.2 测试结果

4.1.3 数据分析

4.2 实时数据写入

4.2.1 测试说明

4.2.2 测试结果

4.2.3 数据分析

4.3 数据查询