在Beam上，我为什么说Google有统一流式计算的野心

编者按：流式计算（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项目的演进历史为：

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

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

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

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

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

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

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

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

D：How do refinements relate，如何优化

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

由于策略很多，所以灵活性也很好，如：

模块化和抽象也做的很好，如：

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

沟通和互动以及更多干货，欢迎关注新浪微博：@阿里云云栖社区