通过 Savepoint 来切换 State Backend
用户现在可以在从一个 Savepoint 重启时切换一个 Flink 应用的 State Backend。这使得 Flink 应用不再被限制只能使用应用首次运行时选择的 State Backend。
基于这一功能，用户现在可以首先使用一个 HashMap State Backend（纯内存的 State Backend），如果后续状态变得过大的话，就切换到 RocksDB State Backend 中。
在实现层，Flink 现在统一了所有 State Backend 的 Savepoint 格式来实现这一功能。
K8s 部署时使用用户指定的 Pod 模式
原生 kubernetes 部署（Flink 主动要求 K8s 来启动 Pod）中，现在可以使用自定义的 Pod 模板。
使用这些模板，用户可以使用一种更符合 K8s 的方式来设置 JM 和 TM 的 Pod，这种方式比 Flink K8s 集成内置的配置项更加灵活。
生产可用的 Unaligned Checkpoint
Unaligned Checkpoint 目前已达到了生产可用的状态，我们鼓励用户在存在反压的情况下试用这一功能。
具体来说，Flink 1.13 中引入的这些功能使 Unaligned Checkpoint 更容易使用：
- 用户现在使用 Unaligned Checkpoint 时也可以扩缩容应用。如果用户需要因为性能原因不能使用 Savepoint而必须使用 Retained checkpoint 时，这一功能会非常方便。
- 对于没有反压的应用，启用 Unaligned Checkpoint 现在代价更小。Unaligned Checkpoint 现在可以通过超时来自动触发，即一个应用默认会使用 Aligned Checkpoint（不存储传输中的数据），而只在对齐超过一定时间范围时自动切换到 Unaligned Checkpoint（存储传输中的数据）。
关于如何启用 Unaligned Checkpoint 可以参考相关文档。
机器学习迁移到单独的仓库
为了加速 Flink 机器学习的进展（流批统一的机器学习），现在 Flink 机器学习开启了新的 flink-ml 仓库。我们采用类似于 Stateful Function 项目的管理方式，通过使用一个单独的仓库从而简化代码合并的流程并且可以进行单独的版本发布，从而提高开发的效率。
用户可以关注 Flink 在机器学习方面的进展，比如与 Alink（Flink 常用机器学习算法套件）的互操作以及 Flink 与 Tensorflow 的集成。
SQL / Table API 进展
与之前的版本类似，SQL 和 Table API 仍然在所有开发中占用很大的比例。
通过 Table-valued 函数来定义时间窗口
在流式 SQL 查询中，一个最经常使用的是定义时间窗口。Flink 1.13 中引入了一种新的定义窗口的方式：通过 Table-valued 函数。这一方式不仅有更强的表达能力（允许用户定义新的窗口类型），并且与 SQL 标准更加一致。
Flink 1.13 在新的语法中支持 TUMBLE 和 HOP 窗口，在后续版本中也会支持 SESSION 窗口。我们通过以下两个例子来展示这一方法的表达能力：