参考:
Apache Flinkó: Stream and Batch Processing in a Single Engine
为什么要读这篇论文?
- 影响很大,google显示被引用次数881(截止日期:2020-08-07)
- 阿里巴巴以9000万欧元收购了开发它的公司。1
- 流式处理已经不再是仅限于经典的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要大,但是同时也会造成延迟大。