分享嘉宾：周强 蚂蚁集团 技术专家
编辑整理：娄政宇 阿里巴巴
出品平台：DataFunTalk

导读： 今天给大家带来的分享主题是蚂蚁集团自研的流式图计算引擎GeaFlow及其应用。主要内容包括：

• GeaFlow的基本介绍
• GeaFlow的技术架构
• 基于GeaFlow的应用实践
• 总结和展望

01 GeaFlow的基本介绍

1. 什么是图

我们知道图论起源于哥尼斯堡的七桥问题。数据结构的图由顶点的集合和边的集合构成。在我们现实生活当中，图无处不在，包括像资金网络和关系网络等。图相较于传统的表结构，具有如下几个优势。

① 维度的提升

图结构能够表达丰富的数据和关系。比起传统用表的方式去存储信息和组织模式图，图可以很清晰地揭示复杂的模式。尤其在错综复杂的社交金融风控领域，它的效果更为明显。

② 高效的查询、分析

图数据，充分地表达了数据的关联性。基于图可以做一些非常高效的查询和分析。同时基于图我们可以更方便自然地对数据进行建模。比如我们可以通过任意类型的点去表示对象，通过边去表示特定的关系。

2. 应用场景

图的应用场景也非常广泛，例如我们所熟知的关系网络中常见的好友推荐、认识的人、朋友的朋友，以及社群划分、相同兴趣爱好的人等。在知识图谱领域，也可以做关系挖掘，查找共同根结点以及最短路径分析等。另外，在金融风控领域，我们可以做异常资金的流动监控和企业风险的评估。

3. 为什么做实时流图计算

首先我们知道在传统的大数据和数据库领域中，有离线计算、实时计算，以及关系型数据库这样的系统，这些系统本身都是基于table结构的。基于graph的结构在同样的推导下应该有同质的系统出现，比如图数据库和离线图计算以及实时图计算。

早在2017年以前，蚂蚁内部就已经有了图数据库和离线图计算系统。 我们在内部开发实现了一套实时图计算的能力，基于实时的关系数据，可以进行流图融合和时序增量的图计算。在通用的实时计算领域，我们基于关系的数据，可以进行流计算和实时的OLAP分析。随着数据结构的升维，我们在图数据上面也可以衍生出图的流计算以及图的探索分析。

基于以上的思考，我们在2017年开始研发了一套流图的融合计算系统，并且在2018年支持了实时反套现这样一些双十一业务上线；然后基于现在流图的融合计算能力和蚂蚁内部业务的思考， 我们提供了一套仿真的能力 。将在下文进行详细的介绍。

我们基于早期的流图融合计算，可以很好地支持一些内部的应用场景。但是基于动态子图的图计算，无法从全图的视角去看图的变化，比如在图智能的资金核对的场景中，需要我们从全局的图的视角去看财务之间的变化。所以，基于这样的业务场景的诉求，我们在之前的系统能力之上，构建了一套增量的动态时序图计算的能力。通过时序增量的图计算能力，在动态图上，我们可以进行增量计算。另外为了满足内部的研判、血缘分析等交互式分析的场景，我们提供了一套图探索的能力。

02 GeaFlow的技术架构

GeaFlow是蚂蚁内部自研的实时图计算系统。 首先我们提供了DSL化的研发能力，可以方便用户快速开发和上线应用。其次我们打造了一套Mix的计算引擎，也就是多模态的计算引擎。相比通用的大数据系统如flink 、spark主要是基于table的结构，GeaFlow主要是基于graph数据进行计算。

我们这里说的支持分布式动态图，可以从两个维度来理解：

首先数据本身是动态更新的，也就是图本身是一个动态的图。其次，我们和Ray一起构建了一套可以动态拉起DAG执行的能力。融合这一块，我们是把SQL和Gremlin融合到一起，一体化去执行，这样可以在一套编程体系里面去实现丰富的业务逻辑。同时，放在一起之后，可以打造端到端的低延时，包括一些优化也可以统一考虑。相比之下经典的先通过流计算系统做一些处理、再把结果写到消息中间件，下游再拉起Graph System，这样整个端到端的延迟会很高，同时也将增加业务的成本。

这是GeaFlow的整体架构 。最底层是分布式执行引擎Ray，第二部分是统一的图存储。统一的图存储是蚂蚁内部的Graph Store，在此之上我们实现了一套基于Task Base的动态图计算框架。当然Ray本身是actor model的引擎，因此其也具备Task Base的能力，在其之上我们做了更上层的一些语义的封装和抽象。

上一层是统一的执行计划。这里的统一执行计划其实就是把SQL和Gremlin放一起后会生成一个统一的大DAG去执行。

以图为中心的多模态计算能力，是把多种计算能力融合到一起。云化的状态管理是指我们基于DFS实现了一套云化的图状态管理系统。其本身就是计算存储分离的能力，我们将基于流式的方式去访问它。

在上层我们定义了一套GraphView的核心的API。我们认为GraphView是动态图的视图，在动态图的视图上可以做图的遍历计算和增量计算。

最上层是DSL表达层。我们会把SQL和Gremlin放在一起构建HybridDSL的能力。

1. 动态计算

动态计算是GeaFlow系统中一个核心的系统能力。

通用的大数据基本上都是静态的DAG，比如最早的MapReduce是静态的DAG，包括流式系统flink和storm，也都是静态的DAG。在spark上虽然可以去实现一些简单的动态逻辑，但是无法做到在动态图里执行SubDAG。这时会面临一个问题，就是通用的方式可能会把当前的计算状态落盘。落盘会带来一些问题，一方面对于用户本身的编程接口不太友好；另一方面也会导致端到端的延迟更高，研发和运维的成本也会更高。 这里我们的解决方案是和Ray结合 ，通过Ray的动态能力，我们在运行的DAG里面动态地拉起SubDAG以执行，在SubDAG里面可以进行子图的匹配、迭代和计算。

2. 融合计算

融合计算的能力之前已经提到过，首先以反套现的场景为例，其并不需要将每一次的回款行为都进行子图匹配，而是通常需要先做一些业务的处理和判断，比如可以基于实时统计的笔数、交易和回款的金额，在满足了一定条件的情况下，再进行子图的迭代。基于子图的迭代结果，我们会在数据链路处理完之后，回写到table里，供在线使用。 这样的场景包含了流计算和图计算两种模态的能力。 在通用的解决方案中，需要将流计算和图计算组合起来使用，比如通过将flink、spark graphx等多个系统串联起来，这样一方面增加了用户的学习成本，另一方面因为需要构建上下游的衔接，会增加一些不必要的数据存储和端到端的延迟。这里我们通过融合计算，可以打破传统计算的边界，降低运维和开发的成本。

在2017年开始做流图融合计算时，业界基本没有人在做，包括paper里也很少看到，当前学术界也在逐步关注流图计算。我们认为streaming是底层的能力，其既能支持table的数据结构，也能支持graph的数据结构。

3. 分布式Gremlin

这一块是我们在Gremlin上做的工作，为了支持图遍历和图计算的能力，有用到Tinkerpop Gremlin的语法，我们会将其编译成流式图计算引擎上的分布式能力。

相比于通用的Gremlin，其底层是graph store，每个server执行相应的图查询。GeaFlow会将Gremlin脚本构建成分布式的图任务，在我们计算引擎里分布式执行。

4. 一体化DSL

为了便于用户一体化地开发他们的业务应用，GeaFlow提供了一套混合DSL的能力，用户可以通过SQL去构建整体流程 。在数据流到达时，可以触发子图匹配和子图遍历，或者SSSP最短路径的分析等。最后业务会将结果回写到table里面。因为在当前大数据领域，table的使用是更为广泛的，所以我们将graph和table融合到一起，希望将这个事情做得更大。

5. 离线实时一体化

先讲一下背景，传统的业务上线流程为：在定义了业务目标后即开发测试上线，上线后再经过长期观察，验证业务的策略或者特征是否有效。但该流程非常长，所以 我们构建了一套图仿真能力 。

先介绍一下仿真的背景 。仿真是有一定的业务语义。在反套现场景中有一些资金环路存在风险，具体怎么验证环路真有风险，需要根据历史的行为进行验证。其本质是在图的每一个快照上面进行子图的匹配，和实际用户是否发生了套现或者是其他的行为进行对比。这个行为本身就是仿真，这里面临的挑战就是周期会非常长。我们都知道信用卡使用场景，一般用户都是先用信用卡进行支付，最后还款，周期在一个半月左右。而在信贷借钱的场景中，从借钱开始到最后还款，其周期更加长，比如半年甚至一年。从借钱开始到最后发生逾期行为，其时间间隔非常长，所以我们需要通过历史长周期的数据进行仿真。

这样带来的问题是窗口比较长 。相对于典型的大数据计算，比如Flink进行GMV统计时，通常是统计从零点到当前的成交金额。但信贷场景需要看历史长周期，需要通过七天窗口或者更长的窗口进行计算。因此业务的图仿真是既需要长周期，也需要长窗口。GeaFlow通过图数据的历史请求，进行流式回放，用以打造实时仿真一体化，即实时离线的一体化。

通过图仿真能力，可以让业务在正式上线之前进行验证，从而策略和图特征能真正被用起来 。基于仿真的特性，计算会访问历史快照，因而将导致图数据的膨胀。为此我们支持了驱动式的GC策略，以减少无效的存储，同时还引入了多级缓存的策略，提升整个仿真的吞吐。最后业务通过定义、分析、仿真、上线的研发流程，可以大大减少由于提前上线，没有预判到业务的策略或者算法是否有效的问题。

03 基于GeaFlow的应用实践

基于GeaFlow一系列的核心能力，我们在蚂蚁集团已经支持了非常多的业务场景。

1. 实时团伙挖掘

账户风险的识别，基于用户的账号网络进行风控分析，能够有效识别账户的风险。同时在反作弊场景，黑产作案其实没办法简单地通过一度关系进行判定，而通常需要经过2到3度以上的迭代才能判定。通过黑产的聚集性，使用社区划分或社区搜索的算法进行群组挖掘。

在账户风险识别的场景中，团伙从注册到作案通常发生在秒级。还有在反作弊的场景，其团伙的防控时效性也基本都在秒级。以账户风险场景为例，业务基于用户和团伙的账号，挖掘团伙的一些行为，然后流式增量地构建一个金融级的可靠账号网络。基于GeaFlow提供的动态时序图计算能力，可以进行快速的分析和决策。业务上线前将通过图仿真的能力对策略和特征进行验证，用以判断当前的算法是否有效。

经过线上业务使用的对比，我们可以看到基于通用的Spark Graphx进行全量群组挖掘的模式，其规模在亿级点边时可以做到小时级的产出。基于GeaFlow增量实时的群组挖掘能力，业务可以在百亿级的点边量上做到秒级的产出。

2. 流式增量团伙挖掘

流式增量团伙挖掘，业务首先会进行事件前置的预处理，将事件过滤后回写到中间件。下游再进行流式的特征调用，并进行相应的特征预处理。随后将事件和特征解析成相应的点边数据，接着进行团伙挖掘的图计算。通用的团伙挖掘图计算算法，有支持CC和LPA等，业务可以基于相应算法实现业务语义和业务逻辑的开发。首先进行子图的扩展，然后进行聚类，最后将团伙挖掘出来的结果写入在线存储，以提供在线查询。

3. 增量时序图计算

增量时序图计算 。Source按时间窗口进行数据读取，一方面将Source数据进行解析生成增量图的点边数据，增量图在内存中存储；另一方面生成的增量图的点数据会作为Trigger Vertex，用以触发整个增量图的处理。图处理即为典型的迭代计算，在计算过程中将同时访问增量incremental state和历史base state。由于业务需要从全局的角度使用整个图，因此在计算中一般会先扩展子图，然后进行团伙挖掘的计算工作，最后将结果写入在线存储提供实时查询。

最后，在当前窗口的数据处理完团伙挖掘计算后，系统会自动通过异步化的方式将该迭代增量的state写入base state，以有效提升state update的性能。在下一窗口的增量计算时，上一窗口产生的增量state是实时可见的。

以上即为增量时序团伙挖掘的业务效果 。在百亿级规模的时序图计算场景下，业务使用6+度团伙挖掘的复杂算法，可以秒级产出计算结果。通过离线和实时一体化的能力，将业务研发的效能提升7倍以上。

04 总结和展望

GeaFlow实时图计算系统，提供了一整套的实时计算能力。

首先，为了方便业务快速开发，系统提供了一套DSL化的研发能力。其次，通过分布式Gremlin的执行，GeaFlow支持了图遍历和图计算的能力。然后，通过将SQL和Gremlin结合，GeaFlow支持了流图融合的能力。最后，基于上述特性对系统进行了扩展后，GeaFlow提供了时序图计算、图仿真和图探索分析的能力。

基于GeaFlow提供的实时图计算能力，系统为业务提供了一套科学完备的研发流程（定义->构建->分析->仿真->上线）。

目前为止，GeaFlow在蚂蚁内部支持了300多个业务场景，其中包括风控、社交、营销，还有知识图谱、图学习等场景。

基于GeaFlow系统的演进以及内部业务的发展，我们认为实时图计算和AI的结合，将会为业务发挥更大的价值，例如在知识图谱领域，我们可以做知识的推理。在蚂蚁内部业务中，已经和图学习进行了相应融合，通过动态时序图计算能力，业务会采用不同的算法模型进行流式embedding学习，并取得了非常不错的效果。

分享嘉宾：