标签:blog 访问时间 没有 secondary 可靠 错误 下载到本地 方便 api
分布式文件系统由计算机集群中的多个节点构成,这些节点分为两类:
主节点(MasterNode)或者名称节点(NameNode)
从节点(Slave Node)或者数据节点(DataNode)
兼容廉价的硬件设备
流数据读写
大数据集
简单的文件模型
强大的跨平台兼容性
不适合低延迟数据访问
无法高效存储大量小文件
不支持多用户写入节任意修改文件
HDFS默认一个块64MB,一个文件被分成多个块,以块为存储单位,2.x新版本中是128MB
块的大小远大于普通文件系统,可以最小化寻找开销
HDFS采用抽象的块概念可以带来一下几个明显的好处:
支持大规模文件存储:文件以块为单位进行存储,一个大规模文件可以被分拆成若干各文件块,不同文件块被分发到不同节点,因此,一个文件的大小不会受到单个节点存储容量限制,可以远大于网络中任意节点的存储容量
简化系统设计:简化了存储管理,因为文件块大小固定,这样可以非常容易算出一个几点可以存储多少块,其次方便了元数据的管理,元数不需要和文件块一起存储,可以由其他系统负载管理元数据
适合数据备份:每个文件块都可以冗余存储到多个节点上,提高了系统容错和可用性
名称节点负责管理分布式文件系统的命令空间(Namespace),保存了两个核心的数据结构,即Fslmage和EditLog
Fslmage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
名称节点记录了每个文件中个板块所在的数据节点的位置信息
Fslmage文件包含文件系统中所有目录和文件inode的序列化形式,每个inode是一个文件或目录的元数据内部表示,并包含此类信息:文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录,则存储修改时间、权限和配额元数据
Fslmage文件没有记录块存储在哪个数据节点。而是由名称节点把这些映射保留在内存中,当数据节点加入HDFS集群时,数据节点会把自己所包含的块列表告知给名称节点,此后会定期执行这种告知操作,以确保名称节点的块映射时最新的
1)启动名称节点---》将FsImage文件---》加载到内存---》执行EditLog---》同步---》内存中的元数据客户可读
2)内存与元数据映射完成---》创建新的Fslmage文件+空的Editlog文件
说明:名称节点起来后,HDFS中的更新操作会重新写到Editlog文件中,因为Fslmage文件一般都很大(GB级别的很常见),如果所有的更新操作都往Fslmage文件中添加,这样会导致系统运行的十分缓慢,但是,如果往EditLog文件里面写就不会这样,因为EditLog要小很多,每次执行写操作之后,且在向客户端发送成功代码之前,edits文件都需要同步更新
运行期间HDFS的所有操作---》写到EditLog---》时间(久而久之)---》EditLog文件将变得非常大
对运行中HDFS影响不大,但是一旦重启Fslmage里面的所有内容映像到内存中,然后在一条一条执行EditLog,当EditLog文件非常大的时,就会导致名称节点启动非常缓慢,并且此期间是安全模式,无法提供写操作,影响用户使用
解决此问题就需要SecondaryNameNode第二名称节点
1)它用来保存名称节点中对HDFS元数据信息的备份,并减去名称节点重启的时间,一般是单独运行在一台机器上
2)SecondaryNameNode工作情况
1、SecondaryNameNode定期于NameNode通信,请求停止使用EditLog文件,暂时将新的写操作写到要给新的文件edit.new,此操作瞬间完成,上层写日志函数感觉不到差别
2、SecondaryNameNode通过HTTP GEt从NameNode上获取FsImage/EditLog文件下载到本地的相应目录下
3、SecondaryNameNode将下载的Fslmage载入内存然后一条条执行EditLog中的操作,使得内存中的Fslmage保持最新,这个就是EditLog和FsImage文件合并
4、SecondaryNameNode执行完合并会通过post方式将新的FsImage文件发送到NameNode节点
5、NameNode将从SecondaryNameNode接收到的新的FsImage替换就的FsImage文件,同时将edit.new替换EditLog文件,这时EditLog就变小了
数据分布在各节点,数据节点负责数据的存储和读取,会根据客户端或名称节点的调度进行数据的存储和检索,并且向名称节点定期发送所存储的块的列表
HDFS采用了主从(M/S)结构模型,名称节点作为中心服务器,管理文件系统的命名空间即客户端文件的访问。数据节点负责进行客户端的读/写请求,在名称节点的调度吓进行数据的创建、删除、复制操作
HDFS的命名空间包含目录、文件、块
HDFS使用传统的分级文件体系,因此,可以像使用普通文件系统一样,创建/删除目录和文件,及在目录间转移重命名等
HDFS通信协议都是构建在TCP/IP协议基础之上
客户端通过一个可配置端口向名称节点发起tcp链接,并使用客户端协议与名称节点进行交互
名称节点和数据节点间使用数据节点协议进行交互
客户端与数据节点的交互是通过RPC(Remote Procedure Call)来实现的。在设计上,名称节点不会主动发起RPC,而是响应来自客户端和数据节点的RPC请求
客户端就是用户操作HDFS的方式,HDFS在部署时都提供了客户端
HDFS客户端时一个库,包括HDFS文件系接口,这些接口隐藏了HDFS实现中的大部分复杂性
严格来说客户端并不是HDFS的一部分
客户端支持打开、读写、写入等常见的操作,并且提供了类似shell的命令行方式来访问HDFS中的数据
HDFS也提供了Java API,作为应用程序访问文件系统的客户端编程接口
HDFS只设置了一个名称节点,这样做的好处时简化系统设计,但是也带了局限性:
1)命名空间的限制:名称节点时保持在内存中,因此名称节点能够容纳对象(文件、块)的个数会收到内存大小限制
2)性能瓶颈:整个分布式文件系统的吞吐量,受限单个名称节点的吞吐量
3)隔离问题:由于集群中只有一个名称节点,只有一个命名空间,因此,无法对不同应用程序进行隔离
4)集群的可用性:一旦唯一的名称节点发送故障,整个集群不可用
HDFS采用了多副本方式对数据进行冗余,多副本方式优点:
1)加快数据传输速度
2)容易检查数据错误
3)保证数据可靠性
1)数据存放
第一个副本:放在上传文件的数据节点,如果集群外提交,随机选一台磁盘不太满、cpu不太忙的节点
第二个副本:放置在与第一个副本不同的机架的节点上
第三个副本:与第一个副本相同机架的其他节点上
更多副本:随机
hdfs提供了一个API可以确定一个数据节点所属的机架ID,客户端也可以调用API获取自己所属机架ID
当客户端读取数据时,名称节点获得数据块不同的位置列表,列表中包含了副本所在数据节点,发现某个数据数据库副本对应的机架ID和客户端对应机架ID相同,就优先选择该副本读取数据,如没有就随机读取
HDFS具有较高的容错性,可以兼容廉价硬件,它把依你高见出错看作一种常态,还有机制检测数据错误和自动恢复,容错性主要由名称节点出错、数据节点出错、数据出错。
1)名称节点出错
回顾:Fslmage,Editlog
如果整个两个文件损坏,那么HDFS实例将失效
hdfs提供SecondaryNameNode,将会备份这两个文件,在必要的时候Fslmage,Editlog数据进行恢复
2)数据节点出错
心跳信息定期向名称节点报告自己状态,如果出问题,就会被标记为宕机,节点上的数据被标记不可读,名称节点将不会给他们发送任何I/O请求
如出现问题,一些数据节点不可用可能会导致一些数据库副本数量小于冗余因子,名称节点会定期进行检测,一旦发生这种情况会启动数据冗余复制,为它生成新的副本
HDFS和其他分布式文件系统最大的区别就是可以调整冗余数据位置
3)数据出错
由网络磁盘等错误的因素都会导致数据错误,客户端读取到数据后都会进行md5/sha1对数据进行校验,以确定读取到正确的数据
在创建文件时,客户端会对每个文件进行信息摘录,并把这些信息写入到一个路径的隐藏文件
客户端读取文件时,先读取信息摘录,然后利用该信息进行校验,如果出错,客户端就会请求到另外的节点读取,并向名称节点报告,名称节点会定期检测并且重新复制
简单流程就是:打开文件--》获取数据块信息--》读取请求--》读取数据--》获取数据块信息--》读取数据--》关闭文件
简单流程:创建文件--》创建文件元数据--》写入数据--》--》写入数据包--》接收确认包--》关闭文件--》写操作完成
完全参考学习:http://dblab.xmu.edu.cn/blog/290-2/
标签:blog 访问时间 没有 secondary 可靠 错误 下载到本地 方便 api
原文地址:https://www.cnblogs.com/zhangxingeng/p/11819418.html