自从开发完 NebulaGraph Exchange,混迹在各个 NebulaGraph 微信群的我经常会看到一类提问是:NebulaGraph Exchange 的性能如何?哪些参数调整下可以有更好的性能?…索性来一篇文章从实测出发,和大家讲讲如何用好这个数据工具。在本文你将获得 NebulaGraph Exchange 的最佳使用姿势。

01. 环境准备

硬件:

  • Spark 集群:三台机器,每台 96 core,256 G 内存
  • NebulaGraph 集群:三台机器,每台 128 core,252 G 内存,SSD,双万兆网卡
  • 数据:LDBC sf100 数据

软件:

  • Spark 版本:2.4.4
  • NebulaGraph 版本:3.3.0

02. NebulaGraph 优化配置

在进行大批量数据导入时,可以调整 NebulaGraph Storage 服务和 Graph 服务的配置,以达到最大导入性能。请根据 NebulaGraph 的配置描述和你的实际环境资源进行参数调整。

在本次实践中,NebulaGraph 的集群配置针对以下几个配置项进行了修改,其他均采用默认配置:

"storaged":
--rocksdb_block_cache=81920,
--heartbeat_interval_secs=10,
--reader_handlers=64,
--num_worker_threads=64,
--rocksdb_db_options={"max_subcompactions":"64","max_background_jobs":"64"} "graphd":
--storage_client_timeout_ms=360000,
--session_idle_timeout_secs=2880,
--max_sessions_per_ip_per_user=500000,
--num_worker_threads=64

NebulaGraph Storage 服务优化

在这里简单讲一下几个 Storage 服务优化配置项:

  • --rocksdb_block_cache 数据在内存缓存大小,默认是 4 MB,大批量数据导入时可以设置到当前内存的 1/3;
  • --num_worker_threads storaged 的 RPC 服务的工作线程数量,默认 32;
  • --query_concurrentlytrue 表示 storaged 会并发地读取数据,false 表示 storaged 是单线程取数;
  • --rocksdb_db_options={"max_subcompactions":"48","max_background_jobs":"48"}:可用来加速自动 Compaction 过程;
  • --rocksdb_column_family_options={"write_buffer_size":"67108864","max_write_buffer_number":"5"},在刚开始导入大量数据时可以将 disable_auto_compaction 选项设置为 true,提升写入的性能;
  • --wal_ttl=600 在大量数据导入时,若磁盘不充裕,那么该参数需调小,不然可能会因为产生大量的 wal 导致磁盘空间被撑满。

NebulaGraph Graph 服务优化

再简单地罗列下 Graph 服务相关的一些优化配置项:

  • --storage_client_timeout_ms 为 graphd 与 storaged 通信的超时时间;
  • --max_sessions_per_ip_per_user 是单用户单 IP 客户端允许创建的最大 session 数;
  • --system_memory_high_watermark_ratio 设置内存使用量超过多少时停止计算,表示资源的占用率,一般设置为 0.8~1.0 之间;
  • --num_worker_threads 为 graphd 的 RPC 服务的工作线程数量,默认 32。

03. NebulaGraph DDL

下面,我们通过这些语句来创建下 Schema 方便后续导入数据:

CREATE SPACE sf100(vid_type=int64,partition_num=100,replica_factor=3);
USE sf100;
CREATE TAG IF NOT EXISTS `Place`(`name` string,`url` string,`type` string);
CREATE TAG IF NOT EXISTS `Comment`(`creationDate` string,`locationIP` string,`browserUsed` string,`content` string,`length` int);
CREATE TAG IF NOT EXISTS `Organisation`(`type` string,`name` string,`url` string);
CREATE TAG IF NOT EXISTS `Person`(`firstName` string,`lastName` string,`gender` string,`birthday` string,`creationDate` string,`locationIP` string,`browserUsed` string);
CREATE TAG IF NOT EXISTS `Tagclass`(`name` string,`url` string);
CREATE TAG IF NOT EXISTS `Forum`(`title` string,`creationDate` string);
CREATE TAG IF NOT EXISTS `Post`(`imageFile` string,`creationDate` string,`locationIP` string,`browserUsed` string,`language` string,`content` string,`length` int);
CREATE TAG IF NOT EXISTS `Tag`(`name` string,`url` string);
CREATE EDGE IF NOT EXISTS `IS_PART_OF`();
CREATE EDGE IF NOT EXISTS `LIKES`(`creationDate` string);
CREATE EDGE IF NOT EXISTS `HAS_CREATOR`();
CREATE EDGE IF NOT EXISTS `HAS_INTEREST`();
CREATE EDGE IF NOT EXISTS `IS_SUBCLASS_OF`();
CREATE EDGE IF NOT EXISTS `IS_LOCATED_IN`();
CREATE EDGE IF NOT EXISTS `HAS_MODERATOR`();
CREATE EDGE IF NOT EXISTS `HAS_TAG`();
CREATE EDGE IF NOT EXISTS `WORK_AT`(`workFrom` int);
CREATE EDGE IF NOT EXISTS `REPLY_OF`();
CREATE EDGE IF NOT EXISTS `STUDY_AT`(`classYear` int);
CREATE EDGE IF NOT EXISTS `CONTAINER_OF`();
CREATE EDGE IF NOT EXISTS `HAS_MEMBER`(`joinDate` string);
CREATE EDGE IF NOT EXISTS `KNOWS`(`creationDate` string);
CREATE EDGE IF NOT EXISTS `HAS_TYPE`();

04. LDBC sf100 数据集的数据量

该表展示了各类点边的数据量

Label Amount
Comment 220,096,052
Forum 4,080,604
Organisation 7,955
Person 448,626
Place 1,460
Post 57,987,023
Tag 16,080
Tagclass 71
CONTAINER_OF 57,987,023
HAS_CREATOR 278,083,075
HAS_INTEREST 10,471,962
HAS_MEMBER 179,874,360
HAS_MODERATOR 4,080,604
HAS_TAG 383,613,078
HAS_TYPE 16,080
IS_LOCATED_IN 278,539,656
IS_PART_OF 1,454
IS_SUBCLASS_OF 70
KNOWS 19,941,198
LIKES 341,473,012
REPLY_OF 2,200,960,52
STUDY_AT 359,212
WORK_AT 976,349

05. NebulaGraph Exchange 配置

重点来了,看好这个配置,如果下次还有小伙伴配置配错了导致数据导入报错的话,我可是要丢这篇文章的链接了。app.conf 如下:

{
# Spark 相关配置
spark: {
app: {
name: Nebula Exchange
}
} # NebulaGraph 相关配置
nebula: {
address:{
graph:["192.168.xx.8:9669","192.168.xx.9:9669","192.168.xx.10:9669"] //因为实验环境是集群,这里配置了 3 台机器的 graphd 地址
meta:["192.168.xx.8:9559"] //无需配置多台机器的 meta 地址,随机配一个就行
}
user: root
pswd: nebula
space: sf100 // 之前 Schema 创建的图空间名 # NebulaGraph 客户端连接参数设置
connection {
timeout: 30000 //超过 30000ms 无响应会报错
} error: {
max: 32
output: /tmp/errors
} # 使用 Google 的 RateLimiter 限制发送到 NebulaGraph 的请求
rate: {
limit: 1024
timeout: 1000
}
} # 这里开始处理点数据,进行之前的 Schema 和数据映射
tags: [
{
name: Person // tagName 为 Person
type: {
source: csv //指定数据源类型
sink: client //指定如何将点数据导入 NebulaGraph,client 或 sst
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person.csv" // 数据文件的所在路径,如果文件存储在 HDFS 上,用双引号括起路径,以 hdfs:// 开头,例如 "hdfs://ip:port/xx/xx"。如果文件存储在本地,用双引号括起路径,以 file:// 开头,例如 "file:///tmp/xx.csv"。
fields: [_c1,_c2,_c3,_c4,_c5,_c6,_c7] // 无表头,_cn 表示表头
nebula.fields: [firstName,lastName,gender,birthday,creationDate,locationIP,browserUsed] // tag 的属性映射,_c1 对应 firstName
vertex: _c0 // 指定 vid 的列
batch: 2000 // 单次请求写入多少点数据
partition: 180 // Spark partition 数
separator: | // 属性分隔符
header: false // 无表头设置,false 表示无表头
} {
name: Place
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/place.csv"
fields: [_c1,_c2,_c3]
nebula.fields: [name, type, url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
} {
name: Organisation
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/organisation.csv"
fields: [_c1,_c2,_c3]
nebula.fields: [name, type,url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
} {
name: Post
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post.csv"
fields: [_c1,_c2,_c3,_c4,_c5,_c6,_c7]
nebula.fields: [imageFile,creationDate,locationIP,browserUsed,language,content,length]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
} {
name: Comment
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment.csv"
fields: [_c1,_c2,_c3,_c4,_c5]
nebula.fields: [creationDate,locationIP,browserUsed,content,length]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
} {
name: Forum
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum.csv"
fields: [_c1,_c2]
nebula.fields: [creationDate,title]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
} {
name: Tag
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tag.csv"
fields: [_c1,_c2]
nebula.fields: [name,url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
} {
name: Tagclass
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tagclass.csv"
fields: [_c1,_c2]
nebula.fields: [name,url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
] # 开始处理边数据
edges: [
{
name: KNOWS //边类型
type: {
source: csv //文件类型
sink: client //同上 tag 的 sink 说明
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_knows_person.csv" //同上 tag 的 path 说明
fields: [_c2] //无表头的,设定 _c2 为表头
nebula.fields: [creationDate] // 属性值和表头映射,这里为 KNOW 类型边中的 creationDate 属性
source: {
field: _c0 // 源数据中作为 KNOW 类型边起点的列
}
target: {
field: _c1 // 源数据中作为 KNOW 类型边终点的列
}
batch: 2000 // 单批次写入的最大边数据
partition: 180 //同上 tag 的 partition 说明
separator: | //同上 tag 的 separator 说明
header: false // 同上 tag 的 header 说明
} {
name: LIKES
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_likes_comment.csv"
fields: [_c2]
nebula.fields: [creationDate]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: LIKES
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_likes_post.csv"
fields: [_c2]
nebula.fields: [creationDate]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_TAG
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_hasTag_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_TAG
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_hasTag_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_TAG
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post_hasTag_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_TYPE
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tag_hasType_tagclass.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_MODERATOR
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_hasModerator_person.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_MEMBER
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_hasMember_person.csv"
fields: [_c2]
nebula.fields: [joinDate]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_INTEREST
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_hasInterest_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_CREATOR
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post_hasCreator_person.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: HAS_CREATOR
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_hasCreator_person.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: IS_PART_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/place_isPartOf_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: CONTAINER_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_containerOf_post.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/organisation_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: REPLY_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_replyOf_comment.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: REPLY_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_replyOf_post.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: STUDY_AT
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_studyAt_organisation.csv"
fields: [_c2]
nebula.fields: [classYear]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: WORK_AT
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_workAt_organisation.csv"
fields: [_c2]
nebula.fields: [workFrom]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
} {
name: IS_SUBCLASS_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tagclass_isSubclassOf_tagclass.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
]
}

在上面的第一次配置 tag 和 edge 的时候,我增加了一些字段说明,具体的大家可以翻阅下 NebulaGraph Exchange 的文档来获得更详细的说明:https://docs.nebula-graph.com.cn/3.3.0/nebula-exchange/use-exchange/ex-ug-import-from-csv/

06. Spark 提交参数配置

Spark 集群有三个节点,每个节点配置为 96 core, 256 G 内存。

配置的 Spark 提交命令如下:

spark-submit --master "spark://127.0.0.1:7077" \
--driver-memory=2G \
--executor-memory=30G \
--total-executor-cores=120 \
--executor-cores=10 \
--num-executors=3 \ // 对 standalone 模式无效
--class com.vesoft.nebula.exchange.Exchange \
nebula-exchange_spark_2.4-3.3.0.jar -c app.conf

07. 测试结果

在测试中,我们修改了 NebulaGraph Exchange 配置文件中的 batch 数、partition 数和 spark-submit 提交命令中的 total-executor-cores 数来调整导入的并发度,导入结果如下:

Dataset Data Amount NebulaGraph storaged.conf: max_subcompactions NebulaGraph storaged.conf: disable_auto_compaction Spark: total-executor-cores Spark:executor-cores Spark:executor-memory Exchange conf : batch Exchange conf: partition duration
LDBC sf100 vertex:282,386,021,edge:1,775,513,185 4 FALSE 120 10 30 G 2,000 360 1.9 h
LDBC sf100 vertex:282,386,021,edge:1,775,513,185 64 FALSE 120 10 30 G 2,000 360 1.0 h
LDBC sf100 vertex:282,386,021,edge:1,775,513,185 64 FALSE 180 10 30 G 2,000 360 1.1 h
LDBC sf100 vertex:282,386,021,edge:1,775,513,185 64 FALSE 180 10 30 G 3,000 360 1.0 h
LDBC sf100 vertex:282,386,021,edge:1,775,513,185 64 FALSE 90 10 30 G 2,000 180 1.1 h

max_subcompaction 为 64 时,NebulaGraph 机器的磁盘和网络 io 使用情况(时间 15:00 之后的部分)如下:

在进行导入时,storaged 服务的 max_subcompaction 配置对导入性能有很大影响。当 NebulaGraph 机器的 io 达到极限时,应用层的配置参数对导入性能影响甚微

08. 关键性能字段

这里,再单独拉出来关键字段来讲下,大家可以根据自身的数据量、机器配置来调整相关参数。

NebulaGraph Exchange 的 app.conf

这里需要重点关注前面两个字段,当然后面的字段也不是不重要:

  • partition根据 Spark 集群的机器核数决定 partition 配置项的值。partition 的值是 spark-submit 命令中配置的总核数的 2-3 倍,其中:总核数 = num-executors * executor-cores。
  • batch,client 向 graphd 发送的一个请求中有多少条数据。在该实践中采用的 LDBC 数据集的 tag 属性不超过 10 个,设置的 batch 数为 2,000。如果 tag 或 edgeType 属性多且字节数多,batch 可以调小,反之,则调大。
  • nebula.connection.timeout,NebulaGraph 客户端与服务端连接和请求的超时时间。若网络环境较差,数据导入过程出现 "connection timed out",可适当调大该参数。(read timed out 与该配置无关)
  • nebula.error.max,允许发生的最大失败次数。当客户端向服务端发送请求的失败数超过该值,则 NebulaGraph Exchange 退出。
  • nebula.error.output,导入失败的数据会被存入该目录。
  • nebula.rate.limit,采用令牌桶限制 NebulaGraph Exchange 向 NebulaGraph 发送请求的速度,limit 值为每秒向令牌桶中创建的令牌数
  • nebula.rate.timeout,当速度受阻无法获取令牌时,允许最大等待的时间,超过该时间获取不到令牌则 NebulaGraph Exchange 退出。单位:ms。

Spark 的 spark-submit

这里主要讲下 spark-submit 命令关键性使用指引,详细内容可参考 Spark 文档:https://spark.apache.org/docs/latest/spark-standalone.html

spark-submit 有多种提交方式,这里以 standalone 和 yarn 两种为例:

  • standalone 模式:spark://master_ip:port
  • yarn 模式:由于 yarn cluster 模式下会随机选择一台机器作为 driver 进行 job 提交。如果作为 driver 的那个机器中没有 NebulaGraph Exchange 的 jar 包和配置文件,会出现 "ClassNotFound" 的异常,参考论坛帖子:https://discuss.nebula-graph.com.cn/t/topic/9766。所以,yarn 模式下需要在 spark-submit 命令中配置以下参数:
--files app.conf \
--conf spark.driver.extraClassPath=./ \ // 指定 NebulaGraph Exchange jar 包和配置文件所在的目录
--conf spark.executor.extraClassPath=./ \ // 指定 NebulaGraph Exchange jar 包和配置文件所在的目录

除了提交模式之外,spark-submit 还有一些参数需要关注下:

  • --driver-memory,给 spark driver 节点分配的内存。client 模式(还有 sst 模式)导入时,该值可采用默认值不进行配置,因为没有 reduce 操作需要用到 driver 内存。
  • --executor-memory,根据源数据的 size M 和 partition 数 p 进行配置,可配置成 2*( M/p)。
  • --total-executor-cores,standalone 模式下 Spark 应用程序可用的总 cores,可根据 Spark 集群的总 cores 来配。
  • --executor-cores,每个 executor 分配的核数。在每个 executor 内部,多个 core 意味着多线程共享 executor 的内存。可以设置为 5-10,根据集群节点核数自行调节。
  • --num-executors,yarn 模式下申请的 executor 的数量,根据集群节点数来配置。可以设置为 ((节点核数-其他程序预留核数)/executor-cores)*集群节点数,根据节点资源自行调节。比如,一个 Spark 集群有三台节点,每节点有 64 核,executor-cores 设置为 10,节点中为其他程序预留 14 核,则 num-executors 可设置为 15,由公式推断而出 ((64-14)/10)*3 = 15

其他调优

在该实践中,NebulaGraph 除第二步骤提到的优化配置,其他配置均采用系统默认配置,NebulaGraph Exchange 的导入并发度最小为 90,batch 为 2,000。当提高应用程序的并发度时或 batch 数时,导入性能无法再提升。因此可以在优化 NebulaGraph storaged 配置的基础上,适当调整并发度和 batch 数,在自己环境中得到两者的平衡,使导入过程达到一个最佳性能。

关于 Spark 的 total-executor-coresexecutor-coresnum-executors 和配置文件中的 partition 的关系:

  • 在 standalone 模式下,启动多少个 executor 是由 --total-executor-cores--executor-cores 两个参数来决定的,如果设定的 --total-executor-cores 是 10,--executor-cores 是 5,则一共会启动两个 executor。此时给应用程序分配的总核数是 total-executor-cores的值。
  • 在 yarn 模式下,启动多少个 executor 是由 num-executors 来决定的,此时给应用程序分配的总核数是 executor-cores * num-executors 的值。
  • 在 Spark 中可执行任务的 worker 一共是分配给应用程序的总 cores 数个,应用程序中的任务数有 partition 数个。如果任务数偏少,会导致前面设置的 executor 及 core 的参数无效,比如 partition 只有 1,那么 90% 的 executor 进程可能就一直在空闲着没有任务可执行。Spark 官网给出的建议是 partition 可设置为分配的总 cores 的 2-3 倍,如 executor 的总 CPU core 数量为 100,那么建议设置 partition 为 200 或 300。

0. 如何选择数据导入工具

想必通过上面的内容大家对 NebulaGraph Exchange 的数据导入性能有了一定的了解,下图为 NebulaGraph 数据导入工具的分布图:

感兴趣的小伙伴可以阅读文档 https://docs.nebula-graph.com.cn/3.3.0/20.appendix/write-tools/ 了解具体的选择事项。


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

要来近距离快速体验一把图数据库吗?现在可以用用 NebulaGraph Cloud 来搭建自己的图数据系统哟,快来节省大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天免费使用中,点击链接来用用图数据库吧~

想看源码的小伙伴可以前往 GitHub 阅读、使用、(з)-☆ star 它 -> GitHub;和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能,留下「你的名片」一起玩耍呢~

从实测出发,掌握 NebulaGraph Exchange 性能最大化的秘密的更多相关文章

  1. [转帖]龙芯3A4000处理器实测:28nm工艺不变 性能仍可提升100%以上

    龙芯3A4000处理器实测:28nm工艺不变 性能仍可提升100%以上 http://news.mydrivers.com/1/663/663122.htm 龙芯是中科院下属的计算机所研发的自主产权国 ...

  2. 实测:云RDS MySQL性能是自建的1.6倍

    1. 摘要 基于之前写的「云厂商 RDS MySQL 怎么选」的文章,为了进一步了解各云厂商在RDS MySQL数据库性能上的差异,本文将对自建MySQL.阿里云.腾讯云.华为云和AWS 的 RDS ...

  3. linux性能调优概述

    - 什么是性能调优?(what) - 为什么需要性能调优?(why) - 什么时候需要性能调优?(when) - 什么地方需要性能调优?(where) - 什么人来进行性能调优?(who) - 怎么样 ...

  4. 1002-谈谈ELK日志分析平台的性能优化理念

    在生产环境中,我们为了更好的服务于业务,通常会通过优化的手段来实现服务对外的性能最大化,节省系统性能开支:关注我的朋友们都知道,前段时间一直在搞ELK,同时也记录在了个人的博客篇章中,从部署到各个服务 ...

  5. nodejs进程线程优化性能

    1. node.js 单线程的特点 node.js 以异步非阻塞单线程,作为其执行速度的保障.什么是非阻塞单线程? 举一个现实生活中的例子,我去巢大食堂打饭,我选择了A套餐,然后工作人员区为我配餐,我 ...

  6. kafka 解密:破除单机topic数多性能下降魔咒

    https://bbs.huaweicloud.com/blogs/112956 版权归PUMA项目组所有,转载请声明,多谢. kakfa大规模集群能力在前面已给大家分享过,kafka作为消息总线,在 ...

  7. 5G革命:如何让「数据」实现最大性能?

    壹 早在2000年代中期,H-Store第一次在M.I.T.被我们提出来,VoltDB是H-Store的商业化产品,它表示结构相似的数据会被连续存放到一起.在本文的后续描述中,我们将使用V-H来缩写. ...

  8. Java性能调优实战,覆盖80%以上调优场景

    Java 性能调优对于每一个奋战在开发一线的技术人来说,随着系统访问量的增加.代码的臃肿,各种性能问题便会层出不穷. 日渐复杂的系统,错综复杂的性能调优,都对Java工程师的技术广度和技术深度提出了更 ...

  9. 一天五道Java面试题----第九天(简述MySQL中索引类型对数据库的性能的影响--------->缓存雪崩、缓存穿透、缓存击穿)

    这里是参考B站上的大佬做的面试题笔记.大家也可以去看视频讲解!!! 文章目录 1.简述MySQL中索引类型对数据库的性能的影响 2.RDB和AOF机制 3.Redis的过期键的删除策略 4.Redis ...

  10. mysql高性能索引策略

    转载说明:http://www.nyankosama.com/2014/12/19/high-performance-index/ 1. 引言 随着互联网时代地到来,各种各样的基于互联网的应用和服务进 ...

随机推荐

  1. 浅析RobotFramework工具的使用 | 京东物流技术团队

    1 简介 最近几年越来越多的公司都开始进行自动化测试的设计和布局了,自动化,顾名思义就是把以人为驱动的测试行为转化为机器执行的一种过程,并经常用于回归测试中,市面上也存在很多开源的自动化测试的工具和理 ...

  2. TypeScript中的元组 Tuple

    元组类型 // 元组类型:表示一个已知元素数量和类型的数组,各元素的类型不必相同 let undata: [string, '男'| '女']; //已知数量是两个.类型分别是字符串和男或者女 und ...

  3. 原生js拖拽元素(onmouseup不能够触发的原因)

    我们经常会遇见拖拽某一个元素的场景,拖拽也是很常用的: 这次拖拽遇见一个问题,有时在拖拽的时候吗,鼠标松开,元素仍然可以拖拽: 经过查阅资料,发现: 会触发H5原生的拖拽事件.并且不会监听到onmou ...

  4. go中x/sync/semaphore解读

    semaphore semaphore的作用 如何使用 分析下原理 Acquire TryAcquire Release 总结 参考 semaphore semaphore的作用 信号量是在并发编程中 ...

  5. VB6的WindowsXP控件引擎 - 开源研究系列文章

    这几天翻了一下原来VB6的代码,将一些有用的代码进行了整理,然后将这些代码记录下来,开源出来,让需要的朋友能够进行代码复用. 这次介绍的是一个VB6的WindowXP的控件引擎代码,主要是在程序启动的 ...

  6. 案例:使用sqlplus登录报ORA-12547错误

    现象:Exadata刷机之后grid/oracle用户的环境变量是没有设置的,需要手工进行设置,设置完成后发现grid用户执行报错ORA-12547: [grid@dbm0dbadm01 ~]$ sq ...

  7. Postgresql-数据库无法停止,报错:pg_ctl server does not shut down

    根据您的查询,pg_ctl server does not shut down(pg_ctl服务无法关闭)的原因可能有很多.以下是一些可能的解决方案和代码示例: (1)杀死所有与PostgreSQL相 ...

  8. [Ngbatis源码学习]Ngbatis源码阅读之连接池的创建

    Ngbatis源码阅读之连接池的创建 1. NebulaPool的创建 NgbatisBeanFactoryPostProcessor 这个类实现了 BeanFactoryPostProcessor ...

  9. 【译】使用.NET将WebAssembly扩展到云(一)

    原文 | Richard Lander 翻译 | 郑子铭 WebAssembly(Wasm)是一种令人兴奋的新虚拟机和(汇编)指令格式. Wasm 诞生于浏览器,是 Blazor 项目的重要组成部分. ...

  10. NC18389 收益

    题目链接 题目 题目描述 小N是一家金融公司的项目经理.他准备投资一个项目,这个项目要融资L元,融资成功后会得到M元的利润.现在有n个客户.对于第i个客户,他有mi元钱.小N承诺假如最后筹够钱,会给这 ...