Hadoop基础教程-第3章 HDFS：分布式文件系统（3.1 HDFS概述）

第3章 HDFS：分布式文件系统

3.1 HDFS概述

在大数据时代，需要处理分析的数据集的大小已经远远超过了单台计算机的存储能力，需要将数据集进行分区（partition）并存储到若干台独立自治计算机中。但是分区存储的数据不方便管理和维护，迫切需要一种文件系统来管理多台机器上的文件，这就是分布式文件系统（distribute filesystem）。
分布式文件系统是一种允许文件通过网络在多台主机上分享的 文件的系统，可让多机器上的多用户分享文件和存储空间。
分布式文件系统很多，比如HDFS。HDFS（Hadoop Distribute File System）是Hadoop的一个分布式文件系统，Hadoop应用程序使用的主要分布式存储。 HDFS集群主要由一个NameNode来管理文件系统元数据和存储实际数据的DataNodes。

3.1.1 HDFS设计理念

一句话，HDFS设计理念是可以运行在普通机器上，以流式数据方式存储文件，一次写入、多次查询。

• 可构建在廉价机器上
  HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。通过多副本提高可靠性，提供了容错和恢复 机制。
• 高容错性
  由于HDFS可以建立在普通计算机上，节点故障是正常事情。HDFS将数据自动保存多个副本，副本丢失后，自动恢复，实现数据高容错性。
• 适合批处理
  也称为流式数据访问。HDFS适合一次写入、多次查询（读取）的情况。在数据集生成后，长时间在此数据集上进行各种分析。每次分析都将设计该数据集的大部分数据甚至全部数据，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。
• 适合存储大文件
  这里说的大文件包含两种意思：一是值文件大小超过100M以及达到GB甚至TB、PB的文件。二是百万规模以上的文件数量。

3.1.2 HDFS 的局限

没有完美的系统，HDFS也存在一些短板。

• 实时性差
  要求低时间延迟的访问的应用，不适合在HDFS上运行。记住，HDFS是为高数据吞吐量应用优化的，这可能会以高时间延迟为代价。目前，对于低延迟的访问需求，hbase是更好的选择。
• 小文件问题
  由于nameNode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总量受限于nameNode的内存总容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节。过多的小文件存储会大量消耗nameNode的存储量。
• 文件修改问题
  HDFS中的文件只有一个Writer，而且写操作总是将数据添加在文件的末尾（实际上，许多HDFS应用也不允许文件的追加操作）。他不支持具有多个写入者的操作，也不支持在文件的任意位置进行修改。

3.1.3 HDFS架构

http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
如图1所示，HDFS是一个主从结构，一个HDFS集群是由一个管理节点NameNode，它是一个管理文件命名空间和调节客户端访问文件的主服务器，还有一些数据节点DataNode，通常是一个节点一个机器，它来管理对应节点的存储。

图1 HDFS架构

• NameNode
  NameNode负责管理文件目录、文件和block的对应关系以及block和datanode的对应关系。NameNode节点也成为元数据节点，用来管理文件系统的命名空间，维护目录树，接管用户的请求。
  （1） 将文件的元数据保存在一个文件目录树中
  （2） 在磁盘上保存为：fsimage 和 edits
  （3） 保存datanode的数据信息的文件，在系统启动的时候读入内存。

• DataNode
  Datanode是文件系统的工作节点。他们根据需要存储并检索数据块（受客户端或namenode调度），并且定期向nameNode发送他们所存储的块的列表。

• Client(客户端)
  客户端代表用户通过与nameNode和datanode交互来访问整个文件系统。客户端提供了一个类似于POSIX（可移植操作系统界面）的文件系统接口，因此用户在编程时无需知道nameNode和datanode也可以实现其功能。
  HDFS对外开放文件命名空间并允许用户数据以文件形式存储。用户通过客户端（Client）与HDFS进行通讯交互。

• SecondnameNode
  文件系统客户端在执行写操作时，这些操作首先被记录到编辑日志中，然后更新nameNode内存中维护的文件系统的元数据；命名空间镜像文件（fsimage）是文件系统元数据的一个永久检查点，因为fsimage文件是一个大型文件，如果频繁的执行写操作，会使系统运行极为缓慢。但是如果不进行操作，editlog文件会无限增长，一旦nameNode需要恢复，则需要花费非常长的时间，所以HDFS引入了辅助nameNode，如图2所示，为主nameNode内存中的文件系统元数据创建检查点。如图3所示，实现将主nameNode的编辑日志和命名空间镜像文件合并。形成一个更小的editlog文件和最新的fsimage文件。

图2 HDFS架构

客户端执行写操作的时候，首先更新编辑日志（edits），然后修改内存中的文件系统映射。随着时间的推移，编辑日志会非常大。这个时候，就需要将编辑日志和文件系统映射持久检查点（fsimage）进行合并，以减少编辑日志的大小。这个工作就是由辅助namenode完成的。

图3 辅助namenode工作原理

①辅助namenode请求主namenode停止使用edits文件，暂时将新的写操作记录到一个新的文件中；

②辅助namenode从主namenode获取fsimage和edits文件（通过http get）

③辅助namenode将fsimage文件载入内存，逐一执行edits文件中的操作，创建新的fsimage文件。

④辅助namenode将新的fsimage文件发送回主namenode（使用http post）.

⑤主namenode用从辅助namenode接收的fsimage文件替换旧的fsimage文件；用步骤1所产生的edits文件替换旧的edits文件。同时，还更新fstime文件来记录检查点执行时间。

最终，主namenode拥有最新的fsimage文件和一个更小的edits文件。当namenode处在安全模式时，管理员也可调用hadoop dfsadmin –saveNameSpace命令来创建检查点。

从上面的过程中我们清晰的看到辅助namenode和主namenode拥有相近内存需求的原因（因为辅助namenode也把fsimage文件载入内存）。因此，在大型集群中，辅助namenode需要运行在一台专用机器上。

创建检查点的触发条件受两个配置参数控制。通常情况下，辅助namenode每隔一小时（有fs.checkpoint.period属性设置）创建检查点；此外，当编辑日志的大小达到64MB（有fs.checkpoint.size属性设置）时，也会创建检查点。系统每隔五分钟检查一次编辑日志的大小。

3.1.4 块

HDFS内部机制是将一个文件分割成一个或多个块，这些块被存储在一组数据节点中。NameNode节点用来操作文件命名空间的文件或目录操作，如打开，关闭，重命名等等。它同时确定块与数据节点DataNode的映射。数据节点DataNode负责来自文件系统客户的读写请求。数据节点DataNode同时还要执行块的创建，删除，和来自NameNode的块复制指令。

dfs.blocksize是一个文件块的大小了，默认128M。
每一个block会在多个datanode上存储多份副本，默认是3份。
太大的话会有较少map同时计算，太小的话也浪费可用map个数资源，而且文件太小namenode就浪费内存多。根据需要进行设置。