ITBear旗下自媒体矩阵:

一套架构兼容所有计算,蚂蚁金服是怎么做到的?

   时间:2019-10-18 17:30:38 来源:互联网编辑:星辉 发表评论无障碍通道

引言:

蚂蚁金服在过去十五年重塑支付改变生活,为全球超过十二亿人提供服务,这些背后离不开技术的支撑。在2019杭州云栖大会上,蚂蚁金服将十五年来的技术沉淀,以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在“蚂蚁金服科技”公众号上,本文为其中一篇。

正文:

十几年来,蚂蚁金服一直在解决用技术重塑金融服务的问题,在解决这个问题的过程中涉及到两个方向的技术领域,第一就是解决怎么把钱从一个帐户移到另一个帐户,这个过程中出现海量、安全、可用性问题怎么解决,我们的答案就是多地容灾、高可用的分布式架构;第二,新的数字金融时代到来,如何更多更好的利用数据驱动业务发展,也就是数据智能技术。本文将会分享蚂蚁在数据智能方面的一些进展,以及我们的思考。

首先,我们看一下金融数据智能有哪些需求,和传统的大数据有什么不一样的地方:

实时性要求高,实时数据以两倍以上的速度增长,在线决策越来越多,不再是把数据离线做决策再部署到线上;

计算场景复杂多样,以前可能是一个简单的聚合,逐渐进化到用规则做决策,基于图、基于机器学习等决策,整个计算的形式越来越多样化;

数据链路长,研发调试效率低,当你要做全链路数据研发的时候,从头到尾会经历十几个系统,对整体的数据研发提出了很大的挑战;

计算及存储高可用,包括跨城市的容灾,高可靠的计算服务;

数据安全、监管合规、风险防控, 需要做严格的数据安全和隐私保护,特别在监管层面要合规。

过去十几年,计算技术不断演进,从大规模数据仓库批计算,到实时计算和流计算,再到交互式分析,一方面能解决一部分问题,另一方面给我们带来了新的挑战。比如,多种计算模式带来多次研发的效率问题,多套系统带来多样存储需求的成本问题,以及不同容灾和数据安全要求带来的复杂度问题等。

为了解决计算多样性带来的问题,我们需要一个更为开放的计算架构。

蚂蚁金服开放计算架构

做一套系统解决一切问题是技术人员很自然的想法,但难点是怎么定义这个系统的边界。我们认为,计算和业务本身是紧密连接的,业务的需求变化很有可能需要探索越来越多的计算模式。所以我们的实践是这样的开放计算架构,它在不同层面上做了统一,以兼容不同的计算模式。

首先是统一存储层,将各个存储系统打通进行数据共享,这样一来就可以根据计算需求做定制化的优化,内部数据自动回流。

第二是统一数据安全规范,在统一存储上实现统一元数据管理及接入,并且数据血缘互通,统一鉴权及数据访问权限体系,统一数据安全等级和隐私保护体系。

第三是统一编程模型,基于标准SQL和扩展,做业务研发的时候面对的是下层抽象出来的数据,真正做面向数据的编程,不需要关注用交互式分析还是其它计算模式,也不需要关注数据是如何存储的。这样做数据研发以及写业务逻辑的时候可以提升效率。这方面我们做了很多的探索,目标就是当你在做SQL研发的时候可以降低两个数量级,原来可能要写几万行代码,现在只写几百行。

经过这些统一我们形成了如上的架构,这个架构可以根据新的技术进一步扩展。

开放计算架构下的AI引擎

AI计算是开放架构下重要的能力,我们需要打造更加灵活智能的AI引擎。

目前绝大多数公司的人工智能系统,会遵循这样一个架构:有一个数据仓库或集群进行数据清洗和预处理,然后取出一个表,和数据标注一起在一个模型平台上进行训练,训练出来的模型最后再部署到线上去进行预测。这整个流程经过了多个系统,所以这个数据事实上可能会有多份存储,加上模型的传输也会花费比较多的时间,你很难做到真正的实时性,这里面用户也往往需要研发多个平台和组件才能满足需求。

开放架构下可以插入AI引擎,我们在SQL层和深度学习引擎都做了一些工作。SQLFLow相当于用SQL描述你对应用的需求,底层会直接针对SQL产生出机器学习的任务来训练模型。

ElasticDL我们刚刚在9月11日宣布开源(头条附上超链接https://www.toutiao.com/i6735349206833168903/),它是基于TensorFlow的一个弹性调度的AI引擎。当你资源紧张或者发生错误时,仍然可以进行高效的AI训练。同时它让AI的训练变得更加简单,可以在命令行直接训练Keras模型。通过这些工具,我们希望让AI的训练和整个使用过程更加的简洁。

关于SQLFlow和ElasticDL想了解更多可以可以查看他们的开源主页sqlflow.org 和 elasticdl.org

在开放性的架构下,事实上也不需要做引擎的改变,一般的模式是,当有一个新的引擎或工具可以直接拿过来使用,使用完了觉得需要优化,就在上面迭代提升。

开放计算架构下的金融级图计算

在金融领域里,金融场景大量依赖于图数据,我们需要强大的图计算能力,那么开放计算架构如何支持图计算呢?

上图是蚂蚁整个图计算发展的历程,四年以前我们从做图数据产品开始,到做离线全图的迭代计算引擎,然后做流图融合的引擎,然后是高速的图缓存,以及到现在把图相关的所有东西聚合起来,做成一站式的图平台。

首先第一个是金融级分布式图数据库GeaBase,解决的问题是,当你有海量的图数据,数据之间有关系的时候,提供强一致、高容量的存储。它和现有的一些图数据库最大的区别是,很多现有的图数据库都是把所有数据收起来做一个计算,这是最简单的做法,但会导致性能瓶颈,我们做的是把计算下发到worker以实现分布式的高性能。同时GeaBase可以根据用户的业务需求去选择需要什么样的一致性。

然后是大规模全图计算,采用了自适应的分区策略来降低资源门槛,因为很多图计算里面都是需要把全图加载到内存里面,然后进行迭代,这种情况一些超大图对内存的需求量非常高,所以我们做了一些优化希望降低资源的使用率。同时我们也能够更灵活的支持更多的图算法,以及能够做非常大规模高效图关系的挖掘,这个也已经在内部的风控场景落地。

然后还有在线流图融合,蚂蚁研发了业界首个实时多模融合计算框架。起因是我们发现,在业务中有很多时候有数据进来,同时要进行很多的图计算,计算完结果以后再输出,这在业界也是比较前沿的探索课题,我们做到了在海量大图上同时能够做很多层的计算。

基于对图计算的强烈需求,我们做了一个高性能的图缓存,里面的关键技术是基于无冲突的Hash函数,以及对于图数据结构的压缩。大家可以看下图中的效果,我们最高可以压缩到原始数据的五分之一,性能为业界优秀同类产品的2-5倍。

当有了这么多系统后,我们遇到的问题是,在一个场景下需要针对多个引擎做研发,所以我们开发了一站式平台AntGraph,为从开发调试到生产上线整个流程提供便利。我们把所有的访问统一到一个Graph SQL下面,关于这个我们也在进行一些额外的探索,因为到底SQL是不是最适合于Graph语言是有争议的,但我们可以用SQL部分描述性的功能再加上一些扩展,可以完成我们想要的功能。

经过前面针对图计算能力的研发后,我们拥有多个图计算引擎,同时为了优化客户体验,在上层也用SQL语言进行统一。这样我们的开放计算架构就拥有了强大的图计算能力。

开放计算架构下的融合计算

经过前面的研发,开放计算架构里有了大量的计算引擎,虽然在上层进行了统一,但这种情况往往不是最优的选择。当我们对已有的计算模式已经有把握,了解的比较清楚的时候,有没有可能对它们进行更多的优化?很多情况下用户需要的是要多种模式融合起来的计算,有时候需要流加上图,有时候需要流加机器学习加其他的东西,我们给出的答案就是融合计算引擎。

融合计算在底层基于Ray,Ray是蚂蚁金服联合 UC Berkeley 大学推进的新一代计算引擎,融合计算通过一套引擎解决复杂场景问题,通过动态计算及状态共享提高效率,实现研发、运行时、容灾一体化。

融合计算已经在蚂蚁若干场景中落地,包括:

动态图推导,流+图计算,性能上可以1秒内完成6层迭代查询,用于实时反套现、欺诈识别;

金融在线决策,流+分布式查询+在线服务,性能上数据生产到分布式查询一秒内,用于金融网络监控、机构渠道路由等;

在线机器学习,流+分布式机器学习,性能上实现秒级数据样本到模型更新,用于智能营销、实时推荐、流控等。

融合计算并不会取代其它的引擎,而是作为补充,用于部分合适的场景。通过上面的分享可以看到,这套架构可以容纳各种不同种类和作用的计算引擎,这也是开放二字的意义,如果未来有一个新的引擎,或者业务对数据有新的需求,完全可以插入自己的引擎直接使用。

最后总结一下蚂蚁金服对数据智能未来的整体愿景,我们希望未来的存储是可以打通的,所有的引擎是可以插拔、融合的,上层希望有标准的数据访问模式,所有的这一套组合在一起,我们把它叫做Big Data Base。我们认为,大数据经过过去十多年的发展,一定会进化到下一个阶段,对数据的增删改查会像数据库一样简单。

另外一个层面,Big Data Base还意味着可以在一个体系中很方便的使用包含机器学习、图计算以及未来各种各样的计算引擎。这套开放计算架构中的很多组件我们已经开源,这个大的体系我们还在研发过程中,未来会和大家分享更多的细节,希望大家能够一起参与进来,把金融的数据智能领域推到下一个阶段。

举报 0 收藏 0 打赏 0评论 0
 
 
更多>同类资讯
全站最新
热门内容
网站首页  |  关于我们  |  联系方式  |  版权声明  |  网站留言  |  RSS订阅  |  违规举报  |  开放转载  |  滚动资讯  |  English Version
关闭
ITBear微信账号

微信扫一扫
加微信拉群
电动汽车群
科技数码群