这是我参与「第四届青训营 」笔记创作活动的第16天
流式与批式计算
1.流式计算 VS 批式计算
大数据的计算模式主要有：
- 批量计算(batch computing)
- 流式计算(stream computing)
- 交互计算(interactive computing)
- 图计算(graph computing)
其中，流式计算和批量计算是两种主要的大数据计算模式，分别适用于不同的大数据应用场景。
- 流数据（或数据流）是指在时间分布和数量上无限的一系列动态数据集合体，数据的价值随着时间的流逝而降低，因此必须实时计算给出秒级响应。
- 流式计算，就是对数据流进行处理，是实时计算。
- 批量计算则统一收集数据，存储到数据库中，然后对数据进行批量处理的数据计算方式。
流计算与批计算的区别主要体现在以下几个方面：
- 数据时效性不同：流式计算实时、低延迟， 批量计算非实时、高延迟。
- 数据特征不同：流式计算的数据一般是动态的、没有边界的，而批处理的数据一般则是静态数据。
- 应用场景不同：流式计算应用在实时场景，时效性要求比较高的场景，如实时推荐、业务监控...批量计算一般说批处理，应用在实时性要求不高、离线计算的场景下，数据分析、离线报表等。
- 运行方式不同，流式计算的任务持续进行的，批量计算的任务则一次性完成。
2.批处理
- 批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。
- 通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。
- 批处理模式中使用的数据集通常符合下列特：
- 有界：批处理数据集代表数据的有限集合
- 持久：数据通常始终存储在某种类型的持久存储位置中
- 大量：批处理操作通常是处理极为海量数据集的唯一方法
3.处理时间窗口
- 实时计算:处理时间窗口
- 数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
4.处理时间和事件事件
- 处理时间:数据在流式计算系统中真正处理时所在机器的当前时间。
- 事件时间:数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。
在事件发生之后，生成的数据被收集起来，首先进入分布式消息队列，然后被 Flink 系统中的 Source 算子读取消费，进而向下游的转换算子（窗口算子）传递，最终由窗口算子进行计算处理。
5.事件处理时间窗口
- 实时计算:事件时间窗口
- 数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序。
6.WaterMark
在数据中插入一些watermark，来表示当前的真实时间。
在数据存在乱序的时候， watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡。
小结
- 批式计算一般是T+1的数仓架构
- 数据实时性越高，数据的价值越高
- 实时计算分为处理时间和事件时间
- 事件时间需要Watermark配合来处理乱序
WaterMark
1.什么是水位线WaterMark
在数据流中加入一个时钟标记，记录当前的事件时间；这个标记可以直接广播到下游，当下游任务收到这个标记，就可以更新自己的时钟了。由于类似于水流中用来做标志的记号，在 Flink 中，这种用来衡量事件时间（Event Time）进展的标记，就被称作“水位线”（Watermark）。表示系统认为的当前真实的事件时间。具体实现上，水位线可以看作一条特殊的数据记录，它是插入到数据流中的一个标记点，主要内容就是一个时间戳，用来指示当前的事件时间。而它插入流中的位置，就应该是在某个数据到来之后；这样就可以从这个数据中提取时间戳，作为当前水位线的时间戳了。
每个事件产生的数据，都包含了一个时间戳，我们直接用一个整数表示。这里没有指定单位，可以理解为秒或者毫秒（方便起见，下面讲述统一认为是秒）。当产生于2 秒的数据到来之后，当前的事件时间就是 2 秒；在后面插入一个时间戳也为 2 秒的水位线，随着数据一起向下游流动。而当 5 秒产生的数据到来之后，同样在后面插入一个水位线，时间
戳也为 5，当前的时钟就推进到了 5 秒。这样，如果出现下游有多个并行子任务的情形，我们只要将水位线广播出去，就可以通知到所有下游任务当前的时间进度了。
水位线的特性：
- 水位线是插入到数据流中的一个标记，可以认为是一个特殊的数据
- 水位线主要的内容是一个时间戳，用来表示当前事件时间的进展
- 水位线是基于数据的时间戳生成的
- 水位线的时间戳必须单调递增，以确保任务的事件时间时钟一直向前推进
- 水位线可以通过设置延迟，来保证正确处理乱序数据
- 一个水位线 Watermark(t)，表示在当前流中事件时间已经达到了时间戳 t, 这代表 t 之前的所有数据都到齐了，之后流中不会出现时间戳 t’ ≤ t 的数据
2.如何生成WaterMark
在 Flink 的 DataStream API 中 ， 有 一 个 单 独 用 于 生 成 水 位 线 的 方法：.assignTimestampsAndWatermarks()，它主要用来为流中的数据分配时间戳，并生成水位线来指示事件时间：
public SingleOutputStreamOperator<T> assignTimestampsAndWatermarks( WatermarkStrategy<T> watermarkStrategy)
具体使用时，直接用 DataStream 调用该方法即可，与普通的 transform 方法完全一样。
DataStream<Event> stream = env.addSource(new ClickSource()); DataStream<Event> withTimestampsAndWatermarks = stream.assignTimestampsAndWatermarks(<watermark strategy>);
3.如何传递WaterMark
如果一个任务收到了来自上游并行任务的不同的水位线，说明上游各个分区处理得有快有慢，进度各不相同比如上游有两个并行子任务都发来了水位线，一个是 5 秒，一个是 7 秒；这代表第一个并行任务已经处理完 5 秒之前的所有数据，而第二个并行任务处理到了 7 秒。那这时自己的时钟怎么确定呢？当然也要以“这之前的数据全部到齐”为标准。如果我们以较大的水位线 7 秒作为当前时间，那就表示“7 秒前的数据都已经处理完”，这显然不是事实——第一个上游分区才处理到 5 秒，5~7 秒的数据还会不停地发来；而如果以最小的水位线 5 秒作为当前时钟就不会有这个问题了，因为确实所有上游分区都已经处理完，不会再发 5 秒前的数据了。这让我们想到“木桶原理”：所有的上游并行任务就像围成木桶的一块块木板，它们中最短的那一块，决定了我们桶中的水位。
4.部分partition/subtask断流
根据上面提到的watermark传递机制，下游subtask会将上游所有subtask的 watermark值的最小值作为自身的 watermark值。如果上游有一个subtask的 watermark不更新了，则下游的watermark都不更新。
解决方案:ldle source
当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle，并下发一个idle的状态给下游。下游在计算自身 watermark的时候，可以忽略掉当前是idle的那些subtask。
5.迟到数据处理
因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。 算子自身来决定如何处理迟到数据:
- Window聚合，默认会丢弃迟到数据
- 双流join，如果是outer join，则可以认为它不能join到任何数据
- CEP，默认丢弃
Window
1.窗口的概念
Flink 是一种流式计算引擎，主要是来处理无界数据流的，数据源源不断、无穷无尽。想 要更加方便高效地处理无界流，一种方式就是将无限数据切割成有限的“数据块”进行处理，这就是所谓的“窗口”（Window）。
在 Flink 中，窗口其实并不是一个“框”，流进来的数据被框住了就只能进这一个窗口。相比之下，我们应该把窗口理解成一个“桶”。在 Flink 中，窗口可以把流切割成有限大小的多个“存储桶”（bucket)；每个数据都会分发到对应的桶中，当到达窗口结束时间时，就对每个桶中收集的数据进行计算处理。
2.窗口分类
典型的Window:
- Tumble Window(滚动窗口)
- Sliding Window (滑动窗口)
- Session Window(会话窗口)
其它Window:
- 全局 Window
- Count Window
- 累计窗口
- .......
滚动窗口
窗口划分:
- 每个key单独划分
- 每条数据只会属于一个窗口
窗口触发: Window结束时间到达的时候一次性触发
小圆点表示流中的数据，我们对数据按照 userId 做了分区。当固定了窗口大小之后，所有分区的窗口划分都是一致的；窗口没有重叠，每个数据只属于一个窗口。
滚动窗口应用非常广泛，它可以对每个时间段做聚合统计，很多 BI 分析指标都可以用它
来实现。
滑动窗口
窗口划分:
- 每个key单独划分
- 每条数据可能会属于多个窗口
窗口触发: Window结束时间到达的时候一次性触发
在一些场景中，可能需要统计最近一段时间内的指标，而结果的输出频率要求又很高，甚
至要求实时更新，比如股票价格的 24 小时涨跌幅统计，或者基于一段时间内行为检测的异常报警。这时滑动窗口无疑就是很好的实现方式。
会话窗口
窗口划分:
- 每个key单独划分
- 每条数据会单独划分为一个窗口，如果window之间有交集,则会对窗口进行merge
窗口触发: Window结束时间到达的时候一次性触发
3.迟到数据处理
怎么定义迟到?
一条数据到来后，会用WindowAssigner给它划分一个window，一般时间窗口是一个时间区间，比如[10:00,11:00)，如果划分出来的window end 比当前的 watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。
什么情况下会产生迟到数据?
只有事件时间下才会有迟到的数据。
迟到数据默认处理?
丢弃
1.Allow lateness
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
适用于:DataStream、SQL
2.SideOutput(侧输出流)
这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理。
适用于:DataStream
4.增量计算和全量计算
增量计算:
- 每条数据到来，直接进行计算,window只存储计算结果。比如计算sum，状态中只需要存诸sum的结果，不需要保存每条数据。
- 典型的reduce、aggregate等函数都是增量计算
- SQL中的聚合只有增量计算
全量计算:
- 动每条数据到来，会存储到window的state中。等到
- window触发计算的时候，将所有数据拿出来一起计算。
- 典型的process函数就是全量计算
5.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}
小结
- 三种（滚动、滑动、会话)窗口的定义
- 迟到数据处理: AllowLateness、SideOutput
- 增量计算和全量计算模型
- EMIT触发提前输出窗口的结果
