hadoop-2 dfs/yarn 相关概念

一.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其实与之前版本是完全一样的,这点可以让老手忽略了新架构的底层细节