1设置IP,主机名,配置SSH免密码登录
2安装JDK
3解压hadoop安装包
4配置hadoop的核心文件 hadoop-env.sh,core-site.xml , mapred-site.xml , hdfs-site.xml
5配置hadoop环境变量
6格式化 hadoop namenode-format
7启动节点start-all.sh
hadoop是项目总称,它包括HDFS和Mapreduce两个部分。
HDFS是用来存储文件的分布式系统。MapReduce是一个对数据并行计算的编程模型框架,他能把一个对大量数据的计算任务分解为多个小任务,然后交由集群中的每个节点去并行计算,算出结果后再将这些结果汇总起来得出最终结果。
简单来说就是:hdfs实现数据存储,MapReduce实现数据计算处理。
1、HDFS
HDFS是用来存储文件的分布式系统。
它是以block为单位来存储文件的。一个文件在写入hdfs时,会被自动按block大小(hadoop2默认为128m,可自定义)分成块,然后将这些块自动复制到多个DataNode上(默认复制3个副本,包含自身,可自定义)
hdfs将节点分为三种角色。namedone、datanode、Secondname。
- namenode:负责文件系统树及所有文件、目录的元数据,响应客户端请求,管理datanode上文件block的均衡,维持副本数量
- datanode: 响应来自 HDFS 客户机的读写请求。它们还响应来自 NameNode 的创建、删除和复制块的命令。datanode会周期性向Namenode汇报自己节点上所存储的Block相关信息。每条消息都包含一个块报告,NameNode 可以根据这个报告验证块映射和其他文件系统元数据。如果 DataNode 不能发送心跳消息,NameNode 将采取修复措施,重新复制在该节点上丢失的块。
- Secondname:主要负责做checkpoint操作;也可以做冷备,对一定范围内数据做快照性备份。负责辅助NN合并fsimage和edits,减少nn启动时间
2、MapReduce
MapReduce框架可以把一个计算任务分解为许多并行的小型任务,分配到所有的datanode节点上运行后,再将所有的结果汇总起来,得到最后的输出。
用四个字概括就是分而治之。
他的过程大致可以分为split map shuffle(包括map shuffle和reduce shuffle) reduce四个过程
1、Split: 将文件的每一行分割为key value的形式,传给map
2、map: 将每行继续处理,形成新的key value形式
3、map shuffle: 对经过map处理的key value进行排序,默认按key排序
4、reduce shauffle: 对排好序的数据,再根据key进行合并,相同key的数据value会被合并;最后分组形成(key,value{})形式的数据,输出到下一阶段
5、Reduce: 对value进行合并,输出最后的值
一个完整的mapreduce作业流程,包括4个独立的实体:
客户端:client,编写mapreduce程序,配置作业,提交作业。
JobTracker:协调这个作业的运行,分配作业,初始化作业,与TaskTracker进行通信。
TaskTracker:负责运行作业,保持与JobTracker进行通信。
HDFS:分布式文件系统,保持作业的数据和结果。
3、其他
Resourcemanager
Nodemanager
Journalnode:存储主备namenode之间共享数据
Zookeeper:在hadoop ha集群中负责主备namenode之间的故障转移
Zkfc:
hdfs分为namenode和datanode两种节点。
namenode负责维护一个文件系统树,以及所有数据目录及文件的元数据,datanode负责实际数据存储。
客户端向hfds写数据,首先会将数据分块,与namenode通信,namenode告知客户端将数据写入datanode的地址,第一个datanode写完后,将数据同步给第2个datanode,依次类推,直到所有备份节点写完为止,然后进入下一个数据块的写操作。
在有启用机架感知的情况下,存储策略为本地一份,同机架内其它某一节点上一份,不同机架的某一节点上一份。
客户端要向HDFS写数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后,客户端按顺序将文件逐个block传递给相应datanode,并由接收到block的datanode负责向其他datanode复制block的副本
如图:
写详细步骤:1、客户端向namenode请求上传文件,namenode检查目标文件是否已存在,父目录是否存在
2、namenode返回是否可以上传
3、client会先对文件进行切分,比如一个block块128m(dfs.block.size参数),文件有300m就会被切分成3个块,一个128M、一个128M、一个44M请求第一个 block该传输到哪些datanode服务器上
4、namenode返回datanode的服务器IP
5、client向第一台datanode请求上传数据(本质上是一个RPC调用,建立pipeline),第一个datanode收到请求会继续调用第二个datanode,然后第二个调用第三个datanode,将整个pipeline建立完成,逐级返回客户端
6、client开始往第一台datanode上传第一个block,第一台datanode收到后会复制到第二台,第二台复制第三台。
7、dataNode 向客户端通信 表示已经传完 数据块 同时向NameNode报告
8、当一个block传输完成之后,client再次请求namenode上传第二个block的服务器。如上,知道全部上传完成后,datanode向 NameNode 报告 表明 已经传完所有的数据块
https://blog.csdn.net/qq_20641565/article/details/53328279
客户端将要读取的文件路径发送给namenode,namenode获取文件的元信息(主要是block的存放位置信息)返回给客户端,客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件
1、跟namenode通信查询元数据(元数据就是哪些block在哪些datanode节点),namedone向客户端返回文件块所在的datanode服务器IP
2、客户端挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流
3、datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验)
4、客户端以packet为单位接收,先在本地缓存,然后写入目标文件,后面的block块就相当于是append到前面的block块最后合成最终需要的文件。
- NameNode在启动的时候会进入一个称为安全模式的特殊状态,它首先将映像文件(fsimage)载入内存,并执行编辑日志(edits)中的各项操作;
- 一旦在内存中成功建立文件系统元数据映射,则创建一个新的fsimage文件(这个操作不需要SecondNameNode来做)与一个空的编辑日志;
- 此刻namenode运行在安全模式,即namenode的文件系统对于客户端来说是只读的,显示目录、显示文件内容等,写、删除、重命名都会失败;
- 在此阶段namenode搜集各个datanode的报告,当数据块达到最小副本数以上时,会被认为是“安全”的。在一定比例的数据块被认为是安全的以后(datanodes blocks / total blocks 由参数dfs.safemode.threshold.pct控制,默认99.99%),再过若干时间,安全模式结束;
- 当namenode检测到副本数不足的数据块时,该块会被复制,直到达到最小副本数,系统中数据块的位置并不是由namenode维护的,而是以块列表形式存储在datanode中。
达到99.9%的阀值之后,文件系统不会立即推出安全模式,而是会等待30秒之后才会退出。
在安全模式下不可以进行以下操作:
1)创建文件夹
2)上传文件
3)删除文件
但可以查看文件系统上有哪些文件
在安全模式下:
如果一个操作涉及到元数据的修改的话。都不能进行操作
如果一个操作仅仅只是查询。那是被允许的。
所谓的安全模式,仅仅只是保护namenode,而不是保护datanode
在安全模式下强行修改会报错
hdfs dfs -rm /user/testdir/mapreduce/wordcount/input/word.txt
错误: 找不到或无法加载主类 dfsrm
手动开启安全模式的命令:
$ hdfs dfsadmin -safemode enter
Safe mode is ON手动关闭:
hdfs dfsadmin -safemode leave
MapReduce的根本思想概括来说就是“分而治之”,将一个大的计算任务分解成多个小的计算任务,由集群内的节点并行执行后,再将结果汇总起来处理后, 输出最后的值。
1、先将文件按行分割形成< key,value >对2、将分割好的< key,value>对交给用户定义的map方法进行处理,生成新的< key,value >对
3、得到map方法输出的< key,value>对后,Mapper会将它们按照key值进行排序,然后执行Combine过程,将key值相同的value值累加,得到新的< key,value>对
4、Reducer对从Mapper接收的数据进行排序,再交由用户自定义的reducer方法进行处理,得到新的< key,value>对,并作为WordCount的输出结果
a)数据经过 NameNode 传递给 DataNode
b)Client 端将文件切分为 Block,依次上传
c)Client 只上传数据到一台 DataNode,然后由 NameNode 负责 Block 复制工作
答案: B
hadoop dfsadmin –report
一、元数据的管理
NAMENODE对元数据的管理采用三种形式:
1.内存元数据(NameSystem)
2.磁盘元数据镜像文件(fsimage)
3.数据操作日志(edits)
1.元数据的存储机制
内存中有一份完整的元数据(内存 metadata)
磁盘中有一个“准完整”的元数据镜像(fsimage)
用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件)
注:当客户端对hdfs中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据会更新到内存meta.data中。
3.元数据的checkpoint
每隔一段时间,会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint)
namenode和secondary namenode的工作目录存储结构完全相同,所以,当namenode故障退出需要重新恢复时,可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录,以恢复namenode的元数据
2)checkpoint触发条件配置
此参数可以在hdfs-site.xml中配置
dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率,60秒 dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary #以上两个参数做checkpoint操作时,secondary namenode的本地工作目录
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
dfs.namenode.checkpoint.max-retries=3 #最大重试次数
dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的时间间隔3600秒
dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录
NameNode节点的作用是:
- 存储着HDFS上所有文件和目录的元数据信息
- 响应客户端的请求,给datanode发送操作指令
如果NameNode宕机且临时无法恢复,会导致整个Hadoop集群不可用。
因此,namenode的容错机制非常重要,Hadoop提供了两种机制。
没有Namenode,HDFS就不能工作。事实上,如果运行namenode的机器坏掉的话,系统中的文件将会完全丢失,因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此,namenode的容错机制非常重要,Hadoop提供了两种机制。
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时,也写入到一个远程挂载的网络文件系统。
第二种方式是运行一个辅助的Namenode(Secondary Namenode)。 事实上Secondary Namenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并,以防止操作日志文件(edit log)变得过大。通常,Secondary Namenode 运行在一个单独的物理机上,因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份,万一哪天Namenode宕机了,这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode,所以在Namenode宕机时,数据丢失是不可避免的。在这种情况下,一般的,要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用,把NFS中的Namenode元数据文件,拷贝到辅助Namenode,并把辅助Namenode作为主Namenode来运行。
镜像文件和日志文件是什么?
首先要提到两个文件edits和fsimage,下面来说说他们是做什么的。
- 集群中的名称节点(NameNode)会把文件系统的变化以追加保存到日志文件edits中。
- 当名称节点(NameNode)启动时,会从镜像文件 fsimage 中读取HDFS的状态,并且把edits文件中记录的操作应用到fsimage,也就是合并到fsimage中去。合并后更新fsimage的HDFS状 态,创建一个新的edits文件来记录文件系统的变化
那么问题来了,只有在名称节点(NameNode)启动的时候才会合并fsimage和edits,那么久而久之edits文件会越来越大,特别是大型繁忙的HDFS集群。这种情况下,由于某种原因你要重启名称节点(NameNode),那么会花费很长的时间去合并fsimge和edits,然后HDFS才能运行。
三、什么时候checkpiont
secondary NameNode 什么时候执行checkpoint来合并fsimage和eidts。呢?有两个配置参数控制:
- fs.checkpoint.period 指定两次checkpoint的最大时间间隔,默认3600秒。
- fs.checkpoint.size 规定edits文件的最大值,一旦超过这个值则强制checkpoint,不管是否到达最大时间间隔。默认大小是64M。
secondary NameNode 保存最后一次checkpoint的结果,存储结构和主节点(NameNode)的一样,所以主节点(NameNode)可以随时来读取。
如果你没有启动secondary NameNode 那么可以试试 bin/hadoop secondarynamenode -checkpoint 甚至 bin/hadoop secondarynamenode -checkpoint force. 看看生成的文件。
checkpoint可以解决重启NameNode时间过长的弊端。另外还有偏方:
四、Import Checkpoint(恢复数据)
如果主节点挂掉了,硬盘数据需要时间恢复或者不能恢复了,现在又想立刻恢复HDFS,这个时候就可以import checkpoint。步骤如下:
- 拿一台和原来机器一样的机器,包括配置和文件,一般来说最快的是拿你节点机器中的一台,立马能用(部分配置要改成NameNode的配置)
- 创建一个空的文件夹,该文件夹就是配置文件中dfs.name.dir所指向的文件夹。
- 拷贝你的secondary NameNode checkpoint出来的文件,到某个文件夹,该文件夹为fs.checkpoint.dir指向的文件夹
- 执行命令bin/hadoop namenode -importCheckpoint
这样NameNode会读取checkpoint文件,保存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage,是会执行失败的。因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性,但是不会去改动它。
值得推荐的是,你要注意备份你的dfs.name.dir和 ${hadoop.tmp.dir}/dfs/namesecondary。
五、Checkpoint Node 和 Backup Node
在后续版本中hadoop-0.21.0,还提供了另外的方法来做checkpoint:Checkpoint Node 和 Backup Node。则两种方式要比secondary NameNode好很多。所以 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node.
Checkpoint Node像是secondary NameNode的改进替代版,Backup Node提供更大的便利,这里就不再介绍了。1. Hadoop本身提供了可利用secondarynamenode的备份数据来恢复namenode的元数据的方案,但因为checkpoint(在每次 checkpoint的时候secondarynamenode才会合并并同步namenode的数据)的问题,secondarynamenode的备份数据并不能时刻保持与namenode同步,也就是说在namenode宕机的时候secondarynamenode可能会丢失一段时间的数据,这段 时间取决于checkpoint的周期。我们可以减小checkpoint的周期来减少数据的丢失量,但由于每次checkpoint很耗性能,而且这种方案也不能从根本上解决数据丢失的问题。所以如果需求上不允许这种数据的丢失,这种方案可直接不予考虑。
2. Hadoop提供的另一种方案就是NFS,一种即时备份namenode元数据的方案,设置多个data目录(包括NFS目录),让namenode在持 久化元数据的时候同时写入多个目录,这种方案较第一种方案的优势是能避免数据的丢失(这里我们暂时不讨论NFS本身会丢失数据的可能性,毕竟这种几率很小 很小)。既然可以解决数据丢失的问题,说明这套方案在原理上是可行的
参考下面一样:
Hadoop集群中,NameNode节点存储着HDFS上所有文件和目录的元数据信息
如果NameNode挂了,也就意味着整个Hadoop集群也就完了
所以,NameNode节点的备份很重要,可以从以下2个方面来备份NameNode节点
1. 在hdfs-site.xml中,配置多个name的dir到不同的磁盘分区上:
dfs.name.dir
/pvdata/hadoopdata/name/,/opt/hadoopdata/name/
2. 在另外的一台服务器上配置Secondary NameNode:它是NameNode的一个备份
Secondary NameNode会定期合并fsimage和edits日志,将edits日志文件大小控制在一个限度下
合并的时机是由2个配置参数决定的:
fs.checkpoint.period,指定连续两次检查点的最大时间间隔, 默认值是1小时。
fs.checkpoint.size定义了edits日志文件的最大值,一旦超过这个值会导致强制执行检查点(即使没到检查点的最大时间间隔)。默认值是64MB。Secondary NameNode的配置过程如下:
在conf/masters中指定第二名称节点的主机名
在core-site.xml中指定checkpoint的目录
fs.checkpoint.dir
/opt/hadoopdata/secondname,/pvdata/hadoopdata/secondname
Determines where on the local filesystem the DFS secondary
name node should store the temporary images to merge.
If this is a comma-delimited list of directories then the image is
replicated in all of the directories for redundancy.
如果NameNode节点挂了,可以按照如下步骤来从Secondary NameNode来恢复:
在dfs.name.dir指定的位置建立一个空文件夹
从Secondary NameNode上把secondname的目录给scp到新的NameNode机器的fs.checkpoint.dir下
使用hadoop/bin/hadoop namenode -importCheckpoint来启动NameNode,主要不要执行format命令
使用hadoop fsck /user命令检查文件Block的完整性。
1、Datanode工作职责:
- 存储文件;
- 在内部,文件被分割成一个或多个块(Block),并且这些块被存储在一组DataNode中;
- 负责提供来自文件系统客户端的读取和写入请求;
- 执行块创建,删除;
- 启动DN进程的时候会向NN汇报Block信息;
- 通过向NN发送心跳保持与其联系(3秒一次),如果NN10分钟没有收到DN的心跳,则认为DN已经丢失,并且复制其上的Block到其他的DN上。
2、Datanode掉线判断时限参数
datanode进程死亡或者网络故障造成datanode无法与namenode通信,namenode不会立即把该节点判定为死亡,要经过一段时间,这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout,则超时时长的计算公式为:
timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。
而默认的heartbeat.recheck.interval 大小为5分钟,dfs.heartbeat.interval默认为3秒。
。
(1) 一个数据块在 DataNode 上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳;
(2) DataNode 启动后向 NameNode 注册,通过后,周期性(1小时)的向 NameNode 上报所有的块信息;
(3) 心跳是每3秒一次,心跳返回结果带有 NameNode 给该 DataNode 的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个 DataNode 的心跳,则认为该节点不可用;
(4) 集群运行中可以安全加入和退出一些机器。
3.datanode工作机制数据完整性
1)当DataNode读取block的时候,它会计算checksum
2)如果计算后的checksum,与block创建时值不一样,说明block已经损坏。
3)client读取其他DataNode上的block.
4)datanode在其文件创建后周期验证checksum
它不是NameNode的备份,但可以作为NameNode的备份,当因为断电或服务器损坏的情况,可以用SecondNameNode中已合并的fsimage文件作为备份文件恢复到NameNode上,但是很有可能丢失掉在合并过程中新生成的edits信息。因此不是完全的备份。
由于NameNode仅在启动期间合并fsimage和edits文件,因此在繁忙的群集上,edits日志文件可能会随时间变得非常大。较大编辑文件的另一个副作用是下一次重新启动NameNode需要更长时间。SecondNameNode的主要功能是帮助NameNode合并edits和fsimage文件,从而减少NameNode启动时间。
SNN执行合并时机
- 根据配置文件配置的时间间隔fs.checkpoint.period默认1小时;
- dfs.namenode.checkpoint.txns,默认设置为1百万,也就是Edits中的事务条数达到1百万就会触发一次合并,即使未达到检查点期间。
SNN合并流程
- 首先生成一个名叫edits.new的文件用于记录合并过程中产生的日志信息;
- 当触发到某一时机时(时间间隔达到1小时或Edits中的事务条数达到1百万)时SecondaryNamenode将edits文件、与fsimage文件从NameNode上读取到SecondNamenode上;
- 将edits文件与fsimage进行合并操作,合并成一个fsimage.ckpt文件;
- 将生成的合并后的文件fsimage.ckpt文件转换到NameNode上;
- 将fsimage.ckpt在NameNode上变成fsimage文件替换NameNode上原有的fsimage文件,并将edits.new文件上变成edits文件替换NameNode上原有的edits文件。
SNN在hadoop2.x及以上版本在非高可用状态时还存在,但是在hadoop2.x及以上版本高可用状态下SNN就不存在了,在hadoop2.x及以上版本在高可用状态下,处于standby状态的NameNode来做合并操作。
HDFS对数据文件的分布式存放是按照分块block存储,每个block会有多个副本(默认为3)
机架感知是hdfs为了实现文件副本的可靠存储和高效传输而制定的一种副本存放策略 :
具体而言:
1.如果客户端是datanode,那么就将该datanode本身作为第一个块的写入机器(datanode1)。
如果是集群外部客户端,那么就从所有的slave机器中随机选择一台datanode作为第一个块的写入机器(datanode1)。
2. 随后在datanode1所属的机架以外的另外的机架上,随机的选择一台,作为第二个block的写入datanode机器(datanode2)。
3. 在写第三个block前,先判断是否前两个datanode是否是在同一个机架上,如果是在同一个机架,那么就尝试在另外一个机架上选择第三个datanode作为写入机器(datanode3)。而如果datanode1和datanode2没有在同一个机架上,则在datanode2所在的机架上选择一台datanode作为datanode3。
4. 得到3个datanode的列表以后,从namenode返回该列表到客户端之前,会在namenode端首先根据该写入客户端跟datanode列表中每个datanode之间的“距离”由近到远进行一个排序,客户端根据这个顺序有近到远的进行数据块的写入。
5. 当根据“距离”排好序的datanode节点列表返回给客户端以后,客户端便会创建Block OutputStream,并向这次block写入pipeline中的第一个节点(最近的节点)开始写入block数据。
6. 写完第一个block以后,依次按照datanode列表中的次远的node进行写入,直到最后一个block写入成功,客户端返回成功,该block写入操作结束。通过机架感知,hdfs在可靠性(副本在不同机架)和带宽(只需跨越一个机架)中做了一个很好的平衡。
HBase 使用 HDFS(或其他某种分布式文件系统,如 S3等等)来持久化存储数据。为了可以提供行级别的数据更新和快速查询,HBase 也使用了内存缓存技术对数据和本地文件进行追加数据更新操作日志。持久化文件将定期地使用附加日志更新进行更新等操作。
对数据分区,也许最重要的原因就是为了更快的查询速度。注意分区表实际上是将数据存储到不同的分区目录里,并且可以控制每次查询扫描指定的文件目录,而非全局扫描。这就是分区的意义所在。
为什么HDFS是要将文件块设计为64MB或者更大?那么如果一个文件小于64M,会不会占用空间?块大小设置大一点会有什么影响?设置小一点会有什么影响
1)topic 是按照“主题名-分区”存储的
2)分区个数由配置文件决定
3)每个分区下最重要的两个文件是 0000000000.log 和 000000.index,0000000.log
以默认 1G 大小回滚。
ZooKeeper 是一个开源的分布式协调服务,是 Google Chubby 的开源实现。分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。我们公司使用的flume集群,Kafka集群等等,都离不开ZooKeeper呀。每个节点上我们都要搭建ZooKeeper服务。首先我们要在每台pc上配置zookeeper环境变量,在cd到zookeeper下的conf文件夹下在zoo_simjle.cfg文件中添加datadir路径,再到zookeeper下新建data文件夹,创建myid,在文件里添加上server的ip地址。在启动zkserver.sh start便ok了。
随着大数据的快速发展,多机器的协调工作,避免主要机器单点故障的问题,于是就引入管理机器的一个软件,他就是zookeeper来协助机器正常的运行。
Zookeeper有两个角色分别是leader与follower ,其中leader是主节点,其他的是副节点,在安装配置上一定要注意配置奇数个的机器上,便于zookeeper快速切换选举其他的机器。
在其他的软件执行任务时在zookeeper注册时会在zookeeper下生成相对应的目录,以便zookeeper去管理机器。
YARN是Hadoop2.0版本引进的资源管理系统,直接从MR1演化而来。
核心思想:将MR1中的JobTracker的资源管理和作业调度两个功能分开,分别由ResourceManager和ApplicationMaster进程实现。
ResourceManager:负责整个集群的资源管理和调度 ;ApplicationMaster:负责应用程序相关事务,比如任务调度、任务监控和容错等。
YARN的出现,使得多个计算框架可以运行在同一个集群之中。 1. 每一个应用程序对应一个ApplicationMaster。 2. 目前可以支持多种计算框架运行在YARN上面,比如MapReduce、storm、Spark、Flink。