一、简介HDFS——Hadoop分布式文件存储系统
一、概述
- 全称为Hadoop Distributed File System ，Hadoop分布式文件存储系统
- HDFS是根据谷歌的论文：《The Google File System》进行设计的
- 本身是一个分布式的，可扩展，可靠的文件系统
- HDFS中包含三个主要的进程：NameNode，DataNode，SecondaryNameNode。这三个进程一般是分布式不同的主机上，所以一般习惯上是用进程的名字称呼节点
二、特点
- 优点：
- 支持超大文件。超大文件在这里指的是几百M，几百GB，甚至几TB大小的文件。一般来说Hadoop的文件系统会存储TB级别或者PB级别的数据。所以在企业的应用中，数据节点有可能有上千个
- 检测和快速应对硬件故障。在集群的环境中，硬件故障是常见的问题。因为有上千台服务器连接在一起，这样会导致高故障率。因此故障检测和自动恢复(心跳机制)是HDFS文件系统的一个设计目标
- 流式数据访问。HDFS的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据集。主要的是数据的吞吐量，而不是访问速度
- 简化的一致性模型。大部分hdfs操作文件时，需要一次写入，多次读取。在HDFS中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了。这样简单的一致性模型，有利于提高吞吐量
- 高容错性。数据自动保存多个副本，副本丢失后自动恢复
- 可构建在廉价机器上。构建在廉价机器上可以轻松的通过扩展机器数量来近乎线性的提高集群存储能力
- 缺点：
- 不能低延迟数据访问。如和用户进行交互的应用，需要数据在毫秒或秒的范围内得到响应。由于Hadoop针对海量数据的吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟来说，不适合用hadoop来做
- 不适合存储小文件。HDFS支持超大的文件，是通过数据分布在数据节点，数据的元数据保存在名字节点上。名字节点的内存大小，决定了HDFS文件系统可保存的文件数量。虽然现在的系统内存都比较大，但大量的小文件还是会影响名字节点的性能
- 不支持多用户写入、修改文件。HDFS的文件只能有一次写入，不支持修改和追加写入（2.0版本支持追加），也不支持修改。只有这样数据的吞吐量才能大
- 不支持事务。没有像关系型数据库那样，对事务有强有力的支持
二、HDFS进程技术细节介绍
一、概述
- HDFS中，存储数据的时候会将数据进行切块，每一个块称之为Block
- HDFS中，主要包含2个重要的进程：NameNode和DataNode
- NameNode用于管理节点和记录元数据(metadata)
- DataNode是用于存储数据
- HDFS会对数据自动进行备份，称之为副本（replication）。如果不指定，默认情况下副本数量为3(额外复制两次，加上原来的数据构成3个副本)
- HDFS仿照Linux设计了一套文件存储系统
二、Block
- 数据块（Block）是HDFS中数据的最基本的存储单位
- 当在HDFS上存储超大文件时，HDFS会以一个标准将文件切分成几块，分别存储到不同的节点上，切出的数据就称为Block
- Block 默认的大小在Hadoop1.0中是64M，在Hadoop2.0中是128M
- 切块的优点：
- 文件块可以保存在不同的节点上，能够存储超大文件
- 有利于数据的复制，便于快速备份
- 在HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间
三、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大小
- 元数据信息存储在内存以及文件中。其中内存中为实时信息，这样做的目的是为了快速查询；磁盘中的信息不是实时的，存储在磁盘上的目的是为了崩溃恢复
- 元数据信息会持久化到NameNode节点的硬盘上，持久化目录的路径是由core-site.xml的dfs.tmp.dir属性来决定的。此参数如果不配置，默认是放在/tmp
- 存储元数据的目录：dfs/name/current
- 持久化的文件包括：
- fsimage：元数据镜像文件。存储某NameNode元数据信息，并不是实时同步内存中的数据。一般而言，fsimage中的元数据是落后于内存中的元数据的
- edits：操作日志文件,记录了NameNode所要执行的操作
- 当有写请求时，NameNode会首先写该操作先写到磁盘上的edits文件中，当edits文件写成功后才会修改内存，内存修改成功后向客户端返回成功信号，而此时fsimage中的数据并没有发生改动。所以，fsimage中的数据并不是实时的数据，而是在达到条件时再进行更新
- 在Hadoop2.0的集群中，如果存在SecondaryNameNode，则更新过程需要SecondaryNameNode参与；如果不存在SecondaryNameNode，则更新过程发生在NameNode上
- 无论是Hadoop1.0还是2.0，当HDFS启动,NameNode会做一次edits和fsimage合并的操作。这样做的目的是确保fsimage里的元数据更新
- NameNode通过RPC心跳机制来检测DataNode
- 当HDFS启动的时候，NameNode会将fsimage中的元数据信息加载到内存中，然后等待每个DataNode向NameNode汇报自身的存储的信息，比如存储了哪些文件块，块大小，块id等。NameNode收到这些信息之后，会做汇总和检测，检测数据是否完整，复本数量是否达到要求，如果检测出现问题，HDFS会进入安全模式，在安全模式做数据或副本的复制，直到修复完成后，安全模式自动退出
- 如果HDFS处于安全模式，只能对外读服务，不能写服务
- 在Hadoop1.0中，NameNode存在单点故障问题。在Hadoop2.0的伪分布式中，NameNode依然存在单点故障，但是在Hadoop2.0的全分布式中，可以通过舍弃SecondaryNameNode的方式来配置2个NameNode来保证NameNode的高可用
四、DataNode
- 在HDFS中，数据是存放在DataNode上面的，并且是以Block的形式存储的
- 存储Block的目录：dfs/data/current/BP-1998993700-192.168.150.137-1537051327964/current/finalized/subdir0/subdir0
- 在HDFS启动的时候，每个DataNode将当前存储的数据块信息告知NameNode节点
- 之后，DataNode节点会不断向NameNode节点发送心跳报告，默认是每隔3秒发送一次心跳信息
- 心跳信息包含这个节点的状态以及数据块信息
- 如果NameNode10分钟都没收到DataNode的心跳，则认为其已经lost，那么NameNode会copy这个DataNode上的Block到其他DataNode上
- 在HDFS中，DataNode上存储的复本Replication是多副本策略。默认是三个
- 如果是伪分布式模式，副本只能配置1个，因为如果副本数量>1，会导致HDFS一致处于安全模式而不能退出
五、SecondaryNameNode
- SecondaryNameNode并不是NameNode的热备份，而是协助者帮助NameNode进行元数据的合并，
- 合并过程可能会造成极端情况下的数据丢失，此时可以从SecondaryNameNode中恢复部分数据，但是无法恢复全部
- SecondaryNameNode是Hadoop1.0机制。Hadoop2.0已经弃用。如果是Hadoop2.0的伪分布式，还是会看到SecondaryNameNode进程；如果是Hadoop2.0的完全分布式，SecondaryNameNode已经舍弃
- 合并时机：
- 根据配置文件设置的时间间隔：fs.checkpoint.period 默认3600秒
- 根据配置文件设置的edits log大小 fs.checkpoint.size 默认64MB
- 当HDFS启动时候,也会触发合并
- 可以通过指令手动合并：hadoop dfsadmin -rollEdits
- 合并过程：
- 达到条件后 SecondaryNameNode会将nn中的fsimage和edits文件通过网络拷贝过来
- 同时NameNode中会创建一个新的edits.new文件，新的读写请求会写入到这个edits.new中
- 在SecondaryNameNode中，会将拷贝过来的fsimage和edits加载到内存中，将数据进行合并，然后将合并后的数据写到一个新的文件fsimage.ckpt中
- 最后SecondaryNameNode将合并完成的fsimage.ckpt文件拷贝回NameNode中替换之前的fsimage，同时NameNode再将edtis.new重命名为edits
六、Block副本放置策略
- 第一个副本：如果是集群内部提交，那么哪一个DataNode提交的就将该复本放在哪个节点上。如果是集群之外的客户端上传的数据，那么就随机选择一台磁盘不太满，cpu不太忙的节点进行存储
- 第二个副本：放置在第一个复本不同机架的节点上
- 第三个副本：放置在与第二个副本相同机架的节点上
- 更多副本：随机节点(哪个节点比较空闲,就放到哪个节点上)
七、扩展：机架感知策略
- 所谓的机架感知策略中的机架指的是逻辑机架而不是物理机架
- 逻辑机架本质上就是一个映射关系，可以通过shell或者Python脚本指定
- 可以将不同物理机架上的节点配置在同一个逻辑机架上
- 习惯上，会将同一个同一个物理机架或者是同一个用户组内的节点配置在同一个逻辑机架上
三、HDFS回收站机制
一、概述
- 在HDFS中，回收站机制默认是关闭的，即从HDFS上删除文件的时候是立即删除的
- 可以通过配置来手动开启回收站，指定被删除文件的保留时间
二、配置
- 进入Hadoop的安装目录下的子目录etc/hadoop：cd hadoop-2.7.1/etc/hadoop
- 配置core-site.xml
- 编辑core-site.xml：vim core-site.xml
- 添加如下内容：
<property>
<name>fs.trash.interval</name>
<value>1440</value>
</property>
- 保存退出： wq
三、注意事项·
- 回收站的配置中，value的时间单位是分钟。如果配置程0，则表示不开启HDFS的回收站机制。
- 配置为1440表示回收间隔为1天，即文件在回收站存在1天后，会被清除
- 可以通过递归查看指令，查看回收站中的文件：hadoop fs -lsr /user/root/.Trash
- 如果想恢复被删除的文件，执行hdfs 的mv 指令即可
四、DFS目录介绍
一、概述
- dfs目录表示HDFS的存储目录
- dfs/name表示NameNode的持久化目录
- dfs/data表示DataNode的存储目录
- dfs/namesecondary表示SecondaryNameNode的存储目录
- 实际过程中，由于NameNode、DataNode以及SecondaryNameNode应该分布在不同的节点上，所以name、data、nameseconda三个目录也应该出现在不同的节点上
- 当执行格式化指令时，会在指定的数据目录下，生成dfs/name目录
- 当格式化后，启动HDFS前，会生成一个最初的fsimage_0000000000000000000文件，该文件中存储的根节点的信息
- dfs/name/in_use.lock文件的作用是防止在同一台服务器上启动多个NameNode，避免管理紊乱
- 当启动HDFS时，会生成edits文件
- HDFS中有事务id的概念，当HDFS每接收一个写操作（比如：mkdir put mv），都会分配全局递增的事务id，然后写到edits文件中
- 每生成一个新的edits文件，edits文件中都会以OP_START_LOG_SEGMENT开头，当一个edits文件写完后，会以OP_END_LOG_SEGMENT结尾。即在OP_START_LOG_SEGMENT- OP_END_LOG_SEGMENT存储的是这个edits文件所有的事务记录
- edits_inprogress文件的作用是记录当前正在执行的事务文件。后面的编号是以上一次Txid+1来命名的
- 初次使用HDFS时，有一个默认的edits和fsimage的合并周期（1分钟），以后在使用HDFS的过程中，达到条件edits_inprogress会和fsimage进行合并
- 上传文件底层会拆分成如下的事务过程：
- OP_ADD 将文件加入到指定的HDFS目录下，并以._Copyging_结尾，表示此文件还未写完
- ALLOCATE_BLOCK_ID 为文件分配块ID
- SET_GENSTAMP_V2 为块生成时间戳版本号，是全局唯一的
- ADD_BLOCK 写块数据
- OP_CLOSE 表示块数据写完
- OP_RENAME_OLD 将文件重命名，表示写完
- 当停止HDFS后再次启动HDFS时，当执行一个事务之后，底层会触发一次合并，然后生成一个新的edits文件
- seen_txid记录是的最新的edits_inprogress文件末尾的数字
- fsimage_N文件存储的N号事务前的所有的元数据信息
- fsimage_N.md5存储的是fsimage文件的md5校验码，可以通过MD5的校验和来校验文件的完整性：md5sum fsimage_n
二、edits文件和fsimage文件
- 查看edits文件：hdfs oev -i edits文件 -o xxx.xml。例如：hdfs oev -i edits_0000000000000000001-0000000000000000003 -o edits.xml
- 查看fsimage文件：hdfs oiv -i fsimage文件 -o xxx.xml -p XML。例如：hdfs oiv -i fsimage_0000000000000000012 -o fsimage.xml -p XML
- fsimage介绍:fsimage是一个二进制文件，当中记录了HDFS中所有文件和目录的元数据信息。