美团图数据库平台建设及业务实践
详细讲解了美团内部图数据库平台搭建、选型的过程
本文为 #nLive vol.001｜美团图数据库平台建设及业务实践# 主题演讲的文字稿，可前往 B站 观看本次视频
大家好，我是来自美团的赵登昌，今天我给大家分享下美团图数据库平台的建设以及业务实践。
这是本次报告的提纲，主要包括以下六方面内容。
背景介绍
首先介绍下美团在图数据方面的业务需求。
美团内部有比较多的图数据存储以及多跳查询需求，总体来说有以下 4 个方面：
第一个方面是知识图谱方向，美团内部有美食图谱、商品图谱、旅游图谱在内的近 10 个领域知识图谱，数据量级大概在千亿级别。在迭代、挖掘数据的过程中，需要一种组件对这些图谱数据进行统一管理。
第二个方面是安全风控。业务部门有内容风控的需求，希望在商户、用户、评论中通过多跳查询来识别虚假评价；在支付时进行金融风控验证，实时多跳查询风险点。
第三个方面是链路分析，比如说：数据血缘管理，公司数据平台上有很多 ETL Job，Job 和 Job 之间存在强弱依赖关系，这些强弱依赖关系形成了一张图，在进行 ETL Job 的优化或者故障处理时，需要对这个图进行分析。类似的需求还有代码分析、服务治理等。
第四个方面是组织架构管理，包括：公司组织架构的管理，实线汇报链、虚线汇报链、虚拟组织的管理，以及商家连锁门店的管理。比如，需要管理一个商家在不同区域都有哪些门店，能够进行多层关系查找或者逆向关系搜索。
总体来说，我们需要一种组件来管理千亿级别的图数据，解决图数据存储以及多跳查询问题。
传统的关系型数据库、NoSQL 数据库可以用来存储图数据，但是不能很好处理图上多跳查询这一高频操作。Neo4j 公司在社交场景做了 MySQL 和 Neo4j 的多跳查询性能对比，具体测试场景是，在一个 100 万人、每个人大概有 50 个朋友的社交网络里找最大深度为 5 的朋友的朋友。从测试结果看，查询深度增大到 5 时， MySQL 已经查不出结果了，但 Neo4j 依然能在秒级返回数据。实验结果表明多跳查询中图数据库优势明显。
图数据库选型
下面介绍我们的图数据库选型工作。
我们主要有以下 5 个图数据库选型要求
- A. 项目开源，暂时不考虑需要付费的图数据库；
- B. 分布式的架构设计，具备良好的可扩展性；
- C. 毫秒级的多跳查询延迟；
- D. 支持千亿量级点边存储；
- E. 具备批量从数仓导入数据的能力。
我们分析了 DB-Engine 上排名 Top30 的图数据库，剔除不开源的项目后，把剩下的图数据库分成三类。
- 第一类包括 Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。此类图数据库只有单机版本开源可用，性能比较优秀，但是不能应对分布式场景中数据的规模增长，即不满足选型要求 B、D；
- 第二类包括 JanusGraph、HugeGraph。此类图数据库在现有存储系统之上新增了通用的图语义解释层，图语义层提供了图遍历的能力，但是受到存储层或者架构限制，不支持完整的计算下推，多跳遍历的性能较差，很难满足 OLTP 场景下对低延时的要求，即不满足选型要求 C；
- 第三类包括 Dgraph、Nebula Graph。此类图数据库根据图数据的特点对数据存储模型、点边分布、执行引擎进行了全新设计，对图的多跳遍历进行了深度优化，基本满足我们对图数据库的选型要求
之后我们在一个公开社交数据集上（大约 200 亿点边）对 Nebula Graph 、Dgraph 、HugeGraph 进行了深度性能测评。主要从三个方面进行评测：
- 批量数据的导入
- 实时写入性能测试
- 数据多跳查询性能测试
测试详情见 Nebula 论坛：主流开源分布式图数据库Benchmark