计算引擎的那些事儿

　　导语:又到了一年一度应届生实习找工作的时候,有些同学在学校期间对大数据技术感兴趣,但现在也不免心中忐忑:火了十多年的大数据技术还有前途吗?现在进入还有发展机会吗?

　　对于这个问题,我找到蚂蚁资深技术专家、新计算引擎架构师周家英一通追根究底,试图拨开浮在大数据表面的迷雾,弄清这个技术领域的来龙去脉和发展前景。

　　不过需要说明的是,大数据技术分为多个方面,本文只涉及其中的核心底层技术之一,也就是计算引擎。正是这个引擎的轰鸣,载着我们走过精彩纷呈的移动互联网,一头撞入充满未知的AI时代。

　　从MapReduce到Flink,计算引擎都经历了哪些进化?

　　何谓计算引擎,一言以蔽之,就是专门处理数据的程序,在大数据之前,人们用数据库来处理数据,人们常说的SQL,它是一种DSL,它的背后正是数据库的计算引擎,但是数据库的计算和存储通常被集成在一起,统称为数据库引擎。

　　互联网时代到来之后,由于需要计算的数据量太大,计算引擎和存储引擎分开各自演进,这一分开,让两者获得解放,从而有了无数可能,也就开启了狂飙突进的大数据时代。

　　从谷歌论文的大数据三驾马车到现在,计算引擎经历了多重演进。

　　2004年前后,谷歌发布了三篇重要的论文,也就是大数据的三驾马车:分布式文件系统GFS、计算引擎MapReduce、分布式数据库BigTable。

　　2006年,Lucene项目的创始人 Doug Cutting依据论文原理,开发出类似GFS和MapReduce的功能框架,后来被命名为Hadoop。Hadoop套件中的MapReduce实现了传统数据库计算能力之外的种种操作,让搭建一个大数据平台成为可能,它的种种设计理念,一直影响着后来者。

　　(Hadoop之父Doug Cutting)

　　Lucene是第一个提供全文搜索功能的开源项目,在很长时间里都是开发者的首选。当时,Cutting和同为程序员出身的Mike Cafarella决定开发一款可以代替当时的主流搜索产品的开源搜索引擎,这个项目被命名为Nutch。Doug Cutting 希望以开源架构开发出一套搜索技术,类似于现在的谷歌搜索或是微软的必应(Bing)。刚好谷歌的论文发布了,Doug Cutting 利用 Google 公开的技术扩充他已经开发出来的 Lucene 搜索技术,进而打造出了 Hadoop。

　　Hadoop后来演变成了一个庞大的生态,Facebook、Yahoo以及高校和社区都为它贡献了大量的组件,让Hadoop在一段时间内成为大数据平台的事实标准。

　　2012年,UC 伯克利AMP 实验室的一位博士,在使用 MapReduce 进行大数据实验计算时,发现性能非常差,不能满足其计算需求。为了改进这种效率低下的工作方式,他们开发出了一个性能优越的替代产品,叫做 Spark 。由于Spark 性能卓著,一经推出,就受到了业界的认可,开始逐步替代 MapReduce。

　　UC伯克利AMPLab是大数据领域的顶级实验室,甚至可以说没有之一,这个实验室贡献了大数据以及Hadoop生态里非常多的主流组件,包括Spark、Mesos、Alluxio (前身为Tachyon)等。在这些项目的背后,是UC伯克利计算机教授Ion Stoica,Ion是操作系统和分布式计算领域绝对的大佬级人物,后面你可以看到他几乎是扛着这个领域在前进。

　　(Ion Stoica教授)

　　MapReduce和Spark都是批处理模式,也就是分批针对某个时间段的数据进行计算。这种计算由于数据量大,需要花费几十分钟甚至更长。同时这种计算的数据是非在线实时获取的数据,也就是历史积累的数据,也就是离线数据,这种计算又被称为“离线计算”。

　　那么,有没有可能对实时数据进行计算呢?可以。

　　2011年,Twitter开源了它的实时数据计算系统Storm,它将计算数据的间隔缩短到足够小,收到一部分数据就计算一部分,也就是流式计算了。Storm填补了大数据实时计算的缺失,并且便于使用,一经推出就风靡业界。

　　不过,逐渐的,人们对Storm的性能也开始产生不满,它要占用太多的机器资源了!为了更好的性能,人们又开始鼓捣新玩意儿。

　　这个新玩意儿就是Flink,它原本是由3所地处柏林的大学和欧洲的一些大学共同进行的研究项目,2014年加入Apache基金会引起了业界注意,最终因为其新颖的设计和高性能受到越来越多的公司青睐。

　　在Spark的世界观中,一切都是由批次组成的,离线数据是一个大批次,而实时数据是由一个一个无限的小批次组成的。

　　而在Flink的世界观中,一切都是由流组成的,离线数据是有界限的流,实时数据是一个没有界限的流。

　　正因为如此,Flink不仅仅能够做流式计算,它还能进行批处理,也就是流批一体。

　　但我们也不能说Spark的世界观就错了,它们只是角度不一样,事实上后来Spark也通过“微批处理”为原理的Spark Streaming支持了流批一体。

　　计算引擎发展到这个程度,在数据处理这个维度上,终于可以宣称暂时告一段落了。

　　但这是否意味着计算引擎领域再无新鲜事呢?

　　当然不是,下面就轮到我们的重头戏——Ray出场了。

　　计算引擎新星Ray，回归分布式计算本质

　　上一波关于批和流的领域变革,驱动力来源于对海量数据的分析和挖掘的需求,而新的驱动力,来自人工智能时代的呼唤。

　　2017年,由AMPLab升级而来的UC伯克利RISELab实验室里,Ion Stoica等人在研究强化机器学习的过程中,发现现有的计算引擎不能很好的满足机器学习的需求,这一次,他们选择回归分布式计算的本原。

　　这里我要提一下RISELab实验室的另一位大佬Michael I.Jordan,他是机器学习领域的杰出科学家,美国三院院士,培养出AI领域很多大牛,包括吴恩达、图灵奖得主 Yoshua Bengio等都曾是他的学生。

　　(Michael I.Jordan教授)

　　正是由于Michael和Ion将机器学习和分布式计算进行的碰撞,才诞生了Ray。

　　分布式计算是相对于集中式计算来说的,是利用各自独立的计算设备来共同完成一个计算任务。现代编程语言是以单机应用程序为目标设计的,要开发分布式计算程序,需要考虑很多额外的东西,比如一致性、数据完整、通信、容灾、任务调度等。

　　另一方面,机器学习的训练和调参过程需要计算海量数据并且进行反复学习,他们对算力的需求远远超过了摩尔定律的增长,更何况,如今摩尔定律已经快失效了。

　　Ion Stoica在他的博客写道:

　　“根据OpenAI的一篇流行博客,从2012年起,满足最新机器学习的计算量就以几乎每3.4月翻一倍的速度增长,这等于每18个月增长40倍,也就是摩尔定律的20倍!因此,哪怕摩尔定律没有失效,我们也迟早会面对算力增长难以满足机器学习需求的情况。”

　　——《The Future of Computing is Distributed》,Ion Stoica

　　而这导致了机器学习训练过程所花的时间越来越长。

　　从2014年到2019年,自然语言识别的主流算法的训练过程所消耗的时间增长了5000倍;从2015到2018年,图像识别的ResNet模型的训练时间增长超过11000倍。

　　更别提,在强化学习这一类别中,因为它的算法通常包含很多不同类型的仿真器(simulation),算法复杂、计算范式多样,因此算法难以在高性能的专用平台上运行,比如GPU,而只能在进行通用计算的CPU上运行。因为GPU上的指令集较为简单,只能运行给定的几种计算模式。

　　因此提升机器学习计算效率、打造一个通用的分布式计算引擎势在必行,这也正是Ray的使命。

　　为了简化分布式编程,Ray提供了一套简单、通用的分布式编程API,屏蔽了分布式系统中的这些常见的难题,让开发者能够使用像开发单机程序一样简单的方式,开发分布式系统。

　　Ray系统中有三个基础概念Task、Object、Actor,分别对应分布式任务、对象和服务。而常用的面向过程的编程语言中,也刚好有三个基本概念,函数、变量和类。在Ray系统中,可以通过简单的改动,实现它们之间的转换。

　　这里我们可先建立一个概念:

　　单机程序 + Ray => 分布式计算程序

　　看到这里,很多人可能还是不能理解Ray的厉害之处,快速开发分布式计算应用,又能怎么样呢,跟我们又有什么关系呢?

　　别着急,下面为你来揭晓。

　　有了Ray,我们可以做很多好玩的事情,其中的一个,就是把两个或多个不同的计算模态或者模块整合在一块,产生更好的计算能力。这就是蚂蚁基于Ray所打造的融合计算。

　　说起这个,我们先来看看为什么要这么做。

　　以在金融行业非常重要的安全风控为例。目前国内移动支付已经非常普及,体验都差不多,我们买完东西点击支付按钮,很快就支付成功了,看上去很简单,几乎感觉不到延迟。但就在这短短的数百甚至数十毫秒之内,支付系统就需要评判这笔支付是否存在欺诈、账号被盗、套现、赌博等违法违规行为,更要命的是,判断这些需要使用不同的计算方式,通常属于不同的系统,一笔支付需要在这些系统里面流转,通关之后才能支付成功。

　　因此,一个实际的问题摆在我们面前,我们需要将这些不同的计算方式以最优的方式重新组合,让这些系统处理每一笔支付的时间越短越好,也就是性能的极致需求。

　　Ray说,这个我在行!于是一拍即合。

　　在蚂蚁,他们已经利用Ray打造了这样的几种融合模式,并已经在生产环境中取得了不错的效果。

　　流计算 + 图计算 + Ray => 流图融合

　　流图融合又叫做在线图计算,它被用在金融风控的实时反套现的场景,也是上面提到的安全风控中的一部分。另外它还被用在蚂蚁森林场景,蚂蚁森林中有多种形式的好友互动,如支付宝好友之间可以互相收取能量,以及好友、亲人之间可以一起合种一棵树。这里面其实就是关系,在蚂蚁森林中有人与人的关系,以及人与树的关系等。它需要实时的去处理和查询这些关系,刚好对应到流计算和图计算的应用场景。

　　流计算 + 机器学习 + Ray => 在线学习

　　传统的在线机器学习系统是一系列子系统组成的任务管道,原始的实时数据需要流经过滤、采样、特征工程、训练和部署等系统,才能发挥作用。这就给我们带来了数据一致性、系统稳定性、多平台等挑战。

　　蚂蚁基于Ray开发出端到端的在线机器学习架构,这一端给出数据,那一端直接出结果,中间的数据处理、模型训练和部署等等都是紧密集成在一起,并且这一切还是实时的。

　　在蚂蚁,他们在实践中摸索出了一套“底盘+插件式”的架构。底盘是Ray分布式计算系统,插件则是这些不同的计算范式子系统,需要哪些就用哪些。

　　当然,这套架构还远未完善,所覆盖的场景还不足够多,我们可以想象,如果插件足够丰富以后,我们可以任意组合不同的插件去打造一个性能最优化的系统,同时还易于维护升级等,无论多么变态的需求都能轻松搞定,给后端同学留下幸福生活。

　　在未来,一切计算都应该是分布式的,而Ray将是我们通向未来的有力帮手。

　　计算引擎领域，我们的机会与挑战

　　前面说了那么多,跟同学们又有什么关系呢?这里我想借阿里和蚂蚁在计算引擎上的研发投入,来说说这个问题。

　　我国网民数量庞大,国内互联网公司对大数据也一直有很强烈的的需求。

　　在谷歌发布了大数据三篇论文之后,国内快速跟进。

　　在子柳的《淘宝技术这十年》中记载了当时的情况,由于淘宝的图片存储服务器不堪重负,谷歌公布了GFS论文之后,2007年淘宝开发了自己的分布式文件系统TFS。

　　历史总是惊人的巧合,在我们准备研发文件存储系统的时候,Google走在了前面,2007年,他们公布了GFS(Google File System)的设计论文,这给我们带来了很多借鉴的思路。随后我们开发出了适合淘宝使用的图片存储系统(TaoBao File System,TFS)。3年之后,我们发现历史的巧合比我们想象的还神奇,几乎跟我们同时,中国的另外一家互联网公司也开发了他们的文件存储系统,甚至取的名字都一样——TFS,太神奇了!(猜猜是哪家)

　　——《淘宝技术这十年》,子柳

　　Hadoop发布后引起了国内的热捧,从2008年起,阿里也借鉴并开发了自己的大数据处理系统“云梯”,它分为两个阶段,云梯1以Hadoop为核心,云梯2则是自研,并且是阿里云操作系统“飞天”的核心功能模块。

　　到了Storm出现,开始引领实时数据处理的时候,阿里开发了JStorm,也就是Java版的Storm,当然里面也包含不少阿里根据自身情况进行的创新。后来阿里将JStorm贡献回了开源社区。

　　Flink出现后,也很快引起了国内公司的关注,2017年,阿里以9000万欧元收购了Flink背后的公司Data Artisans,到现在阿里已经是Flink社区最大的贡献者之一。

　　同样是2017年,蚂蚁与上面提到的Michael I.Jordan教授展开合作,刚好参与到Ray早期的建设当中,与Ray团队互补,从产业界的角度为Ray填补缺失的功能,并为其提供实践案例。从那以后到现在,蚂蚁一直是Ray社区排名第二的贡献者,为Ray的发展壮大立下汗马功劳。

　　把上述经历和计算引擎的发展历史结合起来,我们可以发现一些有意思的事情:

　　一、大数据领域的创新几乎都起源于国外。

　　二、随着计算引擎的发展,国内逐渐从追赶跟随转变到并驾齐驱,到了Flink和Ray的时代,国内已经是计算引擎领域创新的主力之一。

　　国内计算引擎领域的发展,正是国内大数据技术的一个缩影,也是其它千千万万个技术行业发展的缩影。

　　从这个角度来说,正因为国内大数据的应用天地广阔,因此对应技术领域的研发也正如火如荼。我们可以对国内计算引擎的发展有信心,这将是一个持续发展并不断突破的领域。

　　从另一角度看,我们还可以观察到一个事实:

　　大数据和实时数据处理这样从无到有的创新,都来自企业界;而像Flink、Ray这样的颠覆式创新,都来自于高校的实验室。

　　这可能是因为,从实际出发的强需求可以倒逼创新,但一旦有了解决方案,企业可以通过堆机器来解决问题时,他们创新的动力减弱了,或者说害怕贸然采用新的想法导致失败,而学术界则更倾向用新想法来解决老问题以产出创新成果。

　　但我们不得不遗憾的表示,在计算引擎这个领域的发展过程中,国内的高校出现的身影不多,研究较为薄弱,也缺乏相应的人才储备。

　　这也导致高校难以为企业输送合格的计算引擎人才,企业只能自己培养。

　　这时候有同学就要问了:计算引擎听起来这么高级,看上去也很底层,开发起来是不是很难啊?

　　但周家英表示,“难”并不是计算引擎开发的关键字,相反,分布式计算的研发很可能是当代大数据领域中“皇冠上的明珠”

　　分布式计算的研发处于技术栈的偏底层位置,适合对于计算机基础工程更有兴趣的同学,可以不断学习计算机领域的基础知识,如操作系统,硬件优化等等,这样才能让最大限度的发挥底层硬件的性能,把计算做到极致。

　　对于社会招聘,他希望招募的是对计算引擎有一定开发经验,如搜索引擎、开源分布式引擎,或者做过SQL优化、分布式调度等工作的人才。

　　对于应届生招聘,他表示同学们只要把大学计算机相关课程学好了,同时有一定的好奇心,了解下当下主流的几个计算引擎,知道它们的应用场景及原理,如果能去读一下它们的源码,了解为什么这么设计那更是求之不得。

　　作为证明,蚂蚁新计算引擎团队里并不都是头顶锃亮的稳重大叔,反而是以90后为主的年轻人组成的团队。

　　(蚂蚁新计算引擎团队的团建之旅)

　　蚂蚁在新同学加入公司之后,会安排一位师兄对新同学进行引导,无论是工作还是生活上的问题都可以对师兄进行请教。同时对于技术新同学还会安排多轮的脱产培训,让他们了解整个公司的业务架构,以及本团队所需要的技术知识。

　　所以还等什么呢?如果你对计算引擎感兴趣,赶快投递简历,加入蚂蚁新计算引擎团队吧～

特别提醒：本网内容转载自其他媒体，目的在于传递更多信息，并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。