这是我参与「第四届青训营」笔记创作活动的第5天。
概述
流批对比
数据实时性越高，数据价值越大
批处理
批处理典型数仓结构为T+1架构，当天只能看到前一天的计算结果。计算引擎通常为hive或spark等。
处理时间窗口
数据实时流动，实时计算，窗口结束发送结果，避免周期调度任务。
处理时间与事件时间
处理时间：数据在计算系统中真正处理时的当前时间
事件时间：数据产生的时间，如客户端上报数据时的时间。
事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。
watermark
在数据中插入watermark，表示当前的真实时间。
小结
批处理典型数仓结构为T+1架构
数据实时性越高，数据价值越大
实时计算分为处理时间与事件时间
事件时间需要Watermark配合处理乱序
watermark
表示系统认为的当前真实的事件时间
Watermark产生： 一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。
怎么传递watermark
传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。
watermark在生产实践中经常遇到的几个问题
-
怎么观察一个任务中的watermark是多少，以及是否正常
-
通过Flink Web UI上的信息来观察当前任务的watermark情况
-
在开发事件时间的窗口任务的时候，经常会忘记了设置watermark，或者数据太少，watermark没有及时的更新，导致窗口一直不能触发。
-
-
Per-partition / Per-subtask 生成watermark的优缺点
-
早期都是per-subtask的方式进行watermark的生成，这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
-
后期就逐步的变成了per-partition的方式来产生watermark，来避免上面的问题。
-
-
如果有部分partition/subtask会断流，应该如何处理
- 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的（上游只要有不更新的，下游都不更新。），因为它要取上游subtask发来的watermark中的最小值。用一种IDLE状态来标记这种subtask，被标记为这种状态的subtask，我们在计算watermark的时候，可以把它先排除在外。 这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。
-
算子对于时间晚于watermark的数据的处理
- 对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）
- 如window对于迟到的数据，默认就是丢弃；比如双流join，对于迟到数据，可以认为是无法与之前正常数据join上。
小结
定义： 当前系统认为的事件时间所在的真实时间。
产生： Watermark generator 生成
传递： 取上游所有subtask的最小值
部分数据断流： idle source
迟到数据： window丢掉，join不能join。
window
window基本功能
典型window：
1 TUMBLE Window （滚动窗口）
Flink 中的窗口划分是key级别的。 比如下图，有三个key，那每个key的窗口都是单独的。所以整个图中，一种存在14个窗口。
窗口触发：window到达结束时间一次性触发
2 HOP Window （滑动窗口）
在HOP窗口中，每条数据是可能会属于多个窗口的（具体属于多少，取决于窗口定义的大小和滑动），比如下图中假设滑动是1h的话，那窗口大小就是2h，这种情况每条数据会属于两个窗口。除了这一点之外，其它的基本跟HOP窗口是类似的，比如也是key级别划分窗口，也是靠timer进行窗口触发输出。
3 SESSION Window （会话窗口）
会话窗口跟上面两种窗口区别比较大，上面两个窗口的划分，都是根据当前数据的时间就可以直接确定它所属的窗口。会话窗口的话，是一个动态merge的过程。一般会设置一个会话的最大的gap，比如10min。
某个key下面来第一条数据的时候，当这个key后面来了另一条数据的时候，它会立即产生一个窗口，如果这个窗口跟之前的窗口有overlap的话，则会将两个窗口进行一个merge，变成一个更大的窗口，此时需要将之前定义的timer取消，再注册一个新的timer。所以会话窗口要求所有的聚合函数都必须有实现merge。(动态划分)
迟到数据处理
-
定义（窗口中的）： 严格来说数据晚于watermark就算迟到。Window中较为宽松。根据上面说到的watermark原理，watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。（注意，不是数据的时间晚于watermark就算是迟到，而是它所属的窗口已经被触发了，才算迟到）。
-
产生： 只有事件时间才有迟到数据。
-
处理：
-
allow lateness
设置允许迟到的时间，窗口正常计算结束后，会多保留设置要求的时间，后续迟到的数据依旧按照之前的状态进行计算。适用于datastream和SQL。->retract机制 -
sideoutput(侧输出流)
对迟到数据打tag，获取后在业务层面进行选择。
增量计算 VS 全量计算
- 增量计算： 每条数据到来后，直接参与计算（但是还不需要输出结果），系统只储存计算结果，不保存每条数据。Reduce,aggregate都是增量计算。SQL只有增量计算。
- 全量计算： 每条数据到来后，存储到window的state中，直到窗口触发输出的时候，才把所有数据拿出来统一进行计算。（例process）
EMIT触发
正常的窗口都是窗口结束的时候才会进行输出，比如一个1天的窗口，只有到每天结束的时候，窗口的结果才会输出。这种情况下就失去了实时计算的意义了。
- 定义：提前把窗口内容输出出来的一种机制。
- 实现：datastream可自定义trigger实现。SQL通过配置实现。
window高级优化
Mini-batch优化
Flink的状态比较大一些都推荐使用rocksdb statebackend，这种情况下，每次的状态访问就都需要做一次序列化和反序列化，开销较大。
为了降低这种开销，我们可以通过降低状态访问频率的方式来解决，这就是mini-batch最主要解决的问题：即赞一小批数据再进行计算，这批数据每个key的state访问只有一次，这样在单个key的数据比较集中的情况下，对于状态访问可以有效的降低频率，最终提升性能。
mini-batch看似简单，实际上设计非常巧妙。假设用最简单的方式实现，那就是每个算子内部自己进行攒一个小的batch，这样的话，如果上下游串联的算子比较多，任务整体的延迟就不是很容易控制。所以真正的mini-batch实现，是复用了底层的watermark传输机制，通过watermark事件来作为mini-batch划分的依据，这样整个任务中不管串联的多少个算子，整个任务的延迟都是一样的，就是用户配置的delay时间。
Local-global 倾斜优化
local-global优化是分布式系统中典型的优化，主要是可以降低数据shuffle的量，同时也可以缓解数据的倾斜。
将原本的聚合划分成两阶段，第一阶段先做一个local的聚合，这个阶段不需要数据shuffle，是直接跟在上游算子之后进行处理的；第二个阶段是要对第一个阶段的结果做一个merge（如果存在没有实现merge的聚合函数，那么这个优化就不会生效）。
如下图所示，比如是要对数据做一个sum，同样颜色的数据表示相同的group by的key，这样我们可以再local agg阶段对他们做一个预聚合；然后到了global阶段数据倾斜就消除了。
Distinct状态复用
对于distinct的优化，一般批里面的引擎都是通过把它优化成aggregate的方式来处理，但是在流式window中，不能直接这样进行优化，否则算子会变成下发retract的数据。
可以把相同字段的distinct计算用一个map的key来存储，在map的value中，用一个bit vector来实现就可以把各个状态复用到一起了。比如一个bigint有64位，可以表示同一个字段的64个filter，这样可以节省很多整体状态量。
滑动窗口pane复用
滑动窗口中，一条数据可能会属于多个window。同一个key下的window数量可能会比较多，比如3个小时的窗口，1小时的滑动的话，每条数据到来会直接对着3个窗口进行计算和更新。状态访问频率较高，计算量增加很多。
优化方法：窗口的状态划分成更小粒度的pane，比如上面3小时窗口、1小时滑动的情况，可以把pane设置为1h，这样每来一条数据，我们就只更新这条数据对应的pane的结果就可以了。当窗口需要输出结果的时候，只需要将这个窗口对应的pane的结果merge起来就可以了。(需要所有聚合函数都有merge的实现)
小结
mini batch 解决优化频繁访问状态的问题
local global 优化解决倾斜问题
distinct 状态复用降低状态量
pane 优化降低滑动窗口的状态存储量
总结
本节课回顾了之前的内容，介绍了流式计算和批式计算相关概念同时着重介绍了两者间的区别。介绍了watermark的含义和三种window的定义。内容丰富且深入。
