小白学苑

Flink APIs的演变

随着Flink 2.0的临近，社区正计划改进Apache Flink的API。

1) 社区计划在Flink 2.0中删除一些长期被弃用的API，以使Flink运行得更快，包括:

(1) DataSet API, 所有的Scala APIs, 遗留的SinkV1 API, 遗留的TableSource/TableSink API。

(2) DataStream API、Table API和REST API中已弃用的方法/字段/类。

(3) 已弃用的配置选项和指标。

2）社区还计划在长期内淘汰遗留的SourceFunction / SinkFunction API和Queryable State API。这可能不会很快实现，因为用户从这些API迁移的先决条件目前还没有完全满足。

3）社区意识到当前DataStream API的一些问题，例如Flink内部实现的暴露和依赖，这需要进行重大更改来修复。为了提供平稳的迁移体验，社区正在设计一个新的ProcessFunction API，其目标是在长期内逐步取代DataStream API。

Flink作为一个应用程序

这些努力的目标是使部署(长时间运行的流)Flink应用程序感觉很自然。这些努力支持将流作业部署为自包含的应用程序，而不是启动集群并向该集群提交作业。

例如，作为一个简单的Kubernetes部署;像普通应用程序一样部署和伸缩，无需额外的工作流。

(1) 目前，社区正在开发Flink Kubernetes Operator子项目，并在文档中有自己的路线图。

(2) 流查询作为一个应用程序。使SQL Client/Gateway支持以应用模式提交SQL作业(FLIP-316)。

易用性改进

我们不时听到人们说，虽然Flink功能强大，但它并不那么容易掌握。我们听到了这样的声音。社区正在努力改进Flink的可用性。

我们正在努力减少用户需要指定的配置选项的数量，并使它们更容易理解和调优。这包括：删除需要深入了解Flink内部知识才能理解和使用的选项。使Flink在可能的情况下自动动态地决定适当的行为。改进选项的默认值，以便用户在大多数情况下不需要触碰它们。改进选项的定义和描述，以便在必要时更容易理解和使用。

我们已经在这方面取得了一些进展。Flink 1.17需要少于10个配置才能在TPC-DS上获得足够好的性能。混合shuffle支持在不同shuffle模式之间动态切换，并将其内存占用与作业的并行性解耦合。

面向流仓库

Flink已成为流处理的领先技术和事实标准。统一流和批数据处理的概念正在得到越来越多的公司的认可和成功实施。为了进一步统一流批分析，Flink提出了流仓库的概念。这个新概念旨在统一计算和存储，确保数据的实时流动和处理。因此，仓库中的数据始终是最新的，并且从中生成的任何分析或见解都反映了业务的当前状态。这将传统数据仓库的优势与实时洞察相结合。

Apache Flink社区发起了Flink表存储子项目(FLIP-188)，以实现流式批处理统一存储。随着项目的快速发展，Flink Table Store作为一个名为Apache Paimon的独立项目加入了Apache孵化器。Apache Paimon在文档中有自己的路线图。统一存储为Flink提高流批量统一应用程序的性能和体验开辟了道路。

OLAP是Flink流批数据处理后的一个重要场景，用户需要一个OLAP引擎来分析流仓库中的数据。Flink可以执行“OLAP作为批处理的特殊情况”，并且社区正在尝试探索在不影响流处理和批处理的情况下改进短期作业的可能性。这是一个很好的特性，它将为Flink成为统一的流-批-OLAP数据处理系统的用户带来巨大的价值。

为了构建一个高效的流仓库，Flink中有很多东西需要改进，例如:

(1) 支持丰富的仓库API来管理数据和元数据，例如:CTAS/RTAS (FLIP-303)、CALL (FLIP-311)、TRUNCATE (FLIP-302)等。

(2) CBO(基于成本的优化)在流查询的流湖屋中使用统计数据。

(3) 充分利用流湖屋的布局和索引，减少流查询的数据读取和处理。

(4) 对短期作业的改进，以支持具有低延迟和并发执行的OLAP查询。