「流计算中的 Window 计算」

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

收获

1. 了解实时计算和批式计算的本质区别，以及实时计算所带来的新的机遇和挑战
2. 了解实时计算中的核心功能: Watermark机制、Window机制
3. 了解3大基本窗口类型的定义、使用以及核心原理
4. 了解窗口机制中的最核心的优化及其原理
5. 以上学习内容均会结合最前沿的企业实践进行讲解

概述

流式计算 VS 批式计算

简述流式计算的基本概念，与批式计算相比的难点和挑战

特性	批式计V算	流式计算
数据存储	HDFS、Hive	Kafka、Pulsar
数据时效性	天级别	分钟级别
准确性	精准	精准和时效性之间取舍
典型计算引擎	Hive、Spark、Flink	Flink
计算模型	Exactly-Once	At Least Once / Exactly Once
资源模型	定时调度	长期持有
主要场景	离线天级别数据报表	实时数仓、实时营销、实时风控

批处理

• 批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。
• 通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性。
• 

小时级批计算

处理时间窗口

实时计算:处理时间窗口 数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。

处理时间 VS 事件时间

• 处理时间:数据在流式计算系统中真正处理时所在机器的当前时间。
• 事件时间:数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。

事件时间窗口

• 实时计算:事件时间窗口

• 数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。

• 什么时候窗口才算结束呢?

Watermark

• 在数据中插入一些watermark，来表示当前的真实时间。
• 在数据存在乱序的时候，watermark就比较重要了，它河以用来在乱序容忍和实时性之间做一个平衡。

小结

1. 批式计算一般是T+1的数仓架构
2. 数据实时性越高，数据的价值越高
3. 实时计算分为处理时间和事件时间
4. 事件时间需要Watermark 配合来处理乱序

Watermark

Watermark 的含义、生成方法、传递机制，以及一些典型场景的问题和优化

什么是 Watermark?

表示系统认为的当前真实的事件时间

如何产生Watermark?

如何传递Watermark?

如何通过Flink UI观察Watermark?

典型问题

Per-partition Vs per-subtask watermark生成

• Per-subtask watermark生成

  • 早期版本都是这种机制。典型的问题是如果一个source subtask消费多个partition，那么多个partition之间的数据读取可能会加剧乱序程度。

• Per-partition watermark生成

  • 新版本引入了基于每个 partition单独的watermark生成机制，这种机制可以有效避免上面的问题。

部分partition/subtask断流

• 根据上面提到的watermark传递机制，下游subtask会将上游所有subtask的 watermark值的最小值作为自身的 watermark值。如果上游有一个subtask 的watermark 不更新了，则下游的watermark都不更新。

• 解决方案:Idle source

  • 当某个subtask断流超过配置的 idle超时时间时，将当前subtask置为idle，并下发一个idle 的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask。

迟到数据处理

• 因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。

• 算子自身来决定如何处理迟到数据:

  • Window聚合，默认会丢弃迟到数据
  • 双流join，如果是outer join，则可以认为它
  • 不能join到任何数据CEP，默认丢弃

Watermark小结

1. 含义:表示系统认为的当前真实时间
2. 生成:可以通过Watermark Generator来生成
3. 传递:取上游所有subtask的最小值
4. 部分数据断流: ldle Source
5. 迟到数据处理:Window算子是丢弃;Join 算子
6. 认为跟之前的数据无法join 到

window

Window基本功能眛和高级优化。

3.1

Window分类

典型的Window:

1. Tumble Window(滚动窗口)
2. Sliding Window(滑动窗口)
3. Session Window(会话窗口)

其它Window:

1. 全局 Window
2. Count Window
3. 累计窗口
4. ...

Window使用

滚动窗口

• 窗口划分:

  • 每个key单独划分
  • 每条数据只会属于—个窗口

• 窗口触发:

  • Window结束时间到达的时候一次性触发

滑动窗口

• 窗口划分:

  • 1.每个key单独划分
  • 2.每条数据可能会属于多个窗口

• 窗口触发:

  • Window结束时间到达的时候一次性触发

会话窗口

• 窗口划分:

  1. 每个key单独划分
  2. 每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge

• 窗口触发:

  • Window结束时间到达的时候—次性触发

迟到数据处理

• 怎么定义迟到?

  • 一条数据到来后，会用WindowAssigner给它划分一个window，一般时间窗口是一个时间区间，比如[10:00,11:00)，如果划分出来的window end比当前的watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。

• 什么情况下会产生迟到数据?

  • 只有事件时间下才会有迟到的数据。

• 迟到数据默认处理?

  • 丢弃

• 1.Allow lateness

  • 这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
  • 适用于: DataStream、SQL

• 2.SideOutput(侧输出流)

  • 这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理。
  • 适用于:DataStream

增量计算 VS 全量计算

增量计算:

• 每条数据到来，直接进行计算， window只存储计算结果。比如计算sum，状态中只需要存储sum的结果，不需要保存每条数据。
• 典型的reduce、aggregate等函数都是增量计算
• SQL中的聚合只有增量计算

全量计算:

• 每条数据到来,会存储到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算。
• 心典型的process函数就是全量计算

EMIT触发

什么叫EMIT?

• 通常来讲，window都是在结束的时候才能输出结果，比如1h的 tumble window，只有在1个小时结束的时候才能统一输出结果。
• 如果窗口比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。
• EMIT输出指的是，在window没有结束的时候，提前把 window计算的部分结果输出出来。

怎么实现?

• 在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是:

  • CONTINUE
  • FIRE(触发计算，但是不清理)
  • PURGE
  • FIRE_AND_PURGE

• SQL也可以使用，通过配置:

  • table.exec.emit.early-fire.enabled=true
  • table.exec.emit.early-fire.delay={time}

小结

1. 三种（滚动、滑动、会话)窗口的定义
2. 迟到数据处理: AllowLateness、SideOutput
3. 增量计算和全量计算模型
4. EMIT触发提前输出窗口的结果

3.2 Window 高级优化

Mini-batch优化

倾斜优化-local-global

Distinct计算状态复用

Pane优化

3.2 小结

1. Mini-batch 优化解决频繁访问状态的问题
2. local-global优化解决倾斜问题
3. Distinct状态复用降低状态量
4. Pane优化降低滑动窗口的状态存储量