彻底搞定Flink系列-Flink发展历史与背景以及架构哲学

努力奋斗做好Java
916 阅读6分钟

大家好，我是你们的建哥，一个始终站在技术一线的Leader。又到了一天最惬意的时光，泡上一杯绿茶，跟着我一起回顾平时无法系统梳理的知识。

在彻底搞定Flink系列-快速理解Flink架构与HelloWorld中介绍了Flink的入门。这篇文章本来是想继续说Flink，但是想想还是止住了，中间插播一个问题：

Flink诞生的背景是什么？发展历史与背景是什么？

Flink诞生的背景

MapReduce的缺陷

我们知道，谷歌在2003到2006年间发表了三篇论文，《MapReduce: Simplified Data Processing on Large Clusters》，《Bigtable: A Distributed Storage System for Structured Data》和《The Google File System》介绍了Google如何对大规模数据进行存储和分析。这三篇论文开启了工业界的大数据时代，被称为Google的三驾马车。

2004年，Doug Cutting和Mike Cafarella就初步实现了HDFS和MapReduce，这是Hadoop的两大核心架构。Map Reduce就成为了当时大数据处理的标准。但是MapReduce却带有天生的缺陷：

  • 难以实时计算（MapReduce处理的是存储在本地磁盘上的离线数据）

  • 不能流式计算（MapReduce设计处理的数据源是静态的）

  • 难以DAG计算（有向无环图计算，由于多个任务存在依赖关系，后一个应用的输入是前一个应用的输出。解决这一问题的方式有Apache的Tez计算框架，它是基于hadoop Yarn之上的DAG计算框架，它将MapReduce任务分解为多个子任务同时可以把多个Map/ Reduce任务合并成一个大的DAG任务，这样当前一个任务完成之后，直接将结果输出给下一个任务，不用将结果写到磁盘之上，减少了Map/Reduce之间的文件存储。同时合理的组合其子过程，减少了任务的运行时间。）

因此，基于要解决上面问题的想法，Flink和Spark都诞生了。只不过走了两条不一样的路（关于Spark这本书可以说是绝对入门的书籍：大数据处理框架Apache Spark设计与实现）：

Spark走的是优化MapReduce的路径，而Flink直接是采用另外一个计算方式：

我把数据分批加载到内存，然后通过流一样的计算过程直接计算，什么shuffle过程直接不存在。但是要解决一个问题：要尽量减少数据在机器之间传输。因此，Flink的初衷其实是解决上面的问题的，当时并没有想到流处理。

Flink的前身是一个叫做“Stratosphere”的项目。它起源于德国柏林工业大学(Technische Universität Berlin)Volker Markl教授于2008年提出的构想。由于数据库是Volker Markl教授的主要研究方向之一，因此创建该项目的初衷是构建一个以数据库概念为基础、以大规模并行处理(massively parallel processing, MPP)架构为支撑、以MapReduce计算模型为逻辑框架的分布式数据计算引擎。

这个项目从09年就是开始搞，到2014年才基本成熟。这里面全是一群博士生搞的（因此代码看不懂不奇怪）。

github地址：github.com/stratospher…

文档：markus-h.github.io/stratospher…

其产生的论文：stratosphere.eu/project/pub… 从这个论文可以看到，Flink的基本雏形都有了。

值得注意的是，同样是2009年，Spark诞生于伯克利大学AMPLab，同样属于伯克利大学的研究性项目。他们在很多地方都是相似的。只不过在对待数据的思想上，spark和flink走了不一样的路：spark把所有数据都当做批，flink把所有数据当做流来处理。

注意，在这个时候，Flink对于批处理是落后于Spark的！人们对于Flink当时并不看好，直到Google流处理论文的发表。

Flink关于流计算是如何实现的？

谷歌在VLDB期刊上2015年发表的论文:

The dataflow model: a practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing。

这篇论文标志着流式计算的到来。flink团队一看，简直不就是为我准备的吗？再结合上2013年就发表的论文：MillWheel: Fault-Tolerant Stream Processing at Internet Scale

flink上马流计算！并在0.7版本发布此功能

基于上面两篇论文，增加了Flink的流式处理进行。同年，flink团队发表论文，应对分布式有状态处理的快照机制：奠定了checkpoint机制：Lightweight Asynchronous Snapshots for Distributed Dataflows

值得注意的是，里面采用的分布式快照算法：Chandy-Lamport算法在1985年就发表了（可以关注下Lamport这个大牛，很多现在用到的分布式理论是人家30多年前就发表的，包括Paxos算法。 个人网页：lamport.azurewebsites.net/

Chandy-Lamport算法：zhuanlan.zhihu.com/p/53482103

2015年，flink又发表了一篇论文

Apache Flink: Stream and Batch Processing in a Single Engine Apache Flink。

说明了流批一体的设计，其借鉴的参考论文基本上就是flink用到的知识。所以说为什么是流批一体？因为flink一开始就是应对批处理的。flink这种并发计算模型后面刚好又可以用到流处理而已。

被阿里收购

被阿里收购增量快照没有看到论文。

如果要真的搞懂flink原理，上面的论文是要读一遍的，并且要把Spark搞懂，这样才能更加看出二者设计的差异性。当然，如果要只是搞清楚工程级别的，了解即可（或者看到这个地方再去看论文）。毕竟我们做的还是偏工程的。如果不想看论文（确实上手门槛比较高），可以看这本书：《Streaming Systems》

Flink发展历程

发布日期

Apache孵化器发布日期

Pre-Apache Stratosphere 发布日期

  • 01/2014: Stratosphere 0.4（0.3版本被跳过）
  • 08/2012: Stratosphere 0.2
  • 05/2011: Stratosphere 0.1（08/2011:0.1.1）

创始人Kostas-Tzoumas的researchgate www.researchgate.net/profile/Kos… 可以看到其相关的论文。

avatar
文章
阅读
粉丝