《Apache Flink 案例集（2022版）》——2.数据分析——快手-Flink SQL 在快手的扩展和实践（1） https://developer.aliyun.com/article/1228373
生产实践
一、功能扩展
为了支持内部的业务需求，快手做了很多功能扩展，其中两个围绕窗口的扩展尤为重要：一个是 Group Window Aggregate 扩展，一个是在 Flip-145 里提出的 Window Table-valued Function 扩展。
1. Group Window Aggregate 扩展
快手在 Group Window Aggregate 上做了两个扩展，一个是支持多维聚合，一个是引入高阶窗口函数。
Flink SQL 很早就支持无限流上的多维聚合，快手在 Group Window Aggregate 上也增加了多维分析的功能，支持标准的 Grouping Sets、Rollup 和 CUBE 子句，另外还支持各种窗口类型，比如滚动、滑动、会话窗口等。
比如上图实例，需要统计主题维度和总维度下的累计 UV，SQL 的 group by 子句里包含两部分：一个是 CUMULATE 窗口函数，一个是 Grouping Sets 子句。括号里有两个元素：一个表示总维度，一个表示主题维度。
数据分析的开发者经常会遇到这样的需求，绘制一条曲线，每个点的含义是当天 0 点到当前时间点的累计指标，横坐标表示时间，纵坐标是表示累计的指标。对这样的需求可以有两个解决方案：
第一个方案是使用无限流聚合，把时间归一到分钟粒度以后作为 group key 的一列，但是业务上要求输出到屏幕上的曲线不再变化，而无限流聚合的输出结果是一个更新流，所以不符合要求；
第二个方案是使用一天的滚动窗口函数。为了提前输出结果，还是要设置提前触发，时间点选用当前机器的时间或者是历史输入数据里最大的时间戳。这个方案的缺点，首先是每个点的纵坐标的值并不是这个时间点上的累计值。这会导致几个异常现象，比如作业失败重启或者是业务主动回溯历史的时候，不能完全还原当时的历史曲线。而且各个点上分维度的累计值加起来也不等于总维度的值。还有一个缺点，统计 UV 的时候，我们经常会使用两阶段的聚合来避免 distinct key 的倾斜，但是使用这个方案的时候，原本自身的曲线上可能会出现凹坑。
我们引入 CUMULATE 窗口来解决这些问题，主要有两方面的优点：
第一是使用窗口的结束时间作为每个点的横坐标，曲线上每个点的纵坐标就是在横坐标对应时间点上的累计值，所以无论在回溯历史或者是作业发生 failover 的情况下，曲线都可以完全还原，而且各个时间点上分维度的值加起来总是等于总维度的值；
第二是使用两阶段聚合，能够防止 distinct key 倾斜。由于数据是在窗口结束的时候才发送，所以不存在撤回，输出的是 append 流，因此自增曲线上也不会有凹坑。
2. Window Table-valued Function 扩展
社区在 FLIP-145 中提出 Window Table-valued Function (Window TVF) 语法，并且实现了窗口聚合。在这个基础上我们丰富了窗口算子，包括 TopN、关联和去重，还支持了一个单独的 Window TVF 查询语句，这些功能都已经陆续推到社区的各个版本里。有了这些窗口的算子，用户就可以用 Flink SQL 实现更复杂的业务逻辑。
如上图案例，需要统计当天最热销的 100 件商品的销售额和买家数，以及这些爆品所属主播的销售情况。首先做一个窗口聚合，得到 0 点以来每个商品的销售额和买家数，再做一个窗口聚合，得到每个主播所有宝贝的买家数，两个结果做窗口关联，最后做窗口上的 TopN，得到前 100 名爆品以及它的各项累计指标。
此外快手在Window TVF上还增加了对批模式的支持。原理是引入一个 windows 算子，给输入数据附上所属的窗口属性后发给下游，而下游的算子复用批上已经存在的算子，比如说聚合上是用 HashAgg 或者 SortAgg，关联上是 HashJoin 或者 SortMergeJoin，这些批上的算子和流模式下的算子相比，不需要状态，所以吞吐上也有更好的表现。
