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

04 流计算中的 Window 计算

了解实时计算和批式计算的本质区别，以及实时计算所带来的新的机遇和挑战
了解实时计算中的核心功能:Watermark机制、Window机制
了解3大基本窗口类型的定义、使用以及核心原理
了解窗口机制中的最核心的优化及其原理
以上学习内容均会结合最前沿的企业实践进行讲解

1、概述

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

1.1流式计算VS 批式计算

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

1.2批处理

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

1.2小时级批计算

**缺点：**比较消耗资源，数据产生到计算完成在1个小时内很多场景做不到

如何做到更实时?？>>>处理时间窗口

1.3处理时间窗口

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

1.4处理时间VS事件时间

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

流式窗口的挑战：处理时间与事件时间之间存在延迟，如何去处理

1.5 事件时间窗口

实时计算∶事件时间窗口数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。什么时候窗口才算结束呢?>>>Watermark

1.6 Watermark

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

1.7 小结

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

2、Watermark

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

2.1什么是Watermark ?

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

2.2如何产生Watermark ?

减去固定时间

2.4如何通过Flink UI观察Watermark ?

2.5 典型问题一

Per-partition Vs per-subtask watermark生成 Per-subtask watermark生成早期版本都是这种机制。典型的问题是如果一个source subtask消费多个partition，那么多个partition 之间的数据读取可能会加剧乱序程度。 Per-partition watermark生成新版本引入了基于每个partition单独的 watermark生成机制，这种机制可以有效避免上面的问题。

2.6典型问题二

部分partition/subtask断流根据上面提到的watermark传递机制，下游 subtask 会将上游所有subtask的 watermark值的最小值作为自身的 watermark值。如果上游有一个 subtask 的 watermark 不更新了，则下游的watermark都不更新。解决方案:Idle source 当某个 subtask断流超过配置的 idle 超时时间时，将当前subtask置为idle，并下发一个idle 的状态给下游。下游在计算自身 watermark 的时候，可以忽略掉当前是idle的那些subtask.

2.7典型问题三

迟到数据处理因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。算子自身来决定如何处理迟到数据︰

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

2.8 Watermark 小结

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

Window基本功能和高级优化。

3.1 Window分类

典型的Window :

Tumble Window（滚动窗口)
Sliding Window（滑动窗口)
Session Window(会话窗口)

其它Window :

全局 Window
Count Window
累计窗口

3.1滚动窗口

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

3.1滑动窗口

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

3.1会话窗口

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

3.1迟到数据处理

怎么定义迟到?

一条数据到来后，会用 WindowAssigner给它划分一个 window，一般时间窗口是一个时间区间，比如[10:00,11:00)，如果划分出来的window end 比当前的 watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。

什么情况下会产生迟到数据?

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

迟到数据默认处理?

丢弃

3.1迟到数据处理

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

3.1增量VS全量计算

增量计算: -每条数据到来，直接进行计算，window只存储计算结果。比如计算sum，状态中只需要存储sum的结果，不需要保存每条数据。 -典型的reduce、aggregate等函数都是增量计算- SQL中的聚合只有增量计算全量计算∶ -每条数据到来，会存储到window的state中。等到 window触发计算的时候，将所有数据拿出来一起计算。-典型的process函数就是全量计算

3.1 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}

3.1 小结

1．三种（滚动、滑动、会话）窗口的定义

2．迟到数据处理:AllowLateness、SideOutput

3．增量计算和全量计算模型

4．EMIT触发提前输出窗口的结果

3.2 高级优化

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

04、案例分析

4.1 抖音DAU 实时曲线计算

如何去实现日活曲线的展示？

滚动窗口

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 TUNMBLE(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

4.2大数据任务资源使用实时统计分析

问题描述: 大数据任务（特指离线任务）运行时通常会有多个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)

05 总结

5.1 课程总结

第一部分介绍了流式计算基本概念，以及和批式计算的区别
第二部分介绍了watermark的含义、如何生成、如何传递，以及如何处理部分partition断流的问题
第三部分介绍了三种基本的window的定义，以及迟到数据处理、增量计算VS全量计算、EMIT输出;同时也介绍了local-global优化、mini-batch优化、distinct状态优化、滑动窗口的pane的优化等
两个案例介绍滚动窗口、会话窗口，以及两阶段聚合解决倾斜问题

5.2 个人总结

本节课第一部分为我们介绍流式计算和批式计算的对比，以及慢慢的批式计算到流式计算的优化转换去适应使用场景，最后引出第二部分内容

批处理=>小时级批计算(消耗资源且数据处理与计算一些案例不适用)=>处理窗口事件（流式计算）=>watermark

第二部分主要介绍了watermark的相关知识，以及介绍了3个案例（读取乱序、数据断流、迟到数据处理（Window算子是丢弃;Join算子认为跟之前的数据无法join到））去分析watermark可能遇到的问题，然后提出解决方案；

第三部分为我们先简单介绍了windows的分类区别，然后为我们介绍了迟到数据的处理（默认丢弃，AllowLateness、SideOutput），增量计算VS全量计算，以及Emit触发（提前计算）；然后就是讲解一些window的高级优化（后续整理）

第四部分为我们讲了两个案例，分别为计算日活，这里使用的是滚动窗口，第二个大数据任务资源使用实时统计分析，这个使用场景适合使用会话窗口，

在本节内容中，我对window的高级优化还掌握理解，后续需要去查看相关知识，补全漏洞，然后对于3中窗口的应用场景使用不够熟练，在第二个案例中没有想到会话窗口，需要对3种窗口加深理解，掌握其优点以及如何去处理相关场景

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

04 流计算中的 Window 计算

1、概述

1.1流式计算VS 批式计算

1.2批处理

1.2小时级批计算

1.3处理时间窗口

1.4处理时间VS事件时间

1.5 事件时间窗口

1.6 Watermark

1.7 小结

2、Watermark

2.1什么是Watermark ?

2.2如何产生Watermark ?

2.4如何通过Flink UI观察Watermark ?

2.5 典型问题一

2.6典型问题二

2.7典型问题三

2.8 Watermark 小结

Window基本功能和高级优化。

3.1 Window分类

3.1滚动窗口

3.1滑动窗口

3.1会话窗口

3.1迟到数据处理

3.1迟到数据处理

3.1增量VS全量计算

3.1 EMIT触发

3.1 小结

3.2 高级优化

04、案例分析

4.1 抖音DAU 实时曲线计算

4.2大数据任务资源使用实时统计分析

05 总结

5.1 课程总结

5.2 个人总结