flink sql 知其所以然（八）：flink sql tumble window 的奇妙解析之路

感谢您的小爱心（关注  +  点赞 + 再看），对博主的肯定，会督促博主持续的输出更多的优质实战内容！！！

1.序篇-本文结构

大数据羊说

用数据提升美好事物发生的概率~

34篇原创内容

公众号

源码公众号后台回复flink sql tumble window 的奇妙解析之路获取。

针对 datastream api 大家都比较熟悉了，还是那句话，在 datastream 中，你写的代码逻辑是什么样的，它最终的执行方式就是什么样的。

但是对于 flink sql 的执行过程，大家还是不熟悉的。上节使用 ETL，group agg（sum，count等）简单聚合类 query 带大家走进一条 flink sql query 逻辑的世界。帮大家至少能够熟悉在 flink sql 程序运行时知道 flink 程序在干什么。

此节就是窗口聚合章节的第一篇，以一个最简单、最常用的分钟 tumble window 聚合案例给大家介绍其使用方式和原理。

由于 flink 1.13 引入了 window tvf，所以 1.13 和 1.12 及之前版本的实现不同。本节先介绍 flink 1.12 及之前的 tumble window 实现。这也是大家在引入 flink sql 能力时最常使用的。

本节依然从以下几个章节给大家详细介绍 flink sql 的能力。

1. 目标篇-本文能帮助大家了解 flink sql 什么？

• 回顾上节的 flink sql 适用场景的结论

3. 概念篇-先聊聊常见的窗口聚合

• 窗口竟然拖慢数据产出？

• 常用的窗口

5. 实战篇-简单的 tumble window 案例和运行原理

• 先看一个 datastream 窗口案例

• flink sql tumble window 的语义

• tumble window 实际案例

• GeneratedWatermarkGenerator - flink 1.12.1

• BinaryRowDataKeySelector - flink 1.12.1

• AggregateWindowOperator - flink 1.12.1

7. 总结与展望篇

先说说结论，以下这些结论已经在上节说过了，此处附上上节文章：

1. 场景问题：flink sql 很适合简单 ETL，以及基本全部场景下的聚合类指标（本节要介绍的 tumble window 就在聚合类指标的范畴之内）。

2. 语法问题：flink sql 语法其实是和其他 sql 语法基本一致的。基本不会产生语法问题阻碍使用 flink sql。但是本节要介绍的 tumble window 的语法就是略有不同的那部分。下面详细介绍。

3. 运行问题：查看 flink sql 任务时的一些技巧，以及其中一些可能会碰到的坑：

• 去 flink webui 就能看到这个任务目前在做什么。包括算子名称都会给直接展示给我们目前哪个算子在干啥事情，在处理啥逻辑。

• sql 的 watermark 类型要设置为 TIMESTAMP(3)。

• 事件时间逻辑中，sql api 和 datastream api 对于数据记录时间戳存储逻辑是不一样的。datastream api：每条记录的 rowtime 是放在 StreamRecord 中的时间戳字段中的。sql api：时间戳是每次都从数据中进行获取的。算子中会维护一个下标。可以按照下标从数据中获取时间戳。

2.目标篇-本文能帮助大家了解 flink sql tumble window 什么？

关于 flink sql tumble window 一般都会有以下问题。本文的目标也是为大家解答这些问题：

1. 场景问题：场景问题就不必多说，datastream 在 tumble window 场景下的应用很多了，分钟级别聚合等常用场景

2. 语法问题：flink sql 写 tumble window 任务时是一种与 hive sql 中没有的语法。下文详细介绍。

3. 运行问题：使用一条简单的 tumble window sql 帮大家从 transformation、runtime 帮大家理解 tumble window 的整体运行机制。

4. 理解误区：既然是 sql 必然要遵循 sql 语义，sql tumble window 聚合是输入多条，产出一条数据。并不像 datastream 那样可以在窗口 udf 中做到多对多。

在正式开始聊 tumble window 之前，先看看上节 flink sql 适用场景的结论。让大家先有 flink sql 的一个整体印象以及结论。

2.1.回顾上节的 flink sql 适用场景的结论

不装了，我坦白了，flink sql 其实很适合干的活就是 dwd 清洗，dws 聚合。

此处主要针对实时数仓的场景来说。flink sql 能干 dwd 清洗，dws 聚合，基本上实时数仓的大多数场景都能给覆盖了。

flink sql 牛逼！！！

但是！！！

经过博主使用 flink sql 经验来看，并不是所有的 dwd，dws 聚合场景都适合 flink sql（截止发文阶段来说）！！！

其实这些目前不适合 flink sql 的场景总结下来就是在处理上比 datastream 还是会有一定的损失。

先总结下使用场景：

1. dwd：简单的清洗、复杂的清洗、维度的扩充、各种 udf 的使用

2. dws：各类聚合

然后分适合的场景和不适合的场景来说，因为只这一篇不能覆盖所有的内容，所以本文此处先大致给个结论，之后会结合具体的场景详细描述。

• 适合的场景：

1. 简单的 dwd 清洗场景

2. 全场景的 dws 聚合场景

• 目前不太适合的场景：

1. 复杂的 dwd 清洗场景：举例比如使用了很多 udf 清洗，尤其是使用很多的 json 类解析清洗

2. 关联维度场景：举例比如 datastream 中经常会有攒一批数据批量访问外部接口的场景，flink sql 目前对于这种场景虽然有 localcache、异步访问能力，但是依然还是一条一条访问外部缓存，这样相比批量访问还是会有性能差距。

3.概念篇-先聊聊常见的窗口聚合

窗口聚合大家都在 datastream api 中很熟悉了，目前在实时数据处理的过程中，窗口计算可以说是最重要、最常用的一种计算方式了。

但是在抛出窗口概念之前，博主有几个关于窗口的小想法说一下。

3.1.窗口竟然拖慢数据产出？

一个小想法。

先抛结论：窗口