随着数据量越来越大， 在 一个操作系统管辖的范围存不下了， 那么就 分配到更多的操作系统管理的磁盘中， 但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。

HDFS的基本结构：

NameNode ：管理文件目录结构，接受用户的操作请求,是管理数据节点的。名字节点维护两套数据， 一套是文件目录与数据块之间的关系 ， 另一套是数据块与节点之间的关系 。前一套数据是静态的，是存放在磁盘上的， 通过fsimage和edits文件来维护；后一套数据是动态的，不持久放到到磁盘的，每当集群启动的时候，会自动建立这些信息，所以一般都放在内存中。

DataNode：是HDFS中真正存储数据的节点。

HDFS客户端可以通过java API的方式对HDFS进行读写操作，FileSystem fs = FileSystem.get(new URI(“hdfs://ns1”), new Configuration(),“root”);客户端通过调用FileSystem对象fs的Open()方法打开要读取的文件，DistributedFileSystem通过使用RPC来调用NameNode，以确定文件起始块的位置。

对于文件的每一个块，NameNode返回存有该块副本的DataNode地址。这些DataNode根据它们与客户端的距离来排序（根据集群中的网络拓扑）。如果该客户端本身就是一个DataNode（例如在一个MapReduce任务中）并保存有相应数据块的一个副本时，该节点就会从本地DataNode读取数据。然后DistributedFileSystem返回一个FSDataInputStream对象（支持文件定位的输入流）给客户端读取数据。FSDataInputStream类转而封装DFSInputStream对象，该对象管理着DataNode和NameNode的I/O。

HDFS fsck

HDFS支持fsck命令检查各种不一致，它主要是用来检查和维护不一致的文件系统。若系统掉电或磁盘发生问题，可利用fsck命令对文件系统进行检查。它的设计目的是报告各种文件的问题，例如，文件丢失的块或未复制的块。与传统的本地文件系统的fsck实用程序不同，该命令不纠正它检测到的错误。通常，NameNode会自动纠正大多数可恢复的故障。默认情况下，fsck忽略打开的文件，但提供了在报告期间选择所有文件的选项。HDFS fsck命令不是Hadoop shell命令。它可以运行为bin/hdfs fsck。fsck可以在整个文件系统上运行，也可以在文件的子集上运行。

执行fsck命令行的客户端必选在hadoop-site.xml中配置dfs.http.address项，即namenode的http地址。否则会抛出java.net.ConnectException: Connection refused异常。
Fsck本质上是namenode的一个servlet，而fsck命令对应的类DFSck其实是封装了一个http连接，请求NamenodeFsck对象并执行起fsck()函数，fack()函数递归地从指定path遍历所有的目录和文件，并根据选项确定要打印的内容。如果指定了-move选项，则损坏的文件会被移动到/lost+found目录，如果在根目录下已经存在一个名为lost+found的文件，则move操作会失败并打印warning信息。

Fsck过程的调用指的是从终端机器输入到最终fsck在HDFS内部被执行的整个过程。

规划后的中间流程：

1.输入fsck 直接调用到的就是此类。DFSck内部会发送http请求的方式，根据参数构造URL请求地址，发送到下一个处理对象中。

2.下一个处理对象就是FsckServlet.FsckServlet在这里相当于一个过渡者，马上调用真正操作类NamenodeFsck.。

3.NamenodeFsck在这里会取出请求参数,然后在HDFS内部做真正的fsck检测操作。
DFSck请求构造：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

public int run(final String[] args) throws IOException {

        if (args.length == 0) {

            printUsage(System.err);

            return -1;

        }

        try {

            return UserGroupInformation.getCurrentUser()

                    .doAs(new PrivilegedExceptionAction<Integer>() {

                        @Override

                        public Integer run() throws Exception {

                            return doWork(args);

                        }

                    });

        } catch (InterruptedException e) {

            throw new IOException(e);

        }

    }

//        URL构造完毕后，并发送请求

    URL path = new URL(url.toString());

    URLConnection connection;

        try

    {

        connection = connectionFactory.openConnection(path, isSpnegoEnabled);

    }catch(
    AuthenticationException e)

    {

        throw new IOException(e);

    }

//        获取响应回复,直接输出到终端上

    InputStream stream = connection.getInputStream();

    BufferedReader input = new BufferedReader(new InputStreamReader(stream, "UTF-8"));

    String line = null;

    String lastLine = null;

    int errCode = -1;

        try

    {

        while ((line = input.readLine()) != null) {

            out.println(line);

            lastLine = line;

        }

    }finally

    {

        input.close();

    }

fsck命令执行的基本流程架构如下图所示：

注：对于大的集群来说，对根目录执行fsck操作是很耗时间的而且对namenode压力很大，因此要谨慎使用。

（一）HDFS权限管理模型

1.概述

Hadoop分布式文件系统实现了一个和POSIX系统类似的文件和目录的权限模型。每个文件和目录有一个所有者（owner）和一个组（group）。文件或目录对其所有者、同组的其他用户以及所有其他用户分别有着不同的权限。对文件而言，当读取这个文件时需要有r权限，当写入或者追加到文件时需要有w权限。对目录而言，当列出目录内容时需要具有r权限，当新建或删除子文件或子目录时需要有w权限，当访问目录的子节点时需要有x权限。不同于POSIX模型，HDFS权限模型中的文件没有sticky，setuid或setgid位，因为这里没有可执行文件的概念。为了简单起见，这里也没有目录的sticky，setuid或setgid位。总的来说，文件或目录的权限就是它的模式（mode）。HDFS采用了Unix表示和显示模式的习惯，包括使用八进制数来表示权限。当新建一个文件或目录，它的所有者即客户进程的用户，它的所属组是父目录的组（BSD的规定）。

每个访问HDFS的用户进程的标识分为两个部分，分别是用户名和组名列表。每次用户进程访问一个文件或目录foo，HDFS都要对其进行权限检查。

5.如果用户即foo的所有者，则检查所有者的访问权限；

6.如果foo关联的组在组名列表中出现，则检查组用户的访问权限；

7.否则检查foo其他用户的访问权限。

如果权限检查失败，则用户的操作会失败。

2.用户

在Hadoop中支持两种方式验证用户的身份，具体由hadoo.security.authentication参数决定，具体配置参数配置如下：

无论操作的方式如何，用户身份机制都是由HDFS本身所构成的。在HDFS中没有提供用于创建用户标识、建立组或处理用户凭证的规定。

3.组映射

当用户名确定时，组的列表由hadoop.security.group属性和group mapping服务来管理。用户组关系映射的管理实现有以下几种情况：

8.当节点的JNI服务可用时，它的默认实现是org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback，它通过hadoop的默认API来实现用户组关系的映射。

9.当JNI不可用时，默认实现为org.apache.hadoop.security.ShellBasedUnixGroupsMapping，Shell实现用bash –c命令来解析用户组映射表。

10.使用LDAP服务器来管理用户组关系映射，通过org.apache.hadoop.security.LdapGroupsMapping提供具体实现，但是，如果需要的组只驻留在LDAP中，并且没有在Unix服务器上实现，那么这个提供者只应该被使用。关于配置组映射服务的更多信息可以在Javadocs中找到。

对于HDFS，在NameNode上执行用户到组的映射。因此，NameNode的主机系统配置决定了用户的组映射。注意，HDFS将文件或目录的用户和组存储为字符串;在Unix中，用户和组的标识号没有转换。

每个文件或目录操作将完整的路径名传递给名称节点，并在每个操作的路径上应用权限检查。客户端框架将隐式地将用户标识与名称节点的连接关联起来，从而减少对现有客户端API的更改的需求。一直以来，当一个文件的操作成功时，操作可能会失败，因为文件或路径上的某个目录不再存在。例如，当客户端开始读取一个文件时，它会向name节点发出第一个请求，以发现文件的第一个块的位置。另一个请求可能会失败。另一方面，删除一个文件并不会撤销已经知道文件块的客户机的访问权限。随着权限的增加，客户端对文件的访问可能会在请求之间撤销。再次，更改权限不会撤销已经知道文件块的客户机的访问权限。

public FSDataOutputStream create(Path f, FsPermission permission, boolean overwrite, int bufferSize, short replication, long blockSize, Progressable progress)

public boolean mkdirs(Path f, FsPermission permission)

public void setPermission(Path p, FsPermission permission)

public void setOwner(Path p, String username, String groupname)

public FileStatus getFileStatus(Path f)

新文件或目录的模式限制了我的umask设置作为配置参数。当现有的创建(目录,…)方法使用(不允许参数),新文件的模式是0666 & ^ umask。当使用新的create(path, permission，…)方法(使用权限参数P)时，新文件的模式是P & umask & 0666。当使用现有的mkdirs(path)方法创建新目录时(没有权限参数)，新目录的模式是0777 & umask。当使用新的mkdirs(path, permission)方法(使用权限参数P)时，新目录的模式是P & umask & 0777。

（一）快照Snapshots

1.快照技术

在计算机系统中，快照是系统在特定时间点的状态。这个词是在摄影中被创造出来的。它可以引用系统状态的实际副本，也可以指某些系统提供的功能。

一个大型数据集的完整备份可能需要很长时间才能完成。在多任务或多用户系统中，当数据被备份时，可能会写入数据。这将防止备份成为原子，并引入可能导致数据损坏的版本倾斜。例如，如果用户将文件移动到已经备份的目录中，那么该文件将完全丢失在备份媒体上，因为在添加文件之前已经进行了备份操作。版本倾斜也可能导致文件的损坏，这些文件在读取时改变其大小或内容。

安全备份实时数据的一种方法是，在备份期间暂时禁用对数据的写入访问，或者通过停止访问应用程序，或者使用操作系统提供的锁定API来强制执行独占读取访问。这对于低可用性系统(在桌面计算机和小型工作组服务器上是可以接受的)是可以容忍的。然而，高可用性24/7系统无法承载服务中断。

为了避免停机，高可用性系统可能会在快照上执行备份——在时间点上冻结的数据集的只读副本，并允许应用程序继续写入数据。大多数快照实现都是高效的，并且可以在O(1)中创建快照。换句话说，创建快照所需的时间和I/O不会随着数据集的大小而增加;相比之下,直接备份所需的时间和I / O数据集的大小成正比。在一些系统一旦最初的快照的一个数据集,后续快照复制更改的数据,并使用一个指针引用系统初始快照。与重复克隆数据集相比，这种基于指针的快照方法消耗的磁盘容量更少。

快照的技术类型：

8.基于文件系统的快照

9.基于LVM(逻辑卷管理器)的快照

10.基于NAS的快照

11.基于磁盘阵列的快照

12.基于存储虚拟化设备的快照

13.基于主机虚拟化软件的快照

14.基于数据库的快照

（二）HDFS快照

1.概述

快照snapshots是HDFS文件系统的只读的基于某时间点的拷贝，可以针对某个目录，或者整个文件系统做快照。

快照比较常见的应用场景是：

15.数据备份

16.防止用户误操作

17.进行试验或测试

18.灾难恢复

快照存在两种类型：Read-only (RO) snapshots只读快照，Read-write (RW) snapshots可读写快照

快照的高效性实现：

(1) 快照可以即时创建，耗时仅为O(1)，减少了inode查找时间。

(2) 只有当涉及到快照目录的修改被执行时，才会产生额外的内存消耗。而且内存消耗为O(M)，其中M是被修改的文件或目录数。

(3) 创建快照时，block块并不会被拷贝。快照文件中只记录了block列表和文件大小，不会做任何数据拷贝。

(4) 快照不会对正常的HDFS操作有任何影响：创建快照以后发生的修改操作，被按操作时间的倒序（from newer to older）记录下来。所以当前的数据能被直接获取，而快照点的数据，则通过在当前的数据基础上减去执行过的操作来获取。

注：更新快照的时间间隔越长，快照所需的开销越大，耗时越久。

2.HDFS中快照的两种方式

19.NameNode与DataNode都做快照，快照保存在DataNode中，DataNode负责管理

20.仅NameNode做快照，由NameNode管理

3.快照目录

我们可以在任何被设置为snapshottable的目录上执行快照，对一个目录最多可以创建65536个快照。管理员可以把任何目录设置为snapshottable，没有限制。如果一个目录下已经存在快照，那么只有当先删除所有快照后才能对这个目录进行删除和重命名等操作。
不允许嵌套的snapshottable目录。也就是说，如果一个目录被设置为snapshottable，那么它的父目录和子目录都不允许被设置为snapshottable。

4.快照路径

快照被存放在一个被命名为.snapshot的目录中。比如/foo是一个snapshottable目录，/foo中有一个目录为/foo/bar，对/foo创建一个快照s0。那么/foo/.snapshot/s0/bar就是/foo/bar目录对应的快照。可以通过”.snapshot”路径直接访问和操作快照数据。