这是我参与【第四届青训营】笔记创作活动的第六天
流式计算基本概念
1.1 流式计算vs批式计算
批式计算储存：HDFS；Hive 计算引擎：Hive；Spark；Flink 资源模型：定时调度：跑一个任务就结束了，企业中采用定时调度 场景：离线天级别数据报表
流式计算储存：Kafka；pulsar 计算引擎：Flink 资源模型：长期持有：因为要一直跑数据，提前分配好一定量资源一直跑数据 场景：实时数仓；实时风控；实时推荐
1.2 批处理
批处理模型典型的数仓结构为T+1架构，即数据计算是天级别的，当天只能看到前一天的计算结果。通常使用计算引擎为Hive，Spark等。计算的时候，数据的完全ready的，输入和输出都是确定性的。
小时级批计算：
1:除了计算之外，每次需要申请和调度这个过程，非常浪费资源；
2.时间长度从分钟到小时不等， 数据产生到完成在一个小时之内完成很多场景下做不到
如何做到更实时 数据实时性越高，数据价值越高
1.3 处理时间窗口
实时计算：处理时间窗口，数据实时流动，实时计算，窗口结束直接发送结果（来一条数据发一条结果 ），不需要周期调度任务。
1.4 处理时间vs事件时间
处理时间：数据在流式计算系统中真正处理时所在机器的时间
事件时间：数据产生的时间，比如客户端、传感器等上报数据的时间
处理时间和事件时间有延迟，延迟很难处理
1.5 事件时间窗口
实时计算：事件时间窗口，数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理延迟和乱序，这个和机器本身的容错相关
1.6 Watermarker
事件时间需要watermarker配合处理
在数据中插入一些watermarker，来表示当前的真实时间
在数据乱序时watermarker就很重要了，他可以用来在乱序容忍和实时性之间做一个平衡。假如watermarker后面有一个比watermarker小的数，我们可以认为这个数据是个迟到的数据，不影响前面窗口的计算和结束
Watermark
什么是watermarker
系统认为的当前真实的事件时间
如何产生watermarker
如何接收watermark
watermap 直接收前面传递来的最小值，比如说，前方两个节点一个传来29，一个传来17，这个节点直接收17。
如何通过FLink UI观察watermark？
为什么只看到有输入没输出？首先观察watermarker是不是正常的，没有输出当前的watermarker可能是因为前面的数据不够多；或者前面的watermarker是异常的；也有可能watermarker有计算但是窗口没有到达输出的时候；
典型问题一
per-partitionVSper-subtask watermarker生成 per-subtask生成：早期版本都是这种机制，问题是一个source subtask消费多个partition，每个paitition之间完成的速度都不同，那么多个partition之间数据读取就会加剧乱序程度。
per-partition生成：新版本引入了基于每个partition单独的watermarker生成机制，这种机制可以避免以上问题
典型问题二
subtask/partition断流
根据上面watermarker的传递机制，下游subtask会接收上有所有subtask的watermark的最小值作为自身的watermark值。如果上游有一个watermark的值不更新了，则后面所有watermark都不更新了。e.g.部分watermarker没有产生，导致最终数据没有输出和产生
解决方案：Idle Source 当某个subtask断流超过配置的idle超过时间时，将当前subtask标记为idle，发送给下游一个idle的状态，告诉下游计算时可以忽略掉是idle的那些subtask
典型问题三
处理迟到数据
因为watermarker表示事件发生的真实时间，那晚于watermark到来的数据，系统认为这些数据是迟到的数据。只有事件时间下才有迟到的数据，处理时间没有迟到数据。e.g.window end时间比当前watermarker的值还小，这个数据会被认为是迟到数据
算子自身来决定如何处理迟到的数据：
- window聚合，默认丢弃迟到的数据
- 双流join，如果是outer join则认为他不能join到任何数据
- CEP，默认丢弃
- 可以查看到有多少迟到的数据
Window
基本功能{
Window分类
典型的窗口：
- Tumble Window滑动窗口：窗口划分：1.每个key单独划分；2.每条数据可以属于多个窗口；窗口触发：Window结束时间到达时一次性触发
- Sliding Window滚动窗口：窗口划分：1.每个key单独划分；2.每条数据只属于一个窗口；窗口触发：Window结束时间到达时一次性触发（固定窗口：根据时间确定数据属于哪个窗口，窗口不会变）
- Seesion Window会话窗口：窗口划分：1.每个key单独划分；2.每条数据单独划分一个窗口，如果window之间有交集，则merge两个窗口（数据到来的时候不能确定最终的窗口是哪一个，只能确定这条数据属于哪一个，窗口划分是一个动态的，可能会变大）
其他窗口：
- 全局 Window
- Count Window
- 累计窗口
Window使用方式
FLinkAPI本身是分层结构有 SQL API；Table API；DataStream API；抽象程度分层，抽象程度越高，使用成本越低，表达能力越有限
处理迟到数据2
- AllowLateness：设置一个允许迟到的时间，设置之后，窗口正常结束，不会马上清理状态，而是会多保留Allow lateness这么长的时间，在这段时间数据还没有到来，则继续之前的状态进行计算。适用于：SQL；DataStream
- SideOutput：这种方式需要对迟到的数据打一个tag，然后在DataStream上根据tag获取迟到数据流，在业务层面自行选择处理。适用于：DataStream
增量计算和全量计算
增量计算：
- 每条数据到来，直接进行计算，window只储存计算结果。比如计算sum，状态中只需要储存sum，不需要保存每条数据
- 典型的reduce和aggregate等函数都是增量计算
- SQL中只有聚合是增量计算
全量计算：
- 每条数据的到来，会储存到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算
- 典型的process函数就是全亮计算
EMIT触发
什么叫EMIT
通常来讲，window都是在结束的时候统一输出，比如说一小时的窗口只有在一小时窗口结束以后才会统一输出。如果窗口比较大，就失去了实时计算的意义。EMIT是指，在窗口还没有结束的时候，提前把window计算的部分结果输出出来
怎么实现
在DataStream里用trigger来实现，Trigger的结果可以是：
- Continue；FIRE（触发计算，但不清理）；PURGE；FIRE_AND_PURGE
SQL也可以，通过配置：
- table.exec.emit.early-fire.enable=true
- table.exec.emit.early-fire.delay={time}
}
高级优化{
Mini-batch优化
解决访问频繁问题 原来：每条数据来了以后都要读取原来的状态再进行计算输出，然后在写入，每次都要做反序列化，对CPU的开销很大；Mini-batch优化主要解决状态访问频繁
Mini-batch优化：算子攒一小批数据，读一次状态，处理一小批数据，再输出写入。
Local-golbal倾斜优化
优化解决倾斜问题
Distinct计算状态复用
降低状态量
Pane优化
降低滑动窗口的状态存储量 不是窗口，最后可以组成窗口，组成滚动窗口，最终在输出结果的时候做一次末指
