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个方面来描述内部流程：

• 创建Packet

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

• 发送Packet

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

• 接收ack

发送一个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：

• DistributedShell：分布式的运行shell命令 -MRAppMaster:MapReduce应用的AMNodeManager(NM)，是每个节点上的资源和任务管理器

定时向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

• Client 通过RPC函数获取唯一的ApplicationID

• Client通过RPC函数将ApplicationMaster提交到RM上

YARN ApplicationMaster

image

AM-RM

• 注册

• 申请资源

• 告诉执行完毕

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

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

• maximumCapability 最大可申请的单个container占用的资源量

• client_t_am_token_master_key

• Application_ACLs

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

• ask请求的资源列表。每一个资源用Resourcerequest队形表示。

• release释放的container列表

• response_id 本次通信的应答id

• progress应用程序执行进度

• blacklist_request

返回值为AllocateResponse。

• a_m_command am需要执行的命令。

• response_id 本次通信的应答id

• allcated_containers 分配的container列表

• Completed_container_statuses 运行完成container状态列表

• limit集群可用资源总量

• Updated_nodes 当前集群所有节点运行状态列表

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

image

AM-NM

• 启动container

• 查询状态

• 释放container

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

• 参数startContainersRequest。

  • container_launch_context 封装了container执行环境

  • container_token 启动时候的安全令牌

• 返回值startContainersResponse

  • succeeded_requests 成功运行的container列表

  • failed_requests 运行失败的container列表

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

resource manager

image

• 与客户端交流，处理请求

• 启动管理AM，并在其运行失败时重启AM

• 管理NM，接受汇报信息，及下达管理命令

• 资源管理与调度

• 交互模块：RM对普通用户、管理员、Web提供了三种对外服务：

  • ClientRMService:为普通用户提供服务，它处理来自客户端的各种RPC，比如

    • 应用提交

    • 终止应用

    • 获取应用状态等

  • AdminService:为管理员提供的独立接口，主要目的是为了防止大量普通用户请求阻塞管理员通道，提供如下功能：

    • 动态更新节点列表

    • 更新ACL列表

    • 更新队列信息等

  • WebApp:提供一个Web界面来让用户更友好的获知集群和应用的状态

• NM管理模块：用来管理NM的模块，主要包含以下三个组件：

  • ResourceTrackerService:处理来自NodeManager的请求，主要包括：

    • 注册：注册是NM启动时发生的行为，NM提供的信息包括：节点ID、可用资源上限信息等

    • 心跳：心跳是周期行为。NM提供的信息包括：各个Container运行状态、运行的Application列表、节点健康状态等。RM返回的信息包括：等待释放的Container列表、Application列表等

  • NMLivelinessMonitor:监控NM是否活着，如果NM在一定时间(默认10m)内未上报心跳，则认为它死掉，需要移除

  • NodesListManager:维护正常节点和异常节点列表，管理exclude(类似黑名单)和include(类似白名单)节点列表，这两个列表均是在配置文件中设置的，可以动态加载。

• AM管理模块：主要是用来管理所有AM，主要包括：

  • ApplicationMasterService(AMS):处理来自AM的请求，包括：

    • 注册：是AM启动时发生的行为，信息包括：

    • AM的启动节点、对外RPC端口、trackingURL等

    • 心跳：是周期行为。AM提供的信息包括：所需资源的描述、待释放Container列表、黑名单列表等。AMS返回的信息包括：新分配的Container、失败的Container、待抢占的Container列表等

  • AMLivelinessMonitor:监控AM是否活着，如果AM在一定时间(默认10m)内未上报心路，则认为它死掉，它上面正在运行的Container将会被置为失败状态，而AM本身会被分配到另一个节点上(用户可以指定重试次数，默认5)

  • ApplicationMasterLauncher：与某个NM通信，要求它为某个应用程序启动AM

• 应用管理模块：主要是各个应用外围的管理，并不涉及到应用内部

  • ApplicationACLsManager:管理应用程序访问权限，包含两部分：

    • 查看权限：主要用于查看应用程序基本信息

    • 修改权限：主要用于修改应用程序优先级、杀死应用程序等

  • RMAppManager:管理应用程序的启动和关闭

  • ContainerAllocationExpirer:当AM收到RM新分配的Container后，必须在一定时间(默认10m)内在对应的NM上启动该Container，否则RM将强制回收该Container，而一个已经分配的Container是否该被回收则是由ContainerAllocationExpirer决定和执行的

• 状态机管理模块：RM使用有限状态机维护有状态对象的生命周期，状态机的引入使得Yarn的架构设计清晰，RM内部的状态机有：

  • RMApp:维护一个应用程序的整个运行周期，包括从启动到运行结束的整个过程由于一个APP的生命周期可能会启动多个运行实例(Attempt)，RMApp维护的是所有的这些Attempt

  • RMAppAttempt:一次应用程序的运行实例的整个生命周期，可以理解为APP的一次尝试运行

  • RMContainer:一个Container的运行周期，包括从创建到运行结束的整个过程。

  • RM将资源封装成Container发送给应用程序的AM，AM在Container描述的运行环境中启动任务。Yarn不支持Container重用，一个Container用完后会立刻释放

  • RMNode:维护了一个NM的生命周期，包括从启动到运行结束的整个过程

• 安全模块：RM自带了非常全面的权限管理机制，主要包括：

  • ClientToAMSecretManager

  • ContainerTokenSecretManager

  • ApplicationTokenSecretManager等，由于这块非常复杂，可以找个专题讨论，这里先不展开

• 调度模块：主要包含一个组件ResourceScheduler。是资源调度器，它按照一定的约束条件(比如队列容量限制等)将集群中的资源分配给各个应用程序，目前主要考虑内存和CPUResourceScheduler是一个可插拔式的模块，自带三个调度器，用户可以自己定制。

  • FIFO：先进先出，单用户

  • FairScheduler:公平调度器(FairScheduler基本上具备其它两种的所有功能)

  • CapacityScheduler:容量调度器

node manager

image

HBASE

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