蚂蚁金服过去十五年,重塑支付改变生活,为全球超过十二亿人提供服务,这些背后离不开技术的支撑。在 2019 杭州云栖大会上,蚂蚁金服将十五年来的技术沉淀,以及面向将来的金融技术创新和参会者分享。咱们将其中的优秀演讲整理成文并将陆续发布在“ 蚂蚁金服科技”公众号上,本文为其中一篇。
今年 4 月,蚂蚁金服董事长兼 CEO 井贤栋在参与第二届一带一路国际合做高峰论坛时表示,经过九年的实践,蚂蚁金服改善了中小企业的融资渠道并造成了 310 模式,即 3 分钟在线申请、1 秒钟审核放款、0 人工干预。与此相对的是,仅仅在两年前,有相关人士表示,他们出台的 310 模式倒是 3 周申请,1 月审核,0 概率获贷。算法
那么,蚂蚁金服是如何经过不断探索应用金融新技术,为中小企业提供融资便利,其中的 1 秒钟审核放款,又是如何作到的呢?在这里,咱们来谈谈其中很是关键的一项核心技术,在线图计算技术。数据库
在线图计算就是将流式计算与图计算结合起来,能作到进行实时的图计算的技术。蚂蚁金服在这个方向上通过多年研发,在关键技术上作出了突破性的建立,并造成了面向金融场景的解决方案。编程
蚂蚁研发在线图计算技术,是由于金融场景须要这样的技术来解决问题。缓存
好比,在金融风控中的实时反套现场景。套现,指的是采用违法或者虚假的手段交换而获取现金利益的行为,通常多用于信用卡和公积金等场景。网络
花呗是一个消费信贷类产品,用户能够基于花呗的额度消费,并按期还款。花呗反套现是花呗总体风控中很是关键的一个环节,如何实时的、准确的识别套现行为则是花呗反套现的关键。架构
如图所示,套现的买家经过花呗进行一笔交易的支付,并经过一系列复杂的资金流动,最终经过转帐回款进行资金的套现。并发
经过数据建模,将总体的资金流动抽象成资金关系网络,基于资金关系网络之上进行子图的识别和分析,从而有效的识别套现行为。负载均衡
经过实时反套现的例子,咱们能够获得在线图计算的三个基本需求:运维
再说说你们比较熟悉的蚂蚁森林场景。分布式
蚂蚁森林中有多种形式的好友互动,如支付宝好友之间能够互相收取能量,以及好友、亲人之间能够一块儿合种一棵树。
在蚂蚁森林中有人与人的关系,以及人与树的关系等。它不只须要支持实时的关系数据构建,还须要支持高性能低延迟的关系数据查询和一致性的关系数据修改等需求。
经过蚂蚁森林的例子,咱们也能够获得在线图计算其余三个需求。
经过前面实时反套现和蚂蚁森林的例子,咱们对金融级的在线图计算的需求作一下简单的总结。
咱们将需求分红两部分,第一部分是功能需求:
第二部分是稳定性需求,因为金融场景的特性,因此稳定性显得尤其重要。这里主要列举两点:
在介绍完蚂蚁金服在线图计算相关的场景和需求以后,咱们来一块儿了解下蚂蚁金服在线图计算的核心关键技术及过程当中的思考。
首先,咱们来一块儿看下蚂蚁在线图计算的总体架构图。
在最上层,蚂蚁在线图计算提供一套统一的图开发平台。基于统一的图开发平台,用户能够基于关系元数据和统一的 DSL 进行做业的开发。目前统一的 DSL 主要经过 SQL 和 Gremlin 融合的方式进行编程开发。同时基于用户的 DSL,会实时的构建分布式的 DAG 进行运行。
构建完成后,分布式的任务会实时的对线上的日志数据和事件数据进行实时的处理。这里主要包含两条链路,一条链路会基于实时处理完成的日志数据和事件行为会写入到高性能的图数据库,并基于数据实时的构建高性能的图缓存,提供快速高效的子图抽取。
另一条链路则会基于实时处理的数据,来动态的决策是否须要一个图的 Traversal 和计算,并在计算的过程当中,从高性能缓存快速的抽取子图进行计算,最后将计算的结果输出提供在线使用。
经过前面的架构图,能够看到,蚂蚁的金融级在线图计算主要有三个技术方向:
下面,咱们来分布分布介绍一下这三个方向的核心技术点。
第一个关键技术是:流图融合计算。
以花呗反套现的场景为例,并非每一笔交易或回款行为都须要进行套现行为的识别,须要先进行必定的规则的处理。好比,基于实时的统计交易的笔数或者回款的金额,在知足必定的条件后才开始进行子图的迭代计算。最后,基于图的迭代计算的结果,在进行数据链路的处理后再提供给在线使用。所以,一个场景在完整的计算链路中,须要流计算和图计算两种模态的融合计算。
在传统的计算方式中,则会经过流计算和图计算进行组合的方式来实现全链路,好比经过 Flink、GraphX、Neo4j 等多个系统进行串联。 可是经过传统的方案,用户须要学习多套系统,而且须要维护多套系统进行衔接。并且因为多套系统衔接,所以会产生额外的数据存储和延迟。所以,在蚂蚁金服,咱们打破计算模态的边界,将流计算和图计算进行融合,提供流图融合的计算系统。用户能够经过一套 API、一套计算系统来实现完成流图融合的链路,因为是一套系统,同时能减小用户的运维成本。
一样以花呗反套现场景为例,在实现了流图融合的计算能力以后,因为是否进行图计算,以及采用什么样的图计算算法都是由数据进行动态决策,没法预先设定。所以,传统的静态 DAG 没法知足当前的需求,这里,咱们经过将数据流和控制流相结合,并提供动态 DAG 的能力,从而实现按需计算,弹性的扩缩容。
在提供了融合计算和动态计算的能力以后,如何让用户进行快速便捷的开发显得尤其重要。
这里咱们经过 SQL Plus(Gremlin)的方式进行融合计算的开发,用户能够经过 SQL 来构建总体的 Pipeline 的流程,同时,引入 GraphView 的概念,基于 SQL 能够离线和实时的构建 Graph View。基于 GraphView 之上,能够经过 SQL+Gremlin 实现基于数据驱动的在线图计算能力。
同时,因为 SQL 大部分开发者都比较熟悉,能够减低用户的学习、开发、调试的门槛,易学易用。目前蚂蚁金服也在关注最新的图查询语言国际标准 GQL,将来也会融入于此。
基于以上三个特性,用户能够快速的构建流图的一体化做业。
接着,用户在上线一个算法策略的同时,则须要对策略进行验证,这里用户须要针对流式的数据进行有效的仿真,来断定当前的算法是否有效。
基于当前的在线图计算架构,咱们能够经过模型的有效抽象,将历史的图数据和请求进行有效的回放来实现仿真和在线的一体化架构能力。
与此同时,因为仿真的特性,会对历史版本的数据快照进行访问,从而会引发图数据存储的加速膨胀。 因为这里采用流式回放的方式进行仿真,咱们能够经过基于驱动的数据 GC 策略,从而避免数据的过量膨胀。 同时,基于多级缓存的策略,从而实现提高图仿真的吞吐能力。
以上就是融合计算方向的四个关键技术,经过以上的四个特性,用户能够高效、方便的进行任务的构建和计算。
接下来,会讨论如何快速的进行子图构建。
这里重点介绍一下蚂蚁的高性能图缓存,基于完美 Hash 函数和专业的压缩能力,将数据缓存在内存中进行在线服务,从而实现子图场景下的低延迟和高吞吐。
针对高性能的图缓存,内存的占用显得尤其重要。这里重点看下蚂蚁图缓存和业界系统的压缩比对比图。这里采用的是基于 Twitter 的 User-Follow 的开放数据集。
能够看到,因为图的关联特性,因此业界开源的系统在原始图的基础上,都有必定程度的放大,而业界作得比较好的 TigerGraph 作到了相对于原始大小的 40% 左右的内存使用。而蚂蚁的图缓存能够实现 20% 的原始内存大小。比目前业界最佳,还要节省一半的内存使用。
经过高压缩比,咱们将图数据完整的存放在内存中,下面咱们能够对比一会儿图抽取的 RT 性能。
一样是基于 Twitter 的 UserFollow 的数据,能够看到在 1 度、2 度、3 度的场景下,特别是 1 度的场景,总体的时间延迟仅是 Tiger Graph 的 20% 左右。
经过高性能图缓存,针对子图的高性能查询,才能实如今线的实时链路计算。
下面咱们来看下,如何实现金融场景下的高可靠和一致性的能力需求,这里重点介绍下蚂蚁的金融级图数据库 GeaBase。
GeaBase 内部经过实现 Mirco Shards 的方式来实现数据分片。并基于 Mirco Shard 的数据分片实现 Cost-Base 的数据迁移和自动的负载均衡。同时,借助于蚂蚁的基础架构体系,实现了三地五中心的城市级容灾策略。
经过对比,咱们能够看到,在单机、单副本和机房级故障时,GeaBase 的灾备能力均优于 HBase。与此同时,在城市级容灾的场景下,GeaBase 能够实现数据的恢复和不丢失。
与此同时,GeaBase 还实现了一致性的能力,来知足金融场景的数据强一致性的需求。GeaBase 经过实现 Raft 协议来实现数据的一致性。而且可让业务根据自身业务需求自由选择,是最终一致性仍是强一致性。
蚂蚁的在线图计算目前普遍应用于蚂蚁的多条业务线,支持了风控、社交和营销等 100 多个业务场景。当前在蚂蚁内部有 2000 多台机器的集群规模 7*24 小时运行。
与此同时,蚂蚁逐渐把这些能力输出给外部金融级客户,如常熟农商银行和泰隆银行。好比在常熟农商银行,蚂蚁金服与行方联合共研了蚁燕知识图谱项目,基于蚂蚁研发的在线图计算技术,在大数据量环境下,经过海量关联分析,提早进行担保关系预判,实现担保圈风险的秒级预判和风险提醒,有效管控风险的同时,切实提升了信贷审批效率。蚂蚁金服不只本身实现了 310,还经过合做输出给客户,为实现普惠金融而努力。
将来,蚂蚁金服会继续打磨在线图计算的技术能力,并向更多的合做伙伴开放,一块儿将在线图计算推广到更多的场景中去。