Hadoop学习笔记[1]-HDFS基本知识和读写原理

Hadoop学习笔记[1]-HDFS基本知识和读写原理,第1张

Hadoop学习笔记[1]-HDFS基本知识和读写原理 Hadoop学习笔记[1]-HDFS基本知识和读写原理

  大数据领域的技术基石主要来源于谷歌的三篇论文GFS、MapReduce和BigTable,分别是文件系统、计算框架和数据库,本文所说的HDFS对应其中的GFS,先抛出一个小问题,在HDFS出现之前,市面上就已经存在各种各样的分布式文件系统,那么为什么Hadoop之父还要搞一个HDFS?

1、HDFS基本架构 1-1 存储模型

1)、文件线性按照字节切割成块,具有offset和块ID【数据被切割在不同的块的时候怎么办?】2)、不同文件之间的块大小可以不一样(默认是128M,不同版本不同,和硬件有关)3)、一个文件除了最后一个block块,其余块大小一致4)、block的大小根据硬件的IO特性调整5)、block会被分散在集群的不同节点存储,具有location6)、block具有副本,没有主从的概念,副本不能出现在同一节点7)、副本是满足可靠性和性能的关键8)、文件上传时可以指定block大小和副本数,上传后只能修改副本数9)、不支持修改数据,允许追加数据(Hive底层用的是hdfs存储,所以对修改 *** 作支持很差,因为修改数据之后会导致hdfs文件中某个块的大小不一致,导致后续所有的块的偏移量都出现错误,需要将文件重新存储一次,所以修改 *** 作=重新全量写文件到HDFS) 1-2 架构设计描述

1)、主从架构2)、由一个NameNode和一些DataNode组成3)、NameNode负责存储和管理文件的元数据,并维护一个层次型的目录树4)、DataNode负责存储文件的block,并提供block的读写5)、NameNode和DataNode维持心跳信息,并汇报自己持有的block块信息,因为DN会向NN汇报块位置,所以NN序列化元数据时不会持久化块位置,且块位置会变,也不适合持久化6)、Client和NameNode交互文件元数据和DataNode交互文件的block数据 1-3 文件Block副本放置策略

1)、如果客户端是集群内部节点,则第一个副本放置在本机,如果客户端是集群外节点,则随机选一个不太满的节点2)、第二个副本放置在和第一个副本非同一机架的其余节点,第三个副本放置在和第二个副本相同的机架节点上,其余副本随机放置 1-4 HDFS故障分类及应对方案 1-4-1 HDFS NameNode单点故障及其解决方案

  Hadoop2.X开始引入HA方案,也就是高可用,采用主备架构,一主多备【hadoop2.X只能一主一备,3.X可以一主多备】,使用ZK实现,为了向前兼容,高可用并没有集成在NaneNode内部,而是使用新的进程,进程就是角色,NameNode的高可用监控程序进程的简称为ZKFC,虽然进程不一样,但是ZKFC和NameNode必须部署在同一台物理节点上,不然就没有意义了

1-4-2 HDFS NameNode单点压力过大问题及其解决方案

  采用联邦机制:Federation【元数据分片】,多个NN,管理不同的元数据,多个NN之间不是主备关系

2、HDFS读写流程 2-1 写数据流程

  先上一张图

假设副本数量是3,写流程如下:

1)、客户端向Namenode发送创建block的请求【创建元数据】2)、NN判断元数据是否有效【包括权限等校验】3)、NN触发副本放置策略,返回一个有序的DN列表4)、CLI和DN建立PipeLine连接,Cli只和NN返回的第一个DN建立网络连接,并将其余DN发送给第一台DN,由第一台DN连接第二天DN,以此类推5)、Cli将块切分成Packet(64KB),并使用chunk(512B)+校验和(4B)填充packet6)、Cli将切分好的packet存储在dataQueue中,并向第一台DN发送7)、第一台DN收到packet后本地保存并将其发送给第二台DN,第二台DN收到Packet后也先本地保存,并将其传输给第三台DN,同时第一台DN工作结束后返回Ack给Cli,Cli同时发送下一个【假设传输过程中,有DN挂了,如果是DN3挂了,并不影响整个传输链路,但是如果DN2挂了,那么DN1会直接和DN3建立连接,由于每一台DN都存储了当前接收Packet的序号,假设DN3收到的最大序号是3,则DN1会从4开始将Packet传输给DN3】8)、当block传输完成后,所有的DN会各自向NN汇报,同时Cli继续传输下一个block,如果NN统计后发现block的副本数量不足,则NN会从任意DN中复制Block使副本数量满足要求 2-2 读数据流程

  还是先上一张图

假设副本数量是3,读数据流程如下:

1)、客户端向Namenode发送读数据请求,NN返回文件块信息列表,块的位置信息【NN会按照距离策略排序返回,例如如果Cli所在的节点就有该块,则优先从所在节点获取】2)、Cli根据块的位置信息从Dn中读取对应的块,如果是文件下载,为了减少整体的带宽消耗和读取延时,HDFS会尽量,让读取程序读取距离它最近的副本,如果读取程序的同一机架上有一个副本,那么就会读取该副本,如果HDFS集群跨越多个数据中心,那么也会先读取本地位置中心的副本3)、在分布式计算时,往往不需要下载全部的文件,而只需要下载文件的一部分进行处理,既然Cli支持下载所有的文件块,那么单独下载某几个块也没有问题,所以HDFS支持Cli根据文件的偏移量自定义连接哪些Block的DN,自定义获取数据,而不需要每次都需要下载整个文件【回答一下前面那个问题,为什么有那么多分布式文件系统,还要专门搞一个HDFS出来,主要的目的就是支持分布式计算,计算向数据移动】 3、HDFS-HA解决方案介绍

  HA方案的部署架构图如下

3-1 NameNode数据同步 3-1-1 需要同步的数据内容

客户端提交的交互 *** 作(如创建文件 *** 作)【客户端只能连接主NN *** 作】,最终会反应在文件目录树上文件block块信息【这个可以让DN同时向主机和备机汇报自己的block信息解决】 3-1-2 数据同步方案

1)、 客户端提交 *** 作个主NN,主NN同时将 *** 作发送给备NN,等待备NN也 *** 作成功后才返回给客户端,保证了强一致,但是可用性变低,如果备NN一直不返回,则集群不可用2)、 客户端提交 *** 作个主NN,主NN同时将 *** 作发送给备NN,不等待备NN也 *** 作成功直接返回给客户端,保证了高可靠性,但是一致性无法保证3)、 保证高可用和最终一致性【CAP准则】,hdfs引入新的角色JournalNode存储 *** 作信息,JournalNode本身必须可靠性比较高,主NN将 *** 作信息写入JN集群【和zk类似,主节点负责增删改,从节点只能查】,JN根据一致性算法【Paxos算法,zk的快速选举算法是其简化版本】判断 数据是否存储成功,储存成功则返回给主NN,备NN从JN集群同步对应的 *** 作信息,保证备NN和主NN的数据最终一致 3-2 主备切换流程介绍 3-2-1 ZKFC功能介绍

1)、监控同一台服务器上的NN是不是还在提供服务2)、连接ZK抢锁,就是创建临时目录节点,哪台服务器的ZKFC抢到锁之后,该台服务器对应的NN就是主节点,当监测到同一台服务器的NN挂了之后,会主动删除自己创建的临时目录节点,zk在删除节点后会通知另一台服务器的ZKFC,另一台ZKFC就会尝试抢锁,并准备将本台服务器的NN升级为主3)、当ZKFC抢到锁之后,表示可以将本台服务器运行的NN升级为主,但是ZKFC会访问一下另一台NN,看一下另一台NN是不是真的已经没有对外提供服务,并将对方降级成standby,才会将本服务器的NN升级为主 3-2-2 主备切换的几种情况

1)、ZKFC正常但是NN停服,ZKFC ACTIVE删除临时目录,ZK通知 ZKFC standby,ZKFC stanby在ZK注册节并将NN Active降级,之后将NN standby升级为active2)、ZKFC挂了但是NN正常,ZKFC ACTIVE挂了之后,和ZK连接会话消失,会话超时后,zk删除临时目录,ZK通知 ZKFC standby,ZKFC stanby在ZK注册节并将NN Active降级,之后将NN standby升级为active3)、ZKFC和NN正常,但是不能和zk通信,导致zk删除节点,如果ZKFC Standby也无法连接NN ACTIVE,那么此时ZKFC Standby无法将对方降级,自然也无法升级自己为主,集群会报错

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5720063.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-18
下一篇 2022-12-18

发表评论

登录后才能评论

评论列表(0条)

保存