京河小蚁的博客

大家都知道Flink中算子都是通过序列化分发到各节点上，所以要确保算子对象是可以被序列化的，很多时候大家比较喜欢直接用匿名内部类实现算子，而匿名内部类就会带来闭包问题，当匿名内部类引用的外部对象没有实现序列化接口时，就会导致内部类无法被序列化，因此Flink框架底层必须做好清除工作，直接调用到环境类，这个clean方法，几乎所有的算子都是从这里调用clean方法的，当然除了一些框架本身的调用哈。在咱们看上面文章的时候，看到的那些算子源码里面总会用到clean()，业界称为闭包清除。

先说一下两者的最大区别，window可以设置并行度，windowAll reduce始终并行度为1，且不能更改。上来就进入到KeyedStream类，然后再new WindowedStream(this,assigner).将上面的程序运行起来之后，可以看到print出来的数据，windowAll的reduce 任务始终为1。调用WindowedStream构造器。

reduce对键控数据流的“滚动”统计或者计算。将当前元素与最后减少的值合并并发出新值。普通reduce窗口reduce1、keyBy() -> reduce 算子组合，会计算历史以来所有数据的和，每过来一条数据，就输出一次结果；2、window()->reduce 算子组合，计算的是window窗口内的数据和（也就是一定时间内的数据统计），每次窗口触发的时候，才会输出一次结果。

我们可以看到KeyedStream和filter、map、flatMap算子有差异了，keyBy算子没有使用DataStream,而是另起了一个继承于DataStream的类 KeyedStream。值得一提的是，有些同学说源码生涩难懂，其实不是，你看上面if判断里的东西其实都是咱们学过的继承多态等基础知识，filter调的其实也是用户代码实现的filter。同时，KeySelector选择器也不一样，它返回的是一个KEY。上面代码没有实际业务含义，就是最简单的应用，目的是为了看其源码。

flink map和flatmap算子源码解析

Flink DataStream API 为用户提供了3个算子来实现双流 join，分别是：1、join()；3、intervalJoin(), 另外其实还有两个算子，connect()和union()

鉴于之前已经有粗略的看过，大量知识点可能是复习一下，并且下钻深度，所以给自己规划做完下面脑图中的工作量的时间截止日期为2023年的1月1日，如果中途有不可抗力因素阻碍，时间按照耽误的时间往后推，但是最晚时间截止到春节。之前也写了很多关于Flink的文章，但是总是“瞎写”，为了更加充分的利用好业余时间，花了一晚上的时间，专门整理了一份关于Flink的知识点脑图，图中写到的知识点，计划着深入理解一下。凛冬散尽，星河长明。凡是过往，皆为序章。以梦为马，不负韶华。文章难免会有纰漏，若发现问题，欢迎指正与批评！

最后，提醒一下看源码的小伙伴们，最好看下test目录下的测试类，flink源码中提供了很多测试类，可以细节到具体的方法，所以值得一看。

这玩意，让我丢了一次面，搞它。

广义的概念上，能够捕获数据变更的技术，我们都可以称为CDC （Change Data Capture）。通常我们说的CDC技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。其实我觉得数仓分为实时和离线最好的状态（个人想法）。meetup看了两遍，第一遍感觉听着讲change log那节，比较晦涩，今天又全部听了一遍，感觉对checkpoint的历史节点上优化又有了更深一步的理解。

看了flink-rpc之后，感觉rpc框架真的是太强大了，比如netty、akka，之前基于akka写过一个能够处理千万级实时数据量的处理系统，netyy的话之前也是了解一点，但是对于rpc思想理解上总是感觉差点什么，于是决定跟着老师们，详细的学习下rpc是什么，怎么用，如何能够用好，开始一步一步的手撸吧。...

如果1.15.0/1的行为是可以接受的，因为它是一个稳定的环境。参见[FLINK-28861]https://issues.apache.org/jira/browse/FLINK-28861了解更多信息。有关所有更改的完整列表，请参见:[JIRA] https://issues.apache.org/jira/secure/ReleaseNote.jspa?您可以在更新的下载页面上找到[二进制文件]https://flink.apache.org/downloads.html。.........

执行图是在JobManager生成的,且在创建JobMaster的过程中创建的。本篇是基于per job模式client生成JobGraph之后，就通过submitJob提交给JobManager，JobManager会根据JobGraph生成对应的ExecutionGraph。ExecutionGraph 是Flink作业调度时使用到的核心数据结构，它包含每一个并行的task，每一个intermediate stream以及它们之间的关系。

接上面接着往下面看jobgraph是如何生成的？又经历了哪些转换？

StreamGraph 经过优化后生成了JobGraph，提交给Jobmanager的数据结构，主要的优化为，将多个符合条件的节点 chain在一起作为一个节点，这样可以减少数据在节点之间流动所需要的序列化/反序列化/传输消耗。JobManager根据Execution对job进行调度后，在各个TaskManager上部署Task后形成的图，并不是一个具体的数据结构。JobManager根据JobGraph生成的。是根据用户代码通过Stream API编写的代码生成的最初的图。用来表示程序的拓扑结构。...

Flink 组件通信 RPC通信过程概览图

根据官网和源码中可知，目前PER_JOB模式已经被官悬弃用，后面可能会被完全剔除，替代的是APPLICATION模式两种模式好处都是资源隔离，APPLICATION模式把main方法的初始化放到了集群组件的jobmanager，这样有对于客户端来说，从性能上有了很大的优化。通过比较看两者的源码，才更能体会到APPLICATION模式替代PER_JOB的优点。从execute方法开始读源码。如果想读StreamExecutionEnvironment#execute之前的部分，请参照另一篇Flink1.15

上面介绍了flinkrun相关的命令，下面是客户端模式，分为三种GenericCLI、FlinkYarnSessionCLI和DefaultCLI。

for循环中顺序的取出之前存到集合中的三个客户端，根据cli.isActive(commandLine)这个方法检查，第一个活跃的客户端并立即返回，因为默认的客户端active总是true，从下面代码可以看出。configuration.getOptional(DeploymentOptions.TARGET).isPresent()TARGET是否存在。DefaultCLI#isActive总是true，所以默认客户端总是兜底的。从上面注释中，很容易看出该方法是干什么的，获取活跃的命令行客户端；.....

接上一篇讲到flink-clients调试，接着阅读更详细的源码，很枯燥，慢慢读。参考链接https//blog.51cto.com/u_13870740/5321778，讲解的很好。

本文将详细介绍下flink中的自定义注解模块，了解flink注解的作用与使用。主要围绕flink源码中的 flink-annotations模块，与docs 相关的注解有@ConfigGroup和@ConfigGroups , 通常作用于配置类上；@Documentation.OverrideDefault、@Documentation.Section、@Documentation.TableOption、@Documentation.SuffixOption,@Documentation.ExcludeF

在flink的bin目录下找到一个flink脚本，使用vim命令打开如下内容CliFrontend(客户端启动类)从上面客户端启动脚本，紧接着去代码中查看org.apache.flink.client.cli.CliFrontend 这个类。如果没有编译成功，请自行操作，也可参考小编之前写过的两篇文章（地址就不贴了）。这一节有参考博客。根据上面截图，提交flink app程序入口找到了，我们先来调试下，ide基于idea version2021.1直接debug main方法，如下图所示退出co

以下章节描述了如何将 Flink 项目导入到 IDE 中以进行 Flink 本身的源码开发。有关 Flink 程序编写的信息，请参阅 Java API 和 Scala API 快速入门指南。每当你的 IDE 无法正常工作时，请优先尝试使用 Maven 命令行（mvn clean package -DskipTests），因为它可能是由于你的 IDE 中存在错误或未正确设置。要开始，请首先从我们的库中下载Flink源代码，例如。以下指南是为IntelliJ IDEA 2020.3编写的。一些细节在其他版本中

Flink通过org.apache.flink.core.fs.FileSystem类拥有自己的文件系统抽象。这种抽象提供了一组通用操作，并为各种类型的文件系统实现提供了最低限度的保证。为了支持广泛的文件系统，FileSystem的可用操作集非常有限。例如，不支持追加或修改现有文件。文件系统由文件系统方案来标识，如File://， hdfs://等。Flink直接实现文件系统，其文件系统方案如下:文件，它表示机器的本地文件系统。其他文件系统类型通过连接到Apache Hadoop支持的文件系统套件的实现来

Task 是 Flink 的基本执行单元。算子的每个并行实例都在 task 里执行。例如，一个并行度为 5 的算子，它的每个实例都由一个单独的 task 来执行。StreamTask 是 Flink 流式计算引擎中所有不同 task 子类的基础。本文会深入讲解 StreamTask 生命周期的不同阶段，并阐述每个阶段的主要方法。因为 task 是算子并行实例的执行实体，所以它的生命周期跟算子的生命周期紧密联系在一起。因此，在深入介绍 StreamTask 生命周期之前，先简要介绍一下代表算子生命周期的基本方

这篇文档简要描述了 Flink 怎样调度作业, 怎样在 JobManager 里描述和追踪作业状态。Flink 通过 Task Slots 来定义执行资源。每个 TaskManager 有一到多个 task slot，每个 task slot 可以运行一条由多个并行 task 组成的流水线。 这样一条流水线由多个连续的 task 组成，比如并行度为 n 的 MapFunction 和 并行度为 n 的 ReduceFunction。需要注意的是 Flink 经常并发执行连续的 task，不仅在流式作业中到处

Flink的web界面提供了一个选项卡来监视作业的检查点。这些统计数据在作业终止后也可用。有四个不同的选项卡显示关于检查点的信息:Overview, History, Summary, and Configuration。以下部分将依次介绍所有这些内容。概览选项卡列出了以下统计信息。请注意，这些统计数据不会在JobManager丢失后继续存在，并且在JobManager故障转移时将被重置为。检查点历史记录保存关于最近触发的检查点的统计信息，包括当前正在进行的检查点。注意，对于失败的检查点，度量标准是在最佳

Flink 的事件时间和 watermark 支持对于处理乱序事件是十分强大的特性。然而，由于是系统内部跟踪时间进度，所以很难了解究竟正在发生什么。可以通过 Flink web 界面或指标系统访问 task 的 low watermarks。Flink 中的 task 通过调用 currentInputWatermark 方法暴露一个指标，该指标表示当前 task 所接收到的 the lowest watermark。这个 long 类型值表示“当前事件时间”。该值通过获取上游算子收到的所有 waterma

Flink DataStream API 和 Table / SQL 都支持通过批处理执行模式处理有界输入。此模式是通过 blocking shuffle 进行网络传输。与流式应用使用管道 shuffle 阻塞交换的数据并存储，然后下游任务通过网络获取这些值的方式不同。这种交换减少了执行作业所需的资源，因为它不需要同时运行上游和下游任务。总的来说，Flink 提供了两种不同类型的 blocking shuffles：Hash shuffle 和 Sort shuffle。对于 1.14 以及更低的版本，Ha

Checkpoint 使 Flink 的状态具有良好的容错性，通过 checkpoint 机制，Flink 可以对作业的状态和计算位置进行恢复。参考 Checkpointing 查看如何在 Flink 程序中开启和配置 checkpoint。要理解检查点和保存点之间的区别，请参阅检查点和保存点。Checkpoint 在默认的情况下仅用于恢复失败的作业，并不保留，当程序取消时 checkpoint 就会被删除。当然，你可以通过配置来保留 checkpoint，这些被保留的 checkpoint 在作业失败或取

官网日志地址本章内容基于flink1.7 ，log4j1.x依赖

通过在 conf/flink-conf.yaml 中配置一个或多个报告器，可以向外部系统公开指标。这些报告器将在启动时在每个作业和任务管理器上实例化。所有报告者必须至少具有类或工厂.class属性。可以/应该使用哪个属性取决于报告器实现。有关详细信息，请参阅各个报告器配置部分。某些报告器（称为“计划”）允许指定报告间隔。下面将列出特定于每个报告器的更多设置。指定多个报告器的示例报告器配置要点:当Flink启动时，包含reporter程序的jar必须是可访问的。支持factory.class属性的记者可以作

JobManager 高可用（HA）模式加强了 Flink 集群防止 JobManager 故障的能力。 此特性确保 Flink 集群将始终持续执行你提交的作业。JobManager 协调每个 Flink 的部署。它同时负责 调度 和 资源管理。默认情况下，每个 Flink 集群只有一个 JobManager 实例。这会导致 单点故障（SPOF）：如果 JobManager 崩溃，则不能提交任何新程序，运行中的程序也会失败。使用 JobManager 高可用模式，你可以从 JobManager 失败中恢复，

具体参考官网地址

本页介绍细粒度资源管理的用法、适用场景及其工作原理。注意：此功能目前是 MVP（“最小可行产品”）功能，仅适用于 DataStream API。可能受益于细粒度资源管理的典型方案包括：在如何提高资源效率中，深入探讨了细粒度资源管理如何提高上述场景的资源效率。如 Flink 架构中所述，任务管理器中的任务执行资源被拆分为多个槽。该槽是 Flink 运行时中资源调度和资源需求的基本单位。通过细粒度资源管理，槽请求包含用户可以指定的特定资源配置文件。Flink 将尊重用户指定的资源要求，并从 TaskManag

这个文档描述了那些可以使 Flink 自动调整并行度的选项。Reactive 模式是一个 MVP （minimum viable product，最小可行产品）特性。目前 Flink 社区正在积极地从邮件列表中获取用户的使用反馈。请注意文中列举的一些局限性。在 Reactive 模式下，Job 会使用集群中所有的资源。当增加 TaskManager 时，Job 会自动扩容。当删除时，就会自动缩容。Flink 会管理 Job 的并行度，始终会尽可能地使用最大值。当发生扩缩容时，Job 会被重启，并且会从最新的

Flink 提供了一个命令行界面 （CLI） bin/flink 来运行打包为 JAR 文件的程序并控制其执行。CLI 是任何 Flink 设置的一部分，可在本地单节点设置和分布式设置中使用。它连接到在conf/flink-conf.yaml中指定的正在运行的JobManager。本节中列出的命令工作的先决条件是运行 Flink 部署，如 Kubernetes、YARN 或任何其他可用的选项。您可以随意在本地启动 Flink 集群，在您自己的机器上尝试这些命令。提交作业意味着将作业的 JAR 和相关依赖项上

Apache Flink 基于 JVM 的高效处理能力，依赖于其对各组件内存用量的细致掌控。 考虑到用户在 Flink 上运行的应用的多样性，尽管社区已经努力为所有配置项提供合理的默认值，仍无法满足所有情况下的需求。 为了给用户生产提供最大化的价值， Flink 允许用户在整体上以及细粒度上对集群的内存分配进行调整。为了优化内存需求，参考网络内存调优指南。本文接下来介绍的内存配置方法适用于 1.10 及以上版本的 TaskManager 进程和 1.11 及以上版本的 JobManager 进程。 Flin

所有的配置都在conf/flink-conf.yaml里面设置，预计将是YAML 键值对格式的平面集合key: value。当 Flink 进程启动时，配置会被解析和评估。更改配置文件需要重新启动相关进程。开箱即用的配置将使用您的默认 Java 安装。如果要手动覆盖要使用的 Java 运行时，可以手动设置环境变量JAVA_HOME或配置键env.java.home。conf/flink-conf.yamlFLINK_CONF_DIR您可以通过定义环境变量来指定不同的配置目录位置。对于提供非会话部署的资源提供

Resource Providers有以下三种：本文正是要将yarn，其他两个在Flink官网可查看。本入门部分将指导您在 YARN 上设置功能齐全的 Flink 集群。Apache Hadoop YARN是一个在许多数据处理框架中流行的资源提供程序。Flink 服务提交给 YARN 的 ResourceManager，它在 YARN NodeManager 管理的机器上生成容器。Flink 将其 JobManager 和 TaskManager 实例部署到此类容器中。Flink 可以根据 JobManag