这是我参与「第四届青训营 」笔记创作活动的的第4天

Watermark

watermark的作用：在实时性和乱序容忍做一个平衡，配合时间窗口处理乱序数据。watermark传递机制: 后续算子收到多个watermark的时候，取上游传递给他的最小的watermark。 watermark生成机制： 一个subtask可以包含多个分区，不同的分区读取速度不一样，上游延迟程度不一样，导致人为加剧乱序程度。

对于迟到数据，window算子采取丢弃策略。join算子认为没有join到。

window

滚动窗口 滑动窗口 会话窗口

滚动窗口：窗口按照key划分（窗口定义在keyedStream上，窗口将每个key的数据按照某种规则进行分组，如最近5秒到达的数据。），窗口结束的时候才输出运算结果。数据进来就能计算，输出在结束的时候才输出。

滑动窗口：数据可以属于多个窗口。

会话窗口：数据的间隔决定会话窗口。

迟到数据的处理：window触发了之后才来的数据算迟到，window的触发可以进行一定的延迟allowlateness(DataStream,sql)。测流输出（仅限于Stream）：

计算策略： 增量：来一条计算一条（性能更优）eg：reduce,aggregate 全量：先缓存再计算，数据到来的时候会存在window的state里面，window触发的时候再计算。eg:processWindowFunction

EMIT机制：允许窗口的中间结果输出多次，eg一天的窗口数据，每隔一分钟输出一次，要用到retract机制。自定义触发器trigger实现。计算输出但不清理之前的结果。

MiniBatch优化：让算子攒一小批数据，处理输出，写回状态。可以减少状态的读写，优化资源。利用类似ck的机制，不断传递信号，优化MiniBatch。

数据倾斜优化:local-global:预聚合

distinct状态复用：filter条件复用同一份状态，降低窗台存储量。

pane优化：滑动窗口每条数据属于多个窗口的状态可以复用。在计算滑动窗口的时候把窗口划分成更小的粒度，在之后的计算中可以进行merge复用之前的计算。

案例分析

用flinksql计算抖音日活曲线： 滚动窗口+emit 任务计算量过大，无法直接计算 使用预聚合进行任务的计算，第一阶段先对数据进行分桶计算，第二阶段再对第一阶段的结果进行聚合计算。

会话窗口的应用： 尽快计算出大数据计算计算任务总资源消耗。一个任务有多个container，每个container回收的时候会上报资源消耗情况。假设container的时间间隔不超过10min,可以使用会话窗口尽快计算出一个任务消耗的所有container的资源。