分布式文件系统

HDFS 是 Hadoop Distributed FIleSystem的简称（hadoop 分布式文件系统），那么我们先来说一下，什么叫做分布式文件系统

当数据集的大小超过一台独立的物理计算机的存储能力时，就有必要对它进行分区（partition），并存储到若干台单独的计算机上
管理网络中跨多台计算机存储的文件系统称为分布式文件系统（distributed filesystem）

数据块的概念：

每个磁盘都有默认的数据块大小，这是磁盘进行数据读写的最小单位。
Ok 那么构建在单个磁盘之上的文件系统（ext4/ext3）通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统块一般几千字节，而磁盘块一般为512字节
所以我们平时用的格式化（df 和 fdsik）其实就是用来维护文件系统的。

HDFS同样也有块的概念，但是大的多，默认为64M。与单一磁盘上的文件系统相似，HDFS上的文件（linux一切皆文件，你可以理解为一个1000G的Nginx日志文件）也被分为64M大小的多个分块（chunk），作为独立的存储单元。
但与其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间

数据块的好处：

1. 第一个最明显的好处就是：一个文件的大小可以大于网络中任意一个磁盘的容量。因为文件的所有块并不需要存储在同一个磁盘上
2. 第二个好处就是简化了存储子系统的设计，简化是所有系统的目标，尤其是对于这种分布式系统来说，（因为块大小是固定的，因此计算单个磁盘能存储多少块就相对容易了），同时也消除了对文件元数据的顾虑，块只是数据的一部分，文件的权限信息等（元数据），并不需要与块一起存储
3. 第三个好处就是块还是非常适用于数据备份，提高可用性和容错能力。hdfs默认每个块都会有另外两个副本，加一起是三个，其实说另外两个是副本是不严谨的，三个块是同等地位

文件元数据说明：
文件的元数据：块只是数据的一部分，文件的权限信息，并不需要与块一起存储
后面涉及到了再细说

数据块原理图

数据块原理图

Replicates使用三份会有一个小问题：
就是说你的磁盘空间只会使用三分之一
生产环境关于replicatios的配置：

    <property>
        <name>dfs.replication</name>
        <value>3</value>
    </property>

HDFS 设计思想

HDFS以流式数据访问模式来存储超大文件

• 超大数据：
  超大文件在这里是指具有几百兆、几百G、或者几百T大小的文件，或者PB
• 流式数据：
  HDFS的构建思路是这样的，一次写入多次读取是最高效的访问模式
  最好不要进行实时性写入操作，可以定期倒入数据，比如每天晚上
  数据集通常由数据源生产或者从数据源复制而来，接着长时间在此数据集上做各种分析。
  每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个整个数据集的时间延迟比读取第一条纪录的时间延迟更重要
• 商用硬件：
  Hadoop并不需要运行在昂贵且高可靠的硬件上。他是运行在普通硬件的集群上的（比如说普通台式机、塔式服务器、机架式服务器），因此对于庞大的集群来说，节点的故障率还是很高的，HDFS通过数据分片和副本机制来保证数据的可靠性
• 高时间延迟的数据访问：
  要求低时间延迟数据访问的应用，例如几十毫秒范围，不适合在HDFS上运行
  记住HDFS是为高数据吞吐量应用优化的，这可能会以提高时间延迟为代价
  目前对于低延迟的访问需求，Hbase是更好的选择

Namenode和datanode：

Hdfs有两类节点,以管理者(namenode)-工作者(datanode)模式运行，即一个namenode和多个datanode，namenode管理文件系统的命名空间，它维护着文件系统树及树内所有的文件和目录。这些信息以两个文件形式永久保留在本地硬盘上 ，分别是 命名空间镜像文件及编辑日志文件
Namenode也纪录着“数据块“所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时由数据节点重建

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

Namenode的容错机制：

没有namenode,文件系统将无法使用。事实上如果运行namenode服务的机器损坏，文件系统上的所有文件将会丢失，因为我们不知道如何根据datanode重建文件，因此对namenode容错特别重要，hadoop为此提供了两种容错机制

• 第一种机制是： 备份那些组成文件系统元数据持久状态的文件
  Hadoop可以通过配置使namenode在多个文件系统上保存元数据的持久状态
  这些写操作是实时的，是原子性的（参见mysql事务）
  一般的配置是将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统（NFS）

• 第二种机制是secondarynamenode
  运行一个辅助版namenode，但它不能被用作namenode。
  这个辅助版namenode的重要作用是定期通过编辑日志合并命名空间镜像，以防止编辑日志过大。
  这个辅助namenode一般在另一台单独的物理计算机上运行，因为它需要占用大量的cpu时间与namenode相同容量的内存来执行合并操作
  它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。但是辅助namenode保存的状态总是滞后于主节点，所以在主节点失效时，难免会丢失部分数据。这种情况下一般把存储在NFS上的namenode的元数据复制到辅助namenode上并作为新的主namenode运行

我们截取了一段搭建好的HDFS的数据目录：我们在搭建HDFS的时候会创建数据目录，而且会创建三个

分别是：dn/nn/snn(datanode/namenode/secondarynamenode)

nn的数据：

-rw-rw-r-- 1hadoop hadoop      42 Apr 17 14:11edits_0000000000000000001-0000000000000000002（编辑日志）

-rw-rw-r-- 1hadoop hadoop     605 Apr 17 15:11edits_0000000000000000003-0000000000000000011

-rw-rw-r-- 1hadoop hadoop      42 Apr 17 16:11edits_0000000000000000012-0000000000000000013

-rw-rw-r-- 1hadoop hadoop 1048576 Apr 17 16:36 edits_inprogress_0000000000000000014

-rw-rw-r-- 1hadoop hadoop     502 Apr 17 15:11fsimage_0000000000000000011  （空间镜像）

-rw-rw-r-- 1hadoop hadoop      62 Apr 17 15:11fsimage_0000000000000000011.md5

-rw-rw-r-- 1hadoop hadoop     502 Apr 17 16:11fsimage_0000000000000000013

-rw-rw-r-- 1hadoop hadoop      62 Apr 17 16:11fsimage_0000000000000000013.md5

-rw-rw-r-- 1hadoop hadoop       3 Apr 17 16:11seen_txid

-rw-rw-r-- 1hadoop hadoop     199 Apr 17 10:07VERSION

snn的数据：

-rw-rw-r-- 1hadoop hadoop  42 Apr 17 14:11edits_0000000000000000001-0000000000000000002

-rw-rw-r-- 1hadoop hadoop 605 Apr 17 15:11 edits_0000000000000000003-0000000000000000011

-rw-rw-r-- 1hadoop hadoop  42 Apr 17 16:11edits_0000000000000000012-0000000000000000013

-rw-rw-r-- 1hadoop hadoop 502 Apr 17 15:11 fsimage_0000000000000000011

-rw-rw-r-- 1hadoop hadoop  62 Apr 17 15:11fsimage_0000000000000000011.md5

-rw-rw-r-- 1hadoop hadoop 502 Apr 17 16:11 fsimage_0000000000000000013

-rw-rw-r-- 1 hadoophadoop  62 Apr 17 16:11fsimage_0000000000000000013.md5

你会发现数据基本一致

我们分析下第一种和第二种的劣势

需要手动操作，恢复不及时，极大可能造成数据丢失，所以现在生产环境主要使用一个QJM的方式

Namenode的容错机制之QJM机制：

HDFS集群中只有一个Namenode，这就会引入单点问题；即如果Namenode故障，那么这个集群将不可用，直到Namenode重启或者其他Namenode接入。

有两种方式会影响集群的整体可用性：

1、意外的突发事件，比如物理机器crash，集群将不可用，直到管理员重启Namenode。

2、系统维护，比如软件升级等，需要关闭Namenode，也会导致集群暂时性的失效。

HDFS HA特性即解决这个问题，它通过在集群中同时运行2个(redundant)Namenodes，并让active和passive之间热备(hotstandby)。当Active Namenode故障失效后，即可快速故障转移到新的Namenode上(passive Namenode)；也可以在计划维护期间，基于管理员发起(administrator-inited)的友好的failover。

为了满足共享日志的高可用性，社区引入QJM。QJM由cloudera开发，实现了读写高可用性，使HDFS达到真正的高可用性成为可能。

HDFS的设计思想2：

• 大量的小文件
  由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode内存容量。
  根据经验，每个文件、目录的存储信息大约占150字节
  所以要规划你namenode的内存与文件数量的关系

• 多用户写入，任意修改文件：
  HDFS中的文件可能只有一个writer，而且写操作总是将数据添加在文件的末尾。它不支持多个写入者的操作，也不支持在文件的任意位置进行修改

• 联邦HDFS
  namenode在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈。在2.x发行版系列中，引入的联邦HDFS允许系统通过添加namenode实现扩展，其中每个namenode管理文件系统命名空间的一部分
  例如一个namenode可能管理/usr 目录下的所有文件，而另一个namenode可能管理/share目录下的所有文件
  我司生产环境没有应用，暂时不做过多介绍