Hadoop学习——hdfs分布式文件系统
1、HDFS
1.1 介绍
来源于google的论文《Google File System》
1.2 HDFS特点
- 分布式存储架构，支持海量数据存储。（GB、TB、PB级别数据）
- 高容错性，数据块拥有多个副本（副本冗余机制）。副本丢失后，自动恢复。
- 低成本部署，Hadoop可构建在廉价的服务器上。
- 能够检测和快速应对硬件故障，通过RPC心跳机制来实现。
- 简化的一致性模型，这里指的是用户在使用HDFS时，所有关于文件相关的操作，比如文件切块、块的复制、块的存储等细节并不需要去关注，所有的工作都已被框架封装完毕。用户所需要的做的仅仅是将数据上传到HDFS。这大大简化了分布式文件存储操作的难度和管理的复杂度。
- HDFS不能做到低延迟的数据访问（毫秒级内给出响应）。但是Hadoop的优势在于它的高吞吐率（吞吐率指的是：单位时间内产生的数据流）。可以说HDFS的设计是牺牲了低延迟的数据访问，而获取的是数据的高吞吐率。如果要想获取低延迟的数据访问，可以通过Hbase框架来实现。
- HDFS不许修改数据，所以适用场景是：一次写入，多次读取（once-write-many-read）。注意：HDFS允许追加数据，但不允许修改数据。追加和修改的意义是不同的。
- HDFS不支持并发写入，一个文件同一个时间只能有一个写入者。
- HDFS不适合存储海量小文件，因为会浪费namenode服务节点的内存空间。（元数据信息一般在）
2、HDFS主要内容
HDFS是一个分布式、可扩展、可靠的文件系统。
2.1 namenode
HDFS的namenode称为名字节点，主要职责如下：
（1）管理HDFS的元数据信息(meta data)。
元数据信息包含：文件名、文件大小、被切成几块、每一个块的副本数量、
块id以及块存储在哪台datanode上`。
（2）通过`RPC`心跳机制来检测`datanode`节点状态。 namenode会将元数据信息存储到namenode服务器的内存中一份，目的是供用户快速查询。此外因为元数据信息特别重要，所以，namenode还会把元数据持久化到本地磁盘。
2.2 secondarynamenode
hadoop1.0时，secondarynamenode即snn的作用不仅仅是namenode的备用节点，还承担了namenode的元数据文件的合并。通过这种机制，可以使得nn和snn都具有元数据。另外，nn宕机后，snn可以接替nn继续工作。具体下图：
注意：
snn这种元数据的合并机制，是存在问题的，因为可能会有元数据丢失的情况。
snn机制是hadoop 1.0机制，在hadoop2.0时已经弃用。
如果是hadoop2.0伪分布式，还是会看到snn进程。
如果是hadoop2.0的完全分布式，snn机制已经舍弃。
snn机制存在问题在于它没有达到元数据实时热备，会造成元数据丢失。
所以hadoop1.0的namenode还是存在单点故障问题。hadoop1.0时secondaryname会每整点去合并namenode的edit和fsimage文件，即有一个同步点，比如3点合并了一次，下次是在4点合并，但是如果在中间namenode挂掉了，那4点合并的时候就会丢失namenode挂掉之前的数据。
2.3 datanode
datanode由namenode管理，datanode是通过心跳机制来主动连接namenode。
datanode定时3s向namenode发送心跳信息，节点的状态信息（节点是否还能够提供服务），节点存储的数据信息。
如果超过一定的时间（10min），namenode依然没有收到datanode的心跳信息，认为datanode已经lost
2.4 元数据
元数据持久化的目录路径，是由core-site.xml的dfs.tmp.dir属性来决定的。此参数如果不配置，默认是放在linux系统的/tmp文件夹中，因此必须要配置这个路径。
元数据存储会有两个文件，edit和fsimage文件。edit文件存储HDFS的操作记录，每次有事务操作时，edits会存储，相当于zookeeper的事务log文件;fsimage存储的是整个HDFS的状态，相当于zookeeper快照文件。edits和fsimage会定期合并，合并周期是3600s,即一个小时。注意：元数据存储在fsimage文件中。这两个文件的查看路径在指定dfs.tmp.dir指定的路径中的dfs/name/current文件夹中。
另外，无论是1.0还是2.0，当hdfs启动时，都会做一次edit和fsimage文件的合并。因为自动合并是每次一个小时，如果中间断掉那没有合并，在启动后做一次合并，目的是确保fsimage文件中数据最新。也可以手动合并，命令参考下表。
2.5 不轻易格式化
格式化时命令时，会清空所有以前的元数据，因此格式化命令也非常危险。一般会通过配置文件的方式让这个指令失效。
2.6 hdfs安全模式
当启动hdfs后，每个datanode都会向namenode汇报自身的存储信息，比如存储哪些块，块大小,块id等，namenode收到后，会监测数据是否完整，副本数量是否达到要求，如果监测出现问题，hdfs会进入安全模式，在安全模式做数据或副本的复制，直到修复完成后，安全模式自动退出。
如果hdfs处于安全模式后，只能对外提供读服务，不能写。
如果是伪分布式模式，副本只能设置成1，因为如果副本大于1，会导致hdfs一直处于安全模式而不能退出。
2.7 hdfs块大小
hdfs存储数据的方式是块存储。
hadoop 1.0 切块大小默认 64MB
hadoop 2.0 切块大小默认 128MB注意，切块是以文件为单位，不同的文件不能共用一个文件块。此外，块的内容多大，在磁盘上就占多大。小于默认切块大小，则只占一块，如果大于则需要切块存储。
2.8 hdfs 存储文件的要求
当把一个文件上传到hdfs后，是不允许修改文件的。因为修改属于随机写操作。
hdfs的使用场景是，一次写多次读。
hadoop 2.0,允许追加文件数据，注意，追加操作不同于修改。
hdfs不适合存储海量小文件。因为每上传一个文件，namenode就会用一条元数据来管理，根据经验，一条元数据大约150Kb,所以，上传海量小文件时，会占用namenode节点的内存。
3、常用hdfs命令
命令 | 作用 |
| 创建文件夹 |
| 查看hadoop根路径下的文件 |
| 将当前路径下的1.txt上传到hadoop分布式文件系统中的 |
| 看 |
| 将 |
| 删除 |
| 递归删除 |
| 查看 |
| 如果文件太大，查看可以使用 |
| 将 |
| 在 |
| 将 |
| 递归查看 |
| 手动合并 |
| 离开安全模式 |
| 进入安全模式（进入后只能读不能写） |
4、hadoop切块
默认切块大小为128M，当上传的文件少于128M，不管多小，则会占128M，大于128M时，则会分块，即每128M存一部分。
4.1 切块存储位置
在hadoop安装目录下的etc/hadoop文件夹中，有个core-site.xml文件中配置的hadoop.tmp.dir指定的路径里有个tmp文件夹。
在这个tmp文件夹中可以找到切块的位置，路径为tmp/dfs/data/current/[blockId,BP开头的文件]/VERSION/current/finalized/subdir0/subdir0中，比较深，可以看到有meta元数据信息
4.2 命令查找切块
hadoop fsck /park01/hadoop-2.7.1.tar.gz -files -blocks -locations 命令也可以用来查看元数据的信息。
5、hadoop配置开启回收站
当删除某个文件时，如果再想查看是看不到的，所以需要配置回收站。
2.0版本后，hadoop有回收站功能，hadoop回收站trash,默认是关闭的。找到hadoop安装目录下的etc/hadoop/core-site.xml，打开后在<configuration>标签内,添加如下内容：
<!--默认value为0,即保存0分钟，相当于关闭，1440分钟，周期单位为分钟-->
<property>
<name>fs.trash.interval</name>
<value>1440</value>
</property> 配置完之后，可以用hadoop fs -rmr /park02即会看到打印出来的日志中有类似于下边的话：
Moved: `hdfs://hadoop01:9000/park02` to trash at：
hdfs://hadoop01:9000/user/root/.Trash/Current6、hadoop推荐书籍
- 《google file system 中文版》。
- 《hadoop 权威指南》。
