从零开始的大数据（一） --- HDFS的知识概述（上）

前言

从零开始的高并发系列咱们已经把 zookeeper 给更新完了，顺带一提以前的zookeeper并无结合大数据来进行说明。从新开个坑一方面是一直都想找个理由来总结一下大数据方面的东西，另外一方面则是抓住时代的走向吧，毕竟也是为了本身，因此废话很少说咱们就开始吧。

阅读须知

这相似于一份学习笔记，但是绝对有头有尾，会用最清晰明了的语言来描述知识点，但愿你们也能有所收获

重点：大数据的概念性问题偏多，因此文章中不会像之前同样出现堆积代码的状况，更多都是在阐述概念

大数据的话必定要看命令和日志！

以往 zookeeper 的连接（仅涉及Java）

从零开始的高并发（一）--- Zookeeper的基础概念

从零开始的高并发（二）--- Zookeeper实现分布式锁

从零开始的高并发（三）--- Zookeeper集群的搭建和leader选举

从零开始的高并发（四）--- Zookeeper的分布式队列

从零开始的高并发（五）--- Zookeeper的配置中心应用

从零开始的高并发（六）--- Zookeeper的Master选举及官网小览

1、HDFS的概念

先简单过一下基础概念，起码知道接下来要说的东西和这个东西是用来干啥的

1.1 Hadoop架构

HDFS(Hadoop Distributed FileSystem)，由3个模块组成：分布式存储HDFS，分布式计算MapReduce，资源调度框架Yarn

大量的文件能够分散存储在不一样的服务器上面

单个文件比较大，单块磁盘放不下，能够切分红不少小的block块，分散存储在不一样的服务器上面，各服务器经过网络链接，形成一个总体。

1.2 核心概念block

HDFS3.x上的文件会按照128M为单位切分红一个个的block，分散存储在集群的不一样的数据节点datanode上，须要注意的是，这个操做是HDFS自动完成的。

假设咱们如今要存储一个300M的文件，这个300M就会被切分红

datanode1：128M + datanode2：128M + datanode3：44M
复制代码

这时咱们须要知道，就算它的底层逻辑会按照128M进行划分，但是datanode3一个实际占用44M的块也是不会占据128M的空间的

1.3 block的副本

为何hadoop直至今天会这么流行，就是由于它的初始设计就是能够部署在商用服务器上，而咱们知道，商用服务器是很是廉价的，而这种廉价的服务器就很容易出现故障，好比CPU,IO内存等等均可能会产生问题

按照咱们刚刚1.2的说法，一个文件被分红了3块存储在不一样的datanode上，万一其中的一个datanode挂掉，那岂不是这个文件就找不回来了吗，因此hadoop还对咱们的每个数据块作了一个副本，保证数据的可靠性

副本数能够本身进行手动设置，通常是3个副本

hdfs-site.xml

    <configuration>
        <property>
            <name>dfs.replication</name>
            <value>3</value>
        </property>
    </configuration>
复制代码

能够清晰看到value的值为3，咱们的副本数就为3

相似于这些个属性咱们是如何得知它们的做用的呢，在hadoop官网上能够查看，这里用的2.7.3。点开官方文档，在左侧边栏拉至最下方能够看到configuration项

固然咱们须要找对文件，是HDFS的内容就要找hdfs-default.xml，若是是MapReduce，就要mapred-default.xml，yarn的就是yarn-default.xml

点击hdfs-default.xml，能够按下ctrl+f进行搜索，输入dfs.replication回车

这里咱们就能够看到了，dfs.replication的默认值就是为3，后面的参数说明写着default block replication，而下面的参数dfs.replication.max就是副本最大可设置为512的意思了

一样刚刚在 1.2 核心概念block 时咱们提到的block大小为128M在这个文件中也能够找到

因此其实每个数据块block的大小也是能够自主设置的

1.3.1 机架存储策略

实际机房中，会有机架，每一个机架上会有若干台服务器

通常来讲咱们会把一个block的3个副本分别按照下述方法进行存储：

第一个副本就存储在一个机架A上
第二个副本存储在和这个block块不一样机架（好比机架B）的一个服务器上
复制代码

咱们存储第2个副本时会优先把副本存储在不一样的机架上，这是为了防止出现一个机架断电的状况，若是副本也存储在同机架上的不一样服务器上，这时候数据就可能丢失了。

第三个副本存储在机架B的另一个服务器上（注意副本2,3都存储在了机架B）
复制代码

为何会这么选择，由于若是咱们把副本3也放在另一个机架C上，副本2和副本3之间的通讯就须要副本2经过它的交换机去联系总交换机，而后总交换机去联系机架C的交换机，须要走的路线很是长，并且机房中的带宽资源很是宝贵，若是处于高并发的状况，很容易就把机房的带宽打满，此时整一个集群的响应速度会急剧降低，这时候服务就会出现问题了。

固然咱们的副本数也是能够手动经过命令增长的，在客户端访问量多的时候，能够适当分配一下压力

$ hadoop fs -setrep -R 4 path+FileName
复制代码

setrep的意思其实就是set replication，设置副本数的缩写，上面命令就是将副本数设置成4份了，后面跟着文件路径和文件名便可

2、HDFS的三大组件

再次强调一下，大数据的框架大部分其实都是主从架构，就是一主多从，等下要讲到的HDFS就是一个NameNode，多个DataNode，MapReduce就是一个JobTracker，多个TaskTracker，Yarn则是一个ResourceManager，多个NodeManager，而Spark就是一个Master和多个Slave

DataNode的介绍其实能够省略，姑且只须要知道它的做用是存放block块的便可。

2.1 NameNode的介绍

大数据框架都是分布式的，可能每一个角色都运行在各个不一样的服务器上面，须要进行通讯的时候就要须要网络的支持，而在咱们客户端须要读一个文件的信息时，必须知道咱们这个文件被分红了多少个block，各个block又分别存储在哪一个服务器上，这种用于描述文件的信息被称为文件的元数据信息（metaData），而metaData就是存储在NameNode的内存中的

2.2 metaData的介绍

metaData的大小：文件，block，目录占用大概150byte字节的元数据，因此为何说HDFS适合存储大文件而不适合存储小文件，可想而知存储一个大文件就只有一份150byte的元数据，存储N多个小文件就会伴随存在N份150Byte字节的元数据文件，这就很是地不划算

元数据信息以命名空间镜像文件（如下称为fsimage）和编辑日志（如下称为edits log）的方式保存，二者的做用分别是

fsimage：元数据镜像文件，保存了文件系统目录树信息以及文件和块的对应关系
edits log：日志文件，保存了文件的更改记录
复制代码

为何元数据须要存储在NameNode的内存中呢，答案很简单，存储在内存中意味着快，固然也会存在问题，就是若是NameNode宕机了，内存就没法读取了，此时为了防止这种状况出现，也为了加快NameNode从故障中恢复的速度，就设计了一个SecondaryNameNode的角色

日志缓存方面：客户端向 HDFS 写文件，会记录下来操做日志，而这时咱们会预先准备好两块缓存区域，这个日志在写满了第一块缓存时，会开始录入磁盘，也就是edits log，NameNode的内存中，这种状态就是一个双缓存异步写的操做。这样能够保证客户端写的日志时刻都能被记录下来。

2.3 SecondaryNameNode的介绍

它的做用主要有如下几点

1.备份NameNode中的元数据信息
2.提升NameNode的重启速度
3.必要的时候可做为新的NameNode
复制代码

为何说SecondaryNameNode能够提升NameNode的恢复速度？

当集群启动的时候，会记录下启动的时间t，而随着一段时间过去后或者NameNode中的edits log文件存满后就会触发checkPoint操做，在Spark中也会有这个知识点，主要做用就是对重要的数据进行备份的一个操做

对操做步骤进行一个分点阐述方便你们阅读

1.SecondaryNameNode 会经过http get方式把edits log和fsimage的信息拉取过来

2.在SecondaryNameNode中把edits log和fsimage作一个合并，产生一个新的文件叫作fsimage.ckpt

3.在SecondaryNameNode中合并完成以后，再回传给NameNode里面

4.这时大几率会有客户端还在对NameNode进行读写操做，也会产生新的日志，会单独放在一份edits new文件中

5.刚刚回传回来的fsimage.ckpt进行分解，本来的fsimage和edits log，不过此时的edits log会把edits new中的日志文件一同合并做为完整的一份edits log文件

为何说SecondaryNameNode能够提升NameNode的重启速度

首先搞清楚NameNode节点挂掉后它是如何进行恢复的

首先它会把内存中的镜像文件fsimage读到内存当中，而后经过edits log所记录的全部操做从新执行一遍，把全部的元数据都恢复以后，才能回到关机以前的状态，这个过程十分缓慢

可是有了SecondaryNameNode以后，经过它提供的fsimage.ckpt能够恢复很大一部分的元数据信息，再直接经过执行edits log中所记录下来的，从edits new中合并过来的新操做，就能够进行恢复

而在NameNode肯定没法重启以后，SecondaryNameNode就能够经过如下命令做为新的NameNode对外提供服务

hadoop-daemon.sh start namenode
复制代码

固然咱们不难发现，这种方式很是地不优雅，由于在NameNode进行重启或者SecondaryNameNode进行上位的时间段中咱们的集群确定都会有一段空白期，因此以后讲到的hadoop HA的方式就会帮助咱们解决这个问题

3、HDFS机制

3.1 心跳机制

心跳机制解决了HDFS集群间的通讯问题，仍是NameNode命令DataNode执行操做的途径

1.master namenode启动以后，会开一个ipc server
2.slave DataNode启动，链接NameNode，每隔3s向NameNode发送一个心跳，并携带状态信息
3.NameNode经过对这个心跳的返回值来给DataNode传达任务指令
复制代码

心跳机制的做用

1.NameNode全权管理数据块的复制，它周期性从集群中的每一个DataNode接收心跳信号和块状态报告（blockReport），接收到心跳信号意味着该DataNode节点工做正常，块状态报告包含了该DataNode上全部数据块的列表

2.DataNode启动时向NameNode注册，经过后周期性地向NameNode上报blockReport，每3秒向NameNode发送一次心跳，NameNode返回对该DataNode的指令，如将数据块复制到另外一台机器，或删除某个数据块等···而当某一个DataNode超过10min还没向NameNode发送心跳，此时NameNode就会断定该DataNode不可用，此时客户端的读写操做就不会再传达到该DataNode上

3.hadoop集群刚开始启动时会进入安全模式（99.99%），就用到了心跳机制，其实就是在集群刚启动的时候，每个DataNode都会向NameNode发送blockReport，NameNode会统计它们上报的总block数，除以一开始知道的总个数total，当 block/total < 99.99% 时，会触发安全模式，安全模式下客户端就无法向HDFS写数据，只能进行读数据。

3.2 负载均衡

其实就是节点的增长或减小，或者节点的磁盘使用率高低的问题，主要就是经过网络进行数据的迁移工做以达到高可用率

触发命令

$ HADOOP_HOME/sbin/start-balancer.sh -t 5%
复制代码

5%其实就是刚刚提到的磁盘的利用率差值，大于5%时会触发负载均衡策略

finally

下一篇会继续更新HDFS的读写流程和容错，HA高可用和联邦