hadoop1.0到2.0架构优化的深度思考

       hadoop2.0相对于1.0的优化主要是增加了YARN模块，YARN设计思路是将原1.0的JobTacker三大功能拆分。如下图所示，

       在很多文章里对这种设计细节进行了长篇大论的讨论，如ResourceManager 拥有系统所有资源分配的决定权，负责集群中所有应用程序的资源分配，拥有集群资源主要、全局视图；ApplicationManager主要负责接收job的提交请求，为应用分配第一个Container来运行。而对于初学者来说，看的这个也是云里雾里，似懂非懂的，笔者试着从另外一个角度解析下这种变更带给我们的思考。

       我们在写代码的时候，初期业务简单，并没有进行深度的架构。如一个函数或功能模块里基本上实现了所有的逻辑业务，但随着业务的扩大和深入，这种代码逐渐满足不了系统的要求，于是重构代码，把代码中的业务拆成多种模块单元；java中可以简单的理解成一个方法体中的代码分解成多个不同的类来处理。

       其实hadoop1.0到2.0的submitjob里的变迁也是这种思想，总结起来上面的思想是战略上的考虑，而具体的细节如ResourceManager实现xx功能，则是战术上的细节，很多文章都是在描述这些战术，但这些战术用在自己的系统上未必有用（但思想可以借鉴，如解耦），大部分公司的产品都是自销，不需要考虑太多的兼容性与扩展性，但重构的战略上一致的。

     如hadoop2.0就是submitjob的时候重构了调度模块，把运算模块可插拔化，而在实现细节上就是加了可插拔的入口，命令行或脚本里调用相应的语句即可替换运算工具。