流式计算中的Window机制|青训营笔记

也是不懂了
246 阅读13分钟

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

这篇笔记的主要内容分为四个部分：

  1. 流式计算基本概念，以及和批式计算的区别。
  2. watermark的含义、如何生成、如何传递，以及如何处理部分partition断流的问题。
  3. 三大基本窗口类型的定义，以及迟到数据处理、增量计算和全量计算、EMIT输出；local-global优化、mini-batch优化、distinct状态优化、滑动窗口的pane的优化。
  4. 两个案例：抖音DAU实时曲线计算和大数据任务资源使用实时统计分析。

一、流式计算和批式计算

1. 流式计算 VS 批式计算

image.png 数据价值：实时性越高，数据价值越高。

2. 批处理

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

image.png 小时级批计算： image.png

3. 处理时间窗口

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

image.png 当按处理时间进行窗口化时，系统将传入的数据缓冲到窗口中直到经过了一定的处理时间。例如，在5分钟固定窗口的情况下，系统将缓冲数据为5分钟的处理时间，之后它将把在这5分钟内观察到的所有数据作为一个窗口并将它们发送到下游进行处理。

4. 处理时间 VS 事件时间

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

image.png

5. 事件时间窗口

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

image.png

6. Watermark

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

7. 小结

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

二、Watermark

1. 什么是Watermark？

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

2. 如何产生Watermark？

一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以容忍多长时间的乱序。

SQL： image.png DataStream： image.png

3. 如何传递Watermark？

这个类似与Checkpoint的制作过程，传递就类似与Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。 image.png

4.如何通过Flink UI观察Watermark？

image.png image.png

5. 典型问题一

Per-partition VS per-subtask watermark生成的优缺点

  • Per-subtask watermark生成
  • 在Flink里早期版本都是这种机制，这种方式比较简单。但是如果一个source subtask消费多个partition，那么多个partition之间的数据读取可能会加剧乱序程度。
  • Per-partition watermark生成
  • 新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。

6. 典型问题二

如果有部分partition/subtask断流，应该如何处理？

  • 根据watermark传递机制，下游subtask会将上游所有subtask的watermark值的最小值作为自身的watermark值。如果上游有一个subtask的watermark不更新了，则下游的watermark都不更新。
  • 解决方案：Idle source
  • 当某个subtask断流超过配置的idle超过时间时，将当前subtask置为idle，并下发一个idle的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask。

7. 典型问题三

算子对于时间晚于watermark的数据的处理

  • 因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。
  • 对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）。

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

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

8. Watermark小结

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

三、Window

1. Window-基本功能

1.1. Window分类

典型的Window：

  1. Tumble Window（滚动窗口）
  2. Sliding Window（滑动窗口）
  3. Session Window（会话窗口）

其它Window：

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

1.2. Window使用

image.png

1.3. 滚动窗口

注意：Flink中的窗口划分是key级别的。

窗口划分：

  1. 每个key单独划分
  2. 每条数据只会属于一个窗口

窗口触发： Window结束时间到达的时候一次性触发 image.png 滚动窗口有固定的大小，是一种对数据进行均匀切片的划分方式。窗口之间没有重叠，也不会有间隔，是“首尾相接”的状态。滚动窗口可以基于时间定义，也可以基于数据个数定义；需要的参数只有一个，就是窗口的大小（window size）。

1.4. 滑动窗口

窗口划分：

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

窗口触发： Window结束时间到达的时候一次性触发 image.png

  • 与滚动窗口类似，滑动窗口的大小也是固定的。区别在于，窗口之间并不是首尾相接的，而是可以“错开”一定的位置。如果看作一个窗口的运动，那么就像是向前小步“滑动”一样。定义滑动窗口的参数有两个：除去窗口大小（window size）之外，还有一个滑动步长（window slide），代表窗口计算的频率。
  • 滑动窗口其实是固定大小窗口的更广义的一种形式，滚动窗口也可以看作是一种特殊的滑动窗口——窗口大小等于滑动步长（size=slide）。

1.5. 会话窗口

窗口划分：

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

窗口触发： Window结束时间到达的时候一次性触发 image.png

  • 与滑动窗口和滚动窗口不同，会话窗口只能基于时间来定义，而没有“会话计数窗口”的概念。
  • 考虑到事件时间语义下的乱序流，在Flink底层，对会话窗口的处理会比较特殊：每来一个新的数据，都会创建一个新的会话窗口；然后判断已有窗口之间的距离，如果小于给定的size，就对它们进行合并（merge）操作。在Window算子中，对会话窗口会有单独的处理逻辑。

1.6. 迟到数据处理

（1）怎么定义迟到？

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

（2）什么情况下会产生迟到数据？

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

（3）对于迟到的数据，有两种处理方式：

  • 使用side output方式，把迟到的数据转变成一个单独的流，再由用户自己来决定如何处理这部分数据。
  • 直接drop掉。

注意：side output只有再DataStream的窗口中才可以用，在SQL中目前还没有这种语义，所以暂时只有drop这一个策略。

（4）Allow lateness

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

（5）sideOutput（侧输出流）

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

image.png

1.7. 增量 VS 全量计算

增量计算：

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

image.png

全量计算：

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

image.png

1.8. 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.9. 小结

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

2. Window-高级优化

以下高级优化，只限于在SQL中的window中才有。在DataStream中，用户需要自己通过代码来实现类似的能力。

2.1. Mini-batch优化

在默认情况下，聚合算子对摄入的每一条数据，都会执行“读取累加器状态→修改状态→写回状态”的操作。如果数据流量很大，都会操作的overhead也会随之增加，影响效率（特别是RocksDB这种序列化成本高的Backend）。开启Mini-Batch之后，摄入的数据会攒在算子内部的buffer中，达到指定的容量或时间阙值后再做聚合逻辑。这样，一批数据内的每个key只需要执行一次状态读写。如果key的量相对比较稀疏，优化效果更加明显。

下面这张图展示的是普通的聚合算子的mini-batch原理，window的mini-batch原理是一样的。 image.png Mini-Batch机制会导致数据处理出现一定的延迟，用户需要自己权衡时效性和吞吐量的重要程度再决定。

2.2. 倾斜优化——local-global

  • local-global优化是分布式系统中典型的优化，主要是可以降低数据shuffle的量，同时也可以缓解数据的倾斜。
  • local-global将原本的聚合划分成两阶段，第一阶段先做一个local的聚合，这个阶段不需要数据shuffle，是直接跟再上游算子之后进行处理的；第二个阶段是要对第一阶段的结果做一个merge（如果存在没有实现merge的聚合函数，那么这个优化就不会生效）。

如下图所示，要对数据做一个sum，同样颜色的数据表示相同的group by的key，在local agg阶段对它们做一个预聚合，然后到了globa阶段数据倾斜就消除了。 image.png

2.3. Distinct计算状态复用

在SQL中，有一种方式可以在聚合函数上添加一些filter，如下面的SQL所示： image.png 对于这种情况，我们会对同一个字段用不同的filter来进行count distinct的计算。

把相同字段的distinc计算用一个map的key来存储，在map的value中，用一个bit vector来实现就可以把各个状态复用到一起了。 image.png

2.3. Pane优化

对于滑动窗口而言，其优化方法就是，将窗口的状态划分成更小粒度的pane，比如3个小时的窗口，1小时的滑动的情况，可以把pane设置为1h，这样每来一条数据，我们就只更新这条数据对应的pane的结果就可以了。当窗口需要输出结果的时候，只需要将这个窗口对应的pane的结果merge起来就可以了。

注意：这里也是需要所有聚合函数都有merge的实现的。 image.png

3. 小结

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

四、案例

1.使用Flink SQL计算抖音的日活曲线

问题：所有数据都需要在一个subtask中完成窗口计算，无法并行。 image.png 方法：通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可。 image.png

  • table.exec.emit.early-fire.enabled=true
  • table.exec.emit.early-fire.delay=5min
  • table.exec.window.allow-retract-input=true

2. 使用Flink SQL计算大数据任务的资源使用

  • 问题描述：大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用（CPU、内存）情况上报。一般大数据任务运行时间从几分钟到几小时不等。
  • 要求：根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。假设前后两个container结束时间差不超过10min。 image.png 典型的可以通过会话窗口来将数据划分到一个window中，然后再将结果求和即可。
avatar
文章
阅读
粉丝