架构
Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。
在这里，我们解释了Flink架构的重要方面。
处理无界和有界数据
任何类型的数据都是作为事件流产生的。信用卡交易，传感器测量，机器日志或网站或移动应用程序上的用户交互，所有这些数据都作为流生成。 数据可以作为无界或有界流处理。
- 无界流有一个开始但没有定义的结束。它们不会在生成时终止并提供数据。必须持续处理无界流，即必须在摄取事件后立即处理事件。无法等待所有输入数据到达，因为输入是无界的，并且在任何时间点都不会完成。处理无界数据通常要求以特定顺序（例如事件发生的顺序）摄取事件，以便能够推断结果完整性。
- 有界流具有定义的开始和结束。可以在执行任何计算之前通过摄取所有数据来处理有界流。处理有界流不需要有序摄取，因为可以始终对有界数据集进行排序。有界流的处理也称为批处理。
Apache Flink擅长处理无界和有界数据集。精确控制时间和状态使Flink的运行时能够在无界流上运行任何类型的应用程序。有界流由算法和数据结构内部处理，这些算法和数据结构专门针对固定大小的数据集而设计，从而产生出色的性能。
部署应用程序在任何地方
Apache Flink是一个分布式系统，需要计算资源来执行应用程序。Flink集成了所有常见的集群资源管理器，如Hadoop YARN、Apache Mesos和Kubernetes，但也可以设置为作为独立集群运行。
Flink被设计成能够很好地工作于前面列出的每个资源管理器。这是通过特定于资源管理器的部署模式实现的，这种部署模式允许Flink以其惯用的方式与每个资源管理器交互。
在部署Flink应用程序时，Flink根据应用程序的配置并行性自动识别所需的资源，并从资源管理器请求它们。如果发生故障，Flink将通过请求新的资源来替换失败的容器。提交或控制应用程序的所有通信都是通过REST调用进行的。这简化了Flink在许多环境中的集成。
以任何规模运行应用程序
Flink设计用于在任何规模上运行有状态流应用程序。应用程序被并行化成数千个任务，这些任务分布在一个集群中并发执行。因此，应用程序实际上可以利用无限数量的cpu、主内存、磁盘和网络IO。此外，Flink很容易保持非常大的应用状态。它的异步和增量检查点算法确保了对处理延迟的最小影响，同时保证了精确的一次状态一致性。
利用内存中的性能
有状态Flink应用程序针对本地状态访问进行了优化。任务状态总是在内存中维护，如果状态大小超过可用内存，则在具有访问效率的磁盘数据结构中维护。因此，任务通过访问本地(通常是在内存中)状态来执行所有计算，从而产生非常低的处理延迟。Flink通过定期和异步检查本地状态到持久存储，保证了在发生故障时的精确一次状态一致性。
应用
Apache Flink是一个用于对无界和有界数据流进行有状态计算的框架。Flink在不同的抽象级别提供多个API，并为常见用例提供专用库。
在这里，我们介绍Flink易于使用和富有表现力的API和库。
流媒体应用程序构块
可以由流处理框架构建和执行的应用程序类型由框架控制流，状态和时间的程度来定义。在下文中，我们描述了流处理应用程序的这些构建块，并解释了Flink处理它们的方法。
流
显然，流是流处理的一个基本方面。但是，流可能具有不同的特性，这些特性会影响流可以且应该如何处理。Flink是一个通用的处理框架，可以处理任何类型的流。
- 有界的和无界的流:流可以是无界的或有界的，即，固定大小的数据集。Flink具有处理无界流的复杂特性，但也有专门的操作符来有效地处理有界流。
- 实时流和记录流:所有数据都作为流生成。有两种处理数据的方法。当流生成或将其持久化到存储系统(例如文件系统或对象存储)时实时处理，并在稍后处理。Flink应用程序可以处理记录或实时流。
状态
每个重要的流应用程序都是有状态的，即只有对单个事件应用转换的应用程序才需要状态。运行基本业务逻辑的任何应用程序都需要记住事件或中间结果，以便在以后的时间点访问它们，例如在收到下一个事件时或在特定持续时间之后。
应用程序状态是Apache Flink的一等公民。可以通过查看Flink在状态处理环境中提供的所有功能来查看。
- 多状态基元（Multiple State Primitives）：Flink为不同的数据结构提供状态基元，例如原子值，列表或映射。开发人员可以根据函数的访问模式选择最有效的状态原语。
- 可插拔状态后端（Pluggable State Backends）：应用程序状态由可插拔状态后端管理和检查点。Flink具有不同的状态后端，可以在内存或RocksDB中存储状态，RocksDB是一种高效的嵌入式磁盘数据存储。也可以插入自定义状态后端。
- 完全一次的状态一致性（Exactly-once state consistency）：Flink的检查点和恢复算法可确保在发生故障时应用程序状态的一致性。因此，故障是透明处理的，不会影响应用程序的正确性。
- 非常大的状态（Very Large State）：由于其异步和增量检查点算法，Flink能够维持几TB的应用程序状态。
- 可扩展的应用程序（Scalable Applications）：Flink通过将状态重新分配给更多或更少的工作人员来支持有状态应用程序的扩展。
时间
时间是流媒体应用的另一个重要组成部分 大多数事件流都具有固有的时间语义，因为每个事件都是在特定时间点生成的。此外，许多常见的流计算基于时间，例如窗口聚合，会话化，模式检测和基于时间的连接。流处理的一个重要方面是应用程序如何测量时间，即事件时间和处理时间的差异。
Flink提供了一组丰富的与时间相关的功能。
- Event-time Mode：使用事件时间语义处理流的应用程序根据事件的时间戳计算结果。因此，无论是否处理记录的或实时的事件，事件时间处理都允许准确和一致的结果。
- 支持Watermark：Flink使用Watermark来推断事件时间应用中的时间。Watermark也是一种灵活的机制，可以权衡结果的延迟和完整性。
- 延迟数据处理（Late Data Handling）：当使用 watermark 在事件时间模式下处理流时，可能会发生在所有相关事件到达之前已完成计算。这类事件被称为迟发事件。Flink具有多种处理延迟事件的选项，例如通过侧输出重新路由它们以及更新以前完成的结果。
- 处理时间模式（Processing-time Mode）：除了事件时间模式之外，Flink还支持处理时间语义，该处理时间语义执行由处理机器的挂钟时间触发的计算。处理时间模式适用于具有严格的低延迟要求的某些应用，这些要求可以容忍近似结果。
分层api
Flink 根据抽象程度分层，提供了三种不同的 API。每一种 API 在简洁性和表达力上有着不同的侧重，并且针对不同的应用场景。
ProcessFunction
ProcessFunction 是 Flink 所提供的最具表达力的接口。ProcessFunction 可以处理一或两条输入数据流中的单个事件或者归入一个特定窗口内的多个事件。它提供了对于时间和状态的细粒度控制。开发者可以在其中任意地修改状态，也能够注册定时器用以在未来的某一时刻触发回调函数。因此，你可以利用 ProcessFunction 实现许多有状态的事件驱动应用所需要的基于单个事件的复杂业务逻辑。
DataStream API
DataStream API为许多通用的流处理操作提供了处理原语。这些操作包括窗口、逐条记录的转换操作，在处理事件时进行外部数据库查询等。DataStream API 支持 Java 和 Scala 语言，预先定义了例如map()、reduce()、aggregate() 等函数。你可以通过扩展实现预定义接口或使用 Java、Scala 的 lambda 表达式实现自定义的函数。
SQL & Table API
Flink 支持两种关系型的 API，Table API 和 SQL。这两个 API 都是批处理和流处理统一的 API，这意味着在无边界的实时数据流和有边界的历史记录数据流上，关系型 API 会以相同的语义执行查询，并产生相同的结果。Table API 和 SQL 借助了 Apache Calcite来进行查询的解析，校验以及优化。它们可以与 DataStream 和 DataSet API 无缝集成，并支持用户自定义的标量函数，聚合函数以及表值函数。
Flink 的关系型 API 旨在简化数据分析、数据流水线和 ETL 应用的定义。
Libraries
Flink具有几个用于常见数据处理用例的库。 这些库通常嵌入在API中，而不是完全独立的。 因此，他们可以从API的所有功能中受益，并与其他库集成。
- 复杂事件处理(Complex Event Processing: CEP):模式检测是事件流处理的一个非常常见的用例。Flink的CEP库提供了一个API来指定事件的模式(考虑正则表达式或状态机)。CEP库与Flink的DataStream API集成，以便在DataStreams上评估模式。CEP库的应用程序包括网络入侵检测、业务流程监视和欺诈检测。
- DataSet API: DataSet API是Flink的核心API，用于批处理应用程序。DataSet API的原语包括map、reduce、(外部)join、co-group和iterate。所有操作都由算法和数据结构支持，这些算法和数据结构对内存中的序列化数据进行操作，如果数据大小超过内存预算，则会溢出到磁盘。Flink的DataSet API的数据处理算法受到传统数据库操作符的启发，如混合哈希连接或外部合并排序。
- Gelly: Gelly是一个用于可伸缩图形处理和分析的库。Gelly是在数据集API的基础上实现的，并与之集成。因此，它得益于可伸缩和健壮的操作符。Gelly提供了内置的算法，比如标签传播(label propagation)、三角形枚举(triangle enumeration)和页面排名(page rank)，但也提供了一个Graph API，简化了自定义图形算法的实现。
运维
Apache Flink 是一个针对无界和有界数据流进行有状态计算的框架。由于许多流应用程序旨在以最短的停机时间连续运行，因此流处理器必须提供出色的故障恢复能力，以及在应用程序运行期间进行监控和维护的工具。
Apache Flink 非常注重流数据处理的可运维性。因此在这一小节中，我们将详细介绍 Flink 的故障恢复机制，并介绍其管理和监控应用的功能。
7 * 24小时稳定运行
在分布式系统中，服务故障是常有的事，为了保证服务能够7*24小时稳定运行，像Flink这样的流处理器故障恢复机制是必须要有的。显然这就意味着，它(这类流处理器)不仅要能在服务出现故障时候能够重启服务，而且还要当故障发生时，保证能够持久化服务内部各个组件的当前状态，只有这样才能保证在故障恢复时候，服务能够继续正常运行，好像故障就没有发生过一样。
Flink通过几下多种机制维护应用可持续运行及其一致性:
- checkpoint的一致性: Flink的故障恢复机制是通过建立分布式应用服务状态一致性检查点实现的，当有故障产生时，应用服务会重启后，再重新加载上一次成功备份的状态检查点信息。结合可重放的数据源，该特性可保证精确一次（exactly-once）的状态一致性。
- 高效的检查点: 如果一个应用要维护一个TB级的状态信息，对此应用的状态建立检查点服务的资源开销是很高的，为了减小因检查点服务对应用的延迟性（SLAs服务等级协议）的影响，Flink采用异步及增量的方式构建检查点服务。
- 端到端的精确一次: Flink 为某些特定的存储支持了事务型输出的功能，及时在发生故障的情况下，也能够保证精确一次的输出。
- 集成多种集群管理服务: Flink已与多种集群管理服务紧密集成，如 Hadoop YARN, Mesos, 以及 Kubernetes。当集群中某个流程任务失败后，一个新的流程服务会自动启动并替代它继续执行。
- 内置高可用服务: Flink内置了为解决单点故障问题的高可用性服务模块，此模块是基于Apache ZooKeeper技术实现的，Apache ZooKeeper是一种可靠的、交互式的、分布式协调服务组件。
Flink能够更方便地升级、迁移、暂停、恢复应用服务
Flink的 Savepoint 服务就是为解决升级服务过程中记录流应用状态信息及其相关难题而产生的一种唯一的、强大的组件。一个 Savepoint，就是一个应用服务状态的一致性快照，因此其与checkpoint组件的很相似，但是与checkpoint相比，Savepoint 需要手动触发启动，而且当流应用服务停止时，它并不会自动删除。Savepoint 常被应用于启动一个已含有状态的流服务，并初始化其（备份时）状态。
监控和控制应用服务
Flink与许多常见的日志记录和监视服务集成得很好，并提供了一个REST API来控制应用服务和查询应用信息。具体表现如下：
- Web UI方式: Flink提供了一个web UI来观察、监视和调试正在运行的应用服务。并且还可以执行或取消组件或任务的执行。
- 日志集成服务:Flink实现了流行的slf4j日志接口，并与日志框架log4j或logback集成。
- 指标服务: Flink提供了一个复杂的度量系统来收集和报告系统和用户定义的度量指标信息。度量信息可以导出到多个报表组件服务，包括 JMX, Ganglia, Graphite, Prometheus, StatsD, Datadog, 和 Slf4j.
- 标准的WEB REST API接口服务: Flink提供多种REST API接口，有提交新应用程序、获取正在运行的应用程序的Savepoint服务信息、取消应用服务等接口。REST API还提供元数据信息和已采集的运行中或完成后的应用服务的指标信息。
应用场景
概述
Apache Flink因其丰富的功能而成为开发和运行多种不同类型应用程序的绝佳选择。Flink的功能包括对流和批处理的支持，复杂的状态管理，事件时间处理语义以及状态的一致性保证。此外，Flink可以部署在各种资源管理器上（如YARN，Apache Mesos和Kubernetes），也可以作为裸机硬件上的独立群集。Flink配置为高可用性，没有单点故障。Flink提供高吞吐量和低延迟，并为世界上一些最苛刻的流处理应用程序提供支持。
下面，我们将探讨由Flink提供支持的最常见类型的应用程序，并指出实际示例。
- 事件驱动型的应用程序
- 数据分析型的应用程序
- 数据管道型的应用程序
事件驱动型的应用程序
事件驱动型的应用程序是一个有状态的应用程序，它从一个或多个事件流中提取事件，并通过触发计算、状态更新或外部操作对传入事件做出反应。
传统应用程序设计具有分离的计算和数据存储层，在此体系结构中，应用程序从远程事务数据库中读取数据并将数据持久化。
相反，事件驱动的应用程序基于有状态流处理应用程序。在这种设计中，数据和计算是共同定位的，这产生了本地（内存或磁盘）数据访问。通过定期将检查点写入远程持久存储来实现容错。
事件驱动的应用程序不是查询远程数据库，而是在本地访问其数据，从而在吞吐量和延迟方面产生更好的性能。远程持久存储的检查点可以异步和递增完成。因此，检查点对常规事件处理的影响非常小。
几种典型的事件驱动型应用程序：
欺诈识别
异常检测
基于规则的警报
业务流程监控
Web应用程序（社交网络）
数据分析型应用程序
数据分析工作从原始数据中提取信息。传统上，数据分析是在记录事件的有界数据集上作为批量查询或应用程序执行。为了将最新数据合并到分析结果中，必须将其添加到分析的数据集中，并重新运行查询或应用程序。结果将写入存储系统或作为报告发出。
借助先进的流处理引擎，还可以实时地执行分析。流式查询或应用程序不是读取有限数据集，而是摄取实时事件流，并在消耗事件时不断生成和更新结果。结果要么写入外部数据库，要么保持为内部状态。仪表板应用程序可以从外部数据库读取最新结果或直接查询应用程序的内部状态。Apache Flink支持流式和批量分析应用程序。
与批量分析相比，连续流分析的优势不仅限于低延迟。与批量查询相比，流式查询不必处理输入数据中的人为边界，这些边界是由定期导入和输入的有界性质引起的。
另一方面是更简单的应用程序架构。批量分析管道由若干独立组件组成，以定期调度数据提取和查询执行。可靠地操作这样的管道并非易事，因为一个组件的故障会影响管道的后续步骤。相比之下，在像Flink这样的复杂流处理器上运行的流分析应用程序包含从数据摄取到连续结果计算的所有步骤。
几种典型的数据分析型应用程序：
电信网络的质量监控
分析移动应用程序中的产品更新和实验评估
对消费者技术中的实时数据进行特别分析
大规模图分析
数据管道型应用程序
提取 - 转换 - 加载（ETL）是在存储系统之间转换和移动数据的常用方法。通常会定期触发ETL作业，以将数据从事务数据库系统复制到分析数据库或数据仓库。
数据管道与ETL作业具有相似的用途。它们可以转换和丰富数据，并可以将数据从一个存储系统移动到另一个存储系统。但是，它们以连续流模式运行，而不是定期触发。因此，他们能够从连续生成数据的源中读取记录，并以低延迟将其移动到目的地。例如，数据管道可能会监视文件系统目录中的新文件并将其数据写入事件日志。
连续数据流水线优于周期性ETL作业的原因是减少了将数据移动到目的地的延迟。此外，数据管道更通用，可用于更多用例，因为它们能够连续消耗和发送数据。
几种典型的数据管道型应用：
电子商务中的实时搜索索引构建
电子商务中持续的ETL