Hadoop之HDFS概述

Hadoop之HDFS

1 HDFS 概述

随着数据的不断增长，使用单台电脑来存储文件已经无法存储大量的数据，需要分配更多的磁盘，这样
就不好管理数据。因此急需一款系统能够自动管理多台电脑上的文件，其实就是分布式文件管理系统。
HDFS 就是一种分布式文件系统，当然还有GFS（谷歌公司），Lustre（Oracle公司）

1.1 定义

HDFS（Hadoop Distributed File System）是一个分布式文件系统。用于存储文件，通过目录树来定位
文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
HDFS 的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并
不适合用来做网盘应用。

1.2 HDFS 的特点

1.2.1 HDFS 的优势

支持超大文件。超大文件在这里指的是几百M，几百GB，甚至几TB大小的文件。一般来说
Hadoop 的文件系统会存储TB级别或者PB级别的数据。所以在企业的应用中，数据节点有可能有
上千个
检测和快速应对硬件故障。在集群的环境中，硬件故障是常见的问题。因为有上千台服务器连接在
一起，这样会导致高故障率。因此故障检测和自动恢复（心跳机制）是 HDFS 文件系统的一个设
计目标
流式数据访问。HDFS 的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般
都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据集。主要的是数据的吞吐
量，而不是访问速度
简化的一致性模型。大部分 HDFS 操作文件时，需要一次写入，多次读取。在 HDFS 中，一个文
件一旦经过创建、写入、关闭后，一般就不需要修改了。这样简单的一致性模型，有利于提高吞吐
量
高容错性。数据自动保存多个副本，副本丢失后自动恢复
可构建在廉价机器上。构建在廉价机器上可以轻松的通过扩展机器数量来近乎线性的提高集群存储
能力

1.2.2 HDFS 的局限性

不能低延迟数据访问。如和用户进行交互的应用，需要数据在毫秒或秒的范围内得到响应。由于
Hadoop 针对海量数据的吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟来说，不适合
用 Hadoop 来做
不适合存储大量的小文件。HDFS支持超大的文件，是通过数据分布在数据节点，数据的元数据保
存在名字节点上。名字节点的内存大小，决定了HDFS文件系统可保存的文件数量。虽然现在的系
统内存都比较大，但大量的小文件还是会影响名字节点的性能
不支持多用户写入、修改文件。HDFS的文件只能有一次写入，不支持追加写入（2.0 版本开始支
持追加），也不支持修改。只有这样数据的吞吐量才能大
不支持超强的事务。没有像关系型数据库那样，对事务有强有力的支持

2 HDFS 技术架构

2.1 HDFS 模块和节点

2.1.1 Block

数据块（Block）是 HDFS 中数据的最基本的存储单位。
当在 HDFS 上存储超大文件时，HDFS 会以一个标准将文件切分成几块，分别存储到不同的节点
上，切出的数据就称为Block。
Block 默认的大小在 Hadoop1.X 中是 64M，在 Hadoop2.X 中是 128M
切块的优点
文件块可以保存在不同的节点上，能够存储超大文件
有利于数据的复制，便于快速备份
有利于数据的分布式计算，即MapReduce操作
在 HDFS 中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间

2.1.2 Namenode

Namenode 用于存储元数据，管理 Datanode 节点的数据
Namenode 会将管理的数据块的数据放入数据块池（Block Pool）中
Namenode 维护HDFS中的元数据信息：
文件的存储路径
文件和 Block 之间关系的信息
Block数量信息
Block 和 Datanode之间的关系信息
元数据格式参照：FileName replicas block-Ids id2host。例如：/test/a.log,3,{b1,b2},[{b1:
[h0,h1,h3]},{b2:[h0,h2,h4]}]
每一条元数据大概是 150B 大小【HDFS不适合存储小文件，元数据信息最终都要加载到内存】
元数据信息存储在内存以及文件中。其中内存中为实时信息，这样做的目的是为了快速查询；磁盘
中的信息不是实时的，存储在磁盘上的目的是为了崩溃恢复
元数据信息会持久化到 Namenode 节点的硬盘上，edit文件中，最终到fsimage文件
存储元数据的目录：dfs/name/current
持久化的文件包括：
fsimage：元数据镜像文件。存储某 Namenode 元数据信息，并不是实时同步内存中的数
据。一般而言，fsimage 中的元数据是落后于内存中的元数据的
edits：操作日志文件,记录了 Namenode 所要执行的操作


当有写请求时，Namenode 会首先将该操作先写到磁盘上的 edits 文件中，当 edits 文件写成功
后才会修改内存，内存修改成功后向客户端返回成功信号，而此时 fsimage 中的数据并没有发生
改动。所以，fsimage 中的数据并不是实时的数据，而是在达到条件时再进行更新
在 Hadoop2.X 的集群中，如果存在 SecondaryNamenode，则更新过程需要
SecondaryNamenode 参与；如果不存在SecondaryNamenode，则更新过程发生在Namenode
上
无论是 Hadoop1.X 还是 2.X，当 HDFS 启动，Namenode 会做一次 edits 和 fsimage 合并的操
作。这样做的目的是确保 fsimage 里的元数据更新
Namenode 通过 RPC 心跳机制来检测 Datanode 是否还活着
当 HDFS 启动的时候，Namenode 会将 fsimage 中的元数据信息加载到内存中，然后等待每个
Datanode 向Namenode 汇报自身的存储的信息，比如存储了哪些文件块，块大小，块id等。
如果 HDFS 处于安全模式，只能对外提供读服务，不能提供写服务
在 Hadoop1.X 中，Namenode 存在单点故障问题。在 Hadoop2.X 的伪分布式中，Namenode
依然存在单点故障，但是在 Hadoop2.X 的完全分布式中，可以通过舍弃 SecondaryNamenode
的方式来配置2个Namenode 来保证 Namenode 的高可用（HA）。

2.1.3 Datanode

在HDFS中，数据是存放在Datanode上面的，并且是以Block的形式存储的
存储Block的目录：
dfs/data/current/BP-139455586-192.168.100.101-
1568712565049/current/finalized/subdir0/subdir0
在 HDFS 启动的时候，每个Datanode将当前存储的数据块信息告知Namenode节点
之后，Datanode节点会不断向Namenode节点发送心跳报告，默认是每隔3秒发送一次心跳信息
心跳信息包含这个节点的状态以及数据块信息
如果 Namenode 10分钟都没收到 Datanode 的心跳，则认为其已经lost，那么Namenode会
copy这个Datanode 上的 Block 到其他 Datanode 上 [root@node01 dfs]# tree
在HDFS中，Datanode 上存储的复本 Replication 是多复本策略。默认是三个，我们配置的是 2
个
如果是伪分布式模式，副本只能配置1个，因为如果副本数量 >1，会导致HDFS一致处于安全模式
而不能退出

2.1.4 SecondaryNamenode

SecondaryNamenode 并不是 Namenode 的热备份，而是协助者帮助 Namenode 进行元数据的
合并，
合并过程可能会造成极端情况下的数据丢失，此时可以从 SecondaryNamenode 中恢复部分数
据，但是无法恢复全部
SecondaryNamenode 是 Hadoop1.X 机制。Hadoop2.X 已经弃用。如果是Hadoop2.X 的伪分布
式，还是会看到 SecondaryNamenode 进程；如果是Hadoop2.X的完全分布式，
SecondaryNamenode已经舍弃，但是如果配置了，依然存在。
合并时机：
根据配置文件设置的时间间隔：
dfs.namenode.checkpoint.period：默认设置为1小时，指定两个连续检查点之间的最大延
迟
根据 Namenode 上未经检查的事务的数量
dfs.namenode.checkpoint.txns：默认设置为1百万。如果尚未达到检查点周期，将强制紧
急检查点。
当HDFS启动时候,也会触发合并
可以通过指令手动合并
合并过程：
达到条件后 SecondaryNamenode 会将 Namenode 中的 fsimage 和 edits 文件通过网络拷
贝过来
同时 Namenode 中会创建一个新的edits.inprogress文件，新的读写请求会写入到这个
edits.inprogress中 hadoop dfsadmin -rollEdits
在SecondaryNamenode中，会将拷贝过来的fsimage和edits加载到内存中，将数据进行合
并，然后将合并后的数据写到一个新的文件fsimage.ckpt中
最后SecondaryNamenode将合并完成的fsimage.ckpt文件拷贝回Namenode中替换之前的
fsimage，同时Namenode再将edtis.inprogress重命名为edits

.2.2 Block复本放置策略

第一个副本：如果是集群内部提交，那么哪一个DataNode 提交的就将该复本放在哪个节点上。如
果是集群之外的客户端上传的数据，那么就随机选择一台磁盘不太满，cpu不太忙的节点进行存储
第二个副本：放置在第一个复本不同机架的节点上
第三个副本：放置在与第二个副本相同机架的节点上
更多副本：随机节点(哪个节点比较空闲，就放到哪个节点上)

2.3 机架感知策略（了解）

所谓的机架感知策略中的机架指的是逻辑机架而不是物理机架
逻辑机架本质上就是一个映射关系，可以通过shell或者Python脚本指定
可以将不同物理机架上的节点配置在同一个逻辑机架上
习惯上，会将同一个同一个物理机架或者是同一个用户组内的节点配置在同一个逻辑机架上

.2.4 HDFS 写入数据流程

2.5 HDFS 读取数据流程

3 HDFS Shell操作

3.1 基本命令

3.2 其他命令