Hadoop集群之HDFS

HDFS简介

HDFS全称Hadoop Distributed File System，是一个分布式文件系统，基于Google三大论文之一的Google File System开发。主要为了解决在多个普通的节点（廉价的机器，只要有存储空间，cpu和内存要求不高）上存储并访问日益增长的业务数据，并且在理论上可以实现横向无限扩展。

架构介绍

HDFS采用的是主从架构(Master/Slave)，其中namenode是主节点，datanode是从节点，如下图所示：

HDFS架构

Namenode
1.接收客户端的读写请求
2.存储文件的元数据，主要包括文件的文件名，Block信息，副本数，文件的位置信息等
3.接收Datanode的心跳上报
所以，如果Namenode很重要，如果down掉将不能接受Client请求，整个HDFS将不可用。
Datanode
1.客户端实际的读写IO
2.接受Namenode指令，进行Datanode之间的block副本的拷贝
3.上报给Datanode自身的信息（健康状况、文件读写情况等）
Block
一个大文件被切分成多个Block块，Hadoop 2.0后块的默认大小是128M，一个Block有多个副本，它们被存储在不同的节点上，具体存储策略可查阅相关资料。

常用命令

HDFS是一个文件系统，它遵循了与Linux类似的POSIX标准，所以有类似于linux的shell命令行操作接口(命令)。主要提供了User Commands、Admin Commands以及Debug Commands:

HDFS命令

常用的用户命令有dfs、fsck，下面举个例子：
1.查看根目录下的文件列表
hdfs dfs -ls /
2.查看根目录下所有文件的大小
hdfs dfs -du /
等，fsck主要用来查看文件的block信息，以及修复损坏的block等。
常用的管理命令有balancer，用来平衡各个Datanode节点之间的存储负载。
具体各个命令的用法可以查询官方文档HDFS命令，自己去探索。

内存受限问题

为了快速响应文件读写请求，HDFS把所有的元数据都存储在Namenode内存中，随着业务数据增多或小文件很多，都会导致Namenode 占用内存不断增加，如果占用内存接近极限，会导致HDFS不可用，这样就导致了内存受限问题。在实际生产环境中，可以用官方的Federation解决方案，按业务分成多个HDFS集群;也可以提前评估数据基数及其增长速度，保证Namenode有足够的可用内存；同时要做好定时小文件的合并。

单点故障问题

我们上面已经讲到Namenode在集群中的地位至关重要，如果它down掉了将影响整个集群的访问，存在单点故障问题，主要表现在以下几方面:

如果Namenode挂掉了，无法接收Client的读写请求，直接影响业务
Namenode节点挂掉后，如果元数据信息丢失（比如硬盘损坏），整个集群数据将无法恢复，造成灾难性后果

针对以上两点，首先要有一个备份的Namenode，在当前Namenode挂掉后可以马上接管读写请求，不影响业务；另外，要把元数据的信息(edits文件) 存储在公共的区域而不是存储在Namenode节点本地，防止Namenode节点机器故障后元数据信息丢失导致数据无法恢复。常用的高可用解决方案为QJM:

HDFS HA
包含多个Namenode节点，其中只有一个active，接收Client读写请求；其他是standby，除了不能接收Client读写请求，它同样存储元数据信息，接受Datanode上报Block信息，以便在变为active状态是可以快速接受Client请求。
Namenode Active、Standy的状态选择和切换由Zookeeper完成。每个Namenode都伴随着一个zkfc服务，用来监控Namenode可用性，如果其检测到对应的Namenode不可用，则上报给zk，zk从其他Standby的Namenode节点中选择一个为Active，通知zkfc把该Namenode变为Active，这样就实现了瞬间接管。
还有一个问题，那就是元数据的存储问题。为了避免元数据存储在本地时（edits文件）机器故障导致数据无法恢复，在该HA方案中，元数据被存储在Journalnode节点中，为了防止单点故障，一般会有多个Journalnode节点形成一个集群（存储edits文件的多个备份），Namenode不断向Journalnode集群同步元数据，在恢复HDFS集群时，会从Journalnode中加载元数据

关键指标

上面已经详细介绍了HDFS的架构及高可用原理，现在总结一下HDFS运维过程中应该主要关注的一些指标：
1.Namenode Memory，如果该指标已经占比比较高（90%以上），则需要考虑扩展内存，合并文件，清除无用文件
2.Namenode GC Time，如果GC Time比较长，且Namenode RPC queue wait time比较长，则考虑Journalnode 元数据同步可能有问题，需要重启Journalnode
3.Corrupted Blocks，如果损坏Block较多，需要手动修复
4.Under Replicated Blocks，如果副本数缺失很多，需要手动补充副本。

完。