大数据系列之hadoop第二天（hadoop命令及HDFS存储原理）

前言：大数据系列包括hadoop，zookeeper，hive，flume，kafka，hbase，storm，spark等组件，我在这里会很详细跟大家分享集群的搭建和全部组件的使用，会有具体的案例。

Hadoop-HDFS命令

 

命令	说明
1.执行：hadoop  fs -mkdir /park	在hdfs 的根目录下，创建  park目录
2.执行：hadoop  fs  -ls  /	查看hdfs根目录下有哪些目录
3.执行：hadoop  fs -put  /root/1.txt  /park	将linux操作系统root目录下的1.txt放在hdfs的park目录下
4.执行：hadoop  fs -get  /park/jdk  /home	把hdfs文件系统下park目录的文件下载到linux的home目录下
5.执行：hadoop fs -rm /park/文件名	删除hdfs 的park目录的指定文件
6.执行：hadoop fs -rmdir /park	删除park目录，但是前提目录里没有文件
7.执行：hadoop fs -rmr /park	删除park目录，即使目录里有文件
8.执行：hadoop fs -cat /park/a.txt	查看park目录下的a.txt文件
9.执行：hadoop fs -tail /park/a.txt	查看park目录下a.txt文件末尾的数据
10.执行：haddop jar  xxx.jar	执行jar包
11.执行：hadoop fs -cat /park/result/part-r-00000	查看 /park/result/part-r-00000文件的内容
12.执行：hadoop  fs  –mv  /park02  /park01	将HDFS上的park02目录重名为park01命令。
13.执行：hadoop  fs -mv /park02/1.txt /park01	将park02目录下的1.txt移动到/park01目录下
14.执行：hadoop fs -touchz /park/2.txt	创建一个空文件
15.执行：hadoop fs -getmerge    /park    /root/tmp	将park目录下的所有文件合并成一个文件，并下载到linux的root目录下的tmp目录
16.执行：hadoop dfsadmin -safemode leave 离开安全模式   执行：hadoop dfsadmin -safemode enter 进入安全模式	离开hadoop安全模式   在重新启动HDFS后，会立即进入安全模式，此时不能操作hdfs中的文件，只能查看目录文件名等，读写操作都不能进行。 namenode启动时，需要载入fsimage文件到内存，同时执行edits文件中各项操作一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件（这个步骤不需要SNN的参与）和一个空的编辑文件。 此时namenode文件系统对于客户端来说是只读的。 在此阶段NameNode收集各个DataNode的报告，当数据块达到最小复本数以上时，会被认为是“安全”的，在一定比例的数据块被确定为安全后，再经过若干时间，安全模式结束 当检测到副本数不足的数据块时，该块会被复制直到到达最小副本数，系统中数据块的位置并不是namenode维护的，而是以块列表的形式存储在datanode中。   当启动报如下错误时: org.apache.hadoop.dfs.SafeModeException: Cannot delete /user/hadoop/input. Name node is in safe mode
17.执行：hadoop dfsadmin -rollEdits	手动执行fsimage文件和Edis文件合并元数据
18.执行：hadoop dfsadmin -report	查看存活的datanode节点信息
19.执行：hadoop fsck  /park	汇报/park目录 健康状况
20.执行：hadoop fsck /park/1.txt  -files  -blocks -locations  -racks	查看1.txt 这个文件block信息以及机架信息
21.hadoop fs -expunge	手动清空hdfs回收站

 

其他指令

命令	说明
hadoop  fs -cp  /park01/1.txt  /park02	将HDFS上 /park01下的1.txt拷贝一份到 /park02目录下。 目标路径可以有多个，用空格隔开，比如： hadoop fs -cp /park01/1.txt  /park02  /park03……
hadoop fs -du /park/1.txt	查看HDFS上某个文件的大小。也可以查看指定目录，如果是目录的话，则列出目录下所有的文件及其大小，比如： hadoop fs -du /park
hadoop fs -copyFromLocal  /home/1.txt  /park01	将本地文件1.txt上传到/park01目录下
hadoop fs -copyToLocal /park01/1.txt  /home	将HDFS上的1.txt 拷贝到本地文件系统
hadoop  fs -lsr  /	递归查看指定目录下的所有内容

知识点

1.HDFS的来源，来源于《Google File System》

2.HDFS是一个分布式的，可扩展，可靠的文件系统。

3.HDFS的namenode称为名字节点，主要职责：

①管理HDFS的元数据信息（meta data）,文件名，文件大小，被切成几块，每一个块的副本数量，块id，块大小，以及块存储在哪台datanode上

 

②通过RPC心跳机制来检测datanode节点的状态。

4.namenode会将元数据信息存储到namenode服务器的内存中一份，目的是供用户快速查询。此外，因为元数据信息特别重要，所以namenode还会把元数据持久化到本地磁盘上。

5.元数据持久化的目录路径，是由core-site.xml的dfs.tmp.dir属性来决定的。此参数如果不配置，默认是放在/tmp，所以必须要配。

6.namenode用两个文件来存储元数据信息：

①Edits文件  =>存储HDFS的操作记录

②Fsimage文件 =>存储是整个HDFS的状态（相当于快照文件）

Edits和Fsimage会定期合并（是在SNN中合并），合并周期是3600s（1小时），即Fsimage文件存储的是HDFS的元数据信息。

这两个文件的查看路径：hadoop-2.7.1/tmp/dfs/name/current

7.格式化指令：hadoop  namenode -format

这个指令在初次使用HDFS时，需要执行一次。需要注意：此指令非常危险，因为会清空之前所有的元数据信息。

一般会通过配置文件的方式让这个指令失效。

8.HDFS的启动指令：

① start-dfs.sh =>启动所有和HDFS相关的进程，比如namenode,datanode,secondarynamnode

②hadoop-daemon.sh start secondarynamenode | namnode | datanode

9.停止指令：

①stop-dfs.sh

②hadoop-daemon.sh stop secondarynamenode | namnode | datanode

③kill -9 进程id

 

10.SNN的作用不仅仅是namenode的备用节点，还承担了namenode的元数据文件的合并。通过这种机制，可以使得NN和SNN都具有元数据信息。就NN宕机后，SNN可以接替NN继续工作。

注意：SNN这种元数据的合并机制，是存在问题的。因为可能会早元数据丢失的情况。SNN机制是Hadoop1.0机制。Hadoop2.0已经弃用。

如果是Hadoop2.0的伪分布式，还是会看到SNN进程

如果是Hadoop2.0的完全分布式，SNN机制已经舍弃

总结：SNN机制存在问题在于它没有达到元数据实时热备，会造成元数据丢失。所以Hadoop1.0的namenode还是存在单点故障问题。

11.无论是Hadoop1.0还是2.0，当HDFS启动,namenode会做一次Edits和Fsimage合并的操作。这样做的目的是确保fsimage里的元数据更新。

12.可以通过指令手动合并：hadoop dfsadmin -rollEdits

13.当HDFS启动时，每个datanode会向namenode汇报自身的存储的信息，比如存储了哪些文件块，块大小，块id等。namenode收到这些信息之后，会做汇总和检测，检测数据是否完整，副本数量是否达到要求，如果检测出现问题，HDFS会进入安全模式，在安全模式做数据或副本的复制，直到修复完成后，安全模式自动退出。

14.如果HDFS处于安全模式，只能对外读服务，不能写服务。

15.如果是伪分布式模式，副本只能配置1个，因为如果>1，会导致HDFS一致安全模式而不能退出

16.HDFS存储数据的方式是块存储。

Hadoop1.0  切块大小 64MB

Hadoop2.0 切片大小 128MB

例子：1.txt(100MB)  2.txt(100kb)  3.txt(257MB) ，设定副本数量=1

问HDFS集群上总的文件块？

1.txt=1块（100MB)

2.txt=1块(100kb)

3.txt=1块（128MB) 2块（128MB) 3块（1MB)

注意：切块是以文件为单位，不同的文件不能共用一个文件块。此外，文件多大，块就多大（一个块的上限是128M），在磁盘上占多大。

17.存储文件块的服务器叫datanode(数据节点），存储数据块的目录：tmp/dfs/data/current/BP-1998993700-192.168.150.137-1537051327964/current/finalized/subdir0/subdir0

18.当把一个文件上传到HDFS之后，是不允许修改文件的，因为修改操作属于随机写操作。

19.HDFS的适用场景 ：once-write-many-read

20.Hadoop2.0，允许追加文件数据，注意：追加操作不同于修改。

21.问：HDFS是否适合存储海量小文件？

答案是：不适合。

每当上传一个文件，namenode就会用一条元数据来管理。根据经验，一条元数据大约150字节，所以，当上传海量小文件时，会占用namenode的内存资源。

 

HDFS存储原理

Edits和Fsimage文件

知识点(Edits和Fsimage这两个文件是在namenode中)

1.当执行格式化指令时 ，会在指定的tmp目录下，生成dfs/name目录。

此目录是namenode服务器存储元数据的目录

2.当格式化后，启动HFDS前，会生成一个最初的fsimage_0000000000000000000文件

3.在 dfs/data目录，这是datanode节点存储数据块的目录。

4.元数据的存储目录和数据节点的目录的路径可以分开指定

5.在dfs/name/in_use.lock ，这个文件的作用是防止在同一台服务器上启动多个namenode,避免管理紊乱。

6.当启动HDFS时，会生成Edits文件。

7.HDFS有事务id的概念，当HDFS每接收一个事务操作（比如：mkdir put mv），都会分配响应的事务id，然后写到Edits文件中。

Persistent Transaction IDs

One of the subtasks of HDFS-1073 is HDFS-1521, which makes the transaction IDs persist across restarts of

the NameNode. That is to say, the first edit on a newly formatted NN will have transaction ID 1, and that

ID will never be reused for the lifetime of the namesystem (even after restarts and checkpoints).

8.每生成一个新的Edits文件，Edits文件中都会以BEGIN LOG 开头，当一个Edits文件写完后，会以END LOG结尾。即在BEGIN LOG  ——END LOG 存储的是这个Edits文件所有的事务记录

8.1. OP BEGIN LOG SEGMENT - this transaction is written at the start of every new edit log file. It currently

contains no data, but may later contain some special checkpointing information or metadata about the

namespace.

8.2. OP END LOG SEGMENT - this transaction is written at the end of an edit log before it is closed. This is

used as a sanity check that the log was gracefully closed, and is also useful to allow the BackupNode

to synchronize its log roll with the primary NameNode. In the future it might be extended to include

some kind of checksum information about the log file.

9.edits_inprogress文件的作用是记录当前正在执行的事务文件。后面的编号是以上一次Txid+1来命名的。

10.初次使用HDFS时，有一个默认的Edits和Fsimage的合并周期（1分钟），以后在使用HDFS的过程中，edits_inprogress合并的条件：①到达合并周期（3600s) ②执行手动合并指令 ③停止HDFS再启动HDFS

11.上传文件底层会拆分成如下的事务过程：

①OP_ADD 将文件加入到指定的HDFS目录下，并以._Copyging_结尾，表示此文件还未写完

②ALLOCATE_BLOCK_ID 为文件分配块ID

③SET_GENSTAMP_V2 为块生成时间戳版本号，是全局唯一的

④ADD_BLOCK 写块数据

⑤OP_CLOSE  表示块数据写完

⑥OP_RENAME_OLD 将文件重命名，表示写完

12.当停止HDFS在启动HDFS,执行一个事务（比如事务A）后，底层会触发一次rollEdits指令，会触发END LOG事务，然后会生成一个新的Edits。而事务A会记录在下一个Edits。

Edits和Fsimage的合并机制为：

When an image is saved or uploaded via a checkpoint, the validity rule is as follows: any fsimage with

txid N must incorporate all edits from logs containing earlier transaction IDs. So, if we enter safe mode and

call saveNamespace on the above example, we end up with:

12.1. fsimage 0 - original empty imagge

12.2. edits 1-10 - edits before first roll

12.3. edits 11-12 - edit log containing special BEGIN LOG SEGMENT and END LOG SEGMENT transactions but

no actual namespace changes.

12.4. fsimage 12 - all edits from both edit logs have bee incorporated into namespace

12.5. edits inprogress 13 - the edit log where new edits will be appended

13.seen_txid记录是的最新的edits_inprogress文件末尾的数字

14.Fsimage_N文件存储的N号事务前的所有的元数据信息

15.fsimage_0000000000000000002.md5存储的是Fsimage文件的md5校验码

 

注：下一篇分享HDFS api代码及原理