1.1Flink 的源起和设计理念
Flink 起源于一个叫作 Stratosphere 的项目，它是由 3 所地处柏林的大学和欧洲其他一些大学在 2010~2014 年共同进行的研究项目，由柏林理工大学的教授沃克尔·马尔科（Volker Markl）领衔开发。 2014 年 4 月， Stratosphere 的代码被复制并捐赠给了 Apache 软件基金会， Flink 就是在此基础上被重新设计出来的。
Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。 Flink 被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。
1.2Flink的应用场景
电商和市场营销
举例：实时数据报表、广告投放、实时推荐
物联网（IOT）
举例：传感器实时数据采集和显示、实时报警，交通运输业
物流配送和服务业
举例：订单状态实时更新、通知信息推送
银行和金融业
举例：实时结算和通知推送，实时检测异常行为
1.3流式数据处理的发展和演变
1.3.1流处理和批处理
数据处理有不同的方式。
对于具体应用来说，有些场景数据是一个一个来的，是一组有序的数据序列，我们把它叫作“数据流”；而有些场景的数据，本身就是一批同时到来，是一个有限的数据集，这就是批量数据（有时也直接叫数据集）。
容易想到，处理数据流，当然应该“来一个就处理一个”，这种数据处理模式就叫作流处理；因为这种处理是即时的，所以也叫实时处理。与之对应，处理批量数据自然就应该一批读入、一起计算，这种方式就叫作批处理，也叫作离线处理。
1.3.2传统事务处理
我们发现，这里的应用程序在处理数据的模式上有共同之处：接收的数据是持续生成的事件，比如用户的点击行为，客户下的订单，或者操作人员发出的请求。处理事件时，应用程序需要先读取远程数据库的状态，然后按照处理逻辑得到结果，将响应返回给用户，并更新数据库状态。一般来说，一个数据库系统可以服务于多个应用程序，它们有时会访问相同的数据库或表。
这就是传统的“事务处理”架构。系统所处理的连续不断的事件，其实就是一个数据流。而对于每一个事件，系统都在收到之后进行相应的处理，这也是符合流处理的原则的。所以可以说，传统的事务处理，就是最基本的流处理架构 。
1.3.3有状态的流处理
不难想到，如果我们对于事件流的处理非常简单，例如收到一条请求就返回一个“收到”，那就可以省去数据库的查询和更新了。但是这样的处理是没什么实际意义的。在现实的应用中，往往需要还其他一些额外数据。我们可以把需要的额外数据保存成一个“状态”，然后针对这条数据进行处理，并且更新状态。在传统架构中，这个状态就是保存在数据库里的。这就是所谓的“有状态的流处理”。
有状态的流处理是一种通用而且灵活的设计架构，可用于许多不同的场景。具体来说，有以下几种典型应用。
- 事件驱动型（Event-Driven）应用
事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。比较典型的就是以 Kafka 为代表的消息队列几乎都是事件驱动型应用。
- 数据分析（Data Analysis）型应用
- 数据管道（Data Pipeline）型应用
ETL 也就是数据的提取、转换、加载，是在存储系统之间转换和移动数据的常用方法。在数据分析的应用中，通常会定期触发 ETL 任务，将数据从事务数据库系统复制到分析数据库或数据仓库
1.3.4Lambda架构
Lambda 架构主体是传统批处理架构的增强。它的“批处理层”（Batch Layer）就是由传统的批处理器和存储组成，而“实时层”（Speed Layer）则由低延迟的流处理器实现。数据到达之后，两层处理双管齐下，一方面由流处理器进行实时处理，另一方面写入批处理存储空间，等待批处理器批量计算。流处理器快速计算出一个近似结果，并将它们写入“流处理表”中。而批处理器会定期处理存储中的数据，将准确的结果写入批处理表，并从快速表中删除不准确的结果。最终，应用程序会合并快速表和批处理表中的结果，并展示出来。
1.3.5新一代流处理器
第三代流处理器通过巧妙的设计，完美解决了乱序数据对结果正确性的影响。这一代系统还做到了精确一次（exactly-once）的一致性保障，是第一个具有一致性和准确结果的开源流处理器。另外，先前的流处理器仅能在高吞吐和低延迟中二选一，而新一代系统能够同时提供这两个特性。所以可以说，这一代流处理器仅凭一套系统就完成了 Lambda 架构两套系统的工作，它的出现使得 Lambda 架构黯然失色。
1.4特性总结
1.4.1核心特性
- 高吞吐和低延迟
- 结果的准确性
- 精确一次的状态一致性保证
- 可以连接到常用的存储系统
- 高可用
- 能够更新应用程序代码并将作业迁移到不同的flink集群
1.4.2分层API
最底层级的抽象仅仅提供了有状态流，它将处理函数（ Process Function）嵌入到了DataStream API 中。底层处理函数（Process Function）与 DataStream API 相集成，可以对某些操作进行抽象，它允许用户可以使用自定义状态处理来自一个或多个数据流的事件，且状态具有一致性和容错保证。除此之外，用户可以注册事件时间并处理时间回调，从而使程序可以处理复杂的计算。
DataStreamAPI为数据处理提供了通用的构建模块，比如由用户定义的多种形式的转换（transformations）、连接（joins）、聚合（aggregations）、窗口（windows）操作等。 DataSet API为有界数据集提供了额外的支持，例如循环与迭代。这些 API 处理的数据类型以类（classes）的形式由各自的编程语言所表示
Table API 是以表为中心的声明式编程，其中表在表达流数据时会动态变化。 Table API 遵循关系模型：表有二维数据结构（schema）（类似于关系数据库中的表），同时 API 提供可比较的操作，例如 select、 join、 group-by、 aggregate 等 。
Flink 提供的最高层级的抽象是 SQL。这一层抽象在语法与表达能力上与 Table API 类似，但是是以 SQL 查询表达式的形式表现程序。 SQL 抽象与 Table API 交互密切，同时 SQL 查询可以直接在 Table API 定义的表上执行 。
1.5 Flink VS Spark
1.5.1数据处理架构
Spark 以批处理为根本，并尝试在批处理之上支持流计算； 在 Spark 的世界观中，万物皆批次，离线数据是一个大批次，而实时数据则是由一个一个无限的小批次组成的。所以对于流处理框架 Spark Streaming 而言，其实并不是真正意义上的“流”处理，而是“微批次”（micro-batching）处理。
而 Flink 则认为，流处理才是最基本的操作，批处理也可以统一为流处理。在 Flink 的世界观中，万物皆流，实时数据是标准的、没有界限的流，而离线数据则是有界限的流。
无界数据流
所谓无界数据流，就是有头没尾，数据的生成和传递会开始但永远不会结束。我们无法等待所有数据都到达，因为输入是无界的，永无止境，数据没有“都到达”的时候。所以对于无界数据流，必须连续处理，也就是说必须在获取数据后立即处理。在处理无界流时，为了保证结果的正确性，我们必须能够做到按照顺序处理数据。
有界数据流
对应的，有界数据流有明确定义的开始和结束，所以我们可以通过获取所有数据来处理有界流。处理有界流就不需要严格保证数据的顺序了，因为总可以对有界数据集进行排序。有界流的处理也就是批处理。
正因为这种架构上的不同， Spark 和 Flink 在不同的应用领域上表现会有差别。一般来说，Spark 基于微批处理的方式做同步总有一个“攒批”的过程，所以会有额外开销，因此无法在流处理的低延迟上做到极致。在低延迟流处理场景， Flink 已经有明显的优势。而在海量数据的批处理领域， Spark 能够处理的吞吐量更大，加上其完善的生态和成熟易用的 API，目前同样优势比较明显。
1.5.2数据模型和运行架构
Spark 底层数据模型是弹性分布式数据集（RDD）， Spark Streaming 进行微批处理的底层接口 DStream，实际上处理的也是一组组小批数据 RDD 的集合。可以看出， Spark 在设计上本身就是以批量的数据集作为基准的，更加适合批处理的场景。
而 Flink 的基本数据模型是数据流（DataFlow），以及事件（Event）序列。 Flink 基本上是完全按照 Google 的 DataFlow 模型实现的，所以从底层数据模型上看， Flink 是以处理流式数据作为设计目标的，更加适合流处理的场景。
数据模型不同，对应在运行处理的流程上，自然也会有不同的架构。 Spark 做批计算，需要将任务对应的 DAG 划分阶段（Stage），一个完成后经过 shuffle 再进行下一阶段的计算。而Flink 是标准的流式执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。
1.5.3Spark 还是 Flink
Spark 和 Flink 可以说目前是各擅胜场，批处理领域 Spark 称王，而在流处理方面 Flink 当仁不让。
Flink在流处理方面的优势：
- Flink 的延迟是毫秒级别，而 Spark Streaming 的延迟是秒级延迟。
- Flink 提供了严格的精确一次性语义保证。
- Flink 的窗口 API 更加灵活、语义更丰富。
- Flink 提供事件时间语义，可以正确处理延迟数据。
- Flink 提供了更加灵活的对状态编程的 API。
