从hadoop MapReduce 1.0到yarn (1)

其实这个是一个很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……求点赞鼓励一下吧。

待续未完