Flink原理与实战（java版）#第2章 Flink的入门（第二节Flink简介）

电子书 Flink原理与实战（java版）专栏文章入口：电子书 Flink原理与实战（java版）- 目录结构

文章目录

- [2.2 Flink简介](#2.2 Flink简介)
- - [2.2.1 Flink发展历程](#2.2.1 Flink发展历程)
  - [2.2.2 Flink的核心特性](#2.2.2 Flink的核心特性)
  - [2.2.3 分层API](#2.2.3 分层API)

2.2 Flink简介

2.2.1 Flink发展历程

1．发展历程简介

Flink 诞生于欧洲的一个大数据研究项目 StratoSphere。该项目是柏林工业大学的一个研究性项目。早期， Flink 是做离线计算的，在 2014 年， StratoSphere的核心成员孵化出 Flink，同年将 Flink 捐赠 Apache，并在后来成为 Apache 的顶级大数据项目，同时 Flink 计算的主流方向被定位为 Streaming，即用流式计算来做所有大数据的计算。

2014年12月份，Flink发布了0.7版本，正式推出了DataStream API，这也是目前Flink应用的最广泛的API。

2015年6月发布的Flink 0.9版本引入了内置State支持，并支持多种State 类型，如ValueState、MapState、ListState 等。

2016年3月发布的Flink 1.0 版本加入了基于Event Time的计算支持，并引入了 Watermark 机制，可以高效的容忍乱序数据和迟到数据。Flink 1.0同时还内置支持了各种各样的 window，开箱即用的滚动、滑动、会话窗口等，还可以灵活地自定义窗口。再加上 Flink 0.9 中加入的 State API 和高效的 Checkpoint 支持，这一切构成了 Flink 1.0 版本的基石。

2015 年阿里巴巴内部开始大量使用 Flink，同时也对 Flink 做了大刀阔斧的改进。2019年1月8日，阿里巴巴以 9000 万欧元收购了创业公司 Data Artisans。

2．阿里巴巴与Flink

阿里巴巴在使用Flink时根据自己的业务应用场景需要进行了大刀阔斧的改进，具体体现在以下方面，即重构分布式架构、增量 Checkpoint、基于 credit 的流控机制和Streaming SQL。

在2018年的"双11"期间，阿里巴巴集团的Flink服务器集群规模已超过数万台。单个任务所产生的状态数据量级达到了数十TB，而所有任务累积的数据总量更是达到了PB级别。每天需要处理的事件数据超过十万亿条。在"双11"当天零点的高峰时刻，每秒的数据处理量飙升至170亿条。

3．Flink的现在

1）Flink 1.9的架构变化

目前 Flink 最新的版本是1.9，Flink 在这个版本上做了较大的架构调整。截至本书编写时(2024年3月)对外发布的版本是1.18.1，1.19还未正式对外发布。

在 Flink 1.9 版本中，Table API 和 DataStream API 被设计为同等级别的API。未来，这两类接口都将支持流处理和批处理计算。基于这些，Flink 将在统一的有向无环图（DAG）层和流操作符上实现共享，而在运行时层面则维持了分布式流式数据流的处理机制。

2）统一 Operator 抽象

统一的算子抽象允许流式算子执行类似 HashJoin 的操作。阿里巴巴在协议层面进行了扩展，使得算子能够向框架传达它们所需的输入顺序。通过这种统一算子的抽象，算子可以实现重用。

3）Table API & SQL 1.9新特性

全新的 SQL 类型系统：Table API & SQL 1.9 引入了全新的 SQL 的类型系统。
DDL初步支持：这个版本中 Flink 还引入了 DDL 的初步支持，用户可以使用 Create Table 或 Drop Table 等简单的语法定义表或删除表。
Table API增强：Table API 原来仅为关系表达式的 API，Table API & SQL 1.9中现在加入了 Map，FlatMap 等更加灵活的 API。
统一的Catalog API：Table API & SQL 1.9 引入了统一的 Catalog API 之后，可以方便的和其它的 Catalog 对接。比如常见的 Hive，可以通过统一的 Catalog API，实现与 Hive.metastore 交互的插件，让 Flink 可以直接读取和处理 Hive 中的表。
Blink planner：Table API 增加了对 Blink Planner 的支持，这是由于在底层的运行时（Runtime）进行了较大的更改后，需要 SQL 计划器（Planner）与新的运行时进行对接。为了确保原有的 Table API 用户不受影响，社区保留了原有的 Flink Planner。同时，引入了新的 Blink Planner，以适应新的运行时设计。

4）批处理优化

Flink 在运行时（Runtime）层针对批处理实现了许多优化措施。Flink 允许在数据流图中灵活地配置各节点间的传输类型。例如，节点A与节点B之间可以直接网络连接，而节点B与节点C之间可以加入缓存层。当数据输出到缓存时，可以减少故障恢复（FailOver）的开销。如果没有缓存支持，节点间仅通过网络连接，D节点的错误会影响到整个数据流图。而在有缓存的情况下，只需重启一小部分子图，这大大提升了Flink在面对错误时的恢复效率。

Flink 1.9 版本增加了 Shuffle 插件，用户自己可以实现中间的Shuffle 层，通过专门的 Service 接收中间的数据。当然也可以复用基于 Yarn 的 Shuffle Service。

5）生态

Flink 1.9版本在生态方面进行了大量投入，例如增加了对Hive的兼容性。此外，为了提供更好的开发体验，Flink与Zeppelin进行了整合，用户可以在Notebook中使用Flink SQL，也可以使用Python API编写Flink作业。

4．Flink的未来

尽管当前主流应用场景主要依赖批处理（离线计算）和流式处理（实时计算）作为技术手段，但这些方法存在局限性。微服务（Micro Services）场景的需求远超于流计算和批处理。未来，Flink社区将更多地探索和尝试这一领域，以实现对事件驱动应用（Event-driven Application）服务场景的支持。

2.2.2 Flink的核心特性

1．流批一体化

该特性可能是Flink最重要的特性之一，Flink 采用了统一的流处理架构，可以用相同的编程模型和运行时系统支持有界数据的批处理和无界数据的实时流处理。

2．高吞吐、低延迟、高性能和高可用性

Apache Flink 在处理实时数据时表现出色，具有低延迟和高吞吐量的特性。通过将计算任务分解为多个并行的子任务并进行优化，Flink 实现了快速处理和高效利用资源。Flink是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。

3．多种时间语义

Flink 提供了事件时间（Event Time）和处理时间（Process Time）两种语义。通过基于事件驱动的机制使得事件即使乱序到达，流式系统也能够计算出精确的结果，保持了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响。使用事件时间可以对数据按事件发生的时间进行排序等操作，从而得到精确的结果。虽然使用处理时间不一定能得到精确结果，但可以满足低延迟的需求。

4．复杂的状态管理

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

5．高度灵活的窗口操作

在流处理应用中，数据是连续不断的，需要通过窗口的方式对流数据进行一定范围的聚合计算。Apache Flink 提供了3个内置windowing TVFs：TUMBLE、HOP 和 CUMULATE，窗口可以用灵活的触发条件定制化来达到对复杂的流传输模式的支持，用户可以定义不同的窗口触发机制来满足不同的需求。

6．良好的容错性和故障恢复能力

Apache Flink 具备良好的容错性和故障恢复能力。它可以自动监控任务执行过程中的错误，并在发生故障时进行恢复。这种容错机制保证了长时间运行的大规模数据处理场景下的可靠性，使得 Apache Flink 能够提供稳定可靠的服务。Flink 存储状态采用了轻量级分布式快照的Checkpoints，将执行过程中的状态信息进行持久化存储，一旦任务出现异常停止，Flink就能够从Checkpoints中进行任务的自动恢复，以确保数据在处理过程中的一致性（Exactly-Once）。

7．多种一致性语义

Flink 提供了"最多一次（at most once）"、"至少一次（at least once）"语义和"精确一次（exactly once）"语义的状态一致性保证。它能够确保在发生故障或重新启动时，数据流的一致性得到保障。在外部系统的配合下，Flink 也可以实现端到端的"精确一次"语义。

8．丰富的API和库

Apache Flink 提供了丰富的 API 和库（比如机器学习、图形处理、关系数据处理等），以支持各种数据处理需求。它支持流处理和批处理，并提供了多个层级的 API 以及易于使用的操作符和函数，而且不同层级的 API 可以混用。此外，Flink 还提供与其他开源生态系统（如Hadoop、Kafka 等）的无缝集成，进一步方便了数据采集、存储和处理的过程。

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

针对内存管理，Flink实现了自身管理内存的机制，尽可能减少JVM GC 对系统的影响。另外，Flink通过序列化/反序列化方法将所有的数据对象转换成二进制在内存中存储，降低数据存储的大小的同时，能够更加有效地对内存空间进行利用，降低GC带来的性能下降或任务异常的风险，因此Flink较其他分布式处理的框架会显得更加稳定，不会因为JVM GC等问题而影响整个应用的运行。

实际上，Flink 的特性远不止这些，还包括丰富的连接器、多平台部署、多语言支持和SQL Gateway等。这些特性使得 Apache Flink 成为处理实时数据的首选框架，并在各个行业的数据处理需求中广泛应用。

2.2.3 分层API

Flink 为流式/批式处理应用程序的开发提供了不同级别的抽象。如图2-7所示。

图2-7

1．Low-level building block层

Flink API的最底层抽象是状态驱动的实时流处理。其实现是通过Process Function，该函数被集成到Flink的DataStream API中供用户使用。它允许用户在应用程序中自由地处理来自单个或多个数据流的事件，并提供具有全局一致性和容错保障的状态。此外，用户可以在此层抽象中注册事件时间（event time）和处理时间（processing time）回调方法，从而允许程序实现更复杂的计算逻辑。

2．Core APIs层

Flink API的第二层抽象是核心API（Core APIs）。实际上，许多应用程序并不需要使用最底层的抽象API，而是可以采用核心API进行编程。核心API包括DataStream API（用于处理有界/无界数据流场景）和DataSet API（用于处理有界数据集场景）。核心API提供的流式接口（Fluent API）为数据处理提供了通用的模块组件，例如各种用户自定义转换（transformations）、连接（joins）、聚合（aggregations）、窗口（windows）和状态（state）操作等。此层API中处理的数据类型在每种编程语言中都有对应的类。

Process Function这类底层抽象与DataStream API的相互集成使用户可以选择使用更底层的抽象API来实现自己的需求。DataSet API还额外提供了一些原语，如循环/迭代（loop/iteration）操作。由于DataSet API在未来版本中逐渐被淘汰（由DataStream API全面取代），本书不再介绍其相关内容，除非在介绍版本迁移内容时进行相关介绍。

3．Declarative DSL层

Flink API的第三层抽象是Table API。Table API是一种以表为中心的声明式编程（DSL）API，例如在流处理场景中，它可以表示一张正在动态变化的表。Table API遵循并扩展了关系模型：表具有模式（schema），这与关系型数据库中的模式类似，并且Table API也提供了类似于关系模型中的操作，如select、project、join、group-by和aggregate等。Table API程序以声明方式定义应执行的逻辑操作，而不是具体指定程序应执行的代码。尽管Table API使用简便且可以通过各种类型的用户自定义函数进行功能扩展，但其表达能力仍不如核心API。此外，在执行Table API程序之前，优化器还会使用优化规则对用户编写的表达式进行优化。表与DataStream/DataSet之间可以进行无缝切换，Flink允许用户在编写应用程序时将Table API与DataStream/DataSet API混合使用。

4．High-level language层

Flink API的最顶层抽象是SQL。这一层的抽象在语义和程序表达上与Table API相似，但其程序实现采用的是SQL查询语句。SQL抽象层与Table API抽象层之间的联系非常紧密，可以在Table API定义的表上直接执行SQL查询语句。