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

课程内容目录及简要回顾：

课程内容目录

1. 概述（流VS批，处理时间VS事件时间等）
2. Watermark
3. Window（核心）
4. 相关案例分析

简要回顾

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

课后思考题

1. 复习实时计算产生的背景，与离线计算最主要的区别，以及流式窗口计算的最大挑战

   • 实时计算产生的背景：在某些特定业务或场景中，我们希望实时得到系统状态的统计信息，这是采用批量框架难以实现的。

   • 实时计算与离线计算最主要的区别：数据处理单位（数据块与具体数据的区别）、 数据源（有限数据与无限数据的区别） 、任务类型（短任务与长任务的区别）。

   注：离线=批量？实时=流式？
   实时与离线是相较数据处理的延迟而言的，批量和流式是相较数据处理的方式而言的。两者并没有必然的关系。事实上Spark streaming就是采用小批量（batch）的方式来实现实时计算。（详情请戳这）

   • 流式窗口计算的最大挑战：1. 在线环境下的资源调度； 2. 节点依赖环境下的容错策略（详情请戳这）

2. watermark的产生、传递、使用原理，以及在各种断流或者上游出现问题的情况下应该如何处理

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

   传递：类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。

   使用原理：watermark作为数据流中的一部分在Stream中流动， 并携带time stamp。 一个WaterMark(t) 表明在流中处理的EventTime已经到达了t， 那么在流中就不会再有Event Time小于 t的时间产生了。（用于处理乱序事件）

   （在无法保证多个分区的数据一定有序的情况下，我们需要有个机制（即watermark）来保证一个特定的时间后，必须触发window去进行计算。）

3. 三种基本的window的功能和原理

   TUMBLE Window （滚动窗口） （根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中，每条数据只属于一个窗口）

   HOP Window （滑动窗口） （根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中，每条数据可能会属于多个窗口）

   SESSION Window （会话窗口）（动态merge过程，一条数据一个窗口，不同窗口之间有交集需要merge）

4. window的基本功能扩展有哪些
   在某些特定情况下或在某些典型问题的解决需要以下功能：
   迟到数据处理 （1.side output：用户自己决定如何处理迟到数据；2.直接drop掉）
   增量计算 VS 全量计算 （增量计算每条数据直接参与计算，全量计算数据等到窗口触发输出时再统一计算）
   EMIT触发（可以提前把窗口内容输出出来，一个典型的retract的场景）

5. 四种高级的window的优化分别是为了解决什么问题，又是什么原理
   Mini-batch（解决频繁访问状态的问题）
   Local-global（解决倾斜问题）
   Distinct状态复用（降低状态量）
   滑动窗口pane复用（降低滑动窗口的状态存储量）

参考文献：
“实时计算And 离线计算，都是计算啊，区别搁哪呢”（
链接：zhuanlan.zhihu.com/p/42783335 ）
“大数据流式计算存在的挑战”（链接：zhuanlan.zhihu.com/p/82727703）
“学习资料二” （链接：juejin.cn/post/712390…