Flink（上）
- 前言
- 一、Flink 特点
- 二、Flink架构
- 2.1 配置信息（standalone模式，yarn模式）
- 2.2 任务提交流程（yarn模式）
- 2.3 Slots
- 三、并行数据流
- 3.1 One-to-one
- 3.2 Redistributing
- 四、Operator Chains
- 4.1 Operator Chains的优点
- 4.2 OperatorChain 组成条件（重要）
- 五、Flink+kafka的两段式提交
- 总结
前言
Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。本文介绍了Flink的特点、架构、两段式提交以及数据流等相关知识
一、Flink 特点
1、事件驱动型
从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。比较典型的就是以kafka为代表的消息队列几乎都是事件驱动型应用，flume也是。而SparkStreaming是微批次的，也就是以时间为单位，每隔一段时间触发一次。
事件驱动型相比于微批次的优点就是对数据更敏感，延迟更低；
2、流与批的世界观
在spark的世界观中，一切都是由批次组成的，离线数据是一个大批次，而实时数据是由一个一个无限的小批次组成的。
在flink的世界观中，一切都是由流组成的，离线数据是有界限的流，实时数据是一个没有界限的流，这就是所谓的有界流和无界流。
这种以流为世界观的架构，获得的最大好处就是具有极低的延迟低；
3、支持事件时间
目前大多数框架时间窗口计算，都是采用当前系统时间，以时间为单位进行的聚合计算只能反应数据到达计算引擎的时间，而并不是实际业务时间；
二、Flink架构
2.1 配置信息（standalone模式，yarn模式）
Spark中是 driver executor
Flink中是 jobmanager taskmanager
只是名字不同，其他基本一致。
2.2 任务提交流程（yarn模式）
Flink任务提交后，Client向HDFS上传Flink的Jar包和配置，之后向Yarn ResourceManager提交任务，ResourceManager分配Container资源并通知对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager，之后ApplicationMaster向ResourceManager申请资源启动TaskManager，ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager，NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager，TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
2.3 Slots
每一个worker(TaskManager)是一个JVM进程，它可能会在独立的线程上执行一个或多个subtask。为了控制一个worker能接收多少个task，worker通过task slot来进行控制（一个worker至少有一个task slot）。
每个task slot表示TaskManager拥有资源的一个固定大小的子集。假如一个TaskManager有三个slot，那么它会将其管理的内存分成三份给各个slot。资源slot化意味着一个subtask将不需要跟来自其他job的subtask竞争被管理的内存，取而代之的是它将拥有一定数量的内存储备。需要注意的是，这里不会涉及到CPU的隔离，slot目前仅仅用来隔离task的受管理的内存。
通过调整task slot的数量，允许用户定义subtask之间如何互相隔离。如果一个TaskManager一个slot，那将意味着每个task group运行在独立的JVM中（该JVM可能是通过一个特定的容器启动的），而一个TaskManager多个slot意味着更多的subtask可以共享同一个JVM。而在同一个JVM进程中的task将共享TCP连接（基于多路复用）和心跳消息。它们也可能共享数据集和数据结构，因此这减少了每个task的负载。
Task Slot是静态的概念，是指TaskManager具有的并发执行能力，可以通过参数taskmanager.numberOfTaskSlots进行配置，而并行度parallelism是动态概念，即TaskManager运行程序时实际使用的并发能力，可以通过参数parallelism.default进行配置。
也就是说，假设一共有3个TaskManager，每一个TaskManager中的分配3个TaskSlot，也就是每个TaskManager可以接收3个task，一共9个TaskSlot，如果我们设置parallelism.default=1，即运行程序默认的并行度为1，9个TaskSlot只用了1个，有8个空闲，因此，设置合适的并行度才能提高效率。
一个特定operator的subtask的个数被称之为其parallelism(并行度)
三、并行数据流
3.1 One-to-one
stream(比如在source和map operator之间)维护着分区以及元素的顺序。那意味着map operator的subtask看到的元素的个数以及顺序跟source operator的subtask生产的元素的个数、顺序相同，map、fliter、flatMap等算子都是one-to-one的对应关系。
类似于spark中的窄依赖
3.2 Redistributing
stream(map()跟keyBy/window之间或者keyBy/window跟sink之间)的分区会发生改变。也就是指会进行shuffle操作的，原来数据的分区和经过处理后的数据的分区会被打乱。
类似于spark中的宽依赖
四、Operator Chains
相同并行度的one to one操作，Flink将相连的operator 链接在一起形成一个task，原来的operator成为里面的subtask。将operators链接成task是非常有效的优化：它能减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量。
4.1 Operator Chains的优点
1）减少线程切换
2）减少序列化与反序列化
3）减少延迟并且提高吞吐能力
4.2 OperatorChain 组成条件（重要）
1）上下游算子并行度一致
2）上下游算子之间没有数据shuffle
五、Flink+kafka的两段式提交
Flink通过checkpoint来保存数据是否处理完成的状态
由JobManager协调各个TaskManager进行checkpoint存储，checkpoint保存在 StateBackend中，默认StateBackend是内存级的，也可以改为文件级（本地磁盘，分布式磁盘）的进行持久化保存。
执行过程实际上是一个两段式提交，每个算子执行完成，会进行“预提交”，直到执行完sink操作，会发起“确认提交”，如果执行失败，预提交会放弃掉。
（提交过程：只要是kafka将数据放入到source中， 就会进入预提交状态，即通过checkpoint机制存到stateBackend【checkpoint存储器】中，但是只会把状态进行存储并不会告诉kafka；即任务一直往下进行直到sink执行完，进行第二次提交并将stateBackend中的状态改为已执行，同时告诉kafka偏移量）
如果宕机需要通过StateBackend进行恢复，只能恢复所有确认提交的操作。
总结
本文介绍了Flink的特点、架构、两段式提交以及数据流等相关知识，在大数据之Flink（下）中，我们会继续介绍有关Flink的特有算子以及用Flink实现WordCount案例。
