Apache Flink 核心概念术语全解从集群架构、数据流模型到状态与容错机制【免费下载链接】flink项目地址: https://gitcode.com/gh_mirrors/fli/flink导读Flink 的官方文档、源码注释与社区讨论中充斥着大量术语——Flink Application、JobGraph、ExecutionGraph、Operator Chain、State Backend、UID hash……这些概念彼此关联构成了理解 Flink 运行机制的地基。本文以 docs/content/docs/concepts/glossary.md 中的官方术语表为主体骨架逐条解析全部核心术语并结合本仓库的flink-runtime、flink-streaming-java等模块源码加以印证与扩充。读完本文你将能够准确区分集群与进程作业与图任务与子任务状态与检查点这几组最容易混淆的概念并在阅读 Flink 源码、排查运行日志或设计作业时自如使用这些术语。一、总体脉络Flink 的四层抽象模型glossary 中的 30 个术语并非彼此孤立它们天然地落在四层抽象上层次关键术语进程与集群层Flink Cluster、Flink JobManager、Flink JobMaster、Flink TaskManager、Flink Application Cluster、Flink Job Cluster、Flink Session Cluster作业与图层Flink Application、Flink Job、Logical Graph、JobGraph、Physical Graph、ExecutionGraph执行单元与数据层Operator、Function、Instance、Task、Sub-Task、Operator Chain、Record、Event、Partition、Transformation状态与容错层Managed State、State Backend、Checkpoint Storage、JobResultStore、UID、UID hash、Table Program、Execution Mode从用户编写的代码到真正运行在分布式环境中的任务数据要依次经历应用 → 作业 → 逻辑图 → 物理图 → 任务的层层转换而状态、检查点与标识符则贯穿始终保证作业的可靠性与可恢复性。下面逐层展开。二、集群与进程谁在分布式系统里干活Flink ClusterFlink 集群A distributed system consisting of (typically) one JobManager and one or more Flink TaskManager processes.一个 Flink Cluster 是一个分布式系统典型地由一个 JobManager 进程和一个或多个 TaskManager 进程组成。它是 Flink 运行时的物理载体JobManager 负责协调与调度TaskManager 负责真正执行任务。在源码层面这两个进程的启动入口分别位于 flink-runtime/src/main/java/org/apache/flink/runtime/jobmaster/JobMaster.java 与 flink-runtime/src/main/java/org/apache/flink/runtime/taskexecutor/TaskManagerRunner.java。注意 glossary 用typically一词在某些测试或嵌入式场景下JobManager 与 TaskManager 可以共存在同一个 JVM 中但这不改变它们作为独立角色的定位。Flink JobManager作业管理器The JobManager is the orchestrator of a Flink Cluster. It contains three distinct components: Flink Resource Manager, Flink Dispatcher and one Flink JobMaster per running Flink Job.JobManager 是整个集群的协调者orchestrator它内部实际包含三个职责不同的组件Flink Resource Manager资源管理器负责集群资源的分配与回收对应源码中的 flink-runtime/src/main/java/org/apache/flink/runtime/resourcemanager/ResourceManager.java。它与部署平台如 YARN、Kubernetes、Standalone对接管理 TaskManager 的注册、槽位slot的分配与释放。Flink Dispatcher分发器负责接收作业提交请求为每个作业拉起对应的 JobMaster并对外提供 REST 接口。对应源码为 flink-runtime/src/main/java/org/apache/flink/runtime/dispatcher/Dispatcher.java。每个运行中作业一个 Flink JobMaster见下文。理解这三者的关系对排查问题很关键你在 Web UI 上看到的JobManager其实是这三类组件的综合体而日志中标注的 JobManager 日志可能同时包含 Dispatcher、ResourceManager 与多个 JobMaster 的输出。Flink JobMaster作业主管JobMasters are one of the components running in the JobManager. A JobMaster is responsible for supervising the execution of the Tasks of a single job.JobMaster 是 JobManager 内部每个作业对应一个的组件负责监督supervising单个作业的所有 Task 的执行。它持有该作业的调度、检查点协调、结果分区跟踪等运行时状态是整个作业运行期的大脑。对应实现即 JobMaster.java从源码 import 列表可以看到它涉及的职责范围极广slot 池SlotPoolService、心跳HeartbeatManager、结果分区跟踪JobMasterPartitionTracker、检查点CheckpointCoordinator等。一句话区分JobManager 是集群级进程JobMaster 是作业级组件JobManager 进程为每个运行中的作业维护一个 JobMaster。Flink TaskManager任务管理器TaskManagers are the worker processes of a Flink Cluster. Tasks are scheduled to TaskManagers for execution. They communicate with each other to exchange data between subsequent Tasks.TaskManager 是 Flink 集群的工作进程worker。Task 被调度到 TaskManager 上执行不同的 TaskManager 之间会互相通信以在前后相邻的 Task 之间交换数据这正是 Operator Chain 之外、需要走网络栈传输的场景。在源码中TaskManager 进程的核心类为 TaskManagerRunner.java而具体承载任务执行的组件在TaskManagerServicesflink-runtime/src/main/java/org/apache/flink/runtime/taskexecutor/TaskManagerServices.java中组装。TaskManager 的内存划分堆内/堆外、托管内存等直接影响状态后端与网络缓冲的可用空间因此 TaskManager 的资源配置往往是调优的第一步。三、三种集群部署形态Application / Job / Session Clusterglossary 用集群生命周期是否绑定作业这一维度区分了三种部署形态这是理解 Flink 部署模式的钥匙。Flink Application 与 Flink Application Cluster应用集群先看 Flink Application 的定义A Flink application is a Java Application that submits one or multiple Flink Jobs from themain()method (or by some other means). Submitting jobs is usually done by callingexecute()on an execution environment.Flink Application 是一个 Java 应用它从main()方法或通过其他方式提交一个或多个 Flink Job提交动作通常通过调用执行环境的execute()完成。一个应用既可以把作业提交给长期运行的 Session Cluster也可以提交给专用的 Application Cluster 或 Job Cluster。Flink Application Cluster则是只执行来自一个 Flink Application 的作业的专用集群集群生命周期与应用的运行生命周期绑定——应用启动则集群拉起应用结束main()返回则集群随之释放。这种模式让每个应用拥有完全独立的资源与 ClassLoader 环境避免作业间相互干扰是生产环境推荐的部署方式之一。Flink Job Cluster作业集群A Flink Job Cluster is a dedicated Flink Cluster that only executes a single Flink Job. The lifetime of the Flink Cluster is bound to the lifetime of the Flink Job. This deployment mode has been deprecated since Flink 1.15.Flink Job Cluster 是只执行单个 Flink Job的专用集群集群生命周期与作业生命周期绑定。glossary 明确标注该部署模式自 Flink 1.15 起已被弃用deprecated。如果你在旧版本资料中看到per-job cluster的说法指的就是这种形态在新版本中应改用 Application 模式应用模式两者的资源隔离收益相同但 Application 模式在运维与生命周期管理上更统一。Flink Session Cluster会话集群A long-running Flink Cluster which accepts multiple Flink Jobs for execution. The lifetime of this Flink Cluster is not bound to the lifetime of any Flink Job.Session Cluster 是一个长期运行的集群可同时接纳多个 Flink Job 执行集群生命周期不与任何单个作业绑定。过去它也被称为session mode下的 Flink Cluster。三种模式的对比速查模式集群生命周期可运行作业数资源隔离备注Application Cluster绑定应用生命周期一个应用的多个作业好独立集群生产推荐Job Cluster绑定单个作业生命周期仅一个好自 1.15 起弃用Session Cluster长期运行不绑定作业多个作业共享一般共享资源适合开发调试、小作业四、作业与四种图Logical / JobGraph / Physical / ExecutionGraphglossary 中反复出现图graph的概念这是 Flink 中最容易混淆的部分。核心在于区分逻辑图与物理图两个层级。Logical Graph逻辑图与 JobGraphA logical graph is a directed graph where the nodes are Operators and the edges define input/output-relationships of the operators and correspond to data streams or data sets.Logical Graph 是有向图节点是 Operator边描述算子之间的输入/输出关系对应数据流data stream或数据集data set。它由 Flink Application 提交作业时创建通常也被称为dataflow graph数据流图。在 DataStream API 中用户代码经过StreamGraphGenerator见 flink-streaming-java/src/main/java/org/apache/flink/streaming/api/graph/StreamGraphGenerator.java被翻译成StreamGraph再进一步转换为可提交的 JobGraph。glossary 明确指出JobGraph 就是 Logical Graph 的别名see Logical Graph。JobGraph 是作业提交给集群时的蓝图它被序列化后提交给 Dispatcher再由 JobMaster 消费。从源码结构看flink-runtime/src/main/java/org/apache/flink/runtime/jobgraph/目录下的JobGraph、JobVertex、JobEdge等类即对应这一层抽象的运行时实现。Physical Graph物理图与 ExecutionGraphA physical graph is the result of translating a Logical Graph for execution in a distributed runtime. The nodes are Tasks and the edges indicate input/output-relationships or partitions of data streams or data sets.Physical Graph 是 Logical Graph 为在分布式运行时中执行而翻译的结果节点变为 Task边表示输入/输出关系或数据流/数据集的分区关系。glossary 指出ExecutionGraph 是 Physical Graph 的别名see Physical Graph。ExecutionGraph 在源码中是分布式执行的核心数据结构见 flink-runtime/src/main/java/org/apache/flink/runtime/executiongraph/ExecutionGraph.javaThe execution graph is the central data structure that coordinates the distributed execution of a data flow. It keeps representations of each parallel task, each intermediate stream, and the communication between them.该接口的 Javadoc 进一步揭示了物理图内部的三个层级结构对应三种标识符ExecutionJobVertex对应 JobGraph 中的一个顶点通常是一个算子操作如 map 或 join持有该顶点所有并行子任务聚合后的状态用JobVertexID标识ExecutionVertex对应一个并行子任务subtask每个 ExecutionJobVertex 有多少并行度就有多少个 ExecutionVertex用ExecutionJobVertex 并行下标标识Execution一次对 ExecutionVertex 的执行尝试attempt。失败重试、或数据需要重算时会出现多次 Execution每次执行尝试用ExecutionAttemptID唯一标识——JobManager 与 TaskManager 之间所有关于任务部署与状态更新的消息都用 ExecutionAttemptID 寻址。图模型关系小结用户代码DataStream/SQL │ StreamGraphGenerator / 翻译 ▼ Logical Graph逻辑图节点Operator │ JobGraph作业提交蓝图 ▼ Physical Graph物理图节点Task │ ExecutionGraph运行时分布式执行结构 ▼ Task / Sub-Task在 TaskManager 上执行Flink Job作业A Flink Job is the runtime representation of a logical graph (also often called dataflow graph) that is created and submitted by callingexecute()in a Flink Application.Flink Job 是逻辑图数据流图的运行时表示由 Flink Application 中调用execute()创建并提交。因此一个应用可以包含多个作业多次调用execute()而每个作业都有自己独立的 JobMaster、ExecutionGraph 与生命周期。作业是资源分配、状态隔离与故障恢复的基本单位之一。五、数据模型Record、Event 与 PartitionRecord记录Records are the constituent elements of a data set or data stream. Operators and Functions receive records as input and emit records as output.Record 是数据集或数据流的基本组成元素Operator 与 Function 以 Record 为输入、以 Record 为输出。它是 Flink 处理的最小数据单元——无论底层是 Kafka 消息、文件行还是数据库变更日志进入 Flink 后都被抽象为 Record 流。Event事件An event is a statement about a change of the state of the domain modelled by the application. Events can be input and/or output of a stream or batch processing application. Events are special types of records.Event 是对应用所建模领域的状态变化的陈述例如用户下单传感器温度升高。它可以作为流式或批处理应用的输入和/或输出。关键区别在于Event 是 Record 的一种特殊类型——Event 承载业务语义描述发生了什么变化而 Record 是更通用的数据容器概念。Partition分区A partition is an independent subset of the overall data stream or data set. ... A transformation which changes the way a data stream or data set is partitioned is often called repartitioning.Partition 是数据流或数据集的独立子集。数据流/数据集通过把每条 Record 分配到若干个分区之一或之一上来完成划分运行时由 Task 消费各个分区。改变数据流/数据集分区方式的转换称为重分区repartitioning。分区是并行的基石一个算子的并行度是 N则其输出通常被划分为 N 个分区下游 N 个并行子任务各消费一个分区。常见的重分区转换包括 keyBy按键分区、rebalance轮询、broadcast广播等。当算子之间发生重分区时两个算子便无法被链接chaining为同一个 Operator Chain——这正是下一节要讲的链式结构的关键约束。六、执行单元Function、Operator、Instance、Task、Sub-Task 与 Operator ChainFunction函数Functions are implemented by the user and encapsulate the application logic of a Flink program. Most Functions are wrapped by a corresponding Operator.Function 是由用户实现、封装 Flink 程序业务逻辑的代码单元如MapFunction、FlatMapFunction、ProcessFunction。大多数 Function 会被相应的 Operator 包装——也就是说用户写的是 Function而 Flink 运行的是包装了该 Function 的 Operator。Operator算子Node of a Logical Graph. An Operator performs a certain operation, which is usually executed by a Function. Sources and Sinks are special Operators for data ingestion and data egress.Operator 是逻辑图的节点执行某种操作通常由 Function 完成。Source数据接入与 Sink数据输出是特殊类型的 Operator。因此逻辑图节点是 Operator与边是数据流的定义在此闭环一个算子对应一个或一组业务操作Source/Sink 作为边界算子负责数据的流入与流出。Instance实例与并行实例The terminstanceis used to describe a specific instance of a specific type (usually Operator or Function) during runtime. ... the termparallel instanceis also frequently used to emphasize that multiple instances of the same Operator or Function type are running in parallel.Instance 描述运行时某个特定类型通常是 Operator 或 Function的具体实例。由于 Flink 主要用 Java 编写这与 Java 中的Instance/Object概念一致。当同一 Operator 或 Function 类型的多个实例并行运行时则称为并行实例parallel instance——并行度是多少就有多少个并行实例。Task任务与 Sub-Task子任务Node of a Physical Graph. A task is the basic unit of work, which is executed by Flinks runtime. Tasks encapsulate exactly one parallel instance of an Operator or Operator Chain.Task 是物理图的节点是 Flink 运行时执行的基本工作单元。一个 Task 恰好封装一个 Operator 或 Operator Chain 的并行实例。A Sub-Task is a Task responsible for processing a partition of the data stream. The term Sub-Task emphasizes that there are multiple parallel Tasks for the same Operator or Operator Chain.Sub-Task 是负责处理数据流中一个分区的 Task。这个词强调同一 Operator 或 Operator Chain 存在多个并行 Task。简单说一个并行度为 N 的算子有 N 个并行实例每个实例对应一个 Sub-Task在物理图上它们各自是一个 Task 节点。实际运行消费分区的最小调度单位是 Sub-Task对应前文 ExecutionGraph 中的 ExecutionVertex。Operator Chain算子链An Operator Chain consists of two or more consecutive Operators without any repartitioning in between. Operators within the same Operator Chain forward records to each other directly without going through serialization or Flinks network stack.Operator Chain 由两个或更多连续的、中间没有重分区的 Operator组成。链内算子之间直接转发 Record不经过序列化也不走 Flink 网络栈——数据在同一 JVM 的同一线程内直接传递因而吞吐更高、延迟更低。理解这个术语要注意两点形成链的前提是算子间无重分区keyBy、rebalance 等会切断链同时各算子并行度需一致链一旦形成链上所有算子就被打包进一个 Task即一个 Operator Chain 封装为一个并行实例这正是Task 封装一个 Operator 或 Operator Chain的含义。在 Web UI 上看到的一个任务往往就是一条 Operator Chain链内各算子仍可通过disableChaining()等方法显式拆开。七、状态与检查点Managed State、State Backend、Checkpoint StorageManaged State托管状态Managed State describes application state which has been registered with the framework. For Managed State, Apache Flink will take care about persistence and rescaling among other things.Managed State 是已注册到框架Flink 运行时的应用状态。对于托管状态Flink 会负责**持久化persistence与重缩放rescaling**等事宜——即扩缩容时状态自动重新分配、故障时状态可从检查点恢复。与之相对的是 Raw State原生状态框架不感知其内部结构。State Backend状态后端For stream processing programs, the State Backend of a Flink Job determines how its state is stored on each TaskManager (Java Heap of TaskManager or (embedded) RocksDB).对于流处理程序State Backend 决定每个 TaskManager 上状态如何存储典型选项包括TaskManager 的 Java 堆Heap状态存放在 JVM 堆内读写快但受 GC 影响、容量受堆大小限制内嵌RocksDB状态存放在 TaskManager 本地磁盘上的 RocksDB 键值存储中容量大、适合大状态但每次读写涉及序列化。State Backend 决定状态存在哪、怎么存是状态存储策略层面的概念。本仓库中状态后端相关实现分布在 flink-state-backends 模块下如flink-statebackend-rocksdb、flink-statebackend-forst、flink-statebackend-heap-spillable等其中 RocksDB 后端即内嵌 RocksDB 的实现。Checkpoint Storage检查点存储The location where the State Backend will store its snapshot during a checkpoint (Java Heap of JobManager or Filesystem).Checkpoint Storage 是 State Backend 在检查点期间存放其快照snapshot的位置选项包括JobManager 的 Java 堆对应实现为 flink-runtime/src/main/java/org/apache/flink/runtime/state/storage/JobManagerCheckpointStorage.java。从该类的注释可以推断这种方式要求检查点快照必须能放进 JobManager 的 JVM 堆空间只适合状态极小或测试场景文件系统Filesystem对应实现为 flink-runtime/src/main/java/org/apache/flink/runtime/state/storage/FileSystemCheckpointStorage.java可配置 HDFS、S3、OSS 等持久化存储是生产环境的常见选择。三者关系一句话State Backend 决定状态在 TaskManager 上怎么存Checkpoint Storage 决定检查点时状态快照往哪儿放Managed State 是这两者所管理的状态对象本身。八、API 层面的抽象Transformation、Table Program 与运行时执行模式Transformation转换A Transformation is applied on one or more data streams or data sets and results in one or more output data streams or data sets. A transformation might change a data stream or data set on a per-record basis, but might also only change its partitioning or perform an aggregation.Transformation 应用于一个或多个数据流/数据集产出一个或多个输出。它可以按记录粒度改写数据也可以只改变分区方式或执行聚合。关键定位在最后一句While Operators and Functions are the physical parts of Flinks API, Transformations are only an API concept. Specifically, most transformations are implemented by certain Operators.Operator 与 Function 是 Flink API 的物理部分而 Transformation 只是 API 层面的概念——大多数 transformation 由特定 Operator 实现。也就是说map()、keyBy()、window()这类 API 调用是 Transformation它们在编译为逻辑图时会被翻译成对应的 Operator进而在运行时由 Operator/Function 真正执行。Table Program表程序A generic term for pipelines declared with Flinks relational APIs (Table API or SQL).Table Program 是用 Flink 关系型 APITable API 或 SQL声明的流水线的统称。与 DataStream API 程序相对Table Program 走的是关系代数路线声明式地描述做什么如SELECT ... WHERE ...由 Flink 的查询优化器基于 Calcite位于 flink-table/flink-table-planner 模块负责翻译与优化。(Runtime) Execution Mode运行时执行模式DataStream API programs can be executed in one of two execution modes:BATCHorSTREAMING.DataStream API 程序可以在两种运行时执行模式之一中运行BATCH批或STREAMING流。从 Flink 1.12 开始同一套 DataStream API 可以按模式切换语义流模式按事件时间持续处理、支持有界与无界流批模式则按有界数据集的整体处理、可应用批式调度与更积极的算子优化。详细说明见官方文档 Execution Mode。九、容错与恢复JobResultStore作业结果存储The JobResultStore is a Flink component that persists the results of globally terminated (i.e. finished, cancelled or failed) jobs to a filesystem, allowing the results to outlive a finished job. These results are then used by Flink to determine whether jobs should be subject to recovery in highly-available clusters.JobResultStore 是 Flink 的作业结果持久化组件它把**全局终止globally terminated**的作业即 finished、cancelled 或 failed的结果写入文件系统使结果在作业结束后仍然存在。这些结果随后被 Flink 用来判断在高可用HA集群中哪些作业需要被恢复——已确认终止且被标记为干净的作业不会被重复拉起而因异常中断的作业则可能被恢复。该组件的接口定义在 flink-runtime/src/main/java/org/apache/flink/runtime/highavailability/JobResultStore.java其 Javadoc 揭示了结果记录的两种状态dirty脏对应作业尚未被正确清理clean-up 尚未完成后续仍需执行清理动作clean干净对应作业的清理已完成无需进一步操作。接口中的createDirtyResultAsync与markResultAsCleanAsync两个方法即对应登记脏结果 → 清理完成后标记为干净的完整生命周期JobResultStore.java。实际文件系统实现为FileSystemJobResultStore位于同一highavailability包下配置项集中在 flink-runtime/src/main/java/org/apache/flink/runtime/highavailability/JobResultStoreOptions.java。十、算子身份标识UID 与 UID hashUID用户/结构标识A unique identifier of an Operator, either provided by the user or determined from the structure of the job. When the Application is submitted this is converted to a UID hash.UID 是一个 Operator 的唯一标识来源有二用户显式提供通过DataStream.uid(my-operator-id)DataStream API或 SQL 中的算子 hint 等方式指定根据作业结构自动确定未指定时Flink 根据算子在图中的结构信息生成。作业提交时UID 会被转换为UID hash。UID hashUID 哈希A unique identifier of an Operator at runtime, otherwise known as Operator ID or Vertex ID and generated from a UID. It is commonly exposed in logs, the REST API or metrics, and most importantly is how operators are identified within savepoints.UID hash 是运行时 Operator 的唯一标识也被称为Operator ID 或 Vertex ID由 UID 生成。它常见于日志算子相关日志中打印的标识REST API 与指标metricsWeb UI 与监控系统中展示的算子标识最重要的一点——savepoint 中算子的身份标识savepoint 恢复时正是依据 UID hash 把状态对回相应的算子。因此若作业拓扑结构变化导致自动生成的 hash 改变或未显式设置 UID 的算子顺序调整savepoint 恢复就可能失败——这就是官方一直建议为关键算子显式设置 UID的原因。Savepoint 的详细机制见 docs/content/docs/ops/state/savepoints.md。在源码层面UID hash 的生成逻辑位于flink-streaming-java模块的StreamGraphHasherflink-streaming-java/src/main/java/org/apache/flink/streaming/api/graph/StreamGraphHasher.java其 Javadoc 说明它是为 StreamGraph 生成哈希的接口为每个 StreamNode 计算一个哈希而运行时标识类OperatorID定义于 flink-runtime/src/main/java/org/apache/flink/runtime/jobgraph/OperatorID.java其中的fromJobVertexID(JobVertexID)工厂方法OperatorID.java展示了 OperatorID 与作业顶点 ID 之间的转换关系。十一、术语速查表术语一句话定义关键关联Flink Cluster一个 JobManager 若干 TaskManager 的分布式系统集群级Flink JobManager集群协调者含 Resource Manager、Dispatcher 与每个作业一个 JobMaster进程级Flink JobMaster监督单个作业所有 Task 执行的组件作业级Flink TaskManager执行 Task 的工作进程彼此通信交换数据进程级Flink Application从 main() 提交一个或多个作业的 Java 应用应用级Flink Application Cluster只执行一个应用的作业、生命周期绑定应用的专用集群部署形态Flink Job Cluster只执行单个作业、生命周期绑定作业的专用集群1.15 起弃用部署形态Flink Session Cluster长期运行、可执行多个作业、生命周期不绑定作业的集群部署形态Flink Job逻辑图数据流图的运行时表示由 execute() 创建作业级Logical Graph / JobGraph节点为 Operator 的有向图即数据流图 / 作业提交蓝图图模型Physical Graph / ExecutionGraph翻译自逻辑图、节点为 Task 的执行图运行时核心结构图模型Record数据集/数据流的基本组成元素数据模型Event描述领域状态变化陈述的 Record 特殊类型数据模型Partition数据流/数据集的独立子集改变划分方式称重分区数据模型Function用户实现的业务逻辑单元多数被 Operator 包装执行单元Operator逻辑图节点执行操作通常由 Function 完成Source/Sink 为特例执行单元Instance运行时某个 Operator/Function 类型的具体实例并行实例强调并行执行单元Task物理图节点封装一个 Operator 或 Operator Chain 的并行实例执行单元Sub-Task负责处理一个分区的 Task强调同一算子的多个并行 Task执行单元Operator Chain无重分区连续算子组成的链链内直接转发、不经序列化与网络栈执行单元Managed State注册到框架、由 Flink 负责持久化与重缩放的应用状态状态State Backend决定状态在每个 TaskManager 上如何存储Java 堆或 RocksDB状态Checkpoint Storage检查点时状态快照的存放位置JobManager 堆或文件系统检查点JobResultStore持久化全局终止作业结果、决定 HA 下哪些作业需要恢复的组件容错TransformationAPI 层面的数据流/数据集转换概念多数由 Operator 实现APITable Program用 Table API 或 SQL 声明的流水线统称APIExecution ModeDataStream 程序的 BATCH / STREAMING 两种执行模式APIUID算子唯一标识用户提供或按作业结构确定标识UID hash由 UID 生成的运行时算子标识Operator ID / Vertex IDsavepoint 依此识别算子标识结语把术语串成一条主线回顾全文Flink 的核心术语其实可以被一条主线串起你编写一个 Flink Application应用在main()中调用execute()提交 Flink Job作业作业以 Logical Graph / JobGraph逻辑图节点是 Operator边是数据流为蓝图被翻译为 Physical Graph / ExecutionGraph物理图节点是 Task边对应 PartitionTask 封装 Operator 或 Operator Chain 的并行实例Sub-Task并被调度到 TaskManager 上执行而 JobMaster 在 JobManager 中监督这一切执行期间Managed State 按 State Backend 的策略在 TaskManager 上存储检查点快照按 Checkpoint Storage 的配置落位作业结束后 JobResultStore 记录其最终结果UID / UID hash 则保证 savepoint 能准确把状态对回算子。掌握了这条主线你就拥有了阅读 Flink 文档、理解运行日志、排查故障乃至深入源码的统一语言。进一步探索时可以从 glossary.md 出发配合 execution_mode.md执行模式、savepoints.md保存点以及本仓库flink-runtime、flink-streaming-java源码按图索骥地深入每个概念背后的实现。【免费下载链接】flink项目地址: https://gitcode.com/gh_mirrors/fli/flink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考