HDFS

hdfs基础知识，包括hdfs1.0和hdfs2.0的主要架构知识点，可以作为入门参考。

HDFS

HDFS2.0

NameNode HA（高可用）

解决 1.0 中只有一个NameNode，存在的单点故障

HDFS2.0 有两个NameNode

active NameNode

standby NameNode

实现HA的关键问题

1. NN的状态同步

通过JournalNodes 共享存储（edit logs），完成元数据的一致性

DN 同时向两个NN 发送心跳，数据块报告

2. 防止脑裂

JN 只接收一个NN 的写入（序号递增实现）

DN 只接受一个NN 的命令（序号递增实现）

3. NN切换过程，客户端的连接不能断

只有一个NN能响应客户端，RPC层封装一层， 重试机制连接NN，若干次失败后连接新的NN

ZKFC的设计（图中蓝色部分）

zookeeper功能 ：

选主，完成故障转移

FailoverController功能：

1. 监控NN的健康状态

2. 向ZK定期发送心跳，使自己可以被选举。

3. 当自己被ZK选为主时，通过RPC调用使相应的NN转换为active。

FC为什么要从NN分离出来

使得主备选举成为可插拔式的插件

也是功能性代码和应用分离的体现

注：FC作为一个deamon守护进程，和NN部署在同一个机器上

NameNode之间共享数据

NFS（共享文件系统）

QJM（Quorum Journal Node） （最低法定人数管理机制） （用得多，这里作为主讲）

Active可以把editlog日志写到JN上，Standby只能从JN读取。

每个写入的editlog有一个编号Epoch，JN会对比这个编号， 比自己保存的Epoch大或相同，则可以写，并更新Epoch到最新； Standby转换为Active时，会把Epoch+1，这样就防止之前的NN向JN写日志

有2n+1台JN存储edit log，每次写操作只要其中 大多数JN返回成功（≥N+1）即认定写成功。 保证高可用；不会因为个别机器延迟，影响整体性能。 注：其细节基于Paxos（基于消息传递的一致性算法），这里不详述

节点分配

Active NN和Standby NN的机器需要相同的硬件配置

FC和NN在同一台机器上

JN 进程相对来说比较轻量，可以同其他进程运行在同一台机器上

集群中，最少要运行3个JN

NN和JN通常不在一台机器上

zookeeper通常是单独维护的一套独立集群

Standby NN

Standby定期从JN读取一批editlog，与active同步

也执行namespace状态的checkpoints， 所以不需要（也不能）运行Secondary NN、 CheckpointNode和BackupNode这些守护进程

NameNode Federation（联盟架构）

单个NameNode的局限性

Namespace（命名空间）的限制

受单个机器内存限制，无法应对数据的飞速增长

namenode元数据信息，限制了集群中数据块，文件和目录的数目

性能的瓶颈

整个HDFS文件系统的性能受限于单个NameNode的吞吐量

隔离问题

某个用户提交的负载很大的job会减慢其他用户的job

联盟架构设计

为了水平扩展Namenode，Federation使用了多个 独立的Namenode/NameSpace，他们之间相互独立 且不需要互相协调，各自分工，管理自己的区域

每个DataNode要向集群中所有的namenode注册， 且周期性的向所有namenode发送心跳和块报告， 并执行来自所有namenode的命令

Block Pool（块池）

定义

属于单个命名空间的一组block（块）

Block Pool是一个重新将block划分的逻辑概念， 而 DataNode是在物理上划分block

特点与作用（略）

联盟的优点

实现NameNode的横向扩展,使得Hadoop集群的规模可以达到上万台

HDFS 快照

概述

快照是HDFS文件系统的只读的基于某时间点的镜像； 可以针对某个目录，或者整个文件系统做快照； 快照比较常见的应用场景是数据备份，防止用户错误操作和容灾恢复。

快照实现

快照文件只保存被快照目录的修改信息 （block块并不会被拷贝）

HDFS 快照特点

快照的创建是瞬间的，代价为O(1)，取决于子节点扫描文件目录的时间。

当且仅当做快照的文件目录下有文件更新时才会占用小部分内存， 占用内存的大小为O(M)，其中M为更改文件或者目录的数量；

创建快照以后发生的修改操作，被按时间的倒序记录下来

快照不会影响正常的HDFS操作

当前的数据可以被直接获取

快照数据是当前数据减去修改的部分计算出来的。

注意：mv命令和del命令是不允许的，因为快照是只读的

快照目录约束

可以在任何被设置为snapshottable的目录上执行快照 （就是需要开启目录的快照功能，一般管理员才有权限）

对一个目录最多可以创建65536个快照

不允许嵌套

也就是说，如果一个目录被设置为snapshottable， 那么它的父目录和子目录都不允许被设置为snapshottable。

快照被存放在一个被命名为 ".snapshot" 的目录中

例子：

1. /demo/data 目录下启用快照

[root@hadoop2 hadoop]# hdfs dfsadmin -allowSnapshot /demo/data Allowing snapshot on /demo/data succeeded

2. 创建快照

[root@hadoop2 hadoop]# hdfs dfs -createSnapshot /demo/data s0 Created snapshot /demo/data/.snapshot/s0

3. 查看快照

]# hdfs dfs -ls /demo/data/.snapshot/s0

基本语法

1. hdfs dfsadmin -allowSnapshot 路径

（开启指定目录的快照功能）

2. hdfs dfsadmin -disallowSnapshot 路径

（禁用指定目录的快照功能，默认是禁用）

3. hdfs dfs -createSnapshot 路径 名称

（创建快照，名称非必须，默认名是时间戳）

4. hdfs dfs -renameSnapshot 路径 旧名称 新名称

（重命名快照）

5. hdfs lsSnapshottableDir

（列出当前用户所有可快照目录）

6. hdfs snapshotDiff 路径1 路径2

（比较两个快照目录的不同之处）

HDFS 缓存

概述

允许用户指定要缓存的HDFS路径

优点：访问速度快

明确的锁定可以阻止频繁使用的数据被从内存中清除

集中化缓存管理对于重复访问的文件很有用

注意点

可以是目录或文件，但目录是非递归的（仅包含该目录下的文件，不包含子目录）

这些DataNode的缓存也是由NameNode所管理

HDFS ACL（权限控制）

Hadoop从2.4.0开始支持

目前HDFS的权限控制与Linux一致，包括用户、用户组、其他用户组三类权限

首先参数上要开启基本权限和访问控制列表功能

dfs.permissions.enabled dfs.namenode.acls.enabled

常用命令

hadoop fs -getfacl /input/acl hdfs dfs -setfacl -m user:mapred:r-- /input/acl hdfs dfs -setfacl -x user:mapred /input/acl

异构层级存储结构

Hadoop在2.6.0版本中引入的新特性

一个集群中，有多种不同的存储介质，比如有SSD、普通Disk磁盘、RAM等

不同的任务对数据访问速度要求不一样，于是通过相应配置， 控制目录和文件写到什么样的介质上去，并且具备配额控制要求

适用的场景如：冷热数据的存储

集群搭建

同时部署NameNode HA和NameNode Federation时， 集群结构会相对复杂一点

生成环境中，NameNode HA几乎是必备

集群规模在1000台以下时，几乎是不需要NameNode Federation

搭建步骤...(待补充)

HDFS1.0

系统架构

3个组件

Namenode

功能

1. 管理着文件系统命名空间

维护着文件系统树及树中的所有文件和目录

2. 存储元数据

NameNode保存元信息的种类有：

文件名目录名及它们之间的层级关系

文件目录的所有者及其权限

每个文件块的名及文件有哪些块组成

元数据保存在内存中

有两种映射关系

1.文件名到block

2.block 到datanode

注：NameNode元信息并不包含每个块的位置信息，只标识在哪些dataNode

元信息持久化

存放元信息的文件是 fsimage （镜像）

对元信息的操作持久化到edits

nedits文件和fsimage文件会被SecondaryNameNode周期性的合并

Hadoop更倾向存储大文件原因

文件越小，存储同等大小文件所需要的元信息就越多

元信息太多占用 Namenode 内存，增加负担

注：文件的物理存储是按照 64M /每个物理块， 多个小文件也是存储在一起，只是逻辑层面是多个块

其他点

运行会占用大量内存和I/O资源，一般NameNode不会有其他任务

hdfs1.0 中 Namenode 有单点问题

不完全解决方案

将hadoop元数据写入到本地文件系统的同时 再实时同步到一个远程挂载的网络文件系统（NFS） 【异地容灾】

运行一个secondary NameNode

SecondNamenode

并不是NameNode的备份

它是为了考虑持久化到磁盘

两个文件

fsimage

它是在NameNode启动时对整个文件系统的快照

edit logs

它是在NameNode启动后，对文件系统的改动序列

解决的问题

NameNode启动时，edit logs才会合并到fsimage文件中， 当NN运行了很长时间后，edit logs文件会变得很大，重启很耗时； secondary NameNode作用就是定期从edits logs读取并合并到 fsimage； 减少NN重启时间

DataNode

功能

1. 负责存储数据块，负责为系统客户端提供数据块的读写服务

2. 根据NameNode的指示进行创建、删除和复制等操作

3. 心跳机制，定期报告文件块列表信息

4. DataNode之间进行通信，块的副本处理

数据块--磁盘读写的基本单位

HDFS默认数据块大小64MB

磁盘块一般为512B（4096B） --物理的磁盘块

块增大可以减少寻址时间

过大会导致整体任务数量过小，降低作业处理速度 即：任务层面不利于并行计算

注：Namenode、SecondNamenode 在一台物理机

其他概念

Rack 机架

client 客户端

机架感知策略

就是Block副本放置策略

第一个副本，在客户端相同的节点

如果客户端是集群外的一台机器，就随机算节点， 但是系统会避免挑选太满或者太忙的节点

第二个副本，放在不同机架（随机选择）的节点

第三个副本，放在与第二个副本同机架但是不同节点上

同机架传输比跨机架快

block 距离

机房 > 机架> 物理机结点

数据完整性校验

计算校验和

HDFS会在写入、读取时验证校验和

收到客户端的数据

其他副本传过来的数据

客户端从datanode读数据的时候

hdfs 默认检查单位是512字节

即数据的每512字节会生产一个校验码（crc32算法）

因为CRC32是32位即4个字节，这样校验和占用的空间就会少于原数据的1%

后台有一个扫描进程：DataBlockScanner

一旦检测出问题的block，通过心跳，通知NN， 于是NN让DN进行修复（拷贝一个无问题的备份）

这个是防止物理介质出现损减情况而造成的数据损坏。

容错--可靠性保证

1. 心跳机制

2. 多副本机制

3. crc32数据校验

4. SNN：保证元数据避免丢失

5. 回收站(.Trash目录)

6. 报告

]# hdfs fsck /passwd -files -blocks -locations

7. 快照：备份，有助于快速还原

HDFS 特点

能做什么

存储并管理PB级数据

处理非结构化数据

注重数据处理的吞吐量（延迟不敏感）T+1

应用模式：write-once-read-many存取模式（无数据一致性问题）

不适合做

存储小文件（不建议）

大量随机读（不建议）

需要对文件修改（不支持）

多用户写入（不支持，会造成覆盖）

HDFS 写的流程

1. 客户端 rpc 调用NN，创建路径

2. 客户端写入DN，DN自己根据机架感知策略创建多个副本。

注：客户端不会等待DN所有副本创建完成（异步）

3. 客户端向NN确认写入成功

HDFS 读的流程

1、从NN获取元信息

2、可从多个DN读取数据

数据本地化

DateNode 和 tasktracker 部署在同一台机器

Namenode 和 Jobtracker是可以部署不同机器

HDFS 操作命令

显示命令的帮助信息

hdfs dfs -help ls

显示当前目录下的所有文件

hdfs dfs -ls /log/map hdfs dfs -lsr /log/ (递归的) hdfs dfs -ls -R /log/ (递归的)(新版本)

。。。