《Apache Flink 案例集（2022版）》——2.数据分析——快手-Flink SQL 在快手的扩展和实践（2） https://developer.aliyun.com/article/1228372
二、 性能优化 聚合上的状态优化
聚合上的状态优化
这是一个聚合场景下 distinct states 状态复用的案例，需要统计应用下每个子频道的 UV。该案例有两个特点，频道是可枚举的并且每个频道访客的重合度很高。
最原始的查询语句如上图，group key 是一个频道，用一个 count distinct 来计算各个频道的 UV。设备集合在状态中首先是存在一个 map state，假设频道的枚举只有三个，A、B 和 other，group key 是频道 ID, map state 的 key 设备 ID， value 是一个 64 bit 的 long 类型的值，每个 bit 表示这个频道下该设备是否出现，在简单的场景下这个 Value 值就是 1。上图 B 频道下有两个设备，ID 分别是 1 和 3，ID 为 1 的设备同时访问了 A 频道，id 为 3 的设备同时访问了 other 频道。可以发现，不同频道的 map 可以有大量的重合。
我们提出一种简化的 SQL 表达方式，既能达到状态上的收益，又能减轻数据开发人员的负担。用户只需要在查询语句里，通过一个方式告诉优化器 group key 的枚举值，优化器就会自动改写，进行转列和列转行，改写后就可以复用 distinct map state。改写后等价下的查询语句，只需要在过滤条件里指定枚举值就可以，用 in 或 or 的表达方式都可以。
上述性能优化可以用在无限流聚合和窗口聚合，并且一个可枚举维度或多个可枚举维度都是可以的，可以用在简单的聚合查询，也可以用在多维聚合。
但它的限制条件是 group key 里面至少有一个 key 是可枚举的，而且枚举值必须是静态的，能够明确写在过滤条件里。另外每个维度下的 distinct key 得有重合才能达到节约状态的效果。如果需要统计每个省份的 UV，基本上可以认为不同省份的访客是没有交集的，这个时候复用 distinct key 是没有收益的。另外在窗口聚合的时候，窗口函数必须具有行语义，不可以是集合语义。对于行语义的窗口，当前这个数据属于哪个窗口取决于数据本身；但是对于集合语义的窗口，当前这条数据属于哪个窗口，不仅取决于数据本身，还取决于这个窗口收到过的历史数据集合。这个优化调整聚合算子的 group key，会影响每个窗口收到的数据集合，所以不适用于集合语义的窗口。
《Apache Flink 案例集（2022版）》——2.数据分析——快手-Flink SQL 在快手的扩展和实践（4） https://developer.aliyun.com/article/1228369
