Hadoop HDFS深入解析

文件系统

早在 1965 年开发的 Multies ( UNIX 的前身）就详细地设计了文件系统，这使得文件系统成为多用户单节点操作系统的重要组成部分。最初的文件系统用于解决信．息的长期存储，并达到如下要求：

1.能够存储大量的信息。

2.使用信息的应用终止时，信息必须保存下来。

3.多个应用可以并发地存储信息。

解决这些问题的通常方法，是把信息以一种单元，即"文件" ( file)的形式存储在磁盘或者其他外部介质上，一个文件是一个命名的、存储在设备上的信．息的线性字节流。文件在需要的时候可以读取这些信息或者写入新的信息。存储在文件中的信息必须是永久的，也就是说，它不会因为应用的创建／终止受到影响。只有当用户显式地剧除它时，文件才会消失。对文件的管理，包括了文件的结构以及命名、存取、使用、保护和实现，称为文件系统。

从用户的观点来看，文件系统中最重要的方面是文件系统如何呈现在他们面前。即一个文件由什么组成、文件如何命名、如何保护文件，以及对文件可以进行哪些操作等。而对文件系统的设计者来说，他们还需要关注如何记录文件的相关信息。如何组织存储区等问题。

文件系统的用户界面

下面详细讨论文件系统的用户界面，也就是从用户的角度来研究文件，即文件是怎么使用的、有些 什么特征。

文件作为一种抽象机制，最重要的特征就是命名方法。各种系统的文件命名规则略有不同，但一般都支持由一定长度字符串作为文件名。应用创建文件的时候要指定文件名，文件在应用结束后仍然存在，其他应用可以使用该文件名对它进行操作。大部分的文件系统不关心文件里保存的数据，把文件内容作为无结构的字节序列保存。也有一些文件系统支持结构化文件，以记录为单位组织信息，免去文件系统使用者将“原始的”字节流转换成记录流的 麻烦。除了文件名和数锯，文件系统会嗽予文件其他的信息，比如文件的创建日期、文件长度、创建信息、引用计数等。我们把这些额外的项称为文件属性，有时也称为元数据。

1常用文件操作

大部分文件系统支持的与文件相关的常用系统调用如下：

1.创建文件：创建没有任何数据的文件，该调用的目的是声明文件存在，并且设置一些属性。

2.删除文件：当不再需要文件时，必须剧除它以释放存储空间。

3.打开文件：在使用文件之前要先打开文件，打开文件后，文件系统会在内存中保留和打开文件相关的一些 信息，有时还会创建对文件存取的相关机制。

4.关闭文件：当存取结束后，通过关闭文件，可以把在内存中保留的一些信息写回文件系统，井释放打开文件需要占用的资源。

5.读文件：从文件中读取数据，一般来说，该操作从当前位置的文件中将数据读取到一个缓冲区中。

6.写文件：往文件中写入数据。

7.追加数据：该方法是写文件的限制形式，它只能在文件未尾添加数据。

8.读记录：在结构化文件中读取记录。

9.写记录：在结构化文件中写入记录。

10.删除记录：在结构化文件中侧除记录。

11.移动当前位置：当需要指定从哪里读写数据的时候，使用该调用可以把当前位置移动到文件中的特定位置。

12.获取文件属性：读取文件的某个属性，如文件的最后修改时间。

13.设置文件属性：有些属性是用户可以修改的，在文件创建之后，能够修改它们，设置文件属性就是用于这个目的。

14.文件改名：用户改变现有文件的文件名。

1.HDFS 背景

在现代的无论企业还是生活环境中，单个计算机服务器容量往往无法存储大量数据，需许多服务器跨机器存储。统一管理分布在计算机服务器集群上的文件系统称为分布式文件系统。而一旦在系统中，引入网络，就不可避免地引入了所有网络编程的复杂性和挑战，例如挑战之一是如果保证在有些节点（计算机服务器）不可用的时候而整体数据不丢失。

传统的网络文件系统（NFS）虽然也称为分布式文件系统，但是其存在一些限制。由于NFS中，文件是存储在单机上，因此无法提供可靠性保证，当很多客户端同时访问NFS Server时，很容易造成服务器压力，造成性能瓶颈，服务器崩溃。另外如果要对NFS中的文件进行操作，需要首先同步到本地，这些修改在同步到服务端之前，其他客户端是不可见的。某种程度上，NFS不是一种典型的分布式系统，虽然它的文件的确放在远端（单一）的服务器上面。

从上图NFS的协议栈可以看到，它事实上是一种VFS（操作系统对文件的一种抽象）实现，而HDFS，是Hadoop Distributed File System的简称，是Hadoop抽象文件系统的一种实现。Hadoop抽象文件系统可以与本地系统、Amazon S3等集成，甚至可以通过Web协议（webhsfs）来操作。HDFS的文件分布在集群机器上，同时提供副本进行容错及可靠性保证。例如客户端写入读取文件的直接操作都是分布在集群各个机器上的，没有单点性能压力。

2. HDFS设计目的

HDFS设计之初就非常明确其应用场景，适用与什么类型的应用，不适用什么应用，有一个相对明确的指导原则。

2.1 设计目标
存储非常大的文件：这里非常大指的是几百M、G、或者TB级别。实际应用中已有很多集群存储的数据达到PB级别。根据Hadoop官网，Yahoo！的Hadoop集群约有10万颗CPU，运行在4万个机器节点上。更多世界上的Hadoop集群使用情况，参考Hadoop官网.

采用流式的数据访问方式: HDFS基于这样的一个假设：最有效的数据处理模式是一次写入、多次读取数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作
分析工作经常读取其中的大部分数据，即使不是全部。 因此读取整个数据集所需时间比读取第一条记录的延时更重要。

运行于商业硬件上: Hadoop不需要特别贵的、reliable的（可靠的）机器，可运行于普通商用机器（可以从多家供应商采购） ，商用机器不代表低端机器。在集群中（尤其是大的集群），节点失败率是比较高的HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。
2.2 HDFS不适合的应用类型
有些场景不适合使用HDFS来存储数据。下面列举几个：

1） 低延时的数据访问
对延时要求在毫秒级别的应用，不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问。

2）大量小文件
文件的元数据（如目录结构，文件block的节点列表，block-node mapping）保存在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。
经验而言，一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件块，则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。

3）多方读写，需要任意的文件修改
HDFS采用追加（append-only）的方式写入数据。不支持文件任意offset的修改。不支持多个写入器（writer）。

3. HDFS核心概念
   3.1 Blocks
   物理磁盘中有块的概念，磁盘的物理Block是磁盘操作最小的单元&#x