在我的项目中使用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?
答案 0 :(得分:0)
首先,我不认为70 MB是巨大的状态。有许多具有多个TB状态的Flink作业。关于两个查询的状态大小为何不同的问题:
第一个查询是一个简单的投影查询,这意味着每个记录都可以独立处理。因此,查询不需要“记住”任何记录,而只需“流”偏移即可恢复。
第二个查询执行窗口聚合,并且需要记住每个窗口的中间结果(部分和),直到时间足够长以使结果是最终的并且可以发出为止。
由于Flink SQL查询已转换为DataStream运算符,因此SQL查询与使用keyBy().window()
实现聚合之间没有太大区别。两者都运行几乎相同的代码。
更新:已确定状态增加的原因是由RocksDBStateBackend引起的。此开销不是每个键的开销,而是每个有状态运算符的开销。由于RocksDBStateBackend用于保存多个GB到TB的状态大小,因此几MB的开销可以忽略不计。