8月2日，Flink1.20版本发布，一边听歌一边看我分析。（戳上面👆听歌）
本文基于官方网站的Release Note做一个简单的分析，看看哪些内容是更加值得我们关注的。
在定位上，这个版本是一个2.0版本之前的过渡版本，也是1.x时代最后一个版本。
这个版本中有很多细小的变动，和一些MVP版本的开发，那站在用户的角度，比较值得注意的几个特性有哪些：
物化表
1.20版本引入了一个 物化表(Materialized Table) 的概念，官方给的解释是：
通过定义查询语句和数据新鲜度，引擎会自动推导出表结构并创建对应的数据加工链路，以保证查询结果满足所要求的数据新鲜度。
什么意思呢？
我们直接看一段代码：
-- 1. 创建物化表并定义新鲜度
CREATE MATERIALIZED TABLE dwd_orders
(
PRIMARY KEY(ds, id) NOT ENFORCED
)
PARTITIONED BY (ds)
FRESHNESS = INTERVAL '3' MINUTE
AS SELECT
o.ds
o.id,
o.order_number,
o.user_id,
...
FROM
orders as o
LEFT JOIN products FOR SYSTEM_TIME AS OF proctime() AS prod
ON o.product_id = prod.id
LEFT JOIN order_pay AS pay
ON o.id = pay.order_id and o.ds = pay.ds;
-- 2. 暂停数据刷新
ALTER MATERIALIZED TABLE dwd_orders SUSPEND;
-- 3. 恢复数据刷新
ALTER MATERIALIZED TABLE dwd_orders RESUME
-- Set table option via WITH clause
WITH(
'sink.parallesim' = '10'
);
-- 手动刷写历史数据
ALTER MATERIALIZED TABLE dwd_orders REFRESH PARTITION(ds='20231023');
也就是说，现在我们定义了一个dwd_orders的sink算子，下游数据刷新频率等于3分钟。你的sink可以是Kafka、Paimon、Hudi等等。
我把FLIP设计文档中的motivation部分贴在下面，大家可以自己看：
从感官上来讲，根据FLIP设计文档中的描述，我一时分不清这个Feature要解决的真正问题在哪里？
但是不急，我们等2.x版本有了更多的场景再回过头来看看，暂时保持关注。
支持DISTRIBUTED BY
1.20版本中，Flink社区引入了分桶的概念。这个概念在很多计算引擎中都有，例如Hive、Doris等等。
目的是通过将数据拆分为不相交的子集来实现数据在外部存储系统中的负载均衡。
关于这个Feature的出现，主要是2个目的。
第一，在SINK端实现数据的负载均衡
目前Flink Sink算子进行数据均衡存储是在sink connector中实现的。例如官方社区的 kafka sink connetor是支持sink.partitioner这样的配置的，结合Flink的分区算子进行sink端的负载均衡。
此外，很多公司基于此还开发了很多额外的参数让kafka sink connector变得更易用。
第二，Flink作为计算引擎必须要考到Join操作的性能优化
在简化用户的建表操作的同时，让Flink引擎感知到外部数据的物理分布，为未来支持类似bucket join这样的优化打好基础。
State和Checkpoint上的一些优化
Flink 1.20 引入了统一的检查点文件合并机制，它将多个小的检查点文件合并为数量较少的大文件，从而减少了文件创建和文件删除操作的次数，并减轻了检查点期间文件系统元数据管理的压力。
此外，1.20版开始，Flink可以使用RocksDB API在后台合并RocksDB 状态后端生成的小文件。
还有一些其他的优化，大家根据需要去关注官方的文档：
