TableAPI特点：
- Table API是以表为中心的声明式编程
- Table API会在执行之前见过内置优化器优化
slot
- 资源slot化，意味着一个subtas不需要跟来自其他job的subtask竞争被TaskManager管理的内存
- subtask之间相互隔离
- 一个TaskManager多个slot的好处
- 意味着更多的subtask可以共享同一个JVM
- 同一个JVM进程中，task将共享TCP（基于多路复用）和心跳信息
- 也可能共享数据集和数据结构，减少了每个task的负载
flink中的子任务subtask，理解为一个算子就是一个subtask，并行执行的时候，就会有多个subtask。相当于1对多
程序 => 逻辑数据流dataflow
- dataflow是一个有向无环图
- 程序中的转换算子(transform)跟dataflow中的算子（operator）大部分一一对应，少部分一多对应
执行图：
- client生成StreamGraph
- client生成JobGraph，对StreamGraph做优化，提交给JobManager
- JobManager生成ExecutionGraph，JobGraph的并行化版本，调度层最核心的结构
- task的运行构成物理执行图，物理执行图不是一个具体的数据结构
并行度parallelism
- 一个特定算子的subtask个数
- 不同算子的并行度可以不一样
迟到的流数据，它的事件时间有两种可能：乱序、升序。 因此处理这两种情况，需要使用的watermark分别为：
- BoundedOutOfOrdernessTimestampExtractor
- AscendingTimestampExtractor
assignTimestampsAndWatermarks( AssignerWithPeriodicWatermarks timestampAndWatermarkAssigner)
AssignerWithPeriodicWatermarks
- 周期性生成watermark
- 方法是：extractTimestamp
- 使用场景：流数据密集
AssignerWithPunctuatedWatermarks
- 断点式生成watermark
- 方法是：checkAndGetNextWatermark
- 使用场景：流数据稀疏
Watermark是一种延迟机制。
设置使用EventTime时间语义，那么就需要指定stream中的哪个字段作为事件时间。
而对于默认的ProcessTime，以下两种情况在Context ctx中的Context ctx表现不同
- 指定了时间提取器：assignTimestampsAndWatermarks(new AscendingTimestampExtractor())
ctx.timestamp() == 指定的流的字段的时间戳
- 不指定时间提取器
ctx.timestamp() == null
具体参见 cn.fancychuan.process.JavaProcessFunctionTest.testKeyedProcessFunction
侧输出流：
- sideOutputLateData
- processFunction中output
预写日志，至少一次。除非加上幂等性写入，才能精准一次
checkpoint是间隔性进行的，会在流中插入一条特殊的数据 source、transform以及sink遇到这个特殊数据，都会进行状态保存（checkpoint会对每个算子都进行状态保存）
作业出错后，会从最近一次完整的checkpoint中恢复
- 进行ck的时候，停止数据处理了吗？
没有，数据在处理，ck同时也在进行
barrier对齐：
- 多并行度（barrier会广播给各个子任务）
- 等待所有上游子任务的barrier到齐，才会触发状态的快照
- 在等待的过程中，有数据到达当前算子，会先放在缓冲区
- 为了避免对要做快照的状态产生影响
- exectly once
barrier不对齐：at-least-once
比如在等待barrier到齐的时候，来的数据没有放到缓冲区直接计算，这个时候结果就是 at least once
两阶段提交，会在ck完成之后再进行