| 编辑推荐: |
本文主要讲解了HDFS基础，HDFS架构思路解析、HDFS组成架构、HDFS数据写入机制、HDFS数据读取机制等内容。
本文来自微信侦查一线，由火龙果软件Anna编辑、推荐。 |
|
Hadoop包含三大基本组件：
HDFS——分布式文件系统，用于数据存储
YARN——统一资源管理和调度系统，用于管理集群的计算资源并根据计算框架的需求进行调度，支持包含MapReduce、Spark、Flink等多种计算框架。MRv2(Hadoop
2.x)之后的新特性。
MapReduce——分布式计算框架，运行于YARN之上
这篇文章主要是对Hadoop三大基本组件之一的HDFS进行深入的学习。
一、HDFS概述
1.1 HDFS产生背景
随着数据量越来越大，在一一个操作系统存不下所有的数据，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。
1.2 HDFS定义
HDFS（Hadoop Distributed File System）：是Hadoop的分布式文件系统的实现。它的设计目标是存储海量的数据，并为分布在网络中的大量客户端提供数据访问。
HDFS是高容错性的，可以部署在低成本的硬件之上，HDFS提供高吞吐量地对应用程序数据访问。
HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。
1.3 HDFS特性
能够保存PB级的数据量，将数据散布在大量的计算机（节点）上，支持更大的文件。
使用数据备份的方法解决文件存储的可靠性，如果集群中单个节点故障则启用备份。
很好的与Map-Reduce集成，为减小计算时的数据交互，HDFS允许数据在本地计算。
1.4 HDFS局限性
针对高速流式读取进行优化，查询性能低下（可利用Hive查询）
一次写入多次读取，不支持并发写入，并发读取性能很高
不支持文件修改
不支持缓存，每次读取文件须从硬盘上重新读取，当然对于大文件顺序读取性能影响不大
不适合存储小文件
二、HDFS架构思路解析
2.1 HDFS架构思路解析1
HDFS是一种分布式文件系统，将文件存储到不同的计算机节点中。如何将文件保存到不同节点中？
HDFS是基于何种思路来设计目前的架构？
2.2 HDFS架构思路解析2
将文件保存在不同的节点(Node)中：
问题： 可靠性差，节点损坏会导致节点内数据丢失。
解决方案，将一份数据备份到多个节点。
采用这种方法存在以下两种优点：
1、可靠性高，一个节点坏掉，启用备份
2、读取速度快，同一份数据多个备份同时读
那又存在什么局限性呢？
大文件保存和读取困难（如：单个100G文件）。
2.3 HDFS架构思路解析3
解决方案： 将所有文件以固定大小分割为块(Block)，节点只保存固定大小的块。
2.4 HDFS架构思路解析4
在思路解析3中还存在数据读取的问题
如何知道系统中有哪些文件？
节点中只存储了文件的Block，文件的原始信息丢失
如何知道某个原始文件的Block对应于哪些节点？
逐个节点去查找？
还是建立一个管理节点，专门来管理各个节点的信息？
最终解决方案：
存储数据时，将文件的原始信息，以及对应的Block信息存储到“管理节点”中保存。
读取数据时，先查询原始文件记录和对应的Block信息就知道本系统有哪些原始文件，这些文件有哪些Block，以及这些Block存储在哪些节点中。
三、HDFS组成架构
主从模式
整个Hadoop被构建在集群上，集群由各个节点（Node）构成。
将集群中的节点分为NameNode（管理者）和DataNode（工作者）。
文件被拆分为多个Block（块）放到不同的DataNode中，在HDFS 1.x 中每个块默认大小为64MB，HDFS
2.x 中每个块默认大小为128MB，同一个块会备份到多个DataNode中存储。
3.1 HDFS组成架构介绍
HDFS组成架构如下所示：
NameNode（nn）：也就是Master，它是一个主管、管理者。使用NameNode存储元数据信息，保存文件名以及文件的块(Block)存储在哪些DataNode中。每个存活的DataNode定时向NameNode发送心跳信息，如果未收到DataNode的心跳，NameNode将认定其已失效，不再向其派发任何文件读请求。NameNode会将失效的DataNode中的块(Block)备份到其他存活的DataNode中。简单来说就是：
（1）管理HDFS的名称空间;
（2）配置副本策略;
（3）管理数据块(Block) 映射信息;
（4）处理客户端读写请求。
DataNode：就是Slave，NameNode下达命令，DataNode执行实际操作。
（1）存储实际的数据块
（2）执行数据块的读/写操作
Client：就是客户端。
（1）文件切分。文件上传HDFS的时候， Client将文件切分成一 个个的Block， 然后进行上传
（2）与NameNode交互，获取文件的位置信息
（3）与DataNode交互，读取或者写入数据
（4）Client提供一 些命 令来管理HDFS,比如NameNode格式化
（5）Client可以通过一些命令来访问HDFS,比如对HDFS增删查改操作
Secondany NameNode：并非NameNode的热备。当NameNode挂掉的时候，
它并不能马上替换NameNode并提供服务。
（1）辅助NameNode,分担其工作量，比如定期台并fsimage和edits,并推送给NameNode
;
（2）在紧急情况下，可辅助恢复NameNode。
3.2 Namenode的元数据管理机制
整个系统的元数据都保存在NameNode中
内存元数据：meta data，用于元数据查询
硬盘元数据镜像文件：fsimage，持久化存储元数据
数据操作日志：edits，HDFS文件增删会造成元数据更改，将更改记录到edits，可运算出元数据
NameNode元数据管理过程
系统启动时，读取fsimage和edits至内存，形成内存元数据meta data。
client向NameNode发起数据增删查请求
NameNode接收到请求后，在内存元数据中执行增删查操作，并向client返回操作结果。
如果是增删操作，则同时记录数据操作日志edits。
使用Secondary NameNode，在适当的时机将操作日志合并到fsimage中（CheckPoint过程）
3.3 三个问题
为什么块的大小不能设置太小，也不能设置太大?
HDFS的块设置太小，会增加寻址时间，程序一直在找块的开始位置;
如果块设置的太大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时，会非常慢。
总结: HDFS块的大小设置主要取决于磁盘传输速率。
为什么文件操作不直接写入fsimage，而要写入单独的edits文件？
fsimage记录了整个大数据系统的元数据，非常庞大
fsimage是一个流式的文本文件，新增记录只需在文件末尾新增数据，速度快；删除记录时，需要删除文件中间的某些记录，文件越大执行效率越低
edits文件一般很小，通常超过64mb就会被执行合并，批量合并的操作效率比频繁修改高多了
为什么要使用Secondary NameNode合并操作日志？
提高性能：NameNode是唯一面向Client的管理节点，承受Client的并发访问，性能非常重要，而合并edits和fsimage需要较大计算量
提高可靠性：Secondary NameNode在合并edits 和fsimage时，会做数据备份，如果NameNode中的fsimage丢失，可从Secondary
NameNode恢复
3.4 Checkpoint过程
SN(Secondary NameNode)向NameNode(NN)发起询问，是否需要checkpoint
NN读取fstime中的上次checkpoint时间，结合edits文件大小等因素，决定开始checkpoint
NN新建一个edits文件(如：edits.new)，让新操作写入到edits.new中(避免在checkpoint过程中，edits发生改变)
SN向NN请求(http协议)获取fsimage和edits文件
SN将edits与fsimage合并，生成新的fsimage.checkpoint文件
SN将fsimage.checkpoint发送给NN
NN收到fsimage.checkpoint后，将其与旧的fsimage替换，更新fstime文件记录本次checkpoint操作
3.5 NameNode单点故障恢复
NameNode单点故障会导致整个Hadoop崩溃
利用SN(Secondary NameNode)的备份恢复NN (NameNode)元数据
SN与NN并不是时刻同步的，checkpoint有时间间隔，这会导致恢复后有数据丢失
NFS方案(NFS灾备)，对NN中元数据进行即时备份，避免元数据丢失
NSF(Network File System，网络文件系统)可与网络中的主机相互传输文件
NN可配置NFS灾备服务器，在写入fsimage、fstime、edits、edits.new等文件时，同步写入到NSF服务器中，进而避免NN数据丢失
HDFS高可用性
允许配置两个相同的NameNode一个为active mode处于活动模式，另一个为standby
mode处于待机模式
两个NameNode数据保持一致，一旦活动节点失效，则由待机节点切换为活动节点，保证Hadoop的正常运行
两个NameNode的共享同一个NFS以进行数据同步
四、HDFS数据写入机制
0：NameNode需要通过心跳机制收集DataNode的生存状态和存储状态；用以在第3步时，分配最佳的block存储位置。
用户客户端请求Hadoop客户端，并执行文件上传
上传的文件写入到Hadoop客户端的临时目录中，每当写入的数据量越过块(block)边界时(hadoop
1.x缺省64mb，hadoop2.x缺省128mb)，请求NameNode申请数据块
NameNode向Hadoop客户端返回block的位置
Hadoop客户端直接将block写入指定的DataNode
五、HDFS数据读取机制
0：NameNode需要通过心跳机制收集DataNode的生存状态；在第3步时，不会将失效的DataNode位置返回给客户端
用户客户端请求Hadoop客户端，请求返回指定文件
Hadoop客户端向NameNode发起读文件请求
NameNode查询meta data并返回文件对应的block位置
Hadoop客户端直接向DataNode请求block数据，获取到所有block后合并成文件
六、涉及概念（总结）
Block
所有的文件将被拆分为若干block(缺省每个block大小为64mb)，以存放在不同的DataNode中(每个block将有3个备份保存到不同DataNode)
DataNode
用于存储block， block以文件的形式随机存储在集群的各个DataNode上
DataNode不知道数据的内容，提取数据时无法知道每个Block该哪个DataNode上提取，于是需要记录每个Block存储在何处（NameNode上的元数据）。
NameNode
记录文件的元数据，NameNode知道所有的文件对应哪些Block以及这些Block都存放在何处
与各个DataNode通信并管理DataNode
元数据（ Metadata ）
描述数据的数据（data about data）
包含了：每个文件的文件名、文件位置、访问权限和各个块的名称和位置
大量小文件会生成过多元数据记录，降低NameNode查询效率(小文件定义：远远小于block边界大小的文件)。
例：64Mb的文件分配1个block，占用1条元数据记录；而同样大小的1024个64Kb的文件，须分配1024个block，占用1024条元数据记录
心跳
NameNode记录了所有的DataNode，但如果DataNode突然失效，NameNode需要迅速的知道；于是需要每个DataNode定期（默认每3秒）向NameNode发送心跳信息
客户端(Client)
代表用户通过与NameNode和DataNode交互来访问整个文件系统.
|
