书山有路，学海无涯。记录成长，追逐梦想

Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。

总的来说，Apache Flink 有几个显著的优点，使其成为当今最流行的分析引擎之一。它的速度快如闪电，是一个分布式系统，能以容错的方式处理批处理和流式数据，还能处理大型数据集，这些优点使它成为各种应用的理想选择。

现实世界的系统、网络及通信信道往往充斥着缺陷，因此流数据通常都会有所延迟或者以乱序到达。了解如何在这种情况下提供精准确定的结果就变得至关重要。此外，处理实时事件的流处理应用还应以相同的方式处理历史事件，这样才能支持离线分析，甚至时间旅行式分析。当然，如果你的系统无法在故障时保护状态，那一切都是空谈。

水位线允许我们在结果的准确性和延迟之间做出取舍。激进的水位线策略保证了低延迟，但随之而来的是低可信度。该情况下，延迟事件可能会在水位线之后到来，我们必须额外加一些代码来处理它们。反之，如果水位线过于保守，虽然可信度得以保证，但可能会无谓地增加处理延迟。

在流式作业中，算子的状态十分重要，因此需要在故障时予以保护。如果状态在故障期间丢失，那恢复后的结果就会不正确。流式作业通常会运行较长时间，因此状态可能是经过数天甚至数月才收集得到。通过重新处理所有输入来重建故障期间丢失的状态，不仅代价高，而且很耗时。

本篇博客我们将介绍搭建 Flink 时所涉及的不同组件并讨论它们在应用运行时的交互过程。我们主要讨论两类部署 Flink 应用的方式以及它们如何分配和执行任务。最后，我们将解释 Flink 高可用模式的工作原理。

在运行过程中，应用的任务会持续进行数据交换。TaskManager 负责将数据从发送任务传输至接收任务。它的网络模块在记录传输前会先将它们收集到缓冲区中。换言之，记录并非逐个发送的，而是在缓冲区中以批次形式发送。该技术是有效利用网络资源、实现高吞吐的基础。它的机制类似于网络以及磁盘 I/O 协议中的缓冲技术。

在事件时间模式下，Flink 流式应用处理的所有记录都必须包含时间戳。时间戳将记录和特定时间点进行关联，这些时间点通常是记录所对应事件的发生时间。但实际上应用可以自由选择时间戳的含义，只要保证流记录的时间戳会随着数据流的前进大致递增即可。正如前文所述，基本上所有现实应用场景都会出现一定程度的时间戳乱序。

在前面的博客中我们指出，大部分的流式应用都是有状态的。很多算子都会不断地读取并更新某些状态，例如：窗口内收集的记录，输入源的读取位置或是一些定制的，诸如机器学习模型之类的特定应用状态。无论是内置状态还是用户自定义状态，Flink 对它们都一视同仁。本篇博客我们会对 Flink 支持的不同类别的状态进行介绍。

本篇博客我们将介绍 Flink 的检查点（checkpoint）及故障恢复机制，看一下它们如何提供精确一次的状态一致性保障。而在下一篇博客中，我们还会讨论 Flink 所独有的保存点（savepoint）机制，它就像一把 “瑞士军刀”，解决了运行流式应用过程中的诸多难题。

Flink 最具价值且独具一格的功能之一是保存点。原则上，保存点的生成算法和检查点完全一样，因此可以把保存点看做包含一些额外元数据的检查点。保存点的生成不是由 Flink 自动完成，而是需要由用户（或外部调度器）显式触发。同时，Flink 也不会自动清理保存点。后续我们将介绍如何生成和删除保存点。

Apache Flink 持续保持高速发展，是 Apache 最活跃的社区之一。Flink 1.16 共有 240 多个 Contributor 热情参与，共完成了 19 个 FLIP 和 1100 多个 issue，给社区带来非常多振奋人心的功能。

总之，Flink DataGen 是一个强大的工具，可以帮助测试人员构造各种类型的测试数据。通过合理的使用 ，测试人员可以更有效地进行测试，并发现潜在的问题和缺陷。

发生问题时，首先要做的是现象记录，即检查作业的运行状态。如果运行状态不是运行中，那肯定没有数据正常输出了，需要进一步从日志中查找问题根因。如果作业在运行中，但是存在近期的重启记录，也表明可能发生了较严重的问题。此时需要整理问题发生的时间线，便于后续定位参考。

Flink 包含 8 种分区策略，这 8 种分区策略（分区器）分别如下面所示，本文将从源码的角度解读每个分区器的实现方式。

Watermark 是 Apache Flink 为了处理 EventTime 窗口计算提出的一种机制，本质上也是一种时间戳。Watermark 是用于处理乱序事件或延迟数据的，这通常用 Watermark 机制结合 Window 来实现（Watermarks 用来触发 Window 窗口计算）。

通过调整 task slot 的数量，用户可以定义 subtask 如何互相隔离。每个 TaskManager 有一个 slot，这意味着每个 task 组都在单独的 JVM 中运行（例如，可以在单独的容器中启动）。具有多个 slot 意味着更多 subtask 共享同一 JVM。同一 JVM 中的 task 共享 TCP 连接（通过多路复用）和心跳信息。它们还可以共享数据集和数据结构，从而减少了每个 task 的开销。

人们经常会问 Flink 是如何处理背压（backpressure）效应的。 答案很简单：Flink 不使用任何复杂的机制，因为它不需要任何处理机制。它只凭借数据流引擎，就可以从容地应对背压。在这篇博文中，我们介绍一下背压。然后，我们深入了解 Flink 运行时如何在任务之间传送缓冲区中的数据。 最终，我们通过一个小实验展示这一点。

在所有其他模式下，应用程序的 main() 方法都在客户端执行。这一过程包括在本地下载应用程序的依赖项，执行 main() 以提取 Flink 运行时可以理解的应用程序表示（即 JobGraph），并将依赖项和 JobGraph 发送到集群。这就使客户端成为资源消耗大户，因为它可能需要大量网络带宽来下载依赖项并将二进制文件发送到集群，还需要 CPU 周期来执行 main()。当客户端被多个用户共享时，这一问题会更加突出。

Node 为集群的一个操作单元，是 Pod 运行的宿主机。Node 节点里包含一个 Agent 进程，能够维护和管理该 Node 上的所有容器的创建、启停等。Node 还含有一个服务端 kube-proxy，用于服务发现、反向代理和负载均衡。Node 底层含有 docker engine，docker 引擎主要负责本机容器的创建和管理工作。

Flink 程序中设定并行度有 4 种级别，从低到高分别为：算子级别、执行环境级别（ExecutionEnvironment）、客户端（命令行）级别、配置文件级别（flink-conf.yaml）。实际执行时，优先级则是反过来的，算子级别最高。

Flink on YARN 集群部署模式涉及 YARN 和 Flink 两大开源框架，应用启动流程的很多环节交织在一起，为了便于大家理解，在一张图上画出了 Flink on YARN 基础架构和应用启动全流程，并对关键角色和流程进行了介绍说明，整个启动流程又被划分成客户端提交（流程标注为紫色）、Flink Cluster 启动和 Job 提交运行（流程标注为橙色）两个阶段分别阐述，由于分支和细节太多，本文会忽略掉一些，只介绍关键流程（基于 Flink 开源1.9版本源码整理）。

Apache Flink 通过严格控制各种组件的内存使用，在 JVM 上提供高效的工作负载。虽然社区努力为所有配置提供合理的默认值，但用户在 Flink 上部署的应用程序种类繁多，这意味着这并非总是可行。为了向用户提供最大的生产价值，Flink 允许对集群内的内存分配进行高级和精细调整。

以上 Total Process Memory 的模型图可以分为以下的 4 个内存组件，如果在分配内存的时候，显示的指定了组件其中的1个或者多个，那么JVM Overhead的值就是在其它组件确定的情况下，用Total Process Size- 其它获取的值，必须在min-max之间，如果没有指定组件的值，那么就按照0.1 的比例进行计算得到，如果计算出的值小于min取min，如果大于max取max，如果min、max指定的相等，那么这个JVM Overhead就

Flink JVM 进程的总内存（Total Process Memory）由 Flink 应用程序（Total Flink Memory，Flink 总内存）和 JVM 运行进程所消耗的内存组成。Flink 总内存（ Total Flink Memory）包括 JVM Heap、Managed Memory（托管内存，由 Flink 管理）和其他 Direct Memory（或 Native Memory）的使用量。

在 《Flink 内存管理（一）：设置 Flink 进程内存》中我们提到，必须使用下述三种方法之一配置 Flink 的内存（本地执行除外），否则 Flink 启动将失败。这意味着必须明确配置以下选项子集之一，这些子集没有默认值。

WaterMark 只是决定了窗口的触发时机，并非可以改变元素归属的窗口（事件应归属的窗口是由事件本身的事件时间决定的），例如上方元素 C、G，虽然根据设置的延迟时间可能触发窗口 [12:00:00-12:00:10) 计算，但其本身时间不归属于窗口之内，因为窗口 [12:00:00-12:00:10) 中永远不会有 >= 12:00:10 的元素存在。

在流式计算中，流通常是无穷无尽的，我们无法知道什么时候数据源会继续 / 停止发送数据，所以在流上处理聚合事件（count、sum 等）的处理方式与批处理中的处理方式会有所差异。在流上一般用窗口（Window）来限定聚合的范围，例如 “过去 2 分钟网站点击量的计数”、“在最近 100 个人中点赞这个视频的总人数”。窗口的概念相当于帮我们收集了一张有限数据的动态表，我们可以对表中的数据进行聚合计算。

Flink 是一个以流为核心的高可用、高性能的分布式计算引擎。具备流批一体，高吞吐、低延迟，容错能力，大规模复杂计算等特点，在数据流上提供数据分发、通信等功能。

Flink 支持两种划分窗口的方式（time 和 count）。第一种，按时间驱动进行划分、另一种按数据驱动进行划分。

使用嵌入式的本地数据库 RocksDB 将流计算数据状态存储在本地磁盘中，不会受限于 TaskManager 的内存大小，在执行检查点的时候，再将整个 RocksDB 中保存的 State 数据全量或者增量持久化到配置的文件系统中，在 JobManager 内存中会存储少量的检查点元数据。除了对 State 中数据的访问之外，还提供内部运行时信息，如 State 中数据的序列化器，命名空间（namespace）、命名空间的序列化器、命名空间合并的接口。个独立的线程，将自身的状态写入分布式存储可靠存储中。

Checkpoint 被叫做检查点，是 Flink 实现容错机制最核心的功能，是 Flink 可靠性的基石，它能够根据配置周期性地基于 Stream 中各个 Operator 的状态来生成 Snapshot 快照，从而将这些状态数据定期持久化存储下来，当 Flink 程序一旦意外崩溃时，重新运行程序时可以有选择地从这些 Snapshot 进行恢复，从而修正因为故障带来的程序数据状态中断。

反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为瓶颈，下游处理速率跟不上上游发送数据的速率，而需要对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率。

PipeExecutor在 Flink 中被叫做流水线执行器，它是一个接口，是Flink Client生成 JobGraph 之后，将作业提交给集群的重要环节。前面说过，作业提交到集群有好几种方式，最常用的是yarn方式，yarn方式包含3种提交模式，主要使用session模式，per-job模式。application模式中 JobGraph 是在集群中生成。

调度器是 Flink 作业执行的核心组件，管理作业执行的所有相关过程，包括 JobGraph 到 ExecutionGraph 的转换、作业生命周期管理（作业的发布、取消、停止）、作业的 Task 生命周期管理（Task 的发布、取消、停止）、资源申请与释放、作业和 Task 的 Faillover 等。

从 1.9.0 版本开始，引入了阿里巴巴的 Blink ，对 FIink TabIe & SQL 模块做了重大的重构，保留了 Flink Planner 的同时，引入了 Blink PIanner，没引入以前，Flink 没考虑流批作业统一，针对流批作业，底层实现两套代码，引入后，基于流批一体理念，重新设计算子，以流为核心，流作业和批作业最终都会被转为 transformation。

在金融场景中，有时会出现银行卡盗刷现象，犯罪分子利用互联网等技术，在间隔 10 分钟或者更短时间内，使一张银行卡在不同的两个地方出现多次刷卡记录，这从常规操作来说，在间隔时间很多的情况下，用户是无法同时在两个城市进行刷卡交易的，所以出现这种问题，就需要后台做出触发报警机制。

在最新 CDC 调研报告中，Debezium 和 Canal 是目前最流行使用的 CDC 工具，这些 CDC 工具的核心原理是抽取数据库日志获取变更。在经过一系列调研后，目前 Debezium（支持全量、增量同步，同时支持 MySQL、PostgreSQL、Oracle 等数据库），使用较为广泛。

CREATE 语句用于向当前或指定的 Catalog 中注册库、表、视图或函数。注册后的库、表、视图和函数可以在 SQL 查询中使用。

关于看如何看一段 Flink SQL 最终的执行计划：最好的方法就如上图，看 Flink Web UI 的算子图，算子图上详细的标记清楚了每一个算子做的事情。