Flink系列论文导读（上）

Posted 2021-04-13 Flink

今年我除了在读Flink的源码之外，还读了Flink开发团队发的一些论文。本文对Flink的系列论文进行导读，由于论文数目较多（十篇开外），所以本文只包含部分论文。

本文中点评的所有论文，可点击“阅读原文”进行下载。

---

• Apache FlinkTM: Stream and Batch Processing in a Single Engine

这篇论文发于2015年，严格意义上只能算是Flink的系统介绍以及概要设计文档。先总结了一下通用的设计理念，接着按照“流计算”与“批处理”拆开了分析各自特性。很多你从官网上不太容易看出来的实情在这里都可以看到：比如内存管理只应用于批处理；比如批处理中的falut tolerance、状态怎么处理，论文里就写得比较直白，但是官网在这块说得比较含糊，有些所谓的“特点”没有加前提条件（只是在流中有还是只在批处理中有，还是都具备）。其实，Flink号称“Batch on streaming”，就其论文和实现来看，很多特性对于batch跟streaming而言，都是独立实现的，而且是“你有我无，我有你无”的场面，应该说其口号中的Batch作为streaming的special case，有些牵强，不过它加了“run”这个词，应该主要指运行时的处理方式，从这一点来看也能说得过去。

• Lightweight Asynchronous Snapshots for Distributed Dataflows 

这一篇，算是Flink的主论文了，估计很多人都读过。如果你想了解一下其falut tolerance机制，最好读一读。其快照机制没有太多原创，更多得是一种改进。因为以前的很多系统，虽然也是走类似检查点/快照的思路，但是弊端较多：要么需要将所有的数据写入日志，要么就是同步式的快照方式（快照时，系统会停下来，等待快照完成再继续执行，有点类似于JVM GC时的stop-the-world），要么就是快照产生的状态太大了....

而改进就是结合Barrier（屏障）进行异步的快照，简称ABS。所谓的异步就是计算任务照常执行，而快照在独立的线程上以“几乎”不阻塞任务的方式进行（为什么几乎要加引号呢？因为在要保证正确性的场景下，也就是exactly-once时，归属于下一个检查点的元素是要被缓存着阻塞等待直到当前检查点在某个算子上完成）。

还有一点，不知道算不算“创新点”。就是这个算法不但适用于DAG计算模型，还适用于有环的图（Flink原生支持迭代而产生的环形数据流）。在有环的图上面进行快照时，对环（也称之为“back-dege”，回边）中的元素进行日志记录。但是，遗憾的是，当前（1.1.x）流计算中的迭代并不支持这种快照方式，因为存在问题。所以这一点上来看，应该是论文发于实现之前？

• The Stratosphere platform for big data analytics

这一篇是Flink的前身——Stratosphere的介绍论文。如果你对历史感兴趣，可以读一读，但是由于当时是一个研究性的项目，且发表时间相对久远，跟当前的Flink实现已经相去甚远。但从中你不难看出浓厚的MPP以及RDBMS的影子。比如，它提供一个Meteor的DSL来表达任务，有其独立的语法，这有点类似于SQL。然后通过Meteor编写的脚本会被转化为PACT程序，接着会经过编译器等进行优化，最终在Nephele这一执行引擎中执行。现在的Flink的optimizer模块前身就是以前的compiler模块，其中的一些方法名如今还是compile。鉴于现在没有单独讲述Flink优化器对批处理程序进行优化的细节与资料，所以这篇论文中“Section 6 Optimization in Stratosphere”是唯一能找到的一些理论支持了。有兴趣可以看看，借助于典型的数据库的基于成本的优化（CBO）以及“Interesting Properties”（演变于很早的一篇论文里的“Interesting Order”）在实现中到目前为止还是这样。当然这只是一部分，还有程序的等价逻辑转换等等。说实话，需要有很强的RDBMS优化器的理论支持，不然很容易看得云里雾里的，这一节我看了好几遍了，对于细节还是有些困惑。

• The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing 

这篇论文来自Google，主要应该是阐述Google Cloud Dataflow的Dataflow model模型，但是考虑到Flink在流处理中（特别是窗口实现）广泛借鉴了其提出的"时间概念"以及对窗口实现机制的理论，所以也放在系列论文里。具体就不多说了，触发器、窗口合并、事件时间、窗口歪斜Flink都引入了。具体的论文里面的一些example演示图你看不到动态的，你可以去搜《The world beyond batch: streaming 101/102》系列，或者本论文的第一作者的PPT/YouTube视频，可以看到动态演示。顺便说一句，Google好像没觉得Flink实现得多好，但是就目前而言，窗口这块比Spark是好多了。

• Spinning Fast Iterative Data Flows 

这篇是Flink迭代实现的论文三篇论文之一，是最早的一篇，还有两篇是讲迭代恢复时的优化的。顺便说一句，Flink的迭代重心主要在批处理上，感觉流中只是顺便实现，而且两者是不同的实现模型。而这篇论文主要也是针对批处理中的迭代，在论文（批处理）中，它将迭代划分为两种类型：批量（全量）迭代和增量迭代，并且对他们分别展开来讨论。首先引入了Fixpoint（定点）迭代以及step function，然后在增量迭代时引入了Workset（工作集）以及partial solution（在当前实现中变成了Solution Set）,当然还有microstep以及superstep。然后分别介绍了两种迭代数据流模型的集成、执行方式与优化。个人觉得，这应该是初期实现的雏形，现阶段有些概念保留有些已经不见踪影，但还是有读一读的价值。

当前的迭代运行时实现，是基于BSP（整体同步并行）计算模型来实现的，引入SuperStep（超级步）以及基于超级步的路障（SuperstepBarrier）同步。但是据本文的第一篇论文称，它是能够支持SSP或者其他模型，依赖其迭代控制事件。

后面大概还有5-7篇系列论文，待续~

---

---