hdfs基础概念和原理

是什么

分布式文件系统 （Hadoop Distributed File System）：

它是一个文件系统，用于存储文件，通过目录树来定位；其次，它是分布式的，由很多服务联合起来实现其功能，集群中的服务器有各自的角色

做什么

稳定可靠地大规模存储、处理数据，GB/TB/PB级别

满足场景

1.大量的廉价机器搭建分布式文件系统

2.适合一次写入多次读取，支持追加，不支持修改

3.关注吞吐量的流式访问数据(时间可能并不快)

4.存储大量数据

不适用场景

1.对访问时间有严格要求的

2.并发写入的场景

3.存储大量的小文件的(这样会导致元数据过大，且寻道时间过长)

4.随机修改数据的场景

架构解析

集群角色

NameNode

分为Active NameNode和Standby NameNode，NameNode有集群的一些元数据信息、负责管理集群。SN为备用的NameNode,为了保证其的高可用。具体功能如下：

Active NameNode

• 活动管理节点（集群中唯一）
• 管理命名空间：文件系统的目录层次空间
• 管理元数据：目录文件的基本属性、Block相关信息、DataNode相关信息等
• 管理Block副本策略：副本数（默认3副本）、副本放置策略等
• 管理DataNode：节点上下线监测、文件系统健康状况监测、 Block恢复和重分布等
• 处理客户端读写请求：审核权限，编制计划，为DataNode分配任务

Standby NameNode

• 热备管理节点（允许多个） －Hadoop 3.0允许配置多个SN，之前的版本只能有一个SN
• 主备切换：AN宕机后，经过Master选举和元数据恢复，SN升级为AN
• 元数据同步：Checkpoint检查点的周期性同步、选举成功后的元数据恢复

Datanode

• Slave工作节点（高扩展）
• 存储Block数据块和数据校验和
• 向NameNode汇报情况 －日常运行：通过心跳机制（默认3秒），向NameNode定期汇报运行状况和Block统计信息－集群启动：进入安全模式，并向NameNode集中上报Block统计信息
• 执行客户端发送的读写命令

Client

• 文件管理

  －发送文件读写请求，将文件切分为Block或将Block组装为文件

  －与NameNode交互，获取读写计划和相关元数据

  －与DataNode交互，读取或写入Block

• 系统管理：发送HDFS管理命令

数据存储单元

• Block是最小的存储单元，默认为128M
• 文件会被拆分为多Block多副本的形式，即多个node平均block的个数差不多，且每个block不仅只在一个node存储，在其他节点会有副本。

关于block大小：

1.太小-寻址时间增大，map任务增加，并发度增加，集群负载过高，效率变慢

2.太大-map任务量少，并发度太小，集群负载过低，效率变慢

3.128m?为了使寻址开销最小，且任务并发度和集群负载适中。

3.1如果寻址时间为10ms，即查找到目标的bolck的时间为10ms；
3.2寻址时间为传输时间的1%时，则为最佳状态。因此，传输时间=寻址时间/0.01=10ms/0.01=1000ms=1s
3.3而目前磁盘的传输速度普遍为100MB/s
3.4因此block的大小为=1s*100MB/s=100M≈128M。

4.放置策略：三个副本-其一在client所在节点，其二在同一机架的不同节点，其三在不同机架不同节点。

5.129m的文件，创建两个block分分为128m和1m

元数据

包含什么

目录文件的基本属性（如名称、所有者等）、Block相关信息（如文件包含哪些Block、Block放在哪些节点上等）、DataNode相关信息

• Active NameNode：最新的元数据（= fsimage + edits，实时更新）
• Standby NameNode：通过QJM定期（默认60s）同步AN的元数据

组成

fsimage数据检查点镜像文件

1.SN定期对检查点对u内存中的元数据持久化，生成镜像文件

2.其不是实时持久化的原因是：fsimage的写入太慢

3.怎么根据fsimage回复元数据：找到其记录的最后一个变更操作的Transaction Id ，恢复时只需要载入修够的fsimage，并且执行edits_inprogress文件就行

edits编辑日志文件

1.保存的时最近检查点后的所有变更操作(因为之前的已经生成fsimage镜像文件了)

2.变更操作先写edits再写入内存

3.文件以 “Transaction Id前后缀”标记所包含更新操作的范围

持久化和元数据同步

1.0版本

基于远程合并的持久化

①在Checkpoint检查点，SN请求AN停用edits，后续变更操作写入edits.new

②将fsimage和edits下载到SN（第一次需下载fsimage）

③在内存中载入fsimage，与edits进行合并，然后生成新 的fsimage，并将其上传给AN

④用新文件替换edits和fsimage（edits实现瘦身）

缺点：

• 合并前要先将fsimage载入内存，速度慢
• 未实现edits高可用（SN上的edits不是最新的），若AN 上的edits损毁，将导致元数据丢失
• SN无法承担热备职能

2.0版本

QJM

• QJM（Quorum Journal Manager）共享存储系统
• 基于Paxos算法实现的JournalNode集群，实现了edits的 高可用存储和共享访问
• 最好部署奇数（2n+1）个节点，最多容忍n个节点宕机
• 过半（n+1）节点写入成功，即代表写操作完成

基于远程合并的持久化：

基于QJM的edits持久化

①AN将变更操作同步写入本地和QJM的edits

②在内存中执行该操作，并将结果反馈给Client

基于QJM的fsimage持久化

①在Checkpoint检查点，SN先将内存元数据变为只读来 暂停QJM edits的定期同步，再将元数据镜像到fsimage中

②SN将fsimage上传到AN，同时恢复QJM定期同步

③AN根据fsimage的事务id，删除旧edits，实现瘦身

写操作：

1.客户端发起写文件请求 hadoop fs -put(客户端发送指令给文件系统，文件系统告知NN位置)
2.NameNode检查上传文件的命名空间是否存在（就是检测文件目录结构是否存在），创建者是否有权限进行操作，然后返回状态给客户端你可以上传数据；
3.客户端按照分块配置大小将文件分块，然后请求NameNode我要上传blk1，副本数是三个，这个文件一共分割了5块。
4.NameNode检测自己管理下的DateNodes是否满足要求，然后返回给客户端三台DateNode节点信息（存储策略是机架模式）(EditLog增加);
5.Client端根据返回的DataNode信息选择一个离自己最近的一个DataNode节点，创建pipeLine（数据传输管道），DataNode1->DataNode2创建pipeLine,DataNode2->DataNode3创建pipeLine;DataNode3通过这一串管道传递给client数据传输管道已经建立完毕；
6.client端创建Stream流（以packet为单位传输数据64kb）上传数据;
7.DataNode1接受并保持源源不断的packet，然后把packet源源不断的传递给DataNode2，DataNode2也做相应的操作。
8.DataNode也通过pipeLine发送ACK认证数据是否接收完毕。
9.第一个数据块上传完毕后client端开始上传第二个数据块。

读操作

1.client 发起 hadoop fs -get请求；
2.NameNode检查该文件的信息，文件的分块信息和每个分块所对应哪个DateNode，以及备份信息和备份信息所在哪个DataNode；
3.NameNode把这些信息返回给client端。（返回原则也是机架原则，根据网络拓扑将距离最近的DataNode排在前边返回）；
4.根据NameNode的信息，请求各个文件块对应的DataNode节点获取文件数据；
5.合并下载过来的数据块，形成一个完整的文件。

安全模式

是什么

• 安全模式是HDFS的一种特殊状态，在这种状态下，HDFS只接收读数据请求，而不接收写入、删除、修改等变更请求
• 安全模式是HDFS确保Block数据安全的一种保护机制
• Active NameNode启动时，HDFS会进入安全模式，DataNode主动向NameNode汇报可用Block列表等信息，在系统达到安全标准前，HDFS一直处于“只读”状态

进入安全模式原因：

• NameNode重启
• NameNode磁盘空间不足
• Block上报率低于阈值
• DataNode无法正常启动
• 日志中出现严重异常 • 用户操作不当，

何时退出

• Block上报率：DataNode上报的可用Block个数 / NameNode元数据记录的Block个数
• 当Block上报率 >= 阈值时，HDFS才能离开安全模式，默认阈值为0.999

高可用

DataNode的高可用

集群中的DataNode会向NameNode发送心跳，如果NameNode在规定时间没有接收到心跳，会认定DataNode发生了故障了，加入DataNode出现了故障，NameNode接着会向集群中的未损坏的DataNode发送指令，创建数据并拷贝到另外的DataNode，这样就保持了高可用了。

NameNode的高可用

两个NameNode(AN和SN)，即

• 活动 Namenode ：负责处理集群中所有客户端请求；
• 备用 Namenode ：备用节点，拥有和活动的 Namenode 一样的元数据。在活动 Namenode 失效后，会接管它的工作。

1.为保证AN和NN实时的元数据一致，使用上述的QJM 共享存储保证edits实时一致。

2.同时为了监控AN，其宕机时及时切换，引入Zookeeper进行监控,即zkfc( ZooKeeperFailoverController )，即Zookeeper故障转移控制。

**它是什么:**是Hadoop中通过ZK实现FC功能的一个实用工具。
主要作用：作为一个ZK集群的客户端，用来监控NN的状态信息。
谁会用它:每个运行NN的节点必须要运行一个zkfc

zk在zkfc中可以提供的功能：
(1) Failure detector（通过watcher监听机制实现）: 及时发现出故障的NN，并通知zkfc
(2) Active node locator: 帮助客户端定位哪个是Active的NN
(3) Mutual exclusion of active state（通过加锁）: 保证某一时刻只有一个Active的NN

ZKFC的线程模型:

总体上来讲比较简单的，它主要包括三类线程，一是主线程；一是HealthMonitor线程; 一是zookeeper客户端的线程。它们的主要工作方式是：
(1) 主线程在启动所有的服务后就开始循环等待
(2) HealthMonitor是一个单独的线程，它定期向NN发包，检查NN的健康状况
(3) 当NN的状态发生变化时，HealthMonitor线程会回调ZKFailoverController注册进来的回调函数，通知ZKFailoverController NN的状态发生了变化
(4) ZKFailoverController收到通知后，会调用ActiveStandbyElector的API，来管理在zookeeper上的结点的状态
(5) ActiveStandbyElector会调用zookeeper客户端API监控zookeeper上结点的状态，发生变化时，回调ZKFailoverController的回调函数，通知ZKFailoverController，做出相应的变化

hdfs联邦

Hadoop 1.0 HDFS 架构只允许整个集群中存在一个 namespace，而该 namespace 被仅有的一个 namenode 管理。

这样有许多弊端：

• 块存储和 namespace 高耦合
  当前 namenode 中的 namespace 和 block management 的结合使得这两层架构耦合在一起，难以让其他可能namenode 实现方案直接使用 block storage。
• namenode 扩展性
  HDFS 的底层存储，即 Datanode 节点是可以水平扩展的，但 namespace 不可以。当前的 namespace 只能存放在单个namenode 上，而 namenode 在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。
• 性能
  文件操作的性能制约于单个 namenode 的吞吐量，单个 namenode 当前仅支持约 60,000 个并发 task，而下一代Apache MapReduce 将支持超过 1,00,000 个并发任务，这意味着将需要更多的 Namenode 。
• 隔离性
  现在大部分公司的集群都是共享的，每天有来自不同部门的不同用户提交作业。单个 namenode 难以提供隔离性，即：某个用户提交的负载很大的 job 会减慢其他用户的 job ，单一的 namenode 难以像 HBase 按照应用类别将不同作业分派到不同 namenode 上。

引入联邦 federation ：

为了水平扩展 namenode，federation 使用了多个独立的 namenode / namespace。这些 namenode 之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。

参考：https://blog.csdn.net/qq_20042935/category_9220544.html

https://blog.csdn.net/u012736748/article/details/79541311

https://www.hadoopdoc.com/hdfs/hdfs-federation