Flink是Apache基金会旗下的一个开源大数据处理框架。目前，Flink已经成为各大公司大数据实时处理的发力重点，特别是国内以阿里为代表的一众互联网大厂都在全力投入，为Flink社区贡献了大量源码。如今Flink已被很多人认为是大数据实时处理的方向和未来，许多公司也都在招聘和储备掌握Flink技术的人才。

那Flink到底是什么，又有什么样的优点，能够让大家对它如此青睐呢？
本章我们就来做一个详细的了解。首先讲述Flink的源起和设计理念，接着介绍Flink如今的应用领域；进而通过梳理数据处理架构的发展演变，解答为什么要用Flink的疑问。进而梳理Flink的特点，并同另一个流行的大数据处理框架Spark进行比较，从而更深刻地理解Flink的底层架构和优势所在。

一、Flink的源起和设计理念

1、特点

高吞吐、高容错、易用API、语义化窗口、结果正确、低延迟

2、是什么

是一个框架和分布式处理引擎，用于对无界和有界数据流进行状态计算

3、框架处理流程

Flink是一个“框架”，是一个数据处理的“引擎”；既然是“分布式”，当然是为了应付大规模数据的应用场景了；另外，Flink处理的是数据流。所以，Flink是一个流式大数据处理引擎。

而“内存执行速度”和“任意规模”，突出了Flink的两个特点：速度快、可扩展性强——这说的自然就是小松鼠的“快速”和“灵巧”了。

二、Flink的应用

对于数据处理而言，任何行业、任何公司的需求其实都是一样的：数据规模大、实时性要求高、确保结果准确、方便扩展、故障后可恢复——而这些要求，作为新一代大数据流式处理引擎的Flink统统可以满足！这也正是Flink在全世界范围得到广泛应用的原因。

1. 电商和市场营销

举例：实时数据报表、广告投放、实时推荐
在电商行业中，网站点击量是统计PV、UV的重要来源，也是如今“流量经济”的最主要数据指标。很多公司的营销策略，比如广告的投放，也是基于点击量来决定的。另外，在网站上提供给用户的实时推荐，往往也是基于当前用户的点击行为做出的。
网站获得的点击数据可能是连续且不均匀的，还可能在同一时间大量产生，这是典型的数据流。如果我们希望把它们全部收集起来，再去分析处理，就会面临很多问题：首先，我们需要很大的空间来存储数据；其次，收集数据的过程耗去了大量时间，统计分析结果的实时性就大大降低了；另外，分布式处理无法保证数据的顺序，如果我们只以数据进入系统的时间为准，可能导致最终结果计算错误。
我们需要的是直接处理数据流，而Flink就可以做到这一点。

2. 物联网（IOT）

举例：传感器实时数据采集和显示、实时报警，交通运输业
物联网是流数据被普遍应用的领域。各种传感器不停获得测量数据，并将它们以流的形式传输至数据中心。而数据中心会将数据处理分析之后，得到运行状态或者报警信息，实时地显示在监控屏幕上。所以在物联网中，低延迟的数据传输和处理，以及准确的数据分析通常很关键。
交通运输业也体现了流处理的重要性。比如说，如今高铁运行主要就是依靠传感器检测数据，测量数据包括列车的速度和位置，以及轨道周边的状况。这些数据会从轨道传给列车，再从列车传到沿途的其他传感器；与此同时，数据报告也被发送回控制中心。因为列车处于高速行驶状态，因此数据处理的实时性要求是极高的。如果流数据没有被及时正确处理，调整意见和警告就不能相应产生，后果可能会非常严重。

3. 物流配送和服务业

举例：订单状态实时更新、通知信息推送
在很多服务型应用中，都会涉及订单状态的更新和通知的推送。这些信息基于事件触发，不均匀地连续不断生成，处理之后需要及时传递给用户。这也是非常典型的数据流的处理。

4. 银行和金融业

举例：实时结算和通知推送，实时检测异常行为
银行和金融业是另一个典型的应用行业。用户的交易行为是连续大量发生的，银行面对的是海量的流式数据。由于要处理的交易数据量太大，以前的银行是按天结算的，汇款一般都要隔天才能到账。所以有一个说法叫作“银行家工作时间”，说的就是银行家不仅不需要996，甚至下午早早就下班了：因为银行需要早点关门进行结算，这样才能保证第二天营业之前算出准确的账。这显然不能满足我们快速交易的需求。在全球化经济中，能够提供24小时服务变得越来越重要。现在交易和报表都会快速准确地生成，我们跨行转账也可以做到瞬间到账，还可以接到实时的推送通知。这就需要我们能够实时处理数据流。
另外，信用卡欺诈的检测也需要及时的监控和报警。一些金融交易市场，对异常交易行为的及时检测可以更好地进行风险控制；还可以对异常登录进行检测，从而发现钓鱼式攻击，从而避免巨大的损失。

1、为什么选择

批处理和流处理
流数据更真实地反映了我们的生活方式
我们的目标
低延迟
高吞吐
结果的准确性和良好的容错性

三、流式数据处理的发展和演变

我们已经了解，Flink的主要应用场景，就是处理大规模的数据流。那为什么一定要用Flink呢？数据处理还有没有其他的方式？要解答这个疑惑，我们就需要先从流处理和批处理的概念讲起。

1、流处理和批处理

数据处理有不同的方式。
对于具体应用来说，有些场景数据是一个一个来的，是一组有序的数据序列，我们把它叫作“数据流”；而有些场景的数据，本身就是一批同时到来，是一个有限的数据集，这就是批量数据（有时也直接叫数据集）。

容易想到，处理数据流，当然应该“来一个就处理一个”，这种数据处理模式就叫作流处理；因为这种处理是即时的，所以也叫实时处理。与之对应，处理批量数据自然就应该一批读入、一起计算，这种方式就叫作批处理，也叫作离线处理。

2、传统事务处理

数据量可能没有办法太大、造价会比较高、响应速度比较快

3、有状态的流处理

1. 事件驱动型（Event-Driven）应用

事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。比较典型的就是以Kafka为代表的消息队列几乎都是事件驱动型应用。

这其实跟传统事务处理本质上是一样的，区别在于基于有状态流处理的事件驱动应用，不再需要查询远程数据库，而是在本地访问它们的数据，如图1-7所示，这样在吞吐量和延迟方面就可以有更好的性能。

另外远程持久性存储的检查点保证了应用可以从故障中恢复。检查点可以异步和增量地完成，因此对正常计算的影响非常小。

2.数据分析（Data Analysis）型应用

所谓的数据分析，就是从原始数据中提取信息和发掘规律。传统上，数据分析一般是先将数据复制到数据仓库（Data Warehouse），然后进行批量查询。如果数据有了更新，必须将最新数据添加到要分析的数据集中，然后重新运行查询或应用程序。

如今，Apache Hadoop生态系统的组件，已经是许多企业大数据架构中不可或缺的组成部分。现在的做法一般是将大量数据（如日志文件）写入Hadoop的分布式文件系统（HDFS）、S3或HBase等批量存储数据库，以较低的成本进行大容量存储。然后可以通过SQL-on-Hadoop类的引擎查询和处理数据，比如大家熟悉的Hive。这种处理方式，是典型的批处理，特点是可以处理海量数据，但实时性较差，所以也叫离线分析。

如果我们有了一个复杂的流处理引擎，数据分析其实也可以实时执行。流式查询或应用程序不是读取有限的数据集，而是接收实时事件流，不断生成和更新结果。结果要么写入外部数据库，要么作为内部状态进行维护。

Apache Flink同事支持流式与批处理的数据分析应用，如图1-8所示。

与批处理分析相比，流处理分析最大的优势就是低延迟，真正实现了实时。另外，流处理不需要去单独考虑新数据的导入和处理，实时更新本来就是流处理的基本模式。当前企业对流式数据处理的一个热点应用就是实时数仓，很多公司正是基于Flink来实现的。

3. 数据管道（Data Pipeline）型应用

ETL也就是数据的提取、转换、加载，是在存储系统之间转换和移动数据的常用方法。在数据分析的应用中，通常会定期触发ETL任务，将数据从事务数据库系统复制到分析数据库或数据仓库。

所谓数据管道的作用与ETL类似。它们可以转换和扩展数据，也可以在存储系统之间移动数据。不过如果我们用流处理架构来搭建数据管道，这些工作就可以连续运行，而不需要再去周期性触发了。比如，数据管道可以用来监控文件系统目录中的新文件，将数据写入事件日志。连续数据管道的明显优势是减少了将数据移动到目的地的延迟，而且更加通用，可以用于更多的场景。
如图1-9所示，展示了ETL与数据管道之间的区别。

有状态的流处理架构上其实并不复杂，很多用户基于这种思想开发出了自己的流处理系统，这就是第一代流处理器。Apache Storm就是其中的代表。Storm可以说是开源流处理的先锋，最早是由 Nathan Marz 和创业公司 BackType的一个团队开发的，后来才成为Apache 软件基金会下属的项目。Storm 提供了低延迟的流处理，但是它也为实时性付出了代价：很难实现高吞吐，而且无法保证结果的正确性。用更专业的话说，它并不能保证“精确一次”（exactly-once）；即便是它能够保证的一致性级别，开销也相当大。关于状态一致性和exactly-once，我们会在后续的章节中展开讨论。

4、Lambda架构

用两套系统、同时保证低延迟和结果准确性

太麻烦、维护一个需求 要维护两个系统

5、新一代流处理器

Flink 一套系统实现了lamda架构的里面的两套功能

核心特点
高吞吐、低延迟
结果的准确性
精确一次的状态一致性保证
可以与众多常用存储系统链接
高可用，支持动态扩展

之前的分布式流处理架构，都有明显的缺陷，人们也一直没有放弃对流处理器的改进和完善。终于，在原有流处理器的基础上，新一代分布式开源流处理器诞生了。为了与之前的系统区分，我们一般称之为第三代流处理器，代表当然就是Flink。

第三代流处理器通过巧妙的设计，完美解决了乱序数据对结果正确性的影响。这一代系统还做到了精确一次（exactly-once）的一致性保障，是第一个具有一致性和准确结果的开源流处理器。另外，先前的流处理器仅能在高吞吐和低延迟中二选一，而新一代系统能够同时提供这两个特性。所以可以说，这一代流处理器仅凭一套系统就完成了Lambda架构两套系统的工作，它的出现使得Lambda架构黯然失色。
除了低延迟、容错和结果准确性之外，新一代流处理器还在不断添加新的功能，例如高可用的设置，以及与资源管理器（如YARN或Kubernetes）的紧密集成等等。

四、Flink的特性总结

Flink是第三代分布式流处理器，它的功能丰富而强大。

1、Flink的核心特性

Flink区别与传统数据处理框架的特性如下。
高吞吐和低延迟。每秒处理数百万个事件，毫秒级延迟。

结果的准确性。Flink提供了事件时间（event-time）和处理时间（processing-time）语义。对于乱序事件流，事件时间语义仍然能提供一致且准确的结果。

精确一次（exactly-once）的状态一致性保证。

可以连接到最常用的存储系统，如Apache Kafka、Apache Cassandra、Elasticsearch、JDBC、Kinesis和（分布式）文件系统，如HDFS和S3。

高可用。本身高可用的设置，加上与K8s，YARN和Mesos的紧密集成，再加上从故障中快速恢复和动态扩展任务的能力，Flink能做到以极少的停机时间7×24全天候运行。

能够更新应用程序代码并将作业（jobs）迁移到不同的Flink集群，而不会丢失应用程序的状态。

2、分层API

Flink还是一个非常易于开发的框架，因为它拥有易于使用的分层API

最底层级的抽象仅仅提供了有状态流，它将处理函数（Process Function）嵌入到了DataStream API中。底层处理函数（Process Function）与 DataStream API 相集成，可以对某些操作进行抽象，它允许用户可以使用自定义状态处理来自一个或多个数据流的事件，且状态具有一致性和容错保证。除此之外，用户可以注册事件时间并处理时间回调，从而使程序可以处理复杂的计算。

实际上，大多数应用并不需要上述的底层抽象，而是直接针对核心API（Core APIs） 进行编程，比如DataStream API（用于处理有界或无界流数据）以及DataSet API（用于处理有界数据集）。这些API为数据处理提供了通用的构建模块，比如由用户定义的多种形式的转换（transformations）、连接（joins）、聚合（aggregations）、窗口（windows）操作等。DataSet API 为有界数据集提供了额外的支持，例如循环与迭代。这些API处理的数据类型以类（classes）的形式由各自的编程语言所表示。

Table API 是以表为中心的声明式编程，其中表在表达流数据时会动态变化。Table API遵循关系模型：表有二维数据结构（schema）（类似于关系数据库中的表），同时API提供可比较的操作，例如select、join、group-by、aggregate等。

尽管Table API可以通过多种类型的用户自定义函数（UDF）进行扩展，仍不如核心API更具表达能力，但是使用起来代码量更少，更加简洁。除此之外，Table API程序在执行之前会使用内置优化器进行优化。

我们可以在表与 DataStream/DataSet 之间无缝切换，以允许程序将 Table API 与 DataStream 以及 DataSet 混合使用。
Flink提供的最高层级的抽象是SQL。这一层抽象在语法与表达能力上与 Table API 类似，但是是以SQL查询表达式的形式表现程序。SQL抽象与Table API交互密切，同时SQL查询可以直接在Table API定义的表上执行。

五、Flink vs Spark

1、数据处理架构

我们已经知道，数据处理的基本方式，可以分为批处理和流处理两种

批处理针对的是有界数据集，非常适合需要访问海量的全部数据才能完成的计算工作，一般用于离线统计。

流处理主要针对的是数据流，特点是无界、实时, 对系统传输的每个数据依次执行操作，一般用于实时统计。

从根本上说，Spark和Flink采用了完全不同的数据处理方式。可以说，两者的世界观是截然相反的。

Spark以批处理为根本，并尝试在批处理之上支持流计算；在Spark的世界观中，万物皆批次，离线数据是一个大批次，而实时数据则是由一个一个无限的小批次组成的。所以对于流处理框架Spark Streaming而言，其实并不是真正意义上的“流”处理，而是“微批次”（micro-batching）处理

而Flink则认为，流处理才是最基本的操作，批处理也可以统一为流处理。在Flink的世界观中，万物皆流，实时数据是标准的、没有界限的流，而离线数据则是有界限的流。如图1-13所示，就是所谓的无界流和有界流。

1. 无界数据流（Unbounded Data Stream）

所谓无界数据流，就是有头没尾，数据的生成和传递会开始但永远不会结束，如图1-13所示。我们无法等待所有数据都到达，因为输入是无界的，永无止境，数据没有“都到达”的时候。所以对于无界数据流，必须连续处理，也就是说必须在获取数据后立即处理。在处理无界流时，为了保证结果的正确性，我们必须能够做到按照顺序处理数据。

2. 有界数据流（Bounded Data Stream）

对应的，有界数据流有明确定义的开始和结束，如图1-13所示，所以我们可以通过获取所有数据来处理有界流。处理有界流就不需要严格保证数据的顺序了，因为总可以对有界数据集进行排序。有界流的处理也就是批处理。

正因为这种架构上的不同，Spark和Flink在不同的应用领域上表现会有差别。一般来说， Spark 基于微批处理的方式做同步总有一个“攒批”的过程，所以会有额外开销，因此无法在流处理的低延迟上做到极致。在低延迟流处理场景，Flink 已经有明显的优势。而在海量数据的批处理领域，Spark能够处理的吞吐量更大，加上其完善的生态和成熟易用的API，目前同样优势比较明显。

2、数据模型和运行架构

除了三观不合，Spark和Flink在底层实现最主要的差别就在于数据模型不同。

Spark底层数据模型是弹性分布式数据集（RDD），Spark Streaming 进行微批处理的底层接口DStream，实际上处理的也是一组组小批数据RDD的集合。可以看出，Spark在设计上本身就是以批量的数据集作为基准的，更加适合批处理的场景。

而Flink的基本数据模型是数据流（DataFlow），以及事件（Event）序列。Flink基本上是完全按照Google的DataFlow模型实现的，所以从底层数据模型上看，Flink是以处理流式数据作为设计目标的，更加适合流处理的场景。

数据模型不同，对应在运行处理的流程上，自然也会有不同的架构。Spark做批计算，需要将任务对应的DAG划分阶段（Stage），一个完成后经过shuffle再进行下一阶段的计算。而Flink是标准的流式执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。

3、Spark还是Flink？

通过前文的分析，我们已经可以看出，Spark和Flink可以说目前是各擅胜场，批处理领域Spark称王，而在流处理方面Flink当仁不让。具体到项目应用中，不仅要看是流处理还是批处理，还需要在延迟、吞吐量、可靠性，以及开发容易度等多个方面进行权衡。

如果在工作中需要从Spark和Flink这两个主流框架中选择一个来进行实时流处理，我们更加推荐使用Flink，主要的原因有：

Flink的延迟是毫秒级别，而Spark Streaming的延迟是秒级延迟。
Flink提供了严格的精确一次性语义保证。
Flink的窗口API更加灵活、语义更丰富。
Flink提供事件时间语义，可以正确处理延迟数据。
Flink提供了更加灵活的对状态编程的API。

基于以上特点，使用Flink可以解放程序员, 加快编程效率, 把本来需要程序员花大力气手动完成的工作交给框架完成。

当然，在海量数据的批处理方面，Spark还是具有明显的优势。而且Spark的生态更加成熟，也会使其在应用中更为方便。相信随着Flink的快速发展和完善，这方面的差距会越来越小。

另外，Spark 2.0之后新增的Structured Streaming流处理引擎借鉴DataFlow进行了大量优化，同样做到了低延迟、时间正确性以及精确一次性语义保证；Spark 2.3以后引入的连续处理（Continuous Processing）模式，更是可以在至少一次语义保证下做到1毫秒的延迟。而Flink自1.9版本合并Blink以来，在SQL的表达和批处理的能力上同样有了长足的进步。

六、本章总结

主要介绍了Flink的源起和应用，引出了流处理相关的一些重要概念，并通过介绍数据处理架构发展演变的过程，为读者展示了Flink作为新一代分布式流处理器的架构思想。最后我们还将Flink与时下同样火热的处理引擎Spark进行了对比，详细阐述了Flink在流处理方面的优势。
通过本章的学习，大家不仅可以初步了解Flink，而且能够建立起数据处理的宏观思维，这对以后学习框架中的一些重要特性非常有帮助。