在我的项目中使用flink表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。这样地，
但是当使用datastreamapi和 keyBy 而不是表sql GROUP BY ，检查点大小正常，小于1mb。
为什么？
-------更新日期：2019-03-25--------
在做了一些测试并阅读了源代码之后，我们发现出现这种情况的原因是rocksdb。
当使用rockdb作为状态后端时，检查点的大小将超过每个密钥约5mb，而当使用文件系统作为状态后端时，检查点的大小将下降到每个密钥小于100kb。
为什么rocksdb需要这么大的空间来容纳这个州？我们应该什么时候选择rocksdb？
1条答案
按热度按时间ibrsph3r1#
首先，我不认为70MB是一个巨大的状态。有许多Flink工作与多个国家的tbs。关于两个查询的状态大小为何不同的问题：
第一个查询是一个简单的投影查询，这意味着每个记录都可以独立处理。因此，查询不需要“记住”任何记录，只需要恢复流偏移量。
第二个查询执行一个窗口聚合，需要为每个窗口记住一个中间结果（部分和），直到时间进展到可以发出最终结果为止。
由于flinksql查询被转换为数据流操作符，因此sql查询和使用
keyBy().window(). 两者运行的代码几乎相同。更新：已确定状态增加的原因是rocksdbstatebackend引起的。这个开销不是每个键的开销，而是每个有状态操作符的开销。由于rocksdbstatebendback的目的是保存多个gbs到tbs的状态大小，因此几mb的开销可以忽略不计。