Apache Flink: 在同一个引擎做流式和批处理

参考：

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

为什么要读这篇论文？

• 影响很大，google显示被引用次数881（截止日期：2020-08-07）
• 阿里巴巴以9000万欧元收购了开发它的公司。¹
• 流式处理已经不再是仅限于经典的aggregate和joins，而是进化成通用的大规模事件驱动应用。

批处理为什么不够？

• 批处理有高延迟。不能实时地做出响应。
• 批处理没有显式的支持时间的概念。
• 批处理可以被认为是流处理的一个特例：流长度是有限的，数据是有序的，时间不重要。

系统架构

论文[Figure 2]

• Client: 负责把程序代码转换成数据流图（估计是类似spark的RDD的概念）
• Job Manager: 服务器是分成master和worker，这个Job Manager就是master。负责分发任务，做查询优化，生成执行计划，监控任务完成情况，协调做checkpoint和恢复。
• Task Manager: 就是worker。负责执行任务。把状态报告给Job Manager。

数据流图

论文[Figure 3]

• 数据流是并行的——图中上下两条线并行执行。
• 一个operators被分成多个并行的subtasks，每个subtask负责处理流的1个partition（应该是类似sharding的概念）
• 有些节点会要求整个流到它那里停下来，把前后两个operator分成两个阶段(stages)。比如sort-merge joins，目的是防止分布式死锁。
• 控制事件也是随着数据流一起流动。一元操作符（只接受1个partition的）必须保证维持整个partition内部的记录顺序不变（“guarantee a FIFO order of records”）。二元及以上操作符不保证。控制事件有哪些呢？
  • checkpoint barriers
  • watermarks（表示某一特定时间之前的所有数据都已经发完/收到了。）
  • iteration barriers（用于执行迭代任务，表示一次迭代完成）

Trade-off

论文[Figure 4]

• buffer-timeout对于延迟和吞吐量的影响。一般来说延迟和吞吐量是矛盾的，想要吞吐量大，缓冲区的timeout要大，但是同时也会造成延迟大。
• 三种时间概念: event time是事件