我爱编程

Hadoop - yarn notes2

2018-05-12  本文已影响39人  raincoffee

HDFS相关

1. HDFS读写文件过程

image

这里描述的 是一个256M的文件上传过程 ① 由客户端 向 NameNode节点节点 发出请求②NameNode 向Client返回可以可以存数据的 DataNode 这里遵循 机架感应 原则

③客户端 首先 根据返回的信息 先将 文件分块（Hadoop2.X版本 每一个block为 128M 而之前的版本为 64M）④然后通过那么Node返回的DataNode信息 直接发送给DataNode 并且是 流式写入 同时 会复制到其他两台机器⑤dataNode 向 Client通信 表示已经传完 数据块 同时向NameNode报告⑥依照上面（④到⑤）的原理将 所有的数据块都上传结束 向 NameNode 报告 表明 已经传完所有的数据块

image

读写过程链接blog

2.写HDFS时datanode处错怎么办

其中一个块坏了，只要有其它块存在，会自动检测还原。

打开一个DFSOutputStream流，Client会写数据到流内部的一个缓冲区中，然后数据被分解成多个Packet，每个Packet大小为64k字节，每个Packet又由一组chunk和这组chunk对应的checksum数据组成，默认chunk大小为512字节，每个checksum是对512字节数据计算的校验和数据。当Client写入的字节流数据达到一个Packet的长度，这个Packet会被构建出来，然后会被放到队列dataQueue中，接着DataStreamer线程会不断地从dataQueue队列中取出Packet，发送到复制Pipeline中的第一个DataNode上，并将该Packet从dataQueue队列中移到ackQueue队列中。ResponseProcessor线程接收从Datanode发送过来的ack，如果是一个成功的ack，表示复制Pipeline中的所有Datanode都已经接收到这个Packet，ResponseProcessor线程将packet从队列ackQueue中删除。在发送过程中，如果发生错误，所有未完成的Packet都会从ackQueue队列中移除掉，然后重新创建一个新的Pipeline，排除掉出错的那些DataNode节点，接着DataStreamer线程继续从dataQueue队列中发送Packet。下面是DFSOutputStream的结构及其原理，如图所示：

image

我们从下面3个方面来描述内部流程：

Client写数据时，会将字节流数据缓存到内部的缓冲区中，当长度满足一个Chunk大小（512B）时，便会创建一个Packet对象，然后向该Packet对象中写Chunk Checksum校验和数据，以及实际数据块Chunk Data，校验和数据是基于实际数据块计算得到的。每次满足一个Chunk大小时，都会向Packet中写上述数据内容，直到达到一个Packet对象大小（64K），就会将该Packet对象放入到dataQueue队列中，等待DataStreamer线程取出并发送到DataNode节点。

DataStreamer线程从dataQueue队列中取出Packet对象，放到ackQueue队列中，然后向DataNode节点发送这个Packet对象所对应的数据。

发送一个Packet数据包以后，会有一个用来接收ack的ResponseProcessor线程，如果收到成功的ack，则表示一个Packet发送成功。如果成功，则ResponseProcessor线程会将ackQueue队列中对应的Packet删除。

3.namenode的作用

namenode总体来说是管理和记录恢复功能。比如管理datanode，保持心跳，如果超时则排除。对于上传文件都有镜像images和edits,这些可以用来恢复。更多：深度了解namenode---其 内部关键数据结构原理简介http://www.aboutyun.com/forum.php?mod=viewthread&tid=7388

在HDFS中，namenode的服务提供整个HDFS文件系统的namespace管理，块管理等所有服务，metadata所有的相关服务都是由namenode进程在提供。其中包括 filename->blocksequence (namespace)，以及block->machinelist的对应表。其中前者通过fsimage写入到本地文件系统中，而后者是通过每次HDFS启动时，datanode进行blockreport后在内存中重构的数据结构。绝大部分的情况下，namenode服务进程其实都是在被动的接收服务请求 -> 进行相应的操作和更新 –> 进行适当的返回。所以，在HDFS的程序代码中，NameNode类其实只是一个用来接收被动接收调用服务的包装，它实现了ClientProtocol接口，用来接收来自DFSClient的rpc请求；它实现了DatanodeProtocol接口，用来接收来自Datanode的各种服务请求；同时它还实现了NamenodeProtocol，用来提供跟SecondaryNameNode之间的rpc请求和通信。但实际上，对NameNode的rpc调用后面的处理逻辑，以及namespace的bookkeeping，blocksmap的维护，并没有在NameNode的程序结构中包含。真正进行以上数据结构维护的，是HDFS中的FSNamesystem类。对NameNode的各种请求，比如创建，修改，删除，移动，getLocations的操作，在NameNode内部都是通过FSNamesystem提供的接口对内部数据结构进行的访问。

4.NameNode的HA

NameNode的HA一个备用，一个工作，且一个失败后，另一个被激活。他们通过journal node来实现共享数据。

https://blog.csdn.net/daydayup_668819/article/details/70815335

5 分片

https://www.cnblogs.com/qinwangchen/p/5837940.html

totalSize：是整个Map-Reduce job所有输入的总大小。

numSplits：来自job.getNumMapTasks()，即在job启动时用org.apache.hadoop.mapred.JobConf.setNumMapTasks(int n)设置的值，给M-R框架的Map数量的提示。

goalSize：是输入总大小与提示Map task数量的比值，即期望每个Mapper处理多少的数据，仅仅是期望，具体处理的数据数由下面的computeSplitSize决定。

minSplitSize：默认为1，可由子类复写函数protected void setMinSplitSize(long minSplitSize) 重新设置。一般情况下，都为1，特殊情况除外。

minSize：取的1和mapred.min.split.size中较大的一个。

blockSize：HDFS的块大小，默认为64M，一般大的HDFS都设置成128M。

splitSize：就是最终每个Split的大小，那么Map的数量基本上就是totalSize/splitSize。

接下来看看computeSplitSize的逻辑：首先在goalSize（期望每个Mapper处理的数据量）和HDFS的block size中取较小的，然后与mapred.min.split.size相比取较大的。

一个片为一个splits，即一个map，只要搞清楚片的大小，就能计算出运行时的map数。而一个split的大小是由goalSize, minSize, blockSize这三个值决定的。computeSplitSize的逻辑是，先从goalSize和blockSize两个值中选出最小的那个（比如一般不设置map数，这时blockSize为当前文件的块size，而goalSize是文件大小除以用户设置的map数得到的，如果没设置的话，默认是1），在默认的大多数情况下，blockSize比较小。然后再取blockSize和minSize中最大的那个。而minSize如果不通过”mapred.min.split.size”设置的话（”mapred.min.split.size”默认为0），minSize为1，这样得出的一个splits的size就是blockSize，即一个块一个map，有多少块就有多少map。

5 shuffle

http://www.aboutyun.com/thread-10335-1-1.html

YARN

1.架构

image

Yarn依然是Master/Slave的结构：

在资源架构层面，ResourceManager是Master，NodeManager是Slave

在应用运行期间，ApplicationMaster是Master，各个Container是Slave

ResourceManager(RM)，RM是全局的资源管理器，负责整个系统的资源管理和分配。由以下两部分组成：

调度器：根据容量、队列限制条件将系统资源分配给各个应用

资源分配的单位是container，container是一个动态资源单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定了资源使用量。

调度器是一个可插拔的组件，用户可以自己定制，也可以选择Fair或Capacity调度器

应用程序管理器：负责管理所有应用程序的以下内容：

应用提交

与调度器协商资源以启动AM

监控AM运行状态并在失败时重启它

ApplicationMaster(AM)，用户提交的每个应用程序都需要包含一个AM，它的主要功能包括：

与RM调度器协商以获取资源(以container为资源单位)

将得到的任务进一步分配给内部的任务

与NM通信以启动/停止任务

监控所有任务运行状态，并在失败时重新为任务申请资源以重启任务

Tips: 当前Yarn已经实现了两个AM：

定时向RM汇报本节点上的资源使用情况和各个container运行状态

接收并处理来自AM的container启动/停止等请求

Container，是Yarn中的资源抽象

它封装了节点上多个维度的资源(目前Yarn只支持CPU和内存两种资源)

它与slot的不同之处在于，slot是静态的(每个slot的资源相同)，container是动态的(每个container的资源可以不同)。

2.提交作业

image

当用户向YARN中提交一个应用程序之后，Yarn分两大阶段运行该应用：

第一个阶段是启动AM

第二个阶段是由AM创建应用程序，为它申请资源，并监控运行过程，直到运行结束

步骤1：用户向YARN提交应用，其中包括AM、启动AM的命令、用户程序等

步骤2：RM为该应用分配第一个Container，并与对应的NM通信，要求它在这个Container中启动应用的AM

步骤3：AM向RM注册，这样用户可以通过RM查看应用的状态。然后AM为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复以下步骤4～7

步骤4：AM采用轮询的方式通过RPC协议向RM申请和领取资源

步骤5：一旦AM获得资源，便与对应的NM通信，要求它启动任务

步骤6：NM为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过该脚本启动任务

步骤7：各个任务通过某个RPC协议向AM汇报自己的状态和进度，以让AM随时掌握状态，从而可以在任务失败时重启任务

步骤8：应用程序运行完成后，AM向RM申请注销并关闭自己。

3. yarn 组件介绍

client

image

YARN ApplicationMaster

image

AM-RM

AM通过RPC函数registerApplicationMaster向ResourceManager注册。

注册信息封装成RegisterApplicationMasterRequest对象。返回值为RegisterApplicationMasterResponse对象。包含属性：

AM通过RPC函数allocate申请资源。发送参数为AllocateRequest。主要包含以下属性

返回值为AllocateResponse。

AM通过RPC函数finishApplicationMaster告诉执行完毕。参数FinishApplicationMasterRequest。返回值FinishApplicationMasterResponse。

image

AM-NM

ApplicationMaster将申请到的资源二次分配给内部的任务，通过RPC函数startContainer与NM通信启动container。

为了实时掌握container运行状态。AM通过RPC函数getcontainerstatus向NM询问container运行状态。一个container运行万，可以通过stopcontainer释放container。

resource manager

image

node manager

image

HBASE

http://www.aboutyun.com/thread-10886-1-1.html

上一篇 下一篇

猜你喜欢

热点阅读