Flink 部署——概览

最新推荐文章于 2024-07-24 11:58:44 发布

京河小蚁

最新推荐文章于 2024-07-24 11:58:44 发布

阅读量491

点赞数

分类专栏： flink 文章标签： flink big data

本文链接：https://blog.csdn.net/u010772882/article/details/125380526

版权

flink 专栏收录该内容

86 篇文章 33 订阅

订阅专栏

文章目录

概览和参照架构
部署模式
供应商的解决方案

Flink是一个通用的大数据计算框架，在混合匹配的方式下支持适用于多种场景的部署方案。

下面我们一起学习一下部署集群的构建模块，它们的用途和可用的实现，如果仅仅想用本地模式，那么部署一套standalone模式即可满足你的需求。

概览和参照架构

下面的几点展示了构建每一个集群需要的几个模块，首先flink客户端将用户提交的代码，转成一个jobgraph然后提交给集群的jobmanager 。

Jobmanager将用户代码最后转成一个可执行的图，分发给TaskManagers ,这里是代码片段即算子(比如，sources,transforms,sink)执行的资源空间。

当部署flink的时候，每一个模块经常有多种类的选项可以使用，在下面中一一列举了出来。
在这里插入图片描述

Flink 组件

Flink Client：将批处理或流处理应用程序编译为数据流图，然后提交给JobManager，有以下四种表现形式：
1. Command Line Interface
2. REST Endpoint
3. SQL Client
4. Python REPL
JobManager：JobManager是Flink的中心工作协调组件的名称。它有针对不同资源提供程序的实现，这些实现在高可用性、资源分配行为和支持的作业提交模式上有所不同。
JobManager工作提交模式:
1. Application Mode:为一个应用独占运行集群。作业的主方法(或客户端)在JobManager上执行。支持在应用程序中多次调用’ execute ’ / ’ executeAsync '。
2. Per-Job Mode:仅为一个作业运行集群。作业的主方法(或客户端)只在集群创建之前运行。
3. Session Mode: 一个JobManager实例管理多个共享同一个taskmanager集群的作业
TaskManager：TaskManagers是实际执行Flink作业的服务。

External Components (all optional)

组件	目的	实现
High Availability Service Provider		Zookeeper,Kubernetes HA
File Storage and Persistency	对于检查点(流作业的恢复机制)，Flink依赖于外部文件存储系统
Resource Provider	Flink可以通过不同的资源提供框架进行部署，例如Kubernetes或YARN。
Metrics Storage	Flink组件报告内部指标，Flink作业也可以报告额外的、特定于作业的指标。
Application-level data sources and sinks	虽然应用程序级数据源和接收器在技术上不是Flink集群组件部署的一部分，但在规划新的Flink生产部署时应该考虑它们。使用Flink对经常使用的数据进行定位可以获得显著的性能优势	例如:Apache Kafka、Amazon S3、ElasticSearch、Apache Cassandra

可重复的资源清理

一旦作业达到完成、失败或取消的全局终端状态，与该作业关联的外部组件资源将被清除。如果在清理资源时失败，Flink将尝试重试清理。可以配置重试策略。达到重试的最大次数而没有成功将使作业处于脏状态。它的工件需要手动清理(详见高可用性服务/ JobResultStore小节)。重新启动相同的作业(即使用相同的作业ID)将导致重新启动清理，而无需再次运行作业。

目前存在一个问题，即当将completed检查点纳入通常的CompletedCheckpoint管理时，无法删除它们。这些工件不会被可重复的清理所覆盖，也就是说，它们仍然需要手动删除。这是由FLINK-26606覆盖的。

部署模式

in Application Mode,
in a Per-Job Mode,
in Session Mode.

上述模式的不同之处在于:

集群生命周期和资源隔离保证
应用程序的main()方法是在客户机上执行还是在集群上执行。

在这里插入图片描述

Application Mode （应用模式）

在所有其他模式中，应用程序的main()方法在客户端执行。这个过程包括本地下载应用程序的依赖项，执行main()来提取Flink运行时可以理解的应用程序的表示(即JobGraph)，并将依赖项和JobGraph发送到集群。这使得客户机成为一个大量的资源消耗者，因为它可能需要大量的网络带宽来下载依赖项并将二进制文件发送到集群，并且需要CPU周期来执行main()。当客户端在多个用户之间共享时，这个问题会更加明显。

在此基础上，Application Mode为每个提交的应用程序创建一个集群，但这一次，应用程序的main()方法在JobManager上执行。可以将为每个应用程序创建集群视为创建一个会话集群，该会话集群仅在特定应用程序的作业之间共享，并在应用程序完成时被销毁。通过这种架构，应用程序模式提供了与Per-Job模式相同的资源隔离和负载平衡保证，但其粒度是整个应用程序的粒度。在JobManager上执行main()可以节省所需的CPU周期，还可以节省本地下载依赖项所需的带宽。此外，它允许更均匀地分散网络负载，以便下载集群中应用程序的依赖项，因为每个应用程序都有一个JobManager。

在应用程序模式中，main()在集群上执行，而不是在客户机上执行，与其他模式一样。这可能会对代码产生影响，例如，使用registerCachedFile()在环境中注册的任何路径都必须由应用程序的JobManager访问。

与Per-Job模式相比，Application模式允许提交由多个作业组成的应用程序。作业执行的顺序不受部署模式的影响，而是受启动作业的调用的影响。使用execute()，它是阻塞的，建立一个顺序，它将导致“下一个”作业的执行被推迟到“这个”作业完成。使用非阻塞的executeAsync()将导致“下一个”作业在“这个”作业结束之前开始。

应用程序模式允multi-execute()应用程序，但在这些情况下不支持高可用性。应用程序模式中的高可用性仅支持单执行()应用程序。

此外，当应用程序模式(Application Mode，例如使用executeAsync()提交的)中任何一个正在运行的作业被取消时，所有作业都将停止，JobManager也将关闭。支持常规作业完成(通过源关闭)。

Per-Job Mode

为了提供更好的资源隔离保障，Per-Job模式使用可用的资源提供者框架(例如YARN, Kubernetes)为每个提交的作业旋转一个集群。此集群仅对该作业可用。当作业完成时，将关闭集群，清除所有滞留资源(文件等)。这提供了更好的资源隔离，因为行为不端的作业只能关闭它自己的TaskManagers。此外，它将簿记的负担分散到多个JobManagers中，因为每个job都有一个。由于这些原因，Per-Job资源分配模型是许多生产方面的首选模式。

Session Mode

会话模式假设一个已经在运行的集群，并使用该集群的资源来执行任何提交的应用程序。在同一个(会话)集群中执行的应用程序使用相同的资源，因此会竞争相同的资源。这样做的好处是，您不需要为每个提交的作业占用整个集群的资源开销。但是，如果其中一个作业出错或使TaskManager关闭，那么在该TaskManager上运行的所有作业都将受到故障的影响。这除了对导致失败的作业造成负面影响外，还意味着潜在的大规模恢复过程，所有重新启动的作业都并发地访问文件系统，使它对其他服务不可用。此外，让一个集群运行多个作业意味着JobManager的负载更大，JobManager负责记录集群中的所有作业。

总结

在Session模式下，集群的生命周期独立于集群上运行的任何作业的生命周期，所有作业共享资源。Per-Job模式的代价是为每个提交的作业旋转集群，但它提供了更好的隔离保证，因为资源不会在作业之间共享。在这种情况下，集群的生命周期绑定到作业的生命周期。最后，Application Mode为每个应用程序创建一个会话集群，并在集群上执行应用程序的main()方法。