Flink 1.11 究竟有哪些易用性上的改善

本篇文章给大家分享的是有关Flink 1.11 究竟有哪些易用性上的改善，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

• 首先在每个版本的规划初期，会从志愿者中选出 1-2 名作为 Release Manager。1.11.0 版本我作为中国这边的 Release Manager，同时还有一名来自 Ververica 的 Piotr Nowojski 作为德国方的 Release Manager，这在某种程度上也说明中国的开发者和贡献度在整个社区的占比很重要。

• 接下来会进行这个版本的 Feature Kickoff。在一些大的方向上，社区的规划周期可能比较久，会分阶段、分步骤跨越多个版本完成，确保质量。每个版本的侧重点也会有所不同，比如前两个版本侧重于批处理的加强，而这个版本更侧重于流处理易用性的提升。社区规划的 Feature 列表会在邮件列表中发起讨论，以收集更多的用户/开发者意见和反馈。

• 一般的开发周期为 2-3 个月时间，提前会明确规划出大概的 Feature Freeze 时间，之后进行 Release Candidate 的发布和测试、以及 Bug Fix。一般经过几轮的迭代周期后会正式投票通过一个相对稳定的 Candidate 版本，然后基于这个版本正式发布。

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);

• Hive 写入：FLIP-115 完善扩展了 FileSystem Connector 的基础能力和实现，Table/SQL 层的 sink 可以支持各种格式（CSV、Json、Avro、Parquet、ORC），而且支持 Hive Table 的所有格式。

• Partition 支持：数据导入 Hive 引入 Partition 提交机制来控制可见性，通过sink.partition-commit.trigger 控制 Partition 提交的时机，通过 sink.partition-commit.policy.kind 选择提交策略，支持 SUCCESS 文件和 Metastore 提交。

• Hive 读取：实时化的流式读取 Hive，通过监控 Partition 生成增量读取新 Partition，或者监控文件夹内新文件生成来增量读取新文件。

• FLIP-123 通过 Hive Dialect 为用户提供语法兼容，这样用户无需在 Flink 和 Hive 的 CLI 之间切换，可以直接迁移 Hive 脚本到 Flink 中执行。

• 提供 Hive 相关依赖的内置支持，避免用户自己下载所需的相关依赖。现在只需要单独下载一个包，配置 HADOOP_CLASSPATH 就可以运行。

• 对用户而言，在 Flink 中改造已有的 Source 或者重新实现一个生产级的 Source Connector 不是一件容易的事情，具体体现在没有公共的代码可以复用，而且需要理解很多 Flink 内部细节以及实现具体的 Event Time 分配、Watermark 产出、Idleness 监测、线程模型等。

• 批和流的场景需要实现不同的 Source。

• Partitions/Splits/Shards 概念在接口中没有显式表达，比如 Split 的发现逻辑和数据消费都耦合在 Source Sunction 的实现中，这样在实现 Kafka 或 Kinesis 类型的 Source 时增加了复杂性。

• 在 Runtime 执行层，Checkpoint 锁被 Source Function 抢占会带来一系列问题，框架很难进行优化。

• 首先在 Job Manager 和 Task Manager 中分别引入两种不同的组件 Split Enumerator 和 Source Reader，解耦 Split 发现和对应的消费处理，同时方便随意组合不同的策略。比如现有的 Kafka Connector 中有多种不同的 Partition 发现策略和实现耦合在一起，在新的架构下，我们只需要实现一种 Source Reader，就可以适配多种 Split Enumerator 的实现来对应不同的 Partition 发现策略。

• 在新架构下实现的 Source Connector 可以做到批流统一，唯一的小区别是对批场景的有限输入，Split Enumerator 会产出固定数量的 Split 集合并且每个 Split 都是有限数据集；对于流场景的无限输入，Split Enumerator 要么产出无限多的 Split 或者 Split 自身是无限数据集。

• 复杂的 Timestamp Assigner 以及 Watermark Generator 透明的内置在 Source Reader 模块内运行，对用户来说是无感知的。这样用户如果想实现新的 Source Connector，一般不再需要重复实现这部分功能。

• 每次调用可以处理 N 条数据。

• 数据格式基于 Apache Arrow，大大降低了 Java、Python 进程之间的序列化/反序列化开销。

• 方便 Python 用户基于 Numpy 和 Pandas 等数据分析领域常用的 Python 库，开发高性能的 Python UDF。

• PyFlink table 和 Pandas DataFrame 之间无缝切换（FLIP-120），增强 Pandas 生态的易用性和兼容性。

• Table & SQL 中可以定义和使用 Python UDTF（FLINK-14500），不再必需 Java/Scala UDTF。

• Cython 优化 Python UDF 的性能（FLIP-121），对比 1.10.0 可以提升 30 倍。

• Python UDF 中用户自定义 Metric（FLIP-112），方便监控和调试 UDF 的执行。

• Session 模式：提前启动一个集群，所有作业都共享这个集群的资源运行。优势是避免每个作业单独启动集群带来的额外开销，缺点是隔离性稍差。如果一个作业把某个 Task Manager（TM）容器搞挂，会导致这个容器内的所有作业都跟着重启。虽然每个作业有自己独立的 Job Manager（JM）来管理，但是这些 JM 都运行在一个进程中，容易带来负载上的瓶颈。

• Per-job 模式：为了解决 Session 模式隔离性差的问题，每个作业根据资源需求启动独立的集群，每个作业的 JM 也是运行在独立的进程中，负载相对小很多。

• 上游输出端控制单个 Sub Partition 堆积 Buffer 的最大阈值（Backlog），避免负载不均场景下单个链路上堆积大量 Buffer。

• 在不影响网络吞吐性能的情况下合理修改上下游默认的 Buffer 配置。

• 上下游数据传输的基础协议进行了调整，允许单个数据链路可以配置 0 个独占 Buffer 而不死锁，这样总的 Buffer 数量和作业并发规模解耦。根据实际需求在吞吐性能和 Checkpoint 速度两者之间权衡，自定义 Buffer 配比。

• Checkpoint Barrier 跨数据 Buffer 传输，不在输入输出队列排队等待处理，这样就和算子的计算能力解耦，Barrier 在节点之间的传输只有网络延时，可以忽略不计。

• 每个算子多个输入链路之间不需要等待 Barrier 对齐来执行 Checkpoint，第一个到的 Barrier 就可以提前触发 Checkpoint，这样可以进一步提速 Checkpoint，不会因为个别链路的延迟而影响整体。

• 为了和之前 Aligned Checkpoint 的语义保持一致，所有未被处理的输入输出数据 Buffer 都将作为 Channel State 在 Checkpoint 执行时进行快照持久化，在 Failover 时连同 Operator State 一同进行恢复。换句话说，Aligned 机制保证的是 Barrier 前面所有数据必须被处理完，状态实时体现到 Operator State 中；而 Unaligned 机制把 Barrier 前面的未处理数据所反映的 Operator State 延后到 Failover Restart 时通过 Channel State 回放进行体现，从状态恢复的角度来说最终都是一致的。注意这里虽然引入了额外的 In-Flight Buffer 的持久化，但是这个过程实际是在 Checkpoint 的异步阶段完成的，同步阶段只是进行了轻量级的 Buffer 引用，所以不会过多占用算子的计算时间而影响吞吐性能。

  

以上就是Flink 1.11 究竟有哪些易用性上的改善，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。