本文为 #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 ????

从测试后果看 Nebula Graph 在数据导入、实时写入及多跳查问方面性能均优于竞品。此外，Nebula Graph 社区沉闷，问题的响应速度快，所以团队最终抉择了基于 Nebula Graph 来搭建图数据库平台。

图数据库平台建设

上面介绍美团图数据库平台的建设，整个图数据库平台包含 4 层。

第一层是数据生产层，平台的图数据次要有两种起源，第一种是业务方把数仓中数据通过 ETL Job 转成点和边的 Hive 表，而后离线导入到图数据库中；第二种是业务线上实时产生的数据、或者通过 Spark、Flink 等流式解决产生的近线数据，实时地通过 Nebula Graph 提供的在线批量接口灌到图数据库中。

第二层是数据存储层，平台反对两种图数据库集群的部署形式。

  • 第一种是 CP 计划，即 Consistency & Partition tolerance，这是 Nebula Graph 原生反对的集群部署形式。单集群部署，集群中机器数量大于等于正本的数量，正本数量大于等于 3 。只有集群中有大于正本数一半的机器存活，整个集群就能够对外失常提供服务。CP 计划保障了数据读写的强一致性，但这种部署形式下集群可用性不高。
  • 第二种部署形式是 AP 计划，即 Availability & Partition tolerance，在一个利用中部署多个图数据库集群，每个集群数据正本数为 1 ，多集群之间进行互备。这种部署形式的益处在于整个利用对外的可用性高，但数据读写的一致性要差点。

第三层是数据应用层，业务方能够在业务服务中引入平台提供的图谱 SDK，实时地对图数据进行增删改查。

第四层是撑持平台，提供了 Schema 治理、权限治理、数据质检、数据增删改查、集群扩缩容、图谱画像、图数据导出、监控报警、图可视化、集群包治理等性能。

通过这四层架构设计，目前图数据库平台根本具备了对图数据的一站式自助治理性能。如果某个业务方要应用这种图数据库能力，那么业务方能够在这个平台上自助地创立图数据库集群、创立图的 Schema、导入图数据、配置导入数据的执行打算、引入平台提供的 SDK 对数据进行操作；平台侧次要负责各业务方图数据库集群的稳定性。目前有三、四十个业务在平台上真正落地，根本能满足各个业务方需要。

再介绍下图数据库平台中几个外围模块的设计。

高可用模块设计

首先是单利用多集群高可用模块的设计（AP 计划）。为什么有 AP 计划的设计呢？因为接入这个图数据库平台的业务方比拟在意的指标是集群可用性。在线服务对集群的可用性要求十分高，最根底的要求是集群可用性能达到 4 个 9，即一年里集群的不可用工夫要小于一个小时，对于在线服务来说，服务或者集群的可用性是整个业务的生命线，如果这点保障不了，即便集群提供的能力再多再丰盛，那么业务方也不会思考应用，可用性是业务选型的根底。

另外公司要求中间件要有跨区域容灾能力，即要具备在多个地区部署多集群的能力。咱们剖析了平台接入方的业务需要，大概 80% 的场景是 T+1 全量导入数据、线上只读；在这种场景下对图数据的读写强一致性要求并不高，因而咱们设计了单利用多集群这种部署计划。

部署形式能够参考上图，一个业务方在图数据库平台上创立了 1 个利用并部署了 4 个集群，其中北京 2 个、上海 2 个，平时这 4 个集群同时对外提供服务。如果当初北京集群 1 挂了，那么北京集群 2 能够提供服务。如果说真那么不巧，北京集群都挂了，或者对外的网络不可用，那么上海的集群能够提供服务，这种部署形式下，平台会尽可能地通过一些形式来保障整个利用的可用性。而后每个集群外部尽量部署同机房的机器，因为图数据集群外部 RPC 是十分多的，如果有跨机房或者跨区域的频繁调用，整个集群对外的性能会比拟低。

这个 AP 模块的设计次要蕴含上面 4 个局部：

  • 第一局部是右侧的图数据库 Agent，它是部署在图数据库集群的一个过程，用来收集机器和Nebula Graph 三个外围模块的信息，并上报到图数据库平台。Agent 可能接管图数据库平台的命令并对图数据库进行操作。
  • 第二局部是图治理平台，它次要是对集群进行治理，并同步图数据库集群的状态到配置核心。
  • 第三局部是图数据库 SDK，它次要做的事件是治理连贯到图数据库集群的连贯。如果业务方发送了某个查问申请，SDK 会进行集群的路由和负载平衡，抉择出一条高质量的连贯来发送申请。此外，SDK 还会解决图数据库集群中问题机器的主动降级以及复原，并且要反对平滑切换集群的数据版本。
  • 第四局部是配置核心，相似 ZooKeeper，存储集群的以后状态。

每小时百亿级数据导入模块设计

第二个模块是每小时百亿量级数据导入模块，下面说了业务场景里 80% 是 T+1 全量导入数据，而后线上只读。平台在 19 年底 / 20 年初全量导入数据的形式是调用 Nebula Graph 对外提供的批量数据导入接口，这种形式的数据写入速率大略是每小时 10 亿级别，导入百亿数据大略要消耗 10 个小时，这个工夫有点久。此外，在以几十万每秒的速度导数据的过程中，会长期占用机器的 CPU、IO 资源，一方面会对机器造成损耗，另一方面数据导入过程中集群对外提供的读性能会变弱。

为了解决下面两个问题，平台进行了如下优化：在 Spark 集群中间接生成图数据库底层文件 sst file，再借助 RocksDB 的 bulkload 性能间接 ingest 文件到图数据库。这部分提速优化工作在 19 年底的时候就开始了，然而两头遇到 core dump 问题没有上线。在 20 年六、七月份的时候，微信的本利大佬向社区提交了这方面的 pr，和他在线沟通之后解决了咱们的问题，在这里感激一下本利大佬 ???? 。

图数据库平台数据导入的外围流程能够看左边这张图，当用户在平台上提交了导数据操作后，图数据库平台会向公司的 Spark 集群提交一个 Spark 工作，在 Spark 工作中会生成图数据库里相干的点、边以及点索引、边索引相干的 sst 文件，并上传到公司的 S3 云存储上。文件生成后，图数据库平台会告诉利用里的多个集群去下载这些存储文件，之后实现 ingest 跟 compact 操作，最初实现数据版本的切换。

平台方为兼顾各个业务方的不同需要，对立了利用导入、集群导入、离线导入、在线导入以及全量导入、增量导入这些场景，而后细分成上面九个阶段，从流程上保障在导数据过程中利用整体的可用性。

  • sst file生成
  • sst file下载
  • ingest
  • compact
  • 数据校验
  • 增量回溯
  • 数据版本切换
  • 集群重启
  • 数据预热

实时写入多集群数据同步模块设计

第三个模块是实时写入多集群数据同步，平台有 15% 的需要场景是在实时读取数据时，还要把新产生的业务数据实时写入集群，并且对数据的读写强一致性要求不高，就是说业务方写到图数据库里的数据，不须要立马能读到。

针对上述场景，业务方在应用单利用多集群这种部署计划时，多集群里的数据须要保障最终一致性。平台做了以下设计，第一局部是引入 Kafka 组件，业务方在服务中通过 SDK 对图数据库进行写操作时，SDK 并不间接写图数据库，而是把写操作写到 Kafka 队列里，之后由该利用下的多个集群异步生产这个 Kafka 队列。

第二局部是集群在利用级别可配置生产并发度，来控制数据写入集群的速度。具体流程是

  • SDK 对用户写操作语句做语法解析，将其中点边的批量操作拆解成对单个点边操作，即对写语句做一次改写
  • Agent 生产 Kafka 时确保每个点及其出边相干操作在单个线程里程序执行，保障这点就能保障各个集群执行完写操作后最终的后果是统一的。
  • 并发扩大：通过扭转 Kafka 分片数、Agent 中生产 Kafka 线程数来变更和调整 Kafka 中操作的生产速度。
  • 如果将来 Nebula Graph 反对事务的话，下面的配置须要调整成单分片单线程生产，平台须要对设计方案再做优化调整。

第三局部是在实时写入数据过程中，图数据库平台能够同步生成一个全量数据版本，并做平滑切换，通过右图里的流程来确保数据的不重不漏不提早。

图可视化模块设计

第四个模块是图可视化模块，平台在 2020 年上半年调研了 Nebula Graph 官网的图可视化设计跟一些第三方开源的可视化组件，而后在图数据库平台上减少了通用的图可视化性能，次要是用于解决子图摸索问题；当用户在图数据库平台通过可视化组件查看图数据时，能尽量通过失当的交互设计来防止因为节点过多而引发爆屏。

目前，平台上的可视化模块有上面几个性能。

第一个是通过 ID 或者索引查找顶点。

第二个是能查看顶点和边的卡片（卡片中展现点边属性和属性值），能够单选、多选、框选以及按类型抉择顶点。

第三个是图摸索，当用户点击某个顶点时，零碎会展现它的一跳街坊信息，包含：该顶点有哪些出边？通过这个边它能 Touch 到几个点？该顶点的入边又是什么状况？通过这种一跳信息的展现，用户在平台上摸索子图的时候，可疾速理解到周边的街坊信息，更快地进行子图摸索。在摸索过程中，平台也反对对边进行过滤。

第四个是图编辑能力，让平台用户在不相熟 Nebula Graph 语法的状况下也能增删改点边数据，对线上数据进行长期的干涉。

业务实际

上面来介绍下接入咱们平台的一些落地我的项目。

第一个我的项目是智能助理，它的数据是基于美团商户数据、用户评论构建的餐饮娱乐常识图谱，笼罩美食、酒店、游览等畛域，蕴含 13 类实体和 22 类关系。目前点边数量大略在百亿级别，数据是 T+1 全量更新，次要用于解决搜寻或者智能助理里 KBQA（全称：Knowledge Based Question Answer）类的问题。外围解决流程是通过 NLP 算法辨认关系和实体后结构出 Nebula Graph SQL 语句，再到图数据库获取数据。

典型的利用场景有商场找店，比方，某个用户想晓得望京新荟城这个商场有没有海底捞，智能助理就能疾速查出后果通知用户。

还有一个典型场景是标签找店，想晓得望京 SOHO 左近有没有适宜情侣约会的餐厅，或者你能够多加几个场景标签，零碎都能给你查找进去。

第二个是搜寻召回，数据次要是基于医美商家信息构建的医美常识图谱，蕴含 9 类实体和 13 类关系，点边数量在百万级别，同样也是 T+1 全量更新，次要用于大搜底层实时召回，返回与 query 相干的商户、产品或医生信息，解决医美类搜索词少后果、无后果问题。比方，某个用户搜“啤酒肚”这种症状、或者“润百颜”这类品牌，零碎都能给他召回相干的医美门店。

第三个是图谱举荐理由，数据来自用户的画像信息、商户的特色信息、用户半年内珍藏/购买行为，当初的数据量级是 10 亿级别， T+1 全量更新。这个我的项目的指标是给出美食列表举荐商户的可解释理由。为什么会做这个事呢？当初美团 App 和点评 App 上默认的商户举荐列表是由深度学习模型生成的，但模型并不会给出生成这个列表的理由，短少可解释性。然而在图谱里用户跟商户之间人造存在多条连通门路，咱们心愿能选出一条适合门路来生成举荐理由，在 App 界面上展现给用户举荐某家店的起因。比方咱们能够基于用户的协同过滤算法来生成举荐理由，在他乡、消费水平、偏好类目、偏好菜系等多个组合维度中找出多条门路，而后给这些门路打分，选出一条分值较高的门路，之后依照特定 pattern 产出举荐理由。通过上述形式，就能够取得在北京喜爱北京菜的山东老乡都说这家店很赞，或者广州老乡都中意他家的正宗北京炸酱面这类理由。

第四个是代码依赖剖析，是把公司里的代码库中代码依赖关系写到图数据库。公司代码库里有很多服务代码，这些服务都会有对外提供的接口，这些接口的实现依赖于该服务中某些类的成员函数，这些类的成员函数又依赖了本类的成员变量、成员函数、或者其它类的成员函数，那么它们之间的依赖关系就造成了一张图，咱们把这个图写到图数据库里，做什么事呢？

典型场景是 QA 的精准测试，当 RD 实现需要并向公司的代码仓库提交了他的 pr 后，这些更改会实时地写到图数据库中，所以 RD 就能查到他所写的代码影响了哪些内部接口，并且能展现出调用门路来。如果 RD 原本是要改接口 A 的行为，他改了很多货色，然而他可能并不知道他改的货色也会影响到对外接口 B、C、D，这时候就能够用代码依赖剖析来做个 Check。

第五个是服务治理，美团外部有几十万个微服务，这些微服务之间存在相互调用关系，这些调用关系造成了一张图。咱们把这些调用关系实时写入图数据库里，而后做一些服务链路治理和告警优化工作。

第六个我的项目是数据血统，把数仓中 ETL 工作的依赖关系写到了图数据库中，大略是千万级别的数据量级，数据实时写入，每天凌晨做一次全量 reload，次要是用来查找数据工作的上下游依赖。比如说，通过这个 FIND NOLOOP PATH FROM hash('task1') OVER depend WHERE depend.type == '强依赖' UPTO 50 STEPS 语句找出 task1 这个工作的所有强依赖门路。这里，咱们针对 Nebula Graph 官网的 FIND PATH 性能做了一些增强，增加了无环门路的检索跟 WHERE 语句过滤。

美团和 Nebula

最初，来介绍下团队对社区的奉献。

为了更好地满足图数据库平台上用户的需要，咱们对 Nebula Graph 1.0的内核做了局部性能的裁减和局部性能的优化，并把相对来说比拟通用的性能给 Nebula Graph 社区提了 PR，也向社区公众号投稿了一篇 支流开源分布式图数据库Benchmark ???? 。

当然，咱们通过 Nebula Graph 解决了公司内的很多业务问题，目前对 Nebula Graph 社区做的奉献还比拟少，后续会增强在社区技术共享方面的工作，心愿可能造就出越来越多的 Nebula Committer。

美团图数据库平台的将来布局

将来布局次要有两个方面，第一方面是等 Nebula Graph 2.0 的内核绝对稳固后，在咱们图数据库平台上适配 Nebula Graph 2.0 内核。第二方面是去开掘更多的图数据价值。当初美团图数据库平台反对了图数据存储及多跳查问这种根本能力，后续咱们打算基于 Nebula Graph 去摸索一下图学习、图计算的能力，给平台用户提供更多开掘图数据价值的性能。

以上为本次美团 NLP 技术专家——赵登昌老师带来的图数据库平台建设方面的分享。

如果你对【图存储】、【图学习】、【图计算】感兴趣，欢送向赵登昌老师投递简历，投递邮箱：zhaodengchang@meituan.com。

喜爱这篇文章？来来来，给咱们的 GitHub 点个 star 表激励啦~~ ????♂️????♀️ [手动跪谢]

交换图数据库技术？交个敌人，Nebula Graph 官网小助手微信：NebulaGraphbot 拉你进交换群~~