您好,登录后才能下订单哦!
本篇文章给大家分享的是有关HDFS该如何理解,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。HDFS采用了主从(Master/Slave)结构模型,一个HDFS集群是由一个NameNode和若干个DataNode组成的。
一、HDFS的背景介绍
随着数据量越来越大, 在 一个操作系统管辖的范围存不下了, 那么就 分配到更多的操作系统管理的磁盘中, 但是不方便管理和维护,迫切需要一种系统来管理多台机器上的文件,这就是分布式文件管理系统。
学术一点的定义就是: 分布式文件系统是一种允许文件通过网络在多台主机上分享的 文件的系统,可让多机器上的多用户分享文件和存储空间。分布式文件管理系统很多,hdfsHDFS 只是其中一种。适用于一次写入、多次查询的情况,不支持并发写情况,小文件不合适。因为小文件也占用一个块,小文件越多(1000个1k文件)块越 多,NameNode压力越大。
二、 HDFS的基本概念
我们通过 hadoop shell上传的文件是存放在 DataNode的block中, 通过 linux shell是看 不到文件的,只能看到block。 可以一句话描述HDFS: 把客户端的大文件存放在很多节点的数据块中 。在这里,出现了三个关键词:文件、节点、数据块。HDFS就是围绕着这三个关键词设计的,我们在学习的时候也要紧抓住这三个关键词来学习。
三、 HDFS的基本结构之 NameNode
1. 作用
NameNode的作用是 管理文件目录结构,接受用户的操作请求,是管理数据节点的。名字节点维护两套数据, 一套 是文件 目录与数据块之间的关系 , 另一套 是 数据块与节点之间的关系 。 前一套 数据是 静态的 ,是存放在磁盘上的, 通过fsimage和edits文件来维护 ; 后一套 数据是 动态的 ,不持久放到到磁盘的,每当集群启动的时候,会自动建立这些信息,所以一般都放在内存中。
所以他是整个文件系统的 管理节点。 它维护着整个文件系统的 文件目录树,文件/目录的 元信息和每个文件对应的 数据块列表。接收用户的操作请求 。
文件包括:
① fsimage (文件系统镜像):元数据镜像文件。存储某一时段NameNode内存 元数据信息。
② edits: 操作日志文件。
③ fstime: 保存最近一次checkpoint的时间
以上这些文件是保存在linux的文件系统中
2. 特点
是一种允许文件 通过网络在多台主机上分享的文件系统,可让多机器上的多用户分享文件和存储空间。
通透性。让实际上是通过网络来访问文件的动作,由程序与用户看来,就像是访问本地的磁盘一般。
容错。即使系统中有某些节点脱机,整体来说系统仍然可以持续运作而不会有数据损失。
适用于 一次写入、 多次查询的情况,不支持并发写情况,小文件不合适
3. 目录结构
既然NameNode维护这么多的信息,那么 这些信息都存放在哪里呢?
在hadoop源代码中有个文件叫做 hdfs-default.xml
打开这个文件
在第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。
我们可以进入linux文件系统
执行命令 cd /usr/local/hadoop/conf,more core-site.xml 查看,如下图所示
可以看出,这 两个文件的存储位置 是在linux文件系统的/usr/local/hadoop/tmp/dfs/name目录下。
我们进入这个目录
查看这个目录的内容,如下图所示
从图中可知,NameNode的核心文件 fsimage和 edits的存放在current目录下, 与此同时 name目录下有一个文件 in_use.lock 而查看其内容的时候发现,内容为空,也就是说只能有一个Namenode进程能够访问该目录,读者可以自己试一下,当没有开启hadoop时,该目录下是没有文件 in_use.lock 的,当hadoop启动以后才会生成该文件。
文件 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文件共享系统,这里不做详述。
看一下edits的描述
查看一下 hdfs-default.xml 中的一段代码,如下图所示
由其中的描述可知,该变量,决定DFSNameNode的 存储事务文件(edits)在本地文件系统上的位置。 如果这是一个以逗号分隔的目录列表,那么,事务文件会被复制所有的目录中,来冗余。默认值是dfs.name.dir一样。(edit保存事务过程)
四、 HDFS的基本结构之 DataNode
1.作用
DataNode的作用是HDFS中真正存储数据的。
2. block
如果一个文件非常大,比如100GB,那么怎么存储在DataNode中呢?DataNode在存储数据的时候是按照block为单位读写数据的。block是hdfs读写数据的基本单位。
假设文件大小是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 副本
副本就是备份,目的当时是为了 安全。 正是因为集群环境的 不可靠 ,所以才使用副本机制来保证数据的 安全性 。
副本的缺点就是会占用大量的存储空间。副本越多,占用的空间越多。相比数据丢失的风险,存储空间的花费还是值得的。
那么,一个文件有几个副本合适呢?我们查看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系统中。
五、 HDFS的基本结构之 SecondaryNode
HA的一个解决方案。但不支持热备。配置即可。由于数据操作越多edits文件膨胀越大,但不能让他无限的膨胀下去,所以要把日志过程转换出来 放到fsimage中。由于NameNode要接受用户的操作请求,必须能够快速响应用户请求,为了保证NameNode的快速响应给用户,所以将此项工 作交给了 SecondaryNode ,所以他也备份一部分fsimage的一部分内容。
执行过程:从NameNode上 下载元数据信息(fsimage,edits),然后把二者合并,生成新的fsimage,在本地保存,并将其推送到NameNode,同时重置NameNode的edits.默认在安装在NameNode节点上,但这样…不安全!
合并原理 如下图所示。
HDFS有着高容错性(fault-tolerant)的特点,并且设计用来部署在低廉的(low-cost)硬件上。而且它提供高吞吐量(high throughput)来访问应用程序的数据。
以上就是HDFS该如何理解,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。