HDFS分布式文件系统

尚硅谷教案：尚硅谷大数据技术之Hadoop（HDFS）V3.3.docx

简介

随着数据量越来越大，在一个操作系统存不下所有的数据，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。

例如，我有一个超级大的文件需要进行存储，任何一个服务器仅凭自身无法解决这个问题，只能对该文件进行拆分保存。最开始的办法是将该文件拆分后，通过分别记录哪台服务器存储了哪一块数据，然后最后再根据这个记录进行查找。但是很显然，这种方式不方便。所以，HDFS诞生了

HDFS (Hadoop Distributed File System)，它是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。

我们的电脑磁盘，也是个文件系统

HDFS的使用场景:适合一次写入，多次读出的场景。一个文件经过创建、写入和关闭之后就不需要改变。

警告

不要修改存储在HDFS中的文件本身自带的内容，最多可以在文件原内容的底部追加新内容

优缺点

优点

1. 高容错性：
   • 数据自动保存多个副本。它通过增加副本的形式，提高容错性。
   • 某一个副本丢失后，它可以自动恢复。（例如某台存有副本的机器挂掉了，它会自动在一台没有副本的集群内机器上创建副本）
2. 适合处理大数据
   • 数据规模：能够处理数据规模达到GB、TB、甚至是PB级别的数据
   • 文件规模：能够处理百万规模以上的文件数量，数量相当之大。
3. 可以构建在廉价机器上，通过多副本机制，提高可靠性

缺点

1. 不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。HDFS的优势在于数据量大的时候，相较于其他文件系统要更快速的查询（比如MySQL的快速的增删改查）
2. 无法高效的对大量小文件进行存储
   • 存储大量小文件的话，它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的，因为NameNode的内存总是有限的
     NameNode在生产环境下是128GB的空间，用来存储文件，一个文件块（无论是128MB的块，还是1KB的块）会占用150字节，也就是说存储文件的话，能存储9亿个
   • 小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标
3. 不支持并发写入、文件随机修改
   • 同一个文件只能由一个线程写，不允许多个线程同时写
   • 仅支持数据的append（追加），不支持文件的随机修改

HDFS组成架构

找到对应自己Hadoop版本的文档：https://hadoop.apache.org/docs/

左侧树状结构找到并点击 HDFS -> Architecture，往下翻，有如下图片

如下内容，参照上图

1. NameNode(nn)：就是Master，它是一个主管、管理者

   1. 管理HDFS的名称空间
      上图中的 MetaData(元数据) 就是由 NameNode 来管理的
   2. 配置副本策略
      例如有三个文件分别为A、B、C，需要维持的副本数量分别为1、2、3，这个就是由 NameNode 来管理的。NameNode 会记录，A有1个副本、B有2个副本、C有3个副本。然后 NameNode 会告诉 DataNode 每个文件需要维持几份副本
   3. 管理数据块（Block）映射信息
      例如某文件需要分两个块保存、每个块有3个副本、生产服务器有5个，那么这个2块的3个副本会保存在哪个服务器就不确定了，他有可能会保存在同一台服务器上，也有可能不会保存在同一台服务器上（同一个文件的副本只能在一个服务器上保存一次）
   4. 处理客户端读写请求
      客户端请求先请求 NameNode，因为 NameNode 中存储了整个系统中所有数据的相关信息

2. DataNode：就是Slave。NameNode下达命令，DataNode执行实际的操作

   1. 存储实际的数据块
      实际的数据就是存储在DataNode上
   2. 执行数据块的读/写操作

3. Secondary NameNode(SNN、2NN)：在上图中不存在，因为在实际环境中，一般会使用 Zookeeper 搭建两个 NameNode 来管理集群，实现高可用。它并非是NameNode的热备（热备的意思是NameNode挂掉之后，Secondary NameNode会立刻顶替NameNode进行工作）。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务

   1. 辅助NameNode，分担其工作量，比如定期合并 Fsimage 和 Edits，并推送给 NameNode
   2. 在紧急情况下，可辅助恢复NameNode
      只能恢复一部分，因为SNN的扮演的角色是秘书，NN是老板，秘书不可能知道老板知道的全部信息

4. Client：客户端。NameNode服务器的9870端口的网页，就是个客户端。命令操作HDFS文件系统中的文件进行增删改查，命令也是个客户端

   1. 文件切分。文件上传HDFS的时候，Client 将文件切分成一个一个的 Block，然后进行上传
      分块，是由Client来做的。分块的大小是根据NameNode中设置的来分块。这个文件块的大小是可以改变的，常规设置是128MB或256MB
   2. 与 NameNode 交互，获取文件的位置信息
      无论读数据还是写数据，都要和 NameNode 交互
   3. 与 DataNode 交互，读取或者写入数据
      Client 与 NameNode 交互，NameNode 会告诉 Client 是否允许读取数据，或是是否存在文件，文件存在的话是在哪个 DataNode 下。实际工作的还是 DataNode
   4. Client提供一些命令来管理HDFS，比NameNode格式化
   5. Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作:

HDFS文件块大小（面试可能问）

HDFS中的文件在物理上是分块存储(Block)，块的大小可以通过配置参数 dfs.blocksize 来规定，默认大小在 Hadoop2.x/3.x 版本中是128M，1.x 版本中是64M.

这里的块的大小，指的是每一块最多能存储多少数据，例如有个 1KB 的文件，它只占用一块的128M里的1KB，剩余的空间其他块可以使用。

配置文件中默认的块大小是 134217728 B，也就是128MB，需要注意的是，这里的单位是 B

如何设定

如果某一个数据块的寻址时间约为10ms，即查找到目标block的时间为10ms

有很多块的情况下，它会依次遍历目标块，直到找到块为止

专家说（比较靠谱的专家）：寻址时间为传输时间的 1% 时，才是最佳状态

因此，上述块的存储时间应该为 10ms/0.01 = 1000ms = 1s，也就是说该块中保存的文件的最佳传输时间是1秒

而目前普通机械硬盘的传输速率普遍为100MB/s，固态硬盘的传输速率为200-300MB/s

所以说，块大小的设置，应该根据硬盘的传输速率来划分：如果是普通的机械硬盘，那设置128MB就很合适；如果是更强的固态硬盘，那设置256MB就更符合要求

大厂用的大多是256MB，中小厂用的是128MB

为什么块不能设置的太小，也不能太大

1. HDFS的数据块设置的太小，会增加寻址时间，程序一直在查找块的开始位置
   如果一个块的大小是 1KB，存储一个100KB的文件，就意味着要找100个块来进行合并，会增加大量的寻址时间
2. 如果数据块设置的太大，会增加传输时间（从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间），导致程序后期在并发处理这块数据时，会非常的慢