- HDFS百度百科
- HDFS是个分布式文件系统,用来存储文件,通过目录树定位文件,由多台服务器联合实现HDFS的功能,适合一次写入多次读出的场景,不支持文件修改.
- HDFS的优缺点
3.1 优点
3.1.1 高容错性
数据保存多个副本,提高容错性,某个副本丢失后,会自动恢复
3.1.2 大数据处理
能够处理数据量达到GB,TB,PB级别的数据,能够处理百万规模的文件量
3.1.3 成本低
可以搭建在廉价的机器上,通过多副本机制,提高可靠性
3.2 缺点
3.2.1 不适合低延时的数据访问,比如毫秒级的存储数据
3.2.2 无法高效的对大量小文件进行存储,小文件数量过多的话,会占用NameNode大量的内存来存储文件的元数据,而且小文件存储的寻址时间会超过读取时间,违反了HDFS的设计目标
3.2.3 不支持并发写入,文件随机修改,一个文件只能有一个写,不允许多个线程同时写,仅支持数据追加,不支持文件的随机修改 - HDFS组成
1) NameNode
管理HDFS的空间,配置副本策略,管理数据块(block)映射信息,处理客户端读写请求
2) DataNode
存储实际的数据块,执行数据块的读写操作
3) 客户端
① 文件切分,文件上传HDFS的时候,client将文件切分成一个个的block,然后进行上传
② 和NameNode进行交互,获取文件的位置信息
③ 和DataNode进行交互,读取或者写入数据
④ client提供一些命令来管理HDFS,例如NameNode的格式化
⑤ client 可以通过一些命令来访问HDFS,对HDFS进行增删改查等操作
4) SecondaryNameNode
辅助NameNode,分担其工作量,定期合并FSimage 和Edits ,并推送给NameNode,紧急情况下,可以辅助恢复NameNode - HDFS文件块
HDFS中的文件在物理上是分块存储,块的大小可以通过配置参数dfs.blocksize来设定,默认大小在Hadoop2.x中是128M,老版本中是64M
当寻址时间为传输时间1%时,为最佳状态,当HDFS的块大小设置太小的时候,会增加寻址时间,程序一直在找块的开始位置,如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置需要的时间,导致程序在处理数据的时候,效率低下.设置合理的块大小主要取决于磁盘传输效率 - HDFS读写流程
6.1 写数据流程
① 客户端通过Distributed FileSystem模块向NameNode请求上传文件,NameNode检查目标文件是否已存在,父目录是否存在
② NameNode响应是否可以上传
③ 客户端请求上传第一个block,请求返回DataNode
④ NameNode返回DataNode节点
⑤ 客户端通过FSDataOutputStream模块请求dn1上传数据,dn1收到请求会继续调用dn2,然后dn2调用dn3,将这个通信管道建立完成
⑥ dn1,dn2,dn3逐级应答客户端
⑦ 客户端开始往dn1上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,dn1收到一个packet就会传给dn2,dn2传给dn3;dn1每传一个packet会放入一个应答队列等待应答
⑧ 当一个block传输完成后,客户端再次请求NameNode上传第二个block的服务器.(然后循环③-⑧)
6.2 读数据流程
① 客户端通过Distribute FileSystem向NameNode请求下载文件,NameNode通过查询元数据,找到文件块所在的DataNode地址
② 挑选一台DataNode(就近原则)服务器,请求读取数据
③ DataNode开始传输数据给客户端(从磁盘里面读取数据输入流,以packet为单位来做校验)
④ 客户端以packet为单位接收,先在本地缓存,然后写入目标文件 - 机架感知
在HDFS写数据的过程中,NameNode会选择距离待上传数据最近距离的DataNode接收数据,那么这个最近距离怎么计算呢?
节点距离: 两个节点到达最近的共同祖先的距离总和
- NameNode和SecondaryNameNode
① 第一次启动NameNode格式化后,创建Fsimage和Edits文件,如果不是第一次启动,直接加载编辑日志和镜像文件到内存
② 客户端对元数据的增删改请求
③ NameNode记录操作日志,更新滚动日志
④ NameNode在内存中对数据进行增删改
⑤ SecondaryNameNode询问NameNode是否需要checkpoint.直接带回NameNode是否检查结果
⑥ SecondaryNameNode请求执行checkpoint
⑦ NameNode滚动正在写的Edits日志
⑧ 将滚动前的编辑日志和镜像文件拷贝到SecondaryNameNode
⑨ SecondaryNameNode加载编辑日志和镜像文件到内存,然后合并
⑩ 生成了新的镜像文件fsimage.chkpoint
⑪ 拷贝fsimage.chkpoint 到NameNode
⑫ NameNode将fsimage.chkpoint 重新命名成fsimage
详细信息:
fsimage: NameNode内存中元数据序列化后形成的文件
Edits: 记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)
NameNode启动时,先滚动Edits并生成一个空的edits.inprogress,然后加载Edits和Fsimage到内存中,此时NameNode内存就持有最新的元数据信息,client开始对NameNode发送元数据的增删改请求,这些请求的操作首先会被记录到edits.inprogress中,如果此时NameNode挂掉,重启后会从Edits中读取元数据信息,然后NameNode会在内存中执行元数据的增删改操作.
由于Edits中记录的操作会越来越多,Edits文件会越来越大,导致NameNode在启动加载Edits时会很慢,所以需要对Edits和fsimage进行合并(所谓合并,就是将Edits和fsimage加载到内存中,按照edits中的操作一步步执行,最终形成新的fsimage).
SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作.
SecondaryNameNode首先会询问NameNode是否需要CheckPoint(触发CheckPoint需要满足两个条件中的任意一个,定时时间到了和edits中的数据写满了).直接带回NameNode是否检查的结果.SecondaryNameNode执行CheckPoint操作,首先会让NameNode先滚动Edits并生成一个空的edits.inprogress,滚动edits 的目的是给edits打个标记,以后所有的操作都写入edits.inprogress,其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地,然后将拷贝的Edits和Fsimage加载到内存中进行合并,生成fsimage.chkpoint,然后将fsimage.chkpoint 拷贝给NameNode,重命名为Fsimage后替换掉原来的fsimage.NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可,因为合并过的Edits中的元数据信息已经被记录在Fsimage中.
Fsimage文件: HDFS文件系统元数据的一个永久的检查点,其中包括HDFS文件系统的所有目录和文件inode的序列化信息.
Edits文件: 存放HDFS 文件系统的所有更新操作的路径,文件系统客户端的所有写操作首先会被记录到Edits文件中
seen_txid文件保存的是个数字,就是最后一个edits_的数字
每次NameNode启动的时候都会将fsimage文件读入内存,加载edits里面的更新操作,保证内存中的元数据信息是最新的,同步的,可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并
-
DataNode的工作机制
① 一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳
② DataNode启动后向NameNode注册,通过后,周期性的向NameNode上报所有的块信息
③ 心跳是3s一个,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块,如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用
④ 集群运行中可以安全加入和退出一些机器 -
数据完整性
DataNode节点保证数据完整性的方法
① 当DataNode读取block的时候,它会计算checkSum
② 如果计算后的checksum,与block创建时值不一样,说明block已经损坏
③ client 读取其他DataNode上的block
④ DataNode在其文件创建后周期验证CheckSum
-
小文件归档
① HDFS存储小文件
每个文件均按块存储,每个块的元数据存储在NameNode的内存中,因此HDFS存储小文件会非常低效,因为大量的小文件会耗尽NameNode中的大部分内存.
② 解决方法之一
HDFS存档文件或HAR文件,是一个更高效的文件存档工具,它将文件存入HDFS块,在减少NameNode内存使用的同时,允许对文件进行透明的访问,具体说来,HDFS存档文件对内还是一个个的独立文件,对NameNode而言却是一个整体,减少了NameNode的内存 -
回收站
开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除,备份等作用
-
HA(High Available)
实现hadoop集群的高可用关键的策略是消除单点故障,分为HDFS的HA和yarn的HA,HDFS的高可用通过配置Active/Standby两个NameNode实现在集群中对NameNode的热备.
HDFS-HA
① 元数据管理方式需要变化,内存中各保存一份元数据,Edits日志只有Active状态下的NameNode可以写操作,两个NameNode都可以读取Edits,共享的Edits放在一个共享存储中管理
② 需要一个动态管理功能,实现了一个zkfailover,常驻在每一个namenode所在的节点,每个zkfailover负责监控自己所在NameNode节点,利用zk进行状态标识,当需要进行状态切换时,由zkfailover负责切换
③ 两个NameNode之间必须保证ssh免密登录
④ 同一时刻仅仅有一个NameNode对外提供服务
故障转移:
zookeeper是维护少量协调数据,通知客户端这些数据的改变和监控客户端故障的高可用服务.HA的自动故障转移依赖于zookeeper.
集群中的每个NameNode在zookeeper中维护了一个持久会话,如果机器崩溃,zookeeper中的会话将终止,zookeeper通知另一个NameNode需要触发故障转移. zookeeper唯一选择一个节点为active.
ZKFC是故障转移中的另一个组件,是zookeeper的客户端,也监视和管理NameNode的状态,每个运行NameNode的主机也运行了一个ZKFC进程.
ZKFC使用一个健康检查命令定期的ping与之在相同主机的NameNode,只要该NameNode及时的回复健康状态,ZKFC认为该节点是安全的.当NameNode是健康的,ZKFC保持一个在zookeeper中打开的会话,如果本地NameNode处于active,ZKFC也保持一个特殊的znode锁,该锁使用了zookeeper对短暂节点的支持,如果会话终止,锁节点将自动删除.如果本地NameNode是健康的,且ZKFC没有发现其他节点持有znode锁,它将自己获取该锁,如果成功了,则运行故障转移进程使他的本地NameNode为active.
Yarn-HA
官网文档
ResourceManager HA通过Active / Standby架构实现在任何时间，RM之一都是Active，并且一个或多个RM处于Standby模式，等待Active发生故障。启用自动故障转移后，转换为活动状态的触发来自管理员（通过CLI）或集成的故障转移控制器。
手动转换和故障转移
如果未启用自动故障转移，则管理员必须手动将其中一个RM过渡到活动状态。为了从一个RM到另一个RM进行故障转移，他们应该先将Active-RM转换为Standby，然后将Standby-RM转换为Active。所有这些都可以使用“ yarn rmadmin” CLI完成。
自动故障转移
RM可以选择嵌入基于Zookeeper的ActiveStandbyElector，以确定哪个RM应该是Active。当Active发生故障或无响应时，另一个RM将自动选作Active，然后接管。请注意，无需像HDFS那样运行ZKFC守护程序，因为嵌入在RM中的ActiveStandbyElector充当故障检测器和leader选举者，而不是ZKFC守护进程。
RM故障转移上的客户端，ApplicationMaster和NodeManager
当有多个RM时，客户端和节点使用的配置（yarn-site.xml）会列出所有RM。客户端，ApplicationMaster（AM）和NodeManager（NM）尝试以循环方式连接到RM，直到它们到达活动RM。如果Active发生故障，他们将继续轮询轮询，直到命中“新” Active。此默认重试逻辑实现为org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider。您可以通过实现org.apache.hadoop.yarn.client.RMFailoverProxyProvider并将yarn.client.failover-proxy-provider的值设置为类名来覆盖逻辑。