👉引言💎
学习的最大理由是想摆脱平庸，早一天就多一份人生的精彩；迟一天就多一天平庸的困扰。 热爱写作，愿意让自己成为更好的人............
| 铭记于心 | ||
| 🎉✨🎉我唯一知道的，便是我一无所知🎉✨🎉 |
四、【计算】流计算中的Window计算 | 青训营笔记
概述
本课程主要分为四个部分：
- 概述流式计算跟批计算，以及实时数仓和离线数仓的区别；引出流式计算中的window计算定义以及挑战
- 介绍实时计算中的Watermark概念，以及如何产生、传递，还有一些典型的生产实践中遇到的问题
- 介绍三种最基本的window类型，以及他们的实现原理；同时会结合业务场景介绍一些高级优化的功能和原理
- 结合两个真实业务场景的需求，讲解window是如何解决实际生产问题的
课前部分主要罗列课程中涉及到的概念，方便对于流式计算或者Flink不熟悉的同学提前查询和学习；课中部分会将课程的关键思路做一个整理，帮助同学们提前了解课程节奏，更容易跟上课程的节奏；课后是一些小的思考问题，帮助同学们在课后梳理本课程的重点内容。
一、 概述
核心概念，如：
- T+1 离线计算模型
- 事件时间
- Exactly-Once/At-Least-Once
1 流式计算与批式计算
数据价值：实时性越高，数据价值越高
2 批处理
- 2.1 T+1计算模型批处理模型典型的数仓架构为T+1架构,即数据计算时天级别的,当天只能看到前一天的计算结果。
通常使用的计算引Y为Hive或者Spark等。计算的时候,数据是完全ready的，输入和输出都是确定性的。
- 2.2 小时级批计算
- 2.3处理时间窗口
- 数据实时流动,实时计算,窗口结束直接发送结果,不需要周期调度任务
- 2.4处理时间VS事件时间
处理时间:数据在流式计算系统中真正处理时所在机器的当前时间 事件时间:数据产生的时间,比如客户端、传感器、后端代码等上报数据时的时间
- 2.5 事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算,可以有效的处理数据延迟和乱序
由于数据处理 延迟时间的不确定性,那么窗口什么时候算结束呢? 此时就需要 一个新的概念:Watermark
- 2.6 Watermark
在数据中插入一些watermark,来表示当前的真实时间
在数据存在乱序的时候,watermark就比较重要了,它可以用来在乱序容忍和实时性之间做一个平衡
3 总结
- 批式计算 一般使用 T+1 的数仓架构
- 数据实时性越高 ， 数据的价值越高
- 实时计算的时间概念 分为 处理时间 和 事件时间
- 事件时间 需要Watermark 配合来处理乱序
从离线数仓到实时数仓的对比开始，从传统的大数据计算到实时计算是如何演变和过度的，以及实时计算中的核心挑战，最终引出实时计算的 Window 计算以及支撑实时计算的核心概念：Watermark
二、Watermark
本节课中也会涉及到一些基础的概念（这些概念在前面两节课中应该已经进行了讲解），比如：
- Task
- Subtask
- Operator
- Checkpoint
- Barrier
1 概述
- Watermark定义：
当前系统认为的事件时间所在的真实时间。 - Watermark产生：
一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序
- Watermark传递：
- 整个过程类似于Exactly-once语义中算子Checkpoint的制作过程，传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。
2 watermark的常见问题：
- 2.1 怎么观察一个任务中的watermark是多少，是否是正常的
- 一般通过Flink Web UI上的信息来观察当前任务的watermark情况
- 这个问题是生产实践中最容易遇到的问题，大家在开发事件时间的窗口任务的时候，经常会忘记了设置watermark，或者数据太少，watermark没有及时的更新，导致窗口一直不能触发。
- 2.2 Per-partition / Per-subtask 生成watermark的优缺点
- 在Flink里早期都是per-subtask的方式进行watermark的生成，这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
- 后期（上面图中）就逐步的变成了per-partition的方式来产生watermark，来避免上面的问题。
- 2.3 如果有部分partition/subtask会断流，应该如何处理
- 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的，因为它要取上游subtask发来的watermark中的最小值。此时我们可以用一种IDLE状态来标记这种subtask，被标记为这种状态的subtask，我们在计算watermark的时候，可以把它先排除在外。这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。
- 2.4 算子对于时间晚于watermark的数据的处理对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）
- window聚合，默认丢弃迟到数据；
- 双流join，对于迟到数据，可以认为是无法与之前正常数据join上
- CEP,默认丢弃
3 总结
Watermark表示系统认为的当前事件的真实时间,
通过Watermark Generator生成,
传递方式类似于Checkpoint barrier, 取上游所有subtask的最小值,
用IDLE source标记数据断流
对于迟到数据的处理:Window算子 是丢弃,Join算子认为 无法跟之前的数据Join到
🌹写在最后💖： 路漫漫其修远兮，吾将上下而求索！伙伴们，再见！🌹🌹🌹
