Hadoop之HDFS（一）
Hadoop之HDFS（一）
- 1、Hadoop
- 2、HDFS
- 2.1HDFS特点
- 2.1.1优点
- 2.1.2缺点
- 2.2HDFS简单操作
- 2.3 数据块block
- 2.4 HDFS架构
- 2.4.1NameNode
- 2.4.2DataNode
- 2.4.3SecondaryNameNode
- 2.4.4心跳机制
- 2.4.5负载均衡
因为所处大数据行业，之前是小白，所以需要学习一些大数据的知识，便将学到的一些知识记录下来，方便复习，也是为了巩固所学知识。首先将从Hadoop讲起，而首先需要讲的就是Hadoop的HDFS。
1、Hadoop
先大概简单介绍一下Hadoop吧。根据官网的介绍（Hadoop官网），Hadoop是可靠的、可扩展的分布式计算的开源软件，它是一个可以处理大规模数据集的分布式的框架。
在Hadoop中，其主要是由HDFS（Hadoop Distributed File System，分布式存储），MapReduce（分布式计算），Yarn（Yet Another Resource Negotiator，资源调度引擎）。
2、HDFS
下面来介绍Hadoop的第一个模块HDFS。
HDFS是Hadoop中的一个存储子模块，是Hadoop中的分布式文件系统。
文件系统：简单点说就是可以创建、删除和复制文件等的一个软件，文件系统是管理磁盘的软件系统
分布式文件系统：当数据量过大时无法存储在某一台计算机上时，就需要将该数据进行拆分，分散到不同的计算机上进行存储。而管理这些跨多台计算机存储的文件系统则被称为分布式文件系统。
2.1HDFS特点
2.1.1优点
- 适合存储大文件
- 处理非结构化的数据
- 一次写入，多次读写
- 可以运行在廉价的机器上
- 高容错
- 可扩展
2.1.2缺点
- 不适合存储大量的小的文件
- 不适合处理低延迟的数据
- 不支持用户写入及多次修改
2.2HDFS简单操作
HDFS的操作命令与Linux有比较大的相似处，只是HDFS的命令是以hdfs dfs或hadoop fs开头。
-
上传文件到HDFS
hdfs fs -put [本地文件] [HDFS路径] -
下载文件到本地
hdfs fs -get [HDFS文件] [本地路径] -
列出文件目录下的信息
hdfs dfs -ls [HDFS路径] -
查看文件内容
hdfs dfs -cat [文件名] -
创建文件
hdfs dfs -touchz [文件名] -
创建目录
hdfs dfs -mkdir [目录名]
由以上一些常见的命令可以看出，其与Linux命令有着很多的相似处。可以直接在shell中使用hdfs dfs查看支持哪些参数。
2.3 数据块block
在向服务器上传文件的时候，Hadoop不会将该文件整体的直接上传，而是会将文件按照大小进行切分，默认情况下是128M，切分下的一个个的则被称为block，并将这些block分别存储在集群中的不同节点上。这里需要注意，若一个block块不足128M，该小文件不会占据整个块的空间。
我们知道HDFS的分布在廉价的机器上的，这些机器损坏的额可能性比较大，所以为了保证数据的可用性，HDFS的默认情况下是将每一个block保存三份，即三个副本。
在hdfs-site.xml文件中，replication可以设置副本数
dfs.replication
3
副本的存储策略，第一个block一般存储在本机器的HDFS目录下，第二个副本一般存储在不同机架的某个节点上，第三个副本一般存储在同第二个副本的机架上的另一个节点。
2.4 HDFS架构
下面讲下HDFS的架构，大数据的架构基本上都是主从架构。所以，HDFS也是主从架构的。
其主要有NameNode、DataNode和SecondaryNameNode，下面依次介绍。
2.4.1NameNode
NameNode是HDFS的主节点，主要负责文件系统的管理，并将HDFS的元数据信息保存在内存中，负责响应客户端的请求。
HDFS的元数据信息主要记录文件目录树，命名空间信息，并记录每个block的块信息以及存储的datanode的信息。而每个文件的元数据信息所占用的空间大小为150字节的数据，存储相同数量的大文件或者小文件，其元数据所占的空间是一样的，所以HDFS更适合存储大文件。
HDFS的元数据信息会以两种方式保存：一种是edits log，是HDFS的编辑日志，保存客户端对HDFS的全部修改；一种是fsimage，是HDFS的元数据的镜像文件，是HDFS元数据落入磁盘生成的文件。
2.4.2DataNode
主要是存储真实数据的节点，即存储block信息。
2.4.3SecondaryNameNode
在以上的介绍中，知道当对HDFS进行操作的时候，edits log文件都会将这些操作记录下来，所以一旦当机器出现故障的时候，则可以从edits log文件中进行恢复。但是有个问题，就是当edits log文件越来越大的时候，从该文件进行恢复就会花费大量的时间，所以引入了检查点机制checkpoint，fsimage文件就是HDFS元数据的持久检查点，但是依然避免不了随着edits log文件的增大，恢复时间过长的问题。为了解决此问题，引入了SecondaryNameNode机制来辅助NameNode，用来合并fsimage和edits文件。
SecondaryNameNode是定期做检查点的操作，创建检查点有两个条件：一个是时间条件，每隔一个小时创建一个检查点，另一个是edits文件大小的条件，当该文件中包含100万个事务，也是会创建检查点的。
1、首先SecondaryNameNode会先请求NameNode中的edits的滚动，通过HTTP的方式读取NameNode中的fsimage和edits
2、SecondaryNameNode会将fsimage文件读取到内存中，然后执行edits文件中的每个操作，并将其合并为一个新的fsimage文件
3、SecondaryNameNode通过HTTP PUT请求将新的fsimage文件发送到NameNode中
4、NameNode使用新的fsimage替换旧的fsimage，同时系统更新fsimage文件到记录检查点的时间
整个过程结束之后，NameNode就有了最新的fsimage文件和较小的edits文件
2.4.4心跳机制
心跳主要是判断DataNode是否正常工作，并通过心跳机制可以知道该DataNode的存储情况，比如磁盘利用率等。
1、NameNode在启动时，会发送一个ipc server
2、DataNode启动后想NameNode注册，并每隔3秒钟向NameNode发送一个“心跳heartbeat”
3、如果超过10分钟NameNode没有收到某个DataNode的心跳，则认为该DataNode节点不可用
4、DataNode周期性的（6小时）相NameNode上报当前节点上的块状态报告BlockReport，该报告包含了该DataNode上的所有数据块列表。
2.4.5负载均衡
负载均衡比较可能出现的原因是机器与机器之间的磁盘利用率不平衡导致的，尤其是DataNode节点出现故障或者新增DataNode节点时。负载均衡主要是为了提升集群的利用率。手动触发负载均衡可以使用如下命令
#磁盘利用率最大的节点比最小的节点大于5%，触发均衡
$HADOOP_HOME/sbin/start-balancer.sh -t 5%