zhengzaifeidelushang的博客

由 Flink 管理的 keyed state 是一种分片的键/值存储，每个 keyed state 的工作副本都保存在负责该键的 taskmanager 本地中。Checkpoint n 将包含每个 operator 的 state，这些 state 是对应的 operator 消费了严格在 checkpoint barrier n 之前的所有事件，并且不包含在此（checkpoint barrier n）后的任何事件后而生成的状态。相反，这意味着 每一个事件都会影响 Flink 管理的状态精确一次。

Kubernetes 是一种流行的容器编排系统，用于自动化计算机应用程序的部署、扩展和管理。Flink 的原生 Kubernetes 集成允许您直接在正在运行的 Kubernetes 集群上部署 Flink。此外，由于 Flink 可以直接与 Kubernetes 通信，因此它能够根据所需资源动态分配和取消分配 TaskManager。Apache Flink 还提供了一个 Kubernetes 运算符，用于管理 Kubernetes 上的 Flink 集群。

Apache Hadoop YARN 是许多数据处理框架中流行的资源提供者。Flink 服务提交给 YARN 的 ResourceManager，后者在由 YARN NodeManagers 管理的机器上生成容器。Flink 将其 JobManager 和 TaskManager 实例部署到此类容器中。Flink 可以根据在 JobManager 上运行的作业所需的处理槽数量动态分配和取消分配 TaskManager 资源。

独立模式是 Flink 最简单的部署模式。本简短指南将向您展示如何下载、安装和运行 Flink 的最新稳定版本。您还将运行一个示例 Flink CDC 作业并在 Web UI 中查看它。

用户定义函数 (UDF) 可用于转换规则。实现 org.apache.flink.cdc.common.udf.UserDefinedFunction 接口具有无参数的公共构造函数至少有一个名为 eval 的公共方法覆盖 getReturnType 方法以指示其返回 CDC 类型覆盖 open 和 close 方法以执行一些初始化和清理工作@Override@Override// ...@Override// ...

Route 指定匹配一串 source-table 到 sink-table 的规则，最典型的场景是分库分表合并，将多个上游 source 表路由到同一张 sink 表。然后，所有表（包括 source_db.XXX）都将被轻松路由到 sink_db.XXX。

数据接收器用于应用架构更改并将更改数据写入外部系统。数据接收器可以同时写入多个表。

数据源用于访问元数据并从外部系统读取更改的数据。数据源可以同时从多个表读取数据。

通过保存作业状态的快照，Flink能够保证作业的一致性，并提供了高可用性和高效率的保存和恢复机制。冷启动和部署：可以使用检查点来实现作业的冷启动，即在作业启动时，从最近的检查点恢复状态和数据，并从上一次检查点的位置继续处理。当窗口中的数据过期时，Flink会自动丢弃这些数据，从而保持窗口中的数据只包含最新的和有效的内容。容错和故障恢复：Checkpoint可以将作业的状态和数据进行持久化，当发生故障时，Flink可以使用最近的检查点来恢复作业的状态和数据，从而避免数据丢失，并继续处理未完成的任务。

从概念上讲，Flink 的 savepoints 与 checkpoints 的不同之处类似于传统数据库系统中的备份与恢复日志之间的差异。Checkpoints 的主要目的是为意外失败的作业提供恢复机制。Checkpoint 的生命周期 由 Flink 管理， 即 Flink 创建，管理和删除 checkpoint - 无需用户交互。由于 checkpoint 被经常触发，且被用于作业恢复，所以 Checkpoint 的实现有两个设计目标：i）轻量级创建和 ii）尽可能快地恢复。

然而，当 Flink 作业正运行在严重的背压下时，Checkpoint 端到端延迟的主要影响因子将会是传递 Checkpoint Barrier 到 所有的算子/子任务的时间。在启动时，每个 Checkpoint 仍然是 aligned checkpoint，但是当全局 Checkpoint 持续时间超过 aligned-checkpoint-timeout 时， 如果 aligned checkpoint 还没完成，那么 Checkpoint 将会转换为 Unaligned Checkpoint。

导致该的问题原因是， Flink 会在用来恢复的 checkpoint 之上创建增量的 checkpoint，因此后续的 checkpoint 都有可能会依赖于用于恢复的那个 checkpoint。因此，Savepoint 对精确一次的接收器有副作用，为了确保精确一次的语义，如果在最后一个 Savepoint 之后没有 Checkpoint ，那么将使用 Savepoint 进行恢复。这将触发 ID 为 :jobId 的作业的 Savepoint，并返回创建的 Savepoint 路径。

Checkpoint 使 Flink 的状态具有良好的容错性，通过 checkpoint 机制，Flink 可以对作业的状态和计算位置进行恢复。

Elasticsearch 将文档存储在 JSON 字符串中。因此数据类型映射介于 Flink 数据类型和 JSON 数据类型之间。Flink 为 Elasticsearch 连接器使用内置的 ‘json’ 格式。下表列出了 Flink 中的数据类型与 JSON 中的数据类型的映射关系。

在 Flink 中，当查询由 Postgres catalog 注册的表时，用户可以使用 schema_name.table_name 或只有 table_name，其中 schema_name 是可选的，默认值为 “public”。在 Flink 中，当查询由 MySQL catalog 注册的表时，用户可以使用 database.table_name 或只使用 table_name，其中 database 是可选的，默认值为创建 MySQL Catalog 时指定的默认数据库。其他方法目前尚不支持。

更准确地说，数据记录中的 value 被解释为同一 key 的最后一个 value 的 UPDATE，如果有这个 key（如果不存在相应的 key，则该更新被视为 INSERT）。总之，这段代码的作用是通过Kafka连接器创建两个表，并将"pageviews"表中的数据计算出每个地区的pv和uv，并插入到"pageviews_per_region"表中。这段代码是用来创建两个表，一个是"pageviews_per_region"，另一个是"pageviews"，并定义了它们的结构和连接器。

例如在 SQL client JAR 中，Kafka client 依赖被重置在了 org.apache.flink.kafka.shaded.org.apache.kafka 路径下， 因此 plain 登录模块的类路径应写为 org.apache.flink.kafka.shaded.org.apache.kafka.common.security.plain.PlainLoginModule。由于 Kafka 消息中消息键是可选的，以下语句将使用消息体格式读取和写入消息，但不使用消息键格式。

输出字符串格式为 “$row_kind(f0,f1,f2…)“，row_kind是一个 RowKind 类型的短字符串，例如：”+I(1,1)"。注意 在任务运行时使用 Print Sinks 打印记录，你需要注意观察任务日志。Print 连接器允许将每一行写入标准输出流或者标准错误流。或者，也可以通过 LIKE子句 基于已有表的结构去创建新表。Print 连接器是内置的。

这也意味着，在非正常情况下，Debezium 可能会投递重复的变更事件到 Kafka 中，当 Flink 从 Kafka 中消费的时候就会得到重复的事件。请使用 debezium-avro-confluent 来解析 Debezium 的 Avro 消息，使用 debezium-json 来解析 Debezium 的 JSON 消息。使用时，可以在 Flink 的配置文件或在代码中通过设置相应的属性来指定 “table.exec.source.cdc-events-duplicate” 的值。

为了使用 Json 格式，使用构建自动化工具（例如 Maven 或 SBT）的项目和带有 SQL JAR 包的 SQL 客户端都需要以下依赖项。JSON Format 能读写 JSON 格式的数据。当前，JSON schema 是从 table schema 中自动推导而得的。不支持显式地定义 JSON schema。在 Flink 中，JSON Format 使用 jackson databind API 去解析和生成 JSON。下表列出了 Flink 中的数据类型与 JSON 中的数据类型的映射关系。

然后，你可以将原始数据读取为纯字符串，之后使用用户自定义函数将其分为多个字段进行进一步分析。例如 示例中的 my_split。相对应的，你也可以将一个 STRING 类型的列以 UTF-8 编码的匿名字符串值写入 Kafka topic。例如，你可能在 Kafka 中具有原始日志数据，并希望使用 Flink SQL 读取和分析此类数据。下表详细说明了这种格式支持的 SQL 类型，包括用于编码和解码的序列化类和反序列化类的详细信息。

自定义函数（UDF）是一种扩展开发机制，可以用来在查询语句里调用难以用其他方式表达的频繁使用或自定义的逻辑。自定义函数可以用 JVM 语言（例如 Java 或 Scala）或 Python 实现，实现者可以在 UDF 中使用任意第三方库，本文聚焦于使用 JVM 语言开发自定义函数。标量函数 将标量值转换成一个新标量值；表值函数 将标量值转换成新的行数据；聚合函数 将多行数据里的标量值转换成一个新标量值；表值聚合函数 将多行数据里的标量值转换成新的行数据；

Flink Web 界面提供了一个选项卡来监控正在运行 jobs 的反压行为。

摘要计算了所有已完成 checkpoint 的端到端持续时间、增量/全量Checkpoint 数据大小和 checkpoint alignment 期间缓冲的字节数的简单 min/average/maximum 统计信息。请注意，这些统计信息不会在 JobManager 丢失后无法保存，如果 JobManager 故障转移，这些统计信息将重新计数。

应用程序需要能够可靠地创建 checkpoints。在应用故障后，需要有足够的资源追赶数据输入流。第一部分讨论如何大规模获得良好性能的 checkpoints。后一部分解释了一些关于要规划使用多少资源的最佳实践。限制：目前，task 本地恢复仅涵盖 keyed state backends。Keyed state 通常是该状态的最大部分。在不久的将来，我们还将支持算子状态和计时器（timers）。以下 state backends 可以支持 task 本地恢复。

定期压缩可以加快过期状态条目的清理速度，特别是对于很少访问的状态条目。您可以将其设置为 0 以关闭定期压缩，或设置一个较小的值以加速过期状态条目清理，但它会触发更多压缩。在 NeverReturnExpired 的情况下，过期状态的行为就好像它不再存在一样，即使它仍然需要被删除。默认情况下，过期值会在读取时显式删除，例如 ValueState#value，并在配置的状态后端支持的情况下定期在后台进行垃圾收集。在当前实现下，本地状态不会被清除，但在从以前的快照恢复时，它不会包括删除的过期状态。

注意： 为了更好地理解窗口行为，这里把 timestamp 值后面的0去掉了。例如：在 Flink SQL Client 中，如果类型是 TIMESTAMP(3) ，2020-04-15 08:05 应该显示成 2020-04-15 08:05:00.000。下面的示例展示了在10分钟的滚动窗口上保持最后一条记录。

例如：在 Flink SQL Client 中，如果类型是 TIMESTAMP(3) ，2020-04-15 08:05 应该显示成 2020-04-15 08:05:00.000。例如：在 Flink SQL Client 中，如果类型是 TIMESTAMP(3) ，2020-04-15 08:05 应该显示成 2020-04-15 08:05:00.000。这条Flink SQL查询的目标是在表Bid中根据时间窗口对数据进行分组，并找出每个窗口内价格最高的三个供应商。

Top-N 查询是结果更新的. Flink SQL会根据ORDER BY的字段对输入的数据流进行排序，所以如果前 N 条记录发生了变化，那么变化后的记录将作为回撤/更新记录发送到下游。此外，如果 Top-N 条记录需要存储在外部存储中，结果表应该与Top-N查询的唯一键保持一致。Top-N 查询也可以获取上游的唯一键。用下面的 job 举例:比如 product_id 是 ShopSales 的唯一键，这时 Top-N 查询的唯一键是[category, rownum] 和 [product_id]。

ORDER BY 子句使结果行根据指定的表达式进行排序。如果两行根据最左边的表达式相等，则根据下一个表达式进行比较，依此类推。如果根据所有指定的表达式它们相等，则它们以与实现相关的顺序返回。在流模式下运行时，表的主要排序顺序必须按时间属性升序。所有后续的 orders 都可以自由选择。但是批处理模式没有这个限制。

优化器会把 EXIST 重写为 join 和 group 操作.对于流式查询，计算查询结果所需的状态可能会根据输入行数而无限增长。你可以设置一个合适的状态 time-to-live（TTL）来淘汰过期数据以防止状态过大。对于流式查询，计算查询结果所需的状态可能会根据输入行数而无限增长。你可以设置一个合适的状态 time-to-live（TTL）来淘汰过期数据以防止状态过大。如果表达式（可以是列，也可以是函数等）存在于子查询的结果中，则返回 true。UNION 会去重，UNION ALL 不会去重。

注意 Temporal join 不支持与 table/view 的最新版本进行 join 时使用 FOR SYSTEM_TIME AS OF 语法是出于语义考虑，因为左流的连接处理不会等待 temporal table 的完整快照，这可能会误导生产环境中的用户。时态表包含一个或多个版本的表快照，它可以是一个变化的历史表，跟踪变化（例如，数据库变化日志，包含所有快照）或一个变化的维度表，也可以是一个将变更物化的维表（例如，存放最终快照的数据表）。默认情况下，joins 的顺序是没有优化的。

范围（RANGE）定义指定了聚合中包含了多少行数据。范围通过 BETWEEN 子句定义上下边界，其内的所有行都会聚合。Flink 只支持 CURRENT ROW 作为上边界。有两种方法可以定义范围：ROWS 间隔 和 RANGE 间隔。

像大多数数据系统一样，Apache Flink支持聚合函数；包括内置的和用户定义的。用户自定义函数在使用前必须在目录中注册。聚合函数把多行输入数据计算为一行结果。例如，有一些聚合函数可以计算一组行的 “COUNT”、“SUM”、“AVG”（平均）、“MAX”（最大）和 “MIN”（最小）。对于流式查询，重要的是要理解 Flink 运行的是连续查询，永远不会终止。而且它们会根据其输入表的更新来更新其结果表。对于上述查询，每当有新行插入 Orders 表时，Flink 都会实时计算并输出更新后的结果。

和普通的 GROUP BY 子句一样，包含分组窗口函数的 GROUP BY 子句的查询会对各组分别计算，各产生一个结果行。使用 GROUPING SETS 的窗口聚合要求 window_start 和 window_end 列必须位于 GROUP BY 子句中，但不能位于 GROUPING SETS 子句中。使用 CUBE 的窗口聚合要求 window_start 和 window_end 列必须位于 GROUP BY 子句中，但不能位于 CUBE 子句中。CUBE 是用于指定常见类型的分组集的简写符号。

Windows 是处理无限流的核心。Windows 将流分割成有限大小的“桶”，我们可以在其中应用计算。本文档重点介绍 Flink SQL 中如何执行窗口以及程序员如何从其提供的功能中获得最大收益。请注意，每个元素在逻辑上可以属于多个窗口，具体取决于您使用的窗口表值函数。例如，HOP 开窗创建重叠窗口，其中单个元素可以分配给多个窗口。窗口 TVF 是 Fl​​ink 定义的多态表函数（缩写为 PTF）。PTF 是 SQL 2016 标准的一部分，是一种特殊的表函数，但可以将表作为参数。

select_list 规范 * 表示查询将解析所有列。但是，在生产中不鼓励使用 *，因为它会使查询对目录更改的鲁棒性降低。相反，select_list 可以指定可用列的子集或使用所述列进行计算。它可以是现有表、视图或 VALUES 子句、多个现有表的联接结果或子查询。假设该表在目录中可用，以下代码将从 Orders 中读取所有行。查询还可以使用 VALUES 子句使用内联数据。此外，可以在单行的列上调用内置和用户定义的标量函数。用户定义的函数在使用前必须注册到目录中。可以基于 WHERE 子句过滤行。

Flink系列之：WITH clause

查询块是SQL的基本单元。例如，任何内联视图或 SQL 语句的子查询都被视为与外部查询不同的查询块。例子：一条 SQL 语句可以由多个子查询组成。子查询可以是 SELECT、INSERT 或 DELETE。子查询可以在 FROM 子句、WHERE 子句或 UNION 或 UNION ALL 的子查询中包含其他子查询。对于这些不同的子查询或视图类型，它们可以由多个查询块组成，例如：下面的简单查询只有一个子查询，但它有两个查询块 - 一个用于外部 SELECT，另一个用于子查询 SELECT。

SELECT 语句和 VALUES 语句是使用 TableEnvironment 的 sqlQuery() 方法指定的。该方法以表的形式返回 SELECT 语句（或 VALUES 语句）的结果。Table 可以在后续的 SQL 和 Table API 查询中使用、转换为 DataStream 或写入 TableSink。SQL 和 Table API 查询可以无缝混合，并进行整体优化并转换为单个程序。为了在 SQL 查询中访问表，它必须在 TableEnvironment 中注册。