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

学习了

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

参考链接：大数据专场-学习资料二

01.概述

1.1 流式计算vs批式计算

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

1.2批处理

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

1.3处理时间窗口

实时计算：处理时间窗口

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

1.4 处理时间 vs 事件时间

处理时间：数据在流式计算系统中真正处理时所在机器的当前时间

事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间

1.5 事件时间窗口

实时计算：事件时间窗口

数据实时进入到真实事件发牛的窗口中进行计算，可以有效的处理教据延迟和乱序。

1.6 Watermark

在数据中插入一些watermark，来去示当前的真实时问。

在数据存在乱序的时候,watermark 就比较重要了，它可以用来在乱序容忍和实时性之问做一个平衡。

01.小结

1．批式计算一般是T+1的数仓架构

2．数据实时性越高，数据的价值越高

3．实时计算分为处理时间和事件时间

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

核心机制：watermark机制 window机制

02.Watermark

Watermark定义：系统认为的事件时间所在的真实时间。

Watermark产生：一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。 Watermark传递：这个类似于Checkpoint的制作过程，传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。

一些问题：

• 怎么观察一个任务中的watermark是多少，是否是正常的

  • 一般通过Flink Web UI上的信息来观察当前任务的watermark情况
  • 这个问题是生产实践中最容易遇到的问题，大家在开发事件时间的窗口任务的时候，经常会忘记了设置watermark，或者数据太少，watermark没有及时的更新，导致窗口一直不能触发。

• Per-partition / Per-subtask 生成watermark的优缺点

  • 在Flink里早期都是per-subtask的方式进行watermark的生成，这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话，那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
  • 后期（上面图中）就逐步的变成了per-partition的方式来产生watermark，来避免上面的问题。

• 如果有部分partition/subtask会断流，应该如何处理

  • 数据断流是很常见的问题，有时候是业务数据本身就有这种特点，比如白天有数据，晚上没有数据。在这种情况下，watermark默认是不会更新的，因为它要取上游subtask发来的watermark中的最小值。此时我们可以用一种IDLE状态来标记这种subtask，被标记为这种状态的subtask，我们在计算watermark的时候，可以把它先排除在外。这样就可以保证有部分partition断流的时候，watermark仍然可以继续更新。

• 算子对于时间晚于watermark的数据的处理

  • 对于迟到数据，不同的算子对于这种情况的处理可以有不同的实现（主要是根据算子本身的语义来决定的）
  • 比如window对于迟到的数据，默认就是丢弃；比如双流join，对于迟到数据，可以认为是无法与之前正常数据join上。

• 2. Watermark 小结

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

03.window机制

3.1 基本功能

3大基本窗口

1. Tumble Window(滚动窗口)
2. Sliding Window(滑动窗口)
3. Session Window(会话窗口)

滚动窗口

窗口划分：

1.每个key单独划分

2.每条数据只会属于一个窗口

窗口触发：window结束时间到达的时候一次性

滑动窗口

1.每个key单独划分

2.每条数据可能会属于多个窗口

窗口触发：window结束时间到达的时候一次性触发

会话窗口

窗口划分:

1.每个key单独划分

2.每条数据会单独划分为一个窗口,如果window之问有交集,则会对窗口进行merge

窗口触发:

Window结束时问到达的时候一次性触发

迟到数据处理

迟到数据？：watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。（注意，不是数据的时间晚于watermark就算是迟到，而是它所属的窗口已经被触发了，才算迟到）。

什么情况下产生？：只有事件时间才会有迟到的数据

默认处理方式：丢弃

1.Allow lateness

这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。

适用于: DataStream、SQL

2.SideOutput(侧输出流)

这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理。

适用于:DataStream

增量vs全量计算

• 增量计算：每条数据到来后，直接参与计算，windows只存储计算结果（但是还不需要输出结果）
  • SQL中的聚合只有增量计算
  • 典型的reduce、aggregate等函数都是增量计算

• 全量计算：每条数据到来后，先放到一个buffer中，这个buffer会存储到状态里，直到窗口触发输出的时候，才把所有数据拿出来统一进行计算
  • 典型的process函数就是全量计算

在SQL里面，主要是窗口聚合，所以都是可以增量计算的，也就是每条数据来了之后都可以直接进行计算，而不用把数据都存储起来。举个例子，比如要做sum计算，那每来一条数据，就直接把新的数据加到之前的sum值上即可，这样我们就只需要存储一个sum值的状态，而不需要存储所有buffer的数据，状态量会小很多。

DataStream里面要用增量计算的话，需要用reduce/aggregate等方法，就可以用到增量计算。如果用的是process接口，这种就属于是全量计算。

EMIT触发

EMIT触发就是在这种情况下，可以提前把窗口内容输出出来的一种机制。比如我们可以配置一个1天的窗口，每隔5s输出一次它的最新结果，那这样下游就可以更快的获取到窗口计算的结果了。

emit的场景就是一个典型的retract的场景，发送的结果类似于+[1], -[1], +[2], -[2], +[4]这样子。这样才能保证window的输出的最终结果是符合语义的。

3.1 小结

     1.三种(滚动、滑动、会话)窗口的定义
     2.迟到数据处理:AllowLateness.SideOutput
     3.增量计算和全量计算模型
     4.EMIT 触发提前输出窗口的结果

3. 2 window-高级优化

以下说的所有的高级优化，都只限于在SQL中的window中才有。在DataStream中，用户需要自己通过代码来实现类似的能力。

Mini-batch优化

一般来讲，Flink的状态比较大一些都推荐使用rocksdb statebackend，这种情况下，每次的状态访问就都需要做一次序列化和反序列化，这种开销还是挺大的。为了降低这种开销，我们可以通过降低状态访问频率的方式来解决，这就是mini-batch最主要解决的问题：即攒一小批数据再进行计算，这批数据每个key的state访问只有一次，这样在单个key的数据比较集中的情况下，对于状态访问可以有效的降低频率，最终提升性能。

这个优化主要是适用于没有窗口的聚合场景，字节内部也扩展了window来支持mini-batch，在某些场景下的测试结果可以节省20-30%的CPU开销。

这张图展示的是普通的聚合算子的mini-batch原理，window的mini-batch原理是一样的。

倾斜优化 Local-global

local-global优化是分布式系统中典型的优化，主要是可以降低数据shuffle的量，同时也可以缓解数据的倾斜。

所谓的local-global，就是将原本的聚合划分成两阶段，第一阶段先做一个local的聚合，这个阶段不需要数据shuffle，是直接跟在上游算子之后进行处理的；第二个阶段是要对第一个阶段的结果做一个merge（还记得上面说的session window的merge么，这里要求是一样的。如果存在没有实现merge的聚合函数，那么这个优化就不会生效）。

如下图所示，比如是要对数据做一个sum，同样颜色的数据表示相同的group by的key，这样我们可以再local agg阶段对他们做一个预聚合；然后到了global阶段数据倾斜就消除了。

Distinct计算状态复用

对于distinct的优化，一般批里面的引擎都是通过把它优化成aggregate的方式来处理，但是在流式window中，我们不能直接这样进行优化，要不然算子就变成会下发retract的数据了。所以在流式中，对于count distinct这种情况，我们是需要保存所有数据是否出现过这样子的一个映射。

在SQL中，我们有一种方式可以在聚合函数上添加一些filter，如下面的SQL所示：

像这种情况，我们会对同一个字段用不同的filter来进行count distinct的计算。如果每个指标都单独用一个map来记录每条数据是否出现过，那状态量是很大的。

我们可以把相同字段的distinct计算用一个map的key来存储，在map的value中，用一个bit vector来实现就可以把各个状态复用到一起了。比如一个bigint有64位，可以表示同一个字段的64个filter，这样整体状态量就可以节省很多了。

滑动窗口pane复用

滑动窗口如上面所述，一条数据可能会属于多个window。所以这种情况下同一个key下的window数量可能会比较多，比如3个小时的窗口，1小时的滑动的话，每条数据到来会直接对着3个窗口进行计算和更新。这样对于状态访问频率是比较高的，而且计算量也会增加很多。

优化方法就是，将窗口的状态划分成更小粒度的pane，比如上面3小时窗口、1小时滑动的情况，可以把pane设置为1h，这样每来一条数据，我们就只更新这条数据对应的pane的结果就可以了。当窗口需要输出结果的时候，只需要将这个窗口对应的pane的结果merge起来就可以了。

注意：这里也是需要所有聚合函数都有merge的实现的

小结：

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

04.案例分析

案例一：计算实时抖音DAU曲线

DAU(Daily Active User)：指的是每天的去重活跃用户数

输出：每个5s更新一下当前的DAU数值，最终获得一天内的DAU变化曲线

要求：通过上面课程中学到的窗口的功能以及相关的优化，开发一个Flink SQL任务，使得可以高效的计算出来上面要求的实时结果。

问题：所有数据都需要在一个subtask中完成窗口计算，无法并行

滚动窗口

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

案例二：计算大数据任务的资源使用

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

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

会话窗口

思考

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

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

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

4. window的基本功能扩展有哪些

5. 四种高级的window的优化分别是为了解决什么问题，又是什么原理