为什么我的Flink SQL查询的检查点大小不同？

Question

在我的项目中使用Flink Table SQL时，我发现如果我的SQL中有任何GROUP BY子句，则检查点的大小将大大增加。

例如，

INSERT INTO COMPANY_POST_DAY
SELECT
    sta_date,
    company_id,
    company_name
FROM
    FCBOX_POST_COUNT_VIEW

检查点大小将小于500KB。

但是当这样使用时，

INSERT INTO COMPANY_POST_DAY
SELECT
    sta_date,
    company_id,
    company_name,
    sum(ed_post_count)
FROM
    FCBOX_POST_COUNT_VIEW
GROUP BY
    sta_date, company_id, company_name, TUMBLE(procTime, INTERVAL '1' SECOND)

即使没有任何消息处理，检查点大小也将超过70MB。像这样

但是当使用DataStream API和keyBy而不是Table SQL GROUP BY时，检查点大小将是正常的，小于1MB。

为什么？

-------更新于2019-03-25 --------

经过一些测试并阅读了源代码，我们发现其原因是RocksDB。

使用RockDB作为状态后端时，每个密钥检查点的大小将超过5MB，而使用文件系统作为状态后端时，检查点的大小将降至每个密钥小于100KB。 / p>

为什么RocksDB需要那么多空间来保存状态？我们什么时候应该选择RocksDB？

Answer 1

首先，我不认为70 MB是巨大的状态。有许多具有多个TB状态的Flink作业。关于两个查询的状态大小为何不同的问题：

第一个查询是一个简单的投影查询，这意味着每个记录都可以独立处理。因此，查询不需要“记住”任何记录，而只需“流”偏移即可恢复。

第二个查询执行窗口聚合，并且需要记住每个窗口的中间结果（部分和），直到时间足够长以使结果是最终的并且可以发出为止。

由于Flink SQL查询已转换为DataStream运算符，因此SQL查询与使用keyBy().window()实现聚合之间没有太大区别。两者都运行几乎相同的代码。

更新：已确定状态增加的原因是由RocksDBStateBackend引起的。此开销不是每个键的开销，而是每个有状态运算符的开销。由于RocksDBStateBackend用于保存多个GB到TB的状态大小，因此几MB的开销可以忽略不计。