赞
踩
hdfs 存储
yarn 资源调度分配
MapReduce 计算
ResourceManger(RM)
yarn 的资源的控制框架的中心模块,负责集群中所有的资源的统一管理的分配
调度器
应用管理器
调度器(ResourceScheduler)
根据各个应用程序的资源需求,进行分配
应用管理器(Applications Manager)
负责监控或跟踪AM的执行状态
NodeManager(NM)
是ResourceManager每台机器上的代理,负责容器的管理,并监控他们的资源使用情况(CPU,内存,磁盘,网络等等)以及向RM提供这些资源的使用汇报
ApplicationMaster(AM)
yarn中每个应用都会启动一个AM,负责向RM去申请资源。请求NM启动container,并告诉container需要做什么
container
这是一个虚拟的一个概念
yarn中所有应用都是在container上运行的,包括ApplicationMaster
container的分类
运行AM的container
运行各类任务的container,由AM向RM申请的
这张图就是MapReduce on yarn
1-4 启动ApplicationMaster,领取资源
5-8 运行任务,直到任务完成
spark on yarn也大同小异
理想情况下,我们应用对yarn的资源的请求应该立刻被满足,但是实际上,资源有限。特别是很忙的集群
一般指很忙的时间段,比如1-3点 1:05运行 可能1:40才有资源才开始运行,需要等待。
yarn中负责分配资源的就是Scheduler
调度本身就是一个大难题,很难找到一个完美的解决方案,所以yarn提供了三种调度器
以上三种Scheduler如图所示
从9527(原8088)端口的RM管理界面可以看到Scheduler默认为Capcity
hadoop官网上面配置文件说明里有关于调度器的配置
yarn.resourcemanager.scheduler.class
默认为org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
可以修改为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FariScheduler
FIFO一般不用
capacity-scheduler.xml
可以通过这个文件进行详细配置
学习还是得上官网
MapReduce java
Hive 使得SQL->java在MapReduce上跑
官网上写着"easily writing applications" 轻松编写应用程序,但是现在公司基本上不去写MapReduce
对于如何容错,如何进行RPC通信等,开发人员不用关注,关注我们业务逻辑就可以,这方面来说显得较为简单
业务逻辑 + MR框架自带的内置的组件=>分布式应用程序开发
但是呢 用MR来作开发很麻烦,相较于Spark,但是MapReduce的思想是很纯粹很经典的
MapReduce由Map和Reduce组成
Map:映射 把一个任务拆解成多个
Reduce:聚合 把拆解的任务做最后的聚合操作
对于wordcount文件来说其实是把以下内容
hadoop hdfs hdfs hive
hdfs sqoop flume java
Java Hadoop hadoop
变成了
(hadoop,1)
(hdfs,1)
(hdfs,1)
等
Reduce则是把上述内容聚合变为
(hdfs,2)
等
MapReduce-适用/不适用场景
适用:离线、批处理计算
不适用:实时计算
重跑官网例子初步了解MapReduce
关注运行中的进程
22720 DataNode
22595 NameNode
16003 Jps
3766 ResourceManager
22951 SecondaryNameNode
3895 NodeManager
MR运行中的进程
16421 YarnChild Task(包括MapTask ReduceTask)
16058 RunJar
6184 MRAppMaster
可以发现对比安装时的运行例子来说慢了不少
为什么相对安装于跑得慢呢
MapTask ReduceTask都是以进程的方式运行的
进程需要申请资源,运行,释放资源 这就是MR慢的其中一个原因
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。