这是我参与「第四届青训营 」笔记创作活动的的第5天
本来想花时间研究学习hdfs的源码来着，后来一想，自己还有项目啥的事情很多，更何况还想深入flink，所以hdfs就不花太多时间了，人贪多嚼不烂，没人可以做好所有事情
- flink是实时，基于事件驱动。spark streaming是微批模型
- flink支持事件事件等的处理
- source数据输入，transformation中间转换，sink输出
- 设置并行。yml系统层面，run -p客户端，getExecutionEnvironment.setParallelism执行环境，算子.setParallelism层面 我们尽量算子，环境，客户端，系统这样的优先级，业务中通常设置和kafka分区数的倍数
- slot是指单个taskmanager并发执行能力，parallelism指的是所有taskmanager的并发能力
- 9种分区策略
- watermark基于事件时间，用来出发窗口计算，是一个特殊的数据插入到流中
- taskmanager实际执行计算，jobmanager管理tm，协调检查点，负责故障回复，客户端和jm交互和把任务提交到集群
- 通常提交flink到yarn上运行
- ABS:jm定期向source发送检查点骑牛，向下游发送checkpointbarrier。计算算子收到后，进行barrier对齐，多个sink确认检查点正常后结束
- jm也可以结合zk实现高可用
- flink 的低延迟、高吞吐量和对流式数据应用场景更好的支持；另外，flink 可以很好地处理乱序数据，而且可以保证 exactly-once 的状态一致性。
- Exactly once is NOT exactly the same：快照/检查点和时间
- spark streaming 的 checkpoint 仅仅是针对 driver 的故障恢复做了数据和元数据的checkpoint。而 flink 的 checkpoint 机制要复杂了很多，它采用的是轻量级的分布式快照，实现了每个算子的快照，及流动中的数据的快照。
- flink使用检查点实现“精确一次”语义，
