Map

Reduce

- 映射、变换、过滤

- 分解、缩小、归纳

- 1进N出

- 1组进N出

hadoop数据一列求和_mapreduce

Map的并行度由切片的数量来决定，Reduce的并行度由人决定

MR计算的原理：

数据以一条记录为单位经过Map方法映射成KV，相同的key为一组，这一组数据调用一次Reduce方法，在方法内迭代计算这组数据

角色：

  • JobTracker
  • 资源管理
  • 任务调度
  • TaskTracker
  • 任务管理
  • 资源汇报

计算向数据移动的流程，Hadoop1.x

  • Cli
  • 会根据每次的计算任务，咨询NameNode元数据，通过block块酸楚切片（split），得到一个切片清单
  • split是逻辑的，block是物理的，block身上有（offset、locations），split与block形成映射关系，指引split对应的map任务应该移动到哪些节点（即：计算向数据移动）
  • 生成未来运行时的计算程序的相关配置文件
  • cli会将jar、配置xml、split清单上传到HDFS的目录中
  • cli会调用JobTacker通知要启动一个计算程序了，并且告知文件都放在了hdfs的哪些地方
  • JobTracker收到启动程序之后：
  • 从hdfs中取回split清单
  • 根据已收到的TaskTracker汇报的资源数据，确定最终每一个split对应的map应该去哪个节点
  • 当后面TaskTacker再汇报的时候就会取回分配给自己的任务信息
  • TaskTacker：
  • 在心跳取回任务后，从HDFS中下载jar、xml等资源到本机
  • 最终启动任务描述中的MapTask/ReduceTask执行相关逻辑

Hadoop1.x 中JobTracker的三大问题

  • 容易出现单点故障
  • 压力过大（调度可能会有延迟）
  • 集成了资源管理、任务调度两者耦合，带来的弊端是：
  • 未来新的计算框架不能复用资源管理
  • 因为各自实现资源管理，当部署在同一批硬件上时，因为隔离，所以不能感知对方的使用情况，造成资源争抢！

Hadoop2.x淘汰了以上的处理流程，出现了yarn架构

hadoop数据一列求和_资源管理_02

yarn架构：将1.x中JobTracker的资源管理功能独立出来，进行独立的资源管理

  • 模型：
  • container容器
  • 虚的：对象、属性、nodeManager、cpu、内存、io
  • 物理：
  • jvm进程->操作系统进程
  • NodeManager会有线程监控container资源情况，若有超额，会由NM直接kill掉
  • 通过cgroup（内核级）技术，在启动jvm进程的时候，由kernel约束死
    *整合docker
  • 架构/框架
  • ResourceManager
  • 负责整体资源的管理
  • NodeManager
  • 向ResourceManager汇报心跳，提交自己的资源情况
  • 运行流程（MapReduce On Yarn）
  • MR-cli（切片清单、配置、jar、商出单hdfs）
  • MR-cli 访问ResourceManager申请AppMaster
  • ResourceManager选择一台节点，通知NodeManager启动一个Container，在里面反射一个MapReduce AppMaster
  • 启动MapReduce AppMaster，从hdfs下载切片清单，向ResourceManager申请资源
  • 由ResourceManager根据自己掌握的资源情况得到一个确定清单，通知NodeManager来启动container
  • container启动后会反向注册到已经启动的ResourceManager AppMaster进程
  • ResourceManager AppMaster（曾经的JobTasker阉割版不带资源管理的）最终将任务发送给container
  • container会反射相应的Task类为对象，调用方法执行，其结果就是我们的业务逻辑代码的执行
  • 计算框架都有Task失败重试的机制
  • 结论：
  • 单点故障：曾经时全局的，即JobTracker挂了，整个计算层都没有了调度
  • 现在，每一个App有一个自己的AppMaster调度，yarn也支持AppMaster失败重试
  • 压力过大：yarn每个计算程序自有AppMaster，每个AppMaster只负责自己计算程序的任务调度，轻量了；AppMaster是在不同的节点中启动的，有了负载
  • 集成了资源管理、任务调度两者耦合：
  • yarn只是资源管理框架，不负责具体的任务调度，进行了解耦
  • 是公共的，只要计算框架继承了yarn的AppMaster的接口，大家都可以使用一个统一视图的资源管理层。

从1.x到2.x：1.x的JobTacker、TaskTracker是MR的常服务，2.x之后没有了这些服务，相应的：MR的cli、调度、任务都变成了临时服务