（一）Flink 概览

本章针对 Apache Flink 的基本概念、主要组件、运行架构、版本历史进行介绍，让学者对 Flink 这项分布式处理技术能够有初步的了解。

目录

• Flink 是什么
• Flink 组件
• Flink 运行架构
• Flink 历史发展

Flink 是什么

Apache Flink 是由 Apache 软件基金会开发的开源流处理框架，是一个在无界和有界数据流上进行状态计算的框架和分布式处理引擎。Flink 已经可以在所有常见的集群环境中运行。目前市场上主流的流式计算框架有 Apache Storm、Spark Streaming、Apache Flink 等，但能同时支持低延迟、高吞吐、Exaactly-Once 的框架只有 Apache Flink。

• 同时支持高吞吐、低延迟

Flink 是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者为一身的分布式流式数据处理框架。Spark Streaming 在流式计算中无法做到低延迟保障。Apache Storm 可以做到低延迟，但无法满足高吞吐的要求。三者中，Flink 极大的提高了数据处理能力。

• 支持有状态的计算

Flink 在 1.4 版本中实现了状态管理。所谓状态，就是在流式计算过程中将中间结果数据保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果，从而无须每次都基于全部的原始数据来统计结果，极大地提升了系统性能，降低了数据计算过程中的资源消耗。

• 支持事件时间

目前大多数框架计算采用的都是系统处理时间（Process Time），也就是事件传输到计算框架处理时，系统主机的当前时间。Flink 能够支持事件时间（Event Time），根据事件本身自带的时间戳（事件的产生时间）进行结果的计算，这种基于事件驱动的机制使得事件即使乱序到达，Flink 也能够计算出精确的结果，保证了结果的准确性和一致性。

• 支持高度灵活的窗口

流式计算中，数据是连续不断的，需要通过窗口的方式对流数据进行一定范围内的聚合计算，例如统计近一小时内用户的访问量，这种情况下我们必须定义一个窗口，用来收集近一小时的数据。Flink 提供了三类默认窗口：计数窗口（Count Window）、时间窗口（Time Window）和会话窗口（Session Window），通过对不同窗口的选择，可以达到对复杂应用场景的支持。

• 基于 JVM 实现独立的内存管理

内存管理是所有流式计算框架需要重点考虑的部分，尤其是对数据量比较大的计算场景。针对内存管理，Flink 实现了自身内存管理机制，尽可能的减少了 JVM GC 对系统的影响。另外 Flink 通过序列化/反序列化的方式，将所有的数据对象转换成二进制进行存储，有效的对内存空间进行利用，降低了 GC 带来的性能下降以及任务异常的风险。

• 长久稳定运行

为了保证服务能够持续稳定运行，Flink 不仅能在服务出故障的时候重启服务，而且当故障发生时，保证能够持久化服务内部各个组件的当前状态，这样在故障恢复的时候，服务能够继续正常运行。

Flink 组件

1. Flink 中的 API

   Flink 为流式/批式处理应用程序的开发提供了不同级别的抽象。每一种 API 在简洁性和表达力上有着不同的侧重，并且针对不同的应用场景。
   

   • Flink API 最底层的抽象为有状态实时流处理 (Stateful Stream Processing)。其抽象实现是 Process Function。它允许用户在应用程序中自由地处理来自单流或多流的事件（数据），并提供具有全局一致性和容错保障的状态。此外，用户可以在此层抽象中注册事件时间（Event time）和处理时间（Processing time）回调方法，从而允许程序可以实现复杂计算。

   • Flink API 第二层抽象是 Core APIs。实际上许多应用程序不需要使用到最底层抽象的 API，而是可以使用 Core APIs 进行编程。其中 DataStream / DataSet API 应用于无界/有界数据流场景。Core APIs 提供的流式 API 为数据处理提供了通用的模块组件，例如各种形式的用户自定义转换（Transformations）、联接（Joins）、聚合（Aggregations）、窗口（Windows）和状态（State）操作等。

   • Flink API 第三层抽象是 Table API。Table API 是以表（Table）为中心的声明式编程（DSL）API。Table API 遵循（扩展）关系模型：即表拥有 schema（类似于关系型数据库中的 schema），并且 Table API 也提供了类似于关系模型中的操作，比如 select、project、join、group-by 和 aggregate 等。Table API 程序是以声明的方式定义应执行的逻辑操作。尽管 Table API 使用起来很简洁并且可以由各种类型的用户自定义函数扩展功能，但还是比 Core API 的表达能力差。此外，Table API 程序在执行之前还会使用优化器中的优化规则对用户编写的表达式进行优化。

   • Flink API 最顶层抽象是 SQL。这层抽象在语义和程序表达式上都类似于 Table API，但是其程序实现都是 SQL 查询表达式。SQL 抽象与 Table API 抽象之间的关联是非常紧密的，并且 SQL 查询语句可以在 Table API 中定义的表上执行。

2. 组件

   Flink 是由多个组件构成的软件栈，软件栈分层如下图所示。
   

   • 物理部署层

   目前 Flink 支持多种部署模式：本地 Local 开发模式、集群（Standalone/Yarn）、Kubernetes，用户可以根据需要来选择对应的部署模式，目前在企业中使用最多的是基于 Yarn 进行部署，也就是 Flink On Yarn。

   • Runtime 核心层

   该层主要负责对上层不同接口提供基础服务，也是 Flink 分布式计算框架的核心实现层，支持分布式 Stream 作业的执行、JobGraph 到 ExecutionGraph 的映射转换、任务调度等。

   • API & Libraries 层

   在 Flink Runtime 的基础上，Flink 提供了面向批/流处理的计算接口，并在此接口上抽象出了不同的应用类型组件库，例如基于流处理的 CEP（复杂事件处理库）、Table&SQL（结构化表处理库）、基于批处理的 Gelly（图计算库）、FlinkML（机器学习库）等。

Flink 运行架构

Flink 运行时由两种类型的进程组成：一个 JobManager 和一个或者多个 TaskManager。

Client 不是运行时和程序执行的一部分，而是用于准备数据流并将其发送给 JobManager。之后，客户端可以断开连接（分离模式），或保持连接来接收进程报告（附加模式）。客户端可以作为触发执行 Java/Scala 程序的一部分运行，也可以在命令行进程 ./bin/flink run … 中运行。

可以通过多种方式启动 JobManager 和 TaskManager：直接在机器上作为 Standalone 集群启动、在容器中启动、或者通过 YARN 等资源框架管理并启动。TaskManager 连接到 JobManagers，宣布自己可用，并被分配工作。

1. JobManager

   JobManager 具有许多与协调 Flink 应用程序的分布式执行有关的职责：它决定何时调度下一个 Task（或一组 Task）、对完成的 Task 或执行失败做出反应、协调 Checkpoint、并且协调从失败中恢复等等。这个进程由三个不同的组件组成：

   • ResourceManager

   ResourceManager 负责 Flink 集群中的资源提供、回收、分配，它管理 Task slots，这是 Flink 集群中资源调度的单位。Flink 为不同的环境和资源提供者（例如 YARN、Kubernetes 和 Standalone 部署）实现了对应的 ResourceManager。在 Standalone 设置中，ResourceManager 只能分配可用 TaskManager 的 slots，而不能自行启动新的 TaskManager。

   • Dispatcher

   Dispatcher 提供了一个 REST 接口，用来提交 Flink 应用程序执行，并为每个提交的作业启动一个新的 JobMaster。它还运行 Flink WebUI 用来提供作业执行信息。

   • JobMaster

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

   始终至少有一个 JobManager。高可用（HA）设置中可能有多个 JobManager，其中一个始终是 leader，其他的则是 Standby

2. TaskManagers

   TaskManager（也称为 worker）执行作业流的 Task，并且缓存和交换数据流。必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 Task slot。TaskManager 中 Task slot 的数量表示并发处理 Task 的数量。请注意一个 Task slot 中可以执行多个算子。

Flink 历史发展

Apache Flink 自 2014 年开源以来，迄今为止已覆盖海内外数千家企业的实时计算需求，涉及行业包括互联网娱乐、电商、在线教育、游戏、金融等。下面简单的介绍一下 Flink 版本发展历程，详细信息参考官方发布文档。

• 2014 年 8 月份，Apache 发布了第一个 Flink 版本，Flink 0.6.0，在有了较好的流式引擎支持后，流计算的价值也随之被挖掘和重视。
• 2014 年 12 月，Flink 发布了 0.7 版本，正式推出了 DataStream API，这也是目前 Flink 应用的最广泛的 API。
• 2015 年，Flink 发布了第一个稳定版本 0.10。这个版本包括了许多新功能，如流式处理、批处理、迭代处理和图处理等。此外，Flink 还发布了 DataSet API，以便用户可以更轻松地进行批处理。
• 2016 年，Flink 发布了版本 1.1。这个版本包括了许多新功能，如分布式快照、集成的机器学习库、更好的流式处理性能等。此外，Flink 还发布了 Table API，以便用户可以更轻松地进行 SQL 查询。
• 2019 年 8 月 22 日，Apache Flink 1.9.0 版本正式发布，这也是阿里内部版本 Blink 合并入 Flink 后的首次版本发布。此次版本更新带来的重大功能包括批处理作业的批式恢复，以及 Table API 和 SQL 的基于 Blink 的新查询引擎（预览版）。同时，这一版本还推出了 State Processor API，这是社区最迫切需求的功能之一，该 API 使用户能够用 Flink DataSet 作业灵活地读写保存点。此外，Flink 1.9 还包括一个重新设计的 WebUI 和新的 Python Table API（预览版）以及与 Apache Hive 生态系统的集成（预览版）。
• 2020 年 2 月，Flink 1.10 版本[重要版本]发布，Blink 整合完成，作为 Flink 社区迄今为止规模最大的一次版本升级，Flink 1.10 容纳了超过 200 位贡献者对超过 1200 个 issue 的开发实现，包含对 Flink 作业的整体性能及稳定性的显著优化、对原生 Kubernetes 的初步集成（beta 版本）以及对 Python 支持（PyFlink）的重大优化。
• 2020 年 12 月，Flink 1.12 版本[重要版本]发布，在 DataStream API 上添加了高效的批执行模式的支持。这是批处理和流处理实现真正统一的运行时的一个重要里程碑。实现了基于 Kubernetes 的高可用性（HA）方案，作为生产环境中，ZooKeeper 方案之外的另外一种选择。扩展了 Kafka SQL connector，使其可以在 Upsert 模式下工作，并且支持在 SQL DDL 中处理 connector 的 metadata。现在，时态表 Join 可以完全用 SQL 来表示，不再依赖于 Table API 了。
• 2022 年 5 月，Flink 1.15 版本发布，版本中流批一体更加完善，Flink 作为整个数据处理生态中的一环，进一步提升了与云服务的交互操作性，并且添加了更多的 Sink 连接器与数据格式，并且在运行时中去除了对 Scala 的依赖。
• 2023 年 3 月，Flink 1.17 版本发布，开始迈向 Streaming Warehouse。为了在流式数仓领域实现更高效的处理，Flink 1.17 对批处理和流处理的性能和语义都进行了实质性的改进。这些增强措施代表了朝着创建一个更高效、更简化的数据仓库，能够实时处理大量数据的目标迈进了一大步。
• 2023 年 10 月，Flink 发布了 1.18 版本，整体目标是迈向 Streaming Lakehouse。提供了 Flink SQL Gateway 的 JDBC Driver。自适应调度器变得更加强大和更广泛适用，并正在成为 Apache Flink 流处理任务的默认调度器。DDL 进一步扩展，Table API & SQL 支持算子级别状态保留时间（TTL）等。
• 2024 年 3 月，Flink 发布了 1.19 版本，一方面持续在 Flink SQL 性能的提升，包括源表自定义并行度、使用 SQL 提示配置不同的状态 TTL、Window TVF 聚合功能等。另一方面在 Runtime & Coordination 的提升，包括批作业支持源表动态并行度推导、新增管理员 JVM 选项配置选项，另外就是 Checkpoints 提升，通过命令行客户端触发 Checkpoints。与此同时为了给 Flink 2.0 版本做准备，社区正式废弃多个已接近生命周期终点的 API。

Flink 组件以及运行架构图来自官网