如何自做自己的网站,深圳做app开发,电子商务网站开发方式,网站后台模板 phpApache Flink 核心概念之一是流 (无界数据) 批 (有界数据) 一体。
流批一体极大的降低了流批融合作业的开发复杂度。在过去的几个版本中#xff0c;Flink 流批一体逐渐成熟#xff0c;Flink 1.15 版本中流批一体更加完善#xff0c;后面我们也将继续推动这一方向的进展。目…Apache Flink 核心概念之一是流 (无界数据) 批 (有界数据) 一体。
流批一体极大的降低了流批融合作业的开发复杂度。在过去的几个版本中Flink 流批一体逐渐成熟Flink 1.15 版本中流批一体更加完善后面我们也将继续推动这一方向的进展。目前大数据处理的一个趋势是越来越多的业务和场景采用低代码的方式进行数据分析而 Flink SQL则是这种低代码方式数据分析的典型代表。越来越多的用户开始采用 Flink SQL 来实现他们的业务这也是 Flink 用户和生态快速增长的重要原因之一。Apache Flink 作为数据处理生态中的重要一环可以与许多其他技术结合在一起支持各类用户场景。在当下云原生的背景下我们也尽可能将 Flink 与这些系统以及各类云基础设施进行无缝集成。
在 1.15 版本中Apache Flink 社区在上述这些方面都取得了重大进展
1.15 版本的一大看点是改进了运维 Apache Flink 的体验包括明确 Checkpoint 和 Savepoint 在不同作业之间的所属权简化 Checkpoint 和 Savepoint 生命周期管理更加无缝支持完整的自动伸缩通过 Watermark 对齐来消除多个数据源速率不同带来的问题等1.15 版本中Flink 进一步完善流批一体的体验继续完善部分作业完成后的 Checkpoint 操作支持批模式下的 Window table-valued 函数并且使其在流批混合的场景下更加易用。Flink SQL 的进阶包括能够在不丢失状态的情况下升级 SQL 作业添加了对 JSON 相关函数的支持来简化数据的输入与输出操作。Flink 作为整个数据处理生态中的一环1.15 版本进一步提升了与云服务的交互操作性并且添加了更多的 Sink 连接器与数据格式。最后我们在运行时中去除了对 Scala 的依赖[2]。
轻松运维 Apache Flink
长期来看即使是由最好的工程团队来进行构建和调优Flink 作业仍然依赖运维操作。Flink 支持多种不同的部署模式、API、调优配置与用例这意味着运维工作至关重要并且可能十分繁重。
在这个版本中我们听取了用户的反馈对 Flink 的运维操作进行了简化使用户能够更加轻松的进行运维。现在 Flink 明确了 Checkpoint 与 Savepoint 在不同作业之间的所属权更加无缝支持完整的自动伸缩通过 Watermark 对齐消除多个数据源产出速率不同带来的问题并且初步支持了在不丢失状态的情况下升级 SQL 作业的能力。
澄清 Checkpoint 与 Savepoint 语义
Flink 容错策略的两个重要基础概念是 Checkpoint[3] 与 Savepoint[4] (参见比较[5])。
Savepoint 的主要作用是支持作业修改、备份与升级等场景它是由用户来完全控制的。而另一方面Checkpoint 由 Flink 完全控制用于通过支持快速恢复与重启来实现容错的能力。这两个概念十分相似并且它们共享了很大一部分实现。
然而由于遵循不同的功能要求这两个概念逐渐变得不一致使用户看起来没有完整的顶层设计。根据用户反馈这两个概念应该被更好地对齐和协调最重要的是这两个概念应该被更清晰的定义。
在某些停止或重新启动作业的场景下虽然逻辑上应该使用 Savepoint但用户还是会选择使用持久化的 Checkpoint因为 Savepoint 无法享受 Checkpoint 可以使用的一些优化而导致执行较为缓慢。但是在这种情况下作业从持久化的 Checkpoint 重启时 (这种情况下 Checkpoint 实际上被当作 Savepoint 来使用)对用户来说何时可以清理 Checkpoint 中的数据并不十分清楚。
因此在 FLIP-193: 状态所属权[6] 中Flink 希望可以将 Savepoint 和 Checkpoint 抽像成唯一区别是所属权不同的两个概念。在 1.15 中通过支持原生的增量 Savepoint[7]Flink 解决了 Savepoint 的一些不足在过去的版本中Savepoint 总是使用标准格式以及非增量的方式这也是导致它性能较差的原因。在 1.15 中如果用户选择使用原生格式并且同时使用了 RocksDB 状态存储那么 Savepoint 将采用增量的方式来执行。我们也更新了相关文档来更好的概览与理解 Checkpoint 与 Savepoint 的差异。此外关于从 Savepoint / 持久化的 Checkpoint 恢复[8] 的语义我们显式的引入了 CLAIM 与 NO_CLAIM 两种模式。对于 CLAIM 模式 Flink 将接管快照中数据的所属权而对于 NO_CLAIM 模式Flink 将创建它自己的副本而由用户来负责管理与删除原始的数据。注意现在默认将采用 NO_CLAIM 模式之前版本中从 Savepoint / 持久化的 Checkpoint 恢复的行为可以通过指定 LEGACY 模式来恢复。
基于 Reactive 模式与自适应调度器的弹性伸缩
由于越来越多的云服务基于 Apache Flink 构建 Flink 项目变得越来越云原生这使得弹性伸缩也越来越重要。
此版本改进了 Reactive 模式[9] 的指标。Reactive 模式是一个作业级别的模式在这种模式下 JobManager 将尝试使用所有可用的 TaskManager 上的资源。我们在 1.15 中保证了作业级别的指标在 Reactive 模式下也可以正常的工作。
我们还为自适应调度器[10] 添加了异常历史记录。自适应调度器是一个新的调度器它首先声明了所需的资源并且根据根据资源情况在执行前决定资源的并行度。
此外Flink 提高了缩减作业规模的速度TaskManager 现在有一个专用代码路径来关闭自己它会主动从集群中注销自己而不是依赖于心跳从而给 JobManager 一个明确的缩减作业规模的信号。
自适应批调度器
在 1.15 中我们为 Apache Flink 引入了一个新的自适应批处理调度器[11]。这一调度器可以自动根据每个节点需要处理的数据量的大小自动决定批处理作业中各节点的并行度。
此调度器的主要优点包括
易用性批处理作业的用户不再需要手动调优并行度。自适应自动调整并行度可以更好地适应节点消费数据集随时间发生变化的情况。细粒度每个作业节点的并行度可以单独调整。这允许 SQL 批处理作业的节点自动为每个节点选择单独选择最适合的并行度。
跨源节点的 Watermark 对齐
如果一个作业中使用了多个数据源节点并且这些数据源以不同的节奏来增长 Watermark这可能在下游节点中产生一些问题。例如一些算子可能需要缓存非常大量的数据从而导致巨大的算子状态。因此我们在这一版本中引入了 Watermark 对齐的能力。
基于新的 Source 接口来实现的数据源节点可以启用 Watermark 对齐功能[12]。用户可以定义对齐组如果其中某个源节点与其它节点相比 Watermark 领先过多用户可以暂停从该节点中消费数据。对齐 Watermark 的理想情况是有两个或更多以不同速度产生 Watermark 的数据源节点并且数据源节点并发与外部系统的分片数量相同的情况。
SQL 版本升级
SQL 查询的执行计划及其生成的拓扑是通过优化规则和一个基于成本的模型来得到的这意味着即使最小的更改也可能会产生一个完全不同的拓扑。这种动态性使得在不同 Flink 版本间保证快照兼容性非常具有挑战性。在 1.15 中社区首先通过保持拓扑不变的方式使相同的查询在升级 Flink 版本后仍然可以启动和执行。
SQL 升级的核心是 JSON 计划 (即以 JSON 表达的查询执行计划我们目前只有 JavaDocs 中的文档并且仍在努力更新文档[13])JSON Plan 可以让 SQL 计划以结构化数据的方式被导入和导出之前这一功能是一个内部实现现在它将被公开以提供给用户使用。Table API 与 SQL 都会提供一种方式来编译和执行一个保证在不同版本中保持不变的执行计划。此功能将作为实验性 MVP 功能发布。想要尝试的用户已经可以创建一个 JSON 计划然后可以使用这一计划在升级后基于旧的算子结构恢复 Flink 作业。我们将在 1.16 中提供这一功能的完整支持。
从长远来看可靠的升级使 Flink SQL 可以在线上生产场景更加可靠的使用。
基于 Changelog 的状态存储
在 Flink 1.15 中我们引入了 MVP 特性基于 Changelog 的状态存储[14]。这一新的状态存储旨在支持更短、更可以预测的 Checkpoint 间隔。它具有以下优势
更短的端到端延迟端到端延迟主要取决于 Checkpoint 机制特别是使用了两阶段提交的支持端到端一致性的 Sink 节点的情况这种情况下缩短 Checkpoint 周期意味着可以更快的提交数据。更可预测的 Checkpoint 间隔目前 Checkpoint 的完成时间很大程度上取决于需要保存在 Checkpoint 中的数据的大小。通过使这一数据总是可以很小Checkpoint 的完成时间变得更加可以预测。恢复工作更少Checkpoint 越频繁每次重启后重新处理的数据也会越少。
基于 Changelog 的状态存储通过在后台不断向非易失性存储上上传状态变化的记录来实现上述目标。
可重复的清理
在以前的 Flink 版本中Flink 在作业结束时只尝试清理一次与作业相关的残留数据这可能会导致在发生错误时无法完成清理。在这个版本中Flink 将尝试重复运行清理以避免残留数据。默认情况下Flink 将不断重试机制直到运行成功为止。用户可以通过配置相关参数[15] 来改变这种行为。禁用重试策略可以恢复 Flink 之前版本的行为。
清理 Checkpoint 的相关工作仍在进行中包括 FLINK-26606[16]。
Open API
Flink 现在提供遵循 Open API[17] 标准的 REST API 规范。这允许 REST API 与遵循 Open API 标准的工具直接交互。您可以在 [18] 找到相应规范。
Application模式的改进
在 Application 模式[19] 下运行 Flink 时如果用户进行了相关配置[20]它现在可以保证作业在结束前能够正常完成 stop-with-savepoint 操作。
在 Application 模式下运行的作业的恢复和清理也得到了改进。本地状态的元数据也可以保存在工作目录中这使得从本地状态恢复更容易 (例如将工作目录设定在非易失的跨机器的存储中的情况之前本地状态的元数据保存在内存中因此在作业恢复时无法找回)。
流批一体的更多进展
在最新版本中我们对流批一体的支持进行了进一步的完善。
作业结束前的 Checkpoint
在 Flink 1.14 中添加了对作业结束前等待一次 Checkpoint 操作的支持从而保证使用流模式处理有限数据可以保证所有被据被提交但是在 1.14 中该功能必须被手动启用。自上次发布以来我们听取了用户反馈并决定默认启用它。关于这一功能的更多信息以及如何禁用此功能请参阅 [21]。需要指出的是这一默认配置的变化可能延长使用流模式处理有界数据时的执行时间因为作业必须在结束前等待下一个 Checkpoint 完成。
Window table-valued 函数
Window table-valued 函数[22] 之前仅可用于流模式下。在 1.15 中它们现在也可以在批模式下使用。此外通过实现一个专门的算子我们现在不再要求这些 Window 函数必须定义一个聚合器从而进一步增强了 Window table-valued 函数。
Flink SQL
社区指标表明 Flink SQL 被广泛使用并且变得越来越流行。在 1.15 中社区对 Flink SQL 也做了许多改进下文将更加详细地讨论其中两个改进。
CAST / 类型系统增强
数据以各种形式出现但是并不是所有情况下都是用户需要的类型因此 CAST[23] 是 SQL 中最常见的操作之一。在 Flink 1.15 中失败的 CAST 的默认行为已从返回 null 更改为返回错误从而使它更符合 SQL 标准。之前的行为可以通过调用新引入的 TRY_CAST 函数或通过在恢复时配置相应参数来实现。
此外Flink 1.15 也修正了许多 CAST 的错误并对它的功能进行了改进从而保证结果的正确性。
JSON 函数
JSON 是最流行的数据格式之一越来越多的 SQL 用户需要生成或读取 JSON 类型的数据。Flink 1.15 根据 SQL 2016 标准引入了多个 JSON 处理函数[24]。这些函数允许用户来使用 Flink SQL 方言检查、创建和修改 JSON 字符串。
社区支持
Flink 的一个重要目标是使用户能够构建流数据管道来解决他们的用例。一般来说Apache Flink 不会单独使用而是作为更大的数据分析平台中的重要一环。因此简化 Flink 在云环境下的使用与维护、支持无缝连接到其他系统并继续支持 Java 和 Python 等编程语言对完善 Flink 生态十分重要。
云环境互操作性
许多用户在不同云服务提供商所提供的云基础设施中部署与使用 Flink同时也有一些服务可以帮助用户管理部署在他们的平台上的 Flink 集群。
在 Flink 1.15 中我们新增了写入 Google Cloud Storage 的支持。我们还整理了 Flink 生态中的连接器并把精力放在支持 AWS 相关的生态上 (即 KDS[25] 与 Firehose[26])。
Elasticsearch Sink
我们在 Flink 的整个连接器生态上进行了大量工作但我们想强调 Elasticsearch Sink[27]它是基于最新的 Sink API 来实现的因此可以提供异步输出与端到端一致性的能力。它可以作为未来更多 Sink 实现的模板。
Scala-free 的 Flink
博文[28] 已经解释了为什么 Scala 用户现在可以结合任何 Scala 版本 (包括 Scala 3) 使用 Flink的 Java API。
最后删除 Scala 依赖只是清理和更新来自 Flink 生态系统的各种技术的更大工作的一部分。
从 Flink 1.14 开始我们移除了 Mesos 集成隔离了 Akka废弃了 DataSet Java API并将 Table API 隐藏在一个抽象后面。社区的这些努力也吸引了许多用户与贡献者的关注。
PyFlink
在 Flink 1.15 之前Python API 中用户定义的函数是在单独的 Python 进程中执行的这将导致额外的序列化/反序列化和进程通信开销。在数据较大的场景中例如图像处理等这个开销变得不可忽视。此外由于它涉及进程间通信这一处理延迟也是不可忽略的。这些问题在延迟至关重要的场景是不可接受的例如量化交易等。因此在 Flink 1.15 中我们引入了一种 “线程” 模式的新执行模式用户自定义的函数将在 JVM 中作为线程执行而不是在单独的 Python 进程中执行。基准测试表明在 JSON 处理等常见场景中吞吐量可以增加 2 倍处理延迟也从几秒到微秒。需要指出的是由于这仍然是 “线程” 模式的第一个版本此前它仅支持 Python Table API 与 SQL 中的标量函数。我们计划在下一版本中将其扩展到 Python API 中其他类型的自定义函数。
其 它
Flink 1.15 进一步完善了对于连接器测试框架[29] 的支持如果你想贡献一个连接器或改进一个连接器你绝对应该看一下这部分工作。
Flink 1.15 也添加了一些期待已久的功能包括 CSV 格式[30] 与小文件压缩[31]。
同时Sink API 被升级到版本 2[32]。我们鼓励每个连接器的维护者升级到这个版本。
总 结 Apache Flink 简化了运维操作在对齐流批处理功能取得进一步进展改进了 SQL 组件使其变得更易于使用并且现在可以更好地与其他系统进行集成。
同值得一提的是社区为 CDC 连接器[33] 建立了一个新家。同时连接器相关代码[34] 将被移动到 Flink 外一个单独的仓库中 (以 Elasticsearch Sink 作业第一个例子[35]。此外现在社区新增了一个由社区维护的关于 K8s Operator[36] 的公告博客[37]。
展望未来社区将继续专注于使 Apache Flink 成为真正的流批一体处理系统并致力于将 Flink 更好地集成到云原生生态系统中。
更多资讯内容请查看该链接flink.apache.org/news/2022/0…
原文链接Apache Flink 1.15正式发布 - 掘金 (juejin.cn)
