Apache Flink® 社区本周发布了 Apache Flink 1.20。在这篇博文中，我们将重点介绍一些最有趣的新增功能和改进。您可以在官方发布公告中找到所有更新的全面概述。

近期的 Flink 版本一直强调改善 Flink 的易用性，不仅面向开发者，也面向那些运维 Flink 集群的人员，这一主题在最新版本中得以延续。同时，Flink 1.20 预计是 Flink 2.0 之前的最后一个次要版本，因此这个次要版本为社区的工作画上了句号——弃用在即将到来的主要版本中应被移除或替换的 API（应用程序编程接口），并清理大量配置选项。

Flink SQL 的改进

在 Flink 1.20 中，我们再次看到 Flink SQL 的多项改进。除了一般的性能增强和稳定性修复之外，社区自豪地推出两个重要特性，它们将进一步简化未来在 Flink 中与表的交互：

DISTRIBUTED BY

FLIP-376 引入了一种统一的方式来为 Flink SQL 表指定分桶策略。分桶是除早已支持的分区（FLIP-63）之外的另一种数据布局机制。与分区不同，通过分桶，用户可以控制所创建组的数量（桶的数量），并定义数据分布策略（例如哈希）。

此前，分桶只能通过 Flink 的 WITH 子句进行配置，并且每个连接器都实现了自己的语法来定义分桶。

让我们来看一个 Flink SQL Kafka Table DDL。

CREATE
TABLE
KafkaTable
(
`
ts
`
TIMESTAMP_LTZ
(
3
)
METADATA
FROM
'timestamp'
,
`
user_id
`
BIGINT
,
`
item_id
`
BIGINT
,
`
behavior
`
STRING
)
WITH
(
'connector'
=
'kafka'
,
'key.format'
=
'json'
,
'key.fields'
=
'user_id;item_id'
,
'value.format'
=
'json'
,
'properties.num.partitions'
=
'6'
,
)

CREATE
TABLE
KafkaTable
(
`
ts
`
TIMESTAMP_LTZ
(
3
)
METADATA
FROM
'timestamp'
,
`
user_id
`
BIGINT
,
`
item_id
`
BIGINT
,
`
behavior
`
STRING
)
WITH
(
'connector'
=
'kafka'
,
'key.format'
=
'json'
,
'value.format'
=
'json'
,
)
DISTRIBUTED
BY
(
user_id
,
item_id
)
INTO
6
BUCKETS

物化表

当用户开始使用 Flink SQL 时，他们往往难以理解数据的新鲜度以及将数据插入表的相关成本影响。用户要么定义提供最低延迟的流式摄取并持续运行（这意味着昂贵的基础设施需要一直运行），要么使用 Flink 批处理作业插入新数据，但后者可能无法满足数据新鲜度要求（例如 SLO）。

FLIP-435 为用户提供了直接在 Flink 中指定数据新鲜度要求的可能性，而无需依赖外部系统来管理。这是通过 MATERIALIZED 表这一新概念实现的，该表会在后台自动刷新。

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

DDL 执行后，Flink 要么启动一个流式作业来满足新鲜度要求，要么调度一个批处理作业定期执行。这一决策基于新配置 materialized-table.refresh-mode.freshness-threshold 做出。如果指定的新鲜度低于阈值，表将通过流式作业持续更新；如果大于阈值，Flink 则调度周期性批处理作业。

DataStream API 的改进

FLIP-380 增加了在非键控流上并行计算聚合的支持。此功能仅可在批处理模式下使用，为 DataStream API 带来了此前仅在 DataSet API 中才 readily 可用的功能。这是必要的，因为 DataSet API 已被弃用，并将在 Flink 2.0 中移除。

运维改进

检查点的统一文件合并

作为 Flink 恢复机制的一部分，Flink 会定期将元数据（检查点）写入持久化存储（例如 blob 存储），以便在发生故障时进行恢复。一个检查点由许多文件组成。多年来，已添加了多种不同的状态文件类型，导致 Flink 作业为单个检查点需要写入 blob 存储的独立文件数量不断增长。

对于大型作业（具有高并行度和众多算子的作业），检查点期间创建的文件数量可能对底层 blob 存储造成显著负载。当使用云解决方案（例如 S3、ADLS 等）时，这种负载直接转化为更多的请求，从而带来更高的成本。当使用自托管 blob 存储（例如 HDFS、Minio）时，则会导致频繁的过载。

通过 FLIP-306，Flink 现在提供了多种配置来控制状态的上传行为，以尽量减少文件数量（例如，state.checkpoints.file-merging 用于启用该功能，state.checkpoints.file-merging.max-file-size 用于控制检查点文件的最大大小）。

与之前的解决方案相比，新配置适用于所有类型的状态文件，并且普遍适用于 Flink 状态。

小型 SST 文件的压缩

Flink 社区还修复了 RocksDB 状态后端的一个长期存在的问题（FLINK-26050）。

在极少数情况下，例如使用 Flink 处理时间窗口创建大量小的非重叠 RocksDB SST 文件时，本地 SST 文件数量的持续增长最终可能导致类似 FLINK-34430 的不稳定情况。

为了避免仅依赖 RocksDB 的自动压缩，Flink 现在会定期扫描本地文件，并在检测到过多小文件时触发手动压缩。

批处理作业从 JobMaster 故障中恢复

Flink 长期以来一直支持通过从检查点重启来恢复流处理作业的 JobMaster 故障，但批处理恢复一直依赖于从头重启作业。这意味着之前的所有进度都会丢失。

FLIP-383 通过使从 JobMaster 故障前已完成的所有任务中恢复状态成为可能，解决了这个问题。

Flink 2.0 的最后准备工作

社区正在进行最后的准备工作，为 Flink 2.0 做准备：

旧版 SinkFunction API 已被弃用。
大约 30 个不再有用的其他配置选项已被弃用，还有一些选项被重新组织，最显著的是关于检查点、保存点、状态和状态恢复的选项。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Confluent Blog

原创地址：https://www.confluent.io/blog/announcing-apache-flink-1-18/

ITPub博客

Flink 1.20 带来重大改进及弃用项