Flink1.19版本更新了，我们按例对最新版本的Flink中的核心能力进行一下解读。
我们的重点还是生产环境应用和需要注意的问题，以及对未来的一些判断。
本次更新涉及到SQL/Runtime/CheckPoint这三个方面的改进，这也是目前整个引擎开发最重要的几个方向。
SQL能力优化
SQL能力上的优化需要大家特别关注的三个能力分别是：源表自定义并行度、sql hint配置TTL、Regular Join支持MiniBatch优化。
源表自定义并行度
Flink 1.19版本中开始支持通过设置scan.parallelism这样的参数来配置并行度，不过目前支持的连接器是DataGen，还没有大范围的支持。
源表的并行度支持是非常重要的一个能力，对不同的source源，并行度解决的问题不尽相同。
我们在消费数据时，增大消费的并行度可以有效解决数据的消费速度和关联效率；对于RocketMQ、Mysql、Redis这样的数据源尤其明显，如果你的数据规模较大，消费延迟，最有效的办法之一就是加大消费并行度；
但是Kafka是个特例，因为Kafka connector的独特的设计，一般在生产环境我们建议消费并行度和Kafka的Partition保持一致，如果不设置的话会默认当前Flink任务的最大并行度。
官方预计下个版本优先支持Kafka，但是我建议社区可以换个其他的source connetcor优先实现。
SQL Hint配置TTL
官方给出了一个案例：
go
-- set state ttl for join
SELECT /*+ STATE_TTL('Orders'= '1d', 'Customers' = '20d') */ *
FROM Orders LEFT OUTER JOIN Customers
ON Orders.o_custkey = Customers.c_custkey;
-- set state ttl for aggregation
SELECT /*+ STATE_TTL('o' = '1d') */ o_orderkey, SUM(o_totalprice) AS revenue
FROM Orders AS o
GROUP BY o_orderkey;在Flink1.18的基础上，1.19版本使TTL的设置变得更加易用，是个很大的提升，我的判断是大家基本上可以在生产环境尝试使用了。对于减少state大小和降低任务资源消耗有很大帮助。
Regular Join支持MiniBatch优化
关于Regular Join相信大家都陌生了，Regular Join在生产环境中的几个非常严重的问题其中之一就是性能问题。因为需要频繁访问状态，如果你的任务状态很大或者对状态的访问非常频繁，那么就会遇到性能瓶颈，Regular Join支持MiniBatch优化在一定程度上能解决这个问题，本质上就是一个批次去重的过程。
Rumtime优化
Flink1.19中开始支持批作业的源表动态并行度推导，允许源连接器根据实际消耗的数据量动态推断并行度。在实际使用中，批任务的并行度的动态推导是提高批作业性能的重要的手段，大家可以尝试小范围使用。不过现在还需要做一点定制开发，源连接器需要实现推理接口，以启用动态并行度推理。目前已经支持FileSource连接器。
Checkpoint
1.19版本支持了一个能力，可以通过设置参数来设置Flink任务在读取不同数据源数据的checkpointing.interval能力。什么意思呢？例如你的代码需要先读一个Hive表，再接着消费Kafka的数据。这两个阶段就可以设置不同的checkpointing.interval。
go
execution.checkpointing.interval: 30sec
execution.checkpointing.interval-during-backlog: 30min以上就1.19版本需要关注的新的能力，我们下个版本再见。
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点