Hadoop调优
2024-03-11 01:23:17 2 举报AI智能生成
登录查看完整内容
Hadoop调优
作者其他创作
大纲/内容
查看NN和DN的进程号：jps
查看占用堆内存大小：jmap -heap 进程号
查看NN和DN占用堆内存命令
默认NameNode堆内存大小为2000MB
配置方法：通过HADOOP_NAMENODE_OPTS=-Xmx3072m （这里配置为3M）
Hadoop2.x
默认NameNode堆内存大小不确定，由JVM堆内存弹性伸缩
配置方法：export HDFS_NAMENODE_OPTS=\
推荐配置：NameNode最小内存配置为1G，每超过1000000个Block，增加1G内存
Hadoop3.x
hadoop-env.sh配置
NameNode内存配置
默认DataNode堆内存大小不确定，由JVM堆内存弹性伸缩
配置方法：export HDFS_DATANODE_OPTS=\
推荐配置：DataNode最小内存配置为4G，能够处理40000000个Block，如果Block数或者副本数每升高1000000个，提高1G内存
DataNode内存配置
指导公式：20 * loge(Cluster数量)
配置方法：dfs.namenode.handler.count
hdfs-site.xml配置
NameNode核心线程数
回收站内文件过期时间：dfs.trash.interval = 0
检查回收站中文件是否过期的线程开启间隔时间：dfs.trash.checkpoint.interval = 0
默认不开启回收站
dfs.trash.interval = 具体时间 （表示回收站中文件默认多久后自动清空，单位是分钟）
检查回收站中文件是否过期的线程开启间隔时间配置：dfs.trash.checkpoint.interval = 具体时间 （分钟）
dfs.trash.checkpoint.interval <= dfs.trash.interval
开启回收站
回收站文件默认存储到/user/用户名/.Trash目录下
命令行上的删除逻辑会走回收站：hadoop fs rm ...
WebUI上的删除逻辑不走回收站
代码删除逻辑默认不走回收站，除非走以上逻辑
删除逻辑走回收站的情况
HDFS核心参数配置
网络带宽：尽可能提升网络带宽
磁盘：尽可能使用固态硬盘
影响因素
通过python开启简单的服务器客观感受HDFS文件拉取速度：python -m SimpleHttpServer
命令 hadoop -jar /xxx/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 文件个数（cpu个数 - 1） -fileSize 文件大小 （128MB）
nrFiles：cpu核数 - 1，表示同时并行启动MapTask个数
-fileSize：单个MapTsak处理的文件的大小
测试参数说明
含义：平均单个MapTask的吞吐量 MB/sec
计算方式：处理的总文件大小 / 单个MapTask处理时间总和
nrFiles * Throughput mb/sec
集群整体吞吐量计算
Throughput mb/sec
含义：平均单个MapTask的吞吐量
计算方式：每个MapTask处理文件大小/每一个MapTask的处理时间总和 / MapTask的总数量
Average IO rate mb/sec
IO rate std deviation：方差、反映各个mapTask处理的差值，越小越均衡
因为整个测试的mr过程中内存消耗较大，如果Yarn没有关闭虚拟内存检测，可能报内存异常
处理方案：在yarn-site.xml中关闭虚拟内存检测，分发配置
可能出现bug
测试结果解析
测试HDFS写性能
命令 hadoop -jar /xxx/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 文件个数（cpu个数 - 1） -fileSize 文件大小 （128MB）
测试参数说明：同理测试HDFS写性能
因为提交测试读性能的客户端根据节点距离最近，选择直接读取本地DN上的数据，不走网络IO
测试出的集群总吞吐量远超网络带宽
测试出的集群总吞吐量正常与带宽几乎一致
测试结果分析
测试HDFS读性能以前，要先测试HDFS写性能
测试HDFS读性能
命令 hadoop -jar /xxx/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean
删除因测试HDFS写性能产生的数据
Hadoop默认提供了测试HDFS性能的工具包
HDFS集群压测
配置方式，配置文件看情况分发
hdfs-site.xml
一般来说配置的两个目录分别由不同磁盘mount
NameNode多目录是数据备份，配置的多目录下的数据完全一致
NameNode多目录配置在生产环境中意义并不大
NameNode多目录
DataNode配置多目录不再是数据备份，而是多数据分节点存储，配置的多目录下数据不一致
DataNode的多目录配置在生产环境下还是会用到的，特别是当原磁盘已经快要存满数据，我们就添加一块新的磁盘去mount新的目录，从而将该目录关联到datanode的数据存储路径
DataNode多目录
生成磁盘均衡计划 hdfs diskbalancer -plan 节点主机名
执行磁盘均衡计划 hdfs diskbalancer -execute 节点主机名.plan.json
查询磁盘均衡情况 hdfs diskbalancer -query 节点主机名
停止磁盘均衡计划 hdfs diskbalancer -stop 节点主机名.plan.json
对于单磁盘来说，即使调用该命令也不会生成磁盘数据均衡计划
磁盘数据均衡
HDFS多目录
扩容节点启动DataNode：hdfs --daemon start datanode
扩容节点启动NodeManager：yarn --daemon start nodemanager
可以动态添加DataNode节点实现动态扩容机制
开启数据均衡：/etc/hadoop-3.1.3/sbin/start-balancer.sh -threashold x （其中x代表集群中个节点的磁盘利用率相差不超过x%）
关闭数据均衡：/etc/hadoop-3.1.3/sbin/stop-balancer.sh
扩容的节点后，集群数据不均衡
白名单：配置的主机ip所对应的DataNode节点可以存储数据
可以动态添加DataNode节点实现动态缩容机制
退役节点时几点状态变为Decommissioning状态，在此过程中退役节点上的数据块会自动复制给其他存活节点，直到退役节点的状态变为Decommissioned，所有数据块复制完成为止
要考虑当前的副本策略，如果副本数为3，服役的节点小于等于3，是不能退役成功的，需要修改副本数以满足当前集群节点数
缩容后，集群数据不均衡，同样可以使用start-balancer.sh -threashold x
黑名单：配置的主机ip所对应的DataNode节点不可以存储数据
如果黑白名单配置了同一DataNode节点，该DataNode节点展现退役状态
在hadoop配置目录下创建whitelist和blacklist文件
白名单配置
黑名单配置
在hdfs-site.xml中配置白名单和黑名单的文件路径
每次对whitelist或者blacklist进行了改动都要分发配置
首次配置：重启集群
非首次配置（之前已配好，仅修改文件）：刷新NameNode即可 命令为 hdfs dfsadmin -refreshNodes
黑白名单生效方式
集群黑白名单配置及生效方案
集群的扩容和缩容
引入纠删码的原因：原有副本策略太耗费磁盘空间，假设300M的数据，存储3个副本，就需要整个集群900M的磁盘空间，但是生产环境中实际上副本几乎用不到，但是又必须容错，所以这里有很大的磁盘空间浪费，因此引入了纠删码
Hadoop3.x引入
原理：一种编码容错技术，对数据块分块分组并编码得到冗余校验信息，一旦某些数据信息丢失，我们仍然可以根据剩下的数据信息和校验信息重新计算提高数据容错
纠删码使用的好处：将数据分为数据单元和校验单元存储，使用更少的磁盘空间保证同样的容错性，但是一旦发生故障，会耗费cpu性能计算恢复数据
查询HDFS中现有的纠删码策略 hdfs -ec -listPolicies
向HDFS中添加新的纠删码策略 hdfs -ec -addPolicies -policyFile <File>
获取某一文件或目录的纠删码策略 hdfs -ec -getPolicy -path <path>
移除HDFS中的纠删码策略 hdfs -ec -removePolicy -policy <policy>
给某一目录或者文件设置纠删码策略 hdfs -ec -path <path> -setPolicy <policy> [-replicate]
取消某一目录或者文件的纠删码策略 hdfs -ec -unsetPolicy -path <path>
RS
RS-LEGACY
XOR
列出所有纠删码的编码方式 hdfs -ec -listCodecs
启动某一纠删码策略 hdfs -ec -enablePolicy -policy <policy>
关闭某一纠删码策略 hdfs -ec -disablePolicy -policy <policy>
-help <command-name>
命令
编码方式：RS
10个数据单元
4个校验单元
会把数据块划分为1024k的一个个小单元块，从而构成一个一个的数据单元
若数据单元和校验单元的总个数不低于10个，那么总能够在数据出现异常时可通过计算恢复数据
默认不开启
RS-10-4-1024k
RS-3-2-1024k
默认开启
RS-6-3-1024k
RS-LEGACY-6-3-1024k
XOR-2-1-1024k
默认策略
纠删码
现在正在访问的数据：内存镜像RAM_DISK
经常访问的数据：固态硬盘SSD
不经常看的数据：机械硬盘DISK
ARCHIVE没有特指某种存储介质，通常指计算能力较弱，存储密度较高的存储介质，用来解决数据量扩增的问题，一般用于归档
永久保存的数据：ARCHIVE
含义：解决不同的数据存储在不同类型的硬盘中，达到最佳性能的问题
RAM：1 DISK：n - 1
Lazy_Persist
SSD: n
ALL_SSD
SSD：1，DISK：n - 1
ONE_SSD
默认存储策略，DISK：n
HOT
DISK：1，ARCHIVE：n - 1
WARM
ARCHIVE：n
如果当前硬盘类型均不为ARCHIVE，那么此时写数据会失败
COLD
存储策略
<property> <name>dfs.datanode.data.dir</name> <value>[SSD]file://${hadoop.tmp.dir}/dfs/data</value></property>
HDFS并不能主动识别硬盘的类型，所以我们需要手动指定
[RAM_DISK]
[SSD]
[DISK]
[ARCHIVE]
硬盘类型
hdfs-site.xml中配置
查看当前有哪些存储策略 hdfs storagePolicies -listPolicies
一旦某目录或文件的我们更换存储策略后，必须使用 hdfs mover 文件或目录路径 命令移动文件块
为指定路径（目录或文件）配置存储策略 hdfs storagePolicies -setStoragePolicy -path xxx -policy xxx
获取指定路径（目录或文件）的存储策略 hdfs storagePolicies -getStoragePolicy -path xxx
取消某路径的存储策略 hdfs storagePolicies -unsetStroragePolicy -path xxx
查看某个文件块的分布 hdfs fsck 文件名 -files -blocks -locations
查看集群节点：hadoop dfsadmin -report
现象：虽然当前采用的是Lazy_Persist存储策略，但是数据块均存储在DSIK中
如果提交写数据请求的Client所在的DataNode节点没有RAM_DISK，则会写入Client所在DataNode节点的DISK中，其余副本写入其他DataNode节点的DISK
如果dfs.datanode.max.locked.memory设置过大也可能出现错误，因为虚拟机的max.locked.memory默认为64KB，所以如果前一个参数配置过大，那么就会报错DataNode的可用内存空间不能超过64KB
如果提交写数据请求的Client所在的DataNode节点有RAM_DISK，但是没有配置dfs.datanode.max.locked.memory，或者其配置的很小，小于dfs.block.size，则会写入Client所在DataNode节点的DISK中，其余副本写入其他DataNode节点的DISK
Lazy_Persist存储策略可能出现的问题
异构存储
HDFS存储优化
情景：NameNode挂了，并且NameNode存储的数据信息丢失
修复方式：将SecondaryNameNode节点上的对应数据块信息拷贝回NameNode节点
启动NameNode：hdfs --daemon start NameNode
NameNode数据丢失
在安全模式下，客户端只能读取NameNode数据，不能修改和删除NameNode数据
NameNode在加载镜像文件和编辑日志的期间处于安全模式
NameNode在接受DataNode注册的期间处于安全模式
进入安全模式的场景
dfs.namenode.safemode.min.datanodes：最小的datanode数，默认为0
dfs.namenode.safemode.threadhold-pct：最小要求的block数达到系统总block数的百分比，默认为0.999f，言外之意就是仅仅容忍丢失1个块
dfs.namenode.safemode.extension：安全模式的稳定时间，默认为30000毫秒，也就是30秒
退出安全模式的场景
hdfs dfsadmin -safemode get：查看安全模式状态
hdfs dfsadmin -safemode enter：强制进入安全模式
hdfs dfsadmin -safemode leave：强制离开安全模式
hdfs dfsadmin -safemode wait：阻塞安全模式的离开，需要我们调用强制离开安全模式才能离开安全模式
集群安全模式
场景：删除某DataNode的至少2个数据块，可能立马看不到效果因为默认DataNode每隔6小时向NameNode报告块信息所以我们可以重启HDFS集群即可马上进入到安全模式观察到WebUI提示我们缺少哪个块等信息
利用磁盘数据恢复工具恢复被删除的数据快信息
按照WebUI上的提示信息取删除NameNode的元数据信息
方案
磁盘修复
集群安全模式&磁盘修复
场景：慢磁盘是指写入数据很慢的一类磁盘，慢磁盘问题是很常见的问题，当机器运行时间长了，上面的任务跑多了，磁盘的读写性能自然就会退化，那么严重的时候就会导致数据写入磁盘延迟的问题
通过现象观察慢磁盘：向HDFS创建一个目录，只需要不到1s，如果我们发现创建目录大多数时候超过1s，说明磁盘极大可能出现了问题
默认NN和DN的心跳是每3秒一次
如果NN和DN上关于心跳通信时间超过了3s，那么就出现了慢磁盘问题
通过WebUI上NN和DN的心跳时间发现慢磁盘
安装fio：yum install -y fio
准备1G大小的test.log文件
结果分析：顺序读的速度为360MiB/s
执行fio测试磁盘顺序读性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r
结果分析：顺序写的速度为341MiB/s
执行fio测试磁盘顺序写性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_w
结果分析：随机写的速度为309MiB/s
执行fio测试磁盘随机写性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randw
结果分析：混合随机读写测试中，随机读速度为220MiB/s，随机写速度为94.6 MiB/s
执行fio测试磁盘混合随机读写性能命令：sudo fio -filename=/home/liangheee/test.log -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r_w -ioscheduler=noop
通过fio命令，测试磁盘的读写性能
如何发现慢磁盘？
慢磁盘问题
1M的小文件和128M的文件占用的NameNode的内存空间是一样的，小文件过多会占用NameNode大量的内存空间，很快导致NameNode的内存空间不足 说明：1M的小文件占用的磁盘空间仍为1M，而不是128M
归档原因
启动YARN，要启动MR
执行命令 hadoop archive -archiveName input.har /input /ouput
HAR归档
归档结果分析：HAR归档能够将多个小文件当作是一个大文件，整体归档存入一个HDFS数据块，仅占用一份文件所占用的NameNode的内存空间，对内还是一个个独立的文件，对NameNode而言却是一个整体，减少了占用NameNode的内存空间
方式一：hadoop fs -ls /output/input.har
方式二：hadoop fs -ls har:///output/input.har
查看归档文件
解归档文件：hadoop fs -cp /output/input.har/* /
小文件归档
HDFS故障排查
推数据 scp -r 本地文件路径 远程用户名@远程主机名:/文件路径
拉数据 scp -r 远程用户名@远程主机名:/文件路径 本地文件路径
本地转发 scp -r 远程用户名1@远程主机名1:/文件路径 远程主机名2@远程主机名2:/文件路径说明：远程主机1和远程主机2之间如果没有配置ssh的方式时即可采用本方式
方案一：scp实现两个远程主机之间的数据复制
bin/hadoop distcp hdfs://hadoop102:8020/user/liangheee/hello.txt hdfs://hadoop105:8020/user/liangheee/hello.txt
方案二：采用distcp命令实现两个Hadoop集群之间的递归数据复制
Apache Hadoop内部数据迁移
Apache Hadoop迁移到CDH
HDFS数据迁移
HDFS调优
CPU
内存
网络
磁盘
计算机性能
数据倾斜
Map运行时间太长，Reduce等待太久
小文件过多
I/O操作优化
性能瓶颈
解决数据倾斜：自定义partitioner
mapreduce.map.memory.mb
默认上限1024M
建议：根据128M数据对应1G来动态调整
该内存配置指的是MapTask向RM申请的内存资源大小（可理解为要求Container至少有这么多内存资源），不仅可以跑java程序还可以跑其他语言的程序
MapTask使用内存上限
mapreduce.map.java.opts
如果堆内存不够，报错java.lang.OutOfMemoryError
这个是用于JVM堆内存大小配置，必须小于mapreduce.map.memory.mb，一般为mapreduce.map.memory.mb的0.75倍，要预留一部分给java代码使用
MapTask堆内存大小
mapreduce.map.cpu.vcores
默认MapTask的cpu核数为1
计算密集型任务可以增加cpu核数
MapTask的Cpu核数
mapreduce.task.io.sort.mb
默认为100M
可以调整到200M
增加环形缓冲区大小
mapreduce.sort.spill.percent
默认为80%
可以调整到90%
提高环形缓冲区反向溢写比例
减少环形缓冲区溢写次数
mapreduce.task.io.sort.factor
默认10个文件
可以提高到20个文件
提高每轮merge文件个数
job.setCombinerClass(xxxReducer.class);
不影响业务前提下进行预聚合
conf.setBoolean(\"mapreduce.map.output.compress\
减少磁盘IO，可进行数据压缩
mapreduce.map.maxattempts
默认4次，可根据己其性能适当提高
每个MapTask最大重试次数，超过该值则认为失败
MapTask
mapreduce.reduce.memory.mb
建议：根据128M数据对应1G来动态调整，可以调整到4G-6G
ReduceTask使用内存上限
mapreduce.reduce.java.opts
ReduceTask堆内存大小
mapreduce.reduce.cpu.vcores
默认ReduceTask的cpu核数为1
计算密集型任务可以增加cpu核数，2到4个cpu核
ReduceTask的Cpu核数
mapreduce.reduce.shuffle.parallelcopies
默认为5
可以调整为10
提高每个Reduce到Map中拉取数据的Fetcher线程数
mapreduce.reduce.shuffle.input.buffer.percent
默认为0.70
可以提高至0.75
提高reduce阶段shuffle占用reduce内存大小
mapreduce.reduce.shuffle.memory.limit.percent
默认为0.25
保持不变
reduce阶段单个shuffle任务占用shuffle总内存比例，超过就溢写到磁盘
mapreduce.reduce.shuffle.merge.percent
默认为0.66
可以提高至0.70
reduce阶段shuffle内存中数据达到多少比例开始merge
mapreduce.reduce.maxattempts
每个ReduceTask最大重试次数，超过该值则认为失败
mapreduce.job.reduce.slowstart.completedmaps
默认为0.05
视情况适当调整
Map任务完成数量达到该比例后，ReduceTask开始申请资源启动
尽量避免走reduce
ReduceTask
mapreduce.task.timeout （单位毫秒）
如果mapreduce任务在该配置时间内，既没有读入也没有写出，也没有更新状态信息，便会超时终止
默认600000毫秒，也就是10分钟
视实际情况调整该参数，若mapreduce处理时间较长，则可以延长超时时间
设置mapreduce任务的超时时间
Shuffle
数据频率倾斜：某一区域的数据量远大于另一区域的数据量
数据大小倾斜：部分记录的大小远大于平均值
数据倾斜现象
方案一：如果空值无意义，那么尽量在map端过滤
方案二：如果空值有意义，可以自定义分区，加上随机数打散，再进行二次聚合
首先检查是否因为空值过多导致数据倾斜
尽量在Reduce之前进行聚合，可行的方案有提前Combiner和Map Join
提升Reduce的数量
减少数据倾斜的方案
数据倾斜问题
MapReduce调优
yarn.resourcemanager.scheduler.class
Apache Hadoop默认为Capacity Scheduler；CDH默认为Fair Scheduler；我们一定不会使用FIFO调度器
调度器
yarn.resourcemanager.scheduler.client.thread-count
默认为50
不能超过集群总线程资源，而且还要预留一部分给其他应用使用
RM处理调度器请求的线程数
ResourceManager相关
yarn.nodemanager.resource.detect-hardware-capabilities
默认为false
建议采用默认，不开启
是否让Yarn自己检测硬件配置
yarn.nodemanager.resource.count-logical-processors-as-cores
如果当前集群的cpu均为i5或i7，也就是物理cpu一致，此时不推荐采用逻辑核数
是否将虚拟核数当作cpu核数
yarn.nodemanager.resource.pcores-vcores-multiplier
默认为1.0
虚拟核数和物理核数的乘积
yarn.nodemanager.resource.memory-mb
默认为8G
根据硬件环境来配置
nodemanager使用内存
yarn.nodemanager.resource.system-reserved-memory-mb
一般配置nodemanager使用内存即可，这个参数不配置
nodemanager为系统预留多少内存
yarn.nodemanager.resource.cpu-vcores
默认为8个
按硬件环境来配置
nodemanager使用cpu核数
yarn.nodemanager.pmem-check-enabled
默认打开
是否开启物理内存检查限制Container
yarn.nodemanager.vmem-check-enabled
建议关闭虚拟内存检测
是否开启虚拟内存检查限制Container
yarn.nodemanager.vmem-pmem-ratio
默认2.1
虚拟内存和物理内存比例
NodeManager相关
yarn.scheduler.minimum-allocation-mb
默认为1G
容器最小内存
yarn.scheduler.maximum-allocation-mb
容器最大内存
yarn.scheduler.minimum-allocation-vcores
默认为1个
容器最小CPU核数
yarn.scheduler.maximum-allocation-vcores
默认为4个
容器最大CPU核数
Container相关
如果每个节点的资源不一致，需要为每个节点单独配置
配置参数
默认情况下调度器只有default队列
针对不同框架创建不同队列，比如Flink、Spark、Hive等，企业很少这样划分队列
按照业务模块创建不同队列，登录注册、购物车、下单、业务部门1、业务部门2
创建队列的参考方式
因为担心员工不小心，写递归死循环代码，把所有资源全部耗尽
实现任务的降级使用，特殊时期保证重要的任务队列资源充足。11.11 6.18业务部门1（重要）=》业务部门2（比较重要）=》下单（一般）=》购物车（一般）=》登录注册（次要）
创建多队列的好处
生产环境下怎么创建队列
需求：default队列占总内存的40%，最大资源容量占总资源60%，hive队列占总内存的60%，最大资源容量占总资源80%
配置多队列的容量调度器
分发配置文件
刷新yarn队列 yarn rmadmin -refreshQueues
步骤
方式一：hadoop jar的方式 (注: -D表示运行时改变参数值)
方式二：打jar包的方式，默认的任务提交都是提交到default队列的。如果希望向其他队列提交任务，需要在Driver中声明
测试效果
测试：向Hive队列提交作业
容量调度器支持任务优先级，在资源紧张时，优先级较高的任务将优先获取资源
默认情况下，Yarn上所有任务的优先级为0，如果想开启任务优先级，须开放此限制
修改yarn-site.xml文件，增加以上参数
分发配置，重启Yarn
资源紧张如图所示
模拟资源环境紧张，可连续提交以上任务，直到新提交的任务申请不到资源为止
优先级更高的任务优先获取资源
再次重新提交优先级高的任务
也可以通过以下命令修改正在执行的任务的优先级，yarn application -appID <ApplicationID> -updatePriority 优先级
设置任务优先级步骤
任务优先级
容量调度器
需求：创建两个队列，分别是test和atguigu（以用户所属组命名）。期望实现以下效果：若用户提交任务时指定队列，则任务提交到指定队列运行；若未指定队列，test用户提交的任务到root.group.test队列运行，atguigu提交的任务到root.group.atguigu队列运行（注：group为用户所属组）
配置文件参考资料：https://hadoop.apache.org/docs/r3.1.3/hadoop-yarn/hadoop-yarn-site/FairScheduler.html
任务队列放置规则参考资料：https://blog.cloudera.com/untangling-apache-hadoop-yarn-part-4-fair-scheduler-queue-basics/
公平调度器的配置涉及到两个文件，一个是yarn-site.xml，另一个是公平调度器队列分配文件fair-scheduler.xml（文件名可自定义）
修改yarn-site.xml文件，加入以下参数
配置fair-scheduler.xml
分发配置并重启Yarn
配置步骤
结果显示
提交任务时指定队列，按照配置规则，任务会到指定的root.test队列
提交任务时不指定队列，按照配置规则，任务会到root.atguigu.atguigu队列
测试提交任务
公平调度器
调度器配置
Yarn调优
每个小文件的元数据信息占用NameNode内存约150byte
小文件过多，导致寻址索引较慢
小文件过多，生成的切片也较多，需要启动的MapTask个数很多，启动MapTask的资源消耗较大，导致MapTask的启动时间比其处理时间花费得更多，出现资源的白白浪费
小文件过多的弊端
从HDFS数据源头上解决：数据采集时，就将小文件或者小批数据合并成大文件后再上传HDFS
从存储方向考虑：采用Har归档的方式，将多个小文件归档成为一个HDFS上文件块，从而减少NameNode内存的使用
采用CombineTextInputFormat，将多个小文件在切片过程中生成一个单独切片或者较少的切片
默认情况下，每个Task任务都需要启动一个JVM来运行，如果Task任务计算的数据量很小，我们可以让同一个Job的多个Task运行在一个JVM中，不必为每个Task都开启一个JVM
观察控制台
观察http://hadoop103:8088/cluster
未开启uber模式，在/input路径上上传多个小文件并执行wordcount程序
在mapred-site.xml中添加如下配置
分发配置
再次执行wordcount程序
开启uber模式
测试对比
开启uber模式，实现JVM重用
从计算方向考虑
小文件解决方案
使用Sort程序评测MapReduce注：一个虚拟机不超过150G磁盘尽量不要执行这段代码
使用RandomWriter来产生随机数，每个节点运行10个Map任务，每个Map产生大约1G大小的二进制随机数
执行Sort程序
验证数据是否真正排好序了
测试MapReduce性能
综合调优
Hadoop生产调优
0 条评论
回复 删除
下一页
