hadoop-2 dfs/yarn 相关概念

-★出爺;3

　　一.dfs
　　1.旧的dfs方案

　　可以看到block管理与NN是一对一的,即整个集群中只有一个'block pool',隔离性差;
　　另外物理是它是置于NN端的,逻辑上把它归入到bock storage上了,这是需要注意的;
　　2.dfs federation

　　新存储架构采用了multi-namespaces机制,安全/故障隔离性好;
　　每个Ns都有一个自己的Pool,这样就构成一个pools(逻辑上的);
　　因为每个pool可以存储不同DN上的blocks地址,所以pool与DN是多对多关系(decommision时就需要在所有NN上处理的原因);
　　在这方面,据我了解百度是分层进行的,这里是并列的.各有各的好处吧.
　　分层的话便于扩展,容易扩展到很多层次;缺点是假如root节点down了也同样引起SPOF问题,而且逐级推进的处理方式导致延时严重;
　　并列的话避免了分层的问题;但每次添加新的NS都引起小小的震荡,而且多个NS时可能带来维护上的不便
　　二.mapreduce部分
　　1.旧的mapred架构

　　可见,JT负担了资源分配,job调度,tasks初始化,hearbeat检测等大量工作,严重影响了集群性能;同时带来单点问题;
　　2.mapreduce nextgen / MRV2 / YARN

　　为了解决JT之前遇到的问题,新一代MR将资源调度,job分配分开了,其中:
　　ResourceManager(只有一个):只负责资源调度问题,比如某些Containers报告的cpu,内存,网络异常等,进行其它Containers调度;
　　其中包括:Scheduler:是一个插件,如之前的FairScheduler,资源调度
　　ApplicationManager:管理job提交,与ApplicationMaster交互
　　ResourceTracker:处理NodeManager的报告信息
　　NodeManager:每台机器一个,与RM形成数据处理构架;与AM进行taks执行,管理等
　　ApplicationMaster(每个job或DAG编程模型一个):负责仲裁从Scheduler获得的Containers,启动并跟踪containers的状态信息等,其实它是first container,承担了之前JT的部分职责.
　　Container:(每个Job有多个) 负责执行MR任务,相当之前的TT
　　从图上可以看出,现在是有二个jobs在提交运行,为了兼容,在YARN上编写MR其实与之前版本是完全一样的,这点可以让老手忽略了新架构的底层细节