2016美国QCon看法:在Beam上,我为什么说Google有统一流式计算的野心-阿里云开发者社区

开发者社区> 阿里云数据库> 正文

2016美国QCon看法:在Beam上,我为什么说Google有统一流式计算的野心

简介: Google在开源社区和云计算上是有很深的痛感的,这种痛感也在促使Google做更多的转变,比如拥抱社区推出更多开源产品,在云计算产品形态上也屈身向3A靠拢,本文中介绍的流式计算产品Beam就是拥抱社区的一个动作,希望能成为一个杰作。

编者按:流式计算(Stream Processing)在经历了若干年的发展之后,已经有了比较完整的生态,如开源的Storm, Flink, Spark等,未开源的如Google的DataFlow,几乎每个巨头都有自己的流式计算系统。生态虽繁荣但分散,各个平台之间也是互不兼容的,一个平台上写的程序很难移植到另外一个平台,这些领域难题再加上Google大一统流式计算的野心催生了Apache孵化器的新项目Beam。

 

         Google是最早实践大数据的公司,目前大数据繁荣的生态很大一部分都要归功于Google最早的几篇论文,这几篇论文早就了以Hadoop为开端的整个开源大数据生态,但是很可惜的是Google内部的这些系统是无法开源的,在开源生态和云计算兴起之后,Google也是受够了闭源的痛苦,据说为了给用户提供HBase服务,Google还为BigTable写了兼容HBase的API,在Google看来这就是一种羞辱,痛定思痛,Google开始走开源之路,将自己的标准推广给社区,这就是Apache Beam项目诞生的整个大背景。整个Beam项目的演进历史为:

147f601b32c9ef2c92613fa776962fc24c269ec1

         撇开这些八卦,Beam的整个设计理念和架构还是不错的,Beam是一个SDK,也是一个构架于各个底层平台Runner之上的Adapter,Beam对流式计算场景中的所有问题重新做了一次归纳,然后针对这些问题提出了几种不同的解决model,然后再把这些model通过一种统一的语言给实现出来,最终这些Beam程序可以run在任何一个计算平台上(只要平台/Runner实现了对Beam的支持)。通过一个Beam的参与方视图也能看出一个大概的架构:

31520e2283085325c209c31414cce5c5bbfc869b

在图中,终端用户用Beam来实现自己流式计算功能,使用的终端语言可能是Python、Java等,每个语言有一个对应的SDK,用户写出的程序会跑在各个平台/Runner上,每个Runner上都实现了从Beam Pipeline到平台功能的映射。

         在任何一个设计开始之前,都先要确定问题,Beam也不例外,在设计者看来在流式计算场景中数据有三个特点,一:数据是非常大的,而且一直在不停产生,理论上是无穷大;二:这些数据的延迟是不可预期的也是不可控的,而且这些乱序是一种天然的行为,无法避免;三:这些数据的用途有可能是记录抽取转换、有可能是用来根据时间窗口做聚合,而且聚合可能是基于当前处理时间processing time,也有可能是根据事件发生时间event time来聚合。Processing time和event time之间是有lag/skew的,如图:

b87b077195973ccd31b96a9a0f577a6105efb5c0 

其中虚线是最理想的,表示处理时间和事件时间是相同的,红线是实际上的线,也叫水印线watermark,watermark一般是通过启发式算法算出来的。

         接下来从high level的问题中抽象出四个具体的问题:

         A:What are you computing,处理的数据是哪种类型,数据转换、聚合或者是两者都有,如图:

a92b54ca0e8332aaaef2ab74a93f7df5be5fbc87        

B:Where in event time,何时发生,其实是用哪种窗口来框住数据并处理,有固定窗口、滑动窗口、会话这三种模式:

92593da5da3d88bbc7df57024d2f674bea52070c        

C:When in processing time,何时被处理,如上Watermark图,在这里引入了一个Trigger机制,Trigger决定何时将计算结果发射出去,发射太早会丢失一部分数据,丧失精确性,发射太晚会导致延迟变长,而且会囤积大量数据,何时Trigger是由Watermark来决定的 

03ab8942f24e5fdfa54d06767b5e06a42559c747 

0d8fca0aa42f05abfeb3c8e4c31ddfe574587d30

        D:How do refinements relate,如何优化

 5cc45f382e74cf4aadac2c032497fb15d3bbf814

         通过这种model能够保证准确性;功能也比较强大,还能识别出用户的burst行为;各种策略之间的可组合性也非常好,如:

0a5034ce2a9e0d1306851b2cdaef9e16292ebe1f

由于策略很多,所以灵活性也很好,如:

67a5b9755ab4774429ecfb30d1cc383e1f80db13

模块化和抽象也做的很好,如: 

055f83ac8d96e6eef8d36015e1234e0af1e83f1c

 

         总结:Beam虽然还在孵化之中,但是以Google对大数据的理解,绝对是一个强力的推手,而且Beam对自己的定位是粘合剂,不是一个挑战者,所以该项目看起来还是比较乐观。不过Beam背后隐藏的Google的野心也是非常大的,Beam看起来像个粘合剂,但是是一个事实上的标准,是对流式计算开源生态的一次大一统,相信未来Google会在大数据领域继续推出其他开源产品,对社区生态和云计算的理解也会越来越深。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接