HDFS读写流程

理论知识点

存储模型

架构设计

角色功能

元数据持久化

安全模式

副本放置策略

读写流程

安全策略

存储模型

·文件线性按字节切割成块（block），具有offset，id
·文件与文件的block大小可以不一样
·一个文件除了最后一个block，其他block大小一致
·block的大小依据硬件的IO特性调整
·block被分散存放在集群的节点中，具有location
·Block具有副本（replication），没有主从概念，副本不能出现在同一个节点
·副本是满足可靠性和性能的关键
文件上传可以指定block大小和副本数，上传后只能改变副本书
·一次写入多次读取，不支持修改
·支持追加数据

架构设计

~HDFS是一个主从（Master/Slaves）架构，主从都是活动的，而且两者之间要有通信的；还有一个主备的概念，主备一般在高可用环境下，主挂了之后备用的才会启用。
~由一个NameNode和一些DataNode组成
~面向文件包含：文件数据（data)和文件元数据（metadata）
~NameNode负责存储和管理文件元数据，并维护了一个层次型的文件目录树
~DataNode负责存储文件数据（block），并提供block的读写
~DataNoce与NameNode维持心跳，并汇报自己持有的block信息
~Client和NameNode交互文件元数据和DataNode交互文件block数据

角色功能

NameNode

~完全基于内存存储文件元数据、目录结构、文件block的映射
~需要持久化方案保证数据可靠性
~提供副本放置策略

DataNode

~基于本地磁盘存储block（文件的形式），所以HDFS相当于一个管理映射的东西，并没有帮我们存储数据。
~并保存block的校验和数据保证block的可靠性
~与NameNode保持心跳，汇报block列表状态

元数据持久化

~任何对文件系统元数据产生修改的操作，NameNode都会使用一种称为EditLog的事物日志记录下来。
~使用FsImage存储内存中所有的元数据状态
~使用本地磁盘保存EditLog和FsImage
~Editlog具有完整性，数据丢失少，但恢复速度慢，并有体积膨胀风险
~FsImage具有恢复速度快，体积与内存数据相当，但不能实时保存，数据丢失多
~NameNode使用了FsImage+EditLog整合的方案；滚动将增量的EditLog更新到FsImage,以保证更近时间点的FsImage和更小的EditLog体积。

数据持久化：
（1） 日志文件：记录实时发生的增删改的操作 append，文本文件
完成性比较好
加载恢复数据：慢/占空间
（2）镜像、快照、dump、db
间隔（小时，天，10分钟，，，），内存全量数据基于某一时间点做的向磁盘的溢写IO
恢复速度快过日志文件
因为是间隔的，容易丢失一部分数据
HDFS：EditsLog: 日志-》体积小，记录少，必然有优势
FsImage: 镜像，快照-》能更快的滚动更新时点。
最近时点的FsImage+增量的EditsLog—>比如现在十点：FI：9点 + 9点到十点的增量的EL---->1,加载FI；2，加载EL；3，内存就得到了关机前的全量数据！！！

安全模式

~HDFS搭建时会格式化，格式化操作会产生一个空的FsImage.
~当NameNode启动时，他从硬盘中读取EditLog和FsImage
~将所有EditLog中的事务作用在内存中的FsImage上，并将这个新版本的FsImage从内存中保存到本地磁盘上；
~然后删除旧的EditLog,因为这个旧的EditLog的事务已经作用在FsImage上了。
~NameNode启动后会进入一个称为安全模式 的特殊状态。
~处于安全模式的NameNode是不会进行数据块的复制的。
~NameNode从所有的DataNode接受心跳信号和块状态报告。
~每当Namenode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全（safely replicated）的。
~在一定百分比（这个参数可以配置）的数据块被NameNode检测确认是安全之后（加上一个额外的30秒等待时间），NameNode将退出安全模式状态。
~接下来他会确定还有哪些数据块的副本没有达到指定数目，并将这些数据复制到其他的DataNode上。

HDFS中的SNN

SecondaryNameNode(snn)
~在非Ha模式下，SNN一般是独立的节点，周期完成对NN的EditLog向FsImage合并，减少EditLog大小，减少NN启动时间。
~根据配置文件设置的时间间隔fs.checkpoint.period默认3600秒
~根据配置文件设置edits log大小 fs.checkpoint.size规定edits文件的最大值，默认是64MB

Block的副本放置策略

~第一个副本：放置在上传文件的DN；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
~第二个副本：放置在与第一个副本不同的机架的节点上。
~第三个副本：与第一个副本相同的机架的节点。
~更多副本：随机节点。

HDFS写流程

~Client和NN连接创建文件元数据
~NN判定元数据是否有效
~NN促发副本放置策略，返回一个有序的DN列表
~Client和DN建立Pipeline连接
~Client将块切分成packet（64KB），并使用chunk（512B）+ chucksum(4B) 填充
~Client将packet放入发送队列dataqueue中，并向第一个DN发送
~第一个DN收到packet后本地保存并发送给第二个DN
~第二个DN收到packet后本地保存并发送给第三个DN
~这一过程中，上游节点同时发送下一个packet
~生活中类比工厂的流水线，结论：流式其实也是变种的并行计算
~Hdfs使用这种传输方式，副本数对于client是透明的
~当block传输完成，DN们各自先NN汇报，同时client继续传输下一个block
~所以，client的传输和block的汇报也是并行的

HDFS的写流程

~为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离他最近的副本。
~如果在读取程序的同一机架上有一个副本，那么就读取该副本
~如果HDFS集群跨越多个数据中心，那么客户端也将首先读取本地数据中心的副本。
～语义：下载一个文件：
　　～client和NN交互文件元数据获取fileBlockLocation
　　～NN会按距离策略排序返回
　　～client尝试下载block并校验数据完整性
～语义：下载一个文件其实是获取文件的所有的block元数据，那么子集获取某些block应该成立
　　～HDFS支持client给出文件的offset自定义连接哪些block的DN，自定义获取数据
　　～这个是支持计算层的分治、并行计算的核心。
　　
分布式文件系统那么多为什么还要有个HDFS？
因为HDFS可以暴露块的位置信息，可以暴露块的偏移量，可以支持客户端读取文件的任意位置