标签:hadoop、大数据
HDFS有着高容错性(fault-tolerant)的特点,并且设计用来部署在低廉的(low-cost)硬件上。而且它提供高吞吐量(high throughput)来访问应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。
1. HDFS有以下几个主要特点:
处理超大文件:存储的一个超大文件可以达到数GB级、数TB级、数PB级。
集群规模动态扩展:节点动态加入到集群,可以数百数千个
流式数据读写:HDFS的设计思想“一次写入,多次读取”,一个数据集一旦由数据源生成,就会被复制分发到不同的存储节点中,然后响应各种各样的数据分析任务请求。
运行于廉价的商用机器集群上:HDFS设计时充分考虑了可靠性、安全性及高可用性,因此Hadoop对硬件要求比较低,可以运行于廉价的商用机器集群,无需昂贵的高可用性机器
2. HDFS的局限性:
不适合低延迟数据访问: HDFS是为了处理大型数据集,主要是为了达到高的数据吞吐量而设计,这就可能以高延迟作为代价。10毫秒以下的访问可以无视hdfs,不过hbase可以弥补这个缺
无法高效存储大量小文件: namenode节点在内存中存储住整个文件系统的元数据,因此文件的数量就会受到限制,每个文件的元数据大约150字节
不支持多用户写入及任意修改文件 :不支持多用户对同一文件进行操作,而且写操作只能在文件末尾完成,即追加操作。
块(block):
HDFS的文件以块的方式存储,块的大小默认为64MB。大于多数文件系统的块的大小。通常文件系统的块的大小为几千字节,磁盘块的大小为512B。
比磁盘块大很多,目的是减少寻址开销。如果块太小,大量的时间将花在磁盘块的定位时间上。
当HDFS文件小于块大小时,不会占满整个数据块的存储空间 ??
HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanode组成。
Namenode是一个中心服务器,负责管理文件系统的命名空间和客户端对文件的访问。
Namenode执行文件系统的命名空间操作,例如打开、关闭、重命名文件和目录,同时决定block到具体Datanode节点的映射。
Datanode负责处理文件系统的读写请求,在Namenode的指挥下进行block的创建、删除和复制
一个文件其实分成一个或多个block,这些block存储在Datanode集合里。
NameNode作用:负责管理文件系统的命名空间(元数据),维护整个文件系统的文件目录树及这些文件的索引目录。
NameNode的文件结构(图示引用书籍:Hadoop实战):
fsimage:二进制文件,存储HDFS文件和目录元数据
Edits:二进制文件,每次保存fsimage之后到下次保存之间的所有HDFS操作,记录在Edit s文件。对文件的每一次操作,如打开、关闭、重命名文件和目录,都会生成一个edit记录。
fstime:二进制文件,fsimage做完一次checkpoint后,将最新的时间戳写入到fstime
VERSION:文本文件,文件的内容为(图示引用书籍:Hadoop实战):
其中,namespaceID是文件系统的唯一标识符,当文件系统第一次被格式化的时候会被创建,这个标识符也要求所有的DataNode节点和NameNode保持一致。 NameNode会使用它识别新的DataNode,DataNode只有在向NameNode注册后才会获取namespaceID。
元数据
包括文件和目录的ownership和permission;
文件包含哪些块,块的个数及块的副本数;
块保存在哪个Datanode(由Datanode启动时上报);
fsimage中的元数据结构如图所示:
元数据分类:分为内存元数据和元数据文件
元数据文件:包含fsimage&edits,存储在本地磁盘和NFS,防止NameNode所在机器磁盘坏掉后数据丢失
内存元数据:包含fsimage和Blockmap的映像。NameNode启动时会加载fsimage&edits文件到内存,merge后将最新的fsimage回写到本地磁盘和NFS,覆盖旧的fsimage文件
NameNode启动过程中fsimage文件处理流程
第一步:首先加载硬盘上的fsimage文件和edits文件,在内存中merge后将新的fsimage写到磁盘上,这个过程叫checkpoint
(一般NameNode会配置两个目录来存放fsimage和edits文件,分别是本地磁盘和NFS,防止NameNode所在机器的磁盘坏掉后数据丢失。
NameNode启动时会比较NFS和本地磁盘中的fstime中记载的checkpoint时间加载最新的fsimage。)
第二步:NameNode加载完fsimage&edits文件后,会将merge后的结果同时写到本地磁盘和NFS。此时磁盘上有一份原始的fsimage文件和一份checkpoint文件:fsimage.ckpt。同时edits文件为空。
第三步:写完checkpoint后,将fsimage.ckpt改名为fsimage(覆盖原有的fsimage),并将最新时间戳写入fstime文件
DataNode的作用:
保存block
启动DataNode线程的时候会向NameNode汇报block信息
通过向NameNode发送心跳保持与其联系(3秒一次),如果NameNode10分钟没有收到DataNode的心跳,则认为其已经lost,并copy其上的block到其它DataNode
DataNode的文件结构(图示引用书籍:Hadoop实战):
Blk_refix:HDFS中的文件数据块,存储的是原始文件内容
Blk_refix.meta:块的元数据文件:包括版本和类型信息的头文件,与一系列块的的区域校验和组成。
VERSION:文本文件,文件的内容为:
其中NamesopaceID、cTime、layoutVersion与NameNode保持一致,namespaceID是第一次连接NameNode获得的。storageType对于DataNode来说是唯一的,用于NameNode表示DataNode。
DataNode启动过程
datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenode
namenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。
为了提高NameNode的可靠性,从Hadoop 0.23开始引入了Secondary NameNode。
Secondary NameNode的作用
Fsimage是HDFS存储元数据的文件,它不会在HDFS的每次文件操作(如打开、查询、创建、修改文件)后进行更新。而HDFS的每一次文件操作会增加一条edits记录。这样会出现edits记录不断增加的情况。
这种设计不影响系统的恢复能力。因为如果Namenode失败了,元数据的最新状态可以通过从磁盘中读出fsimage文件加载到内存中来进行重新恢复,然后重新执行edits记录中的操作,这也正是NameNode重新启动时所做的事情。但是如果edits记录很多,NameNode启动时会花很长的时间来运行edits记录中的操作。在此期间,HDFS文件系统是不可用的。
为了解决这个问题,Hadoop在NameNode之外的节点上运行了一个Secondary NameNode进程。Secondary NameNode定期从NameNode拷贝fsimage和edits记录到临时目录并合并成一个新的Fsimage,随后它将新的fsimage上传到NameNode,这样NameNode便会更新fsimage并删除原来的编辑日志。这个过程叫checkpoint。具体过程如下:
说明:
第一步:Secondary NameNode首先请求NameNode进行edits的滚动,这样NameNode开始重新写一个新的edit log
第二步:Secondary NameNode通过HTTP方式读取NameNode中的fsimage及edits
第三步:Secondary NameNode读取fsimage到内存中,然后执行edits中的每个操作,并创建一个新的统一的fsimage文件。
第四步:Secondary NameNode通过HTTP方式将新的fsimage发送到NameNode
第五步:NameNode用新的fsimage替换旧的fsimage,旧的edits文件用步骤1中的edits进行替换,同时系统会更新fsimage文件记录检查点时间
Secondary NameNode的文件结构(图示引用书籍:Hadoop实战):
Secondary NameNode不足之处:
因为Secondary namenode并不是实时进行checkpoint,所以当还没有进行下一次checkpoint的时候namenode出现了硬件故障同时又没有通过NFS存储元数据,那么Namenode中自上次checkpoint之后到故障发生期间的所有edits文件将丢失。因为此时secondary namenode存的只有上一次的fsimage文件,没有最新的edits文件,无法通过secondary namenode进行这段时间内的数据恢复。
Secondary NameNode不是NameNode的备份进程,如果NameNode宕机了,而SecondaryNameNode没有宕机,集群照样不能正常工作。如果要恢复集群工作,需要手动将Secondary NameNode上的fsimage文件拷贝到新的NameNode上面。
为了解决以上问题,从Hadoop2.0开始,引入了高可用HA NameNode
标签:hadoop、大数据
原文地址:http://bobbleyan.blog.51cto.com/9111528/1544151