Hadoop日记Day5---HDFS介绍

wslhs

一、HDFS介绍
　　1.1 背景
　　随着数据量越来越大，在一个操作系统管辖的范围存不下了，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。
　　学术一点的定义就是：分布式文件系统是一种允许文件通过网络在多台主机上分享的文件的系统，可让多机器上的多用户分享文件和存储空间。分布式文件管理系统很多，HDFS 只是其中一种。适用于一次写入、多次查询的情况，不支持并发写情况，小文件不合适。因为小文件也占用一个块，小文件越多（1000个1k文件）块越多，NameNode压力越大。
　　1.2 HDFS是什么
　　我们通过hadoop shell上传的文件是存放在DataNode的block中，通过linux shell是看不到文件的，只能看到block。可以一句话描述HDFS：把客户端的大文件存放在很多节点的数据块中。在这里，出现了三个关键词：文件、节点、数据块。HDFS就是围绕着这三个关键词设计的，我们在学习的时候也要紧抓住这三个关键词来学习。
二、 HDFS的基本结构
2.1 NameNode
　　(1) 概述

　　NameNode的作用是管理文件目录结构，接受用户的操作请求，是管理数据节点。名字节点维护两套数据：
　　① 文件目录与数据块之间的关系。是静态的，存放在磁盘上的，通过fsimage和edits文件来维护。
　　② 数据块与节点之间的关系。不持久放到到磁盘，每当集群启动的时候，会自动建立这些信息，所以一般都放在内存中。
　　所以他是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表，接收用户的操作请求。
　　文件包括：
　　① fsimage（文件系统镜像）:元数据镜像文件。存储某一时段NameNode内存元数据信息。
　　② edits:操作日志文件。
　　③ fstime:保存最近一次checkpoint的时间
　　以上这些文件是保存在linux的文件系统中
　　(2) 特点
　　是一种允许文件网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。
　　① 通透性。让实际上是通过网络来访问文件的动作，由程序与用户看来，就像是访问本地的磁盘一般。
　　② 容错。即使系统中有某些节点脱机，整体来说系统仍然可以持续运作而不会有数据损失。
　　③ 适用于一次写入、多次查询的情况，不支持并发写情况，小文件不合适
　　(3) 目录结构
　　a) 既然NameNode维护这么多的信息,那么这些信息都存放在哪里呢?
　　在hadoop源代码中有个文件叫做hdfs-default.xml，如图3.1所示。

图 3.1

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

图 3.2

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

图 3.3

　　但是在我们在上一章的配置文件core-site.xml中，配置的值是/usr/local/hadoop/tmp。
　　c) 我们可以进入linux文件系统
　　执行命令 cd /usr/local/hadoop/conf,more core-site.xml查看到如图3.3所示的内容。

图 3.4

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

d) 我们进入这个目录

查看这个目录的内容，如图3.5所示。

图 3.5

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

　　
　　e) 文件fsimage件

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

图 3.6

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

　　f) 看一下edits的描述
　　查看一下hdfs-default.xml中的一段代码如图3.7所示

图 3.7

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

2.2 DataNode
　　(1) 概述
　　DataNode的作用是HDFS中真正存储数据的。
　　(2) block
　　① 如果一个文件非常大，比如100GB，那么怎么存储在DataNode中呢？DataNode在存储数据的时候是按照block为单位读写数据的。block是hdfs读写数据的基本单位。
　　② 假设文件大小是100GB，从字节位置0开始，每64MB字节划分为一个block，依此类推，可以划分出很多的block。每个block就是64MB大小。
　　a) 我们看一下org.apache.hadoop.hdfs.protocol.Block类，这里面的属性有以下几个，如图4.1所示。

图4.1

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

　　b) 为什么一定要划分为64MB大小呢？
　　因为这是在默认配置文件中设置的，我们查看core-default.xml文件，如图4.2所示。

图4.2

　　上图中的参数ds.block.name指的就是block的大小，值是67 108 864字节，可以换算为64MB。如果我们不希望使用64MB大小，可以在core-site.xml中覆盖该值。注意单位是字节。
　　(3) 副本
　　a) 副本就是备份，目的当时是为了安全。正是因为集群环境的不可靠，所以才使用副本机制来保证数据的安全性。
　　b) 副本的缺点就是会占用大量的存储空间。副本越多，占用的空间越多。相比数据丢失的风险，存储空间的花费还是值得的。
　　c) 那么，一个文件有几个副本合适呢？我们查看hdfs-default.xml文件，如图4.3所示。

图4.3

　　从图4.3中可以看到，默认的副本数量是3。意味着HDFS中的每个数据块都有3份。当然，每一份肯定会尽力分配在不同的DataNode服务器中。试想：如果备份的3份数据都在同一台服务器上，那么这台服务器停机了，是不是所有的数据都丢了啊？
　　(4) 目录结构
　　a) DataNode是按block来划分文件的
　　那么划分后的文件到底存放在哪里哪？我们查看文件core-default.xml，如图4.4所示。

图4.4

　　参数dfs.data.dir的值就是block存放在linux文件系统中的位置。变量hadoop.tmp.dir的值前面已经介绍了，是/usr/local/hadoop/tmp，那么dfs.data.dir的完整路径是/usr/local/hadoop/tmp/dfs/data。通过linux命令查看，结果如图4.5所示。
　　b) 上传一个文件
　　我们首先点击PieTTY打开另一个Linux终端，上传一个文件 jdk-6u24-linux-i586.bin，文件大小为 84927175k，如图4.5所示。

图4-5

然后我们可以在原来终端，查看上传文件，就是在该Linux文件系统的/usr/local/hadoop/tmp/dfs/data目录下，如图4.6所示

图 4.6

　　上图中以“blk_”开头的文件就是存储数据的block。这里的命名是有规律的，除了block文件外，还有后缀是“meta”的文件，这是block的源数据文件，存放一些元数据信息。因此，上图中只有2个block文件。
注意：我们从linux磁盘上传一个完整的文件到hdfs中，这个文件在linux是可以看到的，但是上传到hdfs后，就不会有一个对应的文件存在，而是被划分成很多的block存在的。而且由于我们的hadoop安装方式是伪分布安装，只有一个节点，DataNode和NameNode都在这一个节点上，所以上传的block块最终还是在该Linux系统中。
2.3 SecondaryNameNode
　　HA的一个解决方案。但不支持热备。配置即可。由于数据操作越多edits文件膨胀越大，但不能让他无限的膨胀下去，所以要把日志过程转换出来放到fsimage中。由于NameNode要接受用户的操作请求，必须能够快速响应用户请求，为了保证NameNode的快速响应给用户，所以将此项工作交给了SecondaryNode，所以他也备份一部分fsimage的一部分内容。
　　执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，同时重置NameNode的edits.默认在安装在NameNode节点上，但这样...不安全！
　　合并原理如图5.1所示。

图 5.1