Fink初识

最新推荐文章于 2024-09-29 13:41:04 发布

圆师傅

最新推荐文章于 2024-09-29 13:41:04 发布

阅读量893

点赞数 17

分类专栏：大数据文章标签： flink streaming

本文链接：https://blog.csdn.net/Apple_wolf/article/details/141336108

版权

大数据专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1. Flink核心组件

组件名	组件职责	实现
Fink Client	将作业提交给Job Manager	Command Line Interface, Rest Endpoint, Sql Client , python REPL, Scala REPL
Job Manager	Flink的中心协调组件	Standalone、Kubernetes、YARN、Mesos
Task Manager	执行flink作业的进程

2. Flink核心概念

概念	说明
Task	一个阶段多个功能相同subTask的集合，类似于Spark中的TaskSet
subTask	Flink中的最小执行单元，是一个Java类的实例，这个Java类中有属性和方法，完成具体的计算逻辑。
Slot	Flink 中计算资源进行隔离的单元，一个 Slot 中可以运行多个 subTask，但是这些 subTask 必须是来自同一个 Application 的不同阶段的 subTask
State	Flink 在运行过程中计算的中间结果
Source	Flink作业的数据源，可以是本地文件、kafka或者socket等等
Transformation	责处理数据的算子，包括map，filter、reduce等等
Sink	Flink作业的数据存放点，可以是mysql，kafka等

3. 执行应用程序的三种模式

session mode
per-job mode
application mode

3.1 session mode

Session Mode 是预分配资源的，也就是提前根据指定的资源参数初始化一个 Flink 集群，拥有固定数量的 JobManager 和 TaskManager。（JobManager 只有一个）
这样做的好处是，提交的作业可以直接执行，无需花费额外的开销去启动集群。相应地，Session Mode 的弊端也很明显。如果 TaskManager 因某个作业崩溃了，那么该 TaskManager 上运行的所有作业都会受到故障的影响。除了对相关作业产生负面影响外，这还意味着潜在的大规模恢复过程。此外，只有一个集群也意味着 JobManager 的负载大大增加，这是具有一定风险的。

3.2 per-job mode

Per-Job Mode 可以基于资源协调框架（如 YARN、k8s）为每个提交的作业启动专属的 Flink 集群。这提供了更好的资源隔离保证，当作业完成后，集群将被关闭，所有附属的资源也会被清除。
这样的好处是，一个作业的 TaskManager 失败不会影响其他作业的运行，且 JobManager 的负载是分散开来的，不存在单点问题。当然，缺点也很明显，为每个作业启动一个集群会消耗更多的集群资源，同时也会导致一定程度的延时。

3.3 application mode

在 Per-Job Mode 和 Session Mode 下，应用程序的 main 方法都是在客户端执行的，此过程包括：

在本地下载应用程序依赖项
提取 Flink 运行时可以理解的应用程序表示形式（即 JobGraph）
将依赖项和 JobGraph 传输到 Flink 集群

这导致客户端需要消耗非常多的资源，因为它可能需要大量的网络带宽来下载依赖项并将二进制文件传输到集群，并且需要 CPU 资源来执行 main 方法。当有多用户共享客户端时，这个问题将更加明显。

为解决 Per-Job Mode 和 Session Mode 存在的这个缺陷，Application Mode 在 Per-Job Mode 的基础上，将应用程序的 main 方法转移到 JobManager 上执行。通过这种体系结构，Application Mode 提供了与 Per-Job Mode 相同的资源隔离和负载平衡保证，同时也解决了客户端负载过多的问题。

与 Per-Job Mode 相比，Application Mode 允许提交包含多个作业的应用程序。作业的执行顺序不受部署模式影响，但受启动作业调用位置的影响。使用 execute 会导致“下一个”作业的执行被推迟到“该”作业完成为止，使用非阻塞的 executeAsync() 可以使“下一个”作业在“此”作业完成之前就开始

4. Job Manager

Job manager由三个不同的组件组成：

Resource Manager
Dispatcher
Job Master

4.1 Resource Manager

Resource Manager负责Flink集群中的资源提供、回收与分配。
它是 Task Slot （Flink 集群中资源调度的单位，位于 TaskManager 中）的管理者。当 ResourceManager 接收来自 JobManager 的资源请求时，会将存在空闲 slot 的 TaskManager 分配给 JobManager 执行任务。

4.2 Dispatcher

Dispatcher 提供了一个 REST 接口，用来提交 Flink 应用程序，并为每个提交的作业启动一个新的 JobMaster。此外，它还会启动 Flink Web UI 用来显示作业执行信息。

4.3 Job Master

负责管理单个JobGraph的执行，Flink集群中可以同时运行多个作业，每个作业都有自己的Job Master。

5. Watermark

从数据结构看，watermark是一个包含时间戳的数据对象。
从定义上看，watermark是一个度量Event time进展的机制，表明Event time在watermark之前的元素均已流入，不应该再有Event time小于watermark的元素进入数据流。
从功能上看，watermark可以起到控制窗口触发时机的作用，根据这种特性，用户可以为watermark设置一个延时参数，实现延迟触发窗口，为乱序数据流下的窗口提供一定的等待时间。

6. State

State 是记录有状态算子任务计算结果的载体，支持中间结果的读取、保存、更新与清除。

7.时间属性

7.1 处理时间 processing time

执行处理操作的机器的系统时间

7.2 事件时间 Event time

每个事件在对应的设备上发生的时间，也就是数据生成的时间。数据一旦产生，这个时间自然就确定了，所以他作为一个属性嵌入到数据中，是这条数据的时间戳。

但是由于分布式系统中网络传输延迟的不确定性，实际应用中我们要面对的数据流往往是乱序的。在这种情况下，就不能简单地把数据自带的时间戳当作时钟了，而需要用另外的标志来表示事件时间进展，在Flink中把它叫作事件时间的“水位线”（Watermarks）。

7.3 摄取时间Ingestion Time

摄取时间是数据被 Flink 任务接收的时间。
这种时间语义类似于处理时间，但时间戳是在数据进入 Flink 系统时生成的，而不是在具体任务处理时生成。
摄取时间模式下，事件的水位线和时间戳与事件实际生成的时间无关，而是与它们进入 Flink 系统的时间相关。

8. 检查点与保存点

8.1 检查点 check point

检查点是 Flink 的一种自动故障恢复机制。
它周期性地对 Flink 作业的当前状态进行快照，并将其存储到持久化存储中。
检查点可以配置为在一定时间间隔内自动触发，或者在处理了特定数量的元素后触发。
在检查点过程中，Flink 会生成一系列检查点屏障（barriers），这些屏障会阻止数据流，直到所有数据都达到了相同的检查点。
检查点状态包括了键控状态（Keyed State）和操作符状态（Operator State）。

8.2 保存点

保存点是 Flink 作业的手动持久化快照，可以被视为作业的特定版本的备份。
与检查点不同，保存点是手动触发的，并且可以被停止或取消。
保存点非常有用于升级 Flink 作业、修改作业的并行度，或者在不同环境之间迁移作业。
保存点可以包含作业的状态和配置信息，允许作业从特定的状态和配置开始执行。

9. 窗口

9.1 窗口分类

窗口是 Flink 中用于处理有限数据子集的机制，可以是基于时间的（如滚动窗口、滑动窗口）或基于数据量的（如全局窗口、滚动计数窗口）。

1. 滚动窗口：滚动窗口是固定大小的窗口，每个窗口不会重叠。例如，每5秒钟一个窗口，从00:00:00到00:00:05是第一个窗口，00:00:05到00:00:10是第二个窗口，以此类推。
1. 滑动窗口：滑动窗口同样是固定大小，但每个窗口之间有重叠。例如，一个大小为10秒，滑动步长为5秒的窗口，会在每个5秒的边界上滑动。
1. 会话窗口是根据事件的自然间隙来分组的窗口。如果事件在一定时间内没有发生，则会启动一个新的会话窗口。会话窗口的大小不固定。
1. 全局窗口：全局窗口是包含所有数据的单个窗口，通常与特定的触发器和evictor（驱逐器）结合使用，以确定何时输出结果。
1. 计算窗口：计数窗口是基于事件数量的窗口，当达到指定数量的事件时，窗口会被触发处理。