以文件为基本存储单位的缺点
1、文件大小不同,难以实现负载均衡。
2、处理一个文件时,只能利用一个节点资源,无法动用集群。
源自于Google的GFS论文
发表于2003年10月
HDFS是GFS克隆版
Hadoop Distributed File System
易于扩展的分布式文件系统
运行在大量普通廉价机器上,提供容错机制
为大量用户提供性能不错的文件存取服务
优点:
1)高容错性
?数据自动保存多个副本
?副本丢失后,自动恢复
2)适合批处理
?移动计算而非数据
?数据位置暴露给计算框架
3)适合大数据处理
?GB、TB、甚至PB级数据
?百万规模以上的文件数量
?10K+节点规模
4)流式文件访问
?一次性写入,多次读取
?保证数据一致性
5)可构建在廉价机器上
?通过多副本提高可靠性
?提供了容错和恢复机制
不擅长:
1)低延迟与高吞吐率的数据访问 ,比如毫秒级
2)小文件存取
?占用NameNode大量内存
?寻道时间超过读取时间
3)并发写入、文件随机修改
?一个文件同一个时间只能有一个写者
?仅支持append ()
Client:切分文件;访问或通过命令行管理HDFS;与NameNode交互,获取文件位置信息;与DataNode交互,读取和写入数据。
NameNode:Master节点,只有一个,管理HDFS的名称空间和数据块映射信息;配置副本策略;处理客户端请求。
DataNode:Slave节点,存储实际的数据;执行数据块的读写;汇报存储信息给NameNode。
Secondary NameNode:辅助NameNode,分担其工作量;定期合并fsimage和fsedits,推送给NameNode;紧急情况下,可辅助恢复NameNode,但Secondary NameNode并非NameNode的热备。
fsimage和fsedits
NameNode中两个很重要的文件,
fsimage是元数据镜像文件(保存文件系统的目录树)。
edits是元数据操作日志(记录每次保存fsimage之后到下次保存之间的所有hdfs操作)。
内存中保存了最新的元数据信息(fsimage和edits)。
edits过大会导致NameNode重启速度慢,Secondary NameNode负责定期合并它们。
合并的流程图:
数据块的映射关系
1)包括两种:文件与数据块映射关系,DataNode与数据块映射关系;
2)NameNode启动的时候,可通过心跳信息重构映射信息,DataNode运行过程中定时汇报当前block信息;映射关系保存在NameNode内存中。
3)NameNode重启速度慢(需要加载通过合并fsimage与edits文件生成的最新目录树以及DataNode的块信息)
数据块(block)
1)在HDFS中,文件被切分成固定大小的数据块,默认大小为64MB,也可自己配置。
2)为何数据块如此大,因为数据传输时间超过寻道时间(高吞吐率)。
3)文件的存储方式:按大小被切分成若干个block,存储到不同节点上,默认情况下每个block有三个副本。
对于block块的恢复详细信息可以查看如下blog
http://blog.csdn.net/macyang/article/details/7983188
数据存储细节
NameNode 目录结构
${ dfs.name.dir}/current /VERSION
/edits
/fsimage
/fstime
dfs.name.dir 是 hdfs-site.xml 里配置的若干个目录组成的列表。
NameNode
Namenode 上保存着 HDFS 的名字空间。对于任何对文件系统元数据产生修改的操作, Namenode
都会使用一种称为 EditLog 的事务日志记录下来。例如,在 HDFS 中创建一个文件, Namenode 就会在 Editlog
中插入一条记录来表示;同样地,修改文件的副本系数也将往 Editlog 插入一条记录。 Namenode 在本地操作系统的文件系统中存储这个
Editlog 。整个文件系统的名 字空间,包括数据块到文件的映射、文件的属性等,都存储在一个称为 FsImage 的文件中,这 个文件也是放在
Namenode 所在的本地文件系统上。
Namenode 在内存中保存着整个文件系统的名字空间和文件数据块映射 (Blockmap) 的映像
。这个关键的元数据结构设计得很紧凑,因而一个有 4G 内存的 Namenode 足够支撑大量的文件 和目录。当 Namenode
启动时,它从硬盘中读取 Editlog 和 FsImage ,将所有 Editlog 中的事务作 用在内存中的 FsImage
上,并将这个新版本的 FsImage 从内存中保存到本地磁盘上,然后删除 旧的 Editlog ,因为这个旧的 Editlog
的事务都已经作用在 FsImage 上了。这个过程称为一个检查 点 (checkpoint) 。在当前实现中,检查点只发生在 Namenode
启动时,在不久的将来将实现支持 周期性的检查点。
HDFS的默认副本存放策略
Hadoop 0.17 之后:副本1-同Client的节点上;副本2-不同机架中的节点上;副本3-同第二个副本的机架中的另一个节点上;其他副本:随机挑选。如下图示例:
常见错误情况:文件损坏;网络或者机器失效;NameNode挂掉;
文件的完整性:通过CRC32校验,如果有损坏,用其他副本替代损坏文件;
Heartbeat:DataNode定期向NameNode发送eartbeat;
元数据信息:FsImage、Editlog进行多份备份,当NameNode宕机后,可手动还原。
这个网站很详细很好:
HDFS文件读取:
1.首先调用FileSystem对象的open方法,其实是一个DistributedFileSystem的实例
2.DistributedFileSystem通过rpc获得文件的第一批个block的locations,同一block按照重复数会返回多个locations,这些locations按照hadoop拓扑结构排序,距离客户端近的排在前面.
3.前两步会返回一个FSDataInputStream对象,该对象会被封装成
DFSInputStream对象,DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方
法,DFSInputStream最会找出离客户端最近的datanode并连接。
4.数据从datanode源源不断的流向客户端。
5.如果第一块的数据读完了,就会关闭指向第一块的datanode连接,接着读取下一块。这些操作对客户端来说是透明的,客户端的角度看来只是读一个持续不断的流。
6.如果第一批block都读完了,DFSInputStream就会去namenode拿下一批blocks的location,然后继续读,如果所有的块都读完,这时就会关闭掉所有的流。
HDFS读取发生异常处理
如果在读数据的时候,DFSInputStream和datanode的通讯发生异常,就会尝试正在读的block的排第二近的datanode,并且
会记录哪个datanode发生错误,剩余的blocks读的时候就会直接跳过该datanode。DFSInputStream也会检查block数据
校验和,如果发现一个坏的block,就会先报告到namenode节点,然后DFSInputStream在其他的datanode上读该block的
镜像
HDFS读操作设计思考
客户端直接连接datanode来检索数据并且namenode来负责为每一个block提供最优的datanode,namenode仅仅处理
block location的请求,这些信息都加载在namenode的内存中,hdfs通过datanode集群可以承受大量客户端的并发访问。
HDFS文件写入
1.客户端通过调用DistributedFileSystem的create方法创建新文件
2.DistributedFileSystem通过RPC调用namenode去创建一个
没有blocks关联的新文件,创建前,namenode会做各种校验,比如文件是否存在,客户端有无权限去创建等。如果校验通过,namenode就会
记录下新文件,否则就会抛出IO异常.
3.前两步结束后会返回FSDataOutputStream的对象,和读文件的时候相
似,FSDataOutputStream被封装成DFSOutputStream,DFSOutputStream可以协调namenode和
datanode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet,然后排成队列
data quene。
4.DataStreamer会去处理接受data
quene,他先问询namenode这个新的block最适合存储的在哪几个datanode里,比如重复数是3,那么就找到3个最适合的
datanode,把他们排成一个pipeline.DataStreamer把packet按队列输出到管道的第一个datanode中,第一个
datanode又把packet输出到第二个datanode中,以此类推。
5.DFSOutputStream还有一个对列叫ack quene,也是有packet组成,等待datanode的收到响应,当pipeline中的所有datanode都表示已经收到的时候,这时akc quene才会把对应的packet包移除掉。
6.客户端完成写数据后调用close方法关闭写入流
7.DataStreamer把剩余得包都刷到pipeline里然后等待ack信息,收到最后一个ack后,通知datanode把文件标示为已完成。
HDFS文件写入失败
如果在写的过程中某个datanode发生错误,会采取以下几步:
1.pipeline被关闭
2.为了防止防止丢包ack quene里的packet会同步到data quene
3.把产生错误的datanode上当前在写但未完成的block删
4.block剩下的部分被写到剩下的两个正常的datanode
5.namenode找到另外的datanode去创建这个块的复
这些操作对客户端来说是无感知的。
(客户端执行write操作后,写完得block才是可见的,正在写的block对客户端是不可见的,只有调用sync方法,客户端才确保该文件被写操
作已经全部完成,当客户端调用close方法时会默认调用sync方法。是否需要手动调用取决你根据程序需要在数据健壮性和吞吐率之间的权衡。)
注:此部分笔记来源于:
1)HDFS与MapReduce结合
MapReduce作业的输入数据来自HDFS,最终结果也写入HDFS
Mapreduce和HDFS是低耦合的,Mapreduce可以与其他分布式系统结合。HDFS之上可以是其他框架。
2)HDFS与Hbase结合
HDFS为Hbase提供可靠的数据存放服务(操作日志文件WAL和数据索引文件HFile等)
转载自:
http://blog.csdn.net/woshiwanxin102213/article/details/19990487
阅读(2390) | 评论(0) | 转发(0) |