Flink 学习笔记一

2017/11/23 Flink

Flink 学习笔记一

前言

整个中文网站都没有成文的flink学习资料,基本上都是些只言片语,所以我决定写这份学习笔记。使用起来极为不便,什么都没有讲清楚。

flink的历史

flink的起点是一个名为Stratosphere的研究项目,目标是为了构建下一代大数据分析平台。在14年的时候被Apache基金会接受作为一个项目存在。 图一 本的Stratosphere目标是拥有一个runtime,optimizer,Java API,平台日臻成熟时候,开始支持本地运行时和YARN。从0.6版本开始,名字变成了flink。最新版本的flink目标是支持例如:batch Processing,stream processing,graph processing,machine learning等功能。 Flink 0.7版本引入了最重要的功能,Flink streaming API。 最初的版本只有Java API,最新的版本已经开始支持Scala API 了。

架构

Flink 1.x 是由一些组件组成的,如图: 图二 Flink 是分层的架构,第一层是对其底层的抽象。Flink被设计为运行在本地机器或者是Yarn集群上,或者在云上运行。Runtime是Flink的核心数据处理引擎,用来处理用JobGraph API 形成的程序。JobGraph是一种有一系列任务产生和消费数据流的data flow。 DataStream 和 DataSet API 是用来定义Job的接口。JobGraphs是上述API组成的程序在编译的时候生成的。编译过之后,优化器会自动优化程序生成的JobGraph。 JobGraph是通过deployment 模块提交任务的。可以使用三个运行时,本地,远程和Yarn集群。最好使用YARN集群模式运行。

分布式运行

Flink 分布式运行有两个重要的进程,master和worker。Flink程序执行过程中,会有很多进程参与,有三个进程。Job Manager,Task Manager,Job Client。 图三 Flink程序需要提交到Job Client,Job Client会把Job提交到Job Manager。Job Manager会处理资源分配和Job的执行。一旦资源分配成功,task会被分配到各自的Task Manager上。接收到task后,Task Manager会初始化一个线程执行,在任务的执行过程上,task manager 会不停的报告状态给Job Manager。

JobManager

Job Manager也就是Master,协调和管理整个程序的执行过程。Job Manger主要的职责有scheduling tasks,checkpoints,failure recovery。 可以同时有多个Master运行,共同完成需要的功能,所以可以实现高可用性。会有一个Master作为集群和leader,如果leader挂掉了,其他Master会自动选择一个leader。Job Manager 包含的组件如下:

  1. Actor System
  2. Scheduler
  3. Check pointing Flink 使用了Akka Actor System用来在Job Manager 和Task Manager之间通信。

Actor System

Actor System 是一个多actor多角色的系统。这个系统提供了调度,配置,日志等功能。所有的actor组成一个集合,第一个新建立的actor会指定一个parent,新的actor全部从一个线程池实例化,actor之间相互通信是通过消息系统,第一个actor都有一个邮箱。如果actor运行的本地,actor之间的邮箱是通过共享内存实现的,如果actor处于远程系统中,那么邮箱会通过RPC调用实现。第一个父节点是其子节点的管理者,如果子节点产生了错误,父节点会获得通知,如果父节点能处理子节点出错的问题,父节点会重启子节点,如果不能处理,会把问题暴露给它的父节点。 图四 在flink中,一个actor是一个有state和behavior的容器,一个容器的线程会顺序的处理它邮箱中的消息,状态和行为会由于actor收到的消息修改。

Scheduler

flink中的 executors 定义为任务槽,第一个task manager 需要管理一个或多个任务槽,flink 会决定每一个task会占用什么槽或者共享槽。它通过定义SlotSharingGroup或者是CoLocationGroup来确定。

Check pointing

check pointing 是flink的错误处理机制的基础。这个机制会不停的给数据流和executor 状态执行快照,这个机制是由Chandy-Lamport 算法产生的机制。 错误处理机制会为数据流不停的创建轻量级快照,所以不会对性能有比较大的影响,数据流的状态存储的位置可以自己选择,例如存储到HDFS上。 当错误产生的时候,flink会暂停executor的执行并处置它们,并且重新从最近的一个check point 执行。 Stream barriers是flink的快照核心,它们直接插入数据流的,但是不会影响流的执行,它们形成了快照的数据组。每一个barriers都有一个唯一的ID,如图: 图五 第一个快照都会报信息报告给Flink Job Manger checkpoint coordinator,第一次产生新的快照的时候,Flink会对应数据从而避免因为失败对任何数据的重新处理过程,数据对齐过程会使用少量时间,但是在大数据情况下会带来显著的时延,我们选择尽可能的降低延迟,但是Flink是精确的每条数据只处理一次,所以如果程序需要低延迟并且允许重复的数据处理,可以关闭这个机制。会路过对齐,降低延迟。

Task Manager

task manager 是工作节点,在JVM中通过一个或者多个线程执行具体的工作。每一个task的并行度是通过可用的任务槽决定的。每个任务表示一系列的分配在槽上的资源。如果一个task manger有四个槽,那么每个槽会分配25%的内存,槽中会有一个或者多个线程在运行,同一个槽中的线程会使用同一个JVM,同一个JVM中的任务会共享TCP连接和心跳数据。 图七

Job Client

Job Client不是flink的内部组件,但是它是程序的入口。Job client负责从用户接受程序并且创建data flow ,然后把data flow提交到Job manager中进行执行。一旦执行完成,job client会把执行结果返回给用户。 data flow是执行计划,如下是一个简单的word count program:

val text=env.readTextFile("input.txt")  //source

val counts=text.flatMap{ _.toLowerCase.split("\\W+") filter { _.nonEmpty } }
.map{  { _,1 } }
.groupBy(0)
.sum(1)             //Transformation

counts.writerAsCsv("output.txt","\n"," ") //sink

当一个client从用户那里接受到一个程序,它会将程序处理成data flow。上述程序的data flow会如图所示: 图八 处理流程图展示了一个程序是如何转换成为一个data flow的,flink的data flo是默认是并行的分布式的。并行运行的时候,flink会把operators和streams分区。Operator partitions 被称为子任务,流可以把数据一一分布或者重新分布。 从source直接到operator的data flow是不会重新分发数据的。如果有Group By 操作的话,数据会重新分发来保证数据是正确的。 图九

Show Disqus Comments

Search

    Table of Contents