1.1 前言
Apache Flink 是一个分布式流处理引 擎，它提供了直观且极富表达 力的 API 来实现有状态的流处理应用，并且支持在容错的前提下高效、大规模地运行 此类应用。
1.2 传统数据处理架构
1.2.2 事务型处理
该设计在应用需要更新或扩缩容时容易导致问题 。一且多个应用基于相同数据表示或共享架构，那么更改表模式( Schema)或对数据库系统进行扩缩 容必将芳心费力。
1.2.3 分析型处理
将事务型数据复制到一个专门用来处理分析类查询的数据仓库。这个向数据仓库拷贝数据的过程被称 为提取-转换-加载( Extract-Transform-Load, ETL)。 ETL 的基本流程是 : 从事务型数据库中提取数据，将其转换为通用表示形式(可 能包含数据验证、 数据归 一 化 、编码、去重、表模式转换等工作)，最终加载到分析型数据库中。 该流程可能会非常麻烦，通常需要复杂的技术方案来满足性能要求。为了保 持数据仓库中的数据同步， ETL 过程需要周期性地执行 。
1.3 状态化流处理
有状态指的是能够存储和访问中间结果
1.3.1 事件驱动型应用
事件驱动型应用是一 类通过接收事件流触发特定应用业务逻辑的有状态的流式应用。
事件驱动型应用的典型应用场景有 :-
- 实时推荐(例如 在客户浏览商家页面的同时进行产品推荐)。
- 模式识别或复杂事件处理(例如 根据信用卡交易记录进行欺诈识别) 。
- 异常检测(例如计算机网络入侵检测)。
1.3.2 数据管道应用
以低延迟的方式获取、转换并插入数据，我们将此类应用称为数据管道。它需要在短时间内处理大批量数据。 执行数据管道应用的流处理引擎为了支持不同外部系统的数据读写，还需要 提供多样化的数据源、数据汇连接器 。
1.3.3 流式分析应用
流式分析应用不再需要等待周期性地触发。相反，它会持续获取事件流，以 极低的延迟整合最新事件，从而可以不断更新结果 。
流式分析应用常用于:-
- 手机网络质量监控。
- 移动应用中的用户行为分析。
- 消费者技术中的实时数据即席分析。
1.4 Flink快览
Apache Flink是一个集众多具有竞争力的特性于一身的第三代流处理引 擎。
功能：
- 同时支持事件时间和处理时间语义。
- 提供精确 一 次( exactly-once)的状态 一 致性保障 。
- 在每秒处理数百万条事件的同时保持毫秒级延迟。
- 层次化的 API在表达能力和l易用性方面各有权衡。
- 允许在不丢失应用状态的前提下更新作业的程序代码，或进行跨 Flink 集 群的作业迁移。
- 提供了详细、可自由定制的系统及应用指标( metrics)集合，用于提前定 位和!响应问题。
第二章 流处理基础
2.1 Dateflow图
Dataflow程序通常表示为有向图。图中顶点称为算子，表示计算；而边表示数据依赖关系。
为了执行Dataflow程序， 需要将逻辑图转化为物理Dataflow图，后 者会指定程序的执行细节。例如: 当我们使用分布式处理引擎时，每个算子 可能会在不同物理机器上运行多个并行任务。
2.2 数据交换策略
2.3 延迟和吞吐
延迟：
延迟表示处理一个事件所需的时间。本质上，它是从接收事件到在输出中观察到事件处理效果的时间间隔。
吞吐：
吞吐是用来衡量系统处理能力(处理速率)的指标，它告诉我们系统每单位 时间可以处理多少事件。
2.4 数据流上的操作
2.4.1 数据接入和数据输出
负责数据接入操作逻辑的算子称为数据源，数据惊可 以从 TCP 套 接字、文件、Kafka主题或传感器数据接口中获取数据。
负责数据输出的算子称为数据汇，其写入的目标可以 是文件、数据库、消息队列或监控接口等。
2.4.2 转换操作
转换操作是一类“只过一次”的操作，它 们 会分别处理每个事件。
算子既可以同时接收多个输入流或产生多条 输出流，也可以通过单流分割或合并多条流来改变Dataflow 图的结构 。
2.4.3 滚动聚合
滚动聚合 (如求和、求最小值和求最大值 ) 会根据每个到来的事件持续更新结果。
2.4.4 窗口操作
转换操作和滚动聚合每次处理一个事件来产生输出并（可能）更新状态。
窗口操作会持续创建一些称为”桶“的有限事件集合，并允许我们基于这些有限集进行计算。
2.4.4.1 滚动窗口
定义了在触发计算前需要集齐多少条件。
定义了在桶中缓冲数据的时间间隔。
2.4.4.2 滑动窗口
通过指定长度和滑动间隔来定义滑动窗口。滑动间隔决定每隔多久生成一个新的桶。
2.4.4.3 会话窗口
根绝会话间隔将事件分为不同的会话，该间隔值定义了会话在关闭前的非活动时间长度，适用于分析用户行为。
2.5 流处理场景下一分钟的含义
2.5.1 处理时间
处理时间是当前流处理算子所在机器上的本地时钟时间。
2.5.2 事件时间
事件时间是数据流中事件实际发生的时间，它以附加在数据流中事件的时间戳为依据。
处理时间提供了很低的延迟，但是它的结果依赖处理速度，具有不确定性。事件时间则与之相反，能保证结果的准确性，并允许你处理延迟甚至无序的事件。
2.6 水位线
水位线是一个全局进度指标，表示我们确信不会再有延迟事件到来的某个时间点。
第三章 Apache Flink架构
3.1 系统架构
Flink 是 一 个用于状态化并行流处理的分布式系统。它的搭建涉及多个进程，这些进程通常会分布在多台机器上。
3.2 搭建Flink所需组件
JobManager：控制着单个应用程序的执行。
ResourceManager：负责管理Flink的处理资源单元-TaskManager处理槽。
TaskManager：是 Flink 的工作进程( worker process)。通常在 Flink 搭建过程 中要启动多个 TaskManager。每个 TaskManager提供-定数量的处理槽。处理
槽的数目限制了-个 TaskManager可执行的任务数。
Dispatcher：会跨多个作业运行，它提供了 一 个 REST 接口来让我们提 交需要执行的应用。
3.3 应用部署
3.3.1 框架模式
Flink应用会打包成一个JAR文件，通过客户端提交到运行的服务上。如果提交到JobManager，则可以立即执行；如果提交到Dispatcher或ResourceManager上，则会启动一个JobManager并将应用转交给它，然后开始执行。
3.3.2 库模式
Flink应用会绑定到一个特定应用的容器镜像 (女口 Docker镜 像)中。镜像中还包含着运行 JobManager 以及 ResourceManager 的代码。 当容器从镜像启动后会自动加载 ResourceManager和 JobManager，并将 绑定的作业提交执行。
3.4 Flink高可用
Flink中的高可用模式是基于能够提供分布式协调和共识服务的ZooKeeper来完成的。JobManager在高可用模式下工作时，会将JobGraph以及全部所需的元数据写入一个
远程存储系统中。此外，JobManager还会将存储位置的路径写入Zookeeper的数据存储。
当JobManager发生故障时，其下应用的所有任务都会自动取消。新接手的JobManager会执行以下步骤：
- 向Zookeeper请求存储位置，以获取JobGraph。JAR文件以及应用最新检查点在远程存储的状态句柄。
- 向ResourceManager申请处理槽来继续执行应用。
- 重启应用并利用最近一次检查点重置任务状态。
3.5 水位线传播和事件时间
Flink内部将水位线实现为特殊的记录，他们可以通过算子任务进行接收和发送。当任务接收到一个水位线时会执行以下操作：
- 基于水位线记录的时间戳更新内部事件时间时钟。
- 任务的时间服务会找出所有触发时间小于更新后时间时间的计时器。对于每个到期的计时器，调用回调函数，利用他来执行计算或发出记录。
- 任务根据更新后的事件时间将水位线发出。
3.6 键值分区状态常用原语
单值状态：
每个键对应存储一个任意类型的值，该值也可以是某个复杂数据结构。
列表状态：
每个键对应存储一个值得列表。列表中的条目可以是任意类型。
映射状态：
每个键对应存储一个键值映射，该映射的键和值可以是任意类型。
