• 图计算在蚂蚁集团的几种应用类型
• 图计算在落地应用中的趋势观察
• 对数据管理范式的新思考
• 下一代数据管理平台展望

✨✨✨✨✨✨

大家好，我是洪春涛，目前是蚂蚁图计算负责人。今天想跟大家分享一些我们在图计算实践过程的问题和思考，同时希望跟各位老师交流合作。

一、图计算在蚂蚁集团的应用

首先大致介绍一下蚂蚁集团为什么需要做图计算及在图计算上做了哪些工作。

大家知道蚂蚁集团是基于支付宝成长起来的公司，但其实蚂蚁集团的业务线是很复杂的，不止有支付业务，还有微贷业务（如花呗、借呗），社交业务（如蚂蚁森林、蚂蚁农场）。数据类型很多，数据间的关系也很复杂。我们发现图计算在处理复杂的异构数据时非常有效，这也是蚂蚁集团建立国内几乎最大图计算技术团队的原因之一。

1、实时查询需求：支付风控

我们以一个场景为例子，来介绍一下蚂蚁对图的诉求。比如在风控场景中，假设张大妈要给另一位用户马小骗转账，在这种情况下，我们需要判断这笔交易是否正常，是否存在诈骗行为。在这种情况下，我们可以进行几种判断：

• 两点之间是否存在关联？

此外，有时也会出现间接联系。比如我认识张老师，而张老师又认识A，那么我向A转账可能也会相对安全。通常情况下，我们会实时进行这种判断，因为转账时用户不希望等待太久。我们通过实时的图数据库查询来完成这个过程。

• 交易帐号周边是否有风险标？

2、流式计算需求：花呗反套现

刚才讨论的是实时能够查询的情况，但有些情况较难实时查询，例如花呗反套现的案例。类似于信用卡套现，花呗也面临相同的问题，用户会试着去套现花呗，特别是一些黑产、灰产。那我们怎么去判断套现行为？

套现行为的典型特征是往往会有一个回路。因为花呗无法直接兑换成现金，只有在消费交易时才能使用，用户往往通过虚构交易来实现转账。黑灰产就会开设虚假商店，把钱套付给虚假商店，虚假商店再把钱给他，就构成回路。在实际操作中，这个回路可能涉及多次跳转。网上有真实的新闻案例，案例中绕了4、5跳去实现套现。对于这种多跳的情况，实时计算是比较困难的。

为了应对这种情况，我们现在使用流式计算系统进行预计算。当有一笔转账时，系统会即时触发计算，以确定是否存在回路。如果过去没有类似情况，也避免客户等待，系统会先放行这笔交易，并同步计算这笔交易（计算可能需要几十秒到几分钟），将结果存储在在线的HBase或图数据库中。下一次转账时，可以查询上次的计算结果是否存在回路，从而对潜在问题进行预判。这里存在的问题就是，如果第一笔转账属于套现行为，那它是没有被拦截的。

3、离线分析需求：团伙挖掘

第三种需求是离线计算的需求。因为有很多复杂的迭代计算还是需要离线去做，比如团伙挖掘。我们平时使用最多的是类似社区发现、团伙挖掘的算法。例如接到公安机关告知某些账号是洗钱账号，那么我们就需要去挖掘洗钱账号周围是不是有团伙的其他帐号。

4、TuGraph一站式图数据管理系统

目前TuGraph一站式图数据管理系统，从实时的查询、流式的计算到离线的计算和学习，都有相应的系统去承接相应的业务。

蚂蚁从16年开始做图计算到目前已经八年多了，系统的完备性相对较高，其中存在的一些问题我们稍后也会进一步分享。TuGraph已经在蚂蚁有了大量的应用（300+），不只是刚才说的这些风控相关的例子，包括社交会员的推荐、营销、数据血缘等等，大量的业务都在用图计算。

二、图计算在落地应用中的趋势观察

下面我分享下，在与用户进行业务合作的过程中，我们发现的一些有趣的现象。

现象1：用户倾向把图数据库当仓库

我们现在有一些相对比较大的业务。比如说安全部门负责交易和内容的风控，下属有多个业务条线，如反欺诈和反洗钱等。在我们为不同业务搭建图数据库时，我们发现用户更倾向于使用同一张图，而不是像在关系数据库中那样为不同业务建立多个独立的表。在关系数据库中，例如社交业务会创建自己的社交表，而安全业务则会有自己的安全表，尽管它们的核心数据（用户账户）是相同的，但一定是不同的表。当然，每个人用到的图中的属性是不一样的。同一张图中每个用户账户对应一个顶点，但每个顶点可能包含很多不同的属性。我们统计发现，图数据库中大多数顶点的属性数量在50-500之间。这显示出用户在使用图数据库与使用关系数据库的用户行为不一样。

在用户使用过程中我们也发现了一些问题。

首先，当前只有一张图，所有不同类型的点和边都混合在一起。以账户为例，转账边和好友边都存储在账户节点上。不同业务对数据的使用模式不一，却将它们聚集在一起，导致访问效率会有问题。

第二，由于每个点上都有许多属性，且这些属性有不同的业务使用，使用模式也不一样。原来在关系型数据库里实时业务通常使用TP系统，TP的系统一定是行存。但是属性太多的话，一旦更新整个行都要更新，代价太大。我们目前实时查询的数据库还是行存，更新的压力比较大。

第三，由于多个业务部门共用一个图，管理机制相对复杂。在原来关系型数据库中，各部门可以独立创建表并且根据业务需求随意调整。但现在若要增加新的点或属性，必须与其他部门沟通协调，增加了管理开销。目前我们设有专门的数据管理委员会来处理这些事务，但相对来说比之前关系型数据库要复杂一些。

现象2：复杂查询实时化

我们观察到，业务希望把越来越复杂的查询给实时化，业务希望查询越实时越好。尤其在风控场景，最初我们采用离线方式进行查询，例如T+1的模式，今天处理数据，明天使用结果。后来我们意识到1小时或者1天的间隔过长，逐渐转向流式处理。

流式处理能提高数据新鲜度，慢慢我们把越来越多的查询放到实时系统里面去进行，这在用户体验和风险对抗上效果更好，但也带来了成本增加的问题。最典型的就是用流式的预计算去做风险判断时，大多数操作不需要触发很复杂的风控策略或者查询，例如我给我老婆或者朋友转账。若两人关系良好，或彼此芝麻信用分较高，转账时大概率是没有问题的。因为我们无法预测哪些查询会被使用，因此如果对每一笔转账进行预计算，以便在需要时能迅速查到结果，就会浪费很多的预计算的能力。实际上，大多数人际网络较小，查询到三度、四度甚至五度关系，都能实时查询。只有面对较大数据点时，才可能会查不出来。然而，对于这个分界目前并没有明确的标准，这个分界也是在动态变化，这也是一个较大的问题。

现象3：关联分析复杂化

最后一个趋势是越来越多的用户开始使用更复杂的关联分析，尤其是在离线分析方面。之前，离线分析主要依赖ODPS，外部工具如Spark和Hadoop等。但我们发现用户的查询变得越来越复杂，分析需求也随之增加，某些复杂的join场景在内部的ODPS中无法处理，因为过多的join次数导致系统无法承受。因此，我们选择使用图计算来解决这个问题。

使用图计算的一个优势在于，可以预先进行部分join操作。具体来说，每个账户对应的数据被预先放置在该账户的节点附近，这相当于预先完成了一次join，从而减少了实时计算的需求。在我们的观察中，利用图计算引擎进行复杂关联分析时，性能提升可以达到十倍以上。当然，目前我们尚未严谨分析其中有多少收益源自join操作，多少源自系统实现。因此，我们希望未来能有更多人协作，深入研究这一问题。

三、重新思考数据管理范式

刚才分享了一些在实践中遇到的问题和思考。我们意识到，当使用图进行数据管理时，会产生一些跟原来用表很不一样的东西，例如，大家更倾向于将相同的账户上的所有数据都集中到一个节点上。我们也一直思考这些意味什么。

回顾数据管理的早期阶段，主要是以业务为驱动。在各个业务有需求的时候建表，满足自身需求，不需要与他人交互。这种架构在七八十年代的背景下是最优的，因为当时后台分析很少，通常只是简单的报表，这样的架构对系统整体成本较低。

然而，随着大数据分析的发展，机器学习、数据分析、复杂的实施指标越来越多，后台应用也随之增多。这使得我们需要将多个前台表格整合在一起，随之而来的就是数据治理的问题。因为不同表格之间的数据是否对应、是否存在冲突、是否完整等问题，早期没有人去关注，在后期试图去治理就很困难。我们现在发现数据治理的问题其实越来越大，成本也是越来越高的。

如果用图来进行数据管理，会不会有所不同？我们发现，使用图来进行抽象时，用户自然会认为账户就是同一个账户，只不过用的属性不同，而不会存在同一账户存在多份不同数据的冲突。这种设计也可以促使用户在项目初期就考虑数据管理的问题，当用户希望新增属性时，就需要强制性通过数据治理委员会整理相关事项，避免了“先污染后治理”的情况。如果采用图的方式，数据治理可以在一开始就做好，从而保持后续数据的干净。从趋势上看，后端的这个分析会越来越重要。因此，使用图来作为数据管理的抽象和底座会更为合理。

用图来管理所有数据，有以下优势：

1、数据质量更高：因为提前规划数据治理，长远看数据质量会更高。长远看，数据质量是非常重要的。

2、语义丰富：所有数据都在一起，没有“分表”-“聚合”，不用在分布式文件系统一个一个找，只要找到账号，所有相关数据一定在附近。

3、支持深度关联分析：用图去做深度关联分析，从性能上是有优势的。

4、抽象更自然：用户也反馈，他们觉得图的抽象表达是更自然的。

四、GraphUniverse：下一代数据管理平台

所以我们觉得图来管理所有数据是比较有前景的事情，我们正在做一个名为“GraphUniverse”的系统，从最前端的业务到后端的分析，整个都是用图的抽象来做。

我们刚才讨论的是一个宏观愿景，在此基础上我们需要脚踏实地解决一些具体问题。这包括存储问题、不同类型点边及属性放在一起如何保障效率、不同属性数据管理问题、前面提到的预计算问题怎么解决等等。这些都是我们这个系统里正在做的事。当然还有很多更长远的问题需要解决，我们今年联合CCF发布了图计算的专项科研基金，期待吸引更多老师一起合作，深入研究里面的问题。

GraphUniverse系统于今年年初立项，今年完成基础版本，并上线内部系统。预计明年初发布开源版本，希望能有更多人参与研究和实验。长远来看，我们希望真正将图做成一个数据管理的底座。

总结下来，我们在图的应用过程中发现了许多问题，思考这些问题的时候发现并认为利用图进行数据管理对整个数据管理体系是更合适的解决方案。未来我们希望在原生图存储、图查询优化、图物化视图、自然语言交互等多个课题方向与更多老师及专家学者合作。感谢大家的关注与支持。