hadoop学习笔记（一）

                               HDFS概述

HDFS简介

HDFS其实是Hadoop分布式文件系统，是谷歌公司GFS分布式文件系统的开源实现，同时也是Aapche Hadoop项目的一个子项目 。 HDFS通过构建一个能跨越计算机系统或网络系统的单一的文件命名空间(即统一的文件目录结构，在NameNode节点上），实现大数据文件（如PB级）的分布式存储。用户可以通过HDFS的终端命令操作其中的文件，也可以通过HDFS API或MapReduce来编程访问其中的文件数据。这三种方法，后面会进行介绍。

HDFS优点

• 支持大文件的存储
• 支持流式的访问数据
• 运行在廉价的商用机器集群上

HDFS缺点

• 不适合低延迟数据访问
  HDFS是用于处理大规模数据集分析任务的，主要是为了达到高数据吞吐量而设计的，这就可能要求以高延迟作为代价。对于那些有低延迟要求的应用程序，Hbase或Spark是一个更好的选择，它们使用缓存或多个master设计来降低客户端的数据请求压力，以减少延时。

• 无法高效存储大量小文件
  因为NameNode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由NameNode的内存大小来决定的。此外，由于map任务的数量是由数据块的分片数(splits)来决定的，因此在MapReduce处理大量的小文件时（文件大小小于128MB），由于FileInputFormat不会对小文件进行切分，所以每一个小文件都会被当成一个切片（split）并分配一个map任务，从而效率低下。

• 不支持多用户写入和任意修改文件
  在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作，目前HDFS还不支持多个用户对同一文件的写操作。

数据块

HDFS支持文件的“一次写入，多次读取”模型，默认的数据块大小是128MB（在hadoop-2.2版本之前，默认为64MB），所以HDFS中的文件总是按照128MB被切分成不同的数据块。在这里需要注意，虽然HDFS的目录结构与Windows系统中的目录结构都是树状结构，但数据块保存的形式不同。在Windows中，若文件的字节数小于数据块的大小，那么这个这个文件将占据整个数据块，导致存储空间的浪费。而在HDFS，会将小文件进行整合，从而字节数小于数据块的文件，并不会占据整个数据块，同时也可以看出，当一个大文件被切分成若干个小文件之后，最后一个文件的大小可能会与前面的文件不一样。

元数据节点（NameNode）

NameNode的作用：管理分布式文件系统的命名空间，并将所有的文件和目录的元数据保存到Linux本地文件系统的目录（由dfs.namenode.name.dir参数指定）之中。NameNode中的相关文件如下图所示：

说明：

1）VERSION。该文件是NameNode进程的java属性文件，它保存了HDFS命名空间的ID，HDFS集群的ID等信息

2）seen_txid。用来存放transactionID,代表一系列edits文件的尾数，文件系统格式化成功时初值为0.NameNode重启时会从0001开始循环，直到达到seen_txid中的数字为止，循环比对该数字是不是edits文件的尾数，如果不是，则认为可能有元数据丢失。因此，该文件很重要，不能随便删改或修改其数据值。

3）fsimage。该文件是一个加密的二进制文件，保存了HDFS文件的元数据，内容包含NameNode管理的所有DataNode中的文件，数据块以及各数据块所在的DataNode的元数据信息等。
由图片可知，数据内容被加密。
4）edits。该文件用来临时存放HDFS文件的元数据，即：在客户端向HDFS写文件时，文件信息会首先记录在edits文件中，之后当时机成熟时（合并时机由fs.checkpoint.period参数和fs.checkpoint.size参数共同决定，前者默认是1h，后者默认是128MB）再由NameNode将数据合并到fsimage文件中。

数据节点（DataNode）

DataNode的作用：保存HDFS文件的数据内容。在客户端向HDFS写入文件时，大数据文件被切分成多个数据块，为了保证HDFS的高吞吐量，NameNode将这些数据块的存储任务指派给不同的DataNode。每个DataNode在接受到任务之后直接从客户端接收数据，跳过NameNode,经加密后写入到Linux本地系统的相应目录（由dfs.datanode.data.dir参数指定）之中。
客户端从HDFS读文件时，客户端首先访问NameNode,获得文件的每个数据块所在的DataNode信息，再连接这些DataNode，即可获得文件的数据内容。

辅助元数据节点（Secondary NameNode）

作用：周期性地将元数据节点的镜像文件fsimage和日志文件edit合并，以防日志文件过大。
Secondary NameNode并不是NameNode出现问题时的备份节点。
合并过程如下：

• Secondary NameNode请求NameNode停止使用edits，暂时将新的写操作放入一个新的文件中（edits.new）。
• Secondary NameNode从NameNode中通过HTTP GET获得edits，因为要和fsimage合并，所以也是通过HTTP GET的方式把fsimage加载到内存。
• 把edits的内容与fsimage的内容合并，生成新的fsimage。
• 通过HTTP POST的方式，把fsimage发送给NameNode.NameNode从Secondary NameNode获得了fsimage后会把原来的fsimage替换为新的fsimage,把edits.new变成edits。同时会更新seen_txid。

副本

为了容错（即防止因某个DataNode宕机，使某个数据块丢失，造成文件操作出错），HDFS文件的每个数据块都有若干个副本。每个文件的数据块大小和副本数量是可以配置的，副本个数可以在文件创建的时候指定，也可以在之后改变。
为了降低HDFS集群整体的带宽消耗和读取延时，HDFS会尽量让后台程序读取离它最近的副本，如果在读取程序所在的同一个机架上有一个副本，那么就读取该副本。