大数据-hadoop之HDFS

  1. HDFS百度百科
  2. HDFS是个分布式文件系统,用来存储文件,通过目录树定位文件,由多台服务器联合实现HDFS的功能,适合一次写入多次读出的场景,不支持文件修改.
  3. 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 不支持并发写入,文件随机修改,一个文件只能有一个写,不允许多个线程同时写,仅支持数据追加,不支持文件的随机修改
  4. 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
  5. HDFS文件块
    HDFS中的文件在物理上是分块存储,块的大小可以通过配置参数dfs.blocksize来设定,默认大小在Hadoop2.x中是128M,老版本中是64M
    当寻址时间为传输时间1%时,为最佳状态,当HDFS的块大小设置太小的时候,会增加寻址时间,程序一直在找块的开始位置,如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置需要的时间,导致程序在处理数据的时候,效率低下.设置合理的块大小主要取决于磁盘传输效率
  6. 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为单位接收,先在本地缓存,然后写入目标文件
  7. 机架感知
    在HDFS写数据的过程中,NameNode会选择距离待上传数据最近距离的DataNode接收数据,那么这个最近距离怎么计算呢?
    节点距离: 两个节点到达最近的共同祖先的距离总和
    网络拓扑概念
    副本节点选择
  8. 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文件进行了合并

  1. DataNode的工作机制
    在这里插入图片描述
    ① 一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳
    ② DataNode启动后向NameNode注册,通过后,周期性的向NameNode上报所有的块信息
    ③ 心跳是3s一个,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块,如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用
    ④ 集群运行中可以安全加入和退出一些机器

  2. 数据完整性
    DataNode节点保证数据完整性的方法
    ① 当DataNode读取block的时候,它会计算checkSum
    ② 如果计算后的checksum,与block创建时值不一样,说明block已经损坏
    ③ client 读取其他DataNode上的block
    ④ DataNode在其文件创建后周期验证CheckSum
    在这里插入图片描述

  3. 小文件归档
    ① HDFS存储小文件
    每个文件均按块存储,每个块的元数据存储在NameNode的内存中,因此HDFS存储小文件会非常低效,因为大量的小文件会耗尽NameNode中的大部分内存.
    ② 解决方法之一
    HDFS存档文件或HAR文件,是一个更高效的文件存档工具,它将文件存入HDFS块,在减少NameNode内存使用的同时,允许对文件进行透明的访问,具体说来,HDFS存档文件对内还是一个个的独立文件,对NameNode而言却是一个整体,减少了NameNode的内存

  4. 回收站
    开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除,备份等作用
    在这里插入图片描述

  5. 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的值设置为类名来覆盖逻辑。

©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页