7、hadoop的MapReduce计算框架

最新推荐文章于 2024-02-04 16:06:03 发布

贝壳里的沙

最新推荐文章于 2024-02-04 16:06:03 发布

阅读量566

点赞数

分类专栏：大数据处理

本文链接：https://blog.csdn.net/lixiang987654321/article/details/88912615

版权

大数据处理专栏收录该内容

23 篇文章 1 订阅

订阅专栏

说明

1、MapReduce适合做离线计算框架

2、Storm适合做流式计算框架，实时计算

3、Spark内存计算框架，适合做快速获取计算结果

1、基础知识

核心理念是：移动计算而不移动数据

移动计算：将你写好的程序分别拷贝一份到对应机器上，但是数据不移动；

计算步骤：

数据切片---->map task计算 -->shuffle --->reduce-->输出数据（保存在hdfs中的）

（1）以HDFS上的文件或数据作为数据来源进行计算

（2）HDFS上的数据可以被切分成多个片段作为数据输入，每一个片段对应一个Map task线程计算

（3）MapReduce真个计算过程不便于我们去控制它，只能通过代码控制部分功能，大部分的计算由MapReduce计算框架自动完成

案例4个阶段以及作用

步骤（1）数据切分

大数据文件切成n个数据片段，每一个片段交给一个map task（一个java线程）

MapReduce的Split大小：

-max.split(100M)

-min.split(10M)

-blcok(64M)

-max(min.split,min(max.split,block))

所以默认的切分碎片大小为一个block的大小64M，大于64M的被切分成多个split，即如果一个block设置为200M，那么split为100M，被切分为2个碎片。

步骤（2）Map计算

每一个被切分的数据片段都会有一个对应的map task线程进行处理计算

步骤（3）shuffling过程

在mapper和reduce中间的一个步骤，合并计算（根据具体写的程序功能而定），该阶段大多数工作有MapReduce框架自动完成；

作用：可以把mapper的输出按照某种key值重新切分和组合合成n份，把key值符合某种范围的输出送到特定的reducer哪里去

处理；可以讲话reduce过程

map的输出做的shuffle过程：

map输出结果（内存中）-->分区，排序--->溢写到磁盘（已经分区且排序）-->合并磁盘

shuffle的过程出现在map task的输出结果部分以及reduce前的合并过程；

分区规则：partition如何分区就如何写，当然其自己也有默认的分区规则--哈希模运算（每个对象都有哈希值，模数为reduce数，如reducer数量设置为2，一个整数模2结果为0和1两个分区，所有数据要么分到0去，要么分到1区，分区后分别送到0reduce和1reduce，多个reduce能加快速度，需要解决数据倾斜问题）

分区的目的：map task输出结果进行分区的目的就是解决数据负载均衡和数据倾斜（MapReduce如何解决负载均衡和数据倾斜《数据处理不平衡》，默认的partition是可能产生数据倾斜问题，0或1数量不一致）

结论：解决好数据倾斜问题，必须优化和设计好分区规则。

溢写：默认的map task的内存缓冲区为100M，存储着map的输出结果，当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式存放到磁盘，这个过程就是溢写，溢写有单独的线程来完成，不影响往缓冲区写的map结果的线程，spill.percent默认是0.8，当溢写线程启动后，需要对80MB空间的key做排序sort，

merge on disk：合并到磁盘的也有默认规则，默认使用哈希值相同合并规则，也就是键相同合并，也可以自定义合并规则（combine），combine合并的目的是：多个map结果到磁盘，为后续文件拷贝到reduce减少网络多次拷贝；

sort排序：

1、排序算法：比较两个对象和速度，默认排序算法按照对象的asc码字典排序；

fetch：数据拷贝

分区排序好的数据最终会拷贝到对应的reduce中，进行reduce操作

步骤（4）reduce

reduce过程前也有部分shuffle过程，进行来自不同的map task的数据合并，相同集合的shuffle计算结果作为reduce线程的计算输入数据（只拷贝分给这个reduce的对应数据）

程序员可以控制的部分：partition分区，sort排序，merge on disk(combine)磁盘合并，reduce之前的合并是无法控制的，这里的合并是MapReduce自动完成，按照key相同进行合并；

2、MapReduce的架构

一主多从结构

（1）主JobTrack

负责调度分配每一个子任务task运行于TaskTracker上，如果发现有失败的task就重新分配其任务到其他节点上。每一个hadoop集群中只有一个JobTracker，一般运行于master节点上。

注意：1.0之后才有JobTracker，在2.0之后已经不存在JobTracker！

（2）从TaskTrack

TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务（map task或者reduce task），为了减少网络带宽TaskTracker最好运行在HDFS的DataNode上（默认也是如此，TaskTracker运行在DataNode）。

配置：

mapred-site.xml

<name>mapred.job.tracker</name>

<value>hadoop1:9001</value>

</property>

这里因为配置的JobTracker，可以在任意一台机器。

JobTracker与TaskTracker在2.0版本过期问题

低版本的hadoop下MapReduce处理流程

1、首先用户程序(JobClient)提交了一个job,job的信息会发送到Job Tracker,Job Tracker是Map-reduce框架的中心，他需要与集群中的机器定时通信heartbeat,需要管理哪些程序应该跑在哪些机器上，需要管理所有job失败、重启等操作。

2、TaskTracker是Map-Reduce集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。

3、TaskTracker同时监视当前机器的tasks运行状况。TaskTracker需要把这些信息通过heartbeat发送给JobTracker,JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上。

但是随着集群规模个工作负荷的增长，原框架的问题便暴露出来了。

1、JobTracker是Map-reduce的集中处理点，存在单点故障

2、JobTracker完成了太多的任务，造成了过多的资源消耗，当map-reduce job非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险，这也是业界普遍总结出老hadoop 的Map-Reduce只能支持4000节点主机的上限。

3、在TaskTracker端，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM

4、在TaskTracker端，把资源强制划分为map task slot和reduce task slot如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费，也就是前面提到过的集群资源利用的问题。

5、源代码非常难读，因为一个类做了太多的事情，而代码量过多，造成class的任务不清晰，增加bug的修复和版本维护的难读。

新hadoop yarn框架原理及运行机制

为了从根本上解决旧的MapReduce框架的性能瓶颈，促进Hadoop框架的更长远发展，从0.23.0版本开始，Hadoop的MapReduce框架完全重构，叫做MapReduceV2或者Yarn.

基本思想就是将JobTracker两个主要的功能分分离成单独的组件，这两个功能是资源管理和任务调度/监控。新的资源管理器全局管理所有应用程序计算资源的分配。每一个应用的ApplicationMaster负责相应的调度和协调。一个应用程序无非是一个单独的传统的MapReduce任务或者是一个DAG(有向无环图)任务。ResourceManager和每一台机器的阶段管理服务器能够管理用户在哪台机器上的进程并能对计算进行组织。

事实上，每一个应用的ApplicationMaster是一个详细的框架库，它结合从ResourceManager获得的资源和NedoManager协同工作运行和监控任务。

ResourceManager支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲他就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。

ResourceManager是基于应用程序对资源的需求进行调度的；每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存、CPU、磁盘、网络等。可以看出，这同现在MapReduce固定类型的资源使用模式有显著区别，它给集群的使用带来负面的影响，资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序，调度插件可以基于现有的能力调度和公平调度模型。

图中NodeManager是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况（CPU 内存磁盘网络）并且向调度器汇报。

每一个应用的ApplicationMaster的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控他们的进程，处理任务的失败原因。

新旧Hadoop MapReduce框架对比

所以，我们看到的hadoop2.0的运行资源为：

1、客户端不变，其调用API及接口大部分保持兼容，这也是为了开发使用者透明化，对原码不必做大的改变，但是原框架的JobTracker和TaskTracker不见了，取而代之的是ResourceManager AppliactionMaster NodeManager三个部分。

2、ResourceManager是一个中心的服务，它做的事情是调度、启动每一个Job所属的ApplicationMaster、另外监控ApplicationMaster的存在情况。Job里面所在的task的监控，重启等内容不见了，这就是ApplicationMaster存在的原因。ResourceManager负责作业与资源的调度，接收JobSubmitter提交的作业，按照作业的上下文(context)信息，以及从NodeManager收集来的状态信息，启动调度过程，分配一个Container作为Application Master

3、NodeManager功能比较专一，就是负责Container状态的维护，并向RM保持心跳。

4、ApplicationMaster负责一个Job生命周期内的所有工作，类似老的框架中JobTracker,但注意每一个Job(不是每一种)都有一个ApplicationMaster,他可以运行在ResourceManager以外的机器上.

Hadoop yarn优势

1、大大减小了JobTracker（也就是现在的ResourceManager）的资源消耗，并且让检测每一个Job子任务（tasks）状态的程序分布式化了。更安全、更优美

2、在新的Yarn中，ApplicationMaster是一个可变更的部分，用户可以对不同的编程模型写自己的ApplicationMaster，让更多类型的编程模型能够跑在Hadoop集群中。

3、对于资源的表示以内存为单位，比之前以剩余slot数目更合理

4、老的框架中，JobTracker一个很大的负担就是监控kob下的tasks的运行状况，现在，这个部分就扔给ApplicationMaster了，而ResourceManager中有一个模块叫做ApplicationsMaster,它是检测ApplicationMaster的运行状况，如果出问题，会将其在其他机器上重启

5、Container是Yarn为了将来做资源隔离而提出的一个框架，这一点应该借鉴了Mesos的工作，目前是一个框架，仅仅提供Java虚拟机内存的隔离，hadoop团队的设计思路应该后续能支持更多的资源调度和控制，既然资源表示成内存量，那就没有了之前的map slot/reduce slot分开造成集群资源闲置的尴尬情况。