huotu
2021 年12 月 15 日 06:04
1
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,请问这可能是什么原因呢?
huotu
2021 年12 月 15 日 07:53
3
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!
huotu
2021 年12 月 15 日 08:02
4
我这边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
huotu
2021 年12 月 15 日 08:33
6
这个是按之前文档来的,看了一下最新文档有更新;不过这个参数影响的是shuffle分区数,对于SST文件下载没有影响吧
nicole
2021 年12 月 15 日 08:49
7
这个配置影响的是你前面说的时长的问题。 和download是两个问题
download 日志里没有其他详细日志了? 那需要author @darionyaphet 帮忙看下。
huotu
2021 年12 月 15 日 09:03
8
修改partitions后生成SST文件确实效率更高了,10亿数据用了28分钟,重试了 download,还是提示download failed
huotu
2021 年12 月 15 日 09:09
9
没有其他日志了
查看的日志文件: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!
huotu
2021 年12 月 15 日 09:17
10
也核对过hadoop的主namenode地址和端口,都是正确的,rpc 地址 8020, http 地址 50070
下载命令: DOWNLOAD HDFS “hdfs://10.210.40.18:8020/sst”;
nicole
2021 年12 月 15 日 09:56
11
你的fs.defaultFS 配置是多少, 查看hadoop 的core-site.xml 配置文件可以看到。 hadoop3之前 默认的filesystem访问端口是9000.
你看下 meta 和 storage 是不是收到了下载请求的日志?
huotu
2021 年12 月 16 日 05:49
14
配置的是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
huotu
2021 年12 月 16 日 07:10
15
另一个问题是WAL日志占用磁盘空间较多
通过nGQL方式录入50亿数据,需要全文索引,因保证录入性能,所以并未在录入数据的时候创建全文索引,而是选择录入完成后建立全文索引,所以对WAL日志的保留时间由4小时改为24小时,录入完成后,添加listener,创建并重建全文索引,在重建过程中listener 会拷贝WAL数据,发现WAL数据较源数据膨胀了好几倍,导致磁盘空间成为瓶颈
所以,在大数据量录入时,需要建立原生索引和全文索引。同时保证录入性能,有什么建议方案么?