hadoop2.5.2学习及实践札记（三）—— HDFS概念及体系结构
注：文中涉及的文件路径或配置文件中属性名称是针对hadoop2.X系列，相对于之前版本，可能有改动。
附：
HDFS用户指南官方介绍：
http://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
HDFS体系结构官方介绍：
http://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
HDFS
Hadoop Distributed Filesystem（hadoop分布式文件系统）
假设及设计目标
- 硬件故障很常见：HDFS集群可能包含成百上千台机器，每台机器都非常有可能发生故障。检测故障并快速、自动的恢复是HDFS体系的一个核心目标。
- 流式的访问数据：HDFS是为批处理而设计，不是为了交互式用户使用。
- 存储超大文件
- 一次写入，多次读取是最高效的访问模式
- 移动计算比移动数据更便宜：移动计算到接近于数据存储的地方，比移动数据到应用运行的地方更好。
- 可移植性
- 运行于商用硬件
不擅长的领域
- 低时间延迟的数据访问
- 存储大量的小文件
- 多用户写入，任意修改文件
数据块
存储于HDFS中的文件被分割为1个或多个块。
hadoop中文件块默认为64M（hdfs-default.xml中dfs.blocksize属性定义），小于一个块大小的文件不会占用整个块的空间。
HDFS中块如此之大，其目的是为了最小化寻址开销：如果块设置的足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需时间。
但也不宜设置过大，map任务通常一次只处理一个块的数据，如果任务数太少，作业运行速度就比较慢。
块非常适合用于数据备份进而提供数据容错能力和提高可用性。HDFS默认为块保存3个副本（hdfs-default.xml中dfs.replication属性定义）。
HDFS体系结构
HDFS中运行着2类节点namenode、datanode。一个namenode、多个datanode，namenode和datanode以主从（master-slave）模式运行与HDFS集群中。
namenode为管理节点，执行对文件系统命名空间的操作，如：打开、关闭和重命名文件或目录；并且决定文件块与datanode之间的映射关系。
datanode为工作节点，存储并检索数据块，并定期向namenode发送它们存储的块的列表，接收来自namenode的文件块创建、删除和复本改进等命令。
namenode
namenode管理文件系统的命名空间，维护着文件系统树及整棵树内所有的文件和目录的元数据，这些信息以两个文件形式保存在本地磁盘上：命名空间镜像和编辑日志。
对于文件来说，其元数据信息可能包含复本级别、修改时间和访问时间、访问许可、块大小、组成一个文件的块等；
对于目录来说，可能包含信息有修改时间、访问许可和配额元数据等。
namenode运行时，文件系统的元数据是维护在内存中的（这是为什么运行namenode的机器需要较大的内存，也是为什么HDFS不适合存储大量小文件的原因：创建大量的小文件会急速的消耗掉namenode的内存）。
而命名空间镜像是文件系统元数据的一个永久性检查点，将元数据序列化保存于本地磁盘。并不是每次操作都会更新该文件，因为fsimage是一个大型文件，频繁操作会使系统极为缓慢。
对文件系统和其属性的修改会先记录在编辑日志中。
进入namenode数据本地保存目录 {dfs.namenode.name.dir}，{dfs.namenode.name.dir}/current 下，可以查看到如下类型的文件：edits文件为编辑日志，fsimage文件为命名空间镜像。
HDFS Federation
因为namenode在内存中保存元数据，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈。
Hadoop2.x系列中引入了联邦HDFS，允许系统通过添加namenode实现扩展，每个namenode管理文件系统命名空间中的一部分。
块池（block pool）:属于某一命名空间(NS)的一组文件块。
联邦环境下，每个namenode维护一个命名空间卷（namespace volume），包括命名空间的元数据和在该空间下的文件的所有数据块的块池。
namenode之间是相互独立的，两两之间并不互相通信，一个失效也不会影响其他namenode。
datanode向集群中所有namenode注册，为集群中的所有块池存储数据。
datanode
datanode使用本地文件系统保存集群中的文件块信息，进入datanode数据本地保存目录{dfs.datanode.data.dir}
{dfs.datanode.data.dir}/current/BP-xxx表示某一命名空间的块池，因未配置联邦HDFS，只有一个namenode，所以只有一个块池目录。
{dfs.datanode.data.dir}/current/BP-xxx/current/finalized是存储数据的目录，包含两类文件：包含文件原始数据的HDFS块和块的元数据（.meta后缀的文件）。当目录中数据块的数量增加到一定规模时，datanode会创建一个新的子目录来存放新的数据块及其元数据信息，目的是设计一颗高扇出的目录树，即使文件系统中块的数量非常多，目录树的层数也不多，同时避免很多文件都放在同一个目录之中。
HDSF启动及安全模式
从启动脚本/sbin/start-dfs.sh中可以看出，HDFS启动时，先启动namenode，后启动datanode，再启动secondarynamenode（介绍在下面）。
namenode启动时首先将fsimage载入内存，并执行编辑日志中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。
系统中数据块的位置不是由namenode维护的，而是以块列表的形式存储在datanode中。系统启动时由datanode向namenode发送最新的块列表信息，从而在namenode内存中构建一份块位置的映射信息。也就是说，namenode启动后的一段时间里，namenode可能还不了解或了解很少的数据块和datanode之间的映射信息，但这并不意味着系统中的文件块复本数不足（不足时会进行文件块的复制）。
所以namenode启动时首先运行于安全模式，即对于客户端是只读的。安全模式下namenode不会向datanode发出任何块复制或删除指令，这时是没有必要的，namenode只需等待更多的datanode发送块列表信息即可，当接收到足够多的块位置信息，满足“最小复本条件”后，namenode会在30秒后退出安全模式。
最小复本条件是指：整个文件系统中有99.9%（由dfs.namenode.safemode.threshold-pct指定）的块满足最小复本级别（默认值是1，由dfs.namenode.replication.min指定）。
另外也可以手动进入或离开安全模式，命令：
[hadoop@localhost sbin]$ hdfs dfsadmin -safemode Usage: java DFSAdmin [-safemode enter | leave | get | wait]
secondarynamenode
在业务繁忙的集群中，编辑日志可能会随时间推移变得很大，这会造成下次namenode启动时用时过长。
SecondaryNameNode定期地合并fsimage和Edits日志文件，并保持Edits日志文件的大小在一个上限值内，由于它的内存需求与NameNode的一致，所以它通常运行在NameNode以外的一台机器上。Secondary NameNode以NameNode目录结构的相同方式存储合并后的命名空间镜像的副本，以备在namenode发生故障时使用。
但secondarynamenode已过时，可以考虑使用Checkpoint Node或Backup Node替代之。
Checkpoint Node
Checkpoint Node周期性的创建namespace的检查点，它从活动的namenode下载fsimage和edit日志，在本地合并，并把合并后新的fsimage上传到活动的namenode。
Checkpoint Node以与NameNode相同的目录结构存储最新的Checkpoint。新的检查点时刻准备好在namenode需要时对其进行读取。
Backup Node
Backup Node 不但提供了同checkpoint node一样的checkpoint功能，而且还通过同步活动namenode的状态，在内存中维护了一份文件系统命名空间的最新拷贝。 Backup node从namenode接收文件系统Edits流并持久化到磁盘，同时还应用那些Edits到自己内存中的Namespace复本，如此就建立了Namespace的备份。
Backup node不需要像checkpoint node或secondary namenode一样，为了创建检查点，需要从活动的namenode上下载fsimage和edits文件，因为在它的内存中已经有了命名空间的最新状态。Backup Node的Checkpoint处理效率很高，因为它只需要保存Namespace到本地fsimage并重设Edits文件。