这是我参与「第四届青训营 」笔记创作活动的第5天
前提概述
数据价值：实时性越高，数据价值越高
批处理
1.批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。
2.通常使用的计算擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。
处理时间窗口
为了让批处理更加的实时
实时计算：处理数据窗口
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务
处理时间和事件时间
处理时间： 数据在流式计算系统中真正处理时所在机 器的当前时间
事件时间： 数据产生的时间，比如客户端、传感器 后端代码等上报数据时的时间。
事件处理窗口
实时计算：事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序
Watermark
事件时间是需要Watermark配合来处理乱序
1.Watermark
表示系统认为的当前真实的事件时间
1.1 产生Watermark
SQL
CREATE TABLE Orders
user BIGINT,
product STRING,
order_time TIMESTAMP(3),
WATERMARK FOR order_time AS order_time INTERVAL '5'SECOND)
WITH(...);
复制代码
DataStream
WatermarkStrategy
<Tuple2<Long,String>>forBoundedOutoforderness(Duration.ofSeconds(20))
withTimestampAssigner((event,timestamp)->event.fo);
复制代码
1.2 传递Watermark
每个task会取上游传过来的watermark的最小值作为自身的watermark
1.3 通过Flink UI观察Watermark
经典问题：开发了一个Flink window事件窗口的程序，有数据输入，却没有数据输出，这时就可以通过Flink UI 来观察Watermark是否正常
经典问题一---Per-partition VS per-subtask watermark生成
Per-partition VS per-subtask watermark生成
Per-subtask watermark生成
早期版本都是这种机制。典型的问题是如果一个source subtask消费多个partition,那么多个 partition之间的数据读取可能会加剧乱序程度。
Per-partition watermark生成
新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。
经典问题二---部分partition/subtask断流
部分partition/subtask断流
根据上面提到的watermark传递机制，下游subtask会将上游所有subtask的watermark值的最 小值作为自身的watermark值。如果上游有一个subtask的watermark不更新了，则下游的 watermark都不更新。
解决方案：Idle source
当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle,并下发一个idle的状 态给下游。下游在计算自身watermark的时候，可以忽略掉当前是ide的那些subtask。
经典问题三---迟到数据处理
迟到数据处理 因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时系统会认为这种 数据是迟到的数据。
算子自身来决定如何处理迟到数据：
①Window聚合，默认会丢弃迟到数据
②双流join,如果是outer join,则可以认为它不能join到任何数据
③CEP,默认丢弃
小结
1.含义：表示系统认为的当前真实时间
2.生成：可以通过Watermark Generator来生成
3.传递：取上游所有subtask的最小值
4.部分数据断流：Idle Source
5.迟到数据处理：Window算子是丢弃；Join算子认为跟之前的数据无法join到
2. Window
2.1 window基本功能
典型的Vindow: l.Tumble Window(滚动窗口)
2.Sliding Window(滑动窗口)
3.Session Window(会话窗口)
其它Window:
1.全局Vindow
2.Count Window
3.累计窗口
4...
2.2 window的使用
2.3 滚动窗口
窗口划分：
1.每个key单独划分
2.每条数据只会属于一个窗口
窗口触发：
window结束时间到达的时候一次性触发
2.4 滑动窗口
窗口划分：
1.每个key单独划分
2.每条数据可能会属于多个窗口
窗口触发：
window结束时间到达的时候一次性触发
滑动窗口的窗口除了窗口大小之外还有个滚动时间，如果滚动时间为两个小时，则11点-13点为一次窗口，13点-15点为一次窗口，所以会导致一条数据可能会数据多个窗口
2.5 会话窗口
窗口划分：
1.每个key单独划分
2.每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge（合并）
窗口触发：
window结束时间到达的时候一次性触发
2.6 迟到数据处理
怎么定义迟到？
一条数据到来后，会用WindowAssigner给它划分一个window,一般时间窗口是一个时间区间， 比如[10：00,11：00)，如果划分出来的window end比当前的watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。
仕么情况下会产生迟到数据？
只有事件时间下才会有迟到的数据。
迟到数据默认处理？
丢弃
1.Allow lateness
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结 束后，不会马上清理状态，而是会多保留allowLateness这么长时间 在这段时间内如果还有数据到来则继续之前的状态进行计算。
适用于：DataStream、SQL
2.SideOutput(侧输出流)
这种方式需要对迟到数据打一个tag,然后在DataStream上根据这 个tāg获取到迟到数据流，然后业务层面自行选择进行处理。
适用于：DataStream
2.7 增量和全量计算
增量计算
-每条数据到来，直接进行计算，window只存储计算结果。 比如计算sum,状态中只需要存储sum的结果，不需要 保存每条数据。
-典型的reduce、aggregate等函数都是增量计算
-SQL中的聚合只有增量计算
全量计算
-每条数据到来，会存储到window的state中。等到 window触发计算的时候，将所有数据拿出来一起计算。
-典型的orocessl函数就是全量计算
2.8 EMIT触发
√什么叫EMIT?
通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window,只有在1个小时结 束的时候才能统一输出结果。
如果窗口比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。
EMIT输出指的是，在window没有结束的时候 提前把window计算的部分结果输出出来。
√怎么实现？
在DataStream里面可以通过自定义Trigger来实现， Trigger的结果可以是
-CONTINUE
-FIRE(触发计算，但是不清理）
-PURGE
-FIRE_AND_PURGE
SQL也可以使用，通过配置：
-table.exec.emit.early-fire.enabled=true
-table.exec.emit.early-fire.delay={time)
小结
3.Window高级优化
3.1 Mini-batch优化
就是将保存状态的操作不需要每条数据都发生一次，算子可以积累一定的这类操作再执行
3.2 倾斜优化--local-global
3.3 Pane优化
Pane优化降低滑动窗口的状态存储量
滑动窗口
小结
l.Mini-batch优化解决频繁访问状态的问题
2.local--global优化解决倾斜问题
3.Distinct状态复用降低状态量
4.Pane优化降低滑动窗口的状态存储量
案例
需求1---计算抖音日活曲线
改进后
通过两阶段聚合来把数据打散，完成第一轮 聚合，第二轮聚合只需要对各个分桶的结果 求和即可
