flink1.12.0发布了,他来了他来了

Apache Flink 社区很荣幸地宣布 Flink 1.12.0 版本正式发布!近 300 位贡献者参与了 Flink 1.12.0 的开发,提交了超过 1000 多个修复或优化。这些修改极大地提高了 Flink 的可用性,并且简化(且统一)了 Flink 的整个 API 栈。其中一些比较重要的修改包括:

  • 在 DataStream API 上添加了高效的批执行模式的支持。这是批处理和流处理实现真正统一的运行时的一个重要里程碑。

  • 实现了基于Kubernetes的高可用性(HA)方案,作为生产环境中,ZooKeeper方案之外的另外一种选择。

  • 扩展了 Kafka SQL connector,使其可以在 upsert 模式下工作,并且支持在 SQL DDL 中处理 connector 的 metadata。现在,时态表 Join 可以完全用 SQL 来表示,不再依赖于 Table API 了。

  • PyFlink 中添加了对于 DataStream API 的支持,将 PyFlink 扩展到了更复杂的场景,比如需要对状态或者定时器 timer 进行细粒度控制的场景。除此之外,现在原生支持将 PyFlink 作业部署到 Kubernetes上。

本文描述了所有主要的新功能、优化、以及需要特别关注的改动。

Flink 1.12.0 的二进制发布包和源代码可以通过 Flink 官网的下载页面获得,详情可以参阅 Flink 1.12.0 的官方文档。我们希望您下载试用这一版本后,可以通过 Flink 邮件列表和 JIRA 网站和我们分享您的反馈意见。

Flink 1.12 官方文档:
https://ci.apache.org/projects/flink/flink-docs-release-1.12/

新的功能和优化

DataStream API 支持批执行模式

Flink 的核心 API 最初是针对特定的场景设计的,尽管 Table API / SQL 针对流处理和批处理已经实现了统一的 API,但当用户使用较底层的 API 时,仍然需要在批处理(DataSet API)和流处理(DataStream API)这两种不同的 API 之间进行选择。鉴于批处理是流处理的一种特例,将这两种 API 合并成统一的 API,有一些非常明显的好处,比如:

  • 可复用性:作业可以在流和批这两种执行模式之间自由地切换,而无需重写任何代码。因此,用户可以复用同一个作业,来处理实时数据和历史数据。

  • 维护简单:统一的 API 意味着流和批可以共用同一组 connector,维护同一套代码,并能够轻松地实现流批混合执行,例如 backfilling 之类的场景。

考虑到这些优点,社区已朝着流批统一的 DataStream API 迈出了第一步:支持高效的批处理(FLIP-134)。从长远来看,这意味着 DataSet API 将被弃用(FLIP-131),其功能将被包含在 DataStream API 和 Table API / SQL 中。

■ 有限流上的批处理

您已经可以使用 DataStream API 来处理有限流(例如文件)了,但需要注意的是,运行时并不“知道”作业的输入是有限的。为了优化在有限流情况下运行时的执行性能,新的 BATCH 执行模式,对于聚合操作,全部在内存中进行,且使用 sort-based shuffle(FLIP-140)和优化过的调度策略(请参见 Pipelined Region Scheduling 了解更多详细信息)。因此,DataStream API 中的 BATCH 执行模式已经非常接近 Flink 1.12 中 DataSet API 的性能。有关性能的更多详细信息,请查看 FLIP-140。

图片

在 Flink 1.12 中,默认执行模式为 STREAMING,要将作业配置为以 BATCH 模式运行,可以在提交作业的时候,设置参数 execution.runtime-mode:

$ 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 作业。

新的 Data Sink API (Beta)

之前发布的 Flink 版本中[1],已经支持了 source connector 工作在流批两种模式下,因此在 Flink 1.12 中,社区着重实现了统一的 Data Sink API(FLIP-143)。新的抽象引入了 write/commit 协议和一个更加模块化的接口。Sink 的实现者只需要定义 what 和 how:SinkWriter,用于写数据,并输出需要 commit 的内容(例如,committables);Committer 和 GlobalCommitter,封装了如何处理 committables。框架会负责 when 和 where:即在什么时间,以及在哪些机器或进程中 commit。

图片

这种模块化的抽象允许为 BATCH 和 STREAMING 两种执行模式,实现不同的运行时策略,以达到仅使用一种 sink 实现,也可以使两种模式都可以高效执行。Flink 1.12 中,提供了统一的 FileSink connector,以替换现有的 StreamingFileSink connector (FLINK-19758)。其它的 connector 也将逐步迁移到新的接口。

基于 Kubernetes 的高可用 (HA) 方案

Flink 可以利用 Kubernetes 提供的内置功能来实现 JobManager 的 failover,而不用依赖 ZooKeeper。为了实现不依赖于 ZooKeeper 的高可用方案,社区在 Flink 1.12(FLIP-144)中实现了基于 Kubernetes 的高可用方案。该方案与 ZooKeeper 方案基于相同的接口[3],并使用 Kubernetes 的 ConfigMap[4] 对象来处理从 JobManager 的故障中恢复所需的所有元数据。关于如何配置高可用的 standalone 或原生 Kubernetes 集群的更多详细信息和示例,请查阅文档[5]。

注意:需要注意的是,这并不意味着 ZooKeeper 将被删除,这只是为 Kubernetes 上的 Flink 用户提供了另外一种选择。

其它功能改进

 将现有的 connector 迁移到新的 Data Source API

在之前的版本中,Flink 引入了新的 Data Source API(FLIP-27),以允许实现同时适用于有限数据(批)作业和无限数据(流)作业使用的 connector 。在 Flink 1.12 中,社区从 FileSystem connector(FLINK-19161)出发,开始将现有的 source connector 移植到新的接口。

注意: 新的 source 实现,是完全不同的实现,与旧版本的实现不兼容。

■ Pipelined Region 调度 (FLIP-119)

在之前的版本中,Flink 对于批作业和流作业有两套独立的调度策略。Flink 1.12 版本中,引入了统一的调度策略, 该策略通过识别 blocking 数据传输边,将 ExecutionGraph 分解为多个 pipelined region。这样一来,对于一个 pipelined region 来说,仅当有数据时才调度它,并且仅在所有其所需的资源都被满足时才部署它;同时也可以支持独立地重启失败的 region。对于批作业来说,新策略可显著地提高资源利用率,并消除死锁。

■ 支持 Sort-Merge Shuffle (FLIP-148)

为了提高大规模批作业的稳定性、性能和资源利用率,社区引入了 sort-merge shuffle,以替代 Flink 现有的实现。这种方案可以显著减少 shuffle 的时间,并使用较少的文件句柄和文件写缓存(这对于大规模批作业的执行非常重要)。在后续版本中(FLINK-19614),Flink 会进一步优化相关性能。

注意:该功能是实验性的,在 Flink 1.12 中默认情况下不启用。要启用 sort-merge shuffle,需要在 TaskManager 的网络配置[6]中设置合理的最小并行度。

 Flink WebUI 的改进 (FLIP-75)

作为对上一个版本中,Flink WebUI 一系列改进的延续,Flink 1.12 在 WebUI 上暴露了 JobManager 内存相关的指标和配置参数(FLIP-104)。对于 TaskManager 的指标页面也进行了更新,为 Managed Memory、Network Memory 和 Metaspace 添加了新的指标,以反映自 Flink 1.10(FLIP-102)开始引入的 TaskManager 内存模型的更改[7]。

Table API/SQL: SQL Connectors 中的 Metadata 处理

如果可以将某些 source(和 format)的元数据作为额外字段暴露给用户,对于需要将元数据与记录数据一起处理的用户来说很有意义。一个常见的例子是 Kafka,用户可能需要访问 offset、partition 或 topic 信息、读写 kafka 消息中的 key 或 使用消息 metadata中的时间戳进行时间相关的操作。

在 Flink 1.12 中,Flink SQL 支持了元数据列用来读取和写入每行数据中 connector 或 format 相关的列(FLIP-107)。这些列在 CREATE TABLE 语句中使用 METADATA(保留)关键字来声明。

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 connector 的元数据,并且 FileSystem connector 上的相关工作也已经在计划中(FLINK-19903)。由于 Kafka record 的结构比较复杂,社区还专门为 Kafka connector 实现了新的属性[8],以控制如何处理键/值对。关于 Flink SQL 中元数据支持的完整描述,请查看每个 connector 的文档[9]以及 FLIP-107 中描述的用例。

Table API/SQL: Upsert Kafka Connector

在某些场景中,例如读取 compacted topic 或者输出(更新)聚合结果的时候,需要将 Kafka 消息记录的 key 当成主键处理,用来确定一条数据是应该作为插入、删除还是更新记录来处理。为了实现该功能,社区为 Kafka 专门新增了一个 upsert connector(upsert-kafka),该 connector 扩展自现有的 Kafka connector,工作在 upsert 模式(FLIP-149)下。新的 upsert-kafka connector 既可以作为 source 使用,也可以作为 sink 使用,并且提供了与现有的 kafka connector 相同的基本功能和持久性保证,因为两者之间复用了大部分代码。

要使用 upsert-kafka connector,必须在创建表时定义主键,并为键(key.format)和值(value.format)指定序列化反序列化格式。完整的示例,请查看最新的文档[10]。

Table API/SQL: SQL 中 支持 Temporal Table Join

在之前的版本中,用户需要通过创建时态表函数(temporal table function) 来支持时态表 join(temporal table join) ,而在 Flink 1.12 中,用户可以使用标准的 SQL 语句 FOR SYSTEM_TIME AS OF(SQL:2011)来支持 join。此外,现在任意包含时间列和主键的表,都可以作为时态表,而不仅仅是 append-only 表。这带来了一些新的应用场景,比如将 Kafka compacted topic 或数据库变更日志(来自 Debezium 等)作为时态表。

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 ();
-- Table backed by a Kafka compacted topicCREATE TABLE latest_rates (     currency STRING,    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 joinSELECT   o.order_id,  o.order_time,  o.amount * r.rate AS amount,  r.currencyFROM orders AS o, latest_rates FOR SYSTEM_TIME AS OF o.order_time rON o.currency = r.currency;
上面的示例同时也展示了如何在 temporal table join 中使用 Flink 1.12 中新增的 upsert-kafka connector。

 使用 Hive 表进行 Temporal Table Join

用户也可以将 Hive 表作为时态表来使用,Flink 既支持自动读取 Hive 表的最新分区作为时态表(FLINK-19644),也支持在作业执行时追踪整个 Hive 表的最新版本作为时态表。请参阅文档,了解更多关于如何在 temporal table join 中使用 Hive 表的示例。

Table API/SQL 中的其它改进

 Kinesis Flink SQL Connector (FLINK-18858)

从 Flink 1.12 开始,Table API / SQL 原生支持将 Amazon Kinesis Data Streams(KDS)作为 source 和 sink 使用。新的 Kinesis SQL connector 提供了对于增强的Fan-Out(EFO)以及 Sink Partition 的支持。如需了解 Kinesis SQL connector 所有支持的功能、配置选项以及对外暴露的元数据信息,请查看最新的文档。

 在 FileSystem/Hive connector 的流式写入中支持小文件合并 (FLINK-19345)

很多 bulk format,例如 Parquet,只有当写入的文件比较大时,才比较高效。当 checkpoint 的间隔比较小时,这会成为一个很大的问题,因为会创建大量的小文件。在 Flink 1.12 中,File Sink 增加了小文件合并功能,从而使得即使作业 checkpoint 间隔比较小时,也不会产生大量的文件。要开启小文件合并,可以按照文档[11]中的说明在 FileSystem connector 中设置 auto-compaction = true 属性。

 Kafka Connector 支持 Watermark 下推 (FLINK-20041)

为了确保使用 Kafka 的作业的结果的正确性,通常来说,最好基于分区来生成 watermark,因为分区内数据的乱序程度通常来说比分区之间数据的乱序程度要低很多。Flink 现在允许将 watermark 策略下推到 Kafka connector 里面,从而支持在 Kafka connector 内部构造基于分区的 watermark[12]。一个 Kafka source 节点最终所产生的 watermark 由该节点所读取的所有分区中的 watermark 的最小值决定,从而使整个系统可以获得更好的(即更接近真实情况)的 watermark。该功能也允许用户配置基于分区的空闲检测策略,以防止空闲分区阻碍整个作业的 event time 增长。

 新增的 Formats

Format

描述

支持的 Connectors 类型

Avro Schema Registry

(FLINK-16048)

读写由 Confluent Schema Registry KafkaAvroSerializer 序列化的数据

  • Kafka,Upsert Kafka

Debezium Avro

(FLINK-18774)

读写由 Confluent Schema Registry KafkaAvroSerializer序列化的Debezium记录

  • Kafka

Maxwell(CDC)

读写 Maxwell JSON 记录
  • Kafka

  • FileSystem

Raw[13]

(FLINK-14356)

读写 raw values (基于byte的) 作为单独的一列
  • Kafka, Upsert Kafka

  • Kinesis

  • FileSystem

 利用 Multi-input 算子进行 Join 优化 (FLINK-19621)

Shuffling 是一个 Flink 作业中最耗时的操作之一。为了消除不必要的序列化反序列化开销、数据 spilling 开销,提升 Table API / SQL 上批作业和流作业的性能, planner 当前会利用上一个版本中已经引入的N元算子(FLIP-92),将由 forward 边所连接的多个算子合并到一个 Task 里执行。

 Type Inference for Table API UDAFs (FLIP-65)

Flink 1.12 完成了从 Flink 1.9 开始的,针对 Table API 上的新的类型系统[2]的工作,并在聚合函数(UDAF)上支持了新的类型系统。从 Flink 1.12 开始,与标量函数和表函数类似,聚合函数也支持了所有的数据类型。

PyFlink: Python DataStream API

为了扩展 PyFlink 的可用性,Flink 1.12 提供了对于 Python DataStream API(FLIP-130)的初步支持,该版本支持了无状态类型的操作(例如 Map,FlatMap,Filter,KeyBy 等)。如果需要尝试 Python DataStream API,可以安装PyFlink,然后按照该文档[14]进行操作,文档中描述了如何使用 Python DataStream API 构建一个简单的流应用程序。

from pyflink.common.typeinfo import Typesfrom pyflink.datastream import MapFunction, StreamExecutionEnvironmentclass MyMapFunction(MapFunction):    def map(self, value):        return value + 1env = 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")

PyFlink 中的其它改进

 PyFlink Jobs on Kubernetes (FLINK-17480)

除了 standalone 部署和 YARN 部署之外,现在也原生支持将 PyFlink 作业部署在 Kubernetes 上。最新的文档中详细描述了如何在 Kubernetes 上启动 session 或 application 集群。

 用户自定义聚合函数 (UDAFs)

从 Flink 1.12 开始,您可以在 PyFlink 作业中定义和使用 Python UDAF 了(FLIP-139)。普通的 UDF(标量函数)每次只能处理一行数据,而 UDAF(聚合函数)则可以处理多行数据,用于计算多行数据的聚合值。您也可以使用 Pandas UDAF[15](FLIP-137),来进行向量化计算(通常来说,比普通 Python UDAF 快10倍以上)。

注意: 普通 Python UDAF,当前仅支持在 group aggregations 以及流模式下使用。如果需要在批模式或者窗口聚合中使用,建议使用 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.sizepython.fn-execution.framework.memory.size已被删除,将不再生效。

详细发布说明

如果你想要升级到1.12的话,请详细阅读详细发布说明[17]。与之前所有1.x版本相比,1.12可以保证所有标记为 @Public 的接口的兼容性。

原文链接:

https://flink.apache.org/news/2020/12/10/release-1.12.0.html

本文的 Release 文档描述了在 Flink 1.11 和 Flink 1.12 之间更改的重要方面,例如配置,行为或依赖项。如果您打算将 Flink 版本升级到 1.12,请仔细阅读这些说明。

API

移除掉 ExecutionConfig 中过期的方法

移除掉了 ExecutionConfig#isLatencyTrackingEnabled 方法, 你可以使用 ExecutionConfig#getLatencyTrackingInterval 方法代替.

移除掉了 ExecutionConfig#enable/disableSysoutLoggingExecutionConfig#set/isFailTaskOnCheckpointError 过期的方法。

移除掉了 -q CLI 参数。

移除掉过期的 RuntimeContext#getAllAccumulators 方法

过期的 RuntimeContext#getAllAccumulators 方法被移除掉了,请使用 RuntimeContext#getAccumulator 方法作为代替。

由于数据丢失的风险把 CheckpointConfig#setPreferCheckpointForRecovery 方法标为过期

CheckpointConfig#setPreferCheckpointForRecovery 方法标记为过期了, 因为作业在进行恢复时,如果使用较旧的 Checkpoint 状态而不使用新的 Save point 状态数据,可能会导致数据丢失。

FLIP-134: DataStream API 的批处理执行

  • 允许在 KeyedStream.intervalJoin() 的配置时间属性,在 Flink 1.12 之前 KeyedStream.intervalJoin() 算子的时间属性依赖于全局设置的时间属性。在 Flink 1.12 中我们可以在 IntervalJoin 方法后加上 inProcessingTime() 或 inEventTime() ,这样 Join 就不再依赖于全局的时间属性。

  • 在 Flink 1.12 中将 DataStream API 的 timeWindow() 方法标记为过期,请使用 window(WindowAssigner)TumblingEventTimeWindows、 SlidingEventTimeWindowsTumblingProcessingTimeWindows 或者 SlidingProcessingTimeWindows

  • 将 StreamExecutionEnvironment.setStreamTimeCharacteristic() 和 TimeCharacteristic 方法标记为过期。在 Flink 1.12 中,默认的时间属性改变成 EventTime 了,于是你不再需要该方法去开启 EventTime 了。在 EventTime 时间属性下,你使用 processing-time 的 windows 和 timers 也都依旧会生效。如果你想禁用水印,请使用 ExecutionConfig.setAutoWatermarkInterval(long) 方法。如果你想使用 IngestionTime,请手动设置适当的 WatermarkStrategy。如果你使用的是基于时间属性更改行为的通用 'time window' 算子(eg: KeyedStream.timeWindow()),请使用等效操作明确的指定处理时间和事件时间。

  • 允许在 CEP PatternStream 上显式配置时间属性在 Flink 1.12 之前,CEP 算子里面的时间依赖于全局配置的时间属性,在 1.12 之后可以在 PatternStream 上使用 inProcessingTime() 或 inEventTime() 方法。

API 清理

  • 移除了 UdfAnalyzer 配置,移除了 ExecutionConfig#get/setCodeAnalysisMode 方法和 SkipCodeAnalysis 类。

  • 移除了过期的 DataStream#split 方法,该方法从很早的版本中已经标记成为过期的了,你可以使用 Side Output 来代替。

  • 移除了过期的 DataStream#fold() 方法和其相关的类,你可以使用更加高性能的 DataStream#reduce

扩展 CompositeTypeSerializerSnapshot 以允许复合序列化器根据外部配置迁移

不再推荐使用 CompositeTypeSerializerSnapshot 中的 isOuterSnapshotCompatible(TypeSerializer) 方法,推荐使用 OuterSchemaCompatibility#resolveOuterSchemaCompatibility(TypeSerializer) 方法。

将 Scala Macros 版本升级到 2.1.1

Flink 现在依赖 Scala Macros 2.1.1,意味着不再支持 Scala 版本小于 2.11.11。

SQL

对 aggregate 函数的 SQL DDL 使用新类型推断

aggregate 函数的 CREATE FUNCTION DDL 现在使用新类型推断,可能有必要将现有实现更新为新的反射类型提取逻辑,将 StreamTableEnvironment.registerFunction 标为过期。

更新解析器模块 FLIP-107

现在 METADATA 属于保留关键字,记得使用反引号转义。

将内部 aggregate 函数更新为新类型

使用 COLLECT 函数的 SQL 查询可能需要更新为新类型的系统。

Connectors 和 Formats

移除 Kafka 0.10.x 和 0.11.x Connector

在 Flink 1.12 中,移除掉了 Kafka 0.10.x 和 0.11.x Connector,请使用统一的 Kafka Connector(适用于 0.10.2.x 版本之后的任何 Kafka 集群),你可以参考 Kafka Connector 页面的文档升级到新的 Flink Kafka Connector 版本。

CSV 序列化 Schema 包含行分隔符

csv.line-delimiter 配置已经从 CSV 格式中移除了,因为行分隔符应该由 Connector 定义而不是由 format 定义。如果用户在以前的 Flink 版本中一直使用了该配置,则升级到 Flink 1.12 时,应该删除该配置。

升级 Kafka Schema Registry Client 到 5.5.0 版本

flink-avro-confluent-schema-registry 模块不再在 fat-jar 中提供,你需要显式的在你自己的作业中添加该依赖,SQL-Client 用户可以使用flink-sql-avro-confluent-schema-registry fat jar。

将 Avro 版本从 1.8.2 升级到 1.10.0 版本

flink-avro 模块中的 Avro 版本升级到了 1.10,如果出于某种原因要使用较旧的版本,请在项目中明确降级 Avro 版本。

注意:我们观察到,与 1.8.2 相比,Avro 1.10 版本的性能有所下降,如果你担心性能,并且可以使用较旧版本的 Avro,那么请降级 Avro 版本。

为 SQL Client 打包 flink-avro 模块时会创建一个 uber jar

SQL Client jar 会被重命名为 flink-sql-avro-1.12.jar,以前是 flink-avro-1.12-sql-jar.jar,而且不再需要手动添加 Avro 依赖。

Deployment(部署)

默认 Log4j 配置了日志大小超过 100MB 滚动

默认的 log4j 配置现在做了变更:除了在 Flink 启动时现有的日志文件滚动外,它们在达到 100MB 大小时也会滚动。Flink 总共保留 10 个日志文件,从而有效地将日志目录的总大小限制为 1GB(每个 Flink 服务记录到该目录)。

默认在 Flink Docker 镜像中使用 jemalloc

在 Flink 的 Docker 镜像中,jemalloc 被用作默认的内存分配器,以减少内存碎片问题。用户可以通过将 disable-jemalloc 标志传递给 docker-entrypoint.sh 脚本来回滚使用 glibc。有关更多详细信息,请参阅 Docker 文档上的 Flink。

升级 Mesos 版本到 1.7

将 Mesos 依赖版本从 1.0.1 版本升级到 1.7.0 版本。

如果 Flink 进程在超时后仍未停止,则发送 SIGKILL

在 Flink 1.12 中,如果 SIGTERM 无法成功关闭 Flink 进程,我们更改了独立脚本的行为以发出 SIGKILL。

介绍非阻塞作业提交

提交工作的语义略有变化,提交调用几乎立即返回,并且作业处于新的 INITIALIZING 状态,当作业处于该状态时,对作业做 Savepoint 或者检索作业详情信息等操作将不可用。

一旦创建了该作业的 JobManager,该作业就处于 CREATED 状态,并且所有的调用均可用。

Runtime

FLIP-141: Intra-Slot Managed Memory 共享

python.fn-execution.buffer.memory.size 和 python.fn-execution.framework.memory.size 的配置已删除,因此不再生效。除此之外,python.fn-execution.memory.managed 默认的值更改为 true, 因此默认情况下 Python workers 将使用托管内存。

FLIP-119 Pipelined Region Scheduling

从 Flink 1.12 开始,将以 pipelined region 为单位进行调度。pipelined region 是一组流水线连接的任务。这意味着,对于包含多个 region 的流作业,在开始部署任务之前,它不再等待所有任务获取 slot。取而代之的是,一旦任何 region 获得了足够的任务 slot 就可以部署它。对于批处理作业,将不会为任务分配 slot,也不会单独部署任务。取而代之的是,一旦某个 region 获得了足够的 slot,则该任务将与所有其他任务一起部署在同一区域中。

可以使用 jobmanager.scheduler.scheduling-strategy:legacy 启用旧的调度程序。

RocksDB optimizeForPointLookup 导致丢失时间窗口

默认情况下,我们会将 RocksDB 的 ReadOptions 的 setTotalOrderSeek 设置为true,以防止用户忘记使用 optimizeForPointLookup。同时,我们支持通过RocksDBOptionsFactory 自定义 ReadOptions。如果观察到任何性能下降,请将 setTotalOrderSeek 设置为 false(根据我们的测试,这是不可能的)。

自定义 OptionsFactory 设置似乎对 RocksDB 没有影响

过期的 OptionsFactory 和 ConfigurableOptionsFactory 类已移除,请改用 RocksDBOptionsFactory 和 ConfigurableRocksDBOptionsFactory。如果有任何扩展 DefaultConfigurableOptionsFactory 的类,也请重新编译你的应用程序代码。

参考链接:

[1] https://flink.apache.org/news/2020/07/06/release-1.11.0.html#new-data-source-api-beta

[2] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/table/types.html#data-types

[3] https://ci.apache.org/projects/flink/flink-docs-release-1.11/api/java/org/apache/flink/runtime/highavailability/HighAvailabilityServices.html

[4] https://kubernetes.io/docs/concepts/configuration/configmap/

[5] https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/ha/kubernetes_ha.html

[6] https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/config.html#taskmanager-network-sort-shuffle-min-parallelism

[7] https://flink.apache.org/news/2020/04/21/memory-management-improvements-flink-1.10.html

[8] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/table/connectors/kafka.html#key-format

[9] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/table/connectors/

[10] https://ci.apache.org/projects/flink/flink-docs-master/dev/table/connectors/kinesis.html

[11] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/table/connectors/filesystem.html#file-compaction

[12] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/table/connectors/kafka.html#source-per-partition-watermarks

[13] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/table/connectors/formats/raw.html

[14] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/python/datastream_tutorial.html

[15] https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/python/table-api-users-guide/udfs/vectorized_python_udfs.html#vectorized-aggregate-functions

[16] https://ci.apache.org/projects/flink/flink-docs-master/dev/connectors/kafka.html

[17] https://ci.apache.org/projects/flink/flink-docs-stable/release-notes/flink-1.12.html 

猜你喜欢

转载自blog.csdn.net/Baron_ND/article/details/111030075