这是我参与「第四届青训营 」笔记创作活动的的第7天！
典型问题
Per-partition(分区) Vs per-subtask(子任务) watermark生成
Per-subtask watermark生成(子任务) 早期版本都是这种机制。典型的问题是如果一个source subtask(源任务)消费多个partition(下游的区)，那么多个partition之间的数据读取可能会加剧乱序程度。
Per-partition watermark生成(分区) 新版本引入了基于每个 partition单独的watermark生成机制，这种机制可以有效避免上面的问题。
部分partition/subtask断流
根据上面提到的watermark传递机制，下游subtask 会将上游所有subtask的watermark值的最小值作为自身的watermark值。如果上游有一个subtask的 watermark不更新了，则下游的watermark都不更新。
解决方案:ldle source(空闲) 当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle，并下发一个idle的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask(子任务)。
迟到数据处理
因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。
算子自身来决定如何处理迟到数据: Window聚合，默认会丢弃迟到数 双流join，如果是outer join，则可以认为它不能join到任何数据 CEP，默认丢弃
window(窗口)
Window基本功能和高级优化
基本功能
window分类
典型的Window：
Tumble Window（滚动窗口）
Sliding Window（滑动窗口）
Session Window（会话窗口）
其它Window：
全局Window Count Window 累计窗口 等 window使用 API应用程序编程接口,抽象分层 抽象程度越高,用户使用成本低,表达能力低(有限)
滑动窗口
这是最常见的窗口类型，就是根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中windowStart = timestamp - timestamp % windowSize，这条数据所属的window就是[windowStart, windowStart + windowSize)
窗口划分: 1.每个key单独划分 2.每条数据只会属于一个窗口
窗口触发: Window结束时间到达的时候一次性触发
滚动窗口
窗口划分: 1.每个key单独划分 2.每条数据可能会属于多个窗口
窗口触发: Window结束时间到达的时候一次性触发
会话窗口
窗口划分: 1.每个key单独划分 2.每条数据会单独划分为一个窗口，如果window之间有交集,则会对窗口进行merge(合并)
窗口触发: Window结束时间到达的时候一次性触发
迟到数据的处理
迟到数据定义
一条数据到来后，会用WindowAssigner 给它划分一个 window(start,end)，一般时间窗口是一个时间区间，比如[10：00，11：00），如果划分出来的 window end 比当前的 watermark 值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。\
迟到数据产生:
只有事件时间,实际时间下才会有迟到的数据。
处理时间(系统观测,理论时间)不产生\
迟到数据默认处理:
丢弃
(此外处理)\
Allow lateness
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留 allowLateness 这么长时间，在这段时间内如果还有数据到来，则继续之前(先retreat回滚，然后在缓存区继续，参考快照)的状态进行计算。
适用于：DataStream、SQL
\SideOutput（侧输出流）
这种方式需要对迟到数据打一个 tag，然后在 DataStream 上根据这个 tag 获取到迟到数据流，然后业务层面自行选择进行处理。
适用于：DataStream\
案例分析
抖音 DAU 实时曲线计算 大数据任务资源使用实时统计分析
需求一：使用Flink SQL 计算抖音的日活曲线 DAU
需求二：使用Flink SQL 计算大数据任务的资源使用
问题描述： 大数据任务（特指离线任务）运行时通常会有多个 container 启动并运行，每个 container 在运行结束的时候，YARN 会负责将它的资源使用（CPU、内存）情况上报。一般大数据任务运行时间从几分钟到几小时不等。 需求： 根据 YARN 上报的各个 container 的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。 假设前后两个 container 结束时间差不超过 10min
application_id
SUM(cpu_usage)as cpu_total
SUM(memory_usage)as memory_total,
FROM resource_usage
GROUP BY
application_id,
SESSION(event_time,INTERVAL '10'MINUTE)
复制代码
