弗林克定义 　　

　　

　　Apache Flink是一个框架和分布式处理引擎，用于无界和有界数据流上的有状态计算。 　　

　　

　　Apache Flink是一个框架和分布式处理引擎，用于无界和有界数据流的状态计算。 　　

　　

　　Flink相关概念 　　

　　

　　批处理是有界数据流处理的一个例子。在这种模式下，可以选择在输出计算结果之前输入整个数据集，也就是说在输出结果之前可以对整个数据集的数据进行排序、统计或汇总。 　　

　　

　　相反，流处理,涉及无界数据流。至少在理论上，它的数据输入永远不会结束，所以程序必须不断处理到达的数据。 　　

　　

　　 　　

　　

　　弗林克建筑 　　

　　

　　Flink中的应用执行主要涉及三个实体：Client、JobManager和TaskManagers。 　　

　　

　　客户 　　

　　

　　客户端不是运行时和程序执行的一部分，而是用于准备数据流并将其发送到JobManager。之后，客户端可以断开连接(分离模式)或保持连接以接收进程报告(附加模式)。 　　

　　

　　浙江 　　

　　

　　控制应用程序执行的主进程，即每个应用程序将由不同的作业管理器控制和执行。JobManager将首先接收要执行的应用程序，它将包括：JobGraph、逻辑数据流图和JAR包，该包打包了所有的类、库和其他资源。JobManager会将JobGraph转换成物理数据流图，称为“ExecutionGraph”，包含所有可以并发执行的任务。JobManager向ResourceManager请求执行任务所需的资源，即TaskManager上的槽。一旦获得足够的资源，它将把执行图分发给实际运行它们的TaskManager。在运行过程中，JobManager将负责所有需要中央协调的操作，比如检查点的协调。 　　

　　

　　资源管理 　　

　　

　　主要负责管理TaskManager的槽，是Flink中定义的处理资源单元。Flink为不同的环境和资源管理工具提供了不同的资源管理器，例如YARN、Mesos、K8s和独立部署。当JobManager申请槽位资源时，ResourceManager会将有空闲槽位的TaskManager分配给JobManager。如果ResourceManager没有足够的槽来满足JobManager的请求，它还可以向资源提供平台发起会话，以提供用于启动TaskManager进程的容器。 　　

　　

　　分配器 　　

　　

　　它可以跨作业运行，并且为应用程序提交提供了一个REST接口。当一个应用程序被提交执行时，分发服务器将启动并将该应用程序移交给作业管理器。Dispatcher还将启动一个Web UI，用于方便地显示和监控作业执行的信息。Dispatcher在架构中可能不是必需的，这取决于应用程序是如何提交和运行的。 　　

　　

　　出租马匹 　　

　　

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

　　

　　工作管理员 　　

　　

　　Flink中的工作进程。通常在Flink中有几个task manager在运行，每个task manager都包含一定数量的槽。插槽数量限制了TaskManager可以执行的任务数量。启动后，TaskManager会向资源管理器注册它的槽；在收到资源管理器的指令后，TaskManager会提供一个或多个插槽供JobManager调用。作业管理器可以将任务分配给插槽来执行。在执行期间，任务管理器可以与运行同一应用程序的其他任务管理器交换数据。 　　

　　

　　时间语义学 　　

　　

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

　　

　　事件时间：事件发生的时间，记录设备生产(或 　　

者存储)事件的时间摄取时间(ingestion time)： Flink 读取事件时记录的时间处理时间(processing time)： Flink pipeline 中具体算子处理事件的时间

　　

　　

　　

在 Flink 的流式处理中，绝大部分的业务都会使用 eventTime。

　　

　　

我们知道，流处理从事件产生，到流经 source，再到 operator，中间是有一个过程和时间的，虽然大部分情况下，流到 operator 的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络、分布式等原因，导致乱序的产生，所谓乱序，就是指 Flink 接收到的事件的先后顺序不是严格按照事件的 Event Time 顺序排列的。

　　

　　

　　

　　

window

　　

出现乱序数据，首先想到的是要排序，但是流式数据中不能等待所有数据都到达再进行排序，而是要将数据流切分为数据集，并对数据集进行排序，由此引入窗口的概念。 窗口是一种切割无限数据为有限块进行处理的手段，是无限数据流处理的核心。

　　

　　

Flink 有一些内置的窗口分配器，如下所示：

　　

　　

　　

　　

可以对窗口内收集到的数据做聚合或者其他处理操作，主要分为两大类：

　　

　　

增量聚合函数（incremental aggregation functions）：每条数据到来就进行计算，保持一个简单的状态。全窗口函数（full window functions）：先把窗口所有数据收集起来，等到计算的时候会遍历所有数据。

　　

Flink提供了丰富的window API：

　　

　　

　　

　　

Watermark

　　

窗口操作虽然可以解决乱序问题，但是依然存在迟到数据的现象，由此引入Watermark。

　　

　　

　　

　　

当一个窗口戳到了关闭时间，不应该立刻触发窗口计算，而是等待一段时间，等迟到的数据来了再关闭窗口。数据流中的 Watermark 用于表示 timestamp 小于 Watermark 的数据都已经到达了，因此，window 的执行也是由 Watermark 触发的。

　　

　　

watermarks 给了开发人员一种选择，使开发者做流处理时可以控制延迟和结果正确性之间的权衡。

　　

　　

如果watermark设置的延迟太大，收到结果的速度可能就会很慢，解决办法是在水位线到达之前输出一个近似结果（增量聚合）。如果watermark到达得太小，则可能收到错误结果，不过 Flink 可以通过侧输出流、允许的延迟(allowed lateness)的间隔解决这个问题。

　　

State Backends

　　

由于有效的状态访问对于处理数据的低延迟至关重要，因此每个并行任务都会在本地维护其状态，以确保快速的状态访问。每传入一条数据，有状态的算子任务都会读取和更新状态。状态的存储、访问以及维护，由一个可插入的组件决定，这个组件就叫做状态后端（state backend） 。如果发生故障，Flink 可以恢复应用程序的完整状态并继续处理。

　　

　　

状态后端主要负责两件事：本地的状态管理，以及将检查点（checkpoint）状态写入远程存储。

　　

　　

名称

　　

状态存储位置

　　

checkpoint存储位置

　　

快照

　　

特点

　　

RocksDBStateBackend

　　

RocksDB

　　

RocksDB

　　

全量 / 增量

　　

支持大于内存大小的状态经验法则：比基于堆的后端慢10倍

　　

FsStateBackend

　　

TM JVM Heap

　　

分布式文件系统

　　

全量

　　

快速，需要大的堆内存受限制于 GC 同时拥有内存级的本地访问速度，和更好的容错保证

　　

MemoryStateBackend

　　

TM JVM Heap

　　

JM JVM Heap

　　

全量

　　

适用于小状态（本地）的测试和实验 快速、低延迟，但不稳定

　　

　　

　　

　　

算子状态的作用范围限定为算子任务，由同一并行任务所处理的所有数据都可以访问到相同的状态，如聚合每分钟的事件时，可将一分钟内数据的增量聚合结果作为状态保存。

　　

　　

Checkpoint

　　

　　

　　

Checkpoint是由 Flink 自动执行的快照，Flink 故障恢复机制的核心就是应用状态的一致性检查点。有状态流应用的一致检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照），这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候。

　　

　　

　　

　　

在执行流应用程序期间，Flink 会定期保存状态的一致检查点。如果发生故障， Flink 将会使用最近的检查点来一致恢复应用程序的状态，并重新启动处理流程

　　

　　

　　

　　

遇到故障之后，第一步就是重启应用

　　

　　

　　

　　

第二步是从 checkpoint 中读取状态，将状态重置。从检查点重新启动应用程序后，其内部状态与检查点完成时的状态完全相同

　　

　　

　　

　　

第三步：开始消费并处理检查点到发生故障之间的所有数据，这种检查点的保存和恢复机制可以为应用程序状态提供“精确一次”（exactly-once）的一致性，因为所有算子都会保存检查点并恢复其所有状态，这样一来所有的输入流就都会被重置到检查点完成时的位置。

　　

　　

Savepoint

　　

一个 Savepoint，就是一个应用服务状态的一致性快照，因此其与checkpoint组件的很相似，但是与checkpoint相比，Savepoint 需要手动触发启动，而且当流应用服务停止时，它并不会自动删除。Savepoint 常被应用于启动一个已含有状态的流服务，并初始化其（备份时）状态。

　　

　　

Savepoint 有以下特点：

　　

　　

便于升级应用服务版本: Savepoint 常在应用版本升级时使用，当前应用的新版本更新升级时，可以根据上一个版本程序记录的 Savepoint 内的服务状态信息来重启服务。它也可能会使用更早的 Savepoint 还原点来重启服务，以便于修复由于有缺陷的程序版本导致的不正确的程序运行结果。方便集群服务移植: 通过使用 Savepoint，流服务应用可以自由地在不同集群中迁移部署。方便Flink版本升级: 通过使用 Savepoint，可以使应用服务在升级Flink时，更加安全便捷。增加应用并行服务的扩展性: Savepoint 也常在增加或减少应用服务集群的并行度时使用。便于A/B测试及假设分析场景对比结果: 通过把同一应用在使用不同版本的应用程序，基于同一个 Savepoint 还原点启动服务时，可以测试对比2个或多个版本程序的性能及服务质量。暂停和恢复服务: 一个应用服务可以在新建一个 Savepoint 后再停止服务，以便于后面任何时间点再根据这个实时刷新的 Savepoint 还原点进行恢复服务。归档服务: Savepoint 还提供还原点的归档服务，以便于用户能够指定时间点的 Savepoint 的服务数据进行重置应用服务的状态，进行恢复服务。

　　

状态一致性

　　

AT-MOST-ONCE（最多一次）AT-LEAST-ONCE（至少一次）EXACTLY-ONCE（精确一次）

　　

Flink内部的状态一致性

　　

Flink 使用了一种轻量级快照机制 ―― 检查点（checkpoint）来保证 exactly-once 语义

　　

　　

端到端的状态一致性

　　

流处理应用除了流处理器以外还包含了数据源（例如 Kafka）和输出到持久化系统。端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终；每一个组件都保证了它自己的一致性。整个端到端的一致性级别取决于所有组件中一致性最弱的组件。

　　

　　

内部保证 ―― checkpointsource 端 ―― 可重设数据的读取位置（kafka可以设置读取的offset）sink 端 ―― 从故障恢复时，数据不会重复写入外部系统

　　

为实现目标端数据不重复下写入有以下实现方式：

　　

　　

幂等写入：（仅在目标端表有主键的情况下适用）事务写入：构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中。

　　

事务写入的两种实现方式：

　　

　　

预写日志 （GenericWriteAheadSink）两阶段提交（TwoPhaseCommitSinkFunction ）

　　

预写日志：

　　

　　

把结果数据先当成状态保存，然后在收到 checkpoint 完成的通知时，一次性写入 sink 系统。简单易于实现，由于数据提前在状态后端中做了缓存，所以无论什么sink 系统，都能用这种方式一批搞定。

　　

缺点：微批处理，不能保证一批数据全部成功。

　　

　　

两阶段提交：

　　

　　

对于每个 checkpoint，sink 任务会启动一个事务，并将接下来所有接收的数据添加到事务里。然后将这些数据写入外部 sink 系统，但不提交它们 ―― 这时只是“预提交”。当它收到 checkpoint 完成的通知时，它才正式提交事务，实现结果的真正写入。

　　

2PC 对外部 sink 系统的要求

　　

　　

外部 sink 系统必须提供事务支持，或者 sink 任务必须能够模拟外部系统上的事务。在 checkpoint 的间隔期间里，必须能够开启一个事务并接受数据写入。在收到 checkpoint 完成的通知之前，事务必须是“等待提交”的状态。 在故障恢复的情况下，这可能需要一些时间。如果这个时候sink系统关闭事务（例如超时了），那么未提交的数据就会丢失。sink 任务必须能够在进程失败后恢复事务。提交事务必须是幂等操作。

　　

部署

　　

部署模式

　　

Application ModePer-Job ModeSession Mode

　　

　　

　　

　　

　　

client load：此过程包括在本地下载应用程序的依赖项，执行用户代码以提取 Flink 的运行时可以理解的应用程序（即JobGraph），并将依赖项和JobGraph(s)传送到集群。

　　

　　

部署模式

　　

client load执行位置

　　

JM是否隔离

　　

TM是否隔离

　　

原生k8s集群是否支持

　　

Application Mode

　　

Client

　　

是

　　

是

　　

是

　　

Per-Job Mode

　　

JM

　　

是

　　

是

　　

否

　　

Session Mode

　　

JM

　　

否

　　

否

　　

是

　　

　　

Flink对k8s集群的要求

　　

　　

Kubernetes版本大于等于1.9。可以访问列表，创建，删除容器和服务，可以通过进行配置~/.kube/config。您可以通过运行来验证权限kubectl auth can-i <list|create|edit|delete> pods。启用Kubernetes DNS。RBAC：default service account具有创建，删除Pod的权限。

　　

关注作者公众号 HEY DATA，一起讨论更多