Hadoop之HDFS与小文件

Hadoop有一个名为“HDFS”的分布式文件系统，它的设计目的是提供一个高容错，且能部署在廉价硬件的分布式系统；它的设计参照了Google的GFS（Google分布式文件系统）；它能支持高吞吐量，适合大规模数据集应用。

HDFS上的文件被划分为以固定块大小的多个分块（默认为64MB，如此大是为了最小化寻址开销），每个块作一个独立的存储单元。

这样做有两个好处：第一可以存储容量大于单一磁盘容量的文件；第二大大简化了存储子系统的设计（只需要管理块，而且块的元数据并不需要与块一同存储）。将每个块复制到少数几个独立的机器上（默认为3个），可以确保在块、磁盘或机器发生故障后数据不会丢失（即发现一个块不可用，系统会从其他地方读取另一个复本，同时重新复制该复本到一台正常的机器上）。下图展示了这些特性。

HDFS集群由一个NameNode(管理者)和多个dataNode(工作者)组成。HDFS解决了单点问题，HDFS集群的管理者是非常重要。NameNode管理文件系统的命名空间，它维护着文件系统树及整颗树内所有的文件和目录，同时也记录着每个文件中各个块到DataNode。同时，NameNode（管理者）包含主要节点（Primary）和备份节点（Stand by），如果Primary出现问题，Stand By可自动接替Primary继续工作。DataNode主要负责响应文件系统客户端发出的读写请求，同时还将在NameNode的指导下负责执行文件的创建、删除以及复制。

Hadoop的MapReduce（分布式计算模型）处理框架正是基于HDFS构建，它充分利用集群的并行优势来处理存储在HDFS上的数据文件。一个MapReduce任务在集群上以任务跟踪（TaskTracker）执行。每个TaskTracker被Job监控，当发现一个TaskTracker执行失败是，JobTracker就会将该任务分配到其他机器上运行。

在运行MapReduce作业经常会遇到各种问题，为了能进行必要的优化，理解HDFS原理还是很有必要的。下面介绍比较常见的一种情况：小文件如何拖累MapReduce作业及可采取的优化措施。

在MapReduce作业中，Hadoop将其输入数据划分成等长的小数据块，称为输入分片。Hadoop为每个分片构建一个map任务，或者说每一个map操作只处理一个输入分片。每个分片被划分为若干个记录，每条记录就是一个键值对，map一个接一个地处理记录。输入分片包括自己的大小和存储位置，存储位置供MapReduce系统将map任务尽量放在分片附近，分片大小用于排序分片，以便优先处理最大的分片，从而最小化作业运行时间。

在一般的MapReduce作业中，使用最多的输入数据格式通常是存储在HDFS上的文件。Hadoop自带的FileInputFormat类是所有使用文件作为其数据源实现的基类。它提供两个功能：一个用于指出作业的输入文件位置；一个是输入文件生成分片的实现代码段。

一个文件如果大于HDFS的块大小，那么它会被分割成多个块，存储在不同的位置。如果分片的大小大于HDFS的块大小，那么一个分片就会从不同位置读取，需要通过网络传输到map任务节点，与使用本地数据运行整个map任务相比，这种方法效率更低。另一方面，如果分片切分得太小，那么管理分片的总时间和构建map任务的总时间将决定作业的整个执行时间。因此，对于大多数作业来说，一个合理的分片大小趋向于HDFS的一个块的大小，即64MB。