基于DataX的janusgraph入库性能优化实践

最新推荐文章于 2024-09-05 23:08:02 发布

置顶仔仔1993

最新推荐文章于 2024-09-05 23:08:02 发布

阅读量890

点赞数

分类专栏：知识图谱大数据文章标签： janusgraph 性能优化

本文链接：https://blog.csdn.net/qq_26777585/article/details/115487700

版权

大数据同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

知识图谱

4 篇文章 0 订阅

订阅专栏

本文介绍了基于DataX的Janusgraph入库性能优化实践，通过调整开图参数、引入Redis缓存及实现多通道入库，实现了入库速度的显著提升。在V2阶段，通过缓存去重提升了20倍性能，V3阶段的多通道设计进一步优化了入库速率。最终，单节点多线程模式下点入库达2500-3000条/秒，边入库达9000条/秒。

摘要由CSDN通过智能技术生成

基于DataX的janusgraph入库性能优化实践

前言

实际工作过程中需要将不同来源的数据写入janusgraph图数据库，项目选型以dataX作为数据抽取框架来开发janusgraphWriter插件来达到适配任意数据来源的目的。具体时间实现DataX插件开发指南，结合自身项目业务完成janusgraph插件开发（后续附上插件开源项目地址）。我们发现在插件运行过程中存在入库性能不理想的问题，本实践有效规避了业务中入库数据去重校验逻辑造成的入库缓慢问题，百倍提高入库速率，基本达到不做校验的入库水平，远远超过对janusgraph开图配置参数的调优对入库速率的性能提升。

1. 插件整体设计

基于项目需求我们要实现以下几个功能：

1. 多源数据入图库

2. 新数据入库，重复数据更新

3. 入库的统计数据与脏数据需要记录

基本设计是依赖Datax开发janusGraphWriter插件，对Reader接入的数据做数据转换，去重校验等逻辑，将数据放入缓存，然后入库；考虑到脏数据体量与数据生产速度等问题，将入库过程中的统计数据与脏数据明细接入到外部kafka集群（修改datax-core工程），便于应用系统消费。

2. 入库插件设计V1

第一版的插件在入库过程中插件写入速度并不理想，并且写入数据随着时间的递增而下降。经过开图参数调优、底层存储系统切换、入库逻辑排查等过程之后，我们发现，最耗时的是数据校验的过程，因为每一条数据在入库前都要查询图数据库来校验数据是否存在，不存在的话才做插入操作，存在就做更新操作（虽然本人觉得，不应该将数据治理工作放到数据抽取的工作中来）。每条数据都需要与数据库交互一次，随着数据库的存量数据增加，查询速度越来越慢是符合预期的。

2.1 对开图参数与底层存储的调优

这里只介绍对入库性能提升较大一些的操作，（开图参数调整对写入速度并没明显的提升；对于切换成cassandra等其他的底层存储，得到的结果是更慢，按照原理cassandra对数据一致性要求更低，预期更快，至于为什么更慢有待大神们指点）：

1. 修改gremlin-server开图参数，配置各个regionserver默认的region数量，根据自己的集群资源和入库数据量来做相应修改，可提高入库速度。

storage.hbase.region-count：gremlin-server对应的底层hbase表的初始region数量；

storage.hbase.regions-per-server：每个hbase的regionServer节点的初始region数量：

此参数配置合理，可以有效利用hbase数据节点资源做到写负载均衡，并且可以降低region 合并操作造成的存储系统停顿耗时。

2. 调大ids.block-size，cache.db-cache-size并未实际提升

3. 修改默认数据压缩方式GZ为SNAPPY，调整storage.hbase.compat-class和storage.hbase.compression-algorithm，需要hadoop支持SNAPPY，未安装成功，预计在大数据量的情况下，提升压缩效率会提高入库速度，参见：Hadoop之常见压缩格式以及性能对比。