大数据｜HDFS分布式文件系统
前文回顾：Hadoop系统
目录
HDFS概述
HDFS在设计时的假设和目标
HDFS的基本特征
HDFS的体系结构
目录节点
数据节点
HDFS的副本机制
HDFS的数据存取策略
数据存放
数据读取
数据复制
HDFS可靠性设计
数据节点出错
数据异常
目录节点出错
HDFS概述
在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统统称为分布式文件系统。HDFS是基于流数据模式访问和处理超大文件的需求而开发的，它可以运行于廉价的商用服务器上。
HDFS（Hadoop Distributed File System）是Apache Hadoop项目的一个子项目。
Hadoop存储大型数据就是使用HDFS作为存储系统，HDFS使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。换句话说，HDFS解决的问题就是大数据存储。
HDFS在设计时的假设和目标
1.硬件出错——硬件故障是常态，HDFS将有成百上千的服务器组成，每一个组成部分都有可能出现故障，因此故障的检测和自动快速恢复是HDFS的核心架构目标。
2.流数据读写——HDFS上的应用与一般的应用不同，HDFS被设计成批量处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据的高吞吐量。
3.大数据集——HDFS应被调整成支持大文件，它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的问题。
4.简单的文件模型——大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。
5.把计算移动到数据附近——一个应用请求的计算，离它操作的数据越近越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比将数据移动到应用所在显然更好。
6.强大的跨平台兼容性——在异构的硬件和软件平台上的可移植性，这将推动需要大数据集的应用更广泛地采用HDFS作为平台。
从HDFS看分布式文件系统的设计需求
- 透明性：对于分布式文件系统，最重要的是希望能达到5个透明性要求——访问的透明性，位置的透明性，移动的透明性，性能的透明性，伸缩的透明性
- 并发控制：客户端对于文件的读写不应该影响其它客户端对同一个文件的读写。HDFS的机制非常简单，任何时间都只允许一个写的客户端，文件经创建并写入之后不再改变，它的模型是一次写，多次读
- 文件复制功能：一个文件可以表示为其内容在不同位置的多个拷贝，这样做带来了至少两个好处——访问同一个文件时，可以从多个服务器中获取，从而改善服务的伸缩性；提高了容错能力，某个副本损坏了，仍然可以从其他服务器节点获取该文件
- 硬件和操作系统的异构性
- 容错能力：在分布式文件系统中，尽量保证文件服务在客户端或者服务端出现问题的时候能正常使用是非常重要的（详见下文可靠性手段）
- 安全性问题：HDFS的安全性是比较弱的，只有简单的与Unix文件系统类似的文件许可控制，未来版本会实现更为安全的策略
HDFS的基本特征
1.大规模数据分布存储能力：存储极大数目的信息（terabytes or petabytes），将数据保存到大量的节点当中；支持很大的单个文件
2.高并发访问能力：提供对数据的快速访问；并提供良好的可扩展性，通过简单加入更多服务器快速扩充系统容量，服务更多的客户端
3.强大的容错能力：提供数据的高可靠性和容错能力，单个或者多个节点不工作，对系统不会造成任何影响，数据仍然可用。通过一定数量的数据复制保证数据存储的可靠性和出错恢复能力
4.顺序式文件访问：HDFS对顺序读进行了优化，支持大量数据的快速顺序读出，代价是对于随机的访问负载较高
5.简单的一致性模型（一次写多次读）：数据支持一次写入，多次读取；不支持已写入数据的更新操作，但允许在文件尾部添加新的数据
6.数据库存储模式：基于块的文件存储，默认的块的大小是64MB，减少元数据的量，有利于顺序读写（在磁盘上数据顺序存放）
HDFS关键特点：
- 高吞吐量，对延时没有要求（可能牺牲延时）。
- 一次写入，多次读取，且一般是顺序读。
- 高容错性，且不需要太昂贵的机器，可以相对节约成本。
HDFS的局限性：
- 不适合低延迟数据访问
- 无法高效存储大量小文件
- 不支持多用户写入及任意修改文件
正因为如此，HDFS适合用来做大数据分析的底层存储服务，并不适合用来做网盘等应用。因为它修改不方便，延迟大，网络开销大，成本高（和做网盘应用的那些相比）。
HDFS的体系结构
Hadoop文件系统采用主从架构对文件系统进行管理，一个HDFS集群由唯一一个目录节点和若干数据节点组成。
- HDFS对外表现为一个普通的文件系统，用户可以用文件名去存储和访问文件，而实际上文件是被分成不同的数据块，这些数据块就是存储在数据节点上
- 一个典型的Hadoop文件系统集群部署，是由一台性能较好的机器运行目录节点，而集群里面的其它机器每台上面运行一个数据节点
- 唯一的目录节点的设计大大简化了整个体系结构，目录节点负责Hadoop文件系统里面所有元数据的管理，这样的设计使数据不会脱离目录节点的控制
目录节点
目录节点（NameNode）是集群里面的主节点，负责管理整个HDFS系统的命名空间和元数据（命名空间、数据块与文件名的映射表、每个数据块副本的位置信息（包括副本因子）），也是客户端访问HDFS系统的入口
- 命名空间，即整个系统的目录结构；命名空间的维护操作包括文件和目录的创建、删除、重命名等
Hadoop的文件命名遵循了传统的“目录/子目录/文件”格式，通过命令行或者API可以创建目录，并将文件保存在目录中，也可以对文件进行创建、删除、重命名等操作。命名空间由目录节点管理，所有对命名空间的改动（创建、删除、重命名、改变属性等，不包括文件打开读取写入数据），都会被HDFS记录下来。
- 数据块与文件名的映射表，客户端需要访问目录节点才能知道一个文件的所有数据块都保存在哪些数据节点上
- 每个数据块副本的位置信息，每个数据块默认有3个副本，应用程序可以指定某一个文件在HDFS中保存多少份，这称为“副本因子”(Replication Factor)，该信息也保存在目录节点里面
数据节点
数据节点（DataNode）一般就是集群里面的一台机器，负责数据的存储和读取
- 在写入时，由目录节点分配数据块的保存，然后客户端直接写到对应的数据节点
- 在读取时，当客户端从目录节点获得数据块的映射关系后，会直接到对应的数据节点读取数据
- 数据节点也要根据目录节点的命令创建、删除数据块和进行副本复制
四个基本组件：HDFS Client、NameNode、DataNode和Secondary NameNode。
Client：就是客户端
- 文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
- 与 NameNode 交互，获取文件的位置信息。
- 与 DataNode 交互，读取或者写入数据。
- Client 提供一些命令来管理 和访问HDFS，比如启动或者关闭HDFS。
Secondary NameNode：并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。
- 辅助 NameNode，分担其工作量。
- 定期合并 fsimage和fsedits，并推送给NameNode。
- 在紧急情况下，可辅助恢复 NameNode。
HDFS的副本机制
HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块，这个数据块被称为block，除了最后一个，所有的数据块都是同样大小的。
1.为了容错，文件的所有block都会有副本。
2.每个文件的数据块大小和副本系数都是可配置的。
3.所有的文件都是以 block 块的方式存放在 HDFS 文件系统当中,作用如下:
- 可以存储任意大的文件，而又不会受到网络中任一单个节点磁盘大小的限制（一个文件有可能大于集群中任意一个磁盘，引入块机制可以很好的解决这个问题）
- 使用抽象块作为操作的单元，可以简化存储系统。
- 块非常适合用于数据备份进而提供数据容错能力。
- 副本优点是安全，缺点是占空间。
hadoop当中, 文件的 block 块大小默认是 128M（也有说是64M，但现在查主要是128M，应该是版本差别），默认的副本数为3,也就是每个block会存三份。
- 假设文件大小是100GB，从字节位置0开始，每128MB字节划分为一个block，依此类推，可以划分出很多的block。每个block就是128MB大小。
- 注意当一个文件的大小不足128M时，比如为2M，那么这个文件也占用一个block，但是这个block实际只占2M的空间，所以从某种意义上来讲，block只是一个逻辑单位。
block块的大小可以通过 hdfs-site.xml 当中的配置文件进行指定。
dfs.block.size
块大小以字节为单位
HDFS分布式文件系统的内部有一个副本存放策略，默认副本数为3,在这里以副本数为3为例：
- 第一副本：优先放置到离写入客户端最近的DataNode点，如果上传节点就是DataNode，则直接上传到该节点，如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
- 第二个副本：放置在于第一个副本不同的机架的节点上（随机选择）
- 第三个副本：与第二个副本相同机架的不同节点中。
HDFS的数据存取策略
数据存放
- 目前Hadoop采用以机柜为基础的数据存放策略，这样做的目的是提高数据可靠性和充分利用网络带宽
- 一个大的Hadoop集群经常横跨多个机柜，而不同机柜之间的数据通讯经过交换机或者路由器，所以同一个机柜中不同机器的通讯带宽是比不同机柜之间机器通讯时候的大
- 默认的副本因子是3，意思就是每一个数据块一共有3个地方存放（存放策略详见上文），这样既可以在机柜异常时进行数据恢复，又可提高读写性能
数据读取
- 数据读取的时候，如果有块数据和客户端的机柜id一样，就优先选择该数据节点，客户端直接和数据节点建立连接，读取数据
- 如果没有，可以随机选取一个数据节点
数据复制
数据复制主要是在数据写入和数据恢复的时候发生，数据复制使用流水线复制的策略
当客户端要在HDFS上面写一个文件
- 首先它把这个文件写在本地
- 然后对文件进行分块，默认128MB一块
- 每块数据都对HDFS目录节点发起写入请求
- 目录节点选择一个数据节点列表（副本位置），返回给客户端
- 然后客户端就把数据写入第一台数据节点，并且把列表传给数据节点
- 当数据节点接收到4KB数据的时候，写入本地，并且发起连接到下一台数据节点，把这个4K传过去，形成一条流水线
- 当最后文件写完的时候，数据复制也同时完成，这是流水线处理的优势
HDFS可靠性设计
HDFS的主要目标之一就是在硬件出错的时候保证数据的完整性，它把磁盘错误作为肯定会出现的情况来对待，而不是异常。
数据节点出错
- 每个数据节点会定时发送一个心跳信息给目录节点，表明自己仍然存活
- 网络异常可能会导致一部分数据节点无法和目录节点通讯，这时候目录节点收不到心跳信息，就认为该数据节点已死机，会从有效数据节点列表中清除它，而该数据节点上面的所有数据块也会被标记为不可读
- 这个时候某些数据块的副本份数有可能就低于它的副本因子，目录节点会定期检查，看每一个数据块是否需要进行副本复制；若需要，则复制到合适的（新的）数据节点
数据异常
- 由于网络传输和磁盘出错的原因，从数据节点读取的数据有可能出现异常，客户端需实现对数据块的校验，保证数据一致性
- 客户端在创建文件的时候，HDFS会为文件生成一个校验和（CheckSum），校验和文件与文件本身保存在同一个空间中。数据传输时，将数据与校验和一起传输，客户端对每个读取的数据块进行校验
- 如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且报告给目录节点这个文件块有错误，目录节点会重新复制这个块
目录节点出错
- HDFS刚启动时，目录节点进入安全模式（safe mode），此时不做任何文件修改操作；目录节点和各个数据节点通信，获得数据块信息，并对数据块信息进行检查；认为安全的块比例超过阈值，才退出安全模式
- 辅助目录节点，用来备份目录节点的元数据，当目录节点失效时，从辅助目录节点恢复出目录节点的元数据
- 文件镜像数据FsImage和编辑日志数据Editlog是目录节点元数据中最重要的部分，前者相当于HDFS的检查点，后者记录对HDFS的最新修改信息
- 目录节点启动时，读取FsImage的内容到内存，并将其与Editlog中的所有修改信息合并生成最新的FsImage；目录节点运行中，所有关于HDFS的修改信息，都将写入Editlog
- FsImage和Editlog是目录节点上面两个最核心的数据结构，如果其中一个文件出错的话，会造成目录节点不起作用
- 由于这两个文件如此重要，所以目录节点上面可以设置多个备份文件，以及在辅助目录节点进行备份，当这两个文件有改变的时候，目录节点就会发起同步操作，虽然这样增加了系统的负担，但是为了实现数据的可靠性，这个同步操作是非常必要的
本文基于老师上课PPT和已有博客，学习博客来源：Lansonli大佬hadoop专栏
最近在发一些panda疯，好可爱好可爱好可爱————
