第9章-构建Hadoop集群-笔记

控制脚本

Hadoop内置一些脚原本运行指令，在集群内启动和终止守护进程。

这些脚本存放在bin目录中，经过masters和slaves文件指定集群内的全部机器。

一、masters文件，主要记录运行辅助namenode的全部机器

masters文件有点误导人。

它主要记录拟运行辅助namenode（secondarynamenode）的全部机器。

二、slaves文件，主要记录运行datanode和tasktracker的全部机器

slaves文件记录了运行datanode和tasktracker的全部机器。

masters和slaves文件存放在配置目录中。

用户也能够改变hadoop-env.sh的HADOOP_SLAVES项的值，将slaves文件放在其余地方（也能够改变文件名称）。

三、start-dfs.sh脚本运行时详细步骤

例如：start-dfs.sh脚本用于启动集群中全部的HDFS守护进程，可是该脚本运行时会在同一机器上运行namenode。

1）、在本地机器上启动一个namenode（脚本所运行的机器）

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

3）、在masters文件中记录的各机器上启动一个辅助namenode。

四、start-mapred.sh脚本运行时详细步骤

脚本start-mapred和start-dfs.sh相似，它启动集群中的全部MapReduce守护进程。

1）、在本地机器上启动一个jobtracker。

2）、在slaves文件列举的每台机器上启动一个tasktracker。

注意：

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

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

上述三、4脚本调用hadoop-daemon.sh脚原本启动和终止hadoop守护进程。

若是已经使用前述三、4脚本，则不宜直接调用hadoop-daemon.sh。

可是若是用户须要从其余系统(或利用本身编写的脚本)控制hadoop守护进程。则能够调用hadoop-daemon.sh。

相似的，hadoop-daemons.sh（多了一个“s”）用于在多个主机上启动同一个守护进程。

控制脚本相关知识点

一、集群内的全部机器经过什么文件指定？

经过masters和slaves文件。

二、hadoop-env.sh的HADOOP_SLAVES项的值用于指定salves文件的存放地址。

三、slaves和masters文件无需分发到各个工做节点

由于只有运行在namenode和jobtracker上的控制脚本能使用这些文件。

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

四、哪一个文件指定运行namenode和jobtracker的机器？

运行namenode和jobtracker的机器由运行脚本的机器决定。它不禁masters文件指定。

五、由masters文件指定的机器会做为何节点？

实际上，在masters文件指定机器，会致使这些机器上运行一个辅助namenode。

主节点场景

因为集群规模差别大，对于主节点守护进程的配置也差别很大。

主节点守护进程：namenode、辅助namenode、jobtracker

一、jobtracker最好运行在一个专用节点上

在一个运行大量MapReduce做业的高负载集群上，jobtracker会使用大量内存和CPU资源，所以最好运行在一个专用节点上。

二、无论主守护进程运行在一个仍是多个节点上，如下规则均适用

1）、在namenode机器上运行HDFS控制脚本。

2）、masters文件包含辅助namenode的地址。

3）、在jobtracker机器上运行MapReduce控制脚本。

当namenode和jobtracker运行在不一样节点之上时，集群中的各节点将运行一个datanode和一个tasktracker，以使slaves文件同步。

主节点场景相关知识点

一、namanode节点主要保存什么信息？

namenode在内存中保存整个命令空间的全部文件和块元数据，它的内存需求很大。

namenode会在内存中存储全部文件的每一个数据块的引用，所以namnode极可能会“吃光”分配给它的全部内存。对于这种状况，咱们能够不改变其余hadoop守护进程的内存分配量而只增长namenode的内存分配量。即：设置hadoop-env.sh文件的HADOOP_NAMENODE_OPTS，包含一个JVM选项以设定内存大小。HADOOP_NAMENODE_OPTS容许向namenode的JVM传递额外选项。

二、辅助节点secondarynamenode主要保存什么信息？

辅助namenode保存一份最新的检查点，记录文件系统的元数据。

将这些历史信息备份到其它节点上，有助于在数据丢失（或系统崩溃）状况下恢复namenode的元数据文件。

辅助namenode在大多数时间是空闲，可是它在建立检查时的内存需求与主namenode差很少。

一旦文件系统包含大量文件，单台机器的物理内存便没法同时运行主namenode和辅助namenode。

三、hadoop中哪些是主节点守护进程

namenode、辅助namenode、jobtracker

系统日志文件

一、建议修改Hadoop系统日志文件默认设置，使之独立于Hadoop的安装目录

默认状况下，Hadoop生成的系统日志文件存放在$HADOOP_INSTALL/logs目录之中，也能够经过hadoop-env.sh文件中的HADOOP_LOG_DIR来进行修改。

二、为何建议修改Hadoop系统日志文件存放目录独立于Hadoop的安装目录

修改默认配置，使之独立于Hadoop的安装目录。这样，即便Hadoop升级以后安装路径发生改变，也不会影响日志文件的位置。

一般能够将日志文件存放在/var/log/hadoop目录中。

实现方法：在hadoop-env.sh中加入如下一行，export HADOOP_LOG_DIR=/var/log/hadoop

三、各个hadoop守护进程均会产生两类日志文件

1）、经过log4j记录的——以.log做为后缀名

由于大部分应用程序的日志消息都写到该日志文件中，因此在对问题进行故障诊断时须要先查看这个文件。

标准的hadoop log4j配置采用平常滚动文件后缀策略(Daily Rolling File Appender)来命名日志文件。

系统不会自动删除过时的日志文件，而是留待用户按期删除或存档，以节约本地磁盘空间。

2）、记录标准输出和标准错误日志——日志文件后缀名为.out

因为hadoop使用log4j记录日志，因此这个文件一般只包含少许记录，甚至为空。

重启守护进程时，系统会建立一个新文件来记录此类日志。系统仅保留最新的5个日志文件。旧的日志文件会附加一个数字后缀，值在1和5之间，5表示最旧的文件。

日志文件名称中的“用户名称”部分实际对应hadoop-env.sh文件中的HADOOP_IDENT_STRING项。

SSH设置

一、利用rsync工具，Hadoop控制脚本可以将配置文件分发到集群中的全部节点。

默认状况下，该功能并未启用。

为了启用该功能，须要在hadoop-env.sh文件中定义HADOOP_MESTER项。

工做节点的守护进程启动以后，会把以HADOOP_MASTER为根的目录树与本地的HADOOP_ISNTALL目录同步（？？？未理解如何运用？！）

二、如何确保每一个工做节点的hadoop-env.sh文件已经设置好HADOOP_MASTER?

对于小型集群来讲很容易解决：

编写一个脚本文件，将主节点的hadoop-env.sh文件拷贝到全部工做节点便可。

对于大型集群来讲：

能够采用相似dsh的工具，并行拷贝文件。

此外，还能够编写hadoop-env.sh文件，添加以上内容，并将这个文件做为自动安装脚本的一部分

三、在一个大型集群中，集群全部节点同时向主节点发出rsync请求，会致使主节点瘫痪，这种状况如何避免？

为了不发生这种状况，须要将HADOOP_SLAVE_SLEEP项设为一小段时间，例如0.1（表示0.1秒钟）。

这样的话，主节点会在相继调用两个工做节点的指令的间隙主动休眠一段时间间隔。

HDFS

HDFS配置文件，各配置选项的做用（HDFS守护进程的关键属性）

一、dfs.name.dir

dfs.name.dir：描述一系列目录，来供namenode存储永久性的文件系统元数据

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

文件系统元数据：包括编辑日志（edits）和文件系统映像(image)

这些元数据会同时备份在全部指定的目录中。

dfs.name.dir描述一系列目录，其目的是支持冗余备份。

二、dfs.data.dir

dfs.data.dir：虽然dfs.data.dir也描述了一系列目录，可是其目的是循环地在各个目录中写数据。

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

所以，为了提升性能，最好分别为各个本地磁盘指定一个存储目录。

这样一来，数据块跨磁盘分布，针对不一样数据块的读操做能够并发执行，从而提高性能。

三、fs.checkpoint.dir

指定一系列目录来保存检查点。

与namenode相似，检查点映像文件会分别存储在各个目录中，以支持辅助namenode的冗余备份。

辅助namenode存放检查点的目录列表。在所列的各个目录中分别存放一份检查点文件的副本。

HDFS相关知识点

一、默认状况下HDFS的存储目录放在哪儿？

默认状况下，HDFS的存储目录放在Hadoop的临时目录之中（即hadoop.tmp.dir属性，默认值是/tmp/hadoop-${user.name}）

二、元数据文件保存在哪儿？

dfs.name.dir是用于配置元数据文件的。它描述一系列目录，其目的是支持冗余备份。

元数据文件会同时备份在全部由dfs.name.dir指定的一系列目录中。

一般状况下，配置dfs.name.dir将namenode的元数据写到一个（或两个）本地磁盘和一个远程磁盘（例如NFS挂载的目录）之中。

这样的话，即便本地磁盘发生故障，甚至整个namenode发生故障，均可以恢复元数据文件，而且重构新的namenode。

三、辅助namenode只是按期保存datanode的检查点，不提供namenode的最新备份。

四、dfs.name.dir和dfs.data.dir描述的一系列目录，他们的目的同样吗？

dfs.name.dir和dfs.data.dir都描述了一系列目录，可是他们的目的是不同的。

dfs.name.dir描述的一系列目录，其目的是支持冗余备份。

dfs.data.dir描述的一系列目录，其目的是循环地在各个目录中写数据。

MapReduce

MapReduce配置文件，各配置选项的做用（MapReduce守护进程的关键属性）

mapred.job.tracker

指定jobtracker的主机名或IP地址，以及它在监听的端口。并不是URI格式，而是“主机：端口”格式。一般状况下，端口号被设为8021。

此属性表示，jobtracker的RPC服务器所在的主机名称和端口号。

mapred.local.dir

存储做业中间数据的一个目录列表。做业终止时，数据被清除。

默认值为：${hadoop.tmp.dir}/mapred/local

此属性使用一个逗号分隔的目录名称列表，最好将这些目录分散到全部本地磁盘，以提高磁盘I/O效率。

一般状况下，会使用与datanode相同的磁盘和分区（可是不一样的目录）存储MapReduce的临时数据。

datanode的数据块存储目录由dfs.data.dir属性项指定。

mapred.system.dir

MapReduce使用分布式文件系统来和运行MapReduce任务的各个tasktracker共享文件。

在做业运行期间存储共享文件的目录，可使针对默认文件系统的相对路径。（默认系统由fs.default.name属性设定，通常为HDFS）

mapred.system.dir指定这些文件的存储目录，能够是针对默认文件系统的相对路径。

默认文件系统由fs.default.name属性设定，通常为HDFS。

mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum

此属性表示tasktracker机器上有多少核是可用的。

在任一时刻，运行在tasktracker之上的map/reduce任务的最大数。默认值为2。

mapred.child.java.opts

此属性表示tasktracker子JVM的有效内存大小

JVM选项，用于启动运行map和reduce任务的tasktracker子进程。

该属性能够针对每一个做业进行设置。例如，能够设置JVM的属性，以支持调试。

MapReduce相关知识点

一、在执行MapReduce做业的过程当中所产生的中间数据和工做文件保存在哪儿？

被写到临时本地文件中。

二、为何要保证本地临时存储空间的容量足够大？

由于执行MapReduce做业的过程当中所产生的中间数据和工做文件，包括map任务的输出数据，数据量可能很是大。所以必须保证本地临时存储空间（有mapred.local.dir属性设置）的容量足够大。

Hadoop的其余属性

集群成员

dfs.hosts

该属性记录即将做为datanode加入集群机器列表。

mapred.hosts

该属性记录即将做为tasktracker加入集群的机器列表。

dfs.hosts.exclude和mapred.hosts.exclude

该属性记录待移除的机器列表。

更多关于移除委任机器的介绍详见笔记中的“解除委任节点”：《第十章-管理Hadoop-笔记》

缓冲区大小

io.file.buffer.size

配置缓冲区大小（core-site.xml）

增大缓冲区容量会显著提升性能。经常使用大小配置为64KB或128KB。默认大小为4KB。

HDFS块大小

dfs.block.size

设置HDFS块大小（hdfs-site.xml）

经过增大集群块大小，下降namenode的内存压力，并向mapper传输更多数据。

默认大小为64MB，许多集群把块大小设为128MB或256MB。

一、默认状况下，HDFS块大小是64MB

默认状况下，HDFS块大小是64MB。可是，许多集群把块大小设为128MB（134 217 728字节）或256MB（268 435 456字节）以下降namenode的内存压力，并向mapper传输更多数据。

二、HDFS块大小可经过hdfs-site.xml中的dfs.block.size属性项设置块大小。

保留的存储空间

默认状况下，datanode可以使用存储目录上的全部闲置空间，这可能致使没有空间可供其余应用程序使用。

若是计划将部分空间留给其余应用程序（非HDFS），则须要设置dfs.datanode.du.reserved属性项来指定待保留的空间大小（以字节为单位）。

dfs.datanode.du.reserved

指定待保留的空间大小（以字节为单位）

回收站

一、Hadoop文件系统有回收站设施。

被删除的文件并未被真正删除，仅只转移到回收站（一个特定文件夹）中。

回收站中的文件在被永久删除以前仍会至少保留一段时间。

该信息由core-site.xml文件中的fs.trash.interval属性项（以分钟为单位）设置。默认状况下，该属性项的值是0，表示回收站特性无效。

二、回收站特性被启用时，每一个用户都有独立的回收站目录

回收站特性被启用时，每一个用户都有独立的回收站目录，即：home目录下的.Trash目录。

fs.trash.interval

core-site.xml文件中配置，配置回收站文件保留时间（以分钟为单位）。默认状况下，该属性项的值是0，表示回收站特性无效。

三、HDFS会自动删除回收站中的文件，可是其余文件系统并不具有这项功能

对于这些不自动删除回收站中文件的文件系统，用户必须按期执行指令来删除已在回收站中超过最小时间的全部文件：

% hadoop fs -expunge

Trash类的expunge（）方法也具备相同效果。

任务的内存限制

例如，假设一台运行tasktracker的机器的可用内存耗尽，则会影响其余正在运行的进程。为了防止因为map或reduce任务出现内存泄露，而影响集群中各个节点的正常工做，须要设置mapred.child.ulimit，限制由tasktracker发起的子进程的最大虚拟内存（单位是千字节）。该值要明显高于JVM内存（由mapred.child.java.opts设置），不然子JVM可能没法启动。

mapred.child.ulimit

限制由tasktracker发起的子进程的最大虚拟内存（单位是千字节）。

做业调度

在多用户的MapReduce设置中，若考虑将默认的FIFO（先进先出）做业调度方案改变为功能更强的调度方案，可参考《第6章-MapReduce的工做机制-做业的调度》一节。

Hadoop其余属性相关知识点

一、Hadoop缓冲区容量经过什么属性项来配置？

经过core-site.xml文件中的io.file.buffer.size属性项来配置缓冲区大小。

二、Hadoop块大小经过什么属性项来配置？

hdfs-site.xml文件中的dfs.block.size。

三、怎样的文件删除后可放到hadoop回收站中？

与其余操做系统相似，hadoop回收站是用户级特性。

只有由文件系统shell直接删除的文件才会放到回收站中，用程序删除的文件会被直接删除。

固然，也有例外状况——使用Trash类。

构造一个Trash实例，调用moveToTrash()方法会把指定路径的文件移到垃圾箱中。若是操做成功，该方法返回一个值；不然，若是回收站特性未被启动，或该文件已经在回收站中，该方法返回false。

四、怎样恢复hadoop回收站的文件

恢复也很简易：在.Trash的子目录中找到文件，并将其移出.Trash目录。

能够怎样提高性能？

一、为各个本地磁盘指定一个存储目录

针对dfs.data.dir配置的一系列目录。为了提升性能，最好分别为各个本地磁盘指定一个存储目录。

这样一来，数据块跨磁盘分布，针对不一样数据块的读操做能够并发执行，从而提高读性能。

二、使用noatime选项挂载磁盘

为了充分发挥性能，须要使用noatime选项挂载磁盘。

该选项意味着执行读操做时，所读文件的最新访问时间信息并不刷新，从而显著提高性能。

三、增大缓冲区容量

Hadoop使用使用一个4KB大小的缓冲区辅助I/O操做。

但对于现代硬件和操做系统来讲，这个容量太过于保守了。增大缓冲区容量会显著提升性能。

例如，64KB（65535字节）或256MB（131072字节）更为经常使用。

能够经过core-site.xml文件中的io.file.buffer.size属性项来设置缓冲区大小。