这是我参与「第四届青训营 」笔记创作活动的的第4天。
本节课程主要分为 4 个方面：
1.概述
2.Watermark
3.Window
4.案例分析
一.概述
1.1.流式计算 vs 批式计算
数据价值：实时性越高，数据价值越高
1.2.批处理：
批处理模型典型的数仓架构为T+1结构，即数据计算时天级别的，当天只能看到前一天的计算结果。通常使用的计算引擎为Hive或者Spark等。计算的时候，数据时完全ready的，输入和输出都是确定性的。
1.3.处理时间窗口
实时计算：处理时间窗口
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
1.4.处理时间 vs 事件时间
处理时间：数据在流式计算系统中真正处理时所在机器的当前时间。
事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时间。
1.5.事件时间窗口
实时计算：事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。
1.6.Watermark
✓ 在数据中插入一些watermark，来表示当前的真实时间。
✓ 在数据存在乱序的时候，watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡。
二.Watermark
2.1.什么时Watermark？
表示系统认为的当前真实的事件时间。
2.2.如何产生Watermark？
一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。
2.3.如何传递Watermark？
2.5.典型问题一：
Per-partition VS per-subtask watermark生成：
□ 在Flink里早期都是per-subtask的方式进行watermark的生成，这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
□ 后期(上面图中)就逐步的变成了per-partition的方式来产生watermark，来避免上面的问题。
典型问题二：
部分partition/subtask断流：
□ 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的，因为它要取上游subtask发来的watermark中的最小值。
□ 此时我们可以用一种IDLE状态来标记这种subtask，被标记为这种状态的subtask，我们在计算watermark的时候，可以把它先排除在外。这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。
典型问题三：
迟到数据处理：
□ 对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）
□ 比如window对于迟到的数据，默认就是丢弃；比如双流join，对于迟到数据，可以认为是无法与之前正常数据join上。
三.Window
3.1.Window-基本功能
3.1.1.Window分类
典型的Window：
1.Tumble Window(滚动窗口)
2.Sliding Window(滑动窗口)
3.Session Window(会话窗口)
3.1.2.滚动窗口
窗口划分： 1).每个key单独划分
2).每条数据只会属于一个窗口
3.1.3.滑动窗口
窗口划分： 1).每个key单独划分
2).每条数据可能会属于多个窗口
3.1.3.会话窗口
窗口划分： 1).每个key单独划分
2).每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge。
3.1.4.迟到数据处理
(1.)怎么定义迟到？
根据上面说到的watermark原理，watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。(注意，不是数据的时间晚于watermark就算是迟到，而是它所属的窗口已经被触发了，才算迟到)。
(2.)什么情况下会产生迟到数据？
只有事件时间下才会有迟到数据。
(3.) 迟到数据默认处理：
丢弃
1).Allow lateness
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常 计算结束后，不会马上清理状态，而是会保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。适用于：DataStream、SQL
2).SideOutput(侧输出流) 这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理。适用于：DataStream
3.1.5.增量 VS 全量计算
增量计算：■ 每条数据到来后，直接参与计算(但是还不需要输出结果),window只存储计算结果。
■ 典型的reduce、aggregate等函数都是增量计算。
■ SQL中的聚合只有增量计算。
全量计算：■ 每条数据到来后，会存储到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算。
■ 典型的process函数就是全量计算。
3.1.6.EMIT触发
EMIT输出的是：在window没有结束的时候，提前把window计算的部分结果输出出来。
3.2.Window-高级优化
1).Mini-batch优化：
优化解决频繁访问状态的问题。
2).local-global(倾斜优化)：
优化解决倾斜问题。
3).Distinct计算状态复用：
状态复用降低状态量。
4).pane优化:
优化降低滑动窗口的状态存储量。
四.案例分析
4.1.使用Flink SQL计算抖音的日活曲线
DAU(Daily Active User)：指的是每天的去重活跃用户数
输出：每个5s更新一下当前的DAU数值，最终获得一天内的DAU变化曲线
要求：通过上面课程中学到的窗口的功能以及相关的优化，开发一个Flink SQL任务，使得可以高效的计算出来上面要求的实时结果。
4.2.使用Flink SQL计算大数据任务的资源使用
问题描述：大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用（CPU、内存）情况上报。一般大数据任务运行时间从几分钟到几小时不等。
需求：根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。假设前后两个container结束时间差不超过10min。
