Fork me on GitHub

周强:蚂蚁集团流式图计算引擎 GeaFlow 的技术架构与应用实践

图片

分享嘉宾:周强 蚂蚁集团 技术专家
编辑整理:娄政宇 阿里巴巴
出品平台: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学习,并取得了非常不错的效果。

分享嘉宾:

图片


本文地址:https://www.6aiq.com/article/1656578153443
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出