-★出爺;3 发表于 2016-12-12 07:10:55

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其实与之前版本是完全一样的,这点可以让老手忽略了新架构的底层细节
页: [1]
查看完整版本: hadoop-2 dfs/yarn 相关概念