抢尽 Spark 风头的 Flink 强在哪里？

点击蓝色“有关SQL”关注我哟

加个“星标”，天天与6000人一起快乐成长

01,  Flink 历史

Flink 也是出自 Apache Software Foundation, 师出名门。加入豪门 Apache 的技术都可以得到长足的发展，这观点在之前的文章中，已经说的太多了，如果你有能打的技术，不放开源给 ASF，有一帮子狂热分子能和你造福人类，维护世界和平。

2010 年，Flink 脱胎于德国研究项目 Stratosphere: Information Management on the Cloud。由 German Research Foundation(DFG) 建立的这个 Stratosphere 项目，生成了一支分支便是 Flink, 2014年3月交给 Apache 孵化，同年12月变成了 Apache 顶级项目。

还记得 Spark 是什么时候出世的吗， 2009 年。不知道 Spark 历史的，可以看我之前的这篇文章：为什么 Spark 在数据科学界这么红？

对手的出现不过晚了 1 年。这一年足够已经很多事情。至今 Flink 虽然很强，但依旧不能替代 Spark. 尤其是加入 ASF 的时间，尤为重要。

Flink 的版本历史

Spark 是 2009 年创立的，2012年成为 Apache 顶级项目

Spark 的版本历史

两者有着相似的发展步伐，平均每年3-4次大的更新。但开源的历史告诉我们，等等总归有更好的产品出现，作为使用者，产品经过2-3次迭代后就可以入手使用了，而产品开发者，则是越早打入市场越有效，Google痛失 Hadoop 的市场，就是最好的例子。

历史，确实是块明镜

02，图说流式计算

业内人士都知道，Spark 与 Flink 之战，本质是在 Data Streaming （数据流）上的战争。那么流式计算的流到底是个怎么回事呢？

这个问题可以很抽象，也可以很形象。只要你走出门，找到小河，盯着看上一会儿就懂了。在大城市的你可能找条有水躺着的河，并不容易。那么请你打开自家的水龙头，盯着看上一会儿，确保你旁边没人（万一被人骂神经病别怪我哦）。

什么， 怕废水？好吧，从环保角度，请你看我的图：

拧开水龙头，当水源源不断流下来时，我们能感受到的是流。它不随我们的意志而停留，只是配合着地球引力，直往下来。

当我们尝试用手去接时，能攥在手里的，只能是一瓢。

想了个聪明的办法，用水杯来接。接完一杯，倒进洗脸盆，再接一杯，给花儿草儿润润嗓儿；只要你有足够的杯子，一杯接着一杯，水可以一点都不浪费的利用起来。

看到这里，流式概念相信不是问题了。它最大的特点就是没有明确的结束时间，只要水阀开着，水就一直流出来。就像微博一样，只要服务器不挂，用户始终在不停地输出文字，图片。

那么问题来了，我开了水龙头是要用来洗头的，浇浇花花草草的，顺便可能还洗个车。这么一杯杯的接，是不是很麻烦？老婆大人都在那里嗷嗷叫洗发水迷眼了，你还一杯杯的送水过去，是不是不及时，要不要被骂，花呗额度开好了没？

怎么办？同个花洒直接挂在脸盆上面，让水直通，边洗边冲，不就是个好方法么！

同理啊，浇花洗车都一样

03，Flink 解决的问题

上面三种对水流的处理场景，洗头对水的及时性渴望最大，谁都不愿意那黏糊糊的玩意儿粘头上那么久；浇花洗车都可以攒足一桶水，慢慢用。

回到 Spark 与 Flink 的比较中来，这个时候优劣就很明显了。

Spark 对流的处理，就像是一杯杯接水，先预存一段时间，然后一个个小批次的拿来用；而 Flink 则是像花洒洗头一样，即来即用，一点延迟都没有。

Spark 的核心是 RDD, 将一段时间内预存的数据集合起来，进行处理；Flink 的核心是 Data Stream, 当数据流动的时候，总有线程去捞起来，再处理。这里的问题有：

1）如何避免被两个不同的线程捞起来处理？是不是需要维护一个 queue,有个先来后到？

2）数据量过大如何处理

3）多个下游，如何保证下游系统能得到最新数据？

4）来不及处理的数据怎么办？存还是不存？

留下这些思考，对每个想要进入流式计算领域的人都有个启发

End

往期精彩：

本号精华合集（二）

精通 SQL 编程，你却只用来拉数据

偏见的背后，是你想象不到的无知