为什么要开发HDFS分布式文件系统
可以更好的支持分布式计算。
hadoop distribute file system是一个分布式 文件系统，操作的是文件，增、删都是以文件为单位。
存储模型
- 文件线性按字节切割成块（block），具有offset，id
offset是指block的偏移量，比如block大小是10，offset可以是0,10,20,30。。。
id是block的名称，比如block1，block2。。。 - 文件与文件的block大小可以不一样
指不同的文件，block大小可以不一样，比如A文件block大小是10Byte，B文件的大小是20Byte。 - 一个文件除最后一个block，其他block大小一致
文件中的数据一定会被切坏，如何恢复，后期拼接时恢复。 - block的大小依据硬件的I/O特性调整
- block被分散存放在集群的节点中，具有location
location是指block存储在集群中的哪个节点上。 - block具有副本（replication），没有主从概念，副本不能出现在同一个节点
副本没有主从概念，比如3个副本就是每个block被存储为三份，三份读哪一个都行。 - 副本是满足可靠性和性能的关键
多个 副本可以让多个程序并行计算，计算想向数据移动，无需拉取文件。 - 文件上传可以指定block大小和副本数，上传后只能修改副本数
文件上传后无法再次调整block大小，但是可以调整block的副本数。 - 一次写入多次读取，不支持修改
只能读取，不能修改，但是能追加数据。
why：原因是如果修改block数据，那边会导致后面的block偏移量都会改变，导致资源被严重浪费（CPU、网络带宽、IO等），这是一个折中设计，因为hdfs目的是为了更好的支持分布式计算，所以没必要为了修改操作而产生泛洪操作。 - 支持追加数据
追加数据不会导致其他block的偏移量修改，只是最后一个block数据产生变化，不会导致泛洪操作，因此支持追加操作。
架构设计
- HDFS是一个主从（Master/Slaves）架构
主和从协作完成一个任务；
主备是指一个干活一个不干活，等主的挂了备的切换为主，其实备就是一个备份。 - 由一个NameNode和一些DataNode组成
NameNode是主，DataNode是从 - 面向文件包含：文件数据（data）和文件元数据（metadata）
- NameNode负责存储和管理文件元数据，并维护一个层次型的文件目录树
类似linux的文件目录树。 - DataNode负责存储文件数据（block块），并提供block的读写
客户端先和NameNode确认去哪里存取，然后到对应的DataNode存取。
NameNode类似一个网关，会把请求转发到不同的节点。 - DataNode与NameNode维持心态，并汇报自己持有的block信息
NameNode确认文件是否存储完成，是根据DataNode上报的信息确认的。 - Client和NameNode交互文件元数据和DataNode交互文件block数据
角色功能
NameNode
- 完全基于内存存储文件元数据、目录树结构、文件block的映射
基于内存存储，为了快速访问，内存的IO是磁盘IO的10万倍 - 需要持久化方案保证数据可靠性
- 提供副本放置策略
DataNode - 基于本地磁盘存储block（文件的形式）
一个文件如果被切分为10个block，那么会被存储成10个小文件，分散到不同的DataNode上。 - 并保存block的校验和，保证block的可靠性
确保下载时block数据不会被破坏，下载block后计算出校验和与DataNode上的校验和比对，一致数据就是正常的。 - 与NameNode保持心跳，汇报block列表状态
元数据持久化
- 任何对文件系统元数据产生修改的操作，NameNode都会使用一种称为EditLog的事务日志记录下
- 使用FsImage存储内存所有的元数据状态
- 使用本地磁盘保存EditLog和FsImage
- EditLog具有完整性，数据丢失少，但恢复速度慢，并有体积膨胀风险。
- FsImage具有恢复速度快，体积与内存数据相当，但不能实时保存，数据丢失多
- NameNode使用了FsImage+EditLog整合的方案
滚动将增量的EditLog更新到FsImage，以保证更近时间点的FsImage和更小的EditLog体积
日志文件的作用
记录实时发生的增删改的操作，可以通过读取日志的方式恢复之前的数据。
优点：日志的完整性比较好，因为是实时的。
缺点：加载数据恢复数据慢，占用空间大。
镜像、快照、dump、db的作用
内存全量数据基于某个时间点写入磁盘，类似于内存全量数据序列化到磁盘。
但是间隔时间不能太短，因为I/O读写慢。
优点：通常是二进制文件存储，恢复速度快。
缺点：因为间隔保存， 容易丢失部分数据。
HDFS元数据如何持久化
通过镜像（FsImage）+日志（EditLog）组合的方式。
HDFS如何组合使用的？
EditLog：尽可能的让日志文件体积小，记录少。
FsImage：尽可能更快的管道更新镜像文件（定时生成FsImage文件）
通过 最近时点的FsImage + 增量的EditLog来持久化数据。
比如现在10点：
使用9点的FsImage + 9点到10点的增量EL
恢复步骤：
1、加载FI
2、加载EL
3、内存就得到了关机前的全量数据
安全模式
-
HDFS搭建时会格式化，格式化操作会产生一个空的FsImage
-
当NameNode启动时，它从硬盘中读取Editlog和FsImage
-
将所有Editlog中的事务作用在内存中的FsImage上
-
并将这个新版本中的FsImage从内存中保存到本地磁盘上
-
然后删除旧的EditLog，因为这个旧的Editlog的事务都已经作用在FsImage上了
-
NameNode启动后会进入一个称为安全模式的特殊状态。
-
处于安全模式的NameNode是不会进行数据块的复制的。
比如文件元数据包括：文件属性，每个块存在哪个DN上。
在持久化的时候：文件属性会持久化，但是文件的每个块所在的位置不会持久化，因此NN启动恢复的时候，NN会丢失块的位置信息。
这么设计的原因是：分布式存储，数据一致性很重要，如果持久化了，但是启动集群的时候，某台DN挂了，那么下载block就会出错。所有使用启动DD上报数据到NN。 -
NameNode从所有的Datanode接收心跳信号和块状态报告。
-
每当NameNode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全（safely repicated）的。
-
在一定百分比（这个参数可配置）的数据块被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不太忙的节点。
- 第二个副本：放置在于第一个副本不同的机架的节点上。
- 第三个副本：与第二个副本相同机架的节点。
减少客户端的成本，如果2,3放置一个机架上，不需要出机架，减少网络IO。 - 更多副本：随机节点。
读写流程
- 客户端首先从NN中拿到DN的排序列表。
- 客户端和位置最近的DN建立TCP连接，第一个DN和第二个DN建立tcp连接，第二个DN和第三个DN建立TCP连接，形成一个pipeline，也就是客户端只和一个DN建立连接。客户端把文件切成多个块，客户端给第一个DN传一个块，传完了几下传第二个块，无需等待第二个DN、第三个DN传完，后续的DN数据有前一个DN负责。其实流水线也是一种变种的并行。
详细的HDFS写流程
客户端现象NN申请一个块的副本位置；客户端发完一个block后，再次向NN申请下一个block的副本位置。
下面是客户端发送一个block的具体流程。文章来源：https://www.toymoban.com/news/detail-503609.html
- Client和NN连接创建文件元数据
- NN判定元数据是否有效
- NN触发副本放置策略，返回一个有序的DN列表
- Client和DN建立Pipeline连接
- Client将块切分成packet(64KB)，并使用chunk(512B) + chunksum(4B)填充。
也就是客户端每次发送一个packet。
64KB = (512B + 4B)*n，也就是64KB的数据分成多个chunk+chunksum - Client将Packet放入发送队列dataqueue中，并向第一个DN发送。
- 第一个DN收到packet后本地保存并发送给第二个DN
- 第二个DN收到packet后本地保存并发送给第三个DN
- 这一个过程中，上游节点同时发送下一个packet
- 生活中类比工程的流水线：结论：流式其实也是变种的并行计算
- Hdfs使用这种传输方式，副本数对于client是透明的
- 当block传输完成，DN们各自向NN汇报，同时client继续传输下一个block
- 所以，client的传输和block的汇报也是并行的
HDFS读流程
文章来源地址https://www.toymoban.com/news/detail-503609.html
HDFS读流程
- 为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。
- 如果在读取程序的同一个机架上有一个副本，那么就读取该副本。
- 如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。
- 语义：下载一个文本：
- client和NN交互文件元数据获取fileBlockLocation
文件的所有block的位置。 - NN会按距离策略排序返回
- Client尝试下载block并校验数据完整性。
- client和NN交互文件元数据获取fileBlockLocation
- 语义：下载一个文件其实是获取文件的所有的block元件数据，那么子集获取某些block应该成立
- Hdfs支持client给出文件的offset自定义连接哪些block的DN，自定义获取数据
- 这个是支持计算层的分治、并行计算的核心
到了这里，关于hadoop-hdfs分布式文件系统理论（一）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
