前言

图数据结构可以很自然地对现实世界进行表征。例如，像用户、门店、骑手这些实体能够用图中的点来进行表示，而用户到门店的消费行为以及骑手给用户的送餐行为则可以用图中的边来表示。通过使用图的方式对场景进行建模，这样便于对复杂关系进行描述。在美团，存在着较多的图数据存储以及多跳查询需求，概括起来主要包含以下 4 个方面：

美团总体来说需要一种组件，以管理千亿级别的图数据，同时解决图数据的存储以及多跳查询问题。图数据库研究的核心课题是海量图数据的高效存储和查询，而在大规模分布式场景中如何进行工程落地，是我们面临的痛点问题。传统的关系型数据库等可以用来存储图数据，但是对于图上多跳查询这一高频操作，却不能很好地处理。

公司在社交场景中进行了传统关系型数据库与图数据库的查询性能对比。该对比在一个社交网络中进行，此社交网络包含 100 万人，每人约有 50 个朋友，要在其中找到最大深度为 5 的朋友的朋友。实验结果显示，在多跳查询方面，图数据库优势明显，如图 2 所示。然而，选取一款高吞吐、低查询延时、能存储海量数据且易用的图数据库是很困难的，自主研发这样的图数据库也很困难。下面将介绍美团在图数据库选型以及平台建设方面所做的一些工作。

图 1

图 2

图数据库选型

5. 具备批量从数仓导入数据的能力。

分析 DB-[2] 上排名靠前的图数据库，且排名在 30 以内。接着，把其中不开源的项目剔除掉。之后，我们把剩下的图数据库划分成三类。

前员工 Rai Jain 离职创业后，于 2016 年推出了图数据库产品。该产品底层数据模型是 RDF[12]，是基于 Go 语言编写的，其存储引擎基于[13]进行了改造，并且使用 RAFT 来保证数据读写的强一致性。

前员工叶小萌离职创业后，在 2019 年推出了一款图数据库产品。该产品的底层数据模型是属性图，是基于 C++语言编写的。其存储引擎是基于[14]进行改造的，并且还使用 RAFT 来保证数据读写的强一致性。

这两个项目的创始人都在互联网公司的图数据库领域钻研了很多年。他们对图数据库在实际落地过程中所面临的痛点有着深刻的理解。并且，他们在整体的架构设计方面也有不少相似的地方。在图数据库的最终选型过程中，我们依据 LDBC-SNB 数据集[15]对一些内容进行了深度性能测评。测试的详细情况在文章“主流开源分布式图数据库”中有体现。从测试结果能够看出，在数据导入、实时写入以及多跳查询等方面，它的性能都比竞品要好。另外，它的社区比较活跃，问题的响应速度也很快。因此，我们团队最终决定基于它来搭建图数据库平台。

图 3

一个完整的集群包含三种类型的服务，分别是 、 以及 Meta 。每种服务都拥有其各自的可执行二进制文件，这些文件既能够部署在同一个节点上，也能够部署在不同的节点上。以下是 架构设计（见图 3）的一些核心要点[16][17]。

Meta：架构图右侧是 Meta 集群，该集群采用特定架构。由集群内所有的 Meta 节点进行选举，之后对外提供服务；处于待命状态，并从其他节点复制更新的数据。一旦某个 Meta 节点出现故障（Down 掉），会再次选举其中一个 Meta 节点成为新的服务节点。Meta 负责存储和提供图数据的相关信息，比如元信息等，还负责提供 Job 机制来管理长耗时任务，它要指挥数据进行迁移、进行变更、处理数据以及重建索引等运维操作。

在架构图中，Meta 的左侧是主要服务，该服务采用存储与计算分离的架构。虚线以上部分为计算，虚线以下部分为存储。存储计算分离具有诸多优势，其中最直接的优势在于，计算层和存储层能够依据各自的情况进行弹性扩容和缩容。此外，存储计算分离还带来了使水平扩展成为可能这一优势。此外，存储计算分离使得能够为多种类型的计算层或计算引擎提供服务。当前有一个高优先级的 OLTP 计算层，而各种 OLAP 迭代计算框架会构成另一个计算层。

无状态计算层：每个计算节点都运行着一个查询计算引擎，且该引擎是无状态的。节点之间不存在任何通信关系。计算节点仅仅从 Meta 读取信息，并且与 Meta 进行交互。这样的设计使得计算层集群在使用 K8s 进行管理或者部署到云上时更加容易。查询计算引擎能够接收客户端的请求。它可以解析查询语句。还能生成抽象语法树（AST）。接着把 AST 传递给执行计划器和优化器。最后交由执行器执行。

分布式存储层采用分布式架构设计，此架构共分三层。最底层是单机版的某种存储系统，它能提供对本地数据的 get、put、scan 等操作。该层定义了数据操作接口，用户可依据自身需求进行相关定制开发。目前，已提供基于特定技术实现的特定功能。层在其之上，实现了 Raft，每一个都与一组 Raft 相对应。在层的上面是，这一层定义了一系列与图相关的 API。这些 API 请求会在这一层被转化为一组针对相应的 KV 操作。正是由于这一层的存在，存储服务才变成了真正的图存储。不然的话，只是一个 KV 存储而已。没将 KV 作为一个服务单独提出，主要原因在于图查询过程会涉及大量计算，这些计算通常需使用图的相关内容，而 KV 层没有数据概念，如此设计便于实现计算下推，这也是查询性能优越的主要原因。

以 C++ 来实现，其架构设计具备能够存储千亿顶点以及万亿边的能力，并且还能提供毫秒级别的查询延时。我们在由 3 台物理机构建的集群上，灌入 10 亿的美食图谱数据，对该功能进行了验证。

图数据库平台建设

图 4

为了对图数据进行统一管理，以降低工程同学在图数据库集群上的运维压力，我们依据开源分布式图数据库，构建了一套一站式的图数据库自助管理平台（见图 4），此平台涵盖以下 4 层：

团队主导设计的图数据库平台与业界方案相比，它除了能够支持存储千亿顶点以及万亿边，还具备毫秒级别查询的能力。并且，它还提供了四项能力，分别是：应用可用性 SLA 能达到 99.99%；可以支持每小时百亿量级的数据导入；在实时写入数据时，能够保证多集群数据的最终一致性；具备易用的图谱可视化能力。接下来将介绍具体的设计思路。

4.1 高可用模块设计

图 5

首先介绍单应用多集群高可用模块的设计。之所以有这样的设计，是因为接入图数据库平台的业务方较为在意集群可用性这一指标。在线服务对集群的可用性有着极高的要求，其最基础的要求是集群的可用性能要达到 4 个 9，也就是说在一年当中，集群的不可用时间需小于一个小时。在线服务中，服务或集群的可用性至关重要，它是整个业务的生命线。若无法保证这点，即便集群具备再多再丰富的能力，业务方也不会考虑使用。可用性是业务进行选型的基础。

另外，公司提出中间件需具备跨区域容灾能力，也就是要能够在多个地域部署多集群。我们对平台接入方的业务需求进行了分析，其中大约 80%的场景是进行 T+1 全量导入数据且线上只读。在这样的场景中，对图数据的读写强一致性要求不是很高，所以我们设计了单应用多集群这样的部署方案。

AP 方案的部署方式可参考图 5。一个业务方在图数据库平台上创建了 1 个应用，并且部署了 4 个集群，其中北京有 2 个集群，上海也有 2 个集群。通常情况下，这 4 个集群会同时对外提供服务。倘若现在北京集群 1 出现故障，那么北京集群 2 能够提供服务。如果真不巧，北京集群出现故障或北京侧对外的网络无法使用，那么上海的集群能够提供服务。在这种部署方式中，平台会通过一些方式来尽力保证整个应用的可用性。并且每个集群内部会尽量部署在同一机房的机器，因为图数据库集群内部存在大量的 RPC，如果有跨机房或跨区域的频繁调用，整个集群对外的性能就会比较低。

图 6

高可用模块主要包含下面 4 个部分，如上图 6 所示：

右侧的图数据库是第一部分，它部署在图数据库集群中，是一个进程。此进程用于收集机器和图数据库三个核心模块的信息，然后上报到图数据库平台。它还能够接收图数据库平台的命令，并对图数据库进行操作。

图数据库平台属于第二部分。它的主要作用是对集群进行管理，同时把图数据库集群的状态同步到配置中心。

第三部分为图数据库 SDK，其主要职责是管理与图数据库集群的连接。当业务方发送查询请求时，SDK 会进行集群的路由和负载均衡操作，从而选出一条高质量的连接来发送该请求。同时，SDK 能够处理图数据库集群中问题机器的自动降级和恢复事宜，并且具备支持平滑切换集群数据版本的功能。

第四部分是配置中心，类似 ，存储集群的当前状态。

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

图 7

第二个模块是每小时能导入百亿量级数据的模块。在 2019 年底到 2020 年初，平台全量导入数据是通过调用对外提供的批量数据导入接口来进行的。这种方式的数据写入速率大约为每小时 10 亿级别。导入百亿数据大概需要耗费 10 个小时，所耗费的时间比较长。在导数据时，速度可达几十万每秒。在此过程中，会一直占用机器的 CPU 和 IO 资源。这一方面会给机器带来损耗，另一方面会使数据导入过程中集群对外提供的读性能变弱。

为了解决上述两个问题，平台进行了以下优化：在集群里直接生成图数据库的底层文件 SST File，接着借助特定的功能，将该文件直接导入到图数据库中。

数据导入的核心流程可参考图 7。用户执行导数据操作后，图数据库平台会向公司的集群提交一项任务。在该任务中，会生成图数据库里相关的点、边以及点索引、边索引相关的 SST 文件，并且会将这些文件上传到美团的 S3 云存储上。文件生成之后，图数据库平台会通知应用里的多个集群去下载这些存储文件。接着，会完成与之相关的操作。最后，完成数据版本的切换。

平台为了兼顾各个业务方的不同需求，将应用导入、集群导入、离线导入、在线导入以及全量导入、增量导入这些场景进行了统一，接着又细分成下面九个阶段，从流程方面来保证在导数据过程中应用整体的可用性，分别是：生成 SST File 、下载 SST File 、数据校验、增量回溯、数据版本切换、集群重启、数据预热。

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

图 8

第三个模块为实时写入多集群数据同步模块。平台约 15%的需求场景是，在实时读取数据的同时，要将新产生的业务数据实时写入集群，且对数据读写的强一致性要求不高，即业务方写到图数据库里的数据，无需立即被读取到。针对上述场景，当业务方使用单应用多集群这种部署方案时，多集群里的数据需保证最终一致性。针对这一需求，我们做了以下设计。

引入组件后，业务方在服务中利用 SDK 对图数据库进行写操作。此时，SDK 不会直接写入图数据库，而是将写操作写入队列中。接着，该应用下的多个集群会异步消费这个队列。

集群在应用级别可配置消费并发度，以此来控制数据写入集群的速度。具体流程为：首先，集群具备在应用级别进行消费并发度配置的能力；接着，通过这种配置来对数据写入集群的速度进行控制。

图 9

在实时写入数据的过程中，平台能够同步生成一个全量数据版本，并且可以进行平滑切换，这样就能确保数据不重、不漏且不延迟。（见图 9）

4.4 图可视化模块设计

图 10

第四个模块是图可视化模块，从图 10 可以看出，它主要用于解决子图探索问题。当用户在图数据库平台利用可视化组件查看图数据时，能够尽量通过合适的交互设计，以避免因节点过多而导致爆屏现象。主要包含以下几个功能：

业务实践

5.1 智能助理

该项目数据是以美团商户数据以及用户评论为基础构建起来的餐饮娱乐知识图谱，其覆盖了美食、酒店、旅游等诸多领域，当中包含 13 类实体以及 22 类关系。当下，点边的数量大致处于百亿这个级别，数据会在 T+1 时进行全量更新，主要是用来解决在搜索或者智能助理当中的 KBQA（全称： Base ）这类问题。核心处理流程是先通过 NLP 算法来识别关系和实体，接着构造出 SQL 语句，然后到图数据库中获取数据。

典型的应用场景包含商场找店。例如，有某个用户想知晓望京新荟城这个商场是否有海底捞，此时系统能够迅速查出结果并告知用户。还有一个场景是标签找店，当用户想知道望京 SOHO 附近有没有适合情侣约会的餐厅，或者用户可以添加更多场景标签，系统都可以协助查找出来。

5.2 搜索召回

该项目数据以医美商家信息为基础构建了医美知识图谱，其中包含 9 类实体以及 13 类关系，点边的数量达到百万级别。它也是 T+1 全量更新的，主要是在大搜底层进行实时召回，能够返回与相关的商户、产品或医生的信息，从而解决医美类搜索词结果少、无结果的问题。比如，有某个用户去搜索“啤酒肚”这样的症状，又或者搜索“润百颜”这类品牌，那么系统是能够召回相关的医美门店的。

5.3 图谱推荐理由

该项目的数据来源于用户的画像信息、商户的特征信息以及用户半年内的收藏/购买行为。其数据量级达到了 10 亿级别，并且是 T+1 全量更新的。如今在美团 App 和点评 App 上，默认的商户推荐列表是由深度学习模型生成的。然而，该模型并不会给出生成此列表的原因，存在缺少可解释性的问题。

在图谱中，用户与商户之间原本就存在着多条相互连通的路径。项目对这些路径进行了考量，准备从中挑选出一条合适的路径，用于生成推荐理由，然后在 App 界面上把推荐某家店的原因展示给用户。该项目通过用户的协同过滤算法来生成推荐理由。它在多个组合维度中进行查找，这些维度包括家乡、消费水平、偏好类目、偏好菜系等。通过查找，找出了多条路径。接着给这些路径打分，从其中选出一条分值较高的路径。最后按照特定要求产出推荐理由。通过上述方式，能够得到“在北京且喜欢北京菜的山东老乡都说这家店很棒”，也能得到“广州老乡都很喜欢他家的正宗北京炸酱面”这类理由。

5.4 代码依赖分析

该项目将代码库中的代码依赖关系写入图数据库。代码库中有很多服务代码，这些服务包含对外提供的接口。这些接口的实现依赖于服务中的某些类的成员函数，而这些类的成员函数又依赖本类的成员变量、成员函数或其他类的成员函数。它们之间的依赖关系形成了一张图，可将此图写入图数据库以进行代码依赖分析。

典型应用场景为精准测试。开发同学完成需求并向公司代码仓库提交 PR 后，能够将更改实时写入图数据库。如此一来，开发同学便可查到自己所写代码影响了哪些外部接口，还能借助图可视化组件查看调用路径。开发同学原本要修改接口 A 的行为，并且修改了大量代码。然而，他或许并不知晓自己所修改的代码会对对外接口 B、C、D 产生影响。在这种情况下，可以借助代码依赖分析来进行相关操作，以提升测试的完备性。

6 总结与展望

目前，图数据库平台具备了对图数据的一站式自助管理功能。某个业务方要使用图数据库能力时，可在平台上自助创建图数据库集群，可创建图，可导入图数据，可配置导入数据的执行计划，可引入平台提供的 SDK 对数据进行操作等。平台侧主要负责各业务方图数据库集群的稳定性。目前，美团有一些业务已经在该平台上落地，数量大概在三四十个。这些业务基本满足了各个业务方的需求。

未来规划主要包含两个方向。其一，依据业务场景对图数据库内核进行优化，以提升平台的稳定性，并且将开发的成果持续反哺给社区。其二，挖掘更多的图数据价值。目前平台只具备图数据存储及多跳查询这种基本能力，后续将会去探索图学习、图计算的能力，从而为平台用户提供更多能够挖掘图数据价值的功能。