您的位置:首页 > 其它

MapReduce——移动数据不如移动计算

2021-06-10 18:43 99 查看 https://www.cnblogs.com/simon-

备忘

Cli:
1、会根据每次计算的数据,咨询NN元数据(block)计算:split得到一个切片清单;
这样map的数量就有了。Split时逻辑的,block是物理的。block身上有(offset,location),split和block之间有映射关系。
结果:split包含偏移量,以及split对应的map任务应该移动到哪些节点上(locations)
例如:split01 A 0 500 n1 n2 n3
可以支持计算向数据移动了~~~

2、生成计算程序未来运行时相关的配置文件xml
3、未来的移动应该相对可靠,什么可靠呢?HDFS可靠,所以cli会将jar,
split清单、配置xml,上传到HDFS目录中(上传的数据副本数10)
4、cli会调用JobTracker,通知要启动一个计算程序了,并且告知文件存在HDFS的什么位置上

JobTracker 收到启动程序后
1、从HDFS中拉取Split清单
2、根据自己收到的TT汇报的资源,最终确定每一个split对应的map应该到哪一个节点中去【确定的清单】
3、TaskTracker会在心跳的时候取回分配给自己的任务信息

TaskTracker在心跳取回任务信息后
1、从HDFS中下载jar包,xml到本地
2、最终【启动】任务描述中的mapTask/reduceTask
[ 最终代码在某一个节点被启动,通过Cli上传,TT下载 ]

JobTracker 存在的问题:
1、单点故障
2、压力过大
3、集成了资源管理和任务调度,两者耦合【线程和进程】
弊端:
1、重复造轮子
2、多种计算框架各自实现资源管理,部署在同一批硬件上,进程隔离,造成资源争抢

========================================================

Hadoop 2.x 出现了Yarn 【线程进程,一脉相承】
1、Cli提交任务,RM会在一台不太忙的NM中启动APP Master--相当于被阉割过的JobTRacker【只管任务调度,不管资源管控】。
2、APP Master从HDFS上取回切片清单,再向RM申请Container.
3、RM根据自己掌握的资源情况,在一些合适的节点上启动Container.
4、Container需要向App master 反向注册,APP Master知道了有多少资源可用。就通过消息(而不是任务代码)将任务分配给Container;
5、Container 从HDFS上拉取Jar,执行任务。

Container
虚拟的:
对象:属性:CPU、mem、I\O量
物理的:
JVM->操作系统进程
1、NM会有线程监控container资源情况,如果超额则直接杀死;
2、CGroup内核级技术:在启动JVM进程的时候,由Kernel直接约束死资源量;

实现架构:
RM:负责整体资源的管理;
NN:汇报心跳,提交自己的资源情况;

MR 运行:
1、CLi(切片清单/配置/jar/上传到HDFS),访问RM申请AppMaster;
2、RM选择一台不忙的节点通知NM启动一个Container,在里面反射一个MRAppMaster
3、启动MRAppMaster,从HDFS下载切片清单,向RM申请资源启动Container;
4、RM根据资源状况得到一个确定的清单,通知NM启动Container;
5、Container 会反向注册到MRAppMatser进程;
6、MRAppMatser可以认为阉割版的JobTracker,最终将任务【消息】发送给Container;
7、Container会反射相应的类,调用方法,运行得到结果。

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐