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

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无法将对方降级，自然也无法升级自己为主，集群会报错