大数据计算框架的发展
最近几年,出现了很多热门的开源社区,其中注明的Hadoop Storm,以及很热门的Spark, 它们有着各自专注的应用场景.Spar掀开了内存计算的先河,也以内为基础,赢得了内存计算的飞速发展.Spark的火热或多或少的掩盖了其他分布式计算的系统的身影.就像Flink.
在这里把计算引擎分为几代.首先第一代无疑是Hadoop承载的MapReduce,它将计算分为两个阶段,分为Map和Reduce.对于上层应用来说就不得不想方设法拆分算法,甚至于不得不在上层应用来说,就不得不想方法拆分算法,甚至不得不在上层应用实现多个Job的串联,以完成一个完整的算法,例如迭代计算.
由于这样的弊端,催生了支持DAG框架的产生.因此,支持DAG的框架被划分为第二代计算框架.如Tez以及更上一层的Oozie.这里我们不去细究各种DAG实现之间的区别,不过对于当时的Tez和Oozie来说,大多还是批处理的任务.
Spark为代表的第三代的计算引擎.第三代计算引擎的特点主要是Job内部的DAG支持(不跨越Job),以及强调的实时计算.在这里,很多人认为第三代计算引擎也能够很好的运行批处理的Job.
随着第三代计算的引擎的出现,促进了上层应用快速发展,例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink的诞生就被归为了第四代.这应该主要表现在Flink对流计算的支持,以及更一步的实时性上面.当然Flink也可以支持Batch的任务,以及DAG的运算.
Flink的计算
在2008年,Flink的前身已经是柏林理工大学的一个研究性项目,在2014被Apache卵化器所化,然后迅速地成为了 ASF（Apache Software Foundation）的顶级项目之一。Flink 的最新版本目前已经更新到了 0.10.0 了.
Flink是一个针对数据流和批数据的分布式处理引擎.它主要是由Java代码实现.对Flink而言,其所要处理的主要场景就是流数据,批数据只是流数据的一个极限特例而已.换句话说,Flink会把所有任务当成流来处理,这也是其最大的特点.Flink可以支持本地的快速迭代,以及一些环形的迭代任务.并且Flink可以定制化内存管理.
在这点,如果要对比Flink和Spark的话,Flink并没有将内存完全交给应用层,这也是为什么Spark相对于Flink,更容易出现OOM(out of memory).就框架本身与应用场景来说，Flink 更相似与 Storm。如果之前了解过 Storm 或者 Flume 的读者，可能会更容易理解 Flink 的架构和很多概念。
Flink的架构图:
如图所示可以得出
Clinet, JobManager和TaskManager.Client用来提交任务给JobManager,JobMangerf分发任务给TaskManger去执行,然后TaskManger会心跳的汇报任务状态.看到这里，有的人应该已经有种回到 Hadoop 一代的错觉。确实，从架构图去看，JobManager 很像当年的 JobTracker，TaskManager 也很像当年的 TaskTracker。然而有一个最重要的区别就是 TaskManager 之间是是流（Stream）。其次,Hadoop一代中,只有Map和Reduce之间是Shuffle,而对Flink而言,可能有很多级,并且在TaskManger内部和TaskManager之间都会有数据传递,而不像Hadoop,是固定的Map到,Reduce.
Flink中的调度简述
在Flink集群中,在计算资源被定义Task Slot. 每个TaskManger会拥有一个或多个Slots. JobManager会以Slot为单位调度Task.但是这里Task跟我们在Hadoop中的理解是有区别.对于Flink的JobManger来说,其调度的是一个Pipeline的Task,而不是一个点.举个例子，在 Hadoop 中 Map 和 Reduce 是两个独立调度的 Task，并且都会去占用计算资源。对 Flink 来说 MapReduce 是一个 Pipeline 的 Task，只占用一个计算资源。类同的，如果有一个 MRR 的 Pipeline Task，在 Flink 中其也是一个被整体调度的 Pipeline Task。在 TaskManager 中，根据其所拥有的 Slot 个数，同时会拥有多个 Pipeline。
Flink的生态圈
一个计算框架要有长远的发展,必须打造一个完整的Stack,只有上层有了具体的应用,并能够很好的发挥计算框架的优势,那么这个计算框架才能吸引更多的资源,才会更快的进步.
Flink首先支持Scala和Java的API,Python也正在测试中.Flink通过Gelly支持了图操作
Flink 为了更广泛的支持大数据的生态圈，其下也实现了很多 Connector 的子项目。最熟悉的，当然就是与 Hadoop HDFS 集成。
Flink的部署
Flink有三种部署模式,分别是Local, Standalone Cluster和Yarn Cluster. 对于local模式来说,JobManager和TaskManager会公用一个JVM来完成Workload.如果要验证一个简单的应用,local模式最方便的.实际应用中大多使用Standalone或者Yarn Cluster.
Standalone 模式
在搭建Flink的安装包,需要先下载Flink安装包针对Hadoop版本.
我们需要指定Master和Worker.Master机器会启动JobManager,Worker则会启动TaskManager.因此,我们需要修改conf目录中的Master和Slaves,在配置Master文件时,需要指定的JobManager的UI监听端口,一般情况下JobManager只需配置一个,Worker则配置一个或多个.
micledeMacBook-Pro:conf micle$ cat masters
localhost:8081
micledeMacBook-Pro:conf micle$ cat slaves
localhost在conf目录中找到文件枫林客-conf.yaml.在这个文件定义了Flink各个模块的基本属性,如RPC的端口,JobManager和TaskManager堆的大小等,在不考虑HA的情况下,一般只需要修改属性taskmanager.numberOfTaskSlots,也就是每个Task Manger所拥有的Solt个数,在这个属性,一般设置成机器CPU的core数,用来平衡机器之间的运算性能.其默认值为1.配置完成后,使用下面的命令启动JobManager和TaskManager.
启动StandAlone模式的Flink
启动之后就可以登录Flink的GUI页面,在页面中我们可以看到Flink集群的基本属性,在JobManager和TaskManager的页面中,可以看到这两个模块的属性.
Yarn Cluster模式
在一个企业中,为了最大化的利用集群资源 ,一般都会在一个集群中同时运行多种类型的Worload.因此Flink也支持在Yarn上面运行.让我们通过下图了解Yarn和Flink的关系
Flink与Yarn的关系
在图中可以看出,Flink与Yarn的关系与MapReduce和Yarn的关系是一样的.Flink通过Yarn的接口实现了自己的AppMaster.在Yarn中部署Flink,Yarn就会用自己的Container来启动Flink的JobManager和TaskManager
了解Flink与Yarn的关系,我们就简单看下部署的步骤.通过一些命令来查看Yarn中现有的Application且检查其状态.
yarn application -list如果命令正确返回,就说明Yarn的RM目前已经在启动状态,针对不同Yarn的版本,Flink有不同的安装包.Flink在Yarn上面有两种运行模式.一种是让Yarn直接启动JobManager和TaskManager,另一种是在运行Flink Workload的时候启动Flink的模块,前者相当于让Flink模块处于Standby的状态.
在下载和解压Flink的安装包之后,需要在环境中增加环境中增加变量Hadoop_conf_dir或者Yarn_conf_dir,其指向Yarn的配置目录
export HADOOP_CONF_DIR=/etc/hadoop/conf
这是因为Flink实现Yarn的Client,因此需要Yarn的一些配置和Jar包.配置好环境变量后,只需简单的运行的脚本,Yarn就会启动Flink和JobManager和TaskManager
yarn-session.sh -d -s 2 -tm 800 -n 2
上面的命令的意思是,向Yarn申请2个Container启动TaskManager(-n 2), 每个TaskManager拥有两个Task Slot(-s 2), 并且向每个TaskManager的Container申请800M的内存,在上面的命令成功后,我们就可以在YarnApplication页面看到Flink的记录
如过有些虚拟机中会有很多错误,这里需要注意内存的大小,Flink向Yarn会申请多个Container,但是Yarn的配置可以限制Container所能申请的内存大小,甚至Yarn本身所管理的内存大小就很小,这样很可能无法正常启动TaskManager,尤其当指多个TaskManager的时候.
Flink的HA
对于一个企业级的应用,稳定性是首要考虑的问题,然后才是性能,因此HA机制是必不可少的.另外对于已经了解Flink架构的读者可能会担心Flink架构单点问题.和Hadoop一代一样,从架构中我们可以明显发现的问题JobManager有明显单点故障问题(SPOF, single point of failure). JobManager肩负着任务调度及资源分配,一旦JobManager出现意外,其后果可想而知,所有同理Flink同样有对JobManager HA 的处理方式,原理上基本和Hadoop一样.
首先，我们需要知道 Flink 有两种部署的模式，分别是 Standalone 以及 Yarn Cluster 模式。对于 Standalone 来说,Flink必须依赖Zookeeper来实现JobManager的HA(Zookeeper已经成为了大部分开源框架HA必不可少的模块).在Zookeeper的帮助下,一个Standalone的Flink集群会同时有多个活着的JobManager,其中一个处于工作状态,其它处于standby状态.当工作中的 JobManager 失去连接后（如宕机或 Crash），Zookeeper 会从 Standby 中选举新的 JobManager 来接管 Flink 集群。
对于Yarn Cluaster模式来说, Flink就要依靠Yarn本身来对JobManager做HA.其实这里完全是Yarn的机制.对于Yarn Cluster模式来说,JobManager和TaskManager都是被Yarn启动在Yarn的Container中,也就是说它的故障恢复,就要完全依靠Yarn中的ResourceManager(和MapReduce的AppMaster).由于完全依赖Yarn,因此不同版本的Yarn可能会有细微的差异.
Flink的Rest API 介绍
Flink 和其他大多开源的框架一样，提供了很多有用的 Rest API。Flink DashBoard本省也是通过其Rest来查询各项的结果数据.在Flink RestAPI基础上,可以比较容易的将Flink的Monitor功能和其它第三方工具集成.
在Flink的进程中,由于JobManager来提供RestAPI的服务.因此在调用Rest之前,要确定JobManager是否处于正常状态.在正常情况下,在发送一个Rest请求给JobManager之后,client就会收到一个JSON格式返回结果.由于目前Rest提供的功能还不多,需要增强这块功能的读者可以在子项目 flink-runtime-web 中找到对应的代码。其中最关键一个类 WebRuntimeMonitor，就是用来对所有的 Rest 请求做分流的，如果需要添加一个新类型的请求，就需要在这里增加对应的处理代码。下面我例举几个常用 Rest API。
1.查询Flink集群的基本信息:/overview.示例命令格式以及返回结果如下:
$ curl http://localhost:8081/overview{"taskmanagers":1,"slots-total":16,
"slots-available":16,"jobs-running":0,"jobs-finished":0,"jobs-cancelled":0,"jobs-failed":0}
- 查询当前Flink集群中的Job信息:/jobs/ 示例命令格式以及返回的结果如下:
$ curl http://localhost:8081/jobs{"jobs-running":[],"jobs-finished":
["f91d4dd4fdf99313d849c9c4d29f8977"],"jobs-cancelled":[],"jobs-failed":[]}
3.查询一个指定的Job信息:/jobs/jobid.这个查询结果会返回 特别多的详细的内容,这是我在浏览器中进行的测试,如下图:
云心Flink的Workload
WordCount的例子,就像是计算框架的helloworld.这里就一Wordcount为例,在Flink中运行Workload.
在安装Flink的环境中,找到Flink的目录,然后在bin/flink,它用来提交Flink workload的工具.对于WordCount,我们可以直接使用已有的示例jar包.
./bin/flink run ./examples/WordCount.jar hdfs://user/root/test hdfs://user/root/out
上面的命令是在 HDFS 中运行 WordCount，如果没有 HDFS 用本地的文件系统也是可以的，只需要将“hdfs://”换成“file://”。这里我们需要强调一种部署关系，就是 StandAlone 模式的 Flink，也是可以直接访问 HDFS 等分布式文件系统的。