这是我参与「第四届青训营 」笔记创作活动的的第3天
数据流和动态表
-
如何在实时数据流中定义 SQL 语义中的表？
- 动态表 ： 随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们
-
实时流的查询特点？
- 查询从不终止
- 查询结果会不断更新，并且会产生一个新的动态表
- 结果的动态表也可转换成输出的实时流
-
动态表到实时流的转换
- Append-only Stream: Append-only 流（只有 INSERT 消息）
- Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）
- Upsert Stream:: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息）
算子状态
在流式计算中，会存在有状态的计算逻辑（算子）
比如，需要计算某个用户在网上的点击量，该用户在网站当前的总点击次数就是算子状态，对于新的输入数据，先判断是否是该用户的点击行为，如果是，则将保留的点击次数（状态）增加一，并将当前累加结果输出。
Exactly-Once 和 Checkpoint
一致性保证语义
- At-most-once：每条数据消费至多一次，处理延迟低
- At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
- Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生
端到端 Exactly-Once 实现
Chandy-Lamport算法
解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照； 在快照制作和 Barrier Alignment 过程中需要暂停处理数据，仍然会增加数据处理延迟； 快照保存到远端也有可能极为耗时。
Checkpoint 能保证每条数据都对各个有状态的算子更新一次，sink 输出算子仍然可能下发重复的数据； 严格意义的端到端的 Exactly-once 语义需要特殊的 sink 算子实现。
两阶段提交协议（2PC）
- Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点
- Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点
事务开启：在 sink task 向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读； 预提交阶段：JobManager 开始下发 Checkpoint Barrier，当各个处理逻辑接收到 barrier 后停止处理后续数据，对当前状态制作快照，此时 sink 也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向 JM 成功的消息，失败则发送失败的消息； 提交阶段：若 JM 收到所有预提交成功的消息，则向所有处理逻辑（包括 sink）发送可以提交此次事务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据；若 JM 有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时 sink 则丢弃这次事务提交的数据下。
