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

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

0 引言

1 概述

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

Input -> MR -> [小时级] -> Output

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

处理时间窗口：
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。(按照时间分割)
事件时间窗口：
数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。(按照事件分割)

事件时间需要Watermark配合来处理乱序

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

2 Watermark

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

两种产生Watermark的方式：

#SQL
CREATE TABLE Orders (
    user BIGINT,
    product STRING,
    order_time TIMESTAMP(3),
    WATERMARK FOR order_time As order_time - INTERVAL '5' SECOND
) WITH ( . . . );

#Java
WatermarkStrategy
.<Tuple2<Long,String>>forBoundedOutOfOrderness(Duration.ofSeconds(20))
.withTimestampAssigner((event, timestamp) ->event.f0);

如何传递Watermark:
Watermark 的传递方式是广播，即广播方式发送到下游。Watermark 与业务数据一样，无差别地传递下去。
多并发的场景下Watermark 是 source task 产生，经过 keyby 分组后触发窗口计算。
①Watermark 要单调递增；②如果算子有多个上游（广播）即输入多个 Watermark(T)，则该算子取最小 Watermark，即min(Watermark(T1), Watermark(T2))。

如何通过Flink UI观察 Watermark：

典型问题：

• 如果一个source subtask消费多个partition，那么多个partition之间的数据读取可能会加剧乱序程度（早期版本都是这种Per-subtask watermark生成机制）。解决方案：Per-partition watermark生成，引入了基于每个 partition单独的watermark生成机制，这种机制可以有效避免上面的问题。（小任务执行？）
• watermark传递机制中，下游subtask 会将上游所有subtask的 watermark值的最小值作为自身的watermark值。如果上游有一个subtask的watermark 不更新了，则下游的watermark都不更新（部分partition/subtask断流）。解决方案:Idle source。当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle，并下发一个idle的状态给下游。下游在计算自身 watermark 的时候，可以忽略掉当前是idle的那些subtask。（flag标志？）
• 因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据（迟到数据处理）。解决方案：算子自身来决定如何处理迟到数据，Window聚合，默认会丢弃迟到数据。双流join，如果是outer join，则可以认为它不能join到任何数据。CEP，默认丢弃。（Window聚合、双流join、CEP）

3 Window

Window分类：
典型的Window：Tumble Window(滚动窗口)、Sliding Window（滑动窗口)、Session Window(会话窗口)
其它Window：全局 Window、Count Window、累计窗口等。

Window使用:

• 滚动窗口：
  窗口划分：每个key单独划分；每条数据只会属于一个窗口
  窗口触发：Window结束时间到达的时候一次性触发

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

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

迟到数据处理：
怎么定义迟到：一条数据到来后，会用WindowAssigner给它划分一个window，一般时间窗口是一个时间区间，比如[10:00,11:00)，如果划分出来的window end 比当前的watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。
什么情况下会产生迟到数据：只有事件时间下才会有迟到的数据。
迟到数据默认处理：丢弃

• Allow lateness
  这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
  适用于:DataStream、SQL
• SideOutput(侧输出流)
  这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理。
  适用于:DataStream

final outputTag<T> lateOutputTag = new OutputTag<T>("late-data"){};
Datastream<T> input = ...;
singleoutputStreamOperator<T>result = input
.keyBy (<key selector>)
.window ( <window assigner>).allowedLateness(<time>)
.sideoutputLateData(lateoutputTag)
.<windowed transformation>( <window function>) ;
DataStream<T> lateStream = result.getSideOutput(lateOutputTag);

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

input
.keyBy (<key selector>)
.window (<window assigner>)
.reduce(new ReduceFunction<Tuple2<String,Long>>() {
    public Tuple2<String，Long> reduce(Tuple2<String,Long> v1，Tuple2<String，Long> v2){
        return new Tuple2<>(v1.f0,v1.f1 + v2.f1);
    }
});

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

input
.keyBy(t -> t.f0)
.window (TumblingEventTimewindows.of(Time.minutes(5))).process(new MyProcesswindowFunction( ));
/* ... */
public class MyProcesswindowFunction
extends ProcessWindowFunction<Tuple2<String，Long，String，String，Timewindow> {
    @override
    public void process(String key，Context context，Iterable<Tuple2<String，Long>> input) {  
    long count = 0;
    for (Tuple2<String, Long> in: input) {
        icount++;
    }
    out.collect(""window: " + context.window() + "count: " + count);)
    }
}

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}

高级优化：

• Mini-batch优化解决频繁访问状态的问题

• local-global优化解决倾斜问题

• Distinct状态复用降低状态量

SELECT
    date_time,shop_id,
    COUNT (DISTINCT item_id）AS item_col1,
    COUNT (DISTINCT item_id）FILTER(WHERE flag IN ( 'iphone')) AS item_col2,COUNT (DISTINCT item_id）FILTER （WHERE flag IN ('android')) AS item_col3,COUNT (DISTINCT item_id)FILTER （WHERE flag IN ( 'pc')) AS item_col4,
    COUNT (DISTINCT item_id)FILTER（WHERE flag IN ('wap')) AS item_col5,COUNT (DISTINCT item_id）FILTER（WHERE flag IN ( 'other')) AS item_col6,
    COUNT (DISTINCT item_id)FILTER (WHERE flag IN ( ' iphone'， 'android' )) AS item_col7,COUNT (DISTINCT item_id）FILTER(WHERE flag IN ('pc','other')) AS item_col8,
    COUNT(DISTINCT item_id)FILTER(WHERE flag IN ( 'iphone'，'android','wap' )) AS item_col9,COUNT(DISTINCT item_id)FILTER (WHERE flag IN ('iphone' ,'android','wap','pc'，'other')) AS item_col10,
    COUNT (DISTINCT visitor_id)AS visitor_col1,
    COUNT(DISTINCT visitor_id)FILTER（WHERE flag IN ('iphone')) AS visitor_col2,COUNT (DISTINCT visitor_id)FILTER（WHERE flag IN ( 'android')) AS visitor_col3,COUNT (DISTINCT visitor_id)FILTER（WHERE flag IN ( 'pc')) AS visitor_col4,
    COUNT (DISTINCT visitor_id)FILTER（WHERE flag IN ( 'wap')) AS visitor_col5,COUNT (DISTINCT visitor_id)FILTER (WHERE flag IN ( 'other')) AS visitor_col6,
    COUNT(DISTINCT visitor_id)FILTER（MHERE flag IN (' iphone' ,'android')) AS visitor_col7,COUNT(DISTINCT visitor_id)FILTER（WHERE flag IN ( 'pc','other')) AS visitor_col8,
    COUNT (DISTINCT visitor_id) FILTER (WHERE flag IN('iphone'，'android'，'wap')) AS visitor_col9,
    COUNT (DISTINCT visitor_id) FILTER (WHERE flag ITN ( 'iphone',' android'， 'wap'，'pc',' other'))AS visitor_col10
FROM logs
GROUP BY date_time, shop_id

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

4 案例分析

• 使用Flink SQL计算抖音的日活曲线:

通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可。

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_timeFROM user_activity
GROUPBY
TUMBLE(event .i..cheo.bruceMOD(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 //自定义

• 使用Flink SQL计算大数据任务的资源使用:

问题描述:大数据任务（特指离线任务)运行时通常会有多个container启动并运行每个container在运行结束的时候，YARN会负责将它的资源使用(CPU、内存)情况上报。一般大数据任务运行时间从几分钟到几小时等。

需求:根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。假设前后两个container结束时间差不超过10min。

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

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)

引用参考

1.【大数据专场 学习资料二】第四届字节跳动青训营
2. Watermark 是怎么生成和传递的？
3. [源码分析] 从源码入手看 Flink Watermark 之传播过程 --- 上
4. [源码分析] 从源码入手看 Flink Watermark 之传播过程 --- 下