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

ShowerSong
149 阅读10分钟

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

01.概述

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

1.1 流式计算 VS 批式计算

数据价值：实时性越高，数据价值越高

1.PNG

1.2 批处理

  • T+1架构：数据计算是天级别的，当天只能看到前一天的计算结果

  • 小时级批计算

  • 如何做到更实时？

1.3 处理时间窗口

  • 实时计算：处理时间窗口
  • 数据实时流动，实时计算；数据进来，直接计算，窗口结束直接发送结果

1.4 处理时间 VS 事件时间

  • 处理时间：数据在流式计算系统中真正处理时所在机器的当前时间

  • 事件事件：数据产生的时间，比如客户端、传感器、后端代码等上报数据的时间

2.jpg

1.5 事件时间窗口

1.6 Watermark

  • 在数据中插入一些watermark，来表示当前的真实时间
  • 在数据乱序的时候，watermark就比较重要了

小结

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

02.Watermark

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

2.1 什么是Ｗatermark？

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

2.2 如何产生Ｗatermark？

Watermark产生：

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

2.3 如何传递Ｗatermark？

Watermark传递：

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

4.png

2.4 典型问题一

Per-partition / Per-subtask 生成watermark的优缺点

  • 在Flink里早期都是per-subtask的方式进行watermark的生成，这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
  • 后期（上面图中）就逐步的变成了per-partition的方式来产生watermark，来避免上面的问题。

2.5 典型问题二

部分partition/subtask断流

  • 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的，因为它要取上游subtask发来的watermark中的最小值。
  • 解决方案：idle source
  • 此时我们可以用一种IDLE状态来标记这种subtask，被标记为这种状态的subtask，我们在计算watermark的时候，可以把它先排除在外。这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。

2.6 典型问题三

迟到数据问题

  • 对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）
  • 比如window对于迟到的数据，默认就是丢弃；比如双流join，对于迟到数据，可以认为是无法与之前正常数据join上。

小结

  • 含义：表示系统认为的当前真实事件

  • 生成：可以通过Watermark Generator 来生成

  • 传递：取上游所有 subtask 的最小值

  • 部分数据断流： idle Source

  • 迟到数据处理

03.Window

Window的基本功能和高级优化

3.1 Window - 基本功能

Window分类 - 典型的Window

  • TUMBLE Window （滚动窗口）
  • HOP Window （滑动窗口）
  • SESSION Window （会话窗口）

TUMBLE Window （滚动窗口）

这是最常见的窗口类型，就是根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中windowStart = timestamp - timestamp % windowSize，这条数据所属的window就是[windowStart, windowStart + windowSize)

窗口划分：

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

窗口触发：

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

2.png

HOP Window （滑动窗口）

窗口划分：

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

SESSION Window （会话窗口）

会话窗口跟上面两种窗口区别比较大，上面两个窗口的划分，都是根据当前数据的时间就可以直接确定它所属的窗口。会话窗口的话，是一个动态merge的过程。一般会设置一个会话的最大的gap，比如10min。

那某个key下面来第一条数据的时候，它的window就是 [event_time, event_time + gap)，当这个key后面来了另一条数据的时候，它会立即产生一个窗口，如果这个窗口跟之前的窗口有overlap的话，则会将两个窗口进行一个merge，变成一个更大的窗口，此时需要将之前定义的timer取消，再注册一个新的timer。

所以会话窗口要求所有的聚合函数都必须有实现merge。

窗口划分：

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

3.png

迟到数据处理

  • 怎么定义迟到？

    • watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。
    • ！注意：不是数据的时间晚于watermark就算是迟到，而是它所属的窗口已经被触发了，才算迟到。
    • 也就是window end 比当前的watermark小，说明窗口已经触发了计算了，这条数据会被认为是迟到数据。

  • 处理方法

    • Allow lateness

      • 设置一个允许迟到的时间

      • 适用于 DataStream、 SQL

    • SideOutput（测流输出）

      • 把迟到的数据转变成一个单独的流，再由用户自己来决定如何处理这部分数据
      • 适用于 DataStream

增量计算 VS 全量计算

  • 增量计算：每条数据到来后，直接参与计算（但是还不需要输出结果）

  • 全量计算：每条数据到来后，先放到一个buffer中，这个buffer会存储到状态里，直到窗口触发输出的时候，才把所有数据拿出来统一进行计算

EMIT触发

上面讲到，正常的窗口都是窗口结束的时候才会进行输出，比如一个1天的窗口，只有到每天结束的时候，窗口的结果才会输出。这种情况下就失去了实时计算的意义了。

那么EMIT触发就是在这种情况下，可以提前把窗口内容输出出来的一种机制。比如我们可以配置一个1天的窗口，每隔5s输出一次它的最新结果，那这样下游就可以更快的获取到窗口计算的结果了。

小结

  • 三种窗口
  • 迟到数据处理
  • 增量计算和全量计算模型
  • EMIT 触发提前输出窗口的结果

3.2 window - 高级优化

Mini-batch 优化

为了降低访问状态的开销，我们可以通过降低状态访问频率的方式来解决，这就是mini-batch最主要解决的问题：积攒一小批数据再进行计算，这批数据每个key的state访问只有一次，这样在单个key的数据比较集中的情况下，对于状态访问可以有效的降低频率，最终提升性能。

mini-batch看似简单，实际上设计非常巧妙。假设用最简单的方式实现，那就是每个算子内部自己进行攒一个小的batch，这样的话，如果上下游串联的算子比较多，任务整体的延迟就不是很容易控制。所以真正的mini-batch实现，是复用了底层的watermark传输机制，通过watermark事件来作为mini-batch划分的依据，这样整个任务中不管串联的多少个算子，整个任务的延迟都是一样的，就是用户配置的delay时间。

5.png

Local-global

local-global优化是分布式系统中典型的优化，主要是可以降低数据shuffle的量，同时也可以缓解数据的倾斜。

所谓的local-global，就是将原本的聚合划分成两阶段：

  • 第一阶段先做一个local的聚合，这个阶段不需要数据shuffle，是直接跟在上游算子之后进行处理的；
  • 第二个阶段是要对第一个阶段的结果做一个merge（还记得上面说的session window的merge么，这里要求是一样的。如果存在没有实现merge的聚合函数，那么这个优化就不会生效）。

如下图所示，比如是要对数据做一个sum，同样颜色的数据表示相同的group by的key，这样我们可以再local agg阶段对他们做一个预聚合；然后到了global阶段数据倾斜就消除了。

6.png

Pane优化

  • 问题：上面所述，一条数据可能会属于多个window。所以这种情况下同一个key下的window数量可能会比较多。

    • 比如3个小时的窗口，1小时的滑动的话，每条数据到来会直接对着3个窗口进行计算和更新。这样对于状态访问频率是比较高的，而且计算量也会增加很多。

  • 优化方法：将窗口的状态划分成更小粒度的pane

    • 比如上面3小时窗口、1小时滑动的情况，可以把pane设置为1h，这样每来一条数据，我们就只更新这条数据对应的pane的结果就可以了。当窗口需要输出结果的时候，只需要将这个窗口对应的pane的结果merge起来就可以了。

      7.PNG

小结

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

04.案例分析

4.1案例一：计算实时抖音DAU曲线

DAU(Daily Active User)：指的是每天的去重活跃用户数

输出：每个5s更新一下当前的DAU数值，最终获得一天内的DAU变化曲线

滚动窗口+EMIT 用到倾斜优化

两段聚合：第一轮将数据打散，根据uid分桶再求和，第二轮对各个分桶的结果求和

4.2 案例二：计算大数据任务的资源使用

通过会话窗口将数据划分到一个window中，然后再将结果求和即可

参考：【大数据专场 学习资料二】第四届字节跳动青训营 - 掘金 (juejin.cn)

avatar
文章
阅读
粉丝