开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 7 天，点击查看活动详情

对于flink，身为数据科学与大数据技术专业的毕业生也只是听过没见过。恰巧，我入职的公司需要这门技术，又是我最喜欢的带薪学习。这里记录下初学者入门flink需要了解的知识。

如果你去百度，谷歌，CSDN上搜索flink，那么你一定会看到以下的介绍。

是不是一脸懵逼？

反正我是一脸懵逼的，所以入门需要先了解一些基础概念。

批量数据处理和流数据处理是非常重要的概念。一般来说，在批处理中，数据是先收集然后处理的，而流处理是实时的，数据是分段发送到分析工具中的。

二者不同之处在于：

无状态计算可以类比一下select操作，来一条，操作一条，数据不用留在系统里面。 有状态计算可以类比一下count，sum操作，这时候就需要缓存之前的数据，才可以实现，这样的计算就是有状态的。

流处理（有时称为事件处理）可以简单地描述为是通过不同算子对无界数据或事件的连续处理。因为网络或机器等原因，数据可能出现丢失的故障，流处理引擎提供了三种可靠性模式。Exactly-once是其中一种可靠性模式，需要与其他两种（At-least-once、At-most-once）对照理解。

这个模式下，算子就像流水线上的摸鱼佬。数据或事件在流水线经过不同的算子时如果在中途出现丢失的情况，那就得过且过，能过一天是一天。 我觉得这个模式比较适合数据不太重要，对精确度要求不是很高的场景。

这个模式下，算子就像流水线上的奋斗逼。数据或事件在流水线经过不同的算子时如果在中途出现丢失的情况，那就必须得从头返工，一丁点错都不能出。 但是这个模式下，可能会重复传两次

准确来说是我的困惑。就是At-least-once 重复尝试两次或多次的场景？这个我查阅了很多资料，没有很明确详细的介绍。所以存在较大的困惑。

如果把 1-> 2 -> 3 -> 4 -> 5 这一串数字当做一次实时计算的流程，数字代表不同的算子。

那么At-least-once 重复尝试两次或多次的场景可能出现的情况如下：

例如在2->3数据丢失，retry从起点1开始，又在 3-> 4 出错，传到起点 1 ，造成了1、2、3的重复运算。

这种情况下只可能是网络延迟导致的误判，如我们使用timeOut判定,2->3流程超过一定时间就重新尝试。但是可能存在2->3超时retry了一次，但是上一次数据没有丢失，只是慢了一点，而且传输成功了，这样第一次成功了，retry也成功了。造成了两次数据传输。

经过下面的介绍，我更愿意相信是第二种可能。

目前从我浅显的了解里,实现这个模式有三种手段。

第一种对任务有一定的要求,需要数据处理具有幂等性,让操作一次和操作多次效果一致。这种任务处理简单，开销也小。但是需要特定的数据特征，局限性很大，不适合作为普遍的处理方法。

第二种是对算子进行培训，让他变成聪明的熟练工。在At-least-once的模式下，算子已经变得聪明了，他会自己维护一个事务日志，我处理过的数据或事件就直接干掉，拒绝重复加工。这种方法发生故障都是出现在局部，总体任务再复杂我的开销也不一定会增加。但是对存储要求较高，而且明显影响每个算子的性能。

第三种是比较简单粗暴的方式，也是flink选用的处理方法。我叫他乾坤大挪移（《大灌篮》版）。通过分布式快照对流水线整体进行记录备份。如果出现故障就回溯，退回到最近的备份状态。这个方法开销比较大，但是确实是目前最常用的。这种任务开销小，但是系统越复杂，回滚次数越多，对性能影响越大。

所以，要注意精确一次语义要求输入流的数据源能够重置，否则会丢失数据。

这个世界上的数据可以抽象成为两种，分别是无边界数据( Unbounded Data)和有边界数据( Bounded Data)。

顾名思义，无界数据是一种不断增长，可以说是无限的数据集。

这种类型的数据，我们无法判定它们到底什么时候会停止发送。在国外的一些技术文章上，有时候我们会看到“流数据(Streaming Data)”这一说法，其实它和无边界数据表达的是同一个概念。

无界数据有一个开始，但没有定义的结束。它们不会在生成数据时终止并提供数据。必须连续处理无限流，即事件必须在摄取后立即处理。不可能等待所有输入数据到达，因为输入是无限的，并且在任何时间点都不会完成。处理无界数据通常需要按特定顺序（例如事件发生的顺序）引入事件，以便能够推断结果完整性。

与无界数据此相反，有边界数据是一种有限的数据集。

这种数据更常见于已经保存好了的数据中。例如，数据库中的数据，或者是我们常见的CSV格式文件中的数据。 有边界数据其实可以看作是无边界数据的一个子集。

有界数据流有明确的结束定义，不需要有序的处理，因为可以等待最后数据流传输结束后统一排序，适用于批处理。

从图中可以了解到，

JobManager处理器:也称之为Master，用于协调分布式执行，它们用来调度task，协调检查点，协调失败时恢复等。

TaskManager处理器：也称之为Worker，用于执行一个dataflow的task(或者特殊的subtask)、数据缓冲和data stream的交换。

JobManager和TaskManager处理器可以直接在物理机上启动，或者通过像YARN这样的资源调度框架启动。TaskManager连接到JobManager，告知自身的可用性进而获得任务分配。

换句话说，JobManager分配资源、任务，TaskManager拥有资源、启动任务。一般在生产环境中，JobManager和TaskManager所在节点应是分离的，其目的主要是为了保证TaskManager（基于内存的计算）不抢夺JobManager的资源。

client客户端并不是runtime的一部分，换句话说，Flink集群启动client提交的任务之后，client客户端是可以断开的。

client不像JobManager和TaskManager对应着 flink集群中的结点（或是物理机、或是虚拟机、或是容器），是触发执行的一个抽象化，若程序在JobManager所在结点执行，则称client在JobManager结点上，同样，其也可以在TaskManager结点上。

从基础结构图可以看到flink提交任务流程。

简化流程图如下：

而事实上，在此过程中flink还会与yarn资源调度有交互。完整过程应该如下：

1）JobMaster 向 YarnResourceManager 申请资源，开始调度 ExecutionGraph 执行，向 YarnResourceManager 申请资源；初次提交作业集群中尚没有 TaskManager，此时资源不足，开始申请资源。

2）YarnResourceManager 收到 JobManager 的资源请求，如果当前有空闲 Slot 则将 Slot 分配给 JobMaster.，否则 YarnResourceManager 将向 YarnMaster 请求创建 TaskManager。

3）YarnResourceManager 将资源请求加入到等待请求队列，并通过心跳向 Yarn RM 申请新的 Container 资源来启动 TaskManager 进程，Yarn 分配新的 Container 给 TaskManager。

4）YarnResourceManager 启动，然后从 HDFS 加载 Jar 文件等所需要的的相关资源，在容器中启动 TaskManager。

5）TaskManager 启动之后，向 ResourceManager 注册，并把自己的 Slot 资源情况汇报给 ResouceManager。

6）ResourceManager 从等待队列中取出 Slot 请求，向 TaskManager 确认资源可用情况，并告知 TaskManager 将 Slot 分配给哪个 JobMaster。

7）TaskManager 向 JobMaster 提供 Slot，JobMaster 调度 Task 到 TaskManager 的此 Slot 上执行。

参考：【万字长文】详解Flink作业提交流程 - 腾讯云开发者社区-腾讯云 (tencent.com)