HDFS

2.HDFS

Hadoop2.0以后的版本移除了原有的JobTracker和TaskTracker，改由Yarn ResourceManager负责集群中所有资源的统一管理和分配，NodeManager管理单个计算结点

系统架构

image

Active NameNode（AN）

• 管理命名空间

• 管理元数据：文件的位置、所有者、权限、数据块等

• 管理Block副本策略：默认3个副本

• 处理客户端读写请求，为DataNode分配任务

Standby NameNode(SN)

Block数据块

若一个Block的大小小于设定值，不会占用整个块空间

Block和元数据分开存储：Block存储于DataNode，元数据存储于NameNode

hadoop1.x默认块大小为64M

hadoop2.x默认块大小为128M

可以在hdfs-site.xml中设置：dfs.block.size

NameNode元数据文件

• edits(编辑日志文件):保存了自最新检查点(Checkpoint)之后的所有文件更新操作

• fsimage(元数据检查点镜像文件):保存了文件系统中所有的目录和文件信息

• Active NameNode内存中有一份最新的元数据(= fsimage + edits)

• Standby NameNode在检查点定期将内存中的元数据保存到fsimage文件中

元数据的两种存储形式

• 内存元数据（NameNode）

• 文件元数据（edits + fsimage) （编辑日志文件 元数据镜像检查点文件）

非HA high available

HDFS主要由三个组件构成，分别是NameNode、SecondaryNameNode和DataNode，其中NameNode和SecondaryNameNode运行在master节点上，DataNode运行在slave节点上

SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。

1. 首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode自己的fsimage]

2. 一旦它有了新的fsimage文件，它将其拷贝回NameNode中。

3. NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。

Secondary NameNode：它不是HA(高可用)，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NN失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失

HA方案 hadoop2.0

两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。

• 当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。

• standby状态的NameNode定期读取JNs中的变更信息，并且一直监控edit log的变化然后把edits文件和fsimage文件合并成一个新的fsimage，合并完成之后会通知active namenode获取这个新fsimage。active namenode获得这个新的fsimage文件之后，替换原来旧的fsimage文件。

• standby可以确保在集群出错时，命名空间状态已经完全同步了。

QJM共享存储系统

DataNode

• Slave工作节点(可大规模扩展)

• 存储Block和数据校验和

• 执行客户端发送的读写操作

• 通过心跳机制定期(默认3秒)向NameNode汇报运行状态和Block列表信息 集群启动时，DataNode向NameNode提供Block列表信息

利用QJM实现元数据高可用

主备NameNode之间通过一组JournalNode同步元数据信息，一条数据只要成功写入多数JournalNode即认为写入成功。通常配置奇数个JournalNode

active namenode和standby namenode之间是通过一组journalnode（数量是奇数，可以是3,5,7...,2n+1）来共享数据。active namenode把最近的edits文件写到2n+1个journalnode上，只要有n+1个写入成功就认为这次写入操作成功了，然后standby namenode就可以从journalnode上读取了。可以看到，QJM方式有容错的机制，可以容忍n个journalnode的失败。

QJM共享存储系统

Quorum Journal Manager

• 部署奇数（2N+1）个JournalNode

• JournalNode负责存储edits编辑日志

• 写edits的时候，只要超过半数（N+1）的 JournalNode返回成功，就代表本次写入成功

• 最多可容忍N个JournalNode宕机

利用ZooKeeper实现Active节点选举

Decommission or Recommission（DataNode退役和服役）

删除DataNode（先退役再删除）

自动切换

优缺点

优点：

• 适合大文件的存储

• 廉价机器，容错，恢复

• 流式数据访问，一次写入，多次读取最高效

缺点：

• 不适合小文件存储

• 不适合并发写入

• 不支持文件随机修改

• 不支持随机读

读写操作

写操作，在client处将文件切分为块

image

读操作，在client处将block拼装成一个文件

image

HDFS读写

1.*****数据块的大小设置为多少合适为什么？*

hadoop数据块的大小一般设置为128M，如果数据块设置的太小，一般的文件也会被分割为多个数据块，在访问的时候需要查找多个数据块的地址，这样的效率很低，而且如果数据块设置太小的话，会消耗更多的NameNode的内存；而如果数据块设置过大的话，对于并行的支持不是太好，而且会涉及系统的其他问题，比如系统重启时，需要从新加载数据，数据块越大，耗费的时间越长。

数据块太小，namenode太累，块太多

太大，恢复时间，并行执行

HDFS写流程：

image

image

1.客户端向NameNode发起写数据，NameNode将信息反馈给Client

2.Client将数据分块， 分块写入DataNode节点，DataNode自动完成副本备份

3.DataNode向NameNode汇报存储完成，NameNode通知客户端

HDFS读流程：

image

1.客户端向NameNode发起读数据的请求

2.NameNode找出最近的DataNode节点信息返回给客户端

3.客户端从DataNode分块下载文件

hadoop常用命令

hdfs dfs -mkdir -p /user/johnson # 创建用户目录
hdfs dfs -ls / 查看目录 本地是看不见的
hdfs dfs -mkdir -p /user/johnson/input
hdfs dfs -put /usr/local/hadoop/etc/hadoop/*.xml /user/johnson/input

rm -r ./output    # 先删除本地的 output 文件夹（如果存在）
hdfs dfs -get /user/johnson/output ./output     # 将 HDFS 上的 output 文件夹拷贝到本机
hdfs dfs -rm -r output 
copyFromLocal（从**本地系统**->**HDFS系统**）、copyToLocal（从**HDFS系统**->**本地系统**）

运行 Hadoop 程序时，为了防止覆盖结果，程序指定的输出目录（如 output）不能存在，否则会提示错误，因此运行前需要先删除输出目录。

延伸

1.如果通过hadoop存储小文件

• 可以采用压缩合并小文件的策略

• 设置文件输入类型：ComnineFileInputFormat

Hadoop分布式缓存

DistributedCache

在执行mr时，mapper之间可能会共享一些数据，如果信息量不大，可以将其从hdfs加载到缓存中

推荐算法

https://www.imooc.com/video/15785