Category Archives: Hadoop

1. 简介

YARN中基础调度单元是队列（queue)，每一个在 容量调度器（Capacity Scheduler）中的队列都有下面属性：
· 短队列名
· 队列路径全名
· 相关子队列和应用的列表
· 队列的保证容量（guaranteed capacity）
· 队列的最大容量（maximum capacity）
· 有效用户和他们相关的资源分配限制的列表
· 队列的状态
· 访问控制列表(ACLs)控制队列的访问 Continue reading →

ZooKeeper是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务——如同步、配置维护、群组和命名管理等。ZK具有高性能、高可用（复制）、有序等特征。请参考上一篇译文zookeeper：一个用于分布式应用的分布式协调服务。本文简单介绍一下开发中经常使用的方法（文档：ZooKeeper API）。 Continue reading →

    ZooKeeper是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务——如同步、配置维护、群组和命名管理等。它以易于编程为基本设计理念，并使用了一个类似于文件系统目录结构风格的数据模型。ZooKeeper服务运行于Java环境中并可以在Java和C中使用。
   众所周知，协调服务很难达到正确，尤其会出现竞争条件或死锁等问题。ZooKeeper设计初衷是为了缓解分布式应用从设计到实现中协调服务的问题。 Continue reading →

YARN中的资源管理器（Resource Manager）负责整个系统的资源管理和调度，并内部维护了各个应用程序的ApplictionMaster信息，NodeManager信息，资源使用信息等。在2.4版本之后，Hadoop Common同样提供了HA的功能，解决了这样一个基础服务的可靠性和容错性问题。其架构如下：

RM HA与NN HA有诸多相同之处（NameNode HA配置详解 ）：
(1). Active/Standby架构，同一时间只有一个RM处于活动状态（如上图所示）。
(2). 依赖zooKeeper实现。手动切换使用yarn rmadmin命令（类似hdfs haadmin命令)，而自动故障转移使用ZKFailoverController。但不同的是，zkfc只作为RM中一个线程而非独立的守护进程来启动。
(3). 当存在多个RM时，客户端使用的yarn-site.xml需要指定RM的列表。 客户端, ApplicationMasters (AMs)和NodeManagers (NMs) 会以轮训的方式寻找活动状态的RM，也就是说AM
s和NMs需要自己提供容错机制。如果当前活动状态的RM挂掉了，那么会继续使用轮训的方式找到新的RM。这种逻辑的实现需要在yarn.client.failover-proxy-provider中指定使用的类：org.apache.hadoop.yarn.client.RMFailoverProxyProvider
此外，新的RM可以恢复之前RM的状态（详见ResourceManger Restart )。当启动RM Restart，重启后的RM就加载之前活动RM的状态信息并继续之前RM的操作，这样应用程序定期执行检查点操作，就可以避免工作内容的丢失。在Active/standby的RM中，活动RM的状态数据需要active和standby都能访问，使用共享文件系统方法（FileSystemRMStateStore ）或者zooKeeper方法（ZKRMStateStore）。后者在同一时间只允许一个RM有写入权限。 Continue reading →

HDFS 集群中NameNode 存在单点故障（SPOF ）。对于只有一个NameNode 的集群，如果NameNode 机器出现意外downtime，那么整个集群将无法使用，直到NameNode 重新启动。HDFS 的HA 功能通过配置Active/Standby 两个NameNodes 实现在集群中对NameNode 的热备来解决上述问题。如果出现Active NN的downtime，就会切换到Standby使得NN服务不间断。HDFS HA依赖zookeeper，下面是测试的过程。

环境如下
主机：debugo0[1-3],CentOS 6.5
Hadoop 2.4.1
ZooKeeper 3.4.6

Continue reading →

YARN(Yet Another Resouce Negotiator)是Hadoop 2.0新增加的一个子项目，与Common, Mapreduce和YARN三个分支并行。它的引入使得Hadoop分布式计算系统进入了平台化时代，即各种计算框架可以运行在一个集群中，由资源管理系统YRAN进行统一的管理和调度，从而共享整个集群资源、提高资源利用率。

1. MRv1的局限性

YARN的出现是为了弥补MapReduce v1(MRv1)中的种种不足，具体表现在：
(1). 扩展性差。MRv1的jobtracker同时具备了资源管理和作业控制两个功能，是一个系统瓶颈所在。严重制约了Hadoop集群扩展性。
(2). 可靠性差。MRv1采用了master/slave结构，其中，master存在单点故障问题。
(3). 资源利用率低。MRv1采用了基于粗粒度的“槽位(slot)”的资源分配模型，通常一个任务不会用完一个槽位的资源，而其他任务也无法使用这些空闲的资源。此外，槽位分为Map slot和reduce slot两种，他们之间不能相互共享，这样就导致了一种槽位资源紧张而另一种闲置。
(4). 无法支持其他计算框架。MR框架基于磁盘数据的离线分析，满足不了应用需求。而内存计算框架、流失计算框架和迭代式计算框架也不能应用于MRv1的hadoop平台上。

hadoop的下一代计算框架MRv2将资源管理功能抽象成一个通用系统YARN，而MRv1的jobtracker和tasktrack也不复存在，计算框架(MR, storm, spark在)同时运行在YARN之上，使得hadoop进入了多计算框架的弹性计算平台时代。这样带来了种种好处：
(1). 资源利用率低。在某些时间，有些资源计算框架的集群资源紧张，而另外一些集群资源空闲。那么这些框架共享使用一个集群则可以大大提高资源利用率。
(2). 运维成本低。由多个集群集中为一个集群从而降低了运维成本。
(3). 数据共享。避免了集群之间数据移动。

2. YARN的基础架构

YARN的基本思想是将MRv1的jobtracker拆分成了两个独立的服务：一个全局的资源管理器ResouceManager和每个应用程序独有的Application Master。前者负责整个系统的资源管理和分配，后者负责单个应用的管理。YARN总体上也Master/slave架构——ResourceManager/NodeManager。前者(RM)负责对各个NodeManager(NM)上的资源进行统一管理和调度。它由两个组件构成：
(1). 调度器(Scheduler): 根据容量、队列等限制条件, 将系统资源分配给正在运行的应用程序。
(2). 应用程序管理器(ApplicationsManager, AsM): 负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMnager(AM)、监控AM运行状态并在失败的时候重启。

(pic by IBM developer)
每一个被提交的应用都会有一个对应的AM，并向RM申请NodeManager的计算资源。不同应用的Applicaion Master可以运行在不同的NodeManager中，互相不干扰。AM主要功能包括:
(1). 与RM scheduler协商以获得container资源。
(2). 将得到的任务进一步分配给内部的任务。
(3). 与NodeManager(NM)通信以启动/停止任务。
(4). 监控所有任务的运行状态。
NodeManager的作用则是负责接收并启动应用的container、而向RM回报本节点上的应用Container运行状态和资源使用情况。

3. YARN之间的通信协议

RPC协议将各个组件连接起来，每个需要通信的组件只有一个RPC协议，且有固定”客户端”和”服务器端”，每次都是由客户端向服务器端主动发起请求。

YARN使用了google的protocol buffers来保证hadoop的兼容性。YARN中主要的通信协议如下：
JobClient -> AM : ApplicationClientProtocol
Admin -> AM : ResourceManagerAdministrationProtocol
AM -> RM : ApplicationMasterProtocol
AM -> NM : ContainerManagermentProtocol – 启停container，获得各个container的使用状态信息。
NM -> RM : ResouceTracker – NM向RM注册、并定时发送心跳信息汇报当前节点的资源使用状况和container运行情况。

4. YARN的工作流程

运行在YARN上的两类应用，二者虽然作用不同，但在YARN上的运行流程是相同的：
短应用程序：一定时间（无论是秒级、小时级甚至更长时间内）可以完成并正常退出的程序。如MapReduce作业、Tez DAG作业等。
长应用程序：一般情况下永远不会退出的应用。通常指像storm service, HBase service(HMaster和RegionServer两类服务）等。它们本身作为一个框架提供API供其他用户使用。

YARN的工作流程如下:
(1). 用户向YARN ResouceManager(RM)提交应用程序，其中包括Application Master(AM)程序、启动AM命令、用户程序。
(2). RM为应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个container中启动应用程序的AM。
(3). AM先向RM进行注册，用户就可以在RM中查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束（重复4-7）。
(4). AM采用轮询的方式通过RPC协议向RM申请和领取资源。
(5). 一旦AM申请到资源后，便与对应的NodeManager（NM）通信，要求它启动任务。
(6). NM为任务设置好环境（环境变量、jar包、二进制程序等），然后将任务启动命令写到一个脚本上并执行它。
(7). 各个任务通过RPC向AM汇报自己的状态和进度。让AM随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。同样的，用户也可以随时向AM查询当前程序运行状态。
(8). 应用程序运行完成后，AM向RM注销并退出。

^^

Book: 董大《深入解析YARN架构设计与实现原理》

本文简单记录了一下使用VMware workstation 10、CentOS和HDP 2.0.6(Hadoop 2.2)发行版构建Hadoop开发测试环境的全部流程。这个过程中我遇到了不少问题，也耽误了不少的时间，所以将此文奉上，希望对大家有所帮助。
本文使用两台虚拟机搭建真实集群环境，操作系统为Cent OS 6.5。可以使用VMware Workstation的简易安装模式来进行。
Continue reading →