HDFS深刻浅析

1、HDFS的背景介绍

随着数据量愈来愈大， 在 一个操做系统管辖的范围存不下了， 那么就 分配到更多的操做系统管理的磁盘中， 可是不方便管理和维护，迫切须要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。

学术一点的定义就是： 分布式文件系统是一种容许文件经过网络在多台主机上分享的 文件的系统，可以让多机器上的多用户分享文件和存储空间。分布式文件管理系统不少，hdfsHDFS 只是其中一种。适用于一次写入、屡次查询的状况，不支持并发写状况，小文件不合适。由于小文件也占用一个块，小文件越多（1000个1k文件）块越 多，NameNode压力越大。

2、 HDFS的基本概念

咱们经过 hadoop shell上传的文件是存放在 DataNode的block中， 经过 linux shell是看 不到文件的，只能看到block。 能够一句话描述HDFS： 把客户端的大文件存放在不少节点的数据块中 。在这里，出现了三个关键词：文件、节点、数据块。HDFS就是围绕着这三个关键词设计的，咱们在学习的时候也要紧抓住这三个关键词来学习。

3、 HDFS的基本结构之 NameNode

1. 做用

NameNode的做用是 管理文件目录结构，接受用户的操做请求,是管理数据节点的。名字节点维护两套数据， 一套 是文件 目录与数据块之间的关系 ， 另外一套 是 数据块与节点之间的关系 。 前一套 数据是 静态的 ，是存放在磁盘上的， 经过fsimage和edits文件来维护 ； 后一套 数据是 动态的 ，不持久放到到磁盘的，每当集群启动的时候，会自动创建这些信息，因此通常都放在内存中。

因此他是整个文件系统的 管理节点。 它维护着整个文件系统的 文件目录树，文件/目录的 元信息和每一个文件对应的 数据块列表。接收用户的操做请求 。

文件包括：

① fsimage （文件系统镜像）:元数据镜像文件。存储某一时段NameNode内存 元数据信息。

② edits: 操做日志文件。

③ fstime: 保存最近一次checkpoint的时间

以上这些文件是保存在linux的文件系统中

2. 特色

<1>是一种容许文件 经过网络在多台主机上分享的文件系统，可以让多机器上的多用户分享文件和存储空间。

<2>通透性。让其实是经过网络来访问文件的动做，由程序与用户看来，就像是访问本地的磁盘通常。

<3>容错。即便系统中有某些节点脱机，总体来讲系统仍然能够持续运做而不会有数据损失。

<4>适用于 一次写入、 屡次查询的状况，不支持并发写状况，小文件不合适

3. 目录结构

<1>既然NameNode维护这么多的信息,那么 这些信息都存放在哪里呢?

在hadoop源代码中有个文件叫作 hdfs-default.xml

<2>打开这个文件

在第149行和第158行，有两个配置信息，一个是 dfs.name.dir， 另外一个是dfs.name.edits.dir 。这两个文件表示的是 NameNode的核心文件fsimage和edits的存放位置，以下图所示

在对应配置的value值有 ${}，这是 变量的表示方式，ER表达式 ，在程序读取文件时，会把变量的值读取出来。那么，第150行的变量 hadoop.tmp.dir的值 (即hadoop临时存储路径)，以下图所示。

可是在咱们在上一章的配置文件 core-site.xml中， 配置的值是/usr/local/hadoop/tmp。

<3>咱们能够进入linux文件系统

执行命令 cd /usr/local/hadoop/conf,more core-site.xml 查看，以下图所示

能够看出，这 两个文件的存储位置 是在linux文件系统的/usr/local/hadoop/tmp/dfs/name目录下。

<4>咱们进入这个目录

查看这个目录的内容，以下图所示

从图中可知，NameNode的核心文件 fsimage和 edits的存放在current目录下， 与此同时 name目录下有一个文件 in_use.lock 而查看其内容的时候发现，内容为空，也就是说只能有一个Namenode进程可以访问该目录，读者能够本身试一下，当没有开启hadoop时，该目录下是没有文件 in_use.lock 的，当hadoop启动之后才会生成该文件。

<5>文件 fsimage 是NameNode的核心文件

这个文件很是重要，丢失的话，Namenode没法使用， 那么如何防止该文件丢失而形成不良后果呢。我能够下再次看一下hdfs-default.xml中的一段代码，以下图所示

由其中的描述可知，该变量，决定DFS NameNode 的NameTable(fsimage)应该在本地文件系统上的存储位置。若是这是 一个用逗号分隔的列表的目录，那么nametable，会被复复制到全部的目录中,来冗余（备份来保证数据的安全性）。 如${hadoop.tmp.dir}/dfs/name，~/name2，~/name3，~/name4。那么fsimage会分别复制到~/name1，~/name2，~/name3，~/name4 目录中。因此这些目录通常是在不一样的机器,不一样的磁盘，不一样的文件夹上，总之越分散越好，这样能保证数据的安全性。有人会问在多台机上怎么实现呢？其实在Linux中有nfs文件共享系统，这里不作详述。

<6>看一下edits的描述

查看一下 hdfs-default.xml 中的一段代码，以下图所示

由其中的描述可知，该变量，决定DFSNameNode的 存储事务文件（edits）在本地文件系统上的位置。 若是这是一个以逗号分隔的目录列表，那么，事务文件会被复制全部的目录中,来冗余。默认值是dfs.name.dir同样。（edit保存事务过程）

4、 HDFS的基本结构之 DataNode

1.做用

DataNode的做用是HDFS中真正存储数据的。

2. block

<1>若是一个文件很是大，好比100GB，那么怎么存储在DataNode中呢？DataNode在存储数据的时候是按照block为单位读写数据的。block是hdfs读写数据的基本单位。

<2>假设文件大小是100GB，从字节位置0开始，每64MB字节划分为一个block，依此类推，能够划分出不少的block。每一个block就是64MB大小。

2.1 咱们看一下 org.apache.hadoop.hdfs.protocol.Block类

这里面的属性有如下几个，下图所示。

由上图可知，类中的属性没有一个是能够存储数据的。 因此block本质上是一个 逻辑概念，意味着block里面不会真正的存储数据，只是划分文件的。

2.2 为何必定要划分为64MB大小呢？

由于这是在默认配置文件中设置的，咱们查看 core-default.xml 文件，以下图所示。

上图中的参数ds.block.name指的就是block的大小，值是67 108 864字节，能够换算为64MB。若是咱们不但愿使用64MB大小，能够在core-site.xml中覆盖该值。注意单位是字节。

2.3 副本

<1>副本就是备份，目的当时是为了 安全。 正是由于集群环境的 不可靠 ，因此才使用副本机制来保证数据的 安全性 。

<2>副本的缺点就是会占用大量的存储空间。副本越多，占用的空间越多。相比数据丢失的风险，存储空间的花费仍是值得的。

<3>那么，一个文件有几个副本合适呢？咱们查看hdfs-default.xml文件，以下图所示。

从图4.3中能够看到，默认的副本数量是3。意味着HDFS中的每一个数据块都有3份。固然，每一份确定会尽力分配在不一样的DataNode服务器中。试想：若是备份的3份数据都在同一台服务器上，那么这台服务器停机了，是否是全部的数据都丢了啊？

3. 目录结构

3.1 DataNode是按block来划分文件的

那么划分后的文件到底存放在哪里哪？咱们查看文件core-default.xml，以下图所示。

参数 dfs.data.dir的值就是 block存放在linux文件系统中的位置。变量 hadoop.tmp.dir的值 前面已经介绍了，是 /usr/local/hadoop/tmp ，那么 dfs.data.dir 的完整路径是/usr/local/hadoop/tmp/dfs/data。 经过linux命令查看，结果如图4.5所示。

3.2 上传一个文件

咱们首先点击PieTTY打开另外一个Linux终端，上传一个文件 jdk-6u24-linux-i586.bin，文件大小为 84927175k，以下图所示。

而后咱们能够在原来终端，查看上传文件，就是在该Linux文件系统的/usr/local/hadoop/tmp/dfs/data目录下， 以下图所示

上图中以 “blk_”开头的文件就是 存储数据的block。这里的命名是有规律的，除了block文件外，还有后 缀是“meta”的文件 ，这是block的源数据文件，存放一些元数据信息。所以，上图中只有2个block文件。

注意：咱们从linux 磁盘上传一个完整的文件到hdfs 中，这个文件在linux 是能够看到的，可是上传到hdfs 后，就不会有一个对应的文件存在，而是被划分红不少的block 存在的。并且因为咱们的hadoop安装方式是 伪分布安装 ，只有一个节点，DataNode和NameNode都在这一个节点上，因此上传的block块最终仍是在该Linux系统中。

5、 HDFS的基本结构之 SecondaryNode

HA的一个解决方案。但不支持热备。配置便可。因为数据操做越多edits文件膨胀越大，但不能让他无限的膨胀下去，因此要把日志过程转换出来 放到fsimage中。因为NameNode要接受用户的操做请求，必须可以快速响应用户请求，为了保证NameNode的快速响应给用户，因此将此项工 做交给了 SecondaryNode ，因此他也备份一部分fsimage的一部份内容。

执行过程：从NameNode上 下载元数据信息（fsimage,edits），而后把两者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，同时重置NameNode的edits.默认在安装在NameNode节点上，但这样...不安全！

合并原理 以下图所示。

免费提供最新Linux技术教程书籍，为开源技术爱好者努力作得更多更好：http://www.linuxprobe.com/