从hadoop MapReduce 1.0到yarn (1)

0
分享 2016-05-30
其实这个是一个很out的话题了,要知道yarn在2013年就推出了,到现在为止,已经成为了hadoop调度的主流。但是还有不少习惯于使用hadoop 1.x的同学,对这个东西没任何感觉。原因可能和虾神以前一样,除了懒得换,还有可能是1.x的结构实在是太简单明了,配置文件少到不写也可以运行通过。

我在5月28日的开发者大会专门通过hadoop 1.x和2.x里面的yarn的演示,其实这些调度机制,在hadoop业界那是人尽皆知的,不过为了符合老夫“致力于推广大数据在GIS领域应用”的身份,所以今天把这个过程通过博客的形式发表一次,同时也作为记忆备份。

首先来看看hadoop 的mapreduce 1.0时代的调度机制:(以下是GIF动画图片)


总共分为13步:


  • 1、用户提交一个任务给JobTracker。
  • 2、任务控制器带着需求,去HDFS里面获取需要进行分析的数据。
  • 3、将数据取回。
  • 4、将任务和相应的数据块,分配给TaskTrancker节点,进行计算。
  • 5、每个计算节点开始加载需要计算的数据块和任务。
  • 6、JobTracker不断的监控TaskTracker的状态,如果Task节点死掉了,会重新发任务启用新的计算节点,如果完成了也会通过监控来决定调度。
  • 7、将计算完成的中间数据写入到hdfs中去。
  • 8、监控发现有些节点有计算量富余。
  • 9、JobTracker重新对任务块进行调度分配。
  • 10、不同计算节点之间进行任务调度。
  • 11、计算完成之后,通知JobTracker。
  • 12、把结果写入到HDFS中去。
  • 13、用户从HDFS中去获取计算结果。




从1.0的调度可以看见,压力最大的节点就是JobTracker,无论是调度分配,还是监控,还是重启任务,都全部依赖这个主控节点,特别用户如果提交了不同类型的分析任务的,比如A用户提交的是一个快速查询的任务,B用户提交的是一个多次迭代长事务的任务,在这种不同类型的任务之间确定是否有计算节点资源空闲,就是一个很头痛的事情。因为迭代的任务会间歇性的调用资源……

所以在1.0时代,除了容易引发单节点故障,还会因为主控节点因为压力过大导致性能下降,因为JobTracker同时兼备了资源管理和作业控制两个功能,这成为系统的一个最大瓶颈,严重制约了Hadoop集群扩展性。——官方的说法是,当他需要管理的节点数超过4000的时候,1.0就会导致“表现出一定的不可预测性”。

还有就是这种架构是专为mapreduce来设计的,如果需要再hadoop上面运行其他的框架,比如内存计算框架、流式计算框架和迭代式计算框架等,他基本上就歇菜了。

针对这种问题,apache升级了hadoop的新一代计算框架,MapReduce V2,并且专门抽象出来作为一个独立的系统,就所谓的Yarn。

关于Yarn的话题,明天再讲……

看在老夫在加过的过程中,还辛苦的码了这么一章博客出来……另外还要做GIF……求点赞鼓励一下吧。

待续未完



文章来源:http://blog.csdn.net/allenlu2008/article/details/51567920

0 个评论

要回复文章请先登录注册