流式计算中的 Window 计算

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

1.流计算基本概念

1.流式计算概述

在传统的数据处理流程中，总是先收集数据，然后将数据放到数据库中。当人们需要的时候通过数据库对数据做查询，得到答案或进行相关的处理。这样看起来虽然非常合理，但是结果却非常的紧凑，尤其是在一些实时搜索应用环境中的某些具体问题，类似于MapReduce方式的离线处理并不能很好地解决问题。这就引出了一种新的数据计算结构---流计算方式。它可以很好地对大规模流动数据在不断变化的运动过程中实时地进行分析，捕捉到可能有用的信息，并把结果发送到下一计算节点。

2.流式计算VS批式计算

3.批处理概念

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

4.小时级批处理

将调度级别下降到小时级，每小时一次调度，理论上可以实现更实时的数仓，但是每次周期处理调度外还有申请、释放等过程，比较消耗资源。
一般线上数仓任务，计算时间从几分钟到几小时不等，分布不均匀，数仓的建模是分层的，三层五层甚至七层都存在，若所有的数据从产生到计算完成都要求在一个小时内，在很多场景下是做不到的。

5.处理时间窗口

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

6.处理时间VS事件时间

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

7.事件时间窗口

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

8.Watermark

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

9.小结

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

2. Watermark

1.Watermark概述

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

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

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

2.Watermark典型问题

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

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

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

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

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

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

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

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

3. Window

1.Window分类

典型的Window：

Tumble Window(滚动窗口)：每个key单独划分，每条数据只会属于一个窗口，Window结束时间到达的时候一次性触发。
Sliding Window(滑动窗口)：每个key单独划分，每条数据可能会属于多个窗口，Window结束时间到达的时候一次性触发。
Session Window(会话窗口)：每个key单独划分，每条数据会单独划分一个窗口，如果Window之间有交集，则会对窗口进行merge，Window结束时间到达的时候一次性触发。其他Window：
全局Window
Count Window
累计窗口

2.滚动窗口详情

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

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

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

3.滑动窗口详情

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

4.会话窗口详情

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

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

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

4.迟到数据的处理

1.迟到数据定义

一条数据到来后，会用WindowAssigner给它划分一个window，一般时间窗口是一个时间区间，如果划分出来的window end比当前的watermark值还要小，说明这个窗口已经触发了，这条数据就是迟到数据。只有事件时间下才会有迟到的数据。迟到数据默认丢弃。

2.迟到数据的处理方式

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

适用于：DataStream、SQL

SideOutput（侧输出流）这种方式需要对迟到数据打一个 tag，然后在 DataStream 上根据这个 tag 获取到迟到数据流，然后业务层面自行选择进行处理。

适用于：DataStream

3.增量计算 VS 全量计算

增量计算：

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

全量计算：

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

4.EMIT 触发

EMIT定义：

通常来讲，Window 都是在结束的时候才能输出结果，比如 1h 的 tumble window，只有在 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）

5.Window 高级优化

1.Mini-batch

一般来讲，Flink的状态比较大一些都推荐使用rocksdb statebackend，这种情况下，每次的状态访问就都需要做一次序列化和反序列化，这种开销还是挺大的。为了降低这种开销，我们可以通过降低状态访问频率的方式来解决，这就是mini-batch最主要解决的问题：即赞一小批数据再进行计算，这批数据每个key的state访问只有一次，这样在单个key的数据比较集中的情况下，对于状态访问可以有效的降低频率，最终提升性能。

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

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

2.Local-global

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

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

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

3.Distinct状态复用

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

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

4.滑动窗口pane复用

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

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

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

6. 案例分析

1.需求一：使用Flink SQL 计算抖音的日活曲线

SELECT 
    COUNT(DISTINCT uid) as dau 
    TUMBLE_START(event_time, INTERVAL '1' DAY) as wstart, 
    LOCALTIMESTAMP AS current_ts 
FROM user_activity 
GROUP BY 
    TUMBLE(event_time, INTERVAL '1' DAY)

table. exec. emit. early-fire. enabled=true
table. exec. emit. early-fire. delay=5min

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

SELECT 
    SUM（partial_cnt）as dau 
    TUMBLE_START（event_time，INTERVAL'1'DAY）as wstart，
    LOCALTIMESTAMP as current_ts 
FROM（
    SELECT 
        COUNT（DISTINCT uid）as partial_cnt，
        TUMBLE_ROWTIME（event_time，INTERVAL'1'DAY）as event_time 
    FROM user_activity 
    GROUP BY 
        TUMBLE（event_time，INTERVAL，'1'DAY），
        MOD（uid，10000）--根据uid分为10000个桶
)
GROUP BY TUMBLE（event_time，INTERVAL'1'DAY）

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

SELECT 
    application_id 
    SUM(cpu_usage)as cpu_total 
    SUM(memory_usage)as memory_total, 
FROM resource_usage 
GROUP BY 
    application_id, 
    SESSION(event_time,INTERVAL '10'MINUTE)

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

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