Flink sql 之 TopN 与 StreamPhysicalRankRule (源码解析)

基于flink1.14的源码做解析

公司内有很多业务方都在使用我们Flink sql平台做TopN的计算，今天同事突然问到我，Flink sql 是怎么实现topN的 ？

蒙圈了，这块源码没看过啊 ，业务要问起来怎么办，赶快打开源码补一下

拿到这个问题先冷静分析一下范围

首先肯定属于Flink sql模块，源码里面肯定是在flink-table-planner包里面，接着topN那不就是ROW_NUMBER嘛，是个函数呀

既然如此那就从flink源码的系统函数作为线索开始找起来，来到 org.apache.calcite.sql.fun.SqlStdOperatorTable类

果然找到了，那calcite的某个rule肯定有个地方判断了它，继续查调用链

不出所料，FlinkLogicalRankRuleBase这个calcite的rule里面果然根据这个function的类型来确定rank的类型了

看下这个rule的匹配条件

 这里也好理解，overAgg的时候会判断这个rank以及对应的类型

这是只是做了一下简单的提取了rank的字段啊，提取谓语啊，提取表达式啊这一些拿信息的操作

然后直接生成新的relNode叫FlinkLogicalRank通过transformTo直接返回了这个等价节点

既然是relNode那肯定又会有calcite的rule去处理它，来找一找

批处理的就不管了，从名字就可以看出来我们要找的类了

看个不带window的吧

 返回StreamPhysicalRank

这个类是一个FlinkPhysicalRel是可以转换成execNode的

这里在多说一句，

这里将partitionKey传入了，就是sql里面的partition by后面的，后面会用这个来创建transformation的keySelecter用来分流数据

返回的这个StreamExecRank就是可以转换成具体的Flink的算子了，具体逻辑就在里面了

接下来看下row_number的具体逻辑，找到方法translateToPlanInternal

根据策略主要分为三种类型

AppendFastStrategy  （输入仅包含插入时）

RetractStrategy   （输入包含update和delete）

UpdateFastStrategy     (输入不应包含删除且输入有给定的primaryKeys且按字段排序时)

来看个retractStrategy的吧

先通过sort的字段获取一个用于排序RowData的比较器 ComparableRecordComparator

根据比较器创建 RetractableTopNFunction

这个类还有两个主要的状态数据结构

dataState这个map用来存放当key相同的所有数据会放在同一个list里面

treeMap这个可排序的map就是通过上面我们sql里面定义的sort by 来排序数据的，Long是指这个相同的key有多少个record

!!!!!!!!!!!  那就是用java的treeMap排序呗

继续往下看

 主逻辑就是这个了

每进入一条数据，会根据这条数据的类型划分

当数据是Insert , UPDATE_AFTER类型是会走 emitRecordsWithRowNumber（）方法

当数据是UPDATE_BEFORE，DELETE类型会走 retractRecordWithRowNumber （）方法

来看下具体逻辑先看INSERT的

 遍历treeMap

解读一下，当数据是insert数据的时候

INSERT数据会先放到treeMap里面去，delete则不会

按顺序遍历treeMap

当遍历过程中发现遍历的key与当前数据的key相同时，和当前数据key相同的所有数据数据（dataState中的LIST），全部撤回并且更新他们的rowNumber+1

继续遍历treeMap

之后的数据全部撤回UpdateBefore，并且向下游发送UpdateAfter使rowNumber+1，遍历直到已经到第TopN个数据循环结束

当数据是DELETE类型的时候，会和Insert反过来，当前key之后的数据全部撤回，然后rowNumber-1

整个处理流程差不多就结束了，可以看到rowNumber当N较大且排序变化频繁的时候，性能消耗还是非常大的，极端情况下游的数据会翻很多倍

这个还需要注意在其他两个策略中还有一个参数，table.exec.topn.cache-size

 影响下面这个本地lruCache的大小

 调大可以减少状态的访问，可以按需要添加