蚂蚁高性能图数据库TuGraph-DB的技术思考与实践

本文主要是介绍蚂蚁高性能图数据库TuGraph-DB的技术思考与实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在近日举行的 DTCC 2022 第十三届中国数据库技术大会-图数据技术与应用创新专场，蚂蚁集团图数据库负责人洪春涛博士分享了蚂蚁高性能图数据库TuGraph-DB的技术思考和实践，以下为演讲内容要点回顾。

图计算的优势

图计算是一种高效的抽象计算方法，可以方便地处理复杂的多维数据。我们将员工和公司之间的关系画成图，这样可以快速查询员工的信息，例如员工的工作情况、与其他员工的关系以及与哪些公司有联系。相比之下，在关系数据库中，我们需要分别建立员工信息表、公司信息表以及员工和公司之间的关系表。这就把整个数据切成了很多张二维表，在实际应用系统中经常能够看到几百上千张表。这样会使得系统变得更加复杂，需要基于多张表去做推断，对人或机器来说都会带来挑战。

对比来看什么是简单查询和复杂查询：

图中表格的前两行属于比较简单的查询，比如某个员工的工龄，直接找到对应的那一行然后取出来就可以；比如找出所有的雇员数大于5的公司，可能在雇佣关系表中就能找出来，在关系数据库里这些都属于常规的操作。

但如果查询再复杂一点，我想知道员工A和员工C之间有什么关系，不一定是一跳的关系，可能包含在同一家公司工作，也可能包含参与了同一个项目，甚至还包含他们有一个共同好友，这些关系就是多种多样的，想用SQL列举所有可能的关系其实就没有那么容易了。如果确定知道这里可能有几种关系，还能靠SQL穷举出来，但随着表越来越多，里面的关系可能有几百上千的时候，再想去穷举就非常难了。

最后还有一种更复杂的查询，比如想找员工A和员工E的所有关系，可能包括A认识B，B认识C，C认识E，相当于在做一个不定长跳数的查询，在SQL里面就非常难写了，相信绝大多数人都难以写出这种查询。

业界有句话，所谓的关系数据库实际上并不擅长处理关系。例如，员工A和E之间的所有关系实际上就是我们要查询的关系，但在关系数据库中处理这种关系查询实际上是不够友好的。这是图数据库的优势所在，它们更擅长处理复杂的关系数据。我们发现，大部分浅显的数据信息都可以比较容易地挖掘出来，但要想更深入地利用数据产生更多的价值，就必须挖掘更深层次的信息，这时就一定会遇到这些复杂的关系，这也是为什么图数据库越来越受欢迎的原因。

为什么图数据库开始流行

图数据库的概念最早出现在七八十年代初期，但当时为什么人们没有选择使用图数据库，而是选择了关系数据库呢？我认为主要原因是，当时的计算机并不那么强大，使用二维表格形式的关系数据库对计算机来说更友好。我们知道，计算机最擅长的事情就是重复的劳动，重复的任务。如果我们要在一张二维表中找一行数据，我们可以一行一行查找，或者使用二分查找（如果数据是树状有序的）。每一层都是重复的算法在运行，这对计算机来说是一个非常规整的数据，容易处理。但如果把数据抽象成一张图，那么难度就会大很多，对计算机来说会更难处理。

举个例子，一个员工可能与其他人有各种不同的关系，比如朋友关系、雇佣关系、参与项目关系，每种关系的类型都不同，对应的数据也都不同。此外，一个点上的边数也非常不规律，有的人可能只有几个好友，而在微博上，一个普通人可能有两三百个粉丝，而大V账号可能有数百万甚至上亿的粉丝。这样一来，存储数据时，普通人和大V之间的差距就非常大了，对计算机来说，处理这两种数据的差异也会很大。

我们知道，在七八十年代，计算机相对来说很弱，如果那个时候使用图来表示数据，整个处理和查询的难度就会大很多。所以，人们选择使用关系数据表的形式表示数据。事实上，那个时候有人做过图数据库，但并没有流行起来，原因就是性能相对关系数据库来说差得太多了。

我们知道，所有的事物，尤其是电脑，一直在不断进步。这包括硬件和软件方面的改进。如今的硬件和几十年前的硬件完全不是一个概念，而现在的软件优化也大不相同。随着这些改进，我们会发现对当前的电脑和计算机系统来说，使用图数据库带来的额外开销可能不是很大的问题。

举个例子，我们会发现，过去人们都使用低级编程语言编写程序，但随着时间的推移，有了高级语言。比如最开始、最原始的电脑可能是用纸袋和机器码写程序，后来有了汇编，再后来有C语言、C++，现在很多人都直接写Python。虽然 Python 程序的执行速度可能较慢，但是写的很快，而用用C++或者汇编去写得写半天，对于编写程序到最终得出结果的整个过程来说，使用 Python 会更方便。

计算机编程语言的发展是从低级向高级演变的，数据抽象也是一样。我们认为，未来的数据抽象一定会对人更友好一些，而不是专注于对机器更友好。如图所示，编程语言的发展是从低级语言向高级语言转变的，我们也认为数据抽象层次也会慢慢从低层次表格抽象向高层次图表抽象发展。

图计算在蚂蚁的应用

自2015年开始，蚂蚁实际上投入了大量资源来研究图计算，研究如何在蚂蚁的业务中使用图计算。例如数据血缘应用。在对业务的处理过程中，我们需要较好地追踪这些数据的流转路径，如果修改了一份源数据会对下游数据产生什么影响，会对最终业务产生什么影响。为了更好地追踪，我们使用图数据库来存储数据。

另一个比较有趣的应用场景就是程序分析。相信几乎所有互联网公司内部都有大量的程序，因此，我们需要管理这些程序，并在每次提交代码时了解将会对哪些内容产生影响。为此，蚂蚁负责程序分析的团队会分析这里的图数据。例如，定义一个变量A，然后使用变量A，“定义”与“使用”之间就会有一条边，使用关系会存储在图数据库中。目前我们的图中已经有超过200亿条边，这是一个非常大的数据量。我们需要对这些数据进行存储、查询和分析，这是蚂蚁公司内部非常多的图数据场景之一。

举个例子来说明优惠券反套现的场景：满额返券是一种比较常见的促销方式，比如购物满2000元就可以享受100元的优惠。这种情况下，如果正常消费，用户花费2000元，通过返券省下100元。但是有些人会想办法注册假商铺，进行虚假交易，目的是把平台补贴的优惠券套出来。因此当用户去买东西，平台要去付补贴的过程，我们需要去实时检测一下会不会有可疑的资金交易情况。

蚂蚁有很多业务需要研究图计算系统和图数据库等技术来满足需求，因为这些业务需要对大量的点边进行分析，数据量超过了100TB，基本上已经达到了PB级别。我们需要对这些图进行实时查询，吞吐率大约在百万级别。由于需要对用户的付款进行实时判断，所以需要比较低的延迟，大约在20毫秒的级别。如果延迟太长，会导致用户体验很差，比如付款需要等待5秒才能完成，这样就会非常麻烦。

图计算系统建设中的问题与挑战

在建立蚂蚁图计算系统的过程中，我们遇到了各种各样的问题。为了解决这些问题，我们与学术界和许多研究界的同事一起合作，并发表了许多相关的学术论文，包括EuroSys等。然而，我们在建立系统的过程中发现，目前的图计算仍处于较早期的阶段，因此许多标准尚未成形。这对我们来说是一个棘手的问题。例如，在关系型数据库中，查询语言基本上就是SQL，但在图数据库中，仅查询语言就有许多种，包括Gremlin、G-SQL等等。这导致了市场的碎片化，人们学习和使用的成本也很高。

在建立图计算系统的过程中，我们也遇到了许多挑战。为了分担较大的通信量，需要将图数据分布到多台机器上，但这会导致边的信息在不同机器之间传递，造成大量的通信。此外，单次查询所涉及的数据量也比较大，例如五跳查询涉及的点数就已达到10的五次方，图中还存在一些非常大的点。同时，用户对图计算系统的需求也十分多样，既有快速查询的需求，也有对复杂算法（如社区发现）的需求，单一系统很难满足这些不同的需求。

TuGraph技术优势

蚂蚁自己开发了一套图计算系统TuGraph，既能解决图数据的存储问题，也能解决流式计算、离线计算和图学习的问题。目前，超过100个业务线和300多个场景都在使用这套系统。这套系统在2021年获得了世界互联网大会领先科技成果奖。

在TuGraph中，性能是一个重要的因素，因为图数据集的体积很大，如果性能不佳就会浪费机器资源，导致许多情况下无法完成任务。比如，希望业务的查询能在几十毫秒内返回结果，但是如果做的性能不好，几秒钟才能返回结果，就无法作为在线查询使用。因此，我们是非常对性能是很重视的，其中在 LDBC-SNB 标准测试中（类似于数据库领域性能标准测试TPC-C），TuGraph仍然是世界纪录的保持者。

TuGraph 的整个图存储是建立在完美哈希的基础上的，这是我们与其他图系统的一个重要区别。目前，大多数图系统使用的是基于数的存储，但数的问题在于永远存在一个 LogN 的查找操作。然而，在图中可以看到，不同的顶点之间实际上是无序的，不需要有顺序，所以顶点这个级别实际上是基于哈希的，理论上，顶点的读取是最优的。

此外，TuGraph 还参与了许多标准的定制，整个系统在尽量往标准化的方向去做。

除了为内部提供服务，我们还向外提供服务，主要是因为，作为一个系统，如果只为有限的客户提供服务，就很容易构建成一个专有系统。我们希望这是一个标准化、开放的系统，所以我们也在对外提供图计算系统的产品和服务。目前，我们也有很多外部客户，包括金融、工业、互联网以及政企领域。

开源开放，共建发展

整个图计算系统目前仍处于较早期的阶段，我们认为还有很多工作要做，包括提升应用性、性能和降低成本。所有的系统都会有这些问题。但是，如果希望普及，我们认为最重要的是有健康的生态，来推动图计算系统的发展，需要有更多的用户和更多的场景使用这个系统。

所有的计算机系统都需要去有一个更开放、更大的生态才能促进发展。蚂蚁有一句话叫做“成熟一个、开放一个”，一个系统成熟以后，我们就会试着开放出去，让更多的人去用。今年9月，我们已经在GitHub上开源了TuGraph中的单机版图数据库，以及一个离线图分析引擎TuGraph Compute。分布式图数据库和流式图计算现在已经包含在我们的商业化版本中，包括一站式图研发平台。我们计划在未来迭代更多更丰富的系统功能，希望能做得更好。

TuGraph开源版特色

为什么要去开源单机版而不是分布式版本？主要是考虑到它的部署和使用成本比分布式版本要低得多，同时功能也很完整、独立。我们希望这样可以让许多刚开始使用图数据库或有使用图数据库解决问题的想法的人，可以先尝试用我们的单机版图数据库。因为它的部署非常简单，如果跑起来没有问题，那么再考虑是否需要分布式版本。如果确实需要，我们可以再跟进这个问题。

我们的单机版图数据库已经能够支持TB级别的数据，我们内部也有很多情况使用单机版图数据库。在单台机器上，我们最大的数据量也达到了2TB多，在线上运行，能够处理百亿级别的点边。事实上，大多数用户使用单机版图数据库都是足够的。由于单机版的图数据库很容易优化，我们对它进行了极致的优化，因此单机版图数据库在性能上可以满足绝大多数场景的需求。此外，它的系统特性也很全面，包括高可用性、多图支持、权限管理、日志记录等，它可以被看作是一个成熟、易用的图数据库，类似于MySQL。

图中所列出的开源版TuGraph几个特性包括：

单机版图数据库能够处理数据量几个TB的数据，前提是磁盘足够大。
成本很低，因为是单机版，部署和运维都很容易。
性能很好，我们对其进行了大量优化。TuGraph的LDBC-SNB测试目前是世界第一，大家可以在GitHub上获取测试SNB的条款并进行测试。
单机版图数据库是一个非常易用的完整系统，我们提供了导入导出工具和查询语言。此外，还提供了底层API，用户可以使用它来编写复杂的程序。

我们的开源版本的目标主要有三点：

首先，我们希望提供一个免费的图数据库产品，能够让更多的人使用图数据库，尝试用它来解决问题。

其次，我们希望促进图数据库标准的成形。目前图数据库的差异太大，每个数据库都有所不同，我们希望通过提供一个参考答案来帮助大家达成趋同。这样大家就可以根据我们提供的设计来判断哪些特征合理，如果觉得合理就可以遵循这个设计，慢慢地大家就会逐渐靠近。假如所有产品在主要特征上保持一致，这样所有人的学习成本就会降低。

最后，基础研究性问题可以不断优化发展，包括存储方面的问题，例如哈希可能是理论上最优的，但是是否还有其他需要调整的东西？目前没有一个很好的研究性平台让大家去进行这些尝试和研究，我们希望提供的开源TuGraph-DB能成为这些研究人员的对比基线，促进研究的发展。

TuGraph企业版特色

除了开源版本，我们也继续提供商业版本。这个版本包含一个分布式图数据库，以及离线计算引擎和流式图计算功能。此外，我们还提供了TuGraph Platform一站式图平台，包括运维、可视化等功能。在这个平台上，用户可以在图数据库中执行流式计算，并在线写回数据库。这种方式通常用于实时查询结果，因为流式计算的时间可能比较长，但用户可以立即查询到较早的结果。这对于在线业务来说非常重要。

商业化产品还提供私有化部署，也可以通过一体机的方式部署硬件，并将很快推出云上部署方案，这样大家就可以在云上体验我们的产品。