nebula数据录入问题咨询

  • nebula 版本:2.6.1
  • 部署方式:分布式
  • 安装方式: RPM
  • 是否为线上版本:N
  • 并搭建好了hadoop集群、ES服务和 Listener
    为了保证录入性能,没有事先创建原生索引和全文索引,也未在图空间添加Listener

1、使用Exchange工具进行数据录入的时候,SST录入方式比nGQL录入方式慢很多,50亿数据,约577GB,采用nGQL方式几个小时即可录入完成,而SST在22个小时后仍然没有生成完SST文件
数据源、application文件中分区和spark配置、都是一致的
在官方实际测试的时候,SST的录入性能是什么样的呢?

2、使用10亿数据进行SST录入测试,生成完SST文件后,执行 DOWNLOAD HDFS 命令时提示 下载失败,日志也只有简单的提示 DOWNLOAD failed,请问这可能是什么原因呢?

  1. 你在用Exchange生成sst文件时,提交命令要参考下nebula-exchange repo中的readme 或者是我们的文档,命令中要加入–spark.sql.shuffle.partitions的配置。
    我们简单测试时 针对2.2亿数据生成sst文件需要7min。
  2. download 失败可能是 没有在所有storage机器上安装HADOOP, 详情要看nebula 的日志。

NebulaGraph集群和Hadoop集群是部署在一起的,都是相同的服务器,即每台服务器都有storage和datanode

提交命令:
sh $APP_DIR/spark/spark/bin/spark-submit
–master yarn
–conf spark.sql.shuffle.partition=1000
–conf spark.default.parallelism=2000
–conf spark.storage.memoryFraction=0.5
–conf spark.shuffle.memoryFraction=0.3
–conf spark.executor.extraJavaOptions="-XX:+PrintGCDetails -Dkey=value -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=1G -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=65 -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCDateStamps"
–class com.vesoft.nebula.exchange.Exchange
$APP_DIR/lib/nebula-exchange-2.6.0.jar
-c $APP_DIR/config/application-sst.conf

下载SST文件报错日志内容
E1215 10:51:09.649435 1088279 MetaClient.cpp:3506] Download Failed:
E1215 10:51:09.649857 1088278 QueryInstance.cpp:108] Download failed!

我这边10亿数据,生成SST用了两个小时
spark申请资源配置:
spark: {
app: {
name: Nebula Exchange 2.6
}
#master:yarn-client
driver: {
memory: 2G
cores: 1
maxResultSize: 4G
}
executor: {
memory: 20G
instances: 16
cores: 1
}
cores:{
max: 80
}
}

服务器资源
节点数:4
节点内存:128GB
CPU:24 cores
磁盘:一块 1.1TB HDD盘

节点规划
nebula:3 metad , 4 graphd ,4 storaged
hadoop:2 namenode,4 datanode,2 resourcemanager ,4 nodemanager

配置不对,是partitions

1 个赞

这个是按之前文档来的,看了一下最新文档有更新;不过这个参数影响的是shuffle分区数,对于SST文件下载没有影响吧

这个配置影响的是你前面说的时长的问题。 和download是两个问题

download 日志里没有其他详细日志了? 那需要author @darionyaphet 帮忙看下。

修改partitions后生成SST文件确实效率更高了,10亿数据用了28分钟,重试了 download,还是提示download failed

没有其他日志了
查看的日志文件:graphd-stderr.log
内容:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0
E1215 14:06:53.479336 1088279 MetaClient.cpp:3506] Download Failed:
E1215 14:06:53.479627 1088279 QueryInstance.cpp:108] Download failed!

也核对过hadoop的主namenode地址和端口,都是正确的,rpc 地址 8020, http 地址 50070
下载命令: DOWNLOAD HDFS “hdfs://10.210.40.18:8020/sst”;

你的fs.defaultFS 配置是多少, 查看hadoop 的core-site.xml 配置文件可以看到。 hadoop3之前 默认的filesystem访问端口是9000.

你看下 meta 和 storage 是不是收到了下载请求的日志?

没有收到下载请求

配置的是8020
core-site.xml


fs.defaultFS
hdfs://mycluster


ha.zookeeper.session-timeout.ms
30000

hdfs-site.xml

dfs.nameservices
mycluster


dfs.ha.namenodes.mycluster
nn1,nn2


dfs.namenode.rpc-address.mycluster.nn1
10.210.40.18:8020


dfs.namenode.rpc-address.mycluster.nn2
10.210.39.97:8020


dfs.namenode.http-address.mycluster.nn1
10.210.40.18:50070


dfs.namenode.http-address.mycluster.nn2
10.210.39.97:50070

另一个问题是WAL日志占用磁盘空间较多
通过nGQL方式录入50亿数据,需要全文索引,因保证录入性能,所以并未在录入数据的时候创建全文索引,而是选择录入完成后建立全文索引,所以对WAL日志的保留时间由4小时改为24小时,录入完成后,添加listener,创建并重建全文索引,在重建过程中listener 会拷贝WAL数据,发现WAL数据较源数据膨胀了好几倍,导致磁盘空间成为瓶颈
所以,在大数据量录入时,需要建立原生索引和全文索引。同时保证录入性能,有什么建议方案么?

也有可能是端口配置的问题

只能是默认端口 9000 么