Flink

Flink中的API

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

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

• Flink API第二层抽象是Core APIs。实际上，许多应用程序不需要使用上述最底层抽象的API，而是可以使用Core APIs进行变成：其中包含DataStream API（应用于有界/无界数据流场景）。Core APIs提供的流式API（Fluent API）为数据处理提供了通用的模块组件，例如各种形式的用户自定义转换（transformations）、联接（joins）、聚合（aggregations）、窗口（windows）和状态（state）操作等。此层API中处理的数据类型在每个编程语言中都有其对应的类。
  Process Function这类带超过抽象和DataStreamAPI的相互集成使得用户可以选择使用更底层的抽象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查询语句可以在TableAPI中定义的表上执行。

什么是状态

数据流中的许多操作一次只查看一个单独的时间（例如时间解析器），而有些操作会记住多个时间的信息（例如窗口操作符）。这些操作被称为有状态操作。 有状态操作的一些示例

• 当应用程序搜索某些事件模式时，状态将存储迄今为止遇到的时间序列。

• 当按分钟/小时/天汇总事件时，状态会保存待汇总的事件。

• 在通过数据流训练机器学习模型时，状态保存着当前版本的模型参数。

• 当需要管理历史数据时，该状态允许高效访问过去发生的事件。

Flink需要了解状态，以便使用检查点和保存点实现容错。 有关状态的知识还允许重新扩展Flink应用程序，着意味着Flink会在并行实例间重新分配状态。 在处理状态时，阅读Flink的状态的后端可能也会有帮助。Flink提供了不同的状态后端，指定了状态的存储方式和位置。

键状态

秘钥状态保存在可视为嵌入式秘钥/值存储库中。状态与有状态操作符读取的数据流一起被严格分区和分发。因此，对键/值状态的访问只能在有键流中进行，即在有键/分区数据交换后进行，并且仅限于与当前事件的键相关联的值。对齐流和状态的键可确保所有状态更新都是本地操作，从而保证一致性，而不会产生事务开销。这种对齐还允许FLink以透明的方式重新分配状态和调整流分区。

状态持久性

Flink采用流重播和检查点相结合的方式实现容错。检查点标记每个输入流中的一个特定点以及每个操作符的相应状态。通过恢复运算符的状态并从检查点开始重放记录，可以从检查点恢复流数据，同时保持一致性（精确一次处理语义）。 检查点间隔是在执行期间容错开销与恢复时间（需要重放的记录数量）之间进行权衡的一种手段。 容错机制可持续绘制分布式流数据的快照。对于状态较小的流式应用程序来读偶，这些快照非常轻量级，可以频繁绘制而不会对性能造成太大影响。流应用程序的状态存储在一颗可配置的位置，通常是分布式文件系统。 如果程序出现故障（由于机器、网络或软件故障），Flink会停止分布式流数据流。然后，系统会重启操作，并将其重置为最新的成功检查点。输入流被重置到状态快照点。作为重新启动的并行数据流的一部分而处理的任何记录，都保证不会影响之前的检查点状态。

Checkpointing检查点

Flink容错机制的核心部分是绘制分布式数据流和操作状态的一致快照。这些快照可作为一致的检查点，在发生故障时系统可以回退到这些快照。Flink绘制这些快照的机制在“Lightweight Asynchronous Snapshots for Distributed Dataflows”（分布式数据流的轻量级异步快照）疑问中有所描述。它的灵感来源于标准的分布式快照Chandy-Lamport）算法，并专门针对Flink的执行模型进行了定制。 请记住，所有与检查点有关的操作都可以异步完成。检查点障碍不会锁步移动，操作可以异步快照其状态。 自Flink1.11版起，检查点可以在对齐或不对齐的情况下进行。在本节中，我们将首先介绍对齐检查点。

Barriers障碍

Flink分布式快照的核心要素是流屏障。这些屏障被注入数据流，并作为数据流的一部分与记录一起流动。屏障永远不会超越记录，而是严格按照顺序流动。屏障将数据流中的记录分为当前快照的记录集和下一个快照的记录集。每个分隔符都带有快照的Id，快照中的记录会被推到分隔符前面。屏障不会中断数据流，因此非常轻便。来自不同快照的多个分隔符可以同时出现在数据流中，这意味着各种快照可能会同时发生。

流屏障在流源处注入并行数据流。快照n的屏障注入点（我们成为Sn）作为报告给检查点协调器（Flink的JobManager）。 然后，这些屏障流向下游。当中间操作符从其所有输入流中接受到快照n的屏障后，它就会向其所有输入流发送快照n的屏障。一旦一个汇操作符（流DAG的末端）从其所有输入流中接收到屏障n，它就会向检查点协调器确定快照n。所有汇操作在确认快照后，该快照即被视为已完成。 快照n完成后，任务将不在向源请求Sn之前的记录，因为此时这些记录（机器后代记录）以通过整个数据流拓扑。

接受多个输入流的操作员需要在快照屏障上对其输入流。上图对此进行了说明：

• 一旦操作员从输入数据流中接受带出快照屏障n，就不能再处理该数据流中的任何记录，直到也从其他输入数据流中接受到屏障n。否则，它将把属于快照n的记录和属于快照n+1的记录混在一起。

• 当最后一个数据流烧到第n个障碍后，操作符会发生所有待处理的传出记录，然后自己发出第n个障碍的快照。

• 它会快照状态并回复处理所有输入数据流的记录，在处理数据流记录之前先处理输入缓冲区的记录。

• 最后，操作员将状态异步写入状态后台。

需要注意的是，所有具有多个输入的运算符和经过洗牌的运算符在使用多个上游任务的输出流时都需要对齐。

Snapshotting Operator State操作员状态快照

当操作符包括任何形式的状态时，这种状态也必须是快照的一部分。 操作符从输入流中接收到所有快照屏障后，在向输入流中发送屏障前，会对其状态进行快照。此时，所有来自屏障前记录的状态更新都以完成，而依赖于屏障后记录的更新还未应用。由于快照的状态可能很大，因此会存储在一个配置的状态后端中。默认情况下，这个JobManager的内存，但在生产使用中应配置分布式可靠存储（如HDFS）。状态存储完成后，操作员会确定检查点，将快照屏障发送到输出流中，然后继续操作。 生成的快照现在包含

• 对于每个并行数据流数据源，快照开始时在数据流中的偏移量/位置。

• 对于每个操作符，都有一个指向作为快照一部分存储的状态的指针。

  

Recovery恢复

这种机制下的恢复非常简单：故障发生时，Flink会选择最新完成的检查点k。然后，系统会重新部署整个分布式数据流，并为每个操作员提供作为检查点k一部分的快照状态。源被设置为从位置Sk开始读取流。例如，在Apache Kafka中，这意味着告诉消费者从偏移量Sk开始获取数据。 如果状态是以增量方式快照的，操作员会从最新完整快照的状态开始，然后对该状态应用一系列增量快照更新。 更多信息，请参阅重新启动策略。

Unaligned Checkpointing不对齐检查点

检查点也可以不对齐执行。其基本思想是，只要飞行中的数据成为操作员状态的一部分，检查点就可以超越所有飞行中的数据。 请注意，这种方法实际上更接近Chandy-Lamport算法，但Flink仍会在源中插入屏障，以避免检查点协调器超载。

• 运算器对其输入缓冲器中存储的did一个障碍做出反应。

• 它会立即将障碍物添加到输出缓冲器的末端，从而将其转发给下游操作员。

• 运算符会将所有被超越的记录标记为异步存储，并创建自身状态的快照。

因此，操作员只需短暂停止处理输入以标记缓冲区、转发屏障并创建其他状态的快照。 非对齐检查点可却从不障碍以最快速度到达汇。它尤其适用于至少有一条缓慢移动数据路径的应用，在这种情况下，对齐时间可能长达数小时。不过，由于它增加了额外的I/O压力，当状态后端的I/O成为瓶颈时，它就无能为力了。有关其他限制，请参阅操作中更深入的讨论。 请注意，保存点将始终对齐。

Unaligned Recovery 不对齐恢复

操作员首先恢复运行中的数据，然后才开始处理非对齐检查点来自上游操作员的任何数据。除此之外，它还执行与恢复对其检查点时相同的步骤。

State Backends状态后端

存储键/值索引的具体数据结构取决于所选的状态后端。一种状态后端将数据存储在内存中的哈希映射中，另一种状态后端则使用RocksDB作为键/值存储。出了定义保存状态的数据结构外，状态后端还实现了对键/值状态进行数据点快照的逻辑，并将快照作为检查点的一部分进行存储。状态后端可以在不改变应用程序逻辑的情况下进行配置。

Savepoints 保存点

所有使用检查点的程序都能从保存点恢复执行。保存允许更新程序和Flink集群，而不会丢失状态。 Savepoints是手动触发的检查点，它能获取程序快照并将其写入状态后端。为此，他们依赖常规的检查点机制。 保存点（Savepoints）与检查点（Checkpoints）类似，只是他们由用户触发，不会在新的检查点完成后自动失效。为了正确使用保存点，了解checkpoints与savepoints之间的区别非常重要，checkpoints与savepoints中对此进行了描述。

Exactly Once vs At Least Once一次或多次

对其步骤可能会增加流程序的延迟。通常情况下，这种额外的延迟只有几毫秒，但我们也看到过一些异常值的延迟明显增加的情况。对于需要所有记录都保持超低延迟（几毫秒）的应用程序，Flink提供了一个开关，可在检查点期间跳过流对齐。一旦操作员看到每个输入的检查点屏障，仍然绘制检查点快照。 当跳过对齐时，运算符会继续处理所有输入，即使在检查点n的某些检查点障碍到达后也是如此。这样，运算符也会处理检查点n的状态快照拍摄之前属于检查点n+1的元素。在还原时，这些记录将作为重复记录出现，因此它们都包含在检查点n的状态快照中，并将在检查点n后作为数据的一部分重放。

对齐只发生在有多个潜质操作（连接）和有多个发送方的操作（流重新分区/洗牌后）上。正因为如此，只有令人尴尬的并行流操作的数据流（map() ,flatMap(),filter(),....)即使在至少一次模式下，实际上也只能保证一次。

State and Fault Tolerance in Batch Programs 批处理程序中的状态和容错

在Batch ExecutionMode（批处理执行模式中），Flink将批处理程序作为流式程序的一种特例来执行，在这种模式下，流是有边界的（元素数量有限）。因此，上述概念适用于批处理程序的方式与适用于流式程序的方式相同，但有一些小的例外：

• 批处理程序的容错不使用检查点。恢复是通过完全重放数据流来实现的。这是可能得，因为输入是有边界的。这使得会分手的成本更高，但由于避免了检查点，常规处理的成本更低。

• 批量执行模式下的状态后端使用简化的内存/核外数据结构，而不是键/值索引。

介绍

及时流处理事有状态流处理的扩展，其中时间在计算中发挥一定作用。除此之外，当你进行时间序列分析、根据特定时间段（通常成为窗口）进行聚合时，或者当你事件发生事件很重要的事件处理时，就会出现这种情况。 在以下部分中，我们将重点介绍你在使用Flink应用程序时应考虑的一些主题。

Notions of Time：Event Time and Processing Time 时间概念：事件时间和处理时间

当在流程序中引用时间时（例如定义窗口），而昆虫引用不同的时间概念：

• 处理时间：处理时间是指正在执行相应操作的是机器的系统时间。

• 当流程序在处理时间上运行时，所有基于时间的操作（如时间窗口）将使用运行相应运算符的机器的系统时钟。每小时处理时间窗口将包括在系统时钟指示整点时间之间到达特定操作员的所有记录。例如，如果应用程序在上午9：15开始运行，则第一个每小时处理时间窗口将包括上午9:15到10:00之间处理的事件，下一个窗口将包括上午10:00到11:00之间处理的事件，以此类推。
  处理事件是最简单的时间概念，不需要流和机器之间的协调。它提供最佳性能和最低延迟。然而，在分布式和异步环境中，处理时间并不能提供确定性，因为它容易受到记录到达系统的速度（例如从消息队列）以及记录在系统内部运算符之间流动的速度的影响。以及停电（计划内或其他情况）。

• 事件时间：事件时间是每个单独事件在其生成设备上发生的事件。该时间通常在记录进入Flink之前嵌入到记录中，并且可以从每个记录中提取该事件时间戳。在事件时间中，时间的进展取决于数据，而不是任何挂钟。事件时间程序必须指定如何生成事件时间水印，这是表示事件时间进度的机制。该水印机制将在下面的后面部分中描述。
  在完美的世界中，事件时间处理将产生完全一致和确定性的结果，无论事件何时到达或其顺序如何。但是，除非已知事件按顺序到达（按时间戳），否则事件时间处理在等待无序事件时产生一些延迟。由于只有等待有限的时间，这限制了事件时间应用程序的确定性。
  假设所有的数据均已达到，事件事件操作将按预期运行，即使在处理无序或延迟事件或重新处理历史数据时，也会产生正确且已知的结果。例如，每小时事件时间窗口将包含带有该小时内事件时间戳的所有记录，无论它们到达的顺序或处理时间如何。（有关详细信息，请参阅有关迟到的部分）。

请注意，有时当时间程序实时处理实时数据时，它们会使用一些处理时间操作，以保证它们及时处理。

Event Time And Watermarks 活动时间和水印

注意：Flink实现了数据流模型中的许多技术，有关事件时间和水印的详细介绍，请查看一下文章。

• Streaming 101 by Tyler Akidau](https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101)

• 数据流论文模型

支持事件时间的流处理器需要一种方法来测量事件时间的进度。例如，当事件时间超过一小时结束时，需要通知构建每小时窗口的窗口操作员，以便操作员可以关闭正在进行的窗口。

事件时间可以独立于处理时间（通过挂钟测量）进行。例如，在一个程序中，操作员的当前事件时间可以稍微落后于处理时间（考虑到接受事件的延迟），而两者都以相同的速度进行。另一方面，另一个流程序可能通过快速已经缓冲在Kafka主题（或另一个消息队列）中的一些历史数据，只需要几秒钟的处理就可以完成数周的事件时间。

下图显示了带有（逻辑）时间戳和内联流动水印的事件流。在此示例中，事件是按顺序排列的（相对于它们的时间戳），这意味着只是流中的周期性标记。

Watermarks in Parallel Streams 并行流中的水印

水印是在源函数处或直接在源函数之后生成的。源函数的每个并行子任务通常独立生成其水印。这些水印定义了该特定并行源的事件时间。 当水印流过流媒体程序时，它们会提前到达操作员的事件时间。每当操作符提前其事件时间时，它都会为其后续操作符下游生成一个新的水印。 一些运算符消耗多个输入流；例如，联合，或keyBy(...) 或 partition(...) 函数后面的运算符。此类运算符的当前事件时间使其输入流事件时间的最小值。当其输入流更新其事件时间时，运算符也会更新。 下面显示了流并行流的事件和水印以及跟踪事件时间的运算符的实例。

Windowing 窗口化

聚合事件（例如计数、求和）在流上的工作方式与批处理中的工作方式不同。例如，不可能对流中的所有元素进行计数，因为流通常是无限的（无界）。相反，流上的聚合（计数、总和等）由窗口限定范围，例如“过去5分钟的计数”或“最后100个元素的总和”。 Windows可以是时间驱动的（例如：每30秒）或数据驱动的（例如：每100个元素）。人们通常会区分不同类型的窗口，例如翻滚窗口（无重叠）、滑动窗口（有重叠）和会话窗口（中间有不活动的间隙）。

请查看此博客文件获取其他窗口示例，或查看DataStreamAPI的窗口文档。

Flink集群剖析

Flink运行时两种类型的进程组成：一个JobManager和一个或者多个TaskManager。 Client不是运行时和程序执行的一部分，而是用于准备数据流将其发送给JobManager。之后，客户端可以断开链接（分离模式），或保持链接来接受进程报告（附加模式）。客户端可以作为触发执行Java/Scala程序的一部分运行，也可以在命令行进程./bin/flink run ...中运行。 可以通过多种方式启动JobManager和TaskManager：直接在机器上作为standalone集群启动、在容器中启动、或者通过YARN等资源框架管理并启动。TaskManager链接到JobManagers，宣布自己可用，并被分配工作。

JobManager

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

• ResourceManager ResourceManager负责Flink集群中的资源提供、回收、分配-它管理task slots，这是FLink集群中资源调度的单位（请参考TaskManager）。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个并行线程。

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集群所需的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 Application Cluster

Flink Application集群是专用的Flink Cluster，仅从Flink Application 执行Flink Jobs。Flink Cluster的寿命与Flink Application的寿命有关。

Flink Job Cluster

Flink Job集群是专用的Flink Cluster，仅执行一个Flink Job。Flink Cluster的寿命与Flink Job的寿命有关。

Flink Cluster

一般情况下，Flink集群是由一个Flink JobManager和一个或多个Flink TaskManager进程组成的分布式系统。

Event

Event是对应用程序建模的域的状态更改的声明。它可以同时为流或批处理应用程序的input和output，也可以单独是input或者output中的一种。Event是特殊类型的Record。

ExecutionGraph

见

Function

Function是由用户实现的，并封装了Flink程序的应用程序逻辑。大多数Function都由相应的Operator封装。

Instance

Instance常用于描述运行时的特定类型（通常是Operator或者Function）的一个具体实例，由于Apache Flink主要是用Java编写的，所以，这与Java中的Instance或Object定义相对应。在ApacheFlink的上下文中，parallel instance也常用于强调同一Operator或者Function的多个instance以并行的方式运行。

Flink Application

一个Flink应用程序是一个java应用程序，它从main()方法（或通过一些其他方式）提交一个或多个Flink Jobs。提交jobs通常是通过调用ExecutionEnvironment的execute()方法来完成的。 一个应用程序的作业可以提交给一个长期运行的Flink Session Cluster，或者提交一个专用的Flink Application Cluster，或提交到Flink Job Cluster。

Flink Job

Flink Job表示为runtime的logical graph（通常也称为数据流图），通过在Flink Application中调用execute()方法创建和提交。

JobGraph

见 Logical Graph

Flink JobManager

Flink JobManager是Flink Cluster的主节点。它包含三个不同的组件：Flink Resource Manager、Flink Dispatcher、运行每个Flink Job的Flink JobMaster。

Flink JobMaster

JobMaster是在Flink JobManager运行中的组件之一。JobManager负责监督单个作业Task的执行。以前，整个Flink JobManager都叫做JobManager。

JobResultStore

JobResultStore是一个Flink组件，它将全局终止（已完成的，已取消的或失败的）作业的结果保存到文件系统中，从而使结果比已完成的作业更长久。这些结果然后被Flink用来确定作业是否应该在高可用集群中被恢复。

Logical Graph

逻辑图是一种有向图，其中顶点是算子，边定义算子的输入/输出关系，并对应数据流或数据集通过Flink Application提交作业来创建逻辑图。 逻辑图通常也成为数据流图。

Managed State

Managed State描述了已在框架中注册的应用程序的托管状态。对于托管状态，Apache Flink来负责持久化和重伸缩等事宜。

Operator

Logical Graph的节点。算子执行某种操作，该操作通常由Function执行。Source和Sink是数据输入和数据输出的特殊算子。

Operator Chain

算子链由两个或多个连续的Operator组成，两者之间没有任何的重新分区。同一算子链内的算子可以彼此直接传递record，而无需通过序列化或Flink的网格栈。

Partition

分区是整个数据流或数据集的独立子集。通过将每个Record分配给一个或多个分区，来把数据流或数据集划分为多个分区。在运行期间，Task会消费数据流或数据集的分区。改变数据流或数据集分区方式的转换通常成为重分区。

Physical Graph

Physical graph是一颗在分布式运行时，把Logical Graph 转换为可执行的结果。节点是Task，便表示数据流或数据集的输入/输出关系或partition。

Record

Record的数据集或数据流的组成元素。Operator和Function接受record作为输入，并将record作为输出发出。

Flink Session Cluster

长时间运行的Flink Cluster，它可以接受多个Flink Job的执行。此Flink Cluster的生命周期不受任何FLink Job生命周期的约束限制。以前，Flink Session Cluster也称为session mode的Flink Cluster，和FLink Application Cluster相对应。

State Backend

对于流处理程序，Flink Job的State Backend决定了其state是如何存储在每个TaskManager上的（TaskManager的Java堆栈或嵌入式RocksDB），以及它在checkpoint时的写入位置（Flink JobManager的java堆或者Fliesystem）。

Sub-Task

Sub-Task是负责处理数据流Partition的Task。“Sub-Task”强调的是同一个Operator或者Operator Chain具有多个并行的Task。

Task

Task是Physical Graph的节点。它是基本的工作单元，由Flink的runtime来执行。Task正好封装了一个Operator或者Operator Chain的parallel instance。

Flink TaskManager

TaskManager是Flink Cluster的工作进程。Task被调度到TaskManager上执行。TaskManager相互通信，只为在后续的Task之间交换数据。

Transformation

Transformation应用于一个或多个数据流或数据集，并产生一个或多个输出数据流或数据集。Transformation可能会在每个记录的基础上更改数据流或数据集，但也可以只更改其分区或执行聚合。虽然Operator和Function是FlinkAPI的物理部分，但Transformation只是一个API概念。具体来说，大多数（但不是全部）Transformation是由某些Operator实现的。

UID

操作员的唯一标识符， 由用户提供或根据任务结构确定。提交申请时，该标识将转换为UID哈希值。

UID Hash

运行时操作符的唯一标识符，也称为“操作符ID“或”顶点ID“，由UID生成。它通常在日志、REST API或度量中暴露，最重要的是，它是保存点钟识别操作符的方式。

开始

如果你想现在开始尝试，创建一个Flink程序，添加FlinkCEP的依赖到项目的pom.xml文件中。

现在可以开始使用PatternAPI写你的第一个CEP程序了

模式API

模式API可以让你定义想从输入流中抽取的复杂模式序列。 每个复杂的模式序列包括多个简单的模式，比如，寻找拥有相同属性事件的模式。从现在开始，我们把这些简单的模式成为模式，把我们在数据流中最终寻找的复杂模式序列称为模式序列，你可以把模式序列看做是这样的模式构成的图，这些模式基于用户指定的条件从一个模式转换到另外一个，比如event.getName().equals("end").一个匹配是输入事件的一个序列，这些事件通过一系列有效的模式转换，能够访问到复杂模式图中的所有模式。

单个模式

一个模式可以是一颗单利或者循环模式.单利模式值接受一个时间,循环模式可以介绍多个时间.在匹配表达式中,循环模式可以介绍多个事件.在模式匹配表达式中,模式"a b+ c ? d"(或者"a",后面跟着一个或者多个"b",在往后选择的跟着一个"c",最后跟着一个"d"),a,c?,和d都是单例模式,b+是一个循环模式,默认情况下,模式都单利的,你可以通过使用量词把它们转换成循环模式.每个模式可以有一颗或者多个条件来决定它接受那些事件.