Nebula Graph 在微众银行数据治理业务的实践

本文为微众银行大数据平台：周可在 nMeetup 深圳场的演讲这里文字稿，演讲视频参见：B站

自我介绍下，我是微众银行大数据平台的工程师：周可，今天给大家分享一下 Nebula Graph 在微众银行 WeDataSphere 的实践情况。

先来说下图数据库应用背景。

WeDataSphere 图数据库架构是基于 JanusGraph 搭建，正如邸帅在演讲《NebulaGraph - WeDataSphere 开源介绍》中提及的那样，主要用于解决微众银行数据治理中的数据血缘问题。在使用 JanusGraph 过程中，微众银行发现 JanusGraph 本身依赖组件较多，数据存储在 HBase 中，索引存储在 Eleasticsearch 中，而因为受分布式高可用和两地三中心架构规范要求，要搭建一套完整的图数据库系统涉及技术点较多，比如高可用问题，再加上三个组件串联，需要解决很多技术问题。而且，本身 JanusGraph 这块数据写入性能也存在问题，当然本身我们对 JanusGraph 的优化也较少，主要集中在参数调整和安全性能提升。

当时用这套系统处理的数据量大概是每天 60 万个点，百万级的边，差不多一天要花 5 个小时左右才能完成写入。这就导致业务方需要使用血缘数据时，大数据平台不能及时提供。

至于微众银行大数据平台为什么选用 Nebula Graph，微众银行早期调研过一些商用、开源的图数据库解决方案，测试部分这里不做赘述，可以参考下 Nebula Graph 社区 美团、腾讯云安全团队和 Boss 直聘 做的性能测评。

这里说下刚才 60 万个点、百万级别边这个场景的情况，在单节点低配机器部署情况下，微众银行导入数据基本上在 20 分钟内完成。Nebula Graph 的写入性能非常好，微众银行大数据平台这块业务对查询的性能要求并不高，Nebula Graph 也能满足大数据平台这块的查询要求。

微众银行的图数据库选择还有一个重量考核点，高可用和容灾的架构支持。这个考核项，Nebula Graph 本身的架构存在一定优势，符合微众银行行内硬性的架构要求和规范。加上大数据平台本身旨在构建一个完整的数据流生态，Nebula Graph 提供了一些大数据相关开源组件，比如：Connector，Exchange，这些工具能很好地同大数据平台进行结合。

最后一点，回归到人的问题——微众银行同开源社区的交流等同于跟其他技术人的交流。和 Nebula Graph 社区交流过程中发，微众银行发现不管是在 PoC 微信群，还是在 Nebula Graph 社区论坛上提问题，官方反馈非常及时。印象较深的一点是，有一天晚上 10 点多，大数据平台在 Nebula Graph 研发人员指导下优化了一个参数，我们在微信群里和 Nebula Graph 反馈，这个参数调整之后解决了生产问题，Nebula Graph 研发同学还给我们发了一个 666 的表情。[手动狗头] 哈哈哈哈挺好。