整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

9.构建Hadoop集群

本章介绍如何在一个计算机集群上构建Hadoop系统。尽管在单机上运行 HDFSMapReduce有助于学习这些系统,但是要想执行一些有价值的工作,必须在多节点系统上运行。

 

有多个选择来获得一个Hadoop集群,从建立一个专属集群,到在租借的硬 件设备上运行Hadoop系统,乃至干使用在云端提供的Hadoop服务。本章和下一章提供了足够的信息来构建和操作Hadoop集群。有些读者可能正在 使用Hadoop服务,并且已经做了大量日常维护操作,对于这些读者,阅读 这两章内容仍然有助于从操作的角度深入理解Hadoop的工作机制。

9.1.集群规范

Hadoop运行在商业硬件上。用户可以选择普通硬件供应商生产的标准化的、广泛有效的硬件来构建集群,无需使用特定供应商生产的昂贵、专有的硬件设备。

 

首先澄清两点。第一,商业硬作并不等同于低端硬件。低端机器常常使用便宜的零部件,其故障率远高于更贵一些(但仍是商业级别)的机器。当用户管理几十台、上百台,甚至几千台机器时,选择便宜的零部件并不划算, 因为更髙的故障率推高了维护成本。第二,也不推荐使用大型的数据库级别的机器,因为这类机器的性价比太低了。用户可能会考虑使用少数几台数据库级别的机器来构建一个集群,使其性能达到一个中等规模的商业机器集群。然而,某一台机器所发生的故障会对整个集群产生更大的负面影响,原因在于更大比例的集群硬件将无法使用。 硬件规格很快就会过时。但为了举例说明,下面列举一下硬件规格。在2010年年中,运行Hadoopdatanodetasktracker的典型机器具有以下规格:

 •  处理器,两个四核2〜2.5 GHzCPU

 •  内存,16~24 GB ECC RAM®

 •  存储器,4xlTBSATA硬盘

  •  网络,千兆以太网

尽管各个集群采用的硬件规格肯定有所不同,但是Hadoop —般使用多核 CPU和多磁盘,以充分利用硬件的强大功能。

为何不使用RAIO?

尽管建议采用RAID(Redundant Array of lndependent Disk,即磁盘阵列)作为 namenode的存储器以保护元数据,但是若将RAID作为datanode的存储设备则不会给HDFS带来益处。HDFS所提供的节点间数据复制技术已可满足数据备份需求,无需使用RAID的冗余机制。

此外,尽管RAID条带化技术(RAID 0)被广泛用于提升性能,但是其速度仍然比用在HDFS里的JBOD(Just a Bunch Of Disks)配置慢。JBOD在所有磁 盘之间循环调度HDFS块。RAID 0的读写操作受限于磁盘阵列中最慢盘片的速度,而JBOD的磁盘操作均独立,因而平均读写速度高于最慢盘片的 读写速度„需要强调的是,各个磁盘的性能在实际使用中总存在相当大的差异,即使对于相同型号的磁盘。针对某一雅虎集群的评测报告表明,在一个测试(Gridmix) 中,JBODRAID 010%;在另一测试(HDFS写吞吐量)中,JBODRAID 0 30%

最后,若JBOD配置的某一磁盘出现故障,HDFS可以忽略该磁盘,继续工作。而RAID的某一盘片故障会导致整个磁盘阵列不可用,进而使相应节 点失效。

 

Hadoop的主体由Java语言写成,能够在任意一个安装了 JVM的平台上运行。但由于仍有部分代码(例如控制脚本)需在Unix环境下执行,因而

Hadoop并不适宜以最终产品的形态运行在非Unix平台上。

事实上,Windows操作系统主要作为一个开发平台(安装了 Cygwin之后), 而非生产平台,详情参见附录A

一个Hadoop集群到底应该有多大?这个问题并无确切答案。但是,Hadoop 的魅力在于用户可以在初始阶段构建一个小集群(大约10个节点),并随存储与计算需求增长持续扩充。从某种意义上讲,更恰当的问题是:你的集群需要增长得多快?用户通过以下一个关于存储的例子可以体会更深。

假如数据每周增长1TB。如果采用三路HDFS复制技术,则每周需要增加 3 TB存储能力。再加上一些中间文件和日志文件(约占30%),基本上相当于每周添设一台机器(2010年的典型机器)。实际上,用户一般不会每周去购买一台新机器并将其加入集群。类似粗略计算的意义在于让用户了解集 群的规模:在本例中,保存两年数据大致需要100台机器。

对于一个小集群(几十个节点)而言,在一台master机器上同时运行 namenodejobtracker通常没问题(需确保至少一份namenode的元数据被另存在远程文件系统中)。随着HDFS中的集群和文件数不断增长, namenode需要使用更多内存,在这种情况下namenodejobtracker,最好 分別放在不同机器中。

辅助namenode可以和namenode —起运行在同一台机器之中,但是同样由 于内存使用的原因(辅助namenode和主namenode的内存需求相同),二者 最好运行在独立的硬件之上;对于大规模集群来说,更是如此。详情可参 见9.4.1节对主节点场景的讨论。运行namenode的机器一般采用64位硬 件,以避免在32位体系结构下Java堆的3 GB内存限制。®

网络拓扑

Hadoop集群架构通常包含两级网络拓扑,如图9-1所示。一般来说,各机架装配30~40个服务器,共享一个1 GB的交换机(该图中各机架只画了 3 个服务器),各机架的交换机又通过上行链路与一个核心交换机或路由器(通常为1GB或更高)互联。该架构的突出特点是同一机架内部的节点之间的总带宽要远高于不同机架上的节点间的带宽。

 

图片.png 

 

机架的注意事项

为了达到Hadoop的最佳性能,配置Hadoop系统以让其了解网络拓扑状况就极为关键。如果集群只包含一个机架,就无需做什么,因为这是默认配置。但是对于多机架的集群来说,描述清楚节点机架间的映射关系就很有必要。这样的话,当HadoopMapReduce任务分配到各个节点时,会倾向于执行机架内的数据传输(拥有更多带宽),而非跨机架数据传输。HDFS 将能够更加智能地放置复本(replica),以取得性能和弹性的平衡。

 

诸如节点和机架等的网络位置以树的形式来表示,从而能够体现出各个位 置之间的网络“距离”。namenode使用网络位置来确定在哪里放置块的复 本(参见3.6.2节);MapReduce的调度器根据网络位置来查找最近的复 本,将它作为map任务的输入。

 

在图9-1所示的网络中,机架拓扑由两个网络位置来描述,即/switch1/rack1 和Awz7c/z//racA:2。由于该集群只有•个顶层路由器,这两个位置可以简写 为/switch1和/rack2

Hadoop配置需要通过一个Java接口 DNSToSwitchMapping来指定节点地址和网络位置之间的映射关系。该接口定义如下:

public interface DNSToSwitchMapping {
public List<String> resolve(List<String> names);
  }

 resolve()函数的输入参数names描述IP地址列表,返回相应的网络位置字符串列表。topology .node .switch.mapping.impl 配置属性实现了 DNSToSwitchMapping 接口,namenode jobtracker 均采用它来解析工作节点的网络位置。

在上例的网络拓扑中,可将nodel、node2node3映射到/rack1,将 node4node5 node6映射到/rack2中。

但是,大多数安装并不需要额外实现新的接口,只需使用默认ScriptBasedMapping实现即可,它运行用户定义的脚本来描述映射关系。脚本的存放路径由属性topology.script.file.name控制。脚本接 受一系列输入参数,描述带映射的主机名称或IP地址,再将相应的网络位 置以空格分开,输出到标准输出。

如果没有指定脚本位置,默认情况下会将所有节点映射到单个网络位置,即/default-rack。

9.2集群的构建和安装

硬件备齐之后,下一步就是装配设备,从零开始安装所需软件以运行Hadoop .

安装和配置Hadoop有多种方式。本章介绍如何使用Apache Hadoop分发包安装Hadoop,同时也介绍一些在安装过程中需要仔细思考的背景知识。此外,如果用户想用RPMDebian包来管理Hadoop安装,则要先安装Clouderas Distribution for Hadoop,详细介绍可参见附录 B

用户可以采用自动安装方法来减轻在各节点上安装和维护相同软件的负担,例如 Red Hat Linux 的 Kickstart Debian Fully Automatic Installation 等。这些工具通过记录问答环节中用户给出的答案(例如磁盘分区设置)和待 安装的包列表等信息来实现自动化安装。更为关键的是,这些工具还提供钩子(hook)以在安装过程末期运行某些脚本。尽管这些脚本并不包含在标准安装程序中,但对调整和定制最终系统非常重要。

下面几个小节将描述运行Hadoop所需的一些个性化设置,这些内容需要被添加到安装脚本之中。

9.2.1 安装 Java

运行Hadoop需要Java 6或更新版本。尽管很多供应商的Java分发包可能也会正常工作,但是首选方案是采用最新稳定版本的Sun JDK。下列指令检査Java是否已被正确安装:

% java -version
java version "1.6.0_12"
3ava(TM) SE Runtime Environment (build 1.6.0_12-b04)
]ava HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

9.2.2创建Hadoop用户 

最好创建特定的Hadoop用户帐号以区分Hadoop和本机上的其他服务。

对于小规模集群来说,有些管理员选择将该新用户的home目录设在NFS 挂载的驱动器上,以辅助SSH密钥分发(参见以下讨论)。一般而言,NFS 服务器在Hadoop集群之外。如果用户选择使用NFS,则有必要考虑 autofs,它提供按需挂载NFS文件系统的功能,即系统访问它时才挂载。autofs也提供一些措施来应对NFS服务器发生故障的情况——发生故障时会 切换到复本文件系统。同时还需要关注NFS的其他特性,例如UIDGID 的同步。有关在Linux系统上搭建NFS的其他信息。

9.2.3安装 Hadoop

从 Apache Hadoop 的发布页面(http//hadoop.apache.org/core/releases.html)下载Hadoop发布包,并在某一本地目录解压缩,例如 /usr/local(/opt/是另一标准选项)。注意,鉴于hadoop用户的home目录可能挂载在NFS上, Hadoop系统最好不要安装在该目录上:

% cd /usr/local
% sudo tar xzf hadoop-x.y. z. tar.gz

此外,还需将Hadoop文件的拥有者改为hadoop用户和组:

% sudo chown -R hadoop:hadoop hadoop-x.y. z

一些管理员喜欢将HDFS和MapReduce安装在同一系统的不同位置中。在本书写就之际,仅当HDFSMapReduce均属于同一个 Hadoop发布时,二者才是兼容的。但在未来的发布版本中,兼容性 限制会逐步放宽。在这种情况下,由于具备更多升级选项,分别独立安装这两款软件会更加合理(详见10.3.3)。例如,可以一边便捷地升级MapReduce(可能打一个补丁),一边仍然运行HDFS

 注意,即使独立安装HDFS和MapReduce,它们仍然可以共享配置信息,其方法是使用–config选项(启动守护进程时)指向同一配置目录。鉴干它们所产生的日志文件的名称不同,不会导致冲突,因此仍然可以将日志输出到同一个目录中。

9.2.4测试安装

准备好安装脚本之后,就可以在集群的机器上进行安装、测试。鉴于安装文件之间存在一些相互依赖关系,整个过程将会迭代多次。系统正常启动之后,用户可进一步配置Hadoop并且试运行。该过程将在后续小节中详细描述。

9.3SSH配置

Hadoop控制脚本(并非守护进程)依赖SSH来执行针对整个集群的操作。例如,某个脚本能够终止并重启集群中的所有守护进程。值得注意的是,控制脚本并非唯一途径,用户也可以利用其他方法执行集群范围的操作(例如 分布式shell)。 为了支持无缝式工作,SSH安装好之后,需要允许hadoop用户无需键入密码即可登陆集群内的机器。最简单的方法是创建一个公钥/私钥对,存放在NFS之中,让整个集群共享该密钥对。

首先,以某hadoop用户帐号登录后,键入以下指令来产生一个RSA密钥对

% ssh-keygen -t rsa -f ~/.ssh/id_rsa

尽管期望无密码登录,但无口令的密钥并不是一个好的选择(运行在本地伪分布集群上时,倒也不妨使用一个空口令,参见附录A)。因此,当系统提 示输入口令时,用户最好指定一个口令。可以使用以免为每个连 接逐一输入密码。

私钥放在由-f选项指定的文件之中,例如~/.ssh/id_rsa。存放公钥的文件名称与私钥类似,但是以“.pub”作为后缀,例如~/.ssh/id_rsa.pub。

接下来,需确保公钥存放在用户打算连接的所有机器的~/.ssh/authorized_keys文件中。如果hadoop用户的home目录是在NFS文件系统中(如前所述),则可以键入以下指令在整个集群内共享密钥:

% cat ~/ .ssh/id_rsa.pub >> ~/.ssh/authorized_keys

如果home目录并没有通过NFS共享,则需要利用其他方法共享公钥(比如 ssh-copy-id)

 测试是否可以从主机器SSH到工作机器。若可以,则表明ssh-agent正在运行。®再运行ssh-add而来存储口令。这样的话,用户即可不用再输入口令就能到一台工作机器。

 

9.4Hadoop 配置

有多个配置文件适用于Hadoop安装,表9-1列举了最重要的几个文件。本节讨论MapReduce 1,可配置jobtrackertasktracker守护进程。有关 MapReduce 2的安装配置与运行MapReduce 1明显不同,请参考9.5节。

这几个重要文件都放在Hadoop分发包的conf目录中。配置目录被重新放 在文件系统的其他地方(Hadoop安装的外面,以便于升级),但是守护 进程启动时需要使用–config选项,以指向本地文件系统的某个目录。

表9-1.Hadoop配置文件

文件名称

格式

描述

hadoop-env.sh

Bash脚本

记录脚本中要用到的环境变a,以运行 Hadoop

core-site.xml

Hadoop 配置 XML

Hadoop Core的配置项,例如HDFS和 MapReduce常用的I/O设置等

hdfs-site.xml

Hadoop 配置 XML

Hadoop守护进程的配置项,包括 namenode、辅助 namenode 和 datanode 等

mapred-site.xml

Hadoop 配置 XML

MapReduce守护进程的配置项,包括 jobtracker 和 tasktracker(每行一个)

masters

纯文本

运行辅助namenode的机器列表(每行一个)

slaves

纯文本

运行datanode和tasktracker的机器列表(每行一个)

hadoop-metrics.properties

Java属性

控制如何在Hadoop上发布度量的属性(参见10.2.2 节)

log4j.properties

Java属性

系统日志文件、namenode审计日志、 tasktracker子进程的任务日志的属性(参见 5.5.6 节)

 

9.4.1 配置管理

Hadoop并没有将所有配置信息放在一个单独的全局位置中。反之,集群的每个Hadoop节点都各自保存一系列配置文件,并由管理员完成这些配置文件的同步工作。Haddoop提供一个基本工具来进行同步配置,即rsync(参见后文的讨论)。此外,诸如dsh或pdsh等并行shell工具也可完成该任务。

 

Hadoop也支持为所有master机器和worker机器采用同一套配置文件。这个做法的最大优势在于简单,不仅体现在理论上(仅需处理一套配置文件),也体现在可操作性上(使用Hadoop脚本就能进行管理)

 

但是,这种一体适用的配置模型并不合适某些集群。以扩展集群为例,当试图为集群添加新机器,且新机器的硬件规格与现有机器不同时,则需要 新建一套配置文件,以充分利用新硬件的额外资源。

 

在这种情况下,需要引入“机器类”的概念,为每一机器类维护单独的配置文件。Hadoop没有提供执行这个操作的工具,需要借助外部工具来执行 该配置操作,例如ChefPuppetcfenginebcfg2等。

 

 对于任何规模的集群来说,同步所有机器上的配置文件都极具挑战性。例如,假设某台机器正好处于异常状态,而此时用户正好发出一条更新配置的指令,如何保证这台机器在恢复正常状态之后也能够更新配置?这个问题很严重,可能会导致集群中各机器的配置不一致。因此,尽管用户能'够使用控制脚本来管理Hadoop,仍然推荐使用控制管理工具管理集群。使用这些工具也可以顺利完成日常维护,例如为安全漏洞打补丁、升级系统包等。

1.控制脚本

Hadoop内置一些脚本来运行指令、在集群内启动和终止守护进程。为了运行这些脚本(存放在bin目录中),需要预先知道集群内的所有机器。有两个文件能达成该目标,即masters和slaves。各文件逐行记录一些机器的名称或IP地址。masters文件的名称确实有点误导人,它主要记录拟运行辅助namenode的所有机器。slaves文件记录了运行datanode和tasktracker的所有机器。这两个文件存放在配置目录之中。用户也可以改变hadoop_env.sh的HADOOP_SLAVES项的值,将slaves文件放在其他地方(也可以改变文件名称)。此外,这些文件无需分发到各个工作节点,因为只有运行在namenodejobtracker上的控制脚本能使用这些文件。

 

用户无需指定究竟由masters文件中的哪台(或哪些)机器来运行namenodejobtracker,这是由运行脚本的机器决定的。(实际上,在masters文件上指定机器会导致在这台(或这些)机器上运行一个辅助namenode,而这可能违背用户期望。)例如,start-dfs.sh脚本用于启动集群中所有的HDFS守护进程,它会在运行该脚本的机器上启动namenode。详细步骤如下。

 

(1)在本地机器上启动一个namenode(脚本所运行的机器)

 

(2)在slaves文件中记录的各机器上启动一个datanode。

 

(3)在masters文件中记录的所有机器上均启动一个辅助namenode。

 

脚本文件start-mapred.sh与start-dfs.sh类似,它启动集群中所有的 MapReduce守护进程。详细步骤如下。

 

(1)在本地机器上启动一个jobtracker。

(2)在slaves文件记录的每台机器上启动一个tasktracker。

 

注意,MapReduce控制脚本不使用masters文件。

 

此外,stop-dfs.sh和stop-mapred.sh脚本能终止由相关启动脚本启动的守护进程。

如果用户已经使用前述脚本,则不宜直接调用hadoop-daemon.sh。但是如果用户需要从其他系统(或利用自己编写的脚本)控制Hadoop守护进程,则可以调用 hadoop-daemon.sh 脚本。类似地,hadoop-daemons.sh(注意,多了 “s”后缀)用于在多个主机上启动同一守护进程。

2.master节点场景

由于集群规模差异较大,对于主节点守护进程的配置也差异很大,包括 namenode、辅助namenodejobtracker。对于一个小型集群来说(几十个节点),可以直接将这些守护进程放到单独的一台机器上。但是,对于大型集群来说,则最好让这些守护进程分别运行在不同机器上。

namenode在内存中保存整个命名空间中的所有文件元数据和块元数据,其内存需求很大。辅助namenode在大多数时间里空闲,但是它在创建检查点时的内存需求与主namenode差不多。详情参见10.1.2节对文件系统映像和编辑日志的讨论。一旦文件系统包含大量文件,单台机器的物理内存便无法同时运行主namenode和辅助namenode

辅助namenode保存一份最新的检査点,记录它创建的文件系统的元数据。将这些历史信息备份到其他节点上,有助于在数据丢失(或系统崩溃)情况下 恢复namenode的元数据文件。详见第10章的讨论。

在一个运行大量MapReduce作业的高负载集群上,jobtracker会占用大量内存和CPU资源,因此它最好运行在一个专用节点上。

不管主守护进程运行在一个还是多个节点上,以下规则均适用:

  •在namenode机器上运行HDFS控制脚本。wakens文件包含辅助 namenode的地址

  •在jobtracker机器上运行MapReduce控制脚本

 

当namenode和jobtracker运行在不同节点之上时,集群中的各节点将运行一个datanode和一个tasktracker,因此各个slaves文件要保持同步。

 

9.4.2环境设置

本节探讨如何设置hadoop-env.sh文件中的变量。

1.内存

在默认情况下,Hadoop为各个守护进程分配1000 MB(IGB)内存。该内存值由 hadoop-env.sh文件的 HADOOP_HEAPSIZE 参数控制。此外,tasktracker 启动独立的子JVM以分别运行mapreduce任务。因此,需要综合考虑上述因素来计算一个工作机器的最大内存需求。

一个tasktracker所能够同时运行別最大map任务数由 mapred.tasktracker.map.tasks.maximum 属性控制,默认是2个任务。相应的,一个tasktracker所能够同时运行的最大reduce任务数由 mapred.tasktracker.reduce.tasks.maximum 属性控制,默认值也是

2。因此,也可以说tasktracker拥有2map槽和2reduce槽。

分配给每个子JVM的内存量由mapred.child.java.opts属性决定,默认值是-Xmx200m,表示每个任务分配200 MB内存。顺便提一句,用户也可以提供其他JVM选项。例如,启用verbose GC Logging工具以调试GC。综上所述,在默认情况下,一个工作机器会占用2800 MB内存(参见 表 9-2)

表9-2.计算工作节点的内存占用量

JVM

默认内存占用量(MB) 8

处理器机器的内存占用量,每个 子任务分配400 MB

datanode

1000

1000

tasktracker

1000

1000

tasktracker 的子 map 任务

2 x 200

7 x 400

tasktracker 的子 reduce 任务

2 x 200

7 x 400

总计

2800

7600

在一个tasktracker上能够同时运行的任务数取决于一台机器有多少个处理器。由于MapReduce作业通常是I/0受限的(即完成整项计算任务的时间开销主要在于I/O操作),因此将任务数设定为超出处理器数也有一定道理,能够获得更好的利用率。至于到底需要运行多少个任务,则依赖于相 关作业的CPU使用情况,但经验法则是任务数(包括mapreduce任务)与处理器数的比值最好在12之间。

 例如,假设客户拥有8个处理器,并计划在各处理器上分别跑2个进程,则可以mapred.tasktracker.map.tasks.maximummapred.tasktracker reduce .tasks.maximum的值分别设为7(考虑到还有datanodetasktracker这两个进程,这两项值不可设为8)。如果各个子任务的可用内存 增至400 MB,则总内存开销将高达7600 MB(参见表9-2)。

 

对于配备8 GB物理内存的机器,该Java内存分配方案是否合理还取决于在这台机器上同时运行的其他进程。例如,若还试图在这台机器运行 Streaming和管道等程序,则该分配方案并不恰当(而且分配到子任务的内存 将会减少),因为无法为其他进程(包括Streaming和管道)分配足够的内存。此时,各进程在系统中不断切换,导致服务性能恶化。精准的内存设置极度依赖于集群自身的特性。用户需要持续监控集群的内存使用情况,并实 时设定优化分配方案。Ganglia(参见10.2.3)就是实时搜集此类信息的有效工具。读者也可参考9.4.5节加深理解。

Hadoop也可设置MapReduce操作所能使用的最大内存量。这类设置分别针对各项作业进行,详情可参见6.4)

对于主节点来说,namenode、辅助namenodejobtracker守护进程在默认情况下各使用1000MB内存,所以总计3000 MB

一个守护进程究竟需要多少内存?

由于namenode会在内存中维护所有文件的每个数据块的引用,因此 namenode很可能会“吃光”分配给它的所有内存。很难套用一个公式来精确计算内弁需求量,因为存需求量取决于多个因素,包括每个文件包含的数据块数、文件名称的在度、文件系统中的目录数等。此外,在不同 Hadoop.本下,namenode的内存需求也不相同。

1000 MB内存(默认配置)通常足够管理数百万个文件。但是根据经验来看,保守估计需要为每1百万个数据块分配1000 MB内存空间。

以一个含200节点的集群为例,假设每个节点有4 TB磁盘空间,数据块大小是128 MB,复本数是3的话,则约有2百万个数据块(甚至更多): 200×4 000 000 MB/(128MBx3)。因此,在本例中,namenode 的内存空间 最好一开始设为2000 MB

也可以只增加namenode的内存分配量而不改变其他Hadoop守妒进程的内存分配,即设置hadoop-env.sh文件的HADOOP_NAMEMODE_OPTS属性包含一个JVM选项以设定内存大小。HADOOP_NAMENODE_OPTS允许向 namenodeJVM传递额外的选项。以SunJVM为例,-Xmx2000m选项表 示为namenode分配2000 MB内存空间

由于辅助namenode的内存需求量和主namenode差不多,所以一旦更改 namenode的内存分配的话还需对辅助namenode做相同更改(使用 HADOOP_SECONDARYNAMENODE_OPTS 变量)。在本例中,辅助 namenode—般与主namenode运行在不同机器上。


此外,也存在设置其他Hadoop守护进程的响存分配量的环境变量。用户 可以利用这些变量更改特定守护进程的内存分配量。详见hadoop-env.sh文件。

2.Java

需要设置Hadoop系统的Java安装的位置。方法一是在hadoop-env.sh文件 中设置JAVA_H0ME项;方法二是在shell中设置JAVA_H0ME环境变量。相比之下,方法一更好,因为只需操作一次就能够保证整个集群使用同一版本的Java。

3.系统日志文件

默认情况下,Hadoop生成的系统日志文件存放在$HADOOP_INSTALL/logs目录之中,也可以通过hadoop-env.sh文件中的HAD00P_L0G_DIR来进行修改。建议修改默认设置,使之独立于Hadoop的安装目录。这样的话,即使 Hadoop升级之后安装路径发生变化,也不会影响日志文件的位置。通常可以将日志文件存放在目录中。实现方法很简单,就是在hadoop-env.sh中加入以下一行:

   export HAD00P_L0G_DIR=/var/log/hadoop

如果日志目录并不存在,则会首先创建该目录(如果操作失败,请确认 Hadoop用户是否有权创建该目录)。运行在各台机器上的各个Hadoop守护 进程会产生两类日志文件。第一类日志文件(以.log作为后缀名)是通过 log4j记录的。鉴于大部分应用程序的日志消息都写到该日志文件中,故障诊断的首要步骤即为检查该文件。标准的Hadoop log4jj配置采用日常滚动文件后缀策略(Daily Rolling File Appender)来命名日志文件(即:首先设定一个日期模式,例如“yyyy-mm-dd”;在某一天产生的日志文件就在名称前缀后面添加一个遵循日期模式的后缀名)。系统并不自动删除过期的日志文 件,而是留待用户定期删除或存档,以节约本地磁盘空间。

第二类日志文件后缀名为.out,记录标准输出和标准错误日志。由于 Hadoop使用log4j记录日志,所以该文件通常只包含少量记录,甚至为空。重启守护进程时,系统会创建一个新文件来记录此类日志。系统仅保留最新的5个日志文件。旧的日志文件会附加一个介于15之间的数字 后缀,5表示最旧的文件。

日志文件的名称(两种类型)包含运行守护进程的用户名称、守护进程名称和本地主机名等信息。例如,hadoop-tom-datanode-sturges.ocal.log.2008-07-04就是一个日志文件的名称。这种命名方法保证集群内所有机器的日志文 件名称各不相同,从而可以将所有日志文件存到一个目录中。

日志文件名称中的“用户名称”部分实际对应hadoop-env.sh文件中 的HADOOP_IDENT_STRING项。若想采用其他名称,可以修改 HADOOP_IDENT_STRING 项。

4.SSH设置

借助SSH协议,用户在主节点上使用控制脚本就能在(远程)工作节点上运 行一系列指令。自定义SSH设置会带来诸多益处。例如,减小连接超时设定(使用ConnectTimeout选项)可以避免控制脚本长时间等待宕机节点的响应。当然,也不可设得过低,否则会导致繁忙节点被跳过。

StrictHostKeyChecking也是一个很有用的SSH设置。设置为no会自动将新主机键加到已知主机文件之中。该项的默认值是ask,提示用户确认 是否已经验证了“键指纹”(key fingerprint),因此不适合大型集群环境®

在hadoop-env.sh文件中定义HADOOP_SSH_OPTS环境变量还能够向SSH传递更多选项。参考sshssh_config手册,了解更多SSH设置。

利用rsync工具,Hadoop控制脚本能够将配置文件分发到集群中的所有节点。默认情况下,该功能并未启用!为了启用功能,需要在hadoop-env.sh文件中定义HADOOP_MASTER项。工作节点的守护进程启动之后,会把以 HADOOP_MASTER为根的目录树与本地的HADOOP_INSTALL目录同步。

如果Hadoop系统的两个主进程(namenodejobtracker)分别运行在不同机器上,该如何执行上述操作?可以任选一台机器为源,另一台机器就能 够像其他工作节点一样通过rsync工具进行同步。实际上,任意一台机器均 可作为rsync的源,即使该机器处在Hadoop集群外部。

在默认情况下并未设置HADOOP_MASTER项,这就引发一个问题:如何确保每个工作节点的文件已经设置好HADOOP_MASTER?对于小型 集群来说很容易解决:编写一个脚本文件,将主节点的心办印文件 复制到所有工作节点即可。对于大型集群来说,既可以采用dsh之类的工具来复制文件,也可以将hadoop-env.sh文件作为自动安装脚本的一部分(例如 Kickstart)

考虑一个已经启用远程同步功能的大型集群。当集群启动时,所有工作节点几乎同时启动,并向主节点发出rsync请求,很可能导致主节点瘫痪。为了避免发生这种情况,需要将HADOOP_SLAVE_SLEEP项设为一小段时间, 例如0.1(表示0.1秒钟),使主节点在相继调用两个工作节点的指令的间隙主动休眠一段时间。

9.4.3 Hadoop守护进程的关键属性

Hadoop的配置属性之多简直让人眼花缭乱。本节讨论对于真实的工作集群 来说非常关键的一些属性(或至少能够理解默认属性的含义),这些属性分散 在三个文件之中,包括 coresite.xmlhdfssite.xml  mapredsite.xml。范例9-1、9.29.3列举了这些文件的典型设置。这些属性大 多被标记为final,以避免被作业配置重写。要想进一步了解如何写配置文 件,可参见5.1节。

范例9-1.典型的core-site.xm丨配置文件


<?xml version="l.0"?>
<!-- core-site.xml -->
<configuration>
    <property>
        <name>fs.default.name</name〉
        <value>hdfs://namenode/〈/value>
        <final>true</final>
    </property>
</configuration>


范例9-2.典型的hdfs-site.xml配置文件


<?xml version="l.0"?>
<!-- hdfs-site.xml -->
<configuration>
    <property>
        <name>dfs.name.dir</name>
        <value>/diskl/hdfs/name,/remote/hdfs/name</value>
        <final>true</final>
    </property>
    <property>
        <name>dfs.data.dir</name>
        <value>/diskl/hdfs/data,/disk2/hdfs/data</value>
        <final>true</final>
    </property>
    </property>
        <name>fs.checkpoint.dir </name>
        <value>/diskl/hdfs/namesecondary,/disk2/hdfs/namesecondary</value>
        <final>true</final>
    </property>
</configuration>

范例9-3.典型的mapred-site.xml配置文件

<?xml version="l.0"?>
<!-- mapred-site.xml -->
<configuration>
    <property>
        <name>mapred.job.tracker</name>
        <value>jobtracker:8021</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.local.dir</name>
        <value>/diskl/mapred/localJ/disk2/mapred/local</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.system.dir</name>
        <value>/tmp/hadoop/mapred/system</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.tasktracker.map.tasks.maximum</name>
        <value>7</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.tasktracker.reduce.tasks.maximum</name> <value>7</value>
        <final>true</final>
    </property>
    <property>
         <name>mapred.child.java.opts</name>
         <value>-xmx400m</value>
         <!-- Not marked as final so jobs can include 〕VM debugging options -->
    </property>
</configuration>


1.HDFS

运行HDFS需要将一台机器指定为namenode。在本例中,属性 fs.default.name描述HDFS文件系统的ITRI,其主机是namenode的主机 名称或IP地址,端口是namenode监听RPC的端口。如果没有指定,那么默认端口是8020。

HDFS(或MapReduce)守护进程并不用•文件来确定主机名 称。由于makers文件只供控制脚本使用,如果不使用控制脚本,可忽略该文件。

属性fs.default.name也指定了默认文件系统,可以解析相对路径。相对 路径的长度更短,使用更便捷(不需要了解特定namenode的地址)。例如, 假设默认文件系统如范例9-1所示的那样,则相对URI /a/b被解析为hdfs: //namenode/a/b。

当用户在运行HDFS时,鉴于fs.default.name指定了HDFS的namenode和默认文件系统,则HDFS必须是服务器配置的默认文件系统。值得注意的是,为了操作方便,也允许在客户端配置中将其他 文件系统指定为默认文件系统。

例如,假设系统使用HDFS和S3两种文件系统,则可以在客户端配 置中将任一文件系统指定为默认文件系统。这样的话,就能用相对 URI指向默认文件系统,用绝对URI指向其他文件系统。

此外,还有其他一些关于HDFS的配置选项,包括namenode和datanode存 储目录的属性。属性项dfs. name .dir指定一系列目录来供namenode存储 永久性的文件系统元数据(编辑日志和文件系统映像)。这些元数据文件会同 时备份在所有指定目录中。通常情况下,通过配置dfs.name.dir属性可 以将namenode元数据写到一两个本地磁盘和一个远程磁盘(例如NFS挂载的目录)之中。这样的话,即使本地磁盘发生故障,甚至整个namenode发 生故障,都可以恢复元数据文件并且重构新的namenode。(辅助namenode 只是定期保存namenode的检査点,不维护namenode的最新备份。)

属性df s . data. dir指定datanode存储数据的目录。前面提到, dfs.name.dir描述一系列目录,其目的是支持namenode进行冗余备份。 虽然dfs.data.dir也描述了一系列目录,但是其目的是使datanode循环 地在各个目录中写数据。因此,为了提高性能,最好分别为各个本地磁盘指定一个存储目录。这样一来,数据块跨磁盘分布,针对不同数据块的读操作可以并发执行,从而提升读取性能。

为了充分发挥性能,需要使用noatitne选项挂载磁盘。该选项意味着执行读操作时,所读文件的最近访问时间信息并不刷新,从而显著提升性能。

最后,还需要指定辅助namenode存储文件系统的检查点的目录。属性fs.checkpoint.dir指定一系列目录来保存检查点。与namenode类似, 检査点映像文件会分别存储在各个目录之中,以支持冗余备份。

表9-3总结了 HDFS的关键配置属性。

表9-3.HDFS守护进程的关键属性

属性名称

类型

默认值

说明

fs.default.name

URI

file:///

默认文件系统。URI定义主 机名称和namenode的RPC 服务器工作的端口号,默认 值是8020。本属性保存在 core-site.xml 中

dfs.name.dir

以逗号分隔的目录名称

 ${hadoop .tmp. dir} /dfs/name

namenode存储永久性的元数 据的目录列表。namenode在 列表上的各个目录中均存放 相同的元数据文件

dfs.data.dir

以逗号分隔的目录名称

 ${hadoop.tmp.dir}/dfs/data

datanode存放数据块的目录 列表。各个数据块分别存放 于某一个目录中

fs.checkpoint.dir

以逗号分隔的目录名称

${hadoop.tmp.dir}/ dfs/namesecondary

辅助namenode存放检査点 的目录列表。在所列的每个 目录中均存放一份检査点文 件的副本

在默认情况下,HDFS的存储目录放在Hadoop的临时目录之中(即hadoop.tmp.dir属性,默认值是/tmp/hadoop-${user.name})。

因此,正确设置这些属性的重要性在干,即使清除了系统的临时目录。数据也不会丢失。

2.MapReduce

用户需要指派一台机器为jobtracker以运行MapReduce。在小型集群中,可以把jobtracker和namenode设置于同一台机器上。设置mapred. job .tracker 属性,指定jobtracker的主机名或IP地址,以及监听端口。该属性并非 URI格式,而是“主机:端口”格式。通常情况下,端口号被设为8021。

 

在执行MapReduce作业的过程中所产生的中间数据和工作文件被写到临时本地文件之中。由于这些数据包括map任务的输出数据,数据量可能非常大,因此必须保证本地临时存储空间(由mapred. local .dir属性设置)的 容量足够大。mapred.local.dir属性使用一个逗号分隔的目录名称列表,最好将这些目录分散到所有本地磁盘,以提升磁盘I/O操作的效率。 通常情况下,会使用与datanode相同的磁盘和分区(但是不同的目录)存储 MapReduce的临时数据。如前所述,datanode的数据块存储目录由 dfs.data.dir属性项指定。

 

MapReduce使用分布式文件系统来和运行MapReduce任务的各个 tasktracker共享文件(例如作业JAR文件)。属性mapred. system.dir指定 这些文件的存储目录,可以是针对默认文件系统的相对路径(默认文件系 统由fs.default.name属性设定),一般为HDFS。

 最后,设置 mapred.tasktracker.map.tasks.maximum 和 mapred.tasktracker.Reduce.tasks. maximum属性时必须考虑到tasktracker所在机器上还剩多 少可以使用的核,设置mapped.child, java .opts属性时必须考虑 tasktracker各子JVM允许使用的内存大小。详情参见9.4.2节对内存的

讨论。

表9-4总结了 HDFS的关键配置属性。

属性名称

类型

默认值

说明

mapred.job. tracker

主机名和 端口

local

运行 jobtracker 的 RPC 服务器的主机名和端口。如果设为默认值local,则运行一个MapReduce作业 时,jobtracker以处理时模 式运行(换言之,用户无需启动jobtracker;如果试图 在该模式下启动jobtracker 还会引发错误)

mapred.local. dir

逗号分隔的目录名称

${hadoop.tmp.dir}/mapred/local

存储作业的中间数据的目 录列表。作业终止时,数据被清除

mapred.system.dir

URI

${hadoop.tmp.dir}/mapred/system

在作业运行期间存储共享文 件的目录,相对于 fs.default.name

mapred.task tracker. map.tasks.maximum

int

2

在任一时刻,允许在 tasktracker 上运行的 map 任务的最大数量

mapred.tasktracker. reduce.tasks.maximum

int

2

在任一时刻,允许在 tasktracker 上运行的 reduce任务的最大数量

mapred.child.java, opts

String

-Xmx200m

JVM选项,用于启动运行 map和reduce任务的 tasktracker子进程。该属 性可以针对每个作业进行 设置。例如,可以设置 JVM的属性,以支持调试

mapreduce.map. java.opts

String

-Xmx200m

JVM选项,针对运行map 任务的子进程(在1.x版本 中不出现)

mapreduce.reduce, java.opts

String

-Xmx200m

JVM选项,针对运行 reduce任备的羊进程(在 1.x版本中不出现)

9.4.4 Hadoop守护进程的地址和端口

Hadoop守护进程一般同时运行RPCHTTP两个服务器,RPC服务器(表 9-5)支持守护进程间的通信,HTTP服务器则提供与用户交互的Web页面 (9-6)。需要分别为各个服务器配置网络地址和端口号。当网络地址被设 0.0.0.0时,Hadoop将与本机上的所有地址绑定。用户也可以指定服务器与某一个地址相绑定。端口号0表示服务器会选择一个空闲的端口号: 但由于这种做法与集群范围的防火墙策略不兼容,通常不推荐。

表9-5.RPC服务器的属性

属性名称

默认值

说明

fs.default.name

file:///

被设为一个HDFS的URI 时,该属性描述namenode 的RPC服务器地址和端 口。若未指定,则默认的 端口号是8020

dfs.datanode.ipc.address

0.0.0.0:50020

datanode的RPC服务器的 地址和端口

mapred.job.tracker

local

被设为主机名称和端口号 W,该属佳指走jobtracker 的RPC服务器地址和端口。常用的端口号是8021

mapred.task.tracker.report.address

127.0.0.1:0

tasktracker 的 RPC 服务器 地址和端口号。tasktracker 的子JVM利用它和 tasktracker通信。在本例 中,使用任一空闲端口均是可行的,因为服务器仅绑定回送地址。仅当本机 没有回送地址时才需要变更 默认设置

除了 RPC服务器之外,各个datanode还运行TCP/IP服务器以支持块传输。服务器地址和端口由属性dfs.datanode.address设定,默认值是0.0.0.0:50010。

表9-6.HTTP服务器的属性

属性名称

默认值

说明

mapred.job.tracker.http.address

0.0.0.0:50030

jobtracker 的 HTTP 服务器地址和端口

mapred.task.tracker.http.address

0.0.0.0:50060

tasktracker 的 HTTP 服务器地址和端口

dfs.http.address

0.0.0.0:50070

namenode的HTTP服务器地址和端口

dfs.datanode.http.address

0.0.0.0:50075

datanode的HTTP服务器地址和端口

dfs.secondary.http.address

0.0.0.0:50090

辅助namenode的HTTP服务器地址和端口

有多个网络接口时,还可以选择某一个网络接口作为各个datanode和tasktracker的IP地址针对HTTP和RPC服务器)。相关属性包括dfs.datanode.dns.interface和mapred.tasktracker.dns.interface,默认值都是default表示使用默认的网络接口。可以修改这两个属性项 来变更网络接口的地址(例如eth0)。

9.4.5 Hadoop的其他属性

本节讨论其他一些可能会用到的Hadoop属性。

1.集群成员

为了便于在将来添加或移除节点,可以通过文件来指定一些允许作为 datanode或tasktracker加入集群的经过认证的机器。属性dfs.hosts记录允许作为datanode加入集群机器列表;属性mapred.hosts记录允许作 为tasktracker加入集群的机器列表。与之相对应的,属性dfs.hosts. exclude和mapred.hosts.exclude所指定的文件分别包含待移除的机器列表。更深入的讨论可参见10.3.2节。

2.缓冲区大小

Hadoop使用一个4 KB(4096字节)的缓冲区辅助I/O操作。对于现代硬件和操作系统来说,这个容量实在过于保守了。增大缓冲区容量会显著提高性能,例如128KB(131072字节)更为常用。可以通过core-site.xml文件中的 io.file, buffer. size属性来设置缓冲区大小。

3. HDFS块大小

默认情况下,HDFS块大小是64 MB,但是许多集群把块大小设为128 MB(134 217 728 字节)或 256 MB(268 435 456 字节)以降低 namenode 的内存 压力,并向mapper传输更多数据。可以通过hdfs-site.xml文件中的 dfs.block. size属性设置块的大小。

4.保留的存储空间

默认情况下,datanode能够使用存储目录上的所有闲置空间。如果计划将 部分空间留给其他应用程序(非HDFS),则需要设置 dfs. datanode . du. reserved属性来指定待保留的空间大小(以字节为单位)。

5.回收站

Hadoop文件系统也有回收站设施,被删除的文件并未被真正删除,仅只转 移到回收站(一个特定文件夹)中。回收站中的文件在被永久删除之前仍会至少保留一段时间。该信息由core-site.xml文件中的fs.trash.interval属 性(以分钟为单位)设置。默认情况下,该属性的值是0,表示回收站特性无效。

与许多操作系统类似,Hadoop的回收站设施是用户级特性,换句话说, 只有由文件系统shell直接删除的文件才会被放到回收站中,用程序删除 的文件会被直接删除。当然,也有例外的情况,如使用Trash类。构造一个Trash实例,调用moveToTrashO方法会把指定路径的文件移到回收站中。如果操作成功,该方法返回一个值,否则,如果回收站特性未被启动,或该文件已经在回收站中,该方法返回false。

当回收站特性被启用时,每个用户都有独立的回收站目录,目:home目录下的Trash目录。恢复文件也很简易:在.Trash的子目录中找到文件,并将其移出.Trash目录。

HDFS会自动删除回收站中的文件,但是其他文件系统并不具备这项功能。 对于这些文件系统,必须定期手动删除。执行以下命令可以删除已在回收 站中超过最小时限的所有文件:

% hadoop fs -expunge

Trash类的expunge()方法也具有相同效果。

6.作业调度

在针对多用户的MapReduce设置中,可以考虑将默认的FIFO作业调度器 替换为一个具有更多特性的调度器。参见6.3.1节中对作业调度的讨论。

7.慢启动reduce

在默认情况下,调度器将会一直等待,直到该作业的5%的map任务已经结束才会调度reduce任务。对于大型作业来说,这可能会降低集群的利用率,因为在等待map任务执行完毕的过程之中,占用了 reduce槽。可以将 mapred.reduce.slowstart.completed.maps 的值设得更大,例如 0.80(80%),能够提升吞吐率。

8.任务的内存限制

在共享集群上,不允许由于存在有纰漏的MapReduce程序而影响集群中各 个节点的正常工作。然而,如果map或reduce任务出现内存泄露,则这种 情况很可能会发生。例如,假设一台运行tasktracker的机器的可用内存耗尽,则会影响其他正在运行的进程。

 考虑另一种情况。用户将mapred.child.java.opts设为一个大值,则其他正在运行的任务由于内存紧张将导致更多磁盘换页操作。若以final修饰 这个属性,将能够阻止该属性在作业中被用户任意修改。但由于总有一些 合理因素允许部分作业占用更多内存,因此上述方案并不总是可行的。此外,即使将mapred.child.java.opts参数锁定,也无法解决该问题,因为 有些任务能够创建新进程,且其内存的使用不受该参数约束。例如, Streaming和管道作业就是如此。

为了防范此类事故,需要采取-些措施来加强任务的内存限制管理。 Hadoop提供了两种机制。最简单的机制是使用Linux和ulimit的命令,它能在操作系统级别完成(在limits.conf文件中,一般可以在/etc/security中发现) 或在Hadoop配置中设置mapred.child.ulimit项。该值以千字节为单位,且应明显高于JVM内存(由mapred.child.java.opts设置),否则子 JVM可能无法启动。

另外一种机制是Hadoop的任务内存监控特性®。基本思路是由管理员为集群中的任务设置虚拟内存限制;用户在作业配置中指定他们的作业的最大 内存需求。如果用户不为其作业设置内存需求,则使用默认设置 (mapred.job.map.memory.mb 和 mapred. job. reduce.memory.mb)。

该机制相对于ulimit方法具有多项优势。首先,它加强了整个任务进程树 的内存利用率,包括由任务创建的进程。其次,它具有内存感知的调度能 力,各个任务会被安排在拥有足够空闲内存的tasktracker上运行。例如,容量调度器会根据内存设置来计算槽的利用率。如果某个作业的 mapred.job.map.memory.mb设置超过mapred.cluster.map.memory.mb,就

该调度器就会为该作业在tasktracker上分配多个槽以运行各个map任务。

为了启用任务内存监控,需要设置表9-7中的所有6项属性。默认值均为-1, 表明此项特征未被启用。

表9-7.MapReduce任务内存监控的属性

属性名称

类型

默认值

说明

mapred.cluster.map. memory.mb

int

-1

定义每个map槽的虚拟内存量(以MB为 单位)。如果map任务所需内存超过该 值,则需要使用多个map槽

mapred.cluster.reduce, memory.mb

int

-1

定义每个reduce槽的虚拟内存量(以MB 为单位)。如果reduce任务所需内存超过 该值,则需要使用多个reduce槽

mapred.job.map.memory.mb

int

-1

定义每个map任务运行时所需的虚拟内存 量(以MB为单位)。如果某个map任务超 过该值,则该任务终止,且被标记为失败

mapred.job.reduce.memory.mb

int

-1

定义每个reduce任务运行时所需的虚拟内 存量(以MB为单位)。如果某个reduce任 务过该值,则该任务终止,且被标记为失败

mapred.cluster.max.map. memory.mb

int

-1

允许用户设置的 mapred . job .map . memory . mb的最大值

mapred.cluster.max.reduce. memory.mb

int

-1

允许用户设置的 mapred . job . reduce . memory . mb的最大值

9.4.6创建用户帐号

Hadoop集群创建完毕,并且正常工作之后,还需要授予用户访问权限。具体而言,就是分别为各用户创建home目录,并相应地赋予用户拥有者 (ownership)权限。

% hadoop fs -mkdir /user/username
% hadoop fs -chown username:username /user/username

设定各目录的空间容量限制非常有必要。以下指令设定某用户的目录容量 不超过1 TB:

% hadoop dfsadmin -setSpaceQuota 1t /user/username

9.5 YARN 配置

YARN是运行MapReduce的下一代架构(参见6.1.2节),其守护进程和配置 选项均与传统的MapReduce(也被称为MapReduce 1)不同。本节将讨论这些 差异,以及如何在YARN上运行MapReduce。

在YARN上,用户不再运行jobtracker或者tasktracker。取而代之的,一个 单独的资源管理器将与HDFS的namenode(对于小型集群)运行在同一机器上,或者运行在一个专有机器上;同时也有节点管理器运行在集群中的每 个工作节点上。

YARN的start-yarn.sh脚本(在sbin目录下)启动集群中的YARN守护进程。该脚本会在脚本所运行的机器上启动资源管理器,还在slaves文件列举的 每台机器上各启动一个节点管理器。

YARN还有一个作业历史服务器和一个Web应用程序代理服务器。前者可显示历史作业的执行细节,后者可使用户安全地访问YARN应用的用户界面。在MapReduce案例中,Web用户界面提供当前正在运行的作业信息,与5.5.3节所描述的类似。在默认情况下,Web应用程序代理服务器和资源管理器在同一进程中运行,但是,也可以将Web应用程序代理服务器配置 成一个单独运行的守护进程。

表9-8列举了 YARN所特有的配置文件,这些文件可作为表9-1中文件的 补充。

表9-8.YARN的配置文件

文件名称

格式

说明

yarn-env.sh

bash脚本

运行YARN的脚本所使用的环境变量

yarn-site.xml

Hadoop配置XML

YARN守护进程的配置设置:资源管理器、作业历史服务器、Web应用程序代理服务器和节点管理器

9.5.1 YARN守护进程的重要属性 

当在YARN上运行MapReduce时,mapred_site.xml文件仍被用于记录通用 MapReduce属性,只是与jobtracker和tasktracker相关的属性已经废弃了。 除了 mapred.child.java.opts以外(以及两个相关属性 mapreduce.map. java.opts 和 mapreduce. reduce. java.opts,分别针对map和reduce任务),表9-4中的其他属性都不再适用于YARN。该属性 所对应的JVM选项被用于启动运行map或者reduce任务的YARN子 进程。

范例9-4中的配置文件显示一些配置属性,这些属性对于MapReduce在 YARN上的运行很重要。

范例9-4. 一组在YARN上运行MapReduce的站点配置文件样例

<?xml version="l.0"?>!-- mapred-site.xml -->
<configuration>
    <property>
        <name>mapred.child.java.opts</name>
        <value>-Xmx400m</value>
        <!-- Not marked as final so jobs can include DVM debugging options -->
    </property>
<configuration>


<?xml version="l.0"?>
<!-- yarn-site.xml -->
<configuration>
    <property>
        <name>yarn.resourcemanager.address</name>
        <va1ue>resourcemanager:8032</value>
    </property>
    <property>
        <name>yarn.nodemanager•local-dirs</name>
        <value>/diskl/nm-local-dir,/disk2/nm-local-dir</value>
        <final>true</final>
    </property>
    <property>
        <name>yarn.nodemanager.aux-services"<name>
        <value>mapreduce.shuffle</value>
    </property>
    <property>
        <name>yarn.nodemanager.resource.memory-mb</name>
        <value>8192</value>
    </property>
</configuration>

YARN资源管理器的地址由yarn.resourcemanager.address指定,其格式为:主机:端口。在客户端配置中,这个属性用于连接到资源管理器(使用 RPC)。此外,mapreduce.framework.name 属性必须要设置为 yarn,这样客户端才会使用YARN而非其他。

尽管YARN不再使用mapred.local.dir属性项,但是它有一个功能相同的属性项,即:yarn.nodemanager.local-dirs,以指定本地磁盘位置来存储中间数据。该属性值是一个以逗号分隔的本地目录列表,以供循环访 问各个目录。

 tasktracker会将map任务的输出转到reduce任务中。鉴于YARN舍弃了 tasktracker,因此它依赖于shuffler句柄来完成此项功能,它是长期运行于 节点管理器的附加服务。由于YARN是一个通用目的的服务,MapReduce 的shuffle句柄还需要被显式地启用,即:将yarn.site.xml中的yarn, nodemanager.aux-services 属性设置为 mapreduce. shuffle。

表9-9总结了 YARN的重要配置属性。

表9-9.YARN守护进程的重要性

属性名称

类型

默认值

说明

yam. resourcemanager. address

主机名和端口

0.0.0.0:8032

主机名称和资源管理器的RPC服 务器的监听端口

yarn.nodemanager. local-dirs

逗号分隔的目录名称

/tmp/nm-local-dir

目录列表,节点管理器允许存储 器将中间数据存于其中。当应用 结束时,中间数据被清除

yarn.nodemanager.aux-services

逗号分隔的服务名称

节点管理器运行的附加服务列表。每 项服务由 yarn.nodemanager.aux- services. service-name .class所指定类实现。默认情况下,并 未指定附加服务

yarn.nodemanager. resource.memory-mb

int

8192

被分配到节点管理器的物理内存 量(单位是MB)

yarn.nodemanager.vmem-pmem-ratio

float

2.1

虚拟内存和物理内存间的比率。 虚拟内存的用量可能超过该数字

内存

与早期MapReduce的基于槽的模型相比,YARN以更加精细化的方式来管理内存。YARN并不为可同时在tasktracker上执行的map和reduce槽的最多数量设定一个固定值,它允许应用程序为任务请求任意规模的内存量(该内存量需在预定范围之内)。在YARN模型中,节点管理器从一个内存池中 分配内存,这意味着可同时运行的任务数量依赖于内存需求总量,而非槽数量。

基于槽的模型可能导致集群未被充分利用,原因是map槽与reduce槽之间 的比率在整个集群内是固定如。然而,在不同时段内,作业对map槽和 reduce槽的需求会不断变化。在初始阶段,作业仅需要map槽,在末尾阶段,作业仅需要reduce槽。在包含多个并发作业的大规模集群中,这种需 求变迁也许并不那么剧烈,但是浪费现象仍然显著。YARN并不区分这两 种类型的槽,从而避免了该问题。

以下讨论节点管理器的内存需求以正常执行作业,相关分析与9.4.5节讨论 内存时所提到的类似。每个Hadoop守护进程使用1000 MB内存,因而需 要2000 MB内存来运行1个datanode和1个节点管理器。还要为运行在本 机上的其他进程保留足够内存。节点管理器的内存分配量可以通过yarn.odemanager. resource.memory-mb 来设定,单位是 MB(默认值是 8192 MB)。

还需要考虑如何分别为各个作业设定内存选项。共有两个控制参数。 mapred.child.java.opts 用于设置 map 或者 reduce 任务的 JVM 堆大 小;mapreduce .map .memory.mb(或者 mapreduce. reduce. memory .mb)用于指定内存大小以运行map(或redeuce)任务。应用宿主会使用后一个参数 设置以从集群中请求资源;此外,节点管理器也会使用该参数来运行、监 控所有任务的内存使用情况^。

例如,假设 mapred.child.java.opts 被设为-Xmx800m, mapreduce. map.memory.mb被设为默认值(1024 MB)。当map任务启动时,节点管理 器会为该任务分配1024 MB内存(在该任务运行期间,系统的内存池也会相 应降低1024 MB),并启动配置为具有最大堆为800 MB的任务JVM。JVM 进程的内存开销比该堆的规模要大,差距的大小依赖于所使用的本地库 (native libraries)、永久生成空间(generation space)等因素。需要注意的是, JVM进程所使用的物理内存必须不超出分配给他的内存大小(1024 MB),这 包括它创建的任何进程,如Streaming或者Pipe等。否则,JVM进程会被 节点管理器终止,并标记为失败。

调度器会指定一个最小和最大内存分配量。例如,容量调度器的默认最小 内存分配量是 1024 MB(由 yarn.scheduler.capacity.minimum-allocation- mb设置),默认最大内存分配量是10 240 MB(由yarn, scheduler .capacity, maximum-allocation-mb 设置)。

除了对物理内存有限制之外,对虚拟内存也有限制。如果进程所使用的虚拟内存量超出预定系数和物理内存限制的乘积,则节点管理器也会终止进 程。该系数由yarn.nodemanager.vmem-pmem-ratio属性指定,默认值

是2.1。在前面的例子中,虚拟内存规模的上限值为2150 MB,即2.1×1024 MB。

除了使用参数来配置内存使用上限之外,还可以使用MapReduce任务计数 器来监控任务执行过程中的真实内存消费量。这些计数器包括:PHYSICAL_ EMORY_BYTES、VIRTUAL_MEMORY_BYTES 和 COMMITTED_HEAP_BYTES(参见

表8-2),分别描述了在某一时刻各种内存的使用情况。

9.5.2YARN守护进程的地址和端口

YARN守护进程运行一个或者多个RPC和HTTP服务,表9-10和表9-11描述了相关细节

表9-10.YARN的RPC服务器属性

属性名称

默认值

说明

yarn.resourcemanager.address

0.0.0.0:8032

资源管理器的RPC服务器地址和端口。_ 客户端(一般在集群外部)通过它与资源管 理器通信

yarn.resourcemanager. admin.address

0.0.0.0:8033

资源管理器的admin RPC服务器地址和端 口。hdmin 客户端(由 yarnrmadmin 调用, 一般在集群外部)借此与资源管理器通信

yarn.resourcemanager. scheduler.address

0.0.0.0:8030

资源管理器的调度器的RPC服务器的地址和端口。应用程序宿主(在集群内部)借 此与资源管理器通信

yarn.resourcemanager.resource-tracker .address

0.0.0.0:8031

资源管理器的resource tracker的RPC服 务器地址和端口。节点管理器(在集群内 部)借此与资源管理器通信

yarn.nodemanager.address

0.0.0.010

节点管理器的RPC服务器地址和端口。 应用程序宿主(在集群内部)借此与节点管理器通信

yarn.nodemanager.localizer. address

0.0.0.0:8040

节点管理器的localizer的RPC服务器地址和端口

mapreduce.jobhistory. address

0.0.0.0:10020

作业历史服务器的RPC服务器地址和端口。客户端(一般在集群外部)借此来査询 历史作业信息。该属性在mapred-site.xml中设置

表9-11.YARN的HTTP服务器属性

属性名称

默认值

说明

yarn.resourcemanager. webapp.address

0.0.0.0:8088

资源管理器的HTTP服务器地址和端口

yarn.nodemanager.webapp.address

0.0.0.0:8042

节点管理器的HTTP服务器地址和端口

yarn.web-proxy.address

Web应用代理服务器的HTTP服务器地址和端口。如果本属性未被设置(默认情况下),则Web应用代理服务器会在资源管 理器进程中运行

mapreduce.jobhistory.webapp.address

0.0.0.0:19888

作业历史服务器的HTTP服务器地址和端 口,在mapred-site.xml中设置

mapreduce.shuffle.port

8080

shuffle 句柄(handler)的 HTTP 端口号,为 map任务的输出结果服务,但不是用户可访问的UI界面。本属性在mapred-site.xml中设置

9.6安全性

早期版本的Hadoop假定HDFS和MapReduce集群运行在安全环境中,由一组相互合作的用户所操作,因而访问控制措施的目标是防止偶然的数据丢失,而非阻止非授权的数据访问。例如,HDFS中的文件许可模块会阻止 用户由于程序漏洞而毁坏整个文件系统,也会阻止运行不小心输入的 hadoop fs -rmr /指令,但却无法阻止某个恶意用户假冒root身份(参见 5.2.2节的补充内容“设置用户标识”)来访问或删除集群中的某些数据。’

从安全角度分析,Hadoop缺乏一个安全的认_证机制,以确保正在操作集群 的用户恰是所声称的安全用户。Hadoop的文^牛许可模块只提供一种简单的 认证机制来决定各个用户对特定文件的访问权限。例如,某个文件的读权 限仅开放给某一组用户,从而阻止其他用户组的成员读取该文件。然而, 这种认证机制仍然远远不够,恶意用户只要能够通过网络访问集群,就有 可能伪造合法身份来攻击系统。

包含个人身份信息的数据(例如终端用户的全名或IP地址)非常敏感。一般情况下,需要严格限制组织内部的能够访问这类信息的员工数。相比之下,敏感性不强(或匿名化)的数据则可以开放给更多用户。如果把同一集群 上的数据划分不同的安全级别,在管理上会方便很多,且低安全级别的数 据也能够被广泛共享。然而,为了迎合数据保护的常规需求,共享集群的 安全认证是不可或缺的。

雅虎公司在2009年就遇到了该难题,因此组织了一个工程师团队来实现 Hadoop的安全认证。这个团队提出了一个方案:用Kerberos(—个成熟的 开源网络认证协议)实现用户认证,Hadoop不直接管理用户隐私,而 Kerberos也不关心用户的授权细节。换句话说,Kerberos的职责在于鉴定登录帐号是否是他所声称的用户,Hadoop则决定该用户到底拥有多少权限。Kerberos技术比较复杂,因此这里只介绍在Hadoop系统中的用法。若 想了解更多背景,可以参阅Jason Garman的《Kerberos权威指南》 (Kerberos: The Definitive Guide)

哪些Hadoop版本支持Kerberos认证?

自从0.20.20x版本之后,Apache Hadoop开始支持Kerberos认证。参见表 1-2可查看支持此特性的新近版本。

9.6.1Kerberos 和 Hadoop

从宏观角度来看,使用Kerberos时,一个客户端要经过三个步骤才可以获 得服务。在各个步骤,客户端需要和一个服务器交换报文。

(1)认证。客户端向认证服务器发送一条报文,并获取一个含时间戳的 票据授予票据(Ticket-Granting Ticket, TGT)。

(2)授权。客户端使用TGT向票据授予服务器(Ticket-Granting Server, TGS)请求一个服务票据。

(3)服务请求。客户端向服务器出示服务票据,以证实自己的合法性。 该服务器提供客户端所需服务,在Hadoop应用中,服务器可以是 namenode 或 jobtracker。

同时,认证服务器和票据授予服务器构成了密钥分配中心(Key Distribution Center, KDC)。整个过程如图9-2所示。

授权和服务请求步骤并非用户级別的行为:客户端系统会代替用户来执行 这些步骤。但是认证步骤通常需要由用户调用kinit命令来执行,该过程 会提示用户输入密码。需要指出的是,这并不意味着每次运行一个作业或访问HDFS的时候都会强迫用户键入密码,因为用户所申请到的TGT具备 一定的有效期。TGT有效期时默认值是10个小时(可以更新至一周)。更通用的做法是采用自动认证:即在登录操作系统的时候自动执行认证操作, 从而只需单次登录(single sign-on)到Hadoop。

如果用户不期望被提示输入密码(例如,运行一个无人值守的MapReduce作 业),则可以使用ktutil命令创建一个Kerberos的文件,该文件保 存了用户密码并且可以通过-t选项应用于kinit命令。

图片.png 

 

图9-2. Kerberos票据交换协议的三个步骤

示例

下面来看一个例子。首先,将coresite.xml文件中的hadoop.security. authentication属性项设置为kerberos,以启用Kerberos认证。®该属 性项的默认值是simple,表示将采用传统的向后兼容(但是不安全)方式, 即利用操作系统用户名称来决定登录者的身份。

其次,还需要将同一文件中的hadoop.security.authorization属性项 设置为true,以启用服务级别的授权。Hadoop.policy.xml文件中的访问控 制列表(ACL)决定哪些用户和组能够访问哪些Hadoop服务。这些服务在协 议级别定义,包括针对MapReduce作业提交的服务、针对namenode通信 的服务等。默认情况下,各个服务的ACL都被设置为*,表示所有用户能 够访问所有服务。但在现实情况下,还是有必要充分考虑ACL策略,以控

制访问服务的用户和组的范围。

ACL的格式很简单,前一段是以逗号隔开的用户名称列表,后一段是以逗 号隔开的组名称列表,两段间以空格隔开。例如,ACL片段 preston,howard directors,inventors会将某服务的访问权限授予两个 用户 preston、howard 和两个组 directors、inventors。

当Kerberos认证被启用时,以下输出内容显示了从本地复制一个文件到 HDFS中时系统反馈的结果。

% hadoop fs -put quangle.txt.
10/07/03 15:44:58 WARN ipc.Client: Exception encountered while connecting to the server: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSEx ception: No valid credentials provided (Mechanism level: Failed to find any Ker beros tgt)]
Bad connection to FS. command aborted, exception: Call to localhost/127.0.0.1:80 20 failed on local exception: java.io.IOException: javax.security.sasl.SaslExcep tion: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

由于用户没有Kerberos票据,所以上述操作失败。用户可以使用kinit指 令向KDC认证,并获得一张票据。

% kinit
Password for hadoop-user@LOCALDOMAIN: password 
% hadoop fs -put quangle.txt .
% hadoop fs -stat %n quangle.txt 
quangle.txt

现在,可以看到文件已成功写入HDFS。注意,由于Kerberos票据的有效 期是10小时,所以尽管执行的是两条文件系统指令,但实际上只需调用一 次kinit命令。另外,klist命令能査看票据的过期时间,kdestroy指令 可销毁票据。在获取票据之后,各项工作与平常无异。

9.6.2委托令牌

在诸如HDFS或MapReduce的分布式系统中,客户端和服务器之间频繁交 互,且每次交互均需认证。例如,一个HDFS读操作不仅会与namenode多 次交互、还会与一个或多个datanode交互。如果在一个高负载集群上采用 三步骤Kerberos票据交换协议来认证每次交互,则会对KDC造成很大压 力。因此,Hadoop使用委托令牌来支持后续认证访问,避免了多次访问 KDC。委托令牌的创建和使用过程均由Hadoop代表用户透明地进行,因而 用户执行kinit命令登录之后就无需再做额外操作了。当然,了解委托令牌的基本用法仍然是有必要的。

委托令牌由服务器创建(在这里是指namenode),可以视为客户端和服务器 之间共享的一个密文。当客户端首次通过RPC访问namenode时,客户端 并没有委托令牌,因而需要利用Kerberos进行认证。之后,客户端从 namenode取得一个委托令牌。在后续RPC调用中,客户端只需出示委托令 牌,namenode就能验证委托令牌的真伪(因为该令牌是由namenode使用密 钥创建的),并因此向服务器认证客户端的身份。

客户端需要使用一种特殊类型的委托令牌来执行HDFS块操作,称为“块 访问令牌”(block access token)。当客户端向namenode发出元数据请求 时,namenode创建相应的块访问令牌并发送回客户端。客户端使用块访问 令牌向datanode认证自己的访问权限。由于namenode会和datanode分享 它创建块访问令牌时用的密钥(通过心跳消息传送),datanode也能够验证这 些块访问令牌。这样的话,仅当客户端已经从namenode获取了针对某一个 HDFS块的块访问令牌时,才可以访问该块。相比之下,在不安全的 Hadoop系统中,客户端只需知道块ID就能够访问一个块了。可以通过将 dfs. block .access .token .enable的值设置为true来启用块访问令牌特性。

在MapReduce中,jobtracker共享HDFS中的作业资源和元数据(例如JAR 文件、输入分片和配置文件)。用户代码运行在tasktracker上,并可以访问 HDFS上的文件(该过程在8.6.1节中介绍过)。在作业运行过程中,jobtracker 和tasktracker使用委托令牌访问HDFS。作业结束时,委托令牌失效。

默认的HDFS实例会自动获得委托令牌。但是若一个作业试图访问其他 HDFS集群,则用户必须将mapreduce.job.hdfs-servers作业属性设置 为一个由逗号隔开的HDFS URI列表,才能够获取相应的委托令牌。

9.6.3其他安全性改进

HDFS和MapReduce已经全面强化了安全措施,以阻止用户在未授权的情

况下访问资源。®—些显著的变化如下。

•任务可以由提交作业的用户以操作系统帐号启动运行,而不一定要 由运行tasktracker的用户启动。这意味着,在这种情况下,可以借助操作系统来隔离正在运行的任务,使它们之间无法相互传送指令 (例如,终止其他用户的任务),这样的话,诸如任务数据等本地信 息的隐私即可通过本地文件系统的安全性而得到保护。

要启用这项特性,需要将 mapped.task.tracker.task-controller 属性设置为 org.apache.hadoop.mapred.LinuxTaskController。此外,管理员还需确保各用户在集群的每个节点上都已经分配帐号 (一般使用LDAP)。

•当任务由提交作业的用户启动运行时,分布式缓存(参见8.4.2节) 是安全的:把所有用户均可读的文件放到共享缓存中(默认的非安 全方式),把其他文件放在私有缓存中,仅限拥有者读取。

•用户只能査看和修改自己的作业,无法操控他人的作业。为了启动 该特性,需要将mapred.acls.enabled属性项设为true。另外,mapreduce.job.acl-view-job 和 mapreduce.job.acl- modify-job属性分别对应一个逗号分隔的用户列表,描述能够查 看或修改指定作业的所有用户。

• shuffle是安全的,可以阻止恶意用户请求获取其他用户的map输 出。然而,由于shuffle并未加密,易受到恶意嗅探(sniffing)攻击。

•正确配置之后,可以阻止恶意的辅助namenode、datanoe或 tasktracker加入集群,从而破坏集群中的数据。这可以通过要求 master节点对试图与之连接的守护进程进行认证来实现。

为了启用该特性,需要使用先前由ktutil命令创建的知声^文件来 配置 Hadoop。以 datanode 为例,首先,把 dfs.datanode.keytab. file属性设置为keytab文件名称;其次,把dfs.datanode. kerberos.principal.•属性设置为要用的datanode用户名称;最 后,把 hadoop-policy.xm!文件中 security.datanode.protocol.acl 属性设置为datanode的用户名称,以设置DataNodeProtocol的 ACL。DatanodeProtocol 是 datanode 用于和 namenode 通信的协 议类。

• datanode最好运行在特权端口(端口号小于1024),使客户端确信它

是安全启动的。

•任务只与其父tasktracker通信,从而阻止攻击者经由其他用户的作 业获取MapReduce数据。

到目前为止,Hadoop还未考虑数据加密问题:不管是RPC还是块传输,数 据均未被加密。此外,HDFS块也没有以加密方式被存储。这些特性预计会 被加到未来发布中去。实际上,可以将当前Hadoop版本与特定应用程序相 结合,以提供加密特性。(例如,实现加密接口 CompressionCodec)。

9.7利用基准评测程序测试Hadoop集群

集群是否已被正确建立?这个问题最好通过实验来回答:运行若干作业, 并确信获得了预期结果。基准评测程序能获得满意的测试结果,用户可以 拿结果数据和其他集群做比较,以检测新集群是否达到预期效果。此外, 还可以据此调整集群设置以优化整体性能。这点一般通过监控系统实现(参 见10_2节),用户可以监测集群中的资源使用情况。

为了获得最佳评测结果,最好不要在运行基准评测程序时还同时运行其他 任务。换言之,在集群入役之前进行评测最为合适,此时用户尚未对集群 有依赖性。一旦用户已经依赖集群执行常规性作业,想要找到集群完全空 闲的时间就非常困难了 (除非和所有其他用户协商一个停止服务的时间段)。 总而言之,基准评测程序最好在此之前就执行。

实践表明,硬盘驱动器故障是新系统最常见的硬件故障。通过运行含有高 强度I/O操作的基准评测程序一例如即将提到的基准评测程序——就能在 系统正式上线前对集群做“烤机”测试。

9.7.1 Hadoop基准评测程序

Hadoop自带若干基准评测程序,安装开销小、运行方便。基准评测程序被 打包为一个名为test.jar的文件,经无参数解压缩之后,就可以获取文件列 表和说明文档:

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar

如果不指定参数,大多数基准测试程序都会显示具体用法。示例如下:

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar TestDFSIO TestFDSIO.0.0.4
Usage: TestFDSIO -read | -write | -clean [-nnFiles N] [-fileSize MB] [-resFile resultFileName] [-bufferSize Bytes]

1.使用TestDFSIO来评测HDFS

TestDFSIO能够用于测试HDFS的I/O性能。它用一个MapReduce作业并 行地读或写文件。各个文件在独立的map任务上被读或写,map任务输出 一些针对刚刚处理完的文件的统计信息;reduce任务汇总这些统计信息,并产 生一份总结报告。

以下命令写10个文件,各文件的大小为1000 MB:

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar TestDFSIO -write -nrFiles 10 -fileSize 1000

运行结束之后,结果被同时写到控制台和一个本地文件之中。注意,是以 添加的方式写到本地文件中,因而重新运行基准评测程序也不会丢失历史 记录:

% cat TestDFSIO_results.log
------ TestDFSIO-----  : write
Date & time : Sun Apr 12 07:14:09 EDT 2009 
Number of files : 10 
Total MBytes processed: 10000
Throughput mb/sec : 7.796340865378244 
Average 10 rate mb/sec: 7.8862199783325195 
10 rate std deviation: 0.9101254683525547
 Test exec time sec : 163.387

在默认情况下,文件被写到目录下的子目录。 可以通过设置test .build .data系统属性来更改目录(仍旧在目录)。

若想测试读操作,则使用-read参数。注意,待读的文件必须已经存在(已 通过TestDFSIO -write命令创建):

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar TestDFSIO -read -nrFiles 10 -fileSize 1000

以下内容是实际测试结果:

-----TestDFSIO-----  : read
Date & time : Sun Apr 12 07:24:28 EDT 2009
Number of files : 10
Total MBytes processed: 10000
Throughput mb/sec : 80.25553361904304
Average 10 rate mb/sec: 98.6801528930664 
10 rate std deviation: 36.63507598174921
 Test exec time sec : 47.624

测试结束之后,可以使用-clean参数删除所有在HDFS上临时生成的文件:

% hadoop jar $HAD00P_INSTALL/hadoop-*-test.jar TestDFSIO -clean

2.使用Sort程序评测MapReduce

Hadoop有一个MapReduce程序能够对输入数据做部分排序。鉴于整个输入 数据集是通过shuffle传输的,Sort程序对于整个MapReduce系统的基准评 测很有帮助。整个测试含三个步骤:创建随机数据、执行排序和验证结果。

首先,使用RandomWriter来产生随机数。该程序运行一个MapReduce作 业,在各节点上分别运行10个map任务,每个 map任务大约产生1GB大 小的随机二进制数,且键和值的大小各不同。用户可以通过 test. randomwriter . maps_per_host 和 test. randomwrite. bytes_per_map 两个属性来改变以上两个参数值。此外,还可修改键、值的取值范围等, 详见RandomWriter的说明。

以下命令演示如何调用RandomWriter(放在示例JAR文件中,而非测试 JAR文件中)以向random-data目录输出数据:

% hadoop jar $HADOOP_INSTALL/hadoop-*-examples.jar randomwriter random-data

接下来,运行Sort程序:

% hadoop jar $HADOOP_INSTALL/hadoop-*-examples.jar sort random-data sorted-data

用户会对Srot程序的总执行时间感兴趣。此外,通过Web界面来观察作业的执行过程更有意义,这样可以了 解作业在各个阶段的开销。在此基础上,可以练习如何调整系统参数(参见 5.6节对作业调优的讨论)。

最后,需要验证在sorted-data文件中的数据是否已经排好序了:

% hadoop jar $HAIX)OP_INSTALL/hadoop-*-test.jar testmapredsort -sortlnput ranckxn-data \ -sortOutput sorted-data

该命令运行SortValidator程序在排序前后的数据上执行一系列检査,以 验证排序结果是否正确。最后,向控制台报告以下输出结果:

SUCCESS! Validated the MapReduce framework's 'sort' successfully.

3.其他基准评测程序

Hadoop的基准评测程序有很多,以下几种最常用。

• MRBench(使用mrbench)会多次运行一个小型作业。与sort基准

不同,该基准的主要目的是检验小型作业能否快速响应。

•NNBench(使用nnbench)测试namenode硬件的加载过程

•Gridmix是一个基准评测程序套装。通过模拟一些真实常见的数据 访问模式,Gridmix能逼真地为一个集群的负载建模。用户可参阅 分发包中的文档来了解如何运行Gridmix,也可访问博客了解更多背景。

9.7.2用户作业

出于集群性能调优的目的,最好包含若干代表性强、使用频繁的作业。这 样的话,调优操作可以更有针对性,而非只是对通用场景调优。但如果待 测集群是用户的第一个Hadoop集群,且还没有任何作业,则Gridmix仍不 失为一个好的评测方案。

如果想把自己的作业作为基准评测时,用户还需要为作业选择数据集合。 这样的话,不管运行多少次,作业始终都基于相同的数据集合,便于分 析、比较性能变迁。当新建或升级集群时,使用同一数据集合还可以比较 新旧集群的性能。

9.8云端的Hadoop 

尽管许多机构自建集群来运行Hadoop,在租赁的硬件上所搭建的云端运行 Hadoop,或提供Hadoop服务仍然很流行。例如,Cloudera提供在公共(或 私有)云端运行Hadoop的工具(参见附录B); Amazon提供Hadoop云服 务,名为 Elastic MapReduce。

本节讨论如何在Amazon EC2上运行Hadoop,这是一个优秀的构建低成 本、试验性的Hadoop系统的方法。

Apache Whirr

Amazon的EC2(Elastic Compute Cloud)是计算服务,允许客户租借计算机 (或称为实例)来运行特定应用。客户可以按需启动和终止实例,并按照所租 借实例的数量和工作时长支付租金。

Apache Whirr 项目(http://whirr.apache.org/)提供了一套 Java API 和一组脚 本,能方便地在EC2或其他云提供商上运行Hadoop。®这些脚本支持多项 操作,包括启动集群、终止集群、列举集群中正在运行的实例等。

在EC2上运行Hadoop对于某些工作流特别恰当。例如,如果用户将数据 存储在Amazon S3上,则可在EC2上搭建集群来运行MapReduce作业,这 些作业从S3上读取数据,并在集群停机前**写回到S3中。如果集群的工作 时间较长,还可将S3中的数据复制到EC2的HDFS之中,通过数据本地化 提高执行效率。相比之下,由于S3和EC2节点并非物理上邻近,直接使用 S3无法享受数据本地化所带来的性能提升。

1.安装

Whin•的安装过程非常方便。从官网下载一个最新发布的压缩包,执行以下 指令将其解压缩到拟使用集群中的一台机器上。

% tar xzf whirr-x.y.z.tar.gz

Whirr•使用SSH与云端的机器通信。因此,可以创建SSH密钥对,以单独 使用Whirr。下面的指令将基于一个空密码来创建一组RSA密钥对,存放 在当前用户的.ssh目录中的id_rsa_whirr文件中。

% ssh-keygen -t rsa -P " -f ^/.ssh/id_rsa_whirr

切莫将Whirr的SSH密钥对与用户的Amazon Web服务账号的凭 证、私钥或者SSH密钥对相混淆。Whirr被设计成可与多个云提供 商一起工作,并且它必须已经访问本地文件系统中密钥对的SSH公 钥和私钥。实际上,该方法也是最简单的为Whirr创建新密钥对的方法,正如前面演示的那样。

 用户需要告诉Whirr相关的云提供商的证书。这些证书可以以环境变量的 方式输出(参见以下命令),也可以以命令行方式或者服务配置文件方式的方 ①在Hadoop发布包的方

式提供。

%export AWS_ACCESS_KEY_ID=’…’.
%export AWS_SECRET_ACCESS_KEY=’...'

2.启动集群

现在可以准备启动集群了。Whirr备有多个文件,以启用相应的通用服务配 置。以下命令使用了其中一个文件以在EC2上启动Hadoop:

% bin/whirr launch-cluster --config recipes/hadoop-ec2.properties \--private-key-file.ssh/id_rsa_whirr

其中,launch-cluster命令首先启动云实例以及运行在云上的服务,再将 控制权交还给用户。

3.配置

在开始使用集群之前,先关注一下Whirr配置的更多细节。配置参数可以 放置在配置文件之中,即可以–config选项批量传输给Whirr命令,或者 使用命令行参数的形式,类似于前面我们提到的–private-key-file参 数的方式来指定SSH私钥文件的位置。

Recipe文件实际上是Java属性文件,定义了若干Whirr属性。例如, hadoop-ec2.properties文件的前两个属性定义了集群和运行在集群上的 服务:

whirr.cluster-name=hadoop
whirr.instance-templates=l hadoop-namenode+hadoop-jobtracker^5 hadoop-datanode+ hadoop-tasktracker

每个集群都有名称,由whirr.cluster-name指定,这样用户就能在标识 的集群上执行操作,例如列举所有正在运行的实例、终止集群等。对于运 行该集群的云账号而言,集群名称必须是唯一的。

属性whirr.instance-templates指定了运行在集群上的服务。该属性以 “基数:服务”的形式描述在多少台机器上运行了哪些服务类型。在上例 中,一台机器运行 hadoop-namenode 和 hadoop-jobtracker,另外 5 台 机器上运行 hadoop-datanode 和 hadoop-tasktracker 。利用 whirr.instance-templates,用户可以精准地定义集群的组成部分。除 了 Hadoop之外,还有许多其他服务类型,用户可以运行来枚 举,该命令不需要参数。

下一组属性指定云证书。

whirr.provider=aws-ec2
whirr. identity=${env: AWS__ACCESS_KEY_ID}
whirr.credential=${env:AWS_SECRET_ACCESS_KEY>

属性whirr, provider定义了云服务提供商,在此例中是EC2(Whirr文档 列举其他受支持的服务提供商)。属性whirr.identity和 whirp.credential是访问云服务的凭证。通俗地讲,它们分别对应用户名和密码信息(各个云服务提供商采用的术语可能不同)。

最后三个参数描述集群的硬件(机器性能,如内存、磁盘、CPU和网速 等)、机器映像(操作系统)和地理位置(数据中心)。这些信息均依赖于服务提 供商。如果忽略这些属性,Whirr会尝试挑选恰当的默认设置。

whirr.hardware-id=cl.xlarge whirr.image-id=us-east-1/ whirr.location-id=us-east-l

在属性文件中,各属性被冠以whirr .作为前缀f但是如果把属性作为参数 传到命令行中,这个前缀就要被移除。例如,用户可以在命令行添加– cluster-name hadoop以设置集群的名称。这种方法可以设置属性文件中 的任一属性值。相反,我们也可以在属性文件中添加如下一行以设置私钥 文件:

whirr, private-key-file=/user/tom/ . ssh/id__rsa_whirr

也有一些指令用于指定运行在集群上的Hadoop的版本号,并且用于跨集群 设置Hadoop配置属性(详细信息参阅recipe文件)。

4.运行代理

为了使用集群,从客户端来的网络通信需要集群主节点使用SSH通道充当 代理来实现,可以使用以下命令:

% .~/.whirr/hadoop/hadoop-proxy.sh

当集群运行时,代理也需要一直运行,当集群终止时,可以按组合键Ctrl-C终止 代理。

5.运行MapReduce作业

MapReduce作业可以从集群内部的机器上启动运行,也可以从集群外部的机器上启动运行。下面,我们演示如何从构建了集群的机器上运行一个作 业,前提是在本地机器上已经安装了和集群相同版本的Hadoop系统。

启动集群时,会在目录中创建一组Hadoop站点配置文件。 可以按照如下设置HADOOP_CONF_DIR环境变量,从而连接到集群中去:

% export HADOOP_CONF_DIR=~/.whirr/hadoop

此时,集群的文件系统还是空的,还需要在运行作业之前增加测试数据。 使用Hadoop的distcp工具并行地从S3(有关S3文件系统的更多信息,可以 参见3.4节)中将数据拷贝到HDFS中是一个有效的方法。

% hadoop distcp \
-Dfs.sBn.awsAccessKeyId='...' \
-Dfs.s3n.awsSecretAccessKey='...' \
 s3n://hadoopbook/ncdc/all input/ncdc/a11

在hadoopbook节点S3桶的所有文件仅被允许拷贝到EC2的美国东 部区域,因而仅能在该区域运行distcp指令。最简单的方式是以以 下命令登陆到主节点(其地址在集群启动时会输出到控制台);

% ssh -i ~/.ssh/id_rsa_whirr master_host

数据准备完毕之后,可以用常用方式运行作业:

% hadoop jar hadoop-examples.jar MaxTemperatureWithCombiner \ /user/$USER/input/ncdc/all /user/$USER/output

或者可以指定数据输出到S3:

% hadoop jar hadoop-examples.jar MaxTemperatureWithCombiner \ /user/$USER/input/ncdc/all sBn://mybucket/output

用户可以使用jobtracker的Web界面(http://master_host:50030/)来监控作业 运行的进度。为了访问在工作节点上的网页,需要在浏览器中建立一个代 理自动配置(PAC)文件。参见Whirr文档以了解操作细节。

6.终止集群

运行destroy-cluster对指定集群进行关机:

% bin/whirr destroy-cluster --config recipes/hadoop-ec2.properties

该指令将终止集群中所有正在运行的实例,并且删除存储在集群中的 数据。

转载请注明:全栈大数据 » 9.构建Hadoop集群

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址