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

时迁bin
138 阅读9分钟

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

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

今天学习了课程《流计算中的Window计算》，学习的内容主要分为以下几个部分：

  • 流式计算的基本概述
  • Watermark的基本原理
  • window基本功能和高级优化
  • 案例分析

一、流式计算的基本概述

流式计算和批式计算的对比

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

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

那么如何做到实时计算？

理论上，批式计算也可以做到实时，可以做小时级批计算，这样就可以得到小时级别的数据计算，那么还能缩短到分钟级别的实时计算吗？在实际生产中，会有各种因素的存在，例如，离线处理需要调度资源，还有一个数仓可能分为几层，每一层可能会依赖上一层得到的数据，这使得批处理的是需要时间的，无法得到更实时。

那么如何做到更实时呢？

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

处理时间和事件时间：

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

事件时间窗口：

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

二、Watermark的基本原理

2.1 Watermark的基本概念

  • 什么是Watermark？

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

  • 如何产生Watermark?

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

  • Watermark是如何传递的？

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

2.2 Watermark在生产实践中经常遇到的问题

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

    • 一般通过Flink Web UI上的信息来观察当前任务的watermark的情况。
    • 在开发事件时间的窗口任务时，要是忘记设置watermark，或者数据太少，watermark没有及时更新，导致窗口一直不能触发。

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

    • Per-subtask watermark生成

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

    • Per-partition watermark生成

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

  3. 部分 partition/subtask 断流

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

    解决方案：Idle source

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

  4. 迟到数据处理

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

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

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

三、Window基本功能和高级优化

3.1 Window基本功能

3.1.1 Window的分类

典型的Window：

  • Tumble Window（滚动窗口）
  • Sliding Window（滑动窗口）
  • Session Window（会话窗口）

其他Window：

  • 全局Window
  • Count Window
  • 累计Window
  • ......

3.1.2 Tumble Window（滚动窗口）

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

  • 窗口的划分

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

  • 窗口的触发：Window结束时间到达的时候就会一次性触发

3.1.3 Sliding Window（滑动窗口）

  • 窗口的划分

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

  • 窗口的触发：Window结束时间到达的时候就会一次性触发

3.1.4 Session Window（会话窗口）

  • 窗口的划分

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

  • 窗口的触发：Window结束时间到达的时候就会一次性触发

3.1.5 迟到数据的处理

迟到数据的定义：根据上面说到的watermark原理，watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。

只有事件时间下才会有迟到的数据，迟到数据的默认处理方式是丢弃。

处理方式：

  • Allow lateness

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

  • SideOutput（侧输出流）

    这种方式需要对迟到的数据打一个标签（tag），然后再DataStream上根据这个tag获取到迟到数据流，然后业务层里面自行选择进行处理。

3.1.6 增量计算和全量计算

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

3.1.7 EMIT触发

什么是EMIT？

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

EMIT输出指的是：在window没有结束的时候，提前把window计算的部分结果输出出来。

怎么实现EMIT触发？

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

    • CONTINUE
    • FIRE（触发计算，但是不清理）
    • PURGE
    • FIRE_AND_PURGE

  • SQL中，配置：

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

3.2 Window 高级优化

3.2.1 Mini-batch

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

3.2.2 Local-global

Local-global：优化解决数据倾斜问题。

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

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

3.2.3 Distinct状态复用

Distinct状态复用降低状态量。

3.2.4 滑动窗口pane复用

Pane 优化降低滑动窗口的状态存储量。

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

四、个人总结与思考

通过本次课程，对流式计算中的窗口（window）计算有了深刻的认识，并理解了窗口计算的基本原理，但是对window高级优化方面，理解不够透彻，我想应该在实践中进行优化，这样才能比较透彻的理解其中的优化原理。

\

avatar
文章
阅读
粉丝