SmartSi

Flink 学习笔记

说完了 preCommit 和 commit，在两次 Checkpoint 发生的间隔当中，会持续的执行 invoke 方法将数据的写到 Kafka，直到 snapshotState 方法被调用，旧的数据被进行预提交，同时生成新的事务，数据继续写入，直到所有任务Checkpoint完成，收到通知，对完成的checkpointId把事务进行正式的提交。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。

这篇文章从 org.apache.flink.table.examples.java.StreamSQLExample 这个简单的例子分析 Flink SQL 的一个简单的执行流程，也算 Flink SQL 执行流程初步的入门，我们先从整体的执行框架了解一个整体流程，方便之后我们有机会对 Flink SQL 进行修改先有一个简单认识

外部 State API 是对外部用户开放的稳定 API，需要使用这种 API 来开发应用程序。开发者 API（Internal API）是对内部开发者使用的 API，是不稳定的，可能会随着版本迁移发生变化。开发者 API（Internal API）在形式上继承了对外 API

对于那些依赖于不支持回滚的状态后端的 Sink，当前检查点机制并不是完全适合。当处理这样的系统时，如果想要保证 Exactly-Once 语义，那么既不能在创建快照时提交数据(如果 Sink 的另一个实例失败了可能会导致对相同数据的重放)，也不能在接收检查点完成通知时提交数据(因为后续失败将使我们不知道数据是否被提交)。

这些依赖项是 Flink 核心依赖项，在实际运行时已经被加载，只需要对它们进行编译，不应将它们打包到项目生成的应用程序 jar 文件中

DataStream 作业开发时往往会遇到一些 jar 包冲突等问题，本文主要讲解作业开发时需要引入哪些依赖以及哪些需要被打包进作业的 jar 中，从而避免不必要的依赖被打入了作业 jar 中以及可能产生的依赖冲突。

Flink 实现操作 OperatorState 的有状态函数，有两种实现方式：- 第一种是通过实现 CheckpointedFunction 接口- 第二种是通过实现 ListCheckpointed 接口

很多时候，我们需要在函数处理第一条记录之前进行一些初始化的工作或者获得函数执行上下文的一些信息，以及在处理完记录后做一些清理工作。而 DataStream API 中的富函数 RichFunction 就提供了这样的机制。DataStream API 提供了一类富函数，和普通函数相比可对外提供跟多的功能。

在我们在使用 Flink Streaming Kafka Connector 从 Kafka 中读取时，一般会采用 SimpleStringSchema 来反序列化 Kafka 中的数据。如果是 Kafka 中的数据是 JSON 格式，然后采用 Gson 或者 FastJson 来解析数据。除了使用这种方式之外，Flink 为我们内置实现了一个 KafkaSerializationSchema 来帮我们解析 Kafka 中的 JSON 格式数据，即 JSONKeyValueDeserializa

序列化 Schema 描述了如何将 Flink 处理的数据类型(Java/Scala对象)转换为 Kafka 可以接受的数据类型。反序列化 Schema 描述了如何将 Kafka 中的数据转换为 Flink 可以处理的数据类型(Java/Scala对象)。

在使用 Flink Streaming Kafka Connector 从 Kafka 中读取时，反序列化器指定 `JSONKeyValueDeserializationSchema` 抛出 org.apache.flink.shaded.jackson2.com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'a': was expecting 异常

本文主要介绍 Flink 1.11 版本中如何使用 DataStream 方式利用 Kafka Connector 从 Kafka 中读取数据并写到 Kafka 中，主要讲述了 Kafka Connector 的功能

Flink 如何处理背压这篇文章虽然比较旧，但比较准确的解释了背压。如果您不了解背压这个概念，我强烈建议您阅读一下。如果想更深入、更底层地了解该话题以及 Flink 的网络堆栈是如何工作的，可以查阅Flink 网络流控和反压剖析详解。从高层次上理解，如果作业图中的某些算子无法以接收记录相同的速度处理记录，就会发生背压。运行这个慢算子的子任务的输入缓冲区就会被填满。一旦输入缓冲区被填满，背压就会传播到上游子任务的输出缓冲区。

在离线 Hive 中，我们经常会使用 Join 进行多表关联。那么在实时中我们应该如何实现两条流的 Join 呢？下面我们分别详细看一下这3个算子是如何实现双流 Join 的。

广播状态模式指的是将低吞吐量的事件流（例如，包含一组规则）广播到某个算子所有并发实例上的一种流应用程序，然后与来自另一条事件流的原始数据进行计算。动态规则：假如我们有这样一条规则，当交易值超过100万美元时需要发警报，并将这一规则广播到算子所有并发实例上。数据丰富：对只包含用户ID的交易数据流进行数据丰富，可以将广播数据与用户ID进行关联。为了实现这样的应用，广播状态是关键组件，我们将在下文详细描述。广播状态是 Flink 中支持的第三种类型的 Operator State。

广播状态可以以某种方式组合处理两个事件流。第一个流的事件被广播到算子所有并行实例上，并存储在状态中。另一个流的事件不会被广播，但是会被发送到同一算子的各个实例上，并与广播流的事件一起处理。这种新的广播状态非常适合低吞吐量和高吞吐量流 Join 或需要动态更新处理逻辑的应用程序。我们将使用一个具体示例来演示如何使用广播状态，并展示具体的API。

反压严重时，Aligned Checkpoint（下文简称 AC）超时主要在于 Barrier 在数据流中排队。反压严重时，数据流动很慢导致 Barrier 流动很慢，最终导致 AC 超时。UC 的核心思路是：当数据流动很慢时，Barrier 通过某些机制超越数据，从而使得 Barrier 可以快速地从 Source 一路超车到 Sink。

Flink 检查点是支持两阶段提交协议并提供端到端的 Exactly-Once 语义的基础。这个方案的一个优点是: Flink 不像其他一些系统那样，通过网络传输存储（materialize）数据 - 不需要像大多数批处理程序那样将计算的每个阶段写入磁盘。Flink 新的 TwoPhaseCommitSinkFunction 提取了两阶段提交协议的通用逻辑，并使构建端到端的 Exactly-Once 语义的应用程序（使用 Flink 和支持事务的外部系统）成为可能。

我们可以看到所有的 Partitioner 都继承了 StreamPartitioner 类。StreamPartitioner 继承自 ChannelSelector 接口。这里的 Channel 概念与 Netty 不同，只是 Flink 对于数据写入实例的简单抽象，我们可以直接认为它就是下游算子的并发实例（即物理分区）。所有 StreamPartitioner 的子类都要实现 selectChannel() 方法，用来选择发送到哪个实例。

要了解一个系统，一般都是从架构开始。我们关心的问题是：系统部署成功后各个节点都启动了哪些服务，各个服务之间又是怎么交互和协调的。下方是 Flink 集群启动后架构图。

TopN 是统计报表和大屏非常常见的功能，主要用来实时计算排行榜。流式的 TopN 不同于批处理的 TopN，它的特点是持续的在内存中按照某个统计指标（如出现次数）计算 TopN 排行榜，然后当排行榜发生变化时，发出更新后的排行榜。本文主要讲解 Flink SQL 是如何从语法和实现上设计 TopN 的。流式 TopN 不仅在语法以及算法上会遇到很多挑战，在不同场景下的优化方案也是个非常有意思的话题。目前 Flink SQL 的 TopN 功能已经大量应用于彩票业务、阿里云的CDN项目、WAF项目等等。

像 Flink 这样的流处理系统需要能够从容地处理背压。背压是指系统在一个临时负载峰值期间接收数据的速率大于其处理速率的一种场景(可以理解为处理速度慢，接收速度快，系统处理不了接收的数据)。许多日常情况都会导致背压。例如，垃圾回收卡顿可能导致流入的数据堆积起来，或者数据源可能出现发送数据过快的峰值。如果处理不当，背压会导致资源耗尽，甚至导致数据丢失。让我们看一个简单的例子。

网络流控是为了在上下游速度不匹配的情况下，防止下游出现过载。网络流控有静态限速和动态反压两种手段。Flink 1.5 之前是基于 TCP 流控 + bounded buffer 实现反压。Flink 1.5 之后实现了自己托管的 credit - based 流控机制，在应用层模拟 TCP 的流控机制。

从上面日志中可以看出是在序列化生成器 SequenceGenerator 初始化时抛出异常，具体与双端队列 ArrayDeque 相关。从上面代码中可以看出每个并发子任务在初始化序列化生成器时会创建一个双端队列 ArrayDeque 来存储。对此，你可以扩大 TaskManager 的堆内存大小。由于我们设置的区间比较大，所以导致双端队列再扩容时出现堆内存溢出。session_id 的生成区间从。

之前我们在 Flink SQL 中支持了 MiniBatch, 在支持高吞吐场景发挥了重要作用。今年我们在 Flink SQL 性能优化中一项重要的改进就是升级了微批模型，我们称之为 MicroBatch，也叫 MiniBatch2.0。之前我们在 Flink SQL 中支持了。

错误日志提示已经很明显，状态大小超过 Checkpoint 持久化存储默认最大值。由于代码中没有指定 CheckpointStorage，因此默认使用 JobManagerCheckpointStorage 存储在内存中，默认大小为 5MB。日志中建议切换到 FileSystemCheckpointStorage 中。注意的是 Flink 1.13 版本将之前的 StateBackend 拆分成新的 StateBackend 和 CheckpointStorage 两个功能。

在 Blink 的流式任务中，State 相关的操作通常都会成为整个任务的性能瓶颈。实时计算部-查询和优化团队开发了 MiniBatch 功能，大幅降低了 State 操作的开销，在今年的双11中，几乎所有适用的任务都启用了 MiniBatch 功能。

DataGen Connector 是一个内置的 Source Connector，基于生成的内存数据来创建表。这在本地开发查询而不访问外部系统（如 Kafka）时很有用。random：随机生成器sequence：序列生成器随机生成器（random），是默认的生成器。可以指定随机生成的最大和最小值。char、varchar、string （类型）可以指定长度。随机生成器是一种无界的生成器，如果指定了总行数，从而变成了一个有界生成器。序列生成器（sequence），可以指定序列的起始和结束值。

本文整理自 Flink Forward 2020 全球在线会议中文精华版，由 Apache Flink PMC 伍翀（云邪）分享，社区志愿者陈婧敏（清樾）整理。旨在帮助大家更好地理解 Flink SQL 引擎的工作原理。

EMIT 输出策略是指在 Flink SQL 中，QUERY 根据不同场景选择不同的输出策略（例如最大延迟时长），从而达到控制延迟或提高数据准确性的效果。例如，1 小时的时间窗口，窗口触发之前希望每分钟都能看到最新的结果，窗口触发之后希望不丢失迟到一天内的数据。如果 1 小时窗口内的统计结果无变化，则不更新输出结果；如果1小时窗口内的统计结果有变化，则更新输出结果。需要注意的是添加了 EMIT 输出策略后会由原来输出 Append 流变成输出 Retract 流。

在 Flink 1.12 之前的版本中，Table API 和 SQL 提供了一组分组窗口 Group Window 函数，常用的时间窗口如滚动窗口、滑动窗口、会话窗口都有对应的实现，具体在 SQL 中调用 TUMBLE()、HOP()、SESSION() 分组窗口函数即可。分组窗口的功能比较有限，只支持窗口聚合，所以在 Flink 1.12 之后的版本中不再推荐使用 Group Window 函数。而是推荐使用功能更加强大以及更有效的 Window TVF，具体请查阅。

基于时间的操作，例如 Table API 和 SQL 查询中的窗口，需要知道时间相关的信息。因此，表需要提供逻辑时间属性以指明时间以及提供访问相应的时间戳。时间属性可以作为表 schema 的一部分，可以在用 CREATE TABLE DDL 语句创建表的时候指定、也可以在 DataStream 中指定、也可以在定义 TableSource 时指定。一旦定义了时间属性，就可以像普通字段一样使用，也可以在时间相关的操作中使用。

窗口 TVF 是 Flink 定义的多态表函数(缩写 PTF)。PTF 是 SQL 2016 标准的一部分，是一个特殊的表函数，可以将表作为参数。因为 PTF 在语义上像表一样使用，所以它们的调用发生在 SELECT 语句的 FROM 子句中。窗口 TVF 是传统 Grouped Window 函数的替代品。窗口 TVF 更符合 SQL 标准，也更强大，可以支持复杂的基于窗口的计算，例如 Window TopN, Window Join。但是，Grouped Window 函数只能支持窗口聚合。

Flink 1.11 的 Unaligned Checkpoint 主要解决在高反压情况下作业难以完成 Checkpoint 的问题，同时它以磁盘资源为代价，避免了 Checkpoint 可能带来的阻塞，有利于提升 Flink 的资源利用率。随着流计算的普及，未来的 Flink 应用大概会越来越复杂，在未来经过实战打磨完善后 Unaligned Checkpoint 很有可能会取代 Aligned Checkpoint 成为 Flink 的默认 Checkpoint 策略。

Chandy-Lamport分布式快照算法小记与分布式数据流的轻量级异步快照。

在本节中，我们将介绍 Flink 如何利用检查点 Checkpoint 实现故障恢复。

QueryableStates 允许用户对流的内部状态进行实时查询，而无需将结果存储到任何外部存储中。这制造了许多有趣的可能，因为我们不再需要等待系统写入外部存储（这一直是此类系统的主要瓶颈之一）。甚至可能没有任何类型的数据库能让用户的应用程序直接查询流，这将使应用程序更快、更便宜。这可能不适用于所有用例，但如果您的 Pipeline 必须维护内部状态（可能是进行一些聚合），则最好使状态可用于查询。我们首先看看当我们使状态可查询以及何时查询时，在 Flink 内部的整体步骤。

基于时间的状态访问限制和自动状态清理是有状态流处理领域的常见挑战。随着 1.6.0 版本发布，Apache Flink 引入了第一个 State TTL 实现来解决这些问题。在当前版本中，状态 TTL 保证在配置超时后状态不可访问，以符合 GDPR 或任何其他数据合规性规则。Flink 社区正在开发多个扩展，以在未来版本中改进和扩展 State TTL 功能。

在 Flink 1.13 版本之前，StateBackend 提供了三个开箱即用的 StateBackend：MemoryStateBackend、FsStateBackend 以及 RocksDBStateBackend。该版本下的 StateBackend 把状态存储(如何在 TM 上本地存储和访问状态)和 Checkpoint 持久化(Checkpoint 如何持久化状态)笼统的混在一起，导致初学者对此感觉很混乱，很难理解。