Hadoop 管理

1.HDFS

1）永久性数据结构

--namenode

存放地址

hdfs-site.xml

<property>
  <name>dfs.name.dir</name>
  <value>/home/hadoop/hdfs/name</value>
  <final>true</final>
</property>

目录结构

current
|--VERSION
|--edits
|--fsimage
|--fstime

VERSION文件时一个Java属性文件，其中包含正在运行的HDFS版本信息。

----layoutVersion是一个负数，描述HDFS永久性数据结构的版本，这个版本号与Hadoop发布包的版本号无关。只要布局更新，版本号便会递减，HDFS也需要升级。

----namespaceID是文件系统的唯一标识，是在文件首次格式化format的时候生成。任何datanode在注册到namenode之前都不知道namespaceID值，因此namenode可以用该属性鉴别新建的datanode。

----cTime属性标记了NameNode存储系统的创建时间，对于刚格式化的存储系统，这个属性值为0；但在文件系统升级之后，该值会更新到新的时间戳。

----storageType属性说明该存储目录包含的是NameNode的数据结构。

#Fri Apr 04 10:35:58 CST 2014
namespaceID=1068158182
cTime=0
storageType=NAME_NODE
layoutVersion=-41

edits：编辑日志文件，文件系统客户端执行写操作时，首先被记录到编辑日志文件中。namenode在内存中维护文件系统的元数据；当编辑日志被修改时，相关元数据也同步更新。在每次执行写操作之后，且在客户端发送成功代码之前，编辑日志都需要更新和同步。

fsimage：文件系统元数据的一个永久性检查点。并非每一个写操作都会更新这个文件，因为fsimage是个大文件，如果频繁执行写操作，会使系统运行极为缓慢。但这个特性根本不会降低系统的恢复能力，因为如果NameNode发生故障，可以先把fsimage文件载入到内存重构新近的元数据，再执行编辑日志记录的各项操作。事实上，NameNode在启动阶段正是这样做的。

fsimage文件包含文件系统中的所有目录和文件inode的序列化信息。每个inode都是一个文件或目录的元数据的内容描述方式。
数据块存储在DataNode中，但fsimage文件并不描述DataNode。而取而代之的是，NameNode将这种块映射关系放在内存中。当datanode加入集群时，namenode向datanode索取块列表以建立块映射关系；namenode还将定期征询datanode以确保它拥有最新的块映射。

当频繁执行操作的时候，edits文件无限增长。尽管这种情况对NameNode的运行没有影响，但由于需要恢复编辑日志中的各项操作，NameNode重启操作会比较慢，这段时间内文件系统处于离线状态，造成无法使用。解决方案就是运行辅助NameNode，为主NameNode内存中的文件系统元数据创建检查点。创建检查点的步骤如下：

(1)辅助NameNode请求主NameNode停止使用edits文件，暂时将新的写操作记录到一个新文件中(命名为edits.new)。

(2)辅助NameNode从NameNode获取fsimage文件和edit log(采用HTTP GET方式)。

(3)辅助NameNode将fsimage文件载入内存，应用edit log，创建一个新的fsimage文件。

(4)辅助NameNode将新的fsimage文件发回NameNode(采用HTTP POST方式)。

(5)主NameNode用从辅助NameNode接收的fsimage文件替换旧的fsimage文件，用1所产生的edits.new改为edits 替换原来的edits，同时，还更新fstime文件来记录检查点执行的时间。 

辅助namenode相关配置

core-site.xml

<property>
  <name>fs.checkpoint.dir</name>
  <value>${hadoop.tmp.dir}/dfs/namesecondary</value>
  <description>Determines where on the local filesystem the DFS secondary
      name node should store the temporary images to merge.
      If this is a comma-delimited list of directories then the image is
      replicated in all of the directories for redundancy.
  </description>
</property>

<property>
  <name>fs.checkpoint.period</name>
  <value>3600</value>
  <description>The number of seconds between two periodic checkpoints.
  </description>
</property>

<property>
  <name>fs.checkpoint.size</name>
  <value>67108864</value>
  <description>The size of the current edit log (in bytes) that triggers
       a periodic checkpoint even if the fs.checkpoint.period hasn't expired.
  </description>
</property>

当namenode处于安全模式时，管理员也可以调用hadoop dfsadmin -saveNamespace命令来创建检查点。

--辅助namenode

辅助NameNode创建检查点的过程不仅是为NameNode创建检查点数据，还可以用作NameNode元数据的备份（尽管非最新），它的目录结构如下：

current
|--VERSION
|--edits
|--fsimage
|--fstime
previous.checkpoint
|--VERSION
|--edits
|--fsimage
|--fstime

目录结构previouts.checkpoint和NameNode结构相同，这种设计方案的好处是，在NameNode发生故障时（假设没有及时备份，甚至NFS也没有），可以从Secondary NameNode恢复数据。一种方法是将相关存储目录复制到新的NameNode中；另一种方法是使用-importCheckpoint选项重启Secondary NameNode守护进程，从而将Secondary NameNode用作新的NameNode。借助这个选项，dfs.name.dir属性定义的目录中没有元数据时，Secondary NameNode就从fs.checkpoint.dir目录载入最新的检查点数据。

--datanode

和NameNode不同，DataNode的存储目录是启动时自动创建的，不需要额外格式化。DataNode的关键文件和目录如下：

${dfs.data.dir}/current/VERSION
                       /blk_<id_1>
                       /blk_<id_1>.meta
                       /blk_<id_2>
                       /blk_<id_2>.meta
                       /......
                       /blk_<id_64>
                       /blk_<id_64>.meta
                       /subdir0/
                       /subdir1/
                       /......
                       /subdir63/

DataNode的VERSION文件和NameNode的VERSION文件非常相似，内容类似如下：

#Fri Apr 04 10:49:08 CST 2014
namespaceID=1068158182
storageID=DS-2013456581-192.168.153.129-50010-1393639837574
cTime=0
storageType=DATA_NODE
layoutVersion=-41

namespaceID属性、cTime属性和layoutVersion属性的值与NameNode中的值相同。实际上，namespaceID是DataNode首次访问NameNode的时候从NameNode处读取的。各个DataNode的storageID都不相同（但对于存储目录是相同的），NameNode可用这个属性来识别DataNode。storageType表示这个目录是datanode的存储目录。

DataNode的current目录中的文件有blk_前缀的，包含两种文件类型：HDFS块文件（仅包含原始数据）和块的元数据文件（含.meta后缀）。

当目录中数据块的数量增加到一定规模时，DataNode会创建一个子目录来存放新的数据块及其元数据信息。这个数量规模由属性dfs.DataNode.numblocks进行配置，默认是64块就创建一个子目录。终极目标是设计一棵高扇出的树，只要访问少数几个目录即可获取数据，同时也避免了很多文件放在一个目录之中的难题。如果dfs.data.dir属性指定了不同磁盘上的多个目录，那么数据块会以轮转的方式写到各个目录中。注意：同一个DataNode上的每个磁盘上的块不会重复，不同DataNode之间的块才可能重复。

2）安全模式

NameNode启动时，是在安全模式下的。它首先将fsimage载入内存，并执行edit log中的各项操作。一旦在内存中成功创建文件系统元数据的映像，则创建一个新的fsimage文件（不需要借助Secondary NameNode）和一个空的编辑日志。此时NameNode监听RPC和HTTP请求。这个过程NameNode的文件系统对于客户端来说是只读的。由于在安全模式下，写、删除或重命名等操作都会失败。

严格来说，在安全模式下，只有那些访问文件系统元数据的文件系统操作是肯定成功的，例如显示目录列表等。对于读文件操作来说，只有集群中当前datanode上的块可用时，才能够读取文件。但文件修改操作（包括写、删除或重命名）均会失败。

需要强调的是数据块的位置并不是NameNode维护的，而是以块列表的形式存储在DataNode中。在系统的正常操作期间，NameNode会在内存中保留所有块位置的映射信息。各个DataNode会向NameNode检查块列表信息（即向NameNode发送块列表的最新情况），NameNode了解到足够多的块位置信息之后，即可高效运行文件系统。但如果NameNode没有检查到足够多的DataNode，则需要将块复制到其他DataNode，而大多数情况下这都不必要的（因为只要等待检查到若干DataNode检入），这会浪费很多资源。所以需要安全模式，在安全模式下NameNode并不向DataNode发出任何块复制或删除的指令。如果满足“最小复本条件”，NameNode会在30秒后退出安全模式，所谓最小复本条件指在整个文件系统中99.9%的块满足dfs.replication.min属性设置的值即可。

在启动一个刚刚格式化的HDFS集群时，系统中没有任何块，所以不会进入安全模式。

相关命令

--查看namenode是否处于安全模式

hadoop dfsadmin -safemode get

--执行某条命令之前先确保NameNode已退出安全模式

hadoop dfsadmin -safemode wait

--进入安全模式

hadoop dfsadmin -safemode enter

--离开安全模式

hadoop dfsadmin -safemode leave

3）日志审计

HDFS的日志能够记录所有文件系统访问请求，有些组织需要这项特性来进行审计，对日志进行审计是log4j在INFO级别实现。默认情况下此特性未开启：

log4j.properties

log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=WARN

4）工具

--dfsadmin

可查找HDFS状态信息，也可以在HDFS上执行管理操作，调用形式：hadoop dfsadmin。仅当用户具有超级用户权限，才可以使用这个工具修改HDFS的状态。

--fsck

检查HDFS中文件的健康状况，该工具会查找那些所有DataNode中缺失的块以及过少或过多副本的块。e.g.

hadoop fsck /

结果：

.................................Status: HEALTHY
 Total size:    5690256 B
 Total dirs:    43
 Total files:   37
 Total blocks (validated):      31 (avg. block size 183556 B)
 Minimally replicated blocks:   31 (100.0 %)
 //过多复制的块
 Over-replicated blocks:        0 (0.0 %)
 //仍需复制的块
 Under-replicated blocks:       3 (9.67742 %)
 //错误复制的块
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     2.0
 //损坏的块
 Corrupt blocks:                0
 //缺失的复本
 Missing replicas:              24 (38.70968 %)
 Number of data-nodes:          2
 Number of racks:               1
FSCK ended at Fri Apr 04 11:48:18 CST 2014 in 80 milliseconds

fsck工具从给定路径开始循环遍历文件系统的命名空间，并检查它所找到的所有文件。 对于检查过的每个文件，都会打印一个“.”。在此过程中，该工具获取文件数据块的元数据并找出问题或检查它们是否一致。注意，fsck工具只是从namenode获取信息，并不与任何datanode进行交互，因此并不真正获取块数据。

所支持的选项：

--move 将受影响的文件移到HDFS的/lost+found/目录
--delete 删除受影响文件
--files 显示第一行信息，包括文件名称、大小、块数量和健康状况(是否有缺损块)
--blocks 描述文件中各个快信息，每一个块一行
--racks 显示各个块的机架位置和DataNode的地址

--datanode块扫描器

各个DataNode运行一个块扫描器，定期检测本节点上的所有块，从而在客户端读到坏块之前及时地检测和修复坏块。扫描周期dfs.datanode.scan.period.hours。扫描器还使用节流机制，来维持datanode磁盘带宽。

用户可通过 http://datanode:50075/blockScannerReport 来获取该DataNode的块测试报告

http://node0:50075/blockScannerReport?listblocks 则会在报告中列出该datanode上所有的块及其最新验证状态。

blk_-4551889395236817790_2443 : status : ok     type : none   scan time : 0               not yet verified
blk_6929772040124236062_2310 : status : ok     type : local  scan time : 1395629341831   2014-03-24 10:49:01,831

type:none 扫描尚未结束

type:local  扫描由后台线程执行

type:remote 扫描由客户端或其他datanode执行

--均衡器

均衡器(balancer)程序是一个Hadoop守护程序，它将块从忙碌的DataNode移到相对空闲的DataNode，从而重新分配块。同时坚持复本放至策略，将复本分散到不同机架，以降低数据损坏率。

均衡目标：每个datanode的使用率（已使用的空间/空间容量）和集群的使用率非常接近，差距不超过给定的阀值。

开启

start-balancer.sh

-threshold参数指定阀值，默认为10%。在任何时刻，集群中都只运行一个均衡器。

均衡器被设计在后台运行，而且带宽也是受限的。

hdfs-site.xml

<property>
  <name>dfs.balance.bandwidthPerSec</name>
  <value>1048576</value>
  <description>
        Specifies the maximum amount of bandwidth that each datanode
        can utilize for the balancing purpose in term of
        the number of bytes per second.
  </description>
</property>

2.监控

监控的目标在于检测集群在何时未提供所期望的服务。主守护进程是最需要监控的，包括主namenode，辅助namenode和jobtracker。

1）日志

所有Hadoop守护进程都会产生日志文件，配置log4j.properties。

--设置日志级别

http://jobtracker-host:50030/logLevel

hadoop daemonlog -setLevel jobtracker-host:50030 org.apache.hadoop.mapred.JobTracker DEBUG

这两种方式修改的日志级别会在守护进程重启时被重置

--获取堆栈轨迹

http://jobtracker-host:50030/stacks

2）度量

HDFS和MapReduce守护进程的事件和度量相关的信息，这些信息统称为“度量”。

HDFS和MapReduce守护进程的事件和度量相关的信息，这些信息统称为“度量”。

度量从属于特定的上下文(Context)。目前，Hadoop使用dfs，mapred，rpc和jvm四个上下文。Hadoop守护进程通常在多个上下文中收集度量。

--和计数器的区别

度量由hadoop守护进程收集，计数器由MapReduce任务收集

度量为管理员服务，计数器为MapReduce用户服务

conf/hadoop-metrics.properties

dfs.class=org.apache.hadoop.metrics.spi.NullContext
mapred.class=org.apache.hadoop.metrics.spi.NullContext
jvm.class=org.apache.hadoop.metrics.spi.NullContext
rpc.class=org.apache.hadoop.metrics.spi.NullContext

每一行分别配置一个不同的上下文，上下文接口为MetricsContext。

--NullContext

既不发布也不更新度量。

--FileContext

将度量写到一个本地文件中。

--GangliaContext

针对超大规模的集群的开源的分布式监控系统，运行之后仅消耗各个节点上很少的资源。

--NullContextWithUpdateThread

不向外部系统发布度量，但会借助定时器定期刷新存储在内存中的度量值，确保这些度量在供其他系统（如JMX）使用时都是最新的。

--CompositeContext

向多个上下文输出一组度量。

3）JAVA管理扩展（JMX）

Java Management Extensions，一个标准的JAVA API，可监控和管理应用。

4）监控方案

同时使用Ganglia和Nagios这样的警告系统来监控Hadoop系统。

3.维护

1）日常管理过程

--元数据备份

方法一，直接保存这些元数据文件的副本。

方法二，整合到namenode上正在使用的文件中。

--数据备份

distcp是一个理想的备份工具，其并行复制文件的功能可以将备份文件存储到其他HDFS集群或者其他Hadoop文件系统。

--fsck工具

--文件系统均衡器

2）委任和解除节点

委任新节点

--将新节点的网络地址添加到include文件（dfs.hosts/mapred.hosts属性指定）中

dfs.hosts和mapred.hosts分别指定允许连接到namenode的所有datanode和允许连接到jobtracker的tasktracker节点，与slaves文件不同，前者供守护进程使用，后者供控制脚本使用。

--运行以下指令，更新namenode的经过审核的一系列datanode集合

hadoop dfsadmin -refreshNodes

--以新节点更新slaves文件，这样的话，Hadoop控制脚本会将新节点包括在未来操作中

--启动新的datanode

--重启MapReduce集群

将mapred.jobtracker.restart.recover设置为true，使得重启后能恢复正在运行的作业

--检查新的datanode和tasktracker是否出现在Web UI中

解除旧节点

--将待解除节点的网址地址添加exclude文件（dfs.host.exclude/mapred.host.exclude属性指定）中，不更新include文件

--重启MapReduce集群，以终止在待解除节点上运行的tasktracker

--执行以下命令，使用一系列新的审核过的datanode来更新namenode设置

hadoop dfsadmin -refreshNodes

--转到Web UI，查看带解除datanode的管理状态是否已经变为“Decommission In Progress”，这些datanode的块将自己的数据复制到其他datanode中。

--当所有datanode的状态为“Decommissioned”时，表明所有块都已经复制完毕。关闭已经解除的节点。

--从include文件中移除这些节点，并运行以下命令

hadoop dfsadmin -refreshNodes

--从slaves文件移除节点 

关于exclude

tasktracker：仅当tasktracker出现在include文件中且不出现在exclude文件中时，才能连接到jobtracker。

datanode：

3）升级

--在升级任务执行之前，确保前一升级已经定妥

--关闭MapReduce，终止子tasktracker上运行的任何孤儿任务

--关闭HDFS，并备份namenode目录

--在集群和客户端安装新版本的Hadoop HDFS和MapReduce

--使用 -upgrade选项启动HDFS

--等待，直到升级完成

--检验HDFS是否运行正常

--启动MapReduce

--回滚或定妥升级人去(可选)

回滚：

$NEW_HADOOP_INSTALL/bin/stop-dfs.sh
$OLD_HADOOP_INSTALL/bin/start-dfs.sh -rollback

定妥：

$NEW_HADOOP_INSTALL/bin/hadoop dfsadmin -finalizeUpgrade