HDFS

最新推荐文章于 2023-04-28 16:31:18 发布

卖报的小男孩0716

最新推荐文章于 2023-04-28 16:31:18 发布

阅读量174

点赞数

分类专栏：大数据

本文链接：https://blog.csdn.net/qq_42306104/article/details/85852431

版权

大数据专栏收录该内容

9 篇文章 0 订阅

订阅专栏

概述

Hadoop分布式文件存储系统
HDFS为了保证数据存储的可靠性和读取性能,对数据进行切块后进行复制(保证副本的数量)并存储在集群的多个节点中.

HDFS中存在一个名字节点NameNode和多个数据节点DataNode

HDFS优点

1.支持超大文件
2.检测和快速应对硬件故障
故障检测和自动恢复(心跳机制)是hdfs文件系统的一个设计目标
3.流式数据访问
hdfs的的数据处理规模比较大,应用一次需要访问大量的数据,同时这些应用一般都是批量处理,而不是用户交互式处理.应用程序能以流的形式访问数据集.主要的是数据的吞吐量,而不是访问速度.
4.简化的一致性模型
大部分hdfs操作文件时,需要一次写入,多次读取,在hdfs中,一个文件一旦经过创建,写入,关闭后,一般就不需要修改了,这样简单的一致性模型,有利于提高吞吐量.
5.高容错性
数据自动保存多个副本,副本丢失后自动恢复
6.可构建在廉价机器上
构建在廉价机器上可以轻松的通过扩展机器数量来提高集群存储能力.

HDFS缺点

1.低延迟数据访问
低延迟数据,如和用户进行交互的应用,需要数据在毫秒和秒的范围内得到响应.由于hadoop针对海量数据的吞吐量做了优化,牺牲了获取数据的延迟,所以对于低延迟来说,不适合用hadoop来做.
2.大量的小文件
Hdfs支持超大的文件,是通过数据分布在数据节点.名字节点的内存大小,决定了hdfs文件系统可保存的文件数量
3.多用户写入文件,修改文件
hdfs的文件只呢有一次写入,不支持修改和追加写入(2.0版本支持追加),也不支持修改.只有这样数据的吞吐量才能大.
4.不支持超强的事实
没有像关系型数据库那样,对事务有强有力的支持

大量小文件为什么影响性能? 因为在HDFS中,任何block,文件都是存储在内存中的,大量的小文件会产生大量的元数据严重占用内存

HDFS细节

数据块(Block)
是HDFS中存储文件的最基本的存储单位
Block默认大小为64(128)M,
从2.7.3版本开始，block size由64 MB变成了128 MB。

把超大规模的文件以一个标准切分成几块,分别存储到不同磁盘上,这样做的好处是:
1.文件快可以保存在不同的磁盘上,在HDFS系统中,一个文件可以切分成不同的Block存储在不同的磁盘上
2.简化存储系统,这样不需要管理文件,管理文件块就可以了.
3.有利于数据的复制,在HDFS系统中,一个数据节点一般会复制三份

NameNode
NameNode维护着HDFS中的元数据信息,包括文件和Block之间关系的信息、Block数量信息、Block和DataNode之间的关系信息，NameNode中的元数据信息存储在内存以及文件中，内存中为实时信息，文件中为数据镜像作为持久化存储使用。
文件包括：
fsimage元数据镜像文件，存储某NameNode元数据信息，并不是实时同步内存中的数据
edits：操作日志文件，记录了Namenode所要执行的操作
fstime：保存最近一次checkpoint的时间
当有写请求时，NameNode会首先写editlog到磁盘edits文件中，成功后才会修改内存，并向客户端返回。
所以，fsimage中的数据并不是实时的数据，而是在达到条件时再进行更新，更新过程需要SNN的参与。

SecondaryNameNode
SecondaryNameNode并不是NameNode的热备份，而是协助者帮助NameNode进行元数据的合并，从另外的角度来看可以提供一定的备份功能(不能保证所有的数据都能恢复,只有在数据产生合并的时候才有这种性能)，但并不是热备，这种合并过程可能会造成极端情况下数据丢失！可以从snn中恢复部分数据，但是无法恢复全部。
何时触发数据合并？
根据配置文件设置的时间间隔：fs.checkpoint.period 默认3600秒
根据配置文件设置的edits log大小 fs.checkpoint.size 默认64MB
当Hadoop被重启的时候,也会触发合并
合并过程(参看文档图)：
达到条件后 snn会将nn中的fsimage和edits文件通过网络拷贝过来，同时nn中会创建一个新的edits.new文件，新的读写请求会写入到这个edits.new中，在snn中将拷贝过来的fsimage和edits合并为一个新的fsimage，最后snn将合并完成的fsimage文件拷贝回nn中替换之前的fsimage，nn再将edtis.new改为edits
由于NameNode实时数据都在内存中，此处的合并指的是磁盘中的持久化的数据的处理。
在这里插入图片描述
DataNode
在hadoop中，数据是存放在DataNode上面的。是以Block的形式存储的。
DataNode节点会不断向NameNode节点发送心跳报告。
初始化时，每个数据节点将当前存储的数据块告知NameNode节点。
通过向NameNode主动发送心跳保持与其联系（3秒一次）
后续DataNode节点在工作的过程中，数据节点仍会不断的更新NameNode节点与之对应的元数据信息，并接受来自NameNode节点的指令，创建、移动或者删除本地磁盘上的数据块。
如果10分钟都没收到dn的心跳，则认为其已经lost，并copy其上的block到其他dn
Replication。多复本。默认是三个。

Block复本放置策略： 第一个副本：放置在上传文件的DN，如果是集群之外提交，就随机选择一台磁盘不太满，cpu不太忙的节点第二个副本：放置在第一个副本不同机架的节点上第三个副本：放置在与第二个副本相同机架的节点上
更多副本：随机节点(哪个节点比较空闲,就放到哪个节点上)

HDFS读流程

使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的DataNode地址；
客户端开发库Client会选取离客户端最接近的DataNode来读取block；如果客户端本身就是DataNode,那么将从本地直接获取数据
读取完当前block的数据后，关闭与当前的DataNode连接，并为读取下一个block寻找最佳的DataNode；
当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。
读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读。
当文件最后一个块也都读取完成后，datanode会连接namenode告知关闭文件。

HDFS的写流程

使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作(用户也有不同的权限)，成功则会为文件创建一个记录，否则会让客户端抛出异常；
当客户端开始写入文件的时候，开发者会将文件切分成多个packets，并在内部以数据队列"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表，列表的大小根据在Namenode中对replication的设置而定。
开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此 pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。
最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。
如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持 replicas设定的数量。