其他分享
首页 > 其他分享> > HDP1: HDFS架构

HDP1: HDFS架构

作者:互联网

学习目标:高可用、单机元数据内存受限、源码设计

一、HDFS架构演进

1、Hadoop的三个版本:对应的三个HDFS版本

​ Hadoop1、2、3

​ HDFS 1、2、3

Hadoop1重点解决的两上问题:

  1. 海量数据如何存储
  2. 海量数据如何进行计算

2、HDFS1.0的架构:

​ HDFS1是一个主从式架构,主节点只有一个NameNode,从节点有多个叫DataNode

​ NameNode:

​ 1、管理元数据信息(文件目录树):文件与Block块,Block块与DataNode主机的关系

​ 2、NameNode为了快速响应用户的操作请求,所以所元数据加载到了内存里面

​ DataNode:

​ 1、存储数据,把上传的数据划分成为固定大小的文件块(Hadoop1默认是64MB)

​ 2、为了保证数据的安全,每个文件块默认都有三个副本

3、HDFS2:解决上一架构的缺陷:单节点故障、内存受限

3.1 单点故障:主备自动切换

解决方案图:ANN与SNN自动切换图:(也是在HDFS2解决的问题)

​ 同一时间只有一个ANN在服务,与SNN进行切换时需要实现自动切换,即ZooKeeper,在每个NN上安装一个ZKFC来监控每个NN的健康状况,下图中的绿色方块即ZK实现的一个锁机制,即只有ANN可以进,如果ANN出问题,则将此锁给SNN,并将SNN转换为ANN,实现了自动切换(在实际生产中,有些企业是不用JournalNode,而是直接改源码使用ZooKeeper来代替JournalNode进行存储解决单点故障问题)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CksXVn9m-1608650765428)(/Users/ryan/大数据/大数据架构师/img/image-20201222215138780.png)]

JournalNode是在MR2也就是Yarn中新加的,journalNode的作用是存放EditLog,同步元数据

在MR1中editlog是和fsimage存放在一起的然后SecondNamenode做定期合并,Yarn在这上面就不用SecondNamanode了

配置文件是;hdfs-site.xml文件负责

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ruOjbAck-1608650765431)(/Users/ryan/大数据/大数据架构师/img/1353331-20191008160147206-1234947374.png)]

​ Active Namenode与StandBy Namenode之间的就是JournalNode,作用相当于NFS共享文件系统.Active Namenode往里写editlog数据,StandBy再从里面读取数据进行同步.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uB6lYhh0-1608650765434)(/Users/ryan/大数据/大数据架构师/img/1353331-20191008155625658-149426410.png)]

​ 两个NameNode为了数据同步,会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时,会告知大部分的JournalNodes进程。

​ standby状态的NameNode有能力读取JNs中的变更信息,并且一直监控edit log的变化,把变化应用于自己的命名空间。standby可以确保在集群出错时,命名空间状态已经完全同步了。

一般200个节点以内,JournalNode3个就够了,如果是2000个以内5个即可。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UlLoSqMe-1608650765436)(/Users/ryan/大数据/大数据架构师/img/1353331-20191008160409794-1622483165.png)]

如何做到两个NameNode?如何保证两个之间元数据一致性问题?

3.1.2 QJM写过程分析(超级重要:这个是解决可靠性也服务性能的关键——分段加锁与双缓冲方案)

​ 上面提到EditLog,NameNode会把EditLog同时写到本地和JournalNode。写本地由配置中参数dfs.namenode.name.dir控制,写JN由参数dfs.namenode.shared.edits.dir控制,在写EditLog时会由两个不同的输出流来控制日志的写过程,分别为:EditLogFileOutputStream(本地输出流)和QuorumOutputStream(JN输出流)。写EditLog也不是直接写到磁盘中,为保证高吞吐,NameNode会分别为EditLogFileOutputStream和QuorumOutputStream定义两个同等大小的Buffer,大小大概是512KB,一个写Buffer(buffCurrent),一个同步Buffer(buffReady),这样可以一边写一边同步,所以EditLog是一个异步写过程,同时也是一个批量同步的过程,避免每写一笔就同步一次日志

这个是怎么实现边写边同步的呢,这中间其实是有一个缓冲区交换的过程,即bufferCurrent和buffReady在达到条件时会触发交换,如bufferCurrent在达到阈值同时bufferReady的数据又同步完时,bufferReady数据会清空,同时会将bufferCurrent指针指向bufferReady以满足继续写,另外会将bufferReady指针指向bufferCurrent以提供继续同步EditLog。上面过程用流程图就是表示如下:

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bFBUUdaL-1608650765442)(/Users/ryan/大数据/大数据架构师/img/1508123437957_9118_1508123462816.png)]

3.1.3 两个问题(数据可靠性与一致性如何保证):

1)、既然EditLog是异步写的,怎么保证缓存中的数据不丢呢?

​ 这里虽然是异步,但实际所有日志都需要通过logSync同步成功后才会给client返回成功码,假设某一时刻NameNode不可用了,其内存中的数据其实是未同步成功的,所以client会认为这部分数据未写成功。

2)、EditLog怎么在多个JN上保持一致的呢?

2.1).隔离双写:

​ 在ActiveNameNode每次同步EditLog到JN时,先要保证不会有两个NN同时向JN同步日志。这个隔离是怎么做的。这里面涉及一个很重要的概念Epoch(时期) Numbers,很多分布式系统都会用到。Epoch有如下几个特性:

QJM是怎么保证上面特性的呢,主要有以下几点:具体步骤

3.2 内存受限:HDFS联邦

​ HDFS为了快速响应客户请求,它会把元数据状态存储在内存中,以实现快速响应。

一般用到联邦是在节点超过1000台以上,即将NN设置为多组,类似于C盘,D盘,E盘方案,可以通过联邦实现多组ANN同时使用,当客户进行访问时就可以指定元数据存储的位置,和DN没有任何关系。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gu98kVTY-1608650765448)(/Users/ryan/大数据/大数据架构师/img/image-20201222215431315.png)]

联邦即引入了NameSpace,原先单NameNode只有Block块组成,使用联邦后由namespace(命名空间)和Block Storage(块的存储)两层,由目录、文件、块组成。采用联邦后解决了内存受限问题,但还是存在单节点故障,所以每组下面都会有一个ANN和SNN组成。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yp0B67CR-1608650765451)(/Users/ryan/大数据/大数据架构师/img/70.png)]

当用户存储文件时需要存到某组NN中时,采用"文件名hash"的方法,这些文件可能会被放到不同的namespace中,为了方便管理多个命名空间,HDFS Federation采用了经典的Client Side Mount Table

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W7G1UVcy-1608650765454)(/Users/ryan/大数据/大数据架构师/img/image-20201222225236409.png)]

4、HDFS3架构:支持多NN

​ HA方案支持多个Namenode,引入纠删码技术。

二、亿级流量支撑——分段加锁与双缓冲方案

思考:

NN管理着元数据,用户所有的操作请求都要操作NN,大一点的平台一天需要运行几十万,上百万的任务。一个任务就会有很多的请求,这些所有的请求都会在NN这儿(更新目录树),对于NN来说这就是亿级的流量,NN是如何支撑亿级流量的呢?

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hJdZGLU0-1608650765458)(/Users/ryan/大数据/大数据架构师/img/image-20201222231538451.png)]

为了保证数据的安全,必须将内存中的数据写到磁盘上,记录日志,为了解决磁盘IO瓶颈,引入:分段加锁和双缓冲的方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9vBdpxE8-1608650765461)(/Users/ryan/大数据/大数据架构师/img/image-20201222231816464.png)]

​ 使用内存缓冲:CurrentBuffer响应客户并发请求,到一定闽值时进行内存交换,交给SyncBuffer进行溢写磁盘,与Kafka的原理一样。

标签:HDFS,架构,EditLog,img,ANN,JN,HDP1,日志,数据
来源: https://blog.csdn.net/qq_36269641/article/details/111569491