大数据之Flink (上)

---

前言

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案例。