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