Mapreduce和Yarn生产上基本调优参数
文章目录
- 1.MapReduce
- 1.1.map 映射
- 1.2.reduce 归约 汇总
- 1.3.shuffle 洗牌
- 1.4.MapReduce2.x 架构设计
- 2.yarn的架构设计
- 2.1 container 容器
- 2.2 架构
- 2.2.1几个概念
- 2.2.2 client向rm提交应用程序流程
- 2.2.3 wordcount案例 理解split个数==map task个数
- 3.yarn的调优及三种资源调度方式
- 3.1.Container
- 3.2 生产如何调优container参数？
- 3.2.1 系统装完 消耗1G
- 3.2.2 系统预留20%内存（包含1G）
- 3.2.3 假设只有DN NM节点
- 3.2.4 container内存
- 3.2.5 container vcore
- 3.2.6 生产如何设置 突破口
- 3.2.7 整合memory cpu
- 3.2.7 假如该节点还有其他组件，比如HBase RS节点
- 3.3 yarn的三种资源调度器
- 3.3.1 FIFO Scheduler 先进先出
- 3.3.2 Capacity Scheduler 计算
- 3.3.3 FairScheduler 公平 生产
1.MapReduce
分布式计算框架 ，生产开发复杂累赘 基本不用
Hivesql Spark Flink
1.1.map 映射
将一组数据按照规则 映射为一组
数据条数不会发生变化
id name
1 a
2 b
3 c
4 a
select * from t;
select id,name+'1' from t;
1 a1
2 b1
3 c1
4 a1
1.2.reduce 归约 汇总
数据条数会发生变化
select
name,count(name)
from
(select id,name+'1' as name from table) t
group name;
a1 2
b1 1
c1 1
1.3.shuffle 洗牌
数据根据key进行网络传输??? 规整到一起，按规则计算
a机器 1 a 一百条
2 b 10万条
b机器 1 a 1万条
3 c 10万条
业界有句话，能不shuffle的就不要shuffle，shuffle会拉长计算的时间
1.4.MapReduce2.x 架构设计
面试题 mr on yarn提交流程
2.yarn的架构设计
2.1 container 容器
虚拟的概念
是运行在nm进程所在的机器上!
oom-killer机制
当Linux服务器某个进程使用内存超标 Linux机器为了保护自己，
主动杀死你的进程，释放内存。
tmp目录 30天机制
12G--》12平方
1平方一个房间 1台电脑 cpu vcore
1平方一个房间 2台电脑
12个房间
每个房间只有1G内存 用来计算
房间的面积是 memory
房间的电脑是 cpu vcore
房间是 container 是虚拟的概念 其实是一组memory+cpu vcore资源的组合
100件货
1 个房间 1个人：100h
升级一下
1 个房间 2个人: 50h
在内存够的情况下，适当增加cpu vcore带来计算效率的提升
2.2 架构
2.2.1几个概念
Resourcemanager 主 rm
ApplicationsManager 应用管理器 作业 程序
ResourceScheduler 资源调度器
NodeManager 从 nm
2.2.2 client向rm提交应用程序流程
1.client向rm提交应用程序（jar） 其中已经包含ApplicationMaster主程序和启动命令
2.ApplicationsManager 会为job分配第一个container，运行ApplicationMaster
3.Applicationmaster向 ApplicationsManager注册，就可以做yarn的web界面看到这个job的运行状态
4.Applicationmaster采取轮询的方式通过【RPC】协议让ResourceScheduler，申请和领取资源（哪台nm 多个内存 多少cpu vcore）
---------------------
启动app master（应用的主程序），领取到资源
5.一旦app master拿到资源列表，就和对应的nm进程通信，要求启动的任务task 计算代码
6.NM为任务设置好运行环境(container容器 包含jar包等资源) ，将任务启动命令写在一个脚本里，并通过该脚本启动任务task
7.各个任务task通过【rpc】协议向app master汇报自己的进度和状态，以此让app master随时掌握task的运行状态。
当task运行失败，会重启任务。
8.当所有task运行完成后，app master向 apps manager申请注销和关闭作业
这时在页面看 是不是完成的 完成的是成功还是失败的
---------------------
运行任务，直到任务完成。
存储 HDFS hive/hbase cassandra kudu
计算 mapreduce --》hive sql/spark/flink
资源和作业调度 yarn
2.2.3 wordcount案例 理解split个数==map task个数
split个数==map task个数
Deer Bear River 将每一行的数据 进行按空格 拆分
Deer,1
Bear,1
River,1
car,1 1
car,1 1+1=2
car,1 2+1=3
int sum = 0;
for (IntWritable val : values) {
sum += val.get();
}
result.set(sum);
context.write(key, result);
http://blog.itpub.net/30089851/viewspace-2095837/ 读读
在进行map计算之前，
mapreduce会根据输入文件计算输入分片（input split），
每个输入分片（input split）针对一个map任务，
输入分片（input split）存储的并非数据本身，
而是一个分片长度和一个记录数据的位置的数组，
输入分片（input split）往往和hdfs的block（块）关系很密切，
假如我们设定hdfs的块的大小是64mb，
如果我们输入有三个文件，大小分别是3mb、65mb和127mb，
那么mapreduce会把3mb文件分为一个输入分片（input split），
65mb则是两个输入分片（input split）而127mb也是两个输入分片
（input split），
5个分片 5个maptask
块大小有关 还和文件个数有关
换句话说我们如果在map计算前做输入分片调整，
例如不合并小文件，那么就会有5个map任务将执行，
而且每个map执行的数据大小不均，
这个也是mapreduce优化计算的一个关键点。
注意点： 文本格式
3.yarn的调优及三种资源调度方式
3.1.Container
关于Yarn的调优 就是调container
虚拟化的 是memory+cpu vcores组成的 是运行task任务的
3.2 生产如何调优container参数？
假设128G 16物理core
3.2.1 系统装完 消耗1G
3.2.2 系统预留20%内存（包含1G）
oom-kill机制
Linux系统防止夯住
给未来部署组件预留空间
128G*20%=25.6G==26G
3.2.3 假设只有DN NM节点
生产上部署一般遵循存储技术一体，就是计算时发现本节点有数据不需要去其他节点拉取，节省网络io
这种一般叫做 数据本地化
DN=2G
NM=4G
128-26=102-2-4=96G
全部用来设计给真正干活的小弟container用
3.2.4 container内存
yarn.nodemanager.resource.memory-mb 96G
yarn.scheduler.minimum-allocation-mb 1G 极限情况下 96个container 内存1G
yarn.scheduler.maximum-allocation-mb 96G 极限情况下 1个container 内存96G 少
container内存会自动增加 默认1G递增 cdh yarn配置的 但是一般不调整
3.2.5 container vcore
yarn自己设计引入概念 是虚拟core
设计初衷是考虑不同的机器的cpu的性能不一样，每个cpu计算的能力都不一样！
比如某个物理cpu是另外一个物理cpu的2倍，
这时通过设置第一个物理cpu的虚拟core来弥补这个差异。
第一台机器 强悍 pcore:vcore=1:2 16core:32vcore
第二台机器 不强悍 pcore:vcore=1:1 16core:16core
现在生产上基本上不可能设置谁强悍谁不强悍
统一 设置 pcore:vcore=1:2
为什么要设置 vcore 1:2呢？
container需要vcore 并发任务是靠vcore
pcore:vcore=1:2 32vcore
pcore:vcore=1:1 16vcore
yarn.nodemanager.resource.pcores-vcores-multiplier 2
yarn.nodemanager.resource.cpu-vcores 32
yarn.scheduler.minimum-allocation-vcores 1 极限情况下 是32个
yarn.scheduler.maximum-allocation-vcores 32 极限情况下 是1个
3.2.6 生产如何设置 突破口
cloudera公司推荐，一个container的vcore最好不要超过5个，那么设置4
yarn.scheduler.maximum-allocation-vcores 4 极限情况下，只有8个container
3.2.7 整合memory cpu
确定 4 vcore 8个container
yarn.nodemanager.resource.memory-mb 96G
yarn.scheduler.minimum-allocation-mb 1G
yarn.scheduler.maximum-allocation-mb 12G 极限情况container 8个
但是spark计算时内存有些指标比较大，那么这个参数必然调大，
那么这种理想化，完美化的设置必然被打破，到时以memory为主
yarn.nodemanager.resource.cpu-vcores 32
yarn.scheduler.minimum-allocation-vcores 1
yarn.scheduler.maximum-allocation-vcores 4
补充：
yarn.nodemanager.pmem-check-enabled false
yarn.nodemanager.vmem-check-enabled false
yarn.nodemanager.vmem-pmem-ratio 2.1 就是有个虚拟内存的概念 一般不要 不要调整这个参数
3.2.7 假如该节点还有其他组件，比如HBase RS节点
256G内存
cpu物理core 32核
DN
NM
HBase RS=30G
https://blog.csdn.net/weixin_44641024/article/details/103248842
请问以上6个参数如何设置？
3.3 yarn的三种资源调度器
bin/hadoop jar \
share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.0-cdh5.16.2.jar \
grep /wordcount/input /wordcount/output2 'dfs[a-z.]+'
sla 5个9
https://blog.csdn.net/youanyyou/article/details/79406515
3.3.1 FIFO Scheduler 先进先出
3.3.2 Capacity Scheduler 计算
而对于Capacity调度器，
有一个专门的队列用来运行小任务，
但是为小任务专门设置一个队列会预先占用一定的集群资源，
这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
3.3.3 FairScheduler 公平 生产
在Fair调度器中，
我们不需要预先占用一定的系统资源，
Fair调度器会为所有运行的job动态的调整系统资源。
如下图所示
当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；
当第二个小任务提交后，Fair调度器会分配一半资源给这个小任
务，让这两个任务公平的共享集群资源。
需要注意的是，在下图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的
Container。小任务执行完成之后也会释放自己占用的资源，
大任务又获得了全部的系统资源。
最终的效果就是Fair调度器即得到了高
的资源利用率又能保证小任务及时完成。