Mapreduce和Yarn生产上基本调优参数

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调度器即得到了高
的资源利用率又能保证小任务及时完成。
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读