Flink-官方文档笔记

Flink-Boot

intsmaze/flink-boot: 懒松鼠Flink-Boot 脚手架让Flink全面拥抱Spring生态体系

Sink

流处理中的sink是指将处理结果输出到外部系统的组件，例如将处理结果写入数据库、发送到消息队列、输出到文件等。sink是流处理中的最后一步，完成了数据的整个流程，让处理结果得以持久化或最终展示给用户。

Java的sink主要通过Stream API提供，常用的sink有：输出到集合、输出到文件、写入数据库等。以下是一个输出到集合的示例代码：

List<Integer> list = new ArrayList<Integer>();
Stream.of(1, 2, 3, 4, 5)
      .filter(i -> i % 2 == 0)
      .forEach(list::add);
System.out.println(list);

这段代码将1~5中的偶数输出，并将结果存储到一个ArrayList中作为sink。

而在Flink中，sink是用于将数据写入外部系统的组件，如将数据写入Kafka、Hadoop、Cassandra等。Flink中的sink在数据流处理过程中扮演着关键的角色，决定了流处理结果的输出方式。以下是一个输出到Kafka的示例代码：

public static void main(String[] args) throws Exception {
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

    Properties properties = new Properties();
    properties.setProperty("bootstrap.servers", "localhost:9092");
    properties.setProperty("topic", "test");

    DataStream<String> stream = env.socketTextStream("localhost", 9999);

    stream.addSink(new FlinkKafkaProducer011<>("localhost:9092", "test", new SimpleStringSchema()));

    env.execute();
}

在这个示例中，数据源来自Socket，数据被处理后通过FlinkKafkaProducer011写入到Kafka中，Kafka作为sink持久化了流处理的结果。

总的来说，sink是流处理中的核心组件之一。Java和Flink都提供了丰富的sink组件用于不同的使用场景，开发者应根据实际需求选择最佳的sink组件。

重点：事件、时间、快照、状态

Event

Flink 明确支持以下三种时间语义:

• 事件时间(event time)： 事件产生的时间，记录的是设备生产(或者存储)事件的时间
• 摄取时间(ingestion time)： Flink 读取事件时记录的时间
• 处理时间(processing time)： Flink pipeline 中具体算子处理事件的时间

waterMarks

watermarks 的作用 — 它们定义何时停止等待较早的事件。

Window

用 Flink 计算窗口分析取决于两个主要的抽象操作：Window Assigners，将事件分配给窗口（根据需要创建新的窗口对象），以及 Window Functions，处理窗口内的数据。

Flink 的窗口 API 还具有 Triggers 和 Evictors 的概念，Triggers 确定何时调用窗口函数，而 Evictors 则可以删除在窗口中收集的元素。

窗口

• 滚动时间窗口
  • 每分钟页面浏览量
  • TumblingEventTimeWindows.of(Time.minutes(1))
• 滑动时间窗口
  • 每10秒钟计算前1分钟的页面浏览量
  • SlidingEventTimeWindows.of(Time.minutes(1), Time.seconds(10))
• 会话窗口
  • 每个会话的网页浏览量，其中会话之间的间隔至少为30分钟
  • EventTimeSessionWindows.withGap(Time.minutes(30))

State

Flink 管理的状态存储在 state backend 中。Flink 有两种 state backend 的实现 – 一种基于 RocksDB 内嵌 key/value 存储将其工作状态保存在磁盘上的，另一种基于堆的 state backend，将其工作状态保存在 Java 的堆内存中。这种基于堆的 state backend 有两种类型：FsStateBackend，将其状态快照持久化到分布式文件系统；MemoryStateBackend，它使用 JobManager 的堆保存状态快照。

名称	Working State	状态备份	快照
RocksDBStateBackend	本地磁盘（tmp dir）	分布式文件系统	全量 / 增量
支持大于内存大小的状态经验法则：比基于堆的后端慢10倍
FsStateBackend	JVM Heap	分布式文件系统	全量
快速，需要大的堆内存受限制于 GC
MemoryStateBackend	JVM Heap	JobManager JVM Heap	全量
适用于小状态（本地）的测试和实验

当使用基于堆的 state backend 保存状态时，访问和更新涉及在堆上读写对象。但是对于保存在 RocksDBStateBackend 中的对象，访问和更新涉及序列化和反序列化，所以会有更大的开销。但 RocksDB 的状态量仅受本地磁盘大小的限制。还要注意，只有 RocksDBStateBackend 能够进行增量快照，这对于具有大量变化缓慢状态的应用程序来说是大有裨益的。

所有这些 state backends 都能够异步执行快照，这意味着它们可以在不妨碍正在进行的流处理的情况下执行快照。

Checkpoint Storage #

Flink 定期对每个算子的所有状态进行持久化快照，并将这些快照复制到更持久的地方，例如分布式文件系统。 如果发生故障，Flink 可以恢复应用程序的完整状态并恢复处理，就好像没有出现任何问题一样。

这些快照的存储位置是通过作业_checkpoint storage_定义的。 有两种可用检查点存储实现：一种持久保存其状态快照 到一个分布式文件系统，另一种是使用 JobManager 的堆。

名称	状态备份
FileSystemCheckpointStorage	分布式文件系统
支持非常大的状态大小高度可靠推荐用于生产部署
JobManagerCheckpointStorage	JobManager JVM Heap
适合小状态（本地）的测试和实验

确保精确一次（exactly once） #

当流处理应用程序发生错误的时候，结果可能会产生丢失或者重复。Flink 根据你为应用程序和集群的配置，可以产生以下结果：

• Flink 不会从快照中进行恢复（at most once）
• 没有任何丢失，但是你可能会得到重复冗余的结果（at least once）
• 没有丢失或冗余重复（exactly once）

Flink 通过回退和重新发送 source 数据流从故障中恢复，当理想情况被描述为精确一次时，这并不意味着每个事件都将被精确一次处理。相反，这意味着 每一个事件都会影响 Flink 管理的状态精确一次。

Barrier 只有在需要提供精确一次的语义保证时需要进行对齐（Barrier alignment）。如果不需要这种语义，可以通过配置 CheckpointingMode.AT_LEAST_ONCE 关闭 Barrier 对齐来提高性能。

端到端精确一次 #

为了实现端到端的精确一次，以便 sources 中的每个事件都仅精确一次对 sinks 生效，必须满足以下条件：

1. 你的 sources 必须是可重放的，并且
2. 你的 sinks 必须是事务性的（或幂等的）

Flink 中的 API #

Flink 为流式/批式处理应用程序的开发提供了不同级别的抽象。

• Flink API 最底层的抽象为有状态实时流处理。其抽象实现是 Process Function，并且 Process Function 被 Flink 框架集成到了 DataStream API 中来为我们使用。它允许用户在应用程序中自由地处理来自单流或多流的事件（数据），并提供具有全局一致性和容错保障的状态。此外，用户可以在此层抽象中注册事件时间（event time）和处理时间（processing time）回调方法，从而允许程序可以实现复杂计算。

• Flink API 第二层抽象是 Core APIs。实际上，许多应用程序不需要使用到上述最底层抽象的 API，而是可以使用 Core APIs 进行编程：其中包含 DataStream API（应用于有界/无界数据流场景）和 DataSet API（应用于有界数据集场景）两部分。Core APIs 提供的流式 API（Fluent API）为数据处理提供了通用的模块组件，例如各种形式的用户自定义转换（transformations）、联接（joins）、聚合（aggregations）、窗口（windows）和状态（state）操作等。此层 API 中处理的数据类型在每种编程语言中都有其对应的类。

  Process Function 这类底层抽象和 DataStream API 的相互集成使得用户可以选择使用更底层的抽象 API 来实现自己的需求。DataSet API 还额外提供了一些原语，比如循环/迭代（loop/iteration）操作。

• Flink API 第三层抽象是 Table API。Table API 是以表（Table）为中心的声明式编程（DSL）API，例如在流式数据场景下，它可以表示一张正在动态改变的表。Table API 遵循（扩展）关系模型：即表拥有 schema（类似于关系型数据库中的 schema），并且 Table API 也提供了类似于关系模型中的操作，比如 select、project、join、group-by 和 aggregate 等。Table API 程序是以声明的方式定义应执行的逻辑操作，而不是确切地指定程序应该执行的代码。尽管 Table API 使用起来很简洁并且可以由各种类型的用户自定义函数扩展功能，但还是比 Core API 的表达能力差。此外，Table API 程序在执行之前还会使用优化器中的优化规则对用户编写的表达式进行优化。

  表和 DataStream/DataSet 可以进行无缝切换，Flink 允许用户在编写应用程序时将 Table API 与 DataStream/DataSet API 混合使用。

• Flink API 最顶层抽象是 SQL。这层抽象在语义和程序表达式上都类似于 Table API，但是其程序实现都是 SQL 查询表达式。SQL 抽象与 Table API 抽象之间的关联是非常紧密的，并且 SQL 查询语句可以在 Table API 中定义的表上执行。

Flink架构

集群剖析

Flink 运行时由两种类型的进程组成：一个 JobManager 和一个或者多个 TaskManager。

JobManager #

JobManager 具有许多与协调 Flink 应用程序的分布式执行有关的职责：它决定何时调度下一个 task（或一组 task）、对完成的 task 或执行失败做出反应、协调 checkpoint、并且协调从失败中恢复等等。这个进程由三个不同的组件组成：

• ResourceManager

  ResourceManager 负责 Flink 集群中的资源提供、回收、分配 - 它管理 task slots，这是 Flink 集群中资源调度的单位（请参考TaskManagers）。Flink 为不同的环境和资源提供者（例如 YARN、Kubernetes 和 standalone 部署）实现了对应的 ResourceManager。在 standalone 设置中，ResourceManager 只能分配可用 TaskManager 的 slots，而不能自行启动新的 TaskManager。

• Dispatcher

  Dispatcher 提供了一个 REST 接口，用来提交 Flink 应用程序执行，并为每个提交的作业启动一个新的 JobMaster。它还运行 Flink WebUI 用来提供作业执行信息。

• JobMaster

  JobMaster 负责管理单个JobGraph的执行。Flink 集群中可以同时运行多个作业，每个作业都有自己的 JobMaster。

始终至少有一个 JobManager。高可用（HA）设置中可能有多个 JobManager，其中一个始终是 leader，其他的则是 standby（请参考 高可用（HA））。

TaskManagers #

TaskManager（也称为 worker）执行作业流的 task，并且缓存和交换数据流。

必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 task slot。TaskManager 中 task slot 的数量表示并发处理 task 的数量。请注意一个 task slot 中可以执行多个算子（请参考Tasks 和算子链）。

Tasks 和算子链 #

对于分布式执行，Flink 将算子的 subtasks 链接成 tasks。每个 task 由一个线程执行。将算子链接成 task 是个有用的优化：它减少线程间切换、缓冲的开销，并且减少延迟的同时增加整体吞吐量。链行为是可以配置的；请参考链文档以获取详细信息。

下图中样例数据流用 5 个 subtask 执行，因此有 5 个并行线程。

Back to top

Task Slots 和资源 #

每个 worker（TaskManager）都是一个 JVM 进程，可以在单独的线程中执行一个或多个 subtask。为了控制一个 TaskManager 中接受多少个 task，就有了所谓的 task slots（至少一个）。

每个 task slot 代表 TaskManager 中资源的固定子集。例如，具有 3 个 slot 的 TaskManager，会将其托管内存 1/3 用于每个 slot。分配资源意味着 subtask 不会与其他作业的 subtask 竞争托管内存，而是具有一定数量的保留托管内存。注意此处没有 CPU 隔离；当前 slot 仅分离 task 的托管内存。

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

默认情况下，Flink 允许 subtask 共享 slot，即便它们是不同的 task 的 subtask，只要是来自于同一作业即可。结果就是一个 slot 可以持有整个作业管道。允许 slot 共享有两个主要优点：

• Flink 集群所需的 task slot 和作业中使用的最大并行度恰好一样。无需计算程序总共包含多少个 task（具有不同并行度）。
• 容易获得更好的资源利用。如果没有 slot 共享，非密集 subtask（source/map()）将阻塞和密集型 subtask（window） 一样多的资源。通过 slot 共享，我们示例中的基本并行度从 2 增加到 6，可以充分利用分配的资源，同时确保繁重的 subtask 在 TaskManager 之间公平分配。

Flink 应用程序执行 #

Flink 应用程序 是从其 main() 方法产生的一个或多个 Flink 作业的任何用户程序。这些作业的执行可以在本地 JVM（LocalEnvironment）中进行，或具有多台机器的集群的远程设置（RemoteEnvironment）中进行。对于每个程序，ExecutionEnvironment 提供了一些方法来控制作业执行（例如设置并行度）并与外界交互（请参考 Flink 程序剖析 ）。

Flink 应用程序的作业可以被提交到长期运行的 Flink Session 集群、专用的 Flink Job 集群 或 Flink Application 集群。这些选项之间的差异主要与集群的生命周期和资源隔离保证有关。

Flink Session 集群 #

• 集群生命周期：在 Flink Session 集群中，客户端连接到一个预先存在的、长期运行的集群，该集群可以接受多个作业提交。即使所有作业完成后，集群（和 JobManager）仍将继续运行直到手动停止 session 为止。因此，Flink Session 集群的寿命不受任何 Flink 作业寿命的约束。
• 资源隔离：TaskManager slot 由 ResourceManager 在提交作业时分配，并在作业完成时释放。由于所有作业都共享同一集群，因此在集群资源方面存在一些竞争 — 例如提交工作阶段的网络带宽。此共享设置的局限性在于，如果 TaskManager 崩溃，则在此 TaskManager 上运行 task 的所有作业都将失败；类似的，如果 JobManager 上发生一些致命错误，它将影响集群中正在运行的所有作业。
• 其他注意事项：拥有一个预先存在的集群可以节省大量时间申请资源和启动 TaskManager。有种场景很重要，作业执行时间短并且启动时间长会对端到端的用户体验产生负面的影响 — 就像对简短查询的交互式分析一样，希望作业可以使用现有资源快速执行计算。

以前，Flink Session 集群也被称为 session 模式下的 Flink 集群。

Flink Job 集群 #

• 集群生命周期：在 Flink Job 集群中，可用的集群管理器（例如 YARN）用于为每个提交的作业启动一个集群，并且该集群仅可用于该作业。在这里，客户端首先从集群管理器请求资源启动 JobManager，然后将作业提交给在这个进程中运行的 Dispatcher。然后根据作业的资源请求惰性的分配 TaskManager。一旦作业完成，Flink Job 集群将被拆除。
• 资源隔离：JobManager 中的致命错误仅影响在 Flink Job 集群中运行的一个作业。
• 其他注意事项：由于 ResourceManager 必须应用并等待外部资源管理组件来启动 TaskManager 进程和分配资源，因此 Flink Job 集群更适合长期运行、具有高稳定性要求且对较长的启动时间不敏感的大型作业。

以前，Flink Job 集群也被称为 job (or per-job) 模式下的 Flink 集群。

Kubernetes 不支持 Flink Job 集群。 请参考 Standalone Kubernetes 和 Native Kubernetes。

Flink Application 集群 #

• 集群生命周期：Flink Application 集群是专用的 Flink 集群，仅从 Flink 应用程序执行作业，并且 main()方法在集群上而不是客户端上运行。提交作业是一个单步骤过程：无需先启动 Flink 集群，然后将作业提交到现有的 session 集群；相反，将应用程序逻辑和依赖打包成一个可执行的作业 JAR 中，并且集群入口（ApplicationClusterEntryPoint）负责调用 main()方法来提取 JobGraph。例如，这允许你像在 Kubernetes 上部署任何其他应用程序一样部署 Flink 应用程序。因此，Flink Application 集群的寿命与 Flink 应用程序的寿命有关。
• 资源隔离：在 Flink Application 集群中，ResourceManager 和 Dispatcher 作用于单个的 Flink 应用程序，相比于 Flink Session 集群，它提供了更好的隔离。

Flink Job 集群可以看做是 Flink Application 集群”客户端运行“的替代方案。

Flink 的数据传输

TaskManager（slot槽）之间的数据接收和数据发送

发送端：将数据发送到接收端

接收端：接受数据

接收端和发送端端并行度应该相同

基于信用值的流量控制

作用：提高吞吐量和利用率，减少等待时间（低延迟 、高吞吐）

接收端 – 发送信用值

发送端 – 发送积压量

发送端在信用值范围内，尽可能多的发送

接收端在积压量中选择策略修改信用值的优先级

任务链接

将满足要求的算计（同一个机器-本地通信，相同并行度），即可压缩上下游调用关系（融合为一个任务）

Job、Job Instance、task

在Flink中，主要有如下三个概念：Job、JobInstance和Task，它们所代表的含义分别如下：

* Job：表示应用程序的一次执行，是一个与Flink集群交互的最高级别的概念，代表了一个拓扑图，并包括了所有需要运行的Task以及它们之间的数据流。Job拥有一个唯一标识，可以通过该标识来查询和管理这个Job以及它的执行状态。

* JobInstance：一个Job实例表示一个具体的Job执行实例，它包含了Job的配置、Task的初始化状态等信息。当Job提交到Flink集群后，会创建一个JobInstance并为其分配资源，该JobInstance会运行相应的Task并在完成后报告其状态。

* Task：表示一个作业中的任务，它是Flink中的最小执行单元。每个Task都处理一个数据分区（Partition）并通过网络传输与其它任务交换数据（Flink中的Shuffle）。一个Job由多个Task组成。一个JobInstance中的任务可以根据需要动态的进行上下扩展。

简而言之，Job是一次作业的最高级别的概念，代表了数据流拓扑，而JobInstance则是具体的Job执行实例，它的配置和状态信息都存储在Flink的JobManager中，可以用于管理和监控Job的执行状态。Task是在作业执行时是真正进行计算的最小执行单元，每个Task都是同构的，负责处理数据的一部分并互相协作完成作业的结果。

需要注意的是，JobInstance是在Job被提交后到集群处理之前创建的，当Job执行完成后，JobInstance会被销毁。而Task则是在JobInstance的生命周期内，根据不同的需要进行动态创建和销毁。

支持数据类型

普通数据类型

Java 和 Scale 元组

POJO ： 包含set、get方法 （Avro 会转为 POJO）

Avro ：Avro是Hadoop的一个数据序列化系统，由Hadoop的创始人Doug Cutting（也是Lucene，Nutch等项目的创始人）开发，设计用于支持大批量数据交换的应用。

https://www.cnblogs.com/wqbin/p/11228188.html