这是我参与「第四届青训营 」笔记创作活动的第1天

Flink：stateful compulations over unbounded an bounded data streams.

发展过程：Hadoop -> Spark -> Flink

Flink分层架构：

1. SDK层：SQL/Table、DataStream、Python
2. Runtime层（执行引擎层）
3. 状态存储层
4. 资源调度层

整体架构：

• JobManager(JM):负责整个任务的协调工作，包括:调度task、触发协调Task 做 Checkpoint、协调容错恢复等；
• TaskManager(TM):负责执行一个DataFlowGraph 的各个task 以及data streams 的 buffer和数据交换。

Flink如何做到流批一体：

批计算本来就是流计算的特例，有界数据流也是数据流，故可用一种架构实现两种计算。

主要从以下模块来做： SQL层 DataStream API层 Scheduler层 Failover Recovery层 Shuffle Service层

Flink Exactly-once 的实现方式：Checkpoint

关键机制：Checkpoint 机制和 Two-phase commit protocol Checkpoint机制详细分析可以参考博客 两阶段提交协议自我感觉与分布式数据库中的大同小异，无非就是协调者，参与者，准备阶段和提交阶段，提交前要先询问是否准备好，若都准备好则提交，否则就不提交。

Watermark:当前系统认为的事件时间所在的真实时间。

Watermark产生：一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。 Watermark传递：这个类似于上节课中介绍的Checkpoint的制作过程，传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。

Window基本功能

TUMBLE Window：根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中

HOP Window：在HOP窗口中，每条数据是可能会属于多个窗口的（具体属于多少，取决于窗口定义的大小和滑动）

SESSION Window：会话窗口跟上面两种窗口区别比较大，上面两个窗口的划分，都是根据当前数据的时间就可以直接确定它所属的窗口。会话窗口的话，是一个动态merge的过程。