大数据那些事(35):Flink和Spark Streaming

Flink的出现是2014年大数据发展的一个重要的事件。 Data Artisans这家位于柏林的大数据创业公司目前是Flink背后的公司。就像DataBricks是Spark的主要开发者一般。我们都知道柏林理工早在2008年就开始做大数据开发，教授的上一代数据引擎并不成功。据他们自己说是受到了MillWheel的影响，决定推倒重来，做一个牛逼的大数据系统。这个系统以Streaming为核心，提供各种各样高级的Window的定义以及low latency的执行框架。然后这样一来Batch会成为Streaming的一个特例。而特定的optimization只在Batch的时候去执行。

对于Flink来说很多人会推荐：Apache Flink： Stream and Batch Processing in a Single Engine. 我个人的体会是这篇论文对系统的介绍还是相对比较直白的，比读文档要好。但是给我个人的感觉其实Batch和Stream并不是完美的复用了代码。所以我其实并没有说服我自己Batch和Stream确实是用了同一个引擎。

但是如果想深入了解Flink的核心思想的话，我还是推荐Lightweight Asynchronous Snapshots for Distributed Dataflows。流计算本来就不是我的长项，这篇文章让我还是有些受益的。

我觉得很有意思的事情是Flink的火起来也是很奇怪。如果去湾区看看的话，Flink可能并没有那么的流行。三大Hadoop批发商都有给Spark打工的但是都还没有给Flink打工的。Google的BEAM可能是Flink火起来很重要的一个原因。因为这个项目公开推崇Flink和Flink的实现。不过从某种程度上也对。在这个项目开源的时候，Spark并不能支持这么多种复杂的Window。另外一个发现是在欧洲和亚洲Flink用的人相对多一些。

Spark Streaming的论文发表于2012年。其基本核心思想是用mini-batch来实现streaming。我有一次和Amazon的流计算平台Kenisis的大老板Roger见面的时候聊起他对业界的看法，他个人的看法是Mini-batch is batch， not streaming。他个人的观点是Spark Streaming并不构成威胁，Flink不好说。但是这个对话是去年上半年。

Spark team在这段时间里面对Streaming投入了大量的工作，目前按照我知道的说法是Spark Streaming已经在很多的benchmark上比Flink要快了。所以技术的进步是很快的。我无法用2012年发表的论文的状态去的Spark Streaming和2015年的Flink做一个对比，更不容易说到了2017年以后到底哪个比哪个更好了。

Data Artisans完成了A轮投资，领头的是Intel。这个组合其实是挺有意思的。Intel早年在UCBerkeley还没有成里DataBricks的时候就有Spark方面的合作了。后来的故事上海和美国本地的政治斗争导致了上海星环公司的诞生。星环应该也是国内做Spark相关开发很成功的企业。现在在Flink里面看到Intel领投，让我不得不多想一下Intel到底是钱多的没处花还是有其他想法了。

很多人都问我Flink和Spark到底哪个能够活下去活的更好。其实毫无疑问的一点Spark已经是一个足够成熟的体系。很多公司都在用，像IBM更是ALL IN了。当然此IBM非彼IBM，今天的IBM在云计算和大数据市场的表现，若干次改旗易帜，和一个不及格的学生没什么区别。所以IBM ALL IN Spark也不能说明什么。但是不管怎么样的来说，我觉得Spark作为一个产品来说已经有了很稳固的地位了。

Flink虽然这两年名气起来了，但是整体来说和Spark的差距还是很明显的， Table API估计比DataFrame差上一两年成熟度也是大家公认的。底层的系统也不是很稳定。当然作为一个重新搭起来的系统，底层对streaming的支持，尤其在一些高精尖的功能的支持上，会比Spark要支持来得容易很多。而且未来我想很长一段时间里Google应该还是会努力去支持Flink的。

我必须说这个市场很大，最后也许就不是一个系统通吃的局面，更可能是每个人都有饭吃，大家都还吃得不错。但是Flink如果想取得Spark今天的成就，其产品成熟度还是任重道远了。