这是我参与「第四届青训营」笔记创作活动的第 5 天。
一、笔记内容
1、概述
2、Watermark
3、Window
4、案例分析
二、概述
1. 流式计算和批式计算
数据价值：实时性越高，数据价值越高
| 特性 | 批式计算 | 流式计算 |
|---|---|---|
| 数据存储 | HDFS、Hive | Kafka、Pulsar |
| 数据时效性 | 天级别 | 分钟级别 |
| 准确性 | 精准 | 精准和时效性之间取舍 |
| 典型计算引擎 | Hive、Spark、Flink | Flink |
| 计算模型 | Exactly-Once | At Least Once/Exactly Once |
| 资源模型 | 定时调度 | 长期持有 |
| 主要场景 | 离线天级别数据报表 | 实时数仓、实时营销、实时风控 |
2.批处理
-
批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。
-
通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。
小时级批计算：更加实时。
3.处理时间窗口
实时计算：处理时间窗口
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
4.处理时间和事件时间
处理时间：数据在流式计算系统中真正处理时所在机器的当前时间。
事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。
5.事件时间窗口
实时计算： 事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。
三、Watermark
Watermark：当前系统认为的事件时间所在的真实时间。
1. Watermark的作用
-
在数据中插入—些watermark，来表示当前的真实时间。
-
在数据存在乱序的时候，watermark可以用来在乱序容忍和实时性之间做一个平衡。
2. Watermark的产生
一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。
3. Watermark的传递
上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。
4. watermark在生产实践中遇到的问题
？问题1：怎么观察一个任务中的watermark是多少，是否是正常的?
-
一般通过Flink Web UI上的信息来观察当前任务的watermark情况；
-
这个问题是生产实践中最容易遇到的问题，在开发事件时间的窗口任务的时候，经常会忘记了设置watermark，或者数据太少，watermark没有及时的更新，导致窗口一直不能触发。
？问题2：Per-partition和Per-subtask watermark生成
-
Per-subtask watermark：
- 在Flink里早期都是per-subtask的方式进行watermark的生成，这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
-
Per-partition watermark：
- 新版本引入了基于每个 partition单独的watermark生成机制，这种机制可以有效避免上面的问题。
？问题3：部分partition/subtask断流
断流原因： 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的，因为它要取上游subtask发来的watermark中的最小值。
解决方案：Idle source ：当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle，并下发一个idle 的状态给下游。下游在计算自身watermark 的时候，可以忽略掉当前是idle的那些subtask。
？问题4：迟到数据处理
迟到数据：因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。
算子自身来决定如何处理迟到数据:
-
Window聚合，默认会丢弃迟到数据；
-
双流join，如果是outer join，则可以认为它不能join到任何数据；
-
CEP，默认丢弃。
四、Window
1.Window的基本功能
1. Window分类
graph TD
典型Window --> umbleWindow(滚动窗口)
典型Window --> SlidingWindow(滑动窗口)
典型Window --> SessionWindow(会话窗口)
2.滚动窗口
窗口划分：
-
1.每个key单独划分
-
2每条数据只会属于—个窗口
窗口触发：Window结束时间到达的时候一次性触发。
3.滑动窗口
窗口划分：
1.每个key单独划分
2.每条数据可能会属于多个窗口
窗口触发：Window结束时间到达的时候一次性触发。
4.会话窗口
窗口划分：
1.每个key单独划分
2每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge。
窗口触发：Window结束时间到达的时候一次性触发。
5.迟到数据处理方法
产生迟到数据的情况：只有事件时间下才会有迟到的数据。
-
Allow lateness
-
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
-
适用于: DataStream、sQL
-
-
SideOutput(侧输出流)
-
这种方式需要对迟到数据打一个tag，然后在DataStream 上根据这个tag 获取到迟到数据流，然后业务层面自行选择进行处理。
-
适用于:DataStream
-
6.增量计算和全量计算
增量计算：
-
每条数据到来,直接进行计算。window只存储计算结果。比如计算sum，状态中只需要存储sum的结果，不需要保存每条数据。
-
典型的reduce、aggregate等函数都是增量计算。
-
SQL中的聚合只有增量计算。
全量计算:
-
每条数据到来,会存储到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算。
-
典型的process函数就是全量计算。
7.EMIT触发
1. EMIT概念
通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window，只有在1个小时结束的时候才能统一输出结果。如果窗口比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。
EMIT输出指的是，在window没有结束的时候，提前把window计算的部分结果输出出来。
2.EMIT实现
在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是:
-
CONTINUE
-
FIRE (触发计算，但是不清理)
-
PURGE
-
FIRE_AND_PURGE
-
SQL也可以使用，通过配置:
-
table.exec.emit.early-fire.enabled=true
-
table.exec.emit.early-fire.delay={time}
2. Window高级优化
1. mini-batch优化
mini-batch主要解决的问题：即赞一小批数据再进行计算，这批数据每个key的state访问只有一次，这样在单个key的数据比较集中的情况下，对于状态访问可以有效的降低频率，最终提升性能。
mini-batch实现原理：复用底层的watermark传输机制，通过watermark事件来作为mini-batch划分的依据，这样整个任务中不管串联的多少个算子，整个任务的延迟都是用户配置的delay时间。
2.Local-global优化
local-global优化是分布式系统中典型的优化，主要是可以降低数据shuffle的量，同时也可以缓解数据的倾斜。
local-global原理：将原本的聚合划分成两阶段，第一阶段先做一个local的聚合，这个阶段不需要数据shuffle，直接跟在上游算子之后进行处理；第二个阶段是对第一个阶段的结果做一个merge（如果存在没有实现merge的聚合函数，那么这个优化就不会生效）。
3.Distinct状态复用
对于distinct的优化，一般批里面的引擎都是通过把它优化成aggregate的方式来处理，但是在流式window中，我们不能直接这样进行优化，要不然算子就变成会下发retract的数据了。所以在流式中，对于count distinct这种情况，我们需要保存所有数据是否出现过需要的映射。
在SQL中，我们有一种方式可以在聚合函数上添加一些filter，如下面的SQL所示：
根据上图：对同一个字段用不同的filter来进行count distinct的计算。如果每个指标都单独用一个map来记录每条数据是否出现过，状态量过大。因此可以将相同字段的distinct计算用一个map的key来存储，在map的value中，用一个bit vector来实现就可以把各个状态复用到一起。
4.滑动窗口pane优化
将窗口的状态划分成更小粒度的pane，如3小时窗口、1小时滑动的情况，可以把pane设置为1h，这样每来一条数据，我们就只更新这条数据对应的pane的结果就可以了。当窗口需要输出结果的时候，只需要将这个窗口对应的pane的结果merge起来就可以了。
这里也是需要所有聚合函数都有merge的实现的。
五、案例分析
1. 使用Flink SQL计算抖音的日活曲线
问题：所有数据都需要在一个subtask中完成窗口计算，无法并行。
解决：通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可。
2. 计算大数据任务的资源使用
问题：大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用（CPU、内存）情况上报。一般大数据任务运行时间从几分钟到几小时不等。
需求：根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。假设前后两个container结束时间差不超过10min。
解决：典型的可以通过会话窗口来将数据划分到一个window中，然后再将结果求和即可。
