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

291 阅读5分钟

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

哈喽大家好,今天是录播学习的第四天,我在这里做了简要的笔记总结供大家查阅。

本篇文章包括一下内容:
1.实时计算和批式计算的本质区别,以及实时计算所带来的新的机遇和挑战
2.实时计算中的核心功能:Watermark机制,Window机制
3.3大基本窗口类型的定义、使用一级核心原理

01.流式计算的基本概念,与批式计算相比的难点与挑战

流式计算,就是对数据流进行处理,是实时计算。

批量计算则统一收集数据,存储到数据库中,然后对数据进行批量处理的数据计算方式。

流式计算VS批式计算

image.png

批处理模型典型的数仓架构为T+1架构,即数据计算时天级别的,当天只能看到前一天的计算结果。
通常使用的计算引擎为Hive或者Spark等,计算的时候,数据是完全ready,输入和输出都是确定性的。如果我们想更具有实时性,我们可以尝试小时级批计算,但是批计算每小时计算会消耗大量资源,也可能批计算在1个小时内的计算不能完成,也是不行的,于是我们采用处理时间窗户进行实时计算,数据实时流动,实时计算,窗口结束直接发送结束,不需要周期调度任务。

02.Watermark

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

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

Watermark传递:这个类似于上节课中介绍的Checkpoint的制作过程,传递就类似于Checkpoint的barrier,上下游task之间有数据传输关系的,上游就会将watermark传递给下游;下游收到多个上游传递过来的watermark后,默认会取其中最小值来作为自身的watermark,同时它也会将自己watermark传递给它的下游。经过整个传递过程,最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。

  • 一般可以通过Flink Web UI上的信息来观察当前任务的watermark情况
  • 怎么观察一个任务中的watermark是多少,是否正常的这个问题是生产实践中最容易遇到的问题,大家在开发事件时间的窗口任务的时候,经常会忘记了设置watermark,或者数据太少,watermark没有及时的更新,导致窗口一直不能触发。
  • 在Flink里早期都是per-subtask的方式进行watermark的生成,这种方式比较简单。但是如果每个source task如果有消费多个partition的情况的话,那多个partition之间的数据可能会因为消费的速度不同而最终导致数据的乱序程度增加。
  • 新版本引入了基于每个per-partition的方式来产生watermark,来避免上面的问题。
  • 数据断流是很常见的问题,我们可以用一种IDLE状态来标记这种subtask,被标记为这种状态的subtask,我们在计算watermark的时候,可以把它先排除在外。这样就可以保证有部分partition断流的时候,watermark仍然可以继续更新。

03.Window基本功能和高级优化

Window-基本功能

Window分类

典型的Window:
1.Tumble Window(滚动窗口): 每个key单独划分,每条数据只会属于一个窗口,Window结束时间到达的时候一次性触发。

2.Sliding Window(滑动窗口): 每个key单独划分,每条数据可能会属于多个窗口,Window结束时间到达的时候一次性触发。

3.Session Window(会话窗口): 每个key单独划分,每条数据会单独划分一个窗口,如果Window之间有交集,则会对窗口进行merge,Window结束时间到达的时候一次性触发。

其他Window:
1.全局Window
2.Count Window
3.累计窗口

迟到数据处理

一条数据到来后,会用WindowAssigner给它划分一个window,一般时间窗口是一个时间区间,如果划分出来的window end比当前的watermark值还要小,说明这个窗口已经触发了,这条数据就是迟到数据。只有事件时间下才会有迟到的数据。一般我们默认迟到数据处理就是丢弃。

增量计算 VS 全量计算

  • 增量计算:每条数据到来后,直接参与计算(但是还不需要输出结果),SQL中的聚合只有增量计算

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

EMIT触发

上面讲到,正常的窗口都是窗口结束的时候才会进行输出,比如一个1天的窗口,只有到每天结束的时候,窗口的结果才会输出。这种情况下就失去了实时计算的意义了。

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

这个功能只在SQL中,如果是在DataStream中需要完成类似的功能,需要自己定义一些trigger来做。

好了,今天的学习到此就结束啦,感谢观看。