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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

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

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

Apache Beam—透视Google统一流式计算的野心-LMLPHP

D:How do refinements relate,如何优化

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

Apache Beam—透视Google统一流式计算的野心-LMLPHP

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

05-02 07:46