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

阿狸啦啦啦
83 阅读12分钟

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

流式计算中的 Window 计算

1.概述

1.1.流批对比

image.png

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

1.2.批处理

  • 批处理模型的典型数仓架构：T+1架构，即数据计算时间是天级别的，当天只能看到前一天的计算结果

  • 常用计算引擎：Hive、Spark

  • 计算的时候，数据是完全ready的，输入输出都是确定性的

  • 如何让批处理更实时？

    • 把天处理变为按小时处理。
    • 小时级批计算，资源的周期调度比较麻烦，且也会浪费资源，某业务场景做不到1h内处理完

1.3.时间

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

image.png

1.4.处理时间窗口

实时计算-处理时间窗口

数据实时流动，实时计算，窗口结束直接发结果，不用周期调度资源。

1.5.事件时间窗口

实时计算-事件时间窗口

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

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

1.6.watermark

image.png 待处理的数据窗口的值比watermark小时，认为是迟到数据，不进行处理了

1.7.小结

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

2.watermark

2.1.概念

Watermark定义：当前系统认为的事件时间所在的真实时间。

2.2.产生

Watermark产生：一般是从数据的事件时间来产生，产生策略可以灵活多样。

最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。

image.png

2.3.传递

Watermark传递，这个类似于上节课中介绍的Checkpoint的制作过程，传递就类似于Checkpoint的barrier。

 上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。

 经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。

image.png

  • window取传来的最小watermark数值
  • task有一个watermark数值，同时会给下游传递这个数值

2.4.典型问题

  • 怎么观察一个任务中的watermark是多少，是否是正常的

    • 一般通过Flink Web UI上的信息来观察当前任务的watermark情况
    • 这个问题是生产实践中最容易遇到的问题，大家在开发事件时间的窗口任务的时候，经常会忘记了设置watermark，或者数据太少，watermark没有及时的更新，导致窗口一直不能触发。

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

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

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

    • 解决方案：idle source

    • 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的，因为它要取上游subtask发来的watermark中的最小值。此时我们可以用一种IDLE状态来标记这种subtask

    • 被标记为IDLE状态的subtask，我们在计算watermark的时候，可以把它先排除在外。这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。

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

    • 对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）
    • 算子自身决定如何处理迟到数据
      • Window聚合，默认会丢弃迟到数据
      • 双流join, 如果是outer join, 则可以认为它不能join到任何数据
      • CEP，默认丢弃

2.5.小结

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

3.window

3.1.基本功能

3.1.1.window分类

  • 典型的Window:
    1. Tumble Window (滚动窗口)
    2. Sliding Window (滑动窗口)
    3. Session Window (会话窗口)
  • 其它Window:
    1. 全局Window
    2. Count Window
    3. 累计窗口

3.1.1.1.window使用

image.png

3.1.1.2.滚动窗口

在我们使用window的过程中，最容易产生的一个疑问是，window的划分是subtask级别的，还是key级别的。这里大家要记住，Flink 中的窗口划分是key级别的。 比如下方的图中，有三个key，那每个key的窗口都是单独的。所以整个图中，一种存在14个窗口。

滚动窗口是最常见的窗口类型。

它根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中。

窗口的触发，是时间大于等于window end的时候，触发对应的window的输出（计算有可能提前就增量计算好了），目前的实现是给每个window都注册一个timer，通过处理时间或者事件时间的timer来触发window的输出。

  • 窗口划分:
    1. 每个key单独划分
    2. 每条数据只会属于一个窗口
  • 窗口触发: Window结束时间到达的时候一次性触发

image.png

3.1.1.2.滑动窗口

在HOP窗口中，每条数据是可能会属于多个窗口的（具体属于多少，取决于窗口定义的大小和滑动），比如下图中假设滑动是1h的话，那窗口大小就是2h，这种情况每条数据会属于两个窗口。除了这一点之外，其它的基本跟HOP窗口是类似的，比如也是key级别划分窗口，也是靠timer进行窗口触发输出。

  • 窗口划分:
    1. 每个key单独划分
    2. 每条数据可能会属于多 个窗口
  • 窗口触发: Window结束时间到达的时候一次性触发

image.png

3.1.1.3.会话窗口

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

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

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

  • 窗口划分:
    1. 每个key单独划分
    2. 每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge
  • 窗口触发:Window结束时间到达的时候一次性触发

image.png

3.1.2.迟到数据处理

  • 定义：watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。（注意，不是数据的时间晚于watermark就算是迟到，而是它所属的窗口已经被触发了，才算迟到）。

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

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

  • 迟到数据的默认处理？

    • 丢弃
    • 其他处理

      • allow lateness

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

      • sideoutput

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

3.1.3.窗口计算模型

  • 增量计算：每条数据到来后，直接参与计算（但是还不需要输出结果）
    • 典型的reduce、aggregate等函数都是增量计算
    • SQL中的聚合函数只有哦增量计算
  • 全量计算：每条数据到来后，先放到一个buffer中，这个buffer会存储到状态里，直到窗口触发输出的时候，才把所有数据拿出来统一进行计算
    • process函数就是全量计算

3.1.4.EMIT触发机制

  • 什么叫EMIT？

    • 在window没有结束的时候，提前把window计算的部分结果输出出来

  • 怎么实现？

image.png

3.2.优化

3.2.1.mini-batch优化

mini-batch最主要解决的问题：即赞一小批数据再进行计算，这批数据每个key的state访问只有一次，这样在单个key的数据比较集中的情况下，对于状态访问可以有效的降低频率，最终提升性能。

这个优化主要是适用于没有窗口的聚合场景，字节内部也扩展了window来支持mini-batch，在某些场景下的测试结果可以节省20-30%的CPU开销。

所以真正的mini-batch实现，是复用了底层的watermark传输机制，通过watermark事件来作为mini-batch划分的依据，这样整个任务中不管串联的多少个算子，整个任务的延迟都是一样的，就是用户配置的delay时间。

下面这张图展示的是普通的聚合算子的mini-batch原理，window的mini-batch原理是一样的。

image.png

3.2.2.倾斜优化 local global

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

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

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

image.png

3.2.3.distinct状态复用

对于distinct的优化，一般批里面的引擎都是通过把它优化成aggregate的方式来处理，但是在流式window中，我们不能直接这样进行优化，要不然算子就变成会下发retract的数据了。所以在流式中，对于count distinct这种情况，我们是需要保存所有数据是否出现过这样子的一个映射。

在SQL中，我们有一种方式可以在聚合函数上添加一些filter，如下面的SQL所示：

image.png 像这种情况，我们会对同一个字段用不同的filter来进行count distinct的计算。如果每个指标都单独用一个map来记录每条数据是否出现过，那状态量是很大的。

我们可以把相同字段的distinct计算用一个map的key来存储，在map的value中，用一个bit vector来实现就可以把各个状态复用到一起了。比如一个bigint有64位，可以表示同一个字段的64个filter，这样整体状态量就可以节省很多了。

image.png

3.2.4.滑动窗口pane复用

滑动窗口如上面所述，一条数据可能会属于多个window。所以这种情况下同一个key下的window数量可能会比较多，比如3个小时的窗口，1小时的滑动的话，每条数据到来会直接对着3个窗口进行计算和更新。这样对于状态访问频率是比较高的，而且计算量也会增加很多。

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

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

image.png

avatar
文章
阅读
粉丝