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

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

目录

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

前言

1. 插件整体设计

2. 入库插件设计V1

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

3. 入库插件设计V2（加缓存）

4. 入库插件设计V3（多通道）

5. 结语

---

前言

实际工作过程中需要将不同来源的数据写入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之常见压缩格式以及性能对比。

3. 入库插件设计V2（加缓存）

相比于第一版，加入了Redis缓存，将每个批次的数据在内存中去重，将写入成功的数据的Vertex的id存进redis，将之前与janus交互，改为批量查询redis，极大提高了入库性能。平均提升20倍以上。

4. 入库插件设计V3（多通道）

为了更进一步提升入库速度，结合DataX的Reader的SplitPk属性，将入库数据拆分成多个通道，并行写入，提高入库性能，这里一般不会是正比提升，因为底层hbase数据节点的入库性能有限制。在多线程无法线性提升入库性能的同时，考虑增加hbase集群的RegionServer。

5. 结语

本实践结合自身项目需求，对janusgraph入库性能，在配置参数，底层存储，入库逻辑等方面做了比较深入的研究和论证，达到了比较好的效果，单节点，多线程模式下，点入库速度能达到2500-300条每秒，边入库速度能达到9000条每秒；如果有兴趣交流知识图谱，请联系作者，见二维码，欢迎交流指正。