1.6新特性
Flink 1.6-有状态流处理的下一步
在Flink 1.6.0中，我们继续在较早版本中进行的基础工作：使Flink用户能够无缝地运行快速数据处理并毫不费力地构建数据驱动的数据密集型应用程序。
Flink的状态支持是使Flink在实现各种用例时如此通用和强大的关键功能之一。为了使其更容易，社区增加了对状态TTL的本地支持（FLINK-9510，FLINK-9938）。此功能允许在状态过期后对其进行清理。现在，通过Flink 1.6.0，计时器状态可以通过将相关状态存储在RocksDB中而退出内核（FLINK-9485）。最后但并非最不重要的一点是，我们还显着改进了计时器（FLINK-9423）的删除。
使用Flink 1.5.0，我们对Flink的分布式体系结构进行了重新设计，以增加对资源弹性和不同部署方案的支持，尤其是更好的容器集成。在Flink 1.6.0中，我们继续进行一些未完成的工作：现在，所有外部通信（包括作业提交）都基于HTTP / REST（FLINK-9280），从而大大简化了容器的设置。Flink 1.6.0还附带了一个容器入口点（FLINK-9488），该入口点可以轻松地引导容器化的作业集群。
流SQL是最具破坏性的功能之一，因为它使Flink更加易于访问。在Apache Flink 1.6.0中，社区进一步改进了SQL CLI（FLINK-8863），使针对大量数据源的流和批处理查询（FLINK-8861）的执行变得轻而易举。此外，对Avro的全面支持（FLINK-9444）使无缝读取任何类型的Avro数据成为可能。最后但并非最不重要的一点是，社区加强了Flink的CEP库（FLINK-9418），该库现在可以处理更大的用例。
没有连接器可以与外界对话的分布式处理引擎将是什么？在最新的Flink版本中，我们添加了一个新的StreamingFileSink（FLINK-9750），BucketingSink作为标准文件接收器而继之。该社区还增加了对ElasticSearch 6.x（FLINK-7386）的支持，并实现了多个AvroDeserializationSchemas（FLINK-9338）以轻松提取Avro数据。
新功能和改进
改善Flink的国家支持
支持状态TTL（FLINK-9510，FLINK-9938）：此功能允许为Flink状态指定生存时间（TTL）。一旦超过了生存时间，Flink将不再允许访问相应的状态值。过期数据将在访问时进行清理，以使操作员键控状态不会无限增长，并且不会包含在后续检查点中。此功能完全符合新的数据保护法规（例如GDPR）。
基于RocksDB（FLINK-9485）的可扩展计时器：Flink的计时器状态现在可以存储在RocksDB中，从而使该技术可以支持更大的计时器状态，因为它可以脱离核心/溢出到磁盘。以前，用户只能使用堆内存大小。最重要的是，计时器状态的快照现在是异步的，即它们不再在检查点期间阻塞处理管道，而是可以递增的。
更快的计时器删除（FLINK-9423）：改进Flink的内部计时器数据结构，以使删除复杂度从O（n）降低为O（log n）。这大大改善了使用计时器的Flink作业。现在，删除计时器也通过面向用户的API公开。
扩展Flink的部署选项
作业集群容器入口点（FLINK-9488）：Flink 1.6.0提供了易于使用的容器入口点，以引导作业集群。将此入口点与用户代码jar组合在一起，将创建一个自包含的映像，该映像在部署后会自动执行所包含的Flink作业。由于映像已经包含Flink作业，因此不再需要客户端通信。避免与客户端进行额外的通信步骤可减少活动部件的数量，并显着改善容器环境中的操作。
完全还原的作业提交（FLINK-9280）：Flink客户端现在通过一个POST调用将所有与作业相关的内容发送到服务器。由于不再需要打开自定义端口，因此可以更轻松地与群集管理框架和容器环境集成。
增强SQL和Table API
SQL Client CLI（FLINK-8863）中的用户定义功能：SQL Client CLI现在支持用户定义功能的注册。由于可以使用更强大的自定义表，聚合和标量函数来丰富SQL查询，因此极大地提高了CLI的表达能力。
SQL Client CLI（FLINK-8861）中对批查询的支持：SQL Client CLI现在支持批查询的执行。
在SQL Client CLI（FLINK-8858）中支持INSERT INTO语句：通过支持SQL的INSERT INTO语句，SQL Client CLI可以用于向Flink提交长时间运行的SQL查询，以将其结果存储在外部系统中。提交后可以关闭SQL Client本身，而无需停止作业。
统一表接收器和格式（FLINK-8866，FLINK-8558）：过去，表接收器必须以编程方式进行配置，并且必须与特定的格式和实现相关联。此版本通过从连接器中解耦格式并改进了发现和配置表接收器的方式对这些方面进行了改进。现在可以使用基于字符串的属性在YAML文件中定义表接收器，而无需编写任何代码。
新的Kafka表接收器（FLINK-9846）：Kafka表接收器现在使用新的统一API，并且支持JSON和Avro格式。
全面的SQL Avro支持（FLINK-9444）：Flink的Table＆SQL API现在可以理解所有的Avro类型，包括通用/特定记录和逻辑类型。这些类型自动与Flink等效类型相互映射，从而可以在SQL中指定端到端ETL管道。
SQL和Table API（FLINK-5878，FLINK-8688，FLINK-6810）的改进的表达能力：Flink的Table＆SQL API支持左，右和完全外部联接，从而允许连续更新结果。SQL聚合函数支持DISTINCT关键字。COUNT(DISTINCT column)窗口聚合和非窗口聚合支持诸如之类的查询。现在，SQL和Table API都包含更多的内置函数，例如MD5, SHA1, SHA2, LOG和UNNEST用于多集。
更多连接器
新增StreamingFileSink（FLINK-9750）：新增功能StreamingFileSink是一次写入文件系统的精确接收器，它利用了从先前获得的知识BucketingSink。通过将接收器与Flink的检查点机制集成在一起，可以完全支持一次。新的接收器基于Flink自己的FileSystem抽象构建，并支持本地文件系统和HDFS，并计划在不久的将来支持S3。它公开了可插拔文件滚动和存储策略。除行编码格式外，新版本还StreamingFileSink提供了对Parquet的支持。可以使用公开的API轻松添加其他批量编码格式（例如ORC）。
ElasticSearch 6.x连接器和对较旧版本的改进支持（FLINK-7386）：Flink现在带有ElasticSearch 6.x的连接器，该连接器建立在Elasticsearch的新高级REST客户端之上。对于仍使用本机Java的旧版ElasticSearch TransportClient，Flink的Elasticsearch连接器现在最多支持Elasticsearch 5.6.10版本。RequestIndexer'sElasticSearch连接器公共接口中的某些API已被弃用。请参考Javadoc /文档以获取新的首选API。
Avro反序列化架构（FLINK-9338）：Flink现在带有，DeserializationSchema它可以反序列化Avro编码的消息。它还添加了与Confluent架构注册表的现成集成。
基于Jepsen的分布式测试套件
Flink社区添加了一个基于Jepsen的测试套件（FLINK-9004），该套件验证了Flink的分布式集群组件在实际故障下的行为。这是迈向Flink容错机制更高测试覆盖率的第一步。社区打算以此来逐步提高测试覆盖率。
其他各种功能和改进
强化的CEP库（FLINK-9418）：CEP操作员的内部NFA状态现在由Flink状态支持。这样，它可以脱离核心来支持更大的用例。
更多富有表现力的DataStream联接（FLINK-8478）：Flink 1.6.0在DataStream API中添加了对间隔联接的支持。利用此功能，现在可以将来自不同流的事件合并在一起，其中一个流中的元素相对于另一流中的元素处于指定的时间间隔内。查看文档以获取更多详细信息。
集群内相互身份验证（FLINK-9312）：Flink的群集组件现在强制与对等方进行相互身份验证。这仅允许Flink组件相互通信，从而使恶意行为者无法冒充Flink组件以窃听集群通信。
1.7新特性
Flink 1.7.0-扩展流处理的范围
在Flink 1.7.0中，我们更加接近实现无缝链接的快速数据处理和为Flink社区构建数据密集型应用程序的目标。我们的最新版本包括一些令人兴奋的新功能和改进，例如对Scala 2.12的支持，一次S3文件接收器，复杂事件处理与流式SQL的集成以及我们将在下面介绍的更多功能。
新功能和改进
Apache Flink（FLINK-7811）中对Scala 2.12的支持：Apache Flink 1.7.0是第一个完全支持Scala 2.12的发行版。这使用户可以使用较新的Scala版本编写Flink应用程序，并利用Scala 2.12生态系统。
状态演化（FLINK-9376）：在许多情况下，由于需求不断变化，长期运行的Flink应用程序需要在其生命周期内进行演化。更改用户状态而不丢失其状态形式的当前应用程序进度是应用程序演进的关键要求。
使用Flink 1.7.0，社区增加了状态演化功能，使您可以灵活地适应长时间运行的应用程序的用户状态架构，同时保持与先前保存点的兼容性。通过状态演化，可以在状态模式中添加或删除列，以更改应用程序在部署后将捕获的业务功能。
现在，当使用Avro的生成类作为用户状态时，状态模式的演化即开即用，这意味着可以根据Avro的规范来演化状态的模式。自从Flink 1.7起，Avro类型是唯一支持架构演变的内置类型，但社区将继续努力，以在将来的Flink版本中进一步扩展对其他类型的支持。
一次S3 StreamingFileSink（FLINK-9752）：StreamingFileSink在Flink 1.6.0中引入的S3 StreamingFileSink（FLINK-9752）现在已扩展为还支持以一次精确的处理保证写入S3文件系统。使用此功能，用户可以构建一次写入S3的精确的端到端管道。
MATCH_RECOGNIZE流式SQL（FLINK-6935）中的支持：这是Apache Flink 1.7.0的主要补充，它MATCH_RECOGNIZE为Flink SQL提供了对该标准的初始支持。此功能将复杂事件处理（CEP）和SQL结合在一起，可以轻松地对数据流进行模式匹配，从而启用了一组新的用例。
此功能目前处于测试阶段，因此我们欢迎社区提供任何反馈和建议，以供将来进行迭代和改进。
流式SQL中的临时表和临时联接（FLINK-9712）：临时表是Apache Flink中的一个新概念，它为表的更改历史记录提供（参数化）视图，并在特定的时间点返回表的内容。
例如，我们可以使用具有历史货币汇率的表。随着时间的推移和增加了新近更新的汇率，该表一直在增长/发展。时间表是一种视图，可以将这些汇率的实际状态返回到任何给定的时间点。使用这样的表格，可以使用正确的汇率将不同货币的订单流转换为通用货币。
临时联接允许使用处理时间或事件时间，同时符合ANSI SQL的要求，通过不断变化/更新的表对流数据进行内存和计算高效的联接。
流式SQL的其他功能：除了上面提到的主要功能外，Flink的Table＆SQL API已得到扩展以服务更多的用例。
内置的功能被添加到API中的以下内容：TO_BASE64，LOG2，LTRIM，REPEAT，REPLACE，COSH，SINH，TANH
SQL客户端现在支持环境文件和CLI会话中的视图定义。此外，基本的SQL语句自动完成功能已添加到CLI。
社区添加了一个Elasticsearch 6表接收器，该接收器允许存储动态表的更新结果。
版本化的REST API（FLINK-7551）：从Flink 1.7.0开始，对REST API进行了版本化。这保证了Flink的REST API的稳定性，因此可以针对Flink中的稳定API开发第三方应用程序。因此，将来的Flink升级将不需要更改现有的第三方集成。
Kafka 2.0连接器（FLINK-10598）：Apache Flink 1.7.0继续添加了更多连接器，使其与更多外部系统进行交互变得更加容易。在此版本中，社区添加了Kafka 2.0连接器，该连接器允许在具有一次保证的情况下对Kafka 2.0进行读写。
本地恢复（FLINK-9635）：Apache Flink 1.7.0通过扩展Flink的计划以在恢复的情况下考虑以前的部署位置，从而完善了本地恢复功能。
如果启用了本地恢复，则Flink将在运行任务的计算机上保留最新检查点的本地副本。通过将任务调度到其先前位置，Flink将通过从本地磁盘读取检查点状态来最大程度地减少网络流量以恢复状态。此功能大大提高了恢复速度。
删除Flink的旧版模式（FLINK-10392）：Apache Flink 1.7.0标志着Flip-6工作已完全完成并达到与旧版模式相当的功能的发行版。因此，此版本删除了对旧模式的支持。
1.8新特性
新功能和改进
最终状态架构演变故事：此版本完成了社区驱动的工作，为Flink管理的用户状态提供了架构演变故事。从1.7.0版开始，这是一项跨越2个发行版的工作，引入了对Avro状态架构演变的支持以及改进的序列化兼容性抽象。
Flink 1.8.0通过将对模式演化的支持扩展到POJO，完成所有Flink内置序列化程序的升级以使用新的序列化兼容性抽象，以及使使用自定义状态序列化程序的高级用户更容易实现这些抽象，来完成这项工作。下面详细解释了完整的即用型架构演变故事的这些不同方面：
支持POJO状态模式演变：支持状态模式演变的数据类型池已扩展为包含POJO。对于使用POJO的状态类型，您现在可以在保持向后兼容性的同时从POJO中添加或删除字段。有关现在支持模式演化的数据类型列表及其演化规范和限制的完整概述，请参阅“状态模式演化”文档页面。
升级所有Flink序列化程序以使用新的序列化兼容性摘要：在1.7.0中，我们引入了新的序列化兼容性抽象TypeSerializerSnapshot 和TypeSerializerSchemaCompatibility。除了提供更可表达的API来反映存储点中存储的数据与运行时注册的数据之间的模式兼容性之外，关于新抽象的另一个重要方面是，它避免了Flink来将状态序列化程序作为保存点中的状态元数据进行Java序列化的需要。
在1.8.0中，所有Flink内置的序列化程序都已升级为使用新的抽象，因此，序列化程序本身不再被Java序列化为保存点。就状态模式的可扩展性而言，这极大地提高了Flink保存点的互操作性。例如，一个结果就是对POJO模式演变的支持，如上所述。另一个结果是Flink支持的所有复合数据类型（例如EitherScala案例类，Flink Java Tuple等）在具有嵌套可演化类型（例如POJO）时通常也可演化。例如，允许使用POMyPojo 类型的ValueState<Tuple2<Integer, MyPojo>>或中 的类型ListState<Either<Integer, MyPojo>>来扩展其模式。
对于正在TypeSerializer为其状态序列化程序使用自定义实现并且仍在使用过时的抽象（即TypeSerializerConfigSnapshot和 CompatiblityResult）的用户，我们强烈建议升级到新的抽象以供将来使用。请参阅“自定义状态序列化”文档页面，以获取有关新抽象的详细说明。
为常见的序列化程序提供预定义的快照实现：为了方便起见，Flink 1.8.0附带了两个预定义的实现，TypeSerializerSnapshot对于大多数TypeSerializers- SimpleTypeSerializerSnapshot和 的实现，使实现这些新抽象的任务更加容易CompositeTypeSerializerSnapshot。文档中的此部分提供有关如何使用这些类的信息。
基于TTL（FLINK-7811）连续清除旧状态：我们在Flink 1.6（FLINK-9510）中为键控状态引入了TTL（生存时间）。此功能启用了清除功能，并在定义的超时后使键状状态条目不可访问。此外，现在在写入保存点/检查点时也将清除状态。
Flink 1.8为RocksDB状态后端（FLINK-10471）和堆状态后端（FLINK-10473）引入了对旧条目的连续清除。这意味着旧条目（根据TTL设置）将被连续清除。
具有用户定义的函数和聚合的SQL模式检测：MATCH_RECOGNIZE子句的支持已通过多种功能扩展。用户定义功能的添加允许在模式检测期间自定义逻辑（FLINK-10597），而添加聚合则允许更复杂的CEP定义，例如以下内容（FLINK-7599）。
SELECT *
FROM Ticker
MATCH_RECOGNIZE (
ORDER BY rowtime
MEASURES
AVG(A.price) AS avgPrice
ONE ROW PER MATCH
AFTER MATCH SKIP TO FIRST B
PATTERN (A+ B)
DEFINE
A AS AVG(A.price) < 15
) MR;
符合RFC的CSV格式（FLINK-9964）：现在可以以符合RFC-4180标准的CSV表格式读取和写入SQL表。该格式对于一般的DataStream API用户也可能有用。
可以直接访问ConsumerRecord（FLINK-8354）的新KafkaDeserializationSchema：对于Flink KafkaConsumers，我们引入了一个KafkaDeserializationSchema可以直接访问Kafka的新功能ConsumerRecord。现在，这可以访问Kafka提供给记录的所有数据，包括标题。这包含了KeyedSerializationSchema功能，该功能已被弃用，但目前仍可用。
FlinkKinesisConsumer（FLINK-5697）中的每个分片水印选项：Kinesis Consumer现在可以发出从每个分片水印派生的周期性水印，以便使用消耗多个Kinesis分片的子任务正确处理事件时间。
DynamoDB流捕获表更改的新使用者（FLINK-4582）：FlinkDynamoDBStreamsConsumer 是Kinesis使用者的一种变体，它支持从DynamoDB表中检索类似CDC的流。
支持用于子任务协调的全局聚合（FLINK-10887）：被设计为用于全局源水印跟踪的解决方案，GlobalAggregateManager 允许在并行子任务之间共享信息。此功能将集成到流连接器中以实现水印同步，并且可以与用户定义的聚合器一起用于其他目的。
重要变化
使用Flink（FLINK-11266）绑定Hadoop库的更改：不再发布包含hadoop的便利二进制文件。
如果部署依赖flink-shaded-hadoop2于 flink-dist，则必须从下载页面的可选组件部分手动下载预先打包的Hadoop jar ，并将其复制到 /lib目录中。或者，可以通过打包flink-dist并激活 include-hadoopMaven配置文件来构建包含hadoop的Flink发行版。
由于flink-dist默认情况下不再包含hadoop ，因此指定 -DwithoutHadoop何时打包flink-dist不再影响构建。
FlinkKafkaConsumer现在将根据主题规范（FLINK-10342）过滤还原的分区：从Flink 1.8.0开始，FlinkKafkaConsumer现在始终过滤出不再与要在还原的执行中订阅的指定主题关联的还原的分区。的早期版本中不存在此行为FlinkKafkaConsumer。如果您希望保留以前的行为，请使用上的 disableFilterRestoredPartitionsWithSubscribedTopics()配置方法FlinkKafkaConsumer。
考虑以下示例：如果您有一个从topic消费的Kafka使用者，则执行A了一个保存点，然后将您的Kafka使用者更改为改为从topic进行消费B，然后从该保存点重新开始工作。在进行此更改之前，您的使用者现在将同时从主题中进行消费，A并且 B因为它以使用者正在从topic中进行消费的状态进行存储 A。进行更改后，您的使用者将仅B在还原后从主题中消费，因为它现在使用已配置的主题过滤存储在状态中的主题。
Table API的Maven模块中的更改（FLINK-11064）：以前具有flink-table依赖项的用户需要根据使用Java或Scala来更新其依赖项flink-table-planner以及正确的依赖项 flink-table-api-*，具体取决于所使用的是Java还是Scala： flink-table-api-java-bridge或flink-table-api-scala-bridge。
已知的问题
丢弃的检查点可能导致任务失败（FLINK-11662）：存在竞争状况，可能导致错误的检查点失败。从作业点从保存点重新启动或检查点需要很长时间时，通常会发生这种情况。如果您看到似乎没有很好解释的随机检查点失败，则可能会受到影响。请参阅Jira问题以获取更多详细信息和解决方法。
1.9 新特性
新功能和改进
细粒度的批量恢复（FLIP-1）
从任务失败中恢复批处理（DataSet，Table API和SQL）作业的时间大大减少了。在Flink 1.9之前，可以通过取消所有任务并重新启动整个作业来恢复批处理作业中的任务失败，即，该作业从头开始，所有进度都无效。在此版本中，可以将Flink配置为将恢复限制为仅在同一故障转移区域中的那些任务。故障转移区域是通过流水线数据交换连接的一组任务。因此，作业的批处理混洗连接定义了其故障转移区域的边界。FLIP-1中提供了更多详细信息 。 alt_text
要使用此新的故障转移策略，您需要执行以下设置：
确保您的条目jobmanager.execution.failover-strategy: region中有该条目flink-conf.yaml。
注意： 1.9发行版的配置默认情况下具有该条目，但是当重新使用先前设置中的配置文件时，必须手动添加它。
此外，您需要在中设置ExecutionMode批处理作业的 ExecutionConfig，BATCH以配置数据传输不进行流水线化，并且作业具有多个故障转移区域。
“区域”故障转移策略还提高了“令人尴尬的并行”流作业的恢复，即没有keyBy（）或重新平衡之类的任何混洗的作业。恢复此类作业后，仅重新启动受影响管道（故障转移区域）的任务。对于所有其他流作业，恢复行为与以前的Flink版本相同。
状态处理器API（FLIP-43）
在Flink 1.9之前，从外部访问作业状态仅限于（仍）实验性Queryable State。此版本引入了一个新的功能强大的库，以使用批处理DataSet API读取，写入和修改状态快照。实际上，这意味着：
可以通过从外部系统（例如，外部数据库）读取数据并将其转换为保存点来引导Flink作业状态。
可以使用Flink的任何批处理API（数据集，表，SQL）查询保存点中的状态，例如分析相关状态模式或检查状态差异以支持应用程序审核或故障排除。
与之前需要在线访问模式迁移的方法相比，保存点中的状态模式可以离线迁移。
可以识别并更正保存点中的无效数据。
新的状态处理器API涵盖了快照的所有变体：保存点，完整检查点和增量检查点。FLIP-43提供了更多详细信息
停止保存点（FLIP-34）
使用保存点取消 是停止/重新启动，派生或更新Flink作业的常用操作。但是，现有的实现方式无法保证一次接收器对外部存储系统的输出持久性。为了改善停止作业时的端到端语义，Flink 1.9引入了一种新SUSPEND模式来停止具有与发出的数据一致的保存点的作业。您可以使用Flink的CLI客户端挂起作业，如下所示：
bin/flink stop -p [:targetDirectory] :jobId
最终作业状态设置为FINISHED“成功”，从而允许用户检测到所请求操作的失败。
FLIP-34提供了更多详细信息
Flink WebUI返工
在讨论 了Flink WebUI内部的现代化讨论之后 ，使用最新的Angular稳定版本重建了该组件-基本上是从Angular 1.x升级到7.x。重新设计的版本是1.9.0中的默认版本，但是有一个链接可以切换到旧的WebUI。
注意：今后，将无法保证旧版本WebUI的功能奇偶性。
新的Blink SQL查询处理器预览
在将Blink捐赠给Apache Flink之后，该社区致力于为Table API和SQL集成Blink的查询优化器和运行时。第一步，我们将整体flink-table模块重构为较小的模块（FLIP-32）。这导致Java和Scala API模块以及优化器和运行时模块之间的接口清晰明确地定义。
接下来，我们扩展了Blink的计划程序，以实现新的优化程序接口，以便现在有两个可插入的查询处理器来执行Table API和SQL语句：1.9之前的Flink处理器和新的基于Blink的查询处理器。基于Blink的查询处理器提供了更好的SQL覆盖范围（1.9中完整的TPC-H覆盖范围，计划在下一版本中提供TPC-DS覆盖范围），并且由于更广泛的查询优化（基于成本的计划选择）而提高了批处理查询的性能。以及更多优化规则），改进的代码生成和优化的操作员实施方式。基于Blink的查询处理器还提供了更强大的流式运行器，具有一些新功能（例如，维表联接，TopN，重复数据删除）和优化以解决聚合中的数据偏斜以及更有用的内置功能。
注意：查询处理器的语义和支持的操作集大部分是但不完全一致的。
但是，Blink的查询处理器的集成尚未完全完成。因此，1.9之前的Flink处理器仍然是Flink 1.9中的默认处理器，并建议用于生产设置。您可以通过EnvironmentSettings在创建时 通过配置眨眼处理器来启用它TableEnvironment。所选处理器必须在执行Java进程的类路径上。对于群集设置，两个查询处理器都将自动以默认配置加载。从IDE运行查询时，您需要向项目中显式添加计划程序依赖项 。
Table API和SQL的其他改进
除了Blink计划程序的令人兴奋的进展之外，社区还对这些界面进行了一系列其他改进，包括：
适用于Java用户的无Scala表API和SQL（FLIP-32）
作为重构和拆分flink-table模块的一部分，创建了两个单独的Java和Scala API模块。对于Scala用户而言，什么都没有真正改变，但是Java用户现在可以使用Table API和/或SQL，而无需引入Scala依赖项。
表格API类型系统 （FLIP-37）的返工
社区实施了一个新的数据类型系统， 以将Table API与Flink的TypeInformation 类分离， 并提高其与SQL标准的兼容性。这项工作仍在进行中，预计将在下一个版本中完成。在Flink 1.9中，UDF以及其他功能还没有移植到新类型的系统中。
表API （FLIP-29）的多列和多行转换
通过一系列支持多行和/或多列输入和输出的转换，扩展了Table API的功能。这些转换极大地简化了处理逻辑的实现，而对于关系运算符而言，这些处理逻辑将非常麻烦。
新的统一目录API （FLIP-30）
我们重新设计了目录API，以存储元数据并统一了内部和外部目录的处理。这项工作主要是作为Hive集成的前提条件而发起的（请参见下文），但是提高了在Flink中管理目录元数据的整体便利性。除了改进目录界面之外，我们还扩展了它们的功能。以前，Table API或SQL查询的表定义是可变的。使用Flink 1.9，可以将用SQL DDL语句注册的表的元数据保留在目录中。这意味着您可以将由Kafka主题支持的表添加到Metastore目录中，然后在您的目录连接到Metastore时查询该表。
SQL API中的DDL支持（FLINK-10232）
到现在为止，弗林克SQL只支持DML语句（如SELECT， INSERT）。外部表（表源和接收器）必须通过Java / Scala代码或配置文件进行注册。对于1.9，我们增加了对SQL DDL语句的支持，以注册和删除表和视图（CREATE TABLE, DROP TABLE)。但是，我们没有添加特定于流的语法扩展来定义时间戳提取和水印生成。下一个版本。
完整Hive集成预览（FLINK-10556）
Apache Hive在Hadoop生态系统中被广泛使用，以存储和查询大量结构化数据。除了作为查询处理器之外，Hive还具有一个名为Metastore的目录，用于管理和组织大型数据集。查询处理器的常见集成点是与Hive的Metastore集成，以便能够利用Hive管理的数据。
最近，社区开始为Flink的Table API和SQL实施连接到Hive的Metastore的外部目录。在Flink 1.9中，用户将能够查询和处理Hive中存储的所有数据。如前所述，您还可以将Flink表的元数据保留在Metastore中。此外，Hive集成还包括支持在Flink Table API或SQL查询中使用Hive的UDF。FLINK-10556中提供了更多详细信息 。
虽然以前，Table API或SQL查询的表定义始终是可变的，但新的目录连接器还允许将表保留在使用SQL DDL语句创建的Metastore中（请参见上文）。这意味着您连接到Metastore并注册一个表，该表例如由Kafka主题支持。从现在开始，只要您的目录连接到Metastore，就可以查询该表。
请注意，Flink 1.9中的Hive支持是试验性的。我们计划在下一个版本中稳定这些功能，并期待您的反馈。
新的Python Table API预览（FLIP-38）
此版本还引入了Python Table API（FLIP-38）的第一个版本。这标志着我们向Flink提供完善的Python支持的目标的开始。该功能被设计为Table API的瘦Python API包装器，基本上将Python Table API方法调用转换为Java Table API调用。在Flink 1.9附带的初始版本中，Python Table API尚不支持UDF，而仅支持标准关系操作。在将来的版本中，将以Python实现对UDF的支持。
如果您想尝试新的Python API，则必须手动安装PyFlink。从那里，您可以看一下本演练，也可以 自己探索。该社区当前正在 准备一个pyflinkPython软件包，该软件包可通过安装pip。
重要变化
Table API和SQL现在是Flink发行版默认配置的一部分。以前，必须通过将相应的JAR文件从./opt移到./lib来启用Table API和SQL。
机器学习库（flink-ml）已被删除，以准备 FLIP-39。
为了支持FLIP-38，已删除了旧的DataSet和DataStream Python API 。
Flink可以在Java 9上编译并运行。请注意，某些与外部系统交互的组件（连接器，文件系统，报告器）可能无法工作，因为各个项目可能已跳过Java 9支持。
1.10新特性
新功能和改进
改进的内存管理和配置
TaskExecutorFlink中的当前内存配置存在一些缺点，这些缺点使得难以推理或优化资源利用率，例如：
流和批处理执行中用于内存占用的不同配置模型；
流执行中堆外状态后端（即RocksDB）的复杂且依赖用户的配置。
为了使内存选项对用户更明确和直观，Flink 1.10对TaskExecutor内存模型和配置逻辑（FLIP-49）进行了重大更改。这些变化使Flink更适合于各种部署环境（例如Kubernetes，Yarn，Mesos），从而使用户可以严格控制其内存消耗。
托管内存扩展
托管内存已扩展为还考虑了的内存使用情况RocksDBStateBackend。虽然批处理作业可以使用堆上或堆外内存，但具有流的作业RocksDBStateBackend只能使用堆上内存。因此，为了允许用户在流执行和批处理执行之间切换而不必修改群集配置，托管内存现在始终处于堆外状态。
简化的RocksDB配置
配置像RocksDB这样的堆外状态后端曾经涉及大量的手动调整，例如减小JVM堆大小或将Flink设置为使用堆外内存。现在，这可以通过Flink的现成配置来实现，并且调整内存预算RocksDBStateBackend就像调整受管内存大小的大小一样简单。
另一个重要的改进是允许Flink绑定RocksDB本机内存使用情况（FLINK-7289），防止其超出总内存预算-这在Kubernetes等容器化环境中尤其重要。有关如何启用和调整此功能的详细信息，请参阅Tuning RocksDB。
注意FLIP-49更改了群集资源配置的过程，这可能需要调整群集以从以前的Flink版本进行升级。有关所引入的更改和调优指南的全面概述，请参阅此设置。
提交作业的统一逻辑
在此版本之前，提交作业是执行环境职责的一部分，并且与不同的部署目标（例如，Yarn，Kubernetes，Mesos）紧密相关。这导致关注点分离不佳，并且随着时间的流逝，用户需要单独配置和管理的定制环境数量不断增加。
在Flink 1.10中，作业提交逻辑被抽象到通用Executor接口（FLIP-73）中。加入的ExecutorCLI（FLIP-81）引入到用于指定配置参数以统一的方式的任何 执行对象。为了完成这项工作，结果检索的过程也与作业提交脱钩，引入了JobClient（FLINK-74），该任务负责获取.FLINK-74JobExecutionResult。
尤其是，通过为用户提供Flink的统一入口点，这些更改使在下游框架（例如Apache Beam或Zeppelin交互式笔记本）中以编程方式使用Flink变得更加容易。对于跨多个目标环境使用Flink的用户，向基于配置的执行过程的过渡还可以显着减少样板代码和可维护性开销。
原生Kubernetes集成（测试版）
对于希望在容器化环境上开始使用Flink的用户，在Kubernetes之上部署和管理独立集群需要一些有关容器，操作员和特定于环境的工具（如）的先验知识kubectl。
在Flink 1.10中，我们推出了Active Kubernetes集成（FLINK-9953）的第一阶段，该阶段支持会话集群（计划了每个作业）。在这种情况下，“活动”是指Flink的ResourceManager（K8sResMngr）与Kubernetes进行本地通信以按需分配新的Pod，类似于Flink的Yarn和Mesos集成。用户还可以利用命名空间为聚合资源消耗有限的多租户环境启动Flink集群。事先配置具有足够权限的RBAC角色和服务帐户。
正如在“提交作业的统一逻辑”中介绍的那样，Flink 1.10中的所有命令行选项都映射到统一配置。因此，用户可以简单地参考Kubernetes配置选项，并使用以下命令在CLI中将作业提交到Kubernetes上的现有Flink会话：
./bin/flink run -d -e kubernetes-session -Dkubernetes.cluster-id=<ClusterId> examples/streaming/WindowJoin.jar
如果您想尝试使用此预览功能，我们建议您逐步完成Native Kubernetes的安装，试用并与社区分享反馈。
表API / SQL：生产就绪的Hive集成
Hive集成在Flink 1.9中宣布为预览功能。此预览允许用户使用SQL DDL将特定于Flink的元数据（例如Kafka表）保留在Hive Metastore中，调用Hive中定义的UDF并使用Flink读取和写入Hive表。Flink 1.10通过进一步的开发进一步完善了这项工作，这些开发使可立即投入生产的Hive集成到Flink，并具有与大多数Hive版本的完全兼容性。
批处理SQL的本机分区支持
到目前为止，仅支持对未分区的Hive表的写入。在Flink 1.10中，Flink SQL语法已通过INSERT OVERWRITE和PARTITION（FLIP-63）进行了扩展，从而使用户能够在Hive中写入静态和动态分区。
静态分区写入
INSERT { INTO | OVERWRITE } TABLE tablename1 [PARTITION (partcol1=val1, partcol2=val2 ...)] select_statement1 FROM from_statement;
动态分区编写
INSERT { INTO | OVERWRITE } TABLE tablename1 select_statement1 FROM from_statement;
完全支持的分区表允许用户利用读取时的分区修剪功能，通过减少需要扫描的数据量来显着提高这些操作的性能。
进一步优化
除了分区修剪外，Flink 1.10还为Hive集成引入了更多读取优化，例如：
投影下推： Flink利用投影下推功能，通过从表扫描中删除不必要的字段来最大程度地减少Flink和Hive表之间的数据传输。这对于具有大量列的表尤其有利。
LIMIT下推：对于带有LIMIT子句的查询，Flink将尽可能限制输出记录的数量，以最大程度地减少通过网络传输的数据量。
读取时进行ORC矢量化：为了提高ORC文件的读取性能，Flink现在默认将本机ORC矢量化阅读器用于2.0.0以上的Hive版本和具有非复杂数据类型的列。
可插拔模块作为Flink系统对象（Beta）
Flink 1.10引入了Flink表核心中可插拔模块的通用机制，首先关注系统功能（FLIP-68）。使用模块，用户可以扩展Flink的系统对象-例如，使用行为类似于Flink系统功能的Hive内置函数。该版本附带一个预先实现的HiveModule，支持多个Hive版本的版本，但用户也可以编写自己的可插拔模块。
Table API / SQL的其他改进
SQL DDL中的水印和计算列
Flink 1.10支持特定于流的语法扩展，以在Flink SQL DDL（FLIP-66）中定义时间属性和水印生成。这允许基于时间的操作（例如加窗），以及在使用DDL语句创建的表上定义水印策略。
CREATE TABLE table_name (
WATERMARK FOR columnName AS <watermark_strategy_expression>
) WITH (
...
)
此版本还引入了对虚拟计算列（FLIP-70）的支持，该列可基于同一表中的其他列或确定性表达式（即，文字值，UDF和内置函数）派生。在Flink中，计算列可用于在创建表时定义时间属性。
SQL DDL的其他扩展
现在，临时/持久功能与系统/目录功能（FLIP-57）之间有明显的区别。这不仅消除了函数引用中的歧义，而且允许确定性的函数解析顺序（即，在命名冲突的情况下，系统函数将优先于目录函数，而临时函数的优先级高于两个维度的持久性函数）。
遵循FLIP-57的基础知识，我们扩展了SQL DDL语法，以支持目录功能，临时功能和临时系统功能（FLIP-79）的创建：
CREATE [TEMPORARY|TEMPORARY SYSTEM] FUNCTION
[IF NOT EXISTS] [catalog_name.][db_name.]function_name
AS identifier [LANGUAGE JAVA|SCALA]
有关Flink SQL中DDL支持的当前状态的完整概述，请查看更新的文档。
注意为了在将来正确处理和保证元对象（表，视图，函数）之间的行为一致，不建议使用Table API中的某些对象声明方法，而应使用更接近标准SQL DDL的方法（FLIP -64）。
TPC-DS的完整覆盖范围可批量处理
TPC-DS是一种广泛使用的行业标准决策支持基准，用于评估和衡量基于SQL的数据处理引擎的性能。在Flink 1.10中，端到端（FLINK-11491）支持所有TPC-DS查询，这反映了它的SQL引擎已准备就绪，可以满足类似现代数据仓库的工作负载的需求。
PyFlink：支持本机用户定义的函数（UDF）
在以前的发行版中引入了PyFlink的预览版，朝着Flink全面支持Python的目标迈进了一步。对于此发行版，重点是使用户能够在表API / SQL（FLIP-58）中注册和使用Python用户定义函数（UDF，已计划UDTF / UDAF ）。
如果您对基础实现感兴趣（利用Apache Beam的可移植性框架），请参考FLIP-58的“体系结构”部分，也请参考FLIP-78。这些数据结构为Pandas支持和PyFlink最终到达DataStream API奠定了必要的基础。
从Flink 1.10开始，用户还可以通过pip使用以下命令轻松安装PyFlink ：
pip install apache-flink
有关PyFlink计划进行的其他改进的预览，请查看FLINK-14500并参与有关所需用户功能的讨论。
重要变化
[ FLINK-10725 ] Flink现在可以编译并在Java 11上运行。
[ FLINK-15495 ] Blink计划程序现在是SQL Client中的默认设置，因此用户可以从所有最新功能和改进中受益。还计划在下一个版本中使用Table API中的旧计划程序进行切换，因此我们建议用户开始熟悉Blink计划程序。
[ FLINK-13025 ]有一个新的Elasticsearch接收器连接器，完全支持Elasticsearch 7.x版本。
[ FLINK-15115 ] Kafka 0.8和0.9的连接器已标记为已弃用，将不再得到积极支持。如果您仍在使用这些版本或有任何其他相关问题，请联系@dev邮件列表。
[ FLINK-14516 ]删除了非基于信用的网络流控制代码以及配置选项taskmanager.network.credit.model。展望未来，Flink将始终使用基于信用的流量控制。
[ FLINK-12122 ] FLIP-6在Flink 1.5.0中推出，并引入了与从中分配插槽的方式有关的代码回归TaskManagers。要使用更接近pre-FLIP行为的调度策略（Flink尝试将工作负载分散到所有当前可用的工作负载中）TaskManagers，用户可以cluster.evenly-spread-out-slots: true在中设置flink-conf.yaml。
[ FLINK-11956 ]s3-hadoop和s3-presto文件系统不再使用类重定位，而应通过插件加载，但现在可以与所有凭据提供程序无缝集成。强烈建议将其他文件系统仅用作插件，因为我们将继续删除重定位。
Flink 1.9附带了重构的Web UI，保留了旧版的UI作为备份，以防万一某些功能无法正常工作。到目前为止，尚未报告任何问题，因此社区投票决定在Flink 1.10中删除旧版Web UI。
1.11特性
新功能和改进
未对齐的检查点（测试版）
在Flink中触发检查点将导致检查点障碍从拓扑源一直流向接收器。对于接收多个输入流的操作员，需要对齐流过每个通道的障碍物，然后操作员才能快照其状态并转发检查点障碍物-通常，这种对齐仅需几毫秒即可完成，但可能会变成几秒钟。背压管道的瓶颈如下：
检查点障碍物在反压通道中的流动会慢得多，从而在检查点期间有效地阻塞了其余通道及其上游操作员。
缓慢的检查点屏障传播会导致更长的检查点时间，并且在最坏的情况下，可能导致应用程序进展缓慢甚至没有进展。
为了提高背压情况下检查点的性能，社区正在使用Flink 1.11推出未对齐检查点（FLIP-76）的第一版。与原始检查点机制（图1）相比，此方法无需等待输入通道之间的障碍物对齐，而是允许障碍物超过飞行中的记录（即，存储在缓冲区中的数据）并在同步部分之前将其转发到下游检查点的位置发生了（图2）。
对齐的检查点
图1：对齐的检查点
未对齐的检查点
图2：未对齐的检查点
由于必须将飞行中的记录作为快照的一部分进行保留，因此未对齐的检查点将导致检查点大小增加。从好的方面来说，检查点时间将大大减少，因此，用户将看到更多的进展（即使在不稳定的环境中），因为更多的最新检查点将减轻恢复过程。您可以在文档中了解有关未对齐检查点当前限制的更多信息，并可以在FLINK-14551中跟踪为此功能计划的改进工作。
与任何测试版功能一样，我们非常感谢您提供早期反馈，您可以在尝试给未对齐的检查点后与社区分享！
信息要启用此功能，您需要enableUnalignedCheckpoints在checkpoint config中配置该选项。请注意，只有将checkpointingMode设置为，才能启用未对齐的检查点CheckpointingMode.EXACTLY_ONCE。
统一水印生成器
到目前为止，水印生成（也称为赋值）依赖于两个不同的接口：AssignerWithPunctuatedWatermarks和AssignerWithPeriodicWatermarks；与时间戳提取紧密相关。除了导致代码重复和维护负担外，这使得难以实施长期要求的功能，例如对空闲检测的支持。用FLIP-126，遗留水印assigners被统一成一个单一的接口：WatermarkGenerator; 并与之分离TimestampAssigner。
这使用户可以更好地控制水印的发射，并简化了新连接器的实现，这些连接器需要在源头支持水印分配和时间戳提取（请参见New Data Source API）。多重数字水印的策略是可用出的即装即用，如弗林克1.11方便的方法（例如forBoundedOutOfOrderness，forMonotonousTimestamps），虽然你也可以选择定制自己的。
支持水印空闲检测
WatermarkStrategy.withIdleness()如果在配置的时间（即超时时间）内没有事件到达，则该方法允许您将流标记为空闲，这进而允许正确处理事件时间偏差，并防止空闲分区阻止整个应用程序的事件时间进度。用户已经可以从Kafka连接器中的每分区空闲检测中受益，该连接器已被适配为使用新接口（FLINK-17669）。
注意 FLIP-126不会带来重大变化，但我们建议用户优先使用WatermarkGenerator向前发展的新界面，以准备在将来的版本中弃用旧版水印分配器。
新数据源API（测试版）
到目前为止，为Flink编写生产级源连接器是一项艰巨的任务，它要求用户一定程度上熟悉Flink的内部结构，并在代码中考虑事件时间分配，水印生成或空闲检测等实现细节。Flink 1.11引入了新的数据源API（FLIP-27），以克服这些限制以及需要重写单独的代码以进行批处理和流式执行的需求。
资料来源API
将拆分发现工作与实际读取的消耗数据（即拆分）分开在不同的组件中进行。在SplitEnumerator和SourceReader-允许混合和匹配不同的枚举策略和分裂的读者。
例如，现有的Kafka连接器具有多种用于分区发现的策略，这些策略与其余代码混合在一起。有了新接口，它将只需要一个读取器实现，并且就不同的分区发现策略而言，可以有多个拆分的枚举器。
批量和流统一
使用Data Source API实现的源连接器将既可以作为有界（批处理）源也可以作为无界（流媒体）源工作。两种情况之间的差异很小：对于有界输入，SplitEnumerator将会生成固定的分割集合，每个分割都是有限的；对于无界输入，拆分不是有限的，或者SplitEnumerator保持生成新拆分。
隐式水印和事件时间处理
该TimestampAssigner和WatermarkGenerator作为的一部分透明地运行SourceReader组件，因此用户也不必实现任何时间戳提取或水印生成代码。
注意尚未使用Data Source API重新实现现有的源连接器-已计划在即将发布的版本中使用。如果您想实现一个新的源，请参阅数据源文档和有关源开发的技巧。
应用模式部署
在Flink 1.11之前，Flink应用程序中的作业可以提交到长时间运行的Flink会话群集（会话模式）或专用的Flink作业群集（作业模式）。对于这两种模式，main()用户程序的方法都在客户端运行。这就带来了一些挑战：一方面，如果客户端是大型安装的一部分，那么它很容易成为生成瓶颈JobGraph。另一方面，它不适用于Docker或Kubernetes等容器化环境。
从此版本开始，Flink获得了其他部署模式：应用程序模式（FLIP-85）；该main()方法在群集而不是客户端上运行的位置。作业提交成为一个单步过程：将应用程序逻辑和依赖项打包到可执行的作业JAR中，集群入口点（ApplicationClusterEntryPoint）负责调用main()方法以提取JobGraph。
在Flink 1.11中，社区致力于在Kubernetes（FLINK-10934）中支持应用程序模式。
其他改进
JobManager的统一内存配置（FLIP-116）
在Flink 1.10中开始进行改进内存管理和配置的工作之后，此版本引入了新的内存模型，该模型使JobManagers的配置选项和术语与FLIP-49中针对TaskManagers引入的配置选项和术语保持一致。这会影响所有部署类型：独立部署，YARN，Mesos和新的活动Kubernetes集成。
注意：重用以前的Flink配置而不进行任何调整可能会导致JVM的计算内存参数不同，结果，性能会发生变化甚至出现故障。如果您打算更新到最新版本，请确保查看迁移指南。
对Flink WebUI（FLIP-75）的改进
在Flink 1.11中，社区开始了对Flink WebUI的一系列改进。首先推出的是更好的TaskManager和JobManager日志显示（FLIP-103），以及新的线程转储实用程序（FLINK-14816）。为即将发布的版本计划的一些其他工作包括更好的背压检测，更灵活和可配置的异常显示以及支持显示子任务失败尝试的历史记录。
Docker映像统一（FLIP-111）
在此版本中，所有与Docker相关的资源都已合并到apache / flink-docker中，并且扩展了入口点脚本，以允许用户以不同的模式运行默认Docker映像，而无需创建自定义映像。该更新的文档详细描述了如何使用和定制弗林克码头工人的官方图片为不同的环境和部署模式。
表API / SQL：支持更改数据捕获（CDC）
更改数据捕获（CDC）已成为一种流行的模式，用于从数据库中捕获已提交的更改并将这些更改传播到下游使用者，例如保持多个数据存储同步并避免常见的陷阱（例如双重写入）。在Flink社区中，能够轻松地将这些变更日志提取并解释为Table API / SQL的功能是Flink社区中非常需要的功能-现在Flink 1.11可以实现这一功能。
为了将Table API / SQL的范围扩展到CDC之类的用例，Flink 1.11引入了具有changelog模式的新表源和接收器接口（请参见New TableSource和TableSink接口），并支持Debezium和Canal格式（FLIP-105）。这意味着动态表源不再仅限于附加的操作和可以摄取这些外部更改日志（INSERT事件），将它们解释为改变操作（INSERT，UPDATE，DELETE事件），并发射它们与变化类型下游。
CDC
用户必须在语句中指定“format=debezium-json”或“format=canal-json”在其中CREATE TABLE使用SQL DDL消耗变更日志。
CREATE TABLE my_table (
...
) WITH (
'connector'='...', -- e.g. 'kafka'
'format'='debezium-json',
'debezium-json.schema-include'='true' -- default: false (Debezium can be configured to include or exclude the message schema)
'debezium-json.ignore-parse-errors'='true' -- default: false
);
Flink 1.11仅支持Kafka作为现成的变更日志源和JSON编码的变更日志，而Avro（Debezium）和Protobuf（Canal）计划在将来的版本中使用。还计划支持MySQL二进制日志和Kafka压缩主题作为源，并将扩展日志支持扩展到批处理执行。
注意有一个已知的问题（FLINK-18461），它阻止将changelog源用于写入upsert接收器（例如MySQL，HBase，Elasticsearch）。这将在下一个修补程序版本（1.11.1）中修复。
表API / SQL：JDBC目录接口和Postgres目录
Flink 1.11引入了一个通用的JDBC目录接口（FLIP-93），该接口使Table API / SQL的用户能够自动从JDBC到关系数据库的连接中派生表模式。这消除了以前对手动模式定义和类型转换的需求，并且还允许在编译时而不是运行时检查模式错误。
随着新版本推出的第一个实现是Postgres目录。
表API / SQL：具有对Avro，ORC和Parquet的支持的FileSystem连接器
为了改善端到端流ETL用例的用户体验，Flink社区为Table API / SQL（FLIP-115）开发了一个新的FileSystem连接器。该实现基于Flink的FileSystem抽象，并重用StreamingFileSink以确保与DataStream API相同的功能集和一致的行为。
这也意味着Table API / SQL用户现在可以使用StreamingFileSink已经支持的所有格式，例如（Avro）Parquet，以及此版本引入的新格式，例如Avro（FLINK-11395）和Orc（FLINK- 10114）。
CREATE TABLE my_table (
column_name1 INT,
column_name2 STRING,
...
part_name1 INT,
part_name2 STRING
) PARTITIONED BY (part_name1, part_name2) WITH (
'connector' = 'filesystem',
'path' = 'file:///path/to/file,
'format' = '...', -- supported formats: Avro, ORC, Parquet, CSV, JSON
...
);
全新的多功能文件系统连接器可透明地处理批处理和流式执行，提供一次精确的保证，并具有完整的分区支持，从而大大扩展了传统连接器的使用范围。这使用户可以轻松实现常见用例，例如将数据从Kafka直接流式传输到Hive。
您可以在FLINK-17778中跟踪对FileSystem连接器的即将进行的改进。
表API / SQL：对Python UDF的支持
在此版本之前，Table API / SQL的用户仅限于使用Java或Scala定义UDF。在Flink 1.11中，社区致力于将Python语言的使用范围扩展到PyFlink之外，并以SQL DDL语法（FLIP-106）和SQL Client（FLIP-114）提供对Python UDF的支持。用户还可以通过SQL DDL或Java Catalog API在系统目录中注册Python UDF，以便可以在作业之间共享功能。
Table API / SQL的其他改进
Hive连接器（FLIP-123）的DDL和DML兼容性
从Flink 1.11开始，用户可以在Table API / SQL和SQL Client中使用Hive语法（HiveQL）直接编写SQL语句。为此，引入了另一种方言，并且用户现在可以基于每个语句在Flink（default）和Hive（hive）之间动态切换。有关受支持的DDL和DML语句的完整列表，请查看Hive方言文档。
对Flink SQL语法的扩展和改进
Flink 1.11引入了主键约束的概念，以利用Flink SQL DDL（FLIP-87）中的运行时优化；
现在，使用CREATE/ ALTER/DROP VIEW语句（FLIP-71）在SQL DDL中完全支持视图对象。
用户现在可以使用动态表选项（FLIP-113）在其DQL / DML语句中指定或覆盖表选项。
为了减少连接器属性的详细程度并改善异常处理，已重构了一些关键属性（FLIP-122）。此更改不会破坏兼容性，因此用户仍然可以使用旧的属性键。
新的TableSource和TableSink接口（FLIP-95）
Flink 1.11引入了新的表源和接收器接口（分别是DynamicTableSource和DynamicTableSink），它们统一了批处理和流执行，并通过Blink计划程序提供了更有效的数据处理，并提供了处理变更日志的支持（请参阅对变更数据捕获（CDC）的支持）。新界面还使用户更容易实现自定义连接器或修改现有连接器。有关如何使用支持更改日志语义的解码格式实现自定义扫描表源的端到端示例，请参阅文档。
注意尽管兼容性不会立即受到影响，但我们建议Table API / SQL用户将所有源和接收器更新到新的接口堆栈。
重构表环境接口（FLIP-84）
随着时间的流逝，用于描述TableEnvironment和Table接口中类似行为的语义有所不同，从而导致不一致的用户体验，有时甚至是不清楚的用户体验。为了改善这一点，使编程表API中更流畅/ SQL，弗林克1.11介绍新方法，像执行统一的行为触发（如executeSql()）和结果表示（例如print()，collect()），同时也奠定基础一样重要特征多语句执行在将来的版本中提供支持。
注意FLIP-84不推荐使用的方法不会立即删除，但是我们建议用户采用新引入的方法。有关新方法和不推荐使用的方法的完整列表，请查看FLIP-84的“摘要”部分。
表API UDF的新类型推断（FLIP-65）
在Flink 1.9中，社区开始为Table API开发新的数据类型系统，以提高其与SQL标准（FLIP-37）的兼容性。现在，Flink 1.11中的这项工作已接近完成，因为Table API UDF暴露于新型系统（标量和表函数，以及计划在下一发行版中使用的集合函数）。
PyFlink：支持熊猫UDF
在此版本之前，PyFlink中的Python UDF仅支持标准Python类型的标量值。这带来了一些限制：
在JVM和Python进程之间传输数据的过程中，很高的序列化/反序列化开销；
难以与常见的Python库集成，以实现诸如pandas和NumPy之类的高性能数值处理。
为了克服这些限制，社区在Flink 1.11（FLIP-97）中引入了对基于熊猫的（标量）矢量化Python UDF的支持。向量化UDF的性能通常要高得多，因为可以通过使用Apache Arrow来最小化序列化/反序列化的开销。和作为输入/输出的处理可以充分利用pandas和NumPy库。这使得Pandas UDF成为使机器学习和其他大规模分布式数据科学工作负载（例如功能工程，分布式模型应用程序）并行化的流行解决方案。pandas.Series
@udf(input_types=[DataTypes.BIGINT(), DataTypes.BIGINT()], result_type=DataTypes.BIGINT(), udf_type="pandas")
def add(i, j):
return i + j
要将UDF标记为Pandas UDF，只需udf_type=”pandas”在udf装饰器中添加一个额外的参数，如文档所述。
PyFlink的其他改进
从熊猫转换为熊猫（FLIP-120）
还支持使用Arrow作为在PyFlink表和之间进行转换的优化pandas.DataFrames，从而使用户能够无缝切换处理引擎，而无需中间连接器。有关如何在PyFlink中使用newfromPandas()和toPandas()方法的示例，请参阅文档。
支持用户定义的表函数（UDTF）（FLINK-14500）
从弗林克1.11，你可以定义和注册自定义UDTFs在PyFlink。与Python UDF相似，UDTF接受零个，一个或多个标量值作为输入，但是可以返回任意数量的行作为输出，而不是单个值。
UDF的Cython性能优化（FLIP-121）
Cython是Python语言的编译超集，通常用于提高Python中大规模数字处理的性能，因为它可以将执行优化到机器代码级速度，并且可以与流行的基于C的库（例如NumPy）很好地配对。从Flink 1.11开始，您可以构建具有Cython支持的PyFlink并“ Cythonize”您的Python UDF，以显着提高代码执行速度（与Flink 1.10中的Python UDF相比快30倍）。
Python UDF中的用户定义指标（FLIP-112）
为了使用户更容易监视和调试Python UDF的执行，PyFlink现在允许收集度量标准并将其公开给外部系统，以及定义用户范围和变量。您可以通过调用function_context.get_metric_group()open方法从UDF访问指标系统，如文档所述。
重要变化
[ FLINK-17339 ]从Flink 1.11开始，Blink计划程序是Table API / SQL中的默认设置。自Flink 1.10起，SQL客户端已经存在这种情况。仍支持旧的Flink计划程序，但未积极开发。
[ FLINK-5763 ]保存点现在将其所有状态包含在一个目录中（元数据和程序状态）。这样可以很容易地找出组成保存点状态的文件，并允许用户通过简单地移动目录来重新定位保存点。
[ FLINK-16408 ]为了减轻对JVM元空间的压力，TaskExecutor只要至少为各个作业分配了一个插槽，用户代码类加载器就会被重用。这会稍微改变Flink的恢复行为，从而不会重新加载静态字段。
[ FLINK-11086 ] Flink现在支持Hadoop 3.0.0以上的Hadoop版本。请注意，Flink项目不提供任何更新的“ flink-shaded-hadoop- *”罐子。用户需要通过HADOOP_CLASSPATH环境变量（推荐）或lib /文件夹提供Hadoop依赖项。
[ FLINK-16963 ] MetricReportersFlink附带的所有内容都已转换为插件。这些不应再放置/lib（可能导致依赖冲突），/plugins/<some_directory>而应该放置。
[ FLINK-12639 ] Flink文档正在做一些返工，因此您可能会注意到，从Flink 1.11开始，内容的导航和组织方式看起来略有不同。
1.12新特性
新功能和改进
DataStream API中的批处理执行模式
Flink的核心API在项目的整个生命周期中都得到了有机开发，并且最初在设计时就考虑了特定的用例。尽管Table API / SQL已经具有统一的运算符，但是使用较低级别的抽象仍然需要您在批处理（DataSet API）和流式（DataStream API）的两个语义上不同的API之间进行选择。由于批处理是无限制流的子集，因此将其合并到单个API中有一些明显的优势：
可重用性：在同一API下进行有效的批处理和流处理将使您可以轻松地在两种执行模式之间切换，而无需重写任何代码。因此，可以轻松地重用作业来处理实时和历史数据。
操作简便：提供统一的API将意味着使用一组连接器，维护单个代码库并能够轻松实现混合执行管道，例如用于回填之类的用例。
考虑到这些优点，社区已朝着统一DataStream API迈出了第一步：支持有效的批处理执行（FLIP-134）。从长远来看，这意味着DataSet API将被DataStream API和Table API / SQL（FLIP-131）弃用并包含在内。对于统一努力的概述，请参阅本最近弗林克前进的谈话。
批处理流
您已经可以使用DataStream API来处理受限制的流（例如文件），但有一个限制，即运行时不能“意识到”作业已受限制。为了优化有界输入的运行时，新BATCH模式执行使用基于排序的混洗（具有纯内存中的聚合）和改进的调度策略（请参见流水线区域调度）。结果，BATCHDataStream API中的模式执行已经非常接近Flink 1.12中DataSet API的性能。有关性能基准的更多详细信息，请查看原始建议（FLIP-140）。
在Flink 1.12中，默认执行模式为STREAMING。要将作业配置为以BATCH模式运行，您可以在提交作业时设置配置：
bin/flink run -Dexecution.runtime-mode=BATCH examples/streaming/WordCount.jar
，或以编程方式执行此操作：
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setRuntimeMode(RuntimeMode.BATCH);
注意：尽管尚未弃用DataSet API，但我们建议用户优先使用具有BATCH执行模式的DataStream API来执行新的批处理作业，并考虑迁移现有的DataSet作业。
新的数据接收器API（测试版）
在以前的版本中，已经确保数据源中的连接器可以同时在两种执行模式下工作，因此在Flink 1.12中，社区专注于实现统一的Data Sink API（FLIP-143）。新的抽象引入了一个写/提交协议和一个更加模块化的接口，其中各个组件都透明地暴露给框架。
一个接收器实现者必须提供什么和如何：一个SinkWriter写入哪些需要提交的数据和输出（即committables）; 以及封装了如何处理提交表的Committer和GlobalCommitter。该框架负责何时和何处：在什么时间和在其机器或程序提交。
这种更加模块化的抽象允许为BATCH和STREAMING模式执行不同的运行时实现，这些运行时实现了预期的目的，但是仅使用一个统一的接收器实现。在Flink 1.12中，FileSink连接器是StreamingFileSink（FLINK-19758）的统一嵌入式替代。其余的连接器将在将来的版本中移植到新接口。
Kubernetes高可用性（HA）服务
Kubernetes提供了Flink可用于JobManager故障转移的内置功能，而不是依赖ZooKeeper。为了启用“ ZooKeeperless” HA设置，社区在Flink 1.12（FLIP-144）中实现了Kubernetes HA服务。该服务建立在与ZooKeeper实现相同的基本接口上，并使用Kubernetes的ConfigMap对象来处理从JobManager故障中恢复所需的所有元数据。有关如何配置高可用性Kubernetes集群的更多详细信息和示例，请参阅文档。
注意：这并不意味着将删除ZooKeeper依赖关系，而只是在Kubernetes上为Flink用户提供了一种替代选择。
其他改进
将现有连接器迁移到新的数据源API
先前版本引入了新的数据源API（FLIP-27），允许实现既可以作为有界（批处理）源也可以作为无界（流式）源使用的连接器。在Flink 1.12中，社区开始从FileSystem连接器（FLINK-19161）开始将现有的源连接器移植到新接口。
注意：统一的源实现将是完全独立的连接器，与旧版本的快照不兼容。
流水线区域调度（FLIP-119）
Flink的调度程序在很大程度上是为分别处理批处理和流式处理工作负载而设计的。此版本引入了统一的调度策略，该策略可识别阻塞的数据交换以将执行图分解为流水线区域。这样，仅当有数据可以执行工作时才调度每个区域，并且仅在所有必需的资源都可用时才部署它。以及独立地重新启动失败的区域。特别是对于批处理作业，新策略可提高资源利用率，并消除死锁。
支持分类合并洗牌（FLIP-148）
为了提高大规模批处理作业的稳定性，性能和资源利用率，社区引入了sort-merge shuffle，以替代Flink已经使用的原始shuffle实现。这种方法可以显着减少改组时间，并使用较少的文件句柄和文件写入缓冲区（这对于大规模作业是有问题的）。后续版本（FLINK-19614）中将实现进一步的优化。
注意：此功能是实验性的，默认情况下未启用。要启用排序合并混洗，您可以在TaskManager网络配置选项中配置合理的最小并行度阈值。
对Flink WebUI（FLIP-75）的改进
作为对Flink WebUI的一系列改进的延续，该社区致力于在WebUI（FLIP-104）上公开JobManager的内存相关指标和配置参数。TaskManager的指标页面也已更新，以反映对Flink 1.10（FLIP-102）中引入的TaskManager内存模型的更改，并为托管内存，网络内存和元空间添加了新的指标。
表API / SQL：SQL连接器中的元数据处理
某些来源（和格式）将其他字段作为元数据公开，这对于用户与记录数据一起处理很有价值。一个常见的例子是卡夫卡，你可能要如访问抵消，分区或主题的信息，读/写记录键或使用嵌入的元数据的时间戳基于时间的操作。在新版本中，Flink SQL支持元数据列以读取和写入表每一行的特定于连接器和格式的字段（FLIP-107）。这些列在CREATE TABLE语句中使用METADATA（reserved）关键字声明。
CREATE TABLE kafka_table (
id BIGINT,
name STRING,
event_time TIMESTAMP(3) METADATA FROM 'timestamp', -- access Kafka 'timestamp' metadata
headers MAP<STRING, BYTES> METADATA -- access Kafka 'headers' metadata
) WITH (
'connector' = 'kafka',
'topic' = 'test-topic',
'format' = 'avro'
);
在Flink 1.12中，公开了Kafka和Kinesis连接器的元数据，并且已经计划在FileSystem连接器上进行工作（FLINK-19903）。由于Kafka记录的结构更为复杂，因此还专门为Kafka连接器实现了新属性，以控制如何处理键/值对。有关Flink SQL中元数据支持的完整概述，请查看每个连接器的文档以及原始提案中的激励用例。
表API / SQL：Upsert Kafka连接器
对于某些用例，例如解释紧凑的主题或写出（更新）汇总结果，有必要将Kafka记录键作为真正的主键来处理，以确定可以插入，删除或更新的内容。为了实现这一点，社区创建了一个专用的upsert连接器（upsert-kafka），该连接器扩展了基本实现以在upsert模式（FLIP-149）中工作。
新的upsert-kafka连接器可用于源和接收器，并提供与现有Kafka连接器相同的基本功能和持久性保证，因为它在引擎盖下重用了大部分代码。要使用upsert-kafka connector，您必须在创建表时定义一个主键约束，并为键（key.format）和值（value.format）指定（反序列化）格式。
表API / SQL：在SQL中支持临时表联接
现在，您无需创建临时表函数来在某个特定时间点查询表，而只需使用标准SQL子句FOR SYSTEM_TIME AS OF（SQL：2011）来表示临时表联接。此外，现在支持对具有时间属性和主键的任何类型的表进行时态联接，而不仅限于仅附加表。这可以解锁一组新的用例，例如直接针对Kafka压缩的主题或数据库变更日志（例如，来自Debezium）执行临时联接。
-- Table backed by a Kafka topic
CREATE TABLE orders (
order_id STRING,
currency STRING,
amount INT,
order_time TIMESTAMP(3),
WATERMARK FOR order_time AS order_time - INTERVAL '30' SECOND
) WITH (
'connector' = 'kafka',
...
);
-- Table backed by a Kafka compacted topic
CREATE TABLE latest_rates (
currency STRING,
currency_rate DECIMAL(38, 10),
currency_time TIMESTAMP(3),
WATERMARK FOR currency_time AS currency_time - INTERVAL '5' SECOND,
PRIMARY KEY (currency) NOT ENFORCED
) WITH (
'connector' = 'upsert-kafka',
...
);
-- Event-time temporal table join
SELECT
o.order_id,
o.order_time,
o.amount * r.currency_rate AS amount,
r.currency
FROM orders AS o JOIN latest_rates FOR SYSTEM_TIME AS OF o.order_time r
ON o.currency = r.currency;
前面的示例还显示了如何upsert-kafka在时态表联接的上下文中利用新的连接器。
临时表联接中的配置单元表
您还可以通过自动读取最新的表分区作为时态表（FLINK-19644）或整个表作为在执行时跟踪最新版本的有界流来对Hive表执行时态表联接。有关在临时表联接中使用Hive表的示例，请参考文档。
Table API / SQL的其他改进
Kinesis Flink SQL连接器（FLINK-18858）
从Flink 1.12开始，Table API / SQL本身也支持将Amazon Kinesis Data Streams（KDS）作为源/接收器。新的Kinesis SQL连接器随附对增强的扇出（EFO）和接收器分区的支持。有关支持的功能，配置选项和公开的元数据的完整概述，请查看更新的文档。
FileSystem / Hive连接器中的流接收器压缩（FLINK-19345）
当写为大文件时，许多批量格式（例如Parquet）是最有效的。当启用频繁的检查点时，这是一个挑战，因为创建了太多的小文件（需要在检查点上滚动）。在Flink 1.12中，文件接收器支持文件压缩，从而允许作业保留较小的检查点间隔，而无需生成大量文件。要启用文件压缩，您可以auto-compaction=true按照文档中的说明设置FileSystem连接器的属性。
Kafka连接器中的水印下推（FLINK-20041）
为了确保从Kafka消费时的正确性，通常最好在每个分区的基础上生成水印，因为分区中的乱序通常比所有分区中的乱序性要低。Flink现在将降低水印策略，以从Kafka用户内部发出分区的水印。源的输出水印将由其读取的分区上的最小水印确定，从而导致更好（即更接近实时）的水印。水印下推还使您可以配置每个分区的空闲状态检测，以防止空闲分区阻止整个应用程序的事件时间进度。
新支持的格式
格式 描述 支持的连接器
Avro架构注册表 读取和写入使用Confluent Schema Registry KafkaAvroSerializer序列化的数据。 卡夫卡，Upsert卡夫卡
黛比兹·阿夫罗（Debezium Avro） 读写通过Confluent Schema Registry KafkaAvroSerializer序列化的Debezium记录。 卡夫卡
麦克斯韦（CDC） 读写Maxwell JSON记录。
卡夫卡
文件系统
生的 读取和写入原始（基于字节）值作为单列。
卡夫卡，Upsert卡夫卡
运动学
文件系统
用于联接优化的多输入运算符（FLINK-19621）
为了消除不必要的序列化和数据溢出并提高批处理和流表API / SQL作业的性能，默认计划程序现在利用最新版本（FLIP-92）中引入的N元流运算符来实现运算符的“链接”通过前缘连接。
表API UDAF的类型推断（FLIP-65）
此版本结束了Flink 1.9中针对Table API的新数据类型系统上开始的工作，并向该新类型系统公开了聚合函数（UDAF）。从Flink 1.12开始，UDAF的行为类似于标量和表函数，并支持所有数据类型。
PyFlink：Python DataStream API
为了扩展PyFlink的可用性，此版本引入了Python DataStream API（FLIP-130）的第一个版本，该版本支持无状态操作（例如Map，FlatMap，Filter，KeyBy）。
from pyflink.common.typeinfo import Types
from pyflink.datastream import MapFunction, StreamExecutionEnvironment
class MyMapFunction(MapFunction):
def map(self, value):
return value + 1
env = StreamExecutionEnvironment.get_execution_environment()
data_stream = env.from_collection([1, 2, 3, 4, 5], type_info=Types.INT())
mapped_stream = data_stream.map(MyMapFunction(), output_type=Types.INT())
mapped_stream.print()
env.execute("datastream job")
要尝试使用Python DataStream API，您可以安装PyFlink并查看本指南，该指南将指导您构建一个简单的流应用程序。
PyFlink的其他改进
Kubernetes上的PyFlink作业（FLINK-17480）
除了独立部署和YARN部署外，PyFlink作业现在还可以本地部署在Kubernetes上。该部署文档都有详细的关于如何启动一个指令会话或应用上Kubernetes集群。
用户定义的汇总函数（UDAF）
在Flink 1.12中，您可以在PyFlink（FLIP-139）中定义和注册UDAF 。与不处理状态并且一次只处理一行的普通UDF相比，UDAF具有状态，可用于计算多个输入行上的自定义聚合。要从矢量化中受益，您还可以使用Pandas UDAF（FLIP-137）（最快10倍）。
注意：常规UDAF仅在组聚合和流模式下受支持。对于批处理模式或窗口聚合，请使用Pandas UDAF。
重要变化
[ FLINK-19319 ]默认流时间特征已更改为EventTime，因此您不再需要调用StreamExecutionEnvironment.setStreamTimeCharacteristic()以启用事件时间支持。
[ FLINK-19278 ] Flink现在依赖于Scala宏2.1.1，因此不再支持<2.11.11的Scala版本。
[ FLINK-19152 ]此版本中已删除了Kafka 0.10.x和0.11.x连接器。如果您仍在使用这些版本，请参阅文档以了解如何升级到通用Kafka连接器。
[ FLINK-18795 ] HBase连接器已升级到最新的稳定版本（2.2.3）。
[ FLINK-17877 ] PyFlink现在支持Python 3.8。
[ FLINK-18738 ]为了与FLIP-53保持一致，托管内存现在也是Python worker的默认设置。配置python.fn-execution.buffer.memory.size和python.fn-execution.framework.memory.size已被删除，将不再生效。