
Nebula & 数仓血缘关系数据的存储与读写
我是数据开发的实习生,在这个岗位上工作四个月左右的时间了,期间负责开发数据平台的功能
我是数据开发的实习生,在这个岗位上工作四个月左右的时间了,期间负责开发数据平台的功能。
因为工作中涉及的一些数据的读写性能较低,所以在调研后,选择部署一个 Nebula 集群。之所以选择 Nebula, 是因为它的技术体系比较成熟,社区也比较完善,对刚刚接触的它的人非常友好,所以很快就开始投入使用了。在使用过程中,有一些自己的见解,和遇到的一些问题及解决方法,在这里向大家分享一下自己的使用经验。
>>>> 选择 Nebula 的原因
性能优越
- 查询速度极快
- 架构分离,易扩展(目前的机器配置低,后续可能扩展)
- 高可用(由于是分布式,所以从使用到现在没有出现过宕机情况)
上手容易
- 介绍全(熟悉架构和性能)
- 部署快(经过手册的洗礼,快速部署简单的集群)
- 使用简便(遇到需要的数据,查询手册获取对应的 nGQL,针对性查询)
- 答疑优秀(遇到问题,可以先翻论坛,如果没有,那就发布帖子,开发人员的帮助很及时)
开源且技术稳定
- 因为实践企业多,用起来也放心。
>>>>
业务需求背景介绍
为方便数据治理、元数据管理及数据质量监控,将调度系统生成的数仓血缘保存起来。
血缘数据流程
从采集、存储到平台展示的数据全流程:
在查询平台的部分数据查询展示:
>>>>
我的具体实践
版本选择
Nebula Graph v3.0.0、Nebula Java v3.0.0
Nebula Graph 和 Java 客户端两个相兼容的版本。
集群部署
- 机器配置:
四台实体机,同配置:
10C * 2 / 16G * 8 / 600G
- 安装方式
RPM 安装。
- 通过 wget 拉取安装包后安装。
- 更改配置文件
主要更改参数
Meta 服务的所有机器 —— meta_server_addrs=ip1:9559, ip2:9559, ip3:9559
当前机器 ip(如果是 meta/graph/storage,填对应 meta/graph/storage 机器的 ip) —— local_ip
- 启动后通过 console 简单测试 add hosts ip:port 增加自己的机器 ip 后,show hosts,如果是 online,即可开始测试相关 nGQL。
数据导入
目前分两种情况更新数据。
- 实时监控调度平台
- 监控每个任务实例,通过依赖节点获取上下游的关系,将关系实时打入到MySQL 和 Nebula 中,更新 Nebula 数据通过 Spark Connector 实现。
(MySQL 做备份,因为 Nebula 不支持事务,可能存在数据偏差)
- 定时调度校正数据
- 通过 MySQL 中的血缘关系,通过 Spark 任务定时校正 Nebula 数据,更新数据同样通过 Spark Connector 实现。
- Spark Connector 的使用:NebulaConnectionConfig 初始化配置,然后通过连接信息、插入的点与边的相关参数及实体 Tag、Edge 创建 WriteNebulaVertexConfig 和 WriteNebulaEdgeConfig 对象,以备写入点和边的数据。
数据平台查询
数据平台查询血缘的应用:
- 获取 Nebula 数据实现过程
- 通过初始化连接池 Nebula pool,实现单例工具类,方便在整个项目中调用并使用 Session。
- 这里一定要注意,连接池只可以有一个,而 Session 可以通过 MaxConnectionNum 设置连接数,根据实际业务来判断具体参数(平台查询越频繁,连接数就要设置的越多一些)。而每次 Session 使用完毕也是要释放的。
- 查询数据,转换为 ECharts 需要的 JSON
- 通过 getSubGraph 获取当前表或字段的所有上下游相关点,这一点通过获取子图的方法,很方便。
- 需要通过结果,解析出其中两个方向数据的点,然后递归解析,最后转为一个递归调用自己的 Bean 类对象。
- 写一个满足前端需要的 JSON 串的 toString 方法,得到结果后即可。
这里分享一下自己的工具类,和核心逻辑代码
工具类:
核心代码:
Bean toString 代码:
得到的优化结果
在查询子图步长接近 20 的情况下,基本上接口返回数据可以控制在 200ms 内(包含后端复杂处理逻辑)
>>>>
结语
本文为 Nebula 社区用户 shixingr 参与 Nebula 社区首届征文活动 🔗 的原创文章,希望这篇文章能够在 Nebula 的使用上切实帮助到大家,也欢迎大家来围观~🥳
文章转载自公众号:Nebula Graph Community
