1. 什么是MapReduce
#后续 Spark完成类似的工作
MapReduce是Hadoop体系下的一种计算模型(计算框架),主要功能是用于操作,处理HDFS上的大数据级数据。
2. MapReduce的构建思想
3.MapReduce程序开发结构
4.yarn 管理计算资源
1. 配置相关的配置文件 etc/hadoop
yarn-site.xml mapred-site.xml
2. 启动yarn
2.1 伪分布式
sbin/yarn-daemon.sh start resourcemanager
sbin/yarn-daemon.sh start nodemanager
2.2 集群方式
mapred-site.xml
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
yarn-site.xml
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<!--指定resourcemanager所对应的节点--> 【分布式环境新加】
<property>
<name>yarn.resourcemanager.hostname</name>
<value>hadoop12.baizhiedu.com</value>
</property>
slaves
datanode同时又是nodemanager
同步集群的每一个节点
正常启动hdfs
namenode格式化
sbin/start-dfs.sh
集群方式的yarn启动
建议 namenode 不要和 resourcemanager放置在同一个点
# ssh相关的机器,避免yes
在集群环境下,yarn启动的命令,需要在resourcemanager所在的节点执行
sbin/start-yarn.sh
sbin/stop-yarn.sh
验证:
jps看进程
http://hadoop12.baizhiedu.com:8088
- Resource Manager
1.Resource Scheduler 调度器
这个调度器呀,简单来说就是为「让我们每一个节点都充分利用起来!!合理的分
配和调度的一种管理器!
值得注意的是:调度器真的是一个纯调度器,它不负奏从事任何具体的和应用程序
相关的工作!比如,运行map任务或者reduce任务,不是他的活,监控程序。跟踪程
序也不是他的活
2. Application Manager 应用程序管理器
AM 主要就是负责接收client端传输的job请求,为应用(疑瞧。要£程序〉分配
第一个Container (资源池)来运行我们第一个Application Master ,还有就是负
责监控 Application Master 并且在遇到失败的时候重启 Application Master
3、调度器 Scheduler 又分为类
1 .容量调度器
2 .公平调度器
3 .队列调度器
~~~java
YARN中有三种调度器:FIFO调度器、容量调度器、公平调度器
FIFO调度器
将应用放置在一个队列中,然后按照提交的顺序运行应用,按照先进先出的队列顺序。首先为队列中第一个应用的请求分配资源,
第一个应用的请求被满足后再一次为队列中的下一个应用去服务。
优点是:简单易懂,配置简单
缺点: 不适合共享集群。大应用会占用集群中的所有资源,所以每个应用必须等待着,直到轮到自己运行。
在一个共享集群中,更适合使用容量调度器或者公平调度器,这两种调度器都允许长时间运行作业并能及时完成,
同时也允许正在进行较小临时查询的用户能够在合理时间内得到返回结果。
容量调度器
一个独立的专门队列保证小作业一提交就可以启动,由于队列容量是为那个队列中的作业保留的,因此这种策略是以整个集群的利用率为代价的。
这与FIFO调度器相比,大作业执行的时间会更长
公平调度器
使用公平调度器时,不需要预留一定量的资源,因为调度器会在所有运行的作业之间动态平衡。
第一个大作业启动时,它是唯一运行的作业,因此获得集群中所有资源。当第二个小作业启动时,它被分配到集群的一半资源,这样每个作业都能公平共享资源。
需要注意的是,从第二个作业的启动到获得公平共享资源之间会有时间延迟,因为它必须等待第一个作业使用的容器用完并释放出资源。
当小作业结束且不再申请资源时,大作业将回去再次使用全部的集群资源。
最终的效果是,得到了较高的集群使用率,同时能保证小作业及时完成。
设想一个场景:假设有 A和B两个用户,分别拥有自己的队列。
A启动一个作业,在B没有需求时A会分配到全部可用的资源;
当A的作业仍在运行时B启动了一个作业,一段时间后,按照我们之前看到的方式,每个作业都用到了一半的集群资源。
这时如果B启动第二个作业并且其它作业仍在运行,那么第二个作业将和B的其它作业共享资源,因此B的每个作业将占用四分之一的集群资源,
而A仍继续占用一半的集群资源。最终的结果就是资源在用户之间实现了公平共享
4、Application Master 负员监控MAP任务 和reduce任务,用户提交的每一个程序(mapred
iice)都会产生一个AM,这个这个AM就是负责整个任务的管理者!
主要作用:
1 .与RM调度器RS协商获取执行资源
2 .与NM通信以后动任务、停止任务其中涉及到了一个东西:资源池C&嫄啊
3 .监控所有旗下的任务的执行状态(map,reduce),如果失败,则会重新启动任务来申请资源
5、contaniner
Yarn中的资源抽象,它封装/某个二点的多维度资源:如内存, 磁盘,网络,10 CPU等
举例:虚拟机
![在这里插入图片描述](https://img-blog.csdnimg.cn/97014923cb57496e912a109b308c784d.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAfuaYpQ==,size_20,color_FFFFFF,t_70,g_se,x_16)
* yarn-任务调度流程图
![在这里插入图片描述](https://img-blog.csdnimg.cn/4c2ef2229d4443cab2276ae78d97d146.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAfuaYpQ==,size_20,color_FFFFFF,t_70,g_se,x_16)
~~~java
-- 提交任务的流程
1、要将应用程序(MapReduce/Spark/Flink)程序运行在YARN集群上,先得有一个用于将任务提交到作业的客户端,也就是client。它向Resource Manager(RM)发起请求,
RM会为提交的作业生成一个JOB ID。此时,JOB的状态是:NEW
2、客户端继续将JOB的详细信息提交给RM,RM将作业的详细信息保存。此时,JOB的状态是:SUBMIT
3、RM继续将作业信息提交给scheduler(调度器),调度器会检查client的权限,并检查要运行Application Master(AM)对应的queue(默认:default queue)是否有足够的资源。此时,JOB的状态是ACCEPT。
4、接下来RM开始为要运行 Applacation Master 的Container资源,并在Container上启动AM。此时,JOB的状态是RUNNING
5、AM启动成功后,开始与RM协调,并向RM申请要运行程序的资源,并定期检查状态。
6、如果JOB按照预期完成。此时,JOB的状态为FINISHED。如果运行过程中出现故障,此时,JOB的状态为FAILED。如果客户端主动kill掉作业,此时,JOB的状态为KILLED。
- 相关的配置参数
服务器,内存128G,16-core
装完系统之后,linux系统会占用1G左右内存,而且生产上面你一定要预留大概20%的内存左右,这20%内存包括这1G内存 128*20%约等于26G
102G可以用来操作
DataNode和nodemanager进程本身占用内存
生产上面DataNode自己本身配置内存2G左右就可以了
生产上面nodemanager进程一般给他4G左右就可以了,
还剩下102-2-4=96G内存,
这个96G内存就是我们的container容器的内存了,也就是干活的内存
yarn.nodemanager.resource.memory-mb
arn的所有container容器能够使用的总内存
yarn.scheduler.minimum-allocation-mb
单个container容器能够分配的最小内存
yarn.scheduler.maximum-allocation-mb
单个container容器能够分配的最大内存
容器container的cpu相关参数配置:
yarn.nodemanager.resource.pcores-vcores-multiplier
指的是虚拟cpu和物理cpu之间的比例,默认一个物理cpu=2个虚拟cpu
yarn.nodemanager.resource.cpu-vcores
指的是最大虚拟CPU的使用数量,物理16core=32vcore
yarn.scheduler.minimum-allocation-vcores
单个container容器能够占用最小vcore数量
yarn.scheduler.maximum-allocation-vcores
上面指的是单个container容器能够占用的做大vcore数量
如何才能让单个container容器使用的内存和vcore达到一个相对平衡的状态,即一个container把一个小任务跑完了,耗费的内存不是很大,然后耗费的vcore也不是很多,而不是出现耗费vcore很多而内存很小,或者内存很大,vcore很少的情况,这个就是我们想寻找的极限平衡值
这个极限平衡值是是需要找打一个突破口,这个突破口就是下面这个参数的配置
yarn.scheduler.maximum-allocation-vcores
cdh官方经过长期的大浪的实践,给出了一个平衡值,这个值很权威,是cdh官方多次测试结果.上面这个参数值<=5,所以我在实际生产项目设置为4,在生产上面能够完美运行.
极限平衡值下参数设置:
上面机器剩余的102G和16核为例、
vcore数量配置
yarn.nodemanager.resource.cpu-vcores 32
yarn.scheduler.minimum-allocation-vcores 1
yarn.scheduler.maximum-allocation-vcores 4
上面三个参数设置完成之后,意思是16核都用来做vcore,单个container容器能够使用的最小vcore数量=1,最大vcore=4,即容器的数量可以使8-32个
内存大小配置
因为上面vcore数量我们已经按照官方权威测试配置,内存也是作出相关配置,也保障最少的容器数量也是8个,即96/8=12,即,每个容器配置的最大内存数量为12G
yarn.nodemanager.resource.memory-mb 96G
yarn.scheduler.minimum-allocation-mb 1G
yarn.scheduler.maximum-allocation-mb 12G 极限情况下,是只有8个container容器
但是实际情况下,单个container容器数量12G有点大了,你想想你的电脑内存才多大,我一般生产上面设置8G就够了,不过设置12G也是没有任何毛病的.
yarn.nodemanager.pmem-check-enabled true
生产设置为true pmem指的是默认检查物理内存,容器使用的物理内存不能超过我们限定的内存大小,因为我们上面设置了所有容器能够使用的最大内存数量,超出这个内存限制,任务就会被kil掉.比如yarn查看资源还剩下2个G能用,但是任务申请了3个G内存,肯定超出了
yarn.nodemanager.vmem-check-enabled true
生产设置为true vmem指的是默认检查虚拟内存,容器使用的虚拟内存不能超过我们设置的虚拟内存大小
yarn.nodemanager.vmem-pmem-ratio 2.1
物理内存和虚拟内存的比例是2.1:1,也就是1G物理内存对应的2.1G得虚拟内存
- 配置
假设一台机器有48G物理内存 ,8core (按照1:2的一般配置)虚拟core(vcore)有 16个
1)Linux系统本身要占内存+空留:20% ----》 48*0.2=9.6G
剩余:80% = 38.4G
2)DN进程(datanode):生产4G
更改datanode的配置(hadoop-env.sh)
HADOOP_NAMENODE_OPTS=-Xmx1024m
HADOOP_DATANODE_OPTS=-Xmx1024m
3)NM进程:4G
更改NodeManager的配置(yarn-env.sh)
export YARN_RESOURCEMANAGER_HEAPSIZE=1024
export YARN_NODEMANAGER_HEAPSIZE=1024
因此,机器还剩 38.4-4-4 =30.8G (近似30G)
dn和nm一般部署在同一台机器:数据本地化
对于物理内存:
yarn.nodemanager.resource.memory-mb 30*1024 30G
默认配置
yarn.scheduler.minimum-allocation-mb 1024 1G
yarn.scheduler.maximum-allocation-mb 8192 8G
因此,container的个数为:
3(30/8)个 ~30(30/1) 个
生产1:
yarn.nodemanager.resource.memory-mb 30G
yarn.scheduler.minimum-allocation-mb 2G
yarn.scheduler.maximum-allocation-mb 30G
container个数: 1个~15个
生产2:
yarn.nodemanager.resource.memory-mb 32G (从系统借的,系统占用的空间就小于20%)
yarn.scheduler.minimum-allocation-mb 2G
yarn.scheduler.maximum-allocation-mb 8G
container个数:4个~16个
对于CPU:
yarn.nodemanager.resource.cpu-vcores 12
yarn.scheduler.minimum-allocation-vcores 1
yarn.scheduler.maximum-allocation-vcores 4
container:
3个~12个
在生产中,要合理配置物理内存和CPU虚拟核的参数,避免出现资源浪费。
查看物理cpu个数
[root@centos8 hadoop]# grep 'physical id' /proc/cpuinfo | sort -u
physical id : 0
physical id : 1
grep 'core id' /proc/cpuinfo | sort -u | wc -l
[root@centos8 hadoop]# grep 'core id' /proc/cpuinfo | sort -u | wc -l
2
grep 'processor' /proc/cpuinfo | sort -u | wc -l
[root@centos8 hadoop]# grep 'processor' /proc/cpuinfo | sort -u | wc -l
4
5. MapReduce的程序开发
1. 准备 HDFS中上传文件
zhangsan afafdaf
lisi afaadfa
wangwu adfasdfads
pom.xml
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-common</artifactId>
<version>2.5.2</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-hdfs</artifactId>
<version>2.5.2</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>2.5.2</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-mapreduce-client-core -->
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-mapreduce-client-core</artifactId>
<version>2.5.2</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-yarn-common -->
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-yarn-common</artifactId>
<version>2.5.2</version>
</dependency>
编码
# MapReduce编程中 一定会涉及到序列化的操作 ,基本进行了封装
String ---- Text
int ---- IntWritable
Long -----LongWritable
# 打成jar,上传到yarn集群(resourcemanager)
bin/yarn -jar hadoop-mr-baizhiedu.jar
处理maven IDEA 手工打jar包: