参考：

• Hadoop.The.Definitive.Guide.4th
• Hadoop官方文档
  • v2.9.2 - https://hadoop.apache.org/docs/r2.9.2/
  • stable - https://hadoop.apache.org/docs/stable/index.html

hadoop3 与 hadoop2 之间的配置信息，存在一些差异。比如 slaves 文件重命名为 workers文件。
有多个配置文件适用于Hadoop安装，下表列举了最重要的几个文件。
Hadoop configuration files

这几个重要文件都放在Hadoop分发包的 etc/hadoop 目录中。配置目录可以被重新安置在文件系统的其他地方(Hadoop安装路径的外面，以便于升级)，只要启动守护进程时使用 —config 选项（或等价的，使用 HADOOP_CONF_DIR 环境变量设置）说明这个目录在本地文件系统的位置就可以了。

1 配置(信息或文件)管理

Configuration Management
Hadoop并没有将所有配置信息放在一个单独的全局位置中。反之，集群的每个Hadoop节点都各自保存一系列配置文件，并由管理员完成这些配置文件的同步工作。有并行shell工具帮助完成同步工作，诸如 dsh 或 pdsh。在这方面，Hadoop集群管理工具例如Cloudera Manager 和Apache Ambari 表现突出，因为在集群间传递修改信息是它们的关注点。
Hadoop也支持为所有master 机器和worker 机器采用同一套配置文件。 这个做法的最大优势在于简单，不仅体现在理论上(仅需处理一套配置文件)，也体现在可操作性上(使用Hadoop脚本就能进行管理)。

但是，这种一体适用的配置模型并不合适某些集群。以扩展集群为例，当试图为集群添加新机器，且新机器的硬件规格与现有机器不同时，则需要新建一套配置文件，以充分利用新硬件的额外资源。
在这种情况下，需要引入“机器类”的概念，为每一机器类维护单独的配置文件。Hadoop没有提供执行这个操作的工具，需要借助外部工具来执行该配置操作，例如Chef、Puppet、CFEngine 和Bcfg2等。

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

2 环境设置

本节探讨如何设置 hadoop-env.sh 文件中的变量。MapReduce 和 YARN(HDFS除外)都有类似的配置文件，分别为mapred-env.sh 和 yarn-env.sh，文件中的变量和组件相关，并且可以进行设置。
注意，hadoop-env.sh 文件里设置的值会被MapReduce和YARN文件覆盖。

2.1 Java

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

2.2 内存堆大小

在默认情况下，Hadoop 为各个守护进程分配1000 MB(IGB)内存。
该内存值由 hadoop-env.sh 文件的 HADOOP_HEAPSIZE 参数控制。也可以通过设置环境变量为单个守护进程修改堆大小。例如，在 yarn-en.sh 文件中设置 YARN_RESOURCEMANAGER_HEAPSIZE，即可覆盖资源管理器的堆大小。

令人惊讶的是，尽管为 namenode 分配更多的堆空间是很常见的事，但对于HDFS守护进程而言并没有相应的环境变量。当然有别的途径可以设置namenode堆空间大小，见接下来的讨论。
除了守护进程对内存的需求，节点管理器还需为应用程序分配容器(container)，因此需要综合考虑上述因素来计算一个工作机器的总体内存需求。

一个守护进程究竟需要多少内存？
由于namenode会在内存中维护所有文件的每个数据块的引用，因此namenode很可能会“吃光”分配给它的所有内存。很难套用一个公式来精确计算内存需求量，因为内存需求量取决于多个因素，包括每个文件包含的数据块数、文件名称的长度、文件系统中的目录数等。
此外，在不同Hadoop 版本下，namenode的内存需求也不相同。
1000MB内存(默认配置)通常足够管理数百万个文件。但是根据经验来看，保守估计需要为每1百万个数据块分配1000MB内存空间。以一个含200节点的集群为例，假设每个节点有24TB磁盘空间，数据块大小是128MB，复本数是3的话，则该节点约有12百万个数据块(甚至更多)：200 24,000,000 MB / (128 MB3)。因此，此时namenode 的内存空间最好一开始设为 12000 MB。
也可以只增加namenode的内存分配量而不改变其他Hadoop守护进程的内存分配，即设置 hadoop_env.sh 文件的 HADOOP_NAMENODE_OPTS 属性包含一个JVM选项以设定内存大小。HADOOP_NAMENODE_OPTS 允许向 namenode 的JVM传递额外的选项。以Sun JVM为例，-Xmx2000m 选项表示为namenode 分配2000MB内存空间。
由于辅助namenode 的内存需求量和主namenode 差不多，所以一旦更改namenode的内存分配的话还需对辅助namenode 做相同更改(使用 HADOOP_SECONDARYNAMENODE_OPTS 变量)。

2.3 系统日志文件

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

export HADOOP_LOG_DIR=/var/log/hadoop

如果日志目录并不存在，则会首先创建该目录(如果操作失败，请确认相关的Unix Hadoop用户是否有权创建该目录)。

运行在各台机器上的各个Hadoop守护进程会产生两类日志文件。
第一类日志文件(以 .log 作为后缀名)是通过 log4j 记录的。鉴于大部分应用程序的日志消息都写到该日志文件中，故障诊断的首要步骤即为检查该文件。标准的Hadoop log4j 配置采用日常滚动文件追加方式(daily rolling file
appender)来循环管理日志文件。系统不自动删除过期的日志文件，而是留待用户定期删除或存档，以节约本地磁盘空间。
第二类日志文件后缀名为 .out ，记录标准输出和标准错误日志。由于 Hadoop 使用log4j记录日志，所以该文件通常只包含少量记录，甚至为空。重启守护进程时，系统会创建一个新文件来记录此类日志。系统仅保留最新的5个日志文件。旧的日志文件会附加一个介于1和5之间的数字后缀，5表示最旧的文件。

日志文件的名称(两种类型)包含运行守护进程的用户名称、守护进程名称和本地主机名等信息。例如，hadoop-hdfs-datanode-ip-10-45-174-112.log.2014-09-20 就是一个日志文件的名称。这种命名方法保证集群内所有机器的日志文件名称各不相同，从而可以将所有日志文件存到一个目录中。
日志文件名称中的“用户名称”部分实际对应 hadoop-env.sh 文件中的 HADOOP_IDENT_STRING 项。如果想采用其他名称，可以修改 HADOOP_IDENT_STRING 项。

2.4 SSH设置

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

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

在 hadoop-en.sh 文件中定义 HADOOP_SSH_OPTS 环境变量还能够向SSH传递更多选项。参考ssh和ssh_config使用手册，了解更多SSH设置。

# 生成公钥和私钥： 
$ ssh-keygen -t rsa 
# 然后敲（三个回车），就会生成两个文件 id_rsa（私钥）、id_rsa.pub（公钥） 
# 将公钥拷贝到要免密登录的目标机器上，实现到hostname机器的免密登录
$ ssh-copy-id hostname
# 直接连接
$ ssh hostname

用户home目录下 .ssh 文件夹里会生成四个文件：

• known_hosts
  记录 ssh 访问过计算机的公钥(public key)
• id_rsa
  生成的私钥
• id_rsa.pub
  生成的公钥
• authorized_keys
  存放授权过得无密登录服务器公钥

  3 Hadoop守护进程的关键属性

  Hadoop的配置属性分散在Hadoop的site文件之中，包括 core-site.xml、hdfs-site.xml 和 yarn-site.xml。
  对于一个正在运行的守护进程，要想知道其实际配置，可以访问该进程web服务器上的 /conf 页面。例如，http://resource-manager-host:8088/conf 表示资源管理器当前的运行配置。这个页面显示了这个守护进程正在使用的配置，配置合并了站点和默认配置文件，并给出了每个属性的来源文件。

  3.1 HDFS

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

属性 fs.defaultFS 也指定了默认文件系统，用来解析相对路径。相对路径的长度更短，使用更便捷（不需要了解特定 namenode 的地址）。例如，假设默认文件系统下面示例所示的那样，则相对 URI /a/b 解析为hdfs://namenode/a/b。

Example. A typical core-site.xml configuration file

<?xml version="1.0"?>
<!-- core-site.xml -->
<configuration>
  <property>
    <name>fs.defaultFS</name>
    <value>hdfs://namenode/</value>
  </property>
</configuration>

当用户在运行HDFS时，鉴于 fs.defaultFS 指定了HDFS的namenode和默认文件系统，则HDFS必须是服务器配置（守护进程操作）的默认文件系统。值得注意的是，为了操作方便，也允许在客户端配置（命令行操作）中将其他文件系统指定为默认文件系统。
例如，假设系统使用HDFS和S3两种文件系统，则可以在客户端配置中将任一文件系统指定为默认文件系统。这样的话，就能用相对URI指向默认文件系统，用绝对URI指向其他文件系统。

此外，还有其他一些关于HDFS的配置选项，包括 namenode 和datanode存储目录的属性。

• 属性 dfs.namenode.name.dir
  指定一系列目录来供 namenode 存储永久性的文件系统元数据（编辑日志和文件系统映像）。这些元数据文件会同时备份在所有指定目录中。
  通常，通过配置 dfs.namenode.name.dir 属性将 namenode 元数据写到一两个本地磁盘和一个远程磁盘(例如NFS挂载的目录)之中。（冗余备份）这样的话，即使本地磁盘发生故障，甚至整个namenode 发生故障，都可以恢复元数据文件并且重构新的namenode。（辅助namenode 只是定期保存namenode的检查点，不维护namenode的最新备份。）
• 属性 dfs.datanode.data.dir
  可以设定 datanode 存储数据块的目录列表。
  前面用 dfs.namenode.name.dir 描述一系列目录，其目的是支持namenode 进行冗余备份。
  虽然 dfs.datanode.data.dir 也描述了一系列目录，但是其目的是使 datanode 循环地在各个目录中写数据。因此，为了提高性能，最好分别为各个本地磁盘指定一个存储目录。这样一来，数据块跨磁盘分布，针对不同数据块的读操作可以并发执行，从而提升读取性能。

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

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

Example. **A typical __hdfs-site.xml__ configuration file**

<?xml version="1.0"?>
<!-- hdfs-site.xml -->
<configuration>
  <property>
    <name>dfs.namenode.name.dir</ name>
    <value>/disk1/hdfs/name,/remote/hdfs/name</value>
  </property>
  <property>
    <name >dfs.datanode.data.dir</name>
    <value>/disk1/hdfs/data,/disk2/hdfs/data</value>
  </property>
  <property>
    <name>dfs.namenode.checkpoint.dir</name>
    <value>/disk1/hdfs/namesecondary,/disk2/hdfs/namesecondary</value>
  </property>
</configuration>

3.2 YARN

为了运行YARN，需要指定一台机器作为资源管理器。
最简单的做法是将属性 yarn.resourcemanager.hostname 设置为用于运行资源管理器的机器的主机名或IP地址。资源管理器服务器的地址基本都可以从该属性获得。例如， yarn.resourcemanager.address 的格式为主机-端口对，yarn.resourcemanager.hostname 表示默认主机。在MapReduce客户端配置中，需要通过RPC连接到资
源管理器时，会用到这个属性。

在执行MapReduce作业的过程中所产生的中间数据和工作文件被写到临时本地文件之中。由于这些数据包括map任务的输出数据，数据量可能非常大，因此必须保证YARN容器本地临时存储空间(由 yarn.nodemanager.local-dirs 属性设置)的容量足够大。yarn.nodemanager.local-dirs 属性使用一个逗号分隔的目录名称列表，最好将这些目录分散到所有本地磁盘，以提升磁盘I0操作的效率。通常情况下，YARN本地存储会使用与datanode数据块存储相同的磁盘和分区(但是不同的目录)。如前所述，datanode 数据块存储目录由 dfs.datanode.data.dir 属性项指定。
与MapReduce 1不同，YARN 没有tasktracker, 它依赖于shuffle 句柄将map任务的输出送给reduce任务。shufle句柄是长期运行于节点管理器的附加服务。由于YARN是一个通用目的的服务，因此要通过将 yarn-site.xml 文件中的yarn.nodemanager.aux-services 属性设置为 mapreduce_shuffle 来显式启用MapReduce的shuffle句柄。

Example. **A typical __yarn-site.xml__ configuration file**

<?xml version="1.0"?>
<!-- yarn-site.xml -->
<configuration>
  <property>
    <name>yarn.resourcemanager.hostname</ nane>
    <value>resourcemanager</value>
  </property>
  <property>
    <name>yarn.nodemanager.local-dirs</nane>
    <value>/disk1/nm-local-dir,/disk2/nm-local-dir</value>
  </property>
  <property>
    <name>yarn.nodemanager.aux-services</ nane>
    <value>mapreduce_shuffle</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</nane>
    <value>16384</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.cpu-vcores</ nane>
    <value>16</value>
  </property>
</configuration>

3.3 内存设置(YARN和MapReduce)

与MapReduce 1的基于slot的模型相比，YARN 以更精细化的方式来管理内存。YARN不会立刻指定一个节点上可以运行的map和reduce slot 的最大数目，相反，它允许应用程序为一个任务请求任意规模的内存（在限制范围内）。

在YARN模型中，节点管理器从一个内存池中分配内存，因此，在一个特定节点上运行的任务数量取决于这些任务对内存的总需求量，而不简单取决于固定的slot数量。

计算为一个运行容器的节点管理器分配多少内存要取决于机器上的物理内存。每个Hadoop守护进程使用1000MB内存，因此需要2000MB内存来运行1个datanode和1个节点管理器。为机器上运行的其他进程留出足够的内存后，剩余的内存可以被指定给节点管理器的容器使用，只要通过将 yarn.nodemanager.resource.memory-mb 配置属性设置为总分配量(单位是MB)。默认是8192 MB，对于大多数设置来说太低了。

接下来是确定如何为单个作业设置内存选项。有两种主要控制方法：

• 一个是控制YARN分配的容器大小
• 另一个是控制容器中运行的Java进程堆大小。

MapReduce的内存控制都由客户端在作业配置中设置。YARN设置是集群层面的设置，客户端不能修改。

容器大小由属性 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 决定，默认值都为1024MB。application master会使用这些设置以从集群中请求资源；此外，节点管理器也会使用这些设置来运行、监控任务容器。Java进程的堆大小由 mapred.child.java.opts 设置，默认是200 MB。也可以单独为map和reduce任务设置Java选项。（mapreduce.map. java.opts 和 mapreduce.reduce.java.opts 属性）

_
例如，假设 mapred.child.java.opts 被设为 -Xmx800m，mapreduce.map.memory.mb 被设为默认值 1024MB，当map任务启动时，节点管理器会为该任务分配1个1024MB的容器(在该任务运行期间，节点管理器的内存池也会相应降低1024MB)，并启动最大堆配置为800MB的任务 JVM。 注意，JVM进程的内存开销将比该堆的规模要大，开销依赖于所使用的本地库(native libraries)、永久生成空间(permanent generation space)等因素。
需要注意的是，JVM进程(包括它创建的任何进程，如Streaming)所使用的物理内存必须不超出分配给它的内存大小(1024MB)。如果一个容器使用的内存超过所分配的量，就会被节点管理器终止，并标记为失败。
（物理内存/12GB > nm总分配/8GB > 单个容器分配/1GB > 任务jvm开销/0.9GB > 任务jvm堆大小/0.8GB）

YARN调度器会指定一个最小和最大内存分配量。默认情况下，最小内存分配量是1024 MB(由 yarn.scheduler.minimum-allocation-mb 设置)，默认情况下，最大内存分配量是8192 MB(由 yarn.scheduler.maximum-allocation-mb 设置)。

容器还需要满足对虚拟内存的限制。如果容器所使用的虚拟内存量超出预定系数和所分配的物理内存的乘积，则节点管理器也会终止进程。该系数由 yarn.nodemanager.vmem-pmem-ratio 属性指定，默认值是2.1。 在前面的例子中，虚拟内存规模的上限值为 2150MB，即2.1 * 1024 MB。

除了使用参数来配置内存使用之外，还可以使用 MapReduce 任务计数器来监控任务执行过程中的真实内存消费量。这些计数器包括：PHYSICAL_MEMORY_BYTES 、VIRTUAL_MEMORY_BYTES 和 COMMITTED_HEAP_BYTES ， 分别描述了在某一时刻各种内存的使用情况，因此也适用于在任务尝试期间的观察。

3.4 CPU设置(YARN和MapReduce)

除了内存外，YARN将CPU的使用作为一种资源进行管理，应用程序可以申请所需要的核数量。通过属性yarn.nodemanager.resource.cpu-vcores 可以设置节点管理器分配给容器的核数量。应该设置为机器的总核数减去机器上运行的每个守护进程(datanode、节点管理器和其他长期运行的进程)占用的核数(每个进程占用1个核)。
通过设置属性 mapreduce.map.cpu.vcores 和 mapreduce.reduce.cpu.vcores ，MapReduce作业能够控制分配给map和reduce容器的核数量。两者的默认值均为1，适合通常的单线程MapReduce任务，因为这些任务使用单核就足够了。

当调度过程中对核数量进行掌控后(这样，当机器没有空余核时，一个容器将不会分到核)，节点管理器默认情况下将不会限制运行中的容器对CPU的实际使用。这意味着一个容器可能会出现滥用配额的情况，例如使用超额的CPU，而这可能会饿死在同一主机上运行的其他容器。YARN提供了基于Linux的 cgroup 技术的、强制实施CPU限制的手段。为此，节点管理器的容器执行类( yarn.nodemanager.containerexecutor.class )必须被设置为使用
LinuxContainerExecutor 类，并且必须将 LinuxContainerExecutor 类配置为使用cgroup， 详情查阅 yarn.nodemanager.linux-container-executor 下(扩展)的属性。

3.5 属性表总结

HDFS__守护进程的关键属性

在默认情况下，HDFS 的存储目录放在 Hadoop 的临时目录下（通过 hadoop.tmp.dir 属性配置，默认值是 /tmp/hadoop-${user .name} ）。因此，正确设置这些属性的重要性在于，即使清除了系统的临时目录。数据也不会丢失。

YARN__守护进程的关键属性

MapReduce作业内存属性(由客户端设置)

MapReduce作业CPU属性(由客户端设置)

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

Hadoop守护进程一般同时运行RPC和HTTP两个服务器，RPC服务器支持守护进程间的通信，HTTP服务器则提供与用户交互的Web页面。需要分别为各个服务器配置网络地址和监听端口号。
端口号 0 表示服务器会选择一个空闲的端口号，但由于这种做法与集群范围内的防火墙策略不兼容，所以这通常是不推荐的。因为防火墙通常开放一定的端口，而不会放开全部的端口，防止对服务器造成冲击。

通常，用于设置服务器RPC和HTTP地址的属性担负着双重责任：一方面它们决定了服务器将绑定的网络接口，另一方面，客户端或集群中的其他机器使用它们连接服务器。例如，节点管理器使用 yarn.resourcemanager.resource-tracker.address 属性来确定它们的资源管理器的地址。

用户经常希望服务器同时可以绑定多个网络接口，将网络地址设为 0.0.0.0 可以达到这个目的，但是却破坏了上述第二种情况，因为这个地址无法被客户端或集群中的其他机器解析。
当网络地址被设为 0.0.0.0 的时候，Hadoop将与本机上所有的地址绑定。用户也可以将服务器与某个指定的地址绑定。（猜测性总结，未在 mapred-site.xml 文件中配置 jobhistory server的地址时，地址默认为 0.0.0.0，则此时可以在任意一个节点上启动历史服务器，并能被外部访问。若指定了address，只能在应用了包含该地址的网卡主机上启动。）
一种解决方案是将客户端和服务器的配置分开，但是更好的一种方案是为服务器绑定主机。通过将 yarn.resourcemanager.hostname 设定为主机名或IP地址，yarn.resourcemanager.bind-host 设定为0.0.0.0，可以确保资源管理器能够与机器上的所有地址绑定，且同时能为节点管理器和客户端提供可解析的地址。
除了RPC服务器之外，各个datanode还运行TCP/IP服务器以支持块传输。属性 dfs.datanode.address 设定了服务器地址和端口号，默认值是 0.0.0.0:50010。有多个网络接口时，还可以为各个datanode选择某一个网络接口作为IP地址(针对HTTP和RPC服务器)。相关属性是 dfs.datanode.dns.interface ，默认值是default，表示使用默认的网络接口。可以修改该属性项来变更网络接口的地址(例如，eth0)。
注意：Hadoop3版本中，各守护进程的地址和端口号与其它版本存在差异。

RPC server properties

HTTP server properties

5 Hadoop的其它属性

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

5.1 集群成员

为了便于在将来添加或移除节点，可以通过文件来指定一些允许作为datanode或节点管理器加入集群的经过认证的机器。
属性 dfs.hosts 记录允许作为datanode加入集群机器列表；属性 yarn.resourcemanager.nodes.include-path 记录允许作为节点管理器加入集群的机器列表。
与之相对应的，属性 dfs.hosts.exclude 和 yarn.resourcemanager.nodes.exclude-path 所指定的文件分别包含待解除的机器列表。

5.2 缓冲区大小

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

5.3 HDFS块大小

在默认情况下，HDFS 块大小是128 MB，但是许多集群把块大小设得更大(如256MB，268435456 字节)以降低namenode的内存压力，并向mapper传输更多数据。可以通过 hdfs-site.xml 文件中的 dfs.blocksize 属性设置块的大小(以字节为单位)。

5.4 保留的存储空间

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

5.5 回收站

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

与许多操作系统类似，Hadoop 的回收站设施是用户级特性，换句话说，只有由文件系统shell直接删除的文件才会被放到回收站中，用程序删除的文件会被直接删除。当然，也有例外的情况，如使用 Trash 类。构造一个Trash 实例，调用 moveToTrash() 方法会把指定路径的文件移到回收站中。该方法返回一个表示成功的值；否则，返回一个false，这意味着回收站特性未被启动，或该文件已经在回收站中。
当回收站特性被启用时，每个用户都有独立的回收站目录，即 home 目录下的 .Trash 目录。恢复文件也很简易：在 .Trash 的子目录中找到文件，并将其移出 .Trash 目录。

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

% hadoop fs - expunge

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

5.6 作业调度

在针对多用户的设置中，可以考虑升级作业调度器队列配置，以反映在组织方面的需求。例如，可以为使用集群的每个组设置一个队列。

5.7 慢启动reduce

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

5.8 短回路本地读

当从HDFS读取文件时，客户端联系datanode，然后数据通过TCP连接发送给客户端。
如果正在读取的数据块和客户端在同一节点上，那么客户端绕过网络从磁盘上直接读取数据效率会更高。这又称作“短回路本地读”(shor-circuit local read)，这种方式能够让应用程序（如HBase）执行效率更高。
将属性 dfs.client.read.shortcircuit 设置为 true ，即可启用短回路本地读。

该读操作基于Unix域套接字实现，在客户端和datanode之间的通信中使用了一个本地路径。该路径使用属性 dfs.domain.socket.path 进行设置，且必须是一条仅有 datanode 用户(通常为hdfs)或 root 用户能够创建的路径，例如 /var/run/hadoop-hdfs/dn_socket。