Hadoop实战(二) hadoop基本组成

一、Hadoop组件

        通常我们所理解的狭义Hadoop构成分为HDFS分布式存储系统和MapReduce编程模型两部分，下面分别从这两个部分介绍。

（一）HDFS

HDFS是一个分布式文件系统，下面主要介绍如何操作该文件系统。

1.基本命令行操作

hadoop fs -help

基本的操作都遵循这个模式，比如常用的  

hadoop fs -lshadoop fs -mkdir /test

有一个值得注意的是，HDFS操作的URI的基本结构：

2.编程读写

文件操作的包：org.apache.hadoop.fs

API起点是抽象类FileSystem

其中Configuration类用于保留键值对的配置参数。

（二）MapReduce

1.数据类型

        我们知道Hadoop可以处理结构化或者非结构化数据。并且，到目前为止，我们还只是知道MR过程中处理的是键值对，对键值对的具体数据类型并没有提出要求。但是，因为在MR过程中需要进行数据传输，Hadoop会将数据进行序列化然后传输，这就是MR操作的数据类型的基本要求---可序列化，这对实现而言就是要求数据类型集成自Writable类。同时，我们知道在Mapper和Reducer之间，Hadoop会自动地对按照键的值数据进行排序，那么这就要求键的对象还要是可比较的Comparable，所以键所使用的数据类型必须是可序列化且可比较的，即继承自WritableComparable类。

        Hadoop实现了一些基本数据类型，同时我们也可以自定实现数据类型，根据上述要求，自定义数据类型必须继承自Writable或WritableComparable。

2.Mapper&Reducer

        Java泛型，其内实现了map和reduce方法。

3.Partitioner

        Partitioner用于重定向Mapper输出，即确定多个mapper和多个reducer之间的对应关系。

        Hadoop默认使用散列的方式，用户也可以进行自定义(implements Partitoner)。

        比如说，对这样如下键值对：

(San Francisco, Los Angeles) Chuck Lam(San Francisco, Dallas) James Warren
默认这两个键值对不会散列到一起，那么它们就有可能不被分配到同一个Reducer，但是如果我们想把这两个散列到一起，即只根据Key的前半个值(San Francisco)进行散列，将出发地相同的键值对分到一起。

4.Combiner

         Combiner用于实现本地化的Reducer，后续的文章会详细介绍到。这种在数据传输之前在本地reduce聚合的方法，可以减少后续Mapper和Reducer之间的数据传输。

以上，实际上虽然我们常常把Hadoop的数据处理模型称作MapReduce，但实际上这个过程不仅仅包含Map和Reduce，还包括data spliting，shuffling，它们对框架的运行而言至关重要，同时我们还可以定制包括Partition和Combining这样的操作，使得整个过程更高效。

二、Hadoop的守护进程

与Hadoop文件相关的守护进程有三类：NameNode、DataNode和SecondaryNameNode。

与Hadoop数据处理相关的守护进程有两类：JobTracker和TaskTracker。【这是1.0版本系列的hadoop，后续更新的2.0系列使用YARN，略有不同。】

Hadoop在分布式存储和计算上的都使用主从架构。

（一）文件存储相关

1.NameNode：

        NameNode是主从架构中的“指挥官”，它指导DataNode执行底层的I/O任务。NameNode中存储元数据，即命名空间信息，块信息等，client操作数据时首先要向NameNode查询文件的具体位置，然后再与相应的DataNode通信。

        NameNode的重要性不言而喻，因为独一无二所以Hadoop集群存在单点失效的问题。后面讲到的SecondaryNameNode也许能帮助减轻故障，但不能解决（要知道，SecondaryNameNode绝不是NameNode的备份！）。

2.DataNode：

        DN是实际进行底层I/O操作的进程。

3.SecondaryNameNode

        SecondaryNameNode是一个用于监测HDFS集群状况的辅助守护进程，它不是NameNode的备份！要介绍它的原理，我们要首先理解NameNode的运行机制。

上面介绍到NameNode存储的是元数据，这些数据运行时是保存在内存中的，当然也可以持久化到磁盘上。下图展示了NameNode是怎么把数据保存到磁盘上的。

上图中，fsimage是在NameNode启动时对整个文件系统的快照；edit logs是NameNode启动后，对文件系统的改动序列。如果没有SecondaryNameNode，那么只有在NameNode启动的时候才会将edit logs合并到fsimage中。实际中，NameNode是很少重启的，这就产生了几个问题：

a.edit logs会变得很大，管理该文件会变得困难；

b.NameNode重启时间将会非常长，因为有大量的合并需要执行；

c.如果NameNode挂掉了，edit logs中所有改动都丢失了。

为了克服上述问题，引入了SecondaryNameNode，它的职责就是合并NameNode的edit logs到fsimage中，如下图：

所以我们说SecondaryNameNode能在一定程序上缓解NameNode单点故障带来的损失。

（二）计算相关

1.JobTracker

        JobTracker是Application和Hadoop之间的纽带，一旦提交代码到集群上，JobTracker就会确定执行计划，在任务失败的时候自动重启任务。【主从架构中的额主节点，监测MR作业的这个执行过程。TaskTracker要不断地JobTracker发送心跳，否则JobTracker会将该TaskTracker看成已崩溃。】

2.TaskTracker

        TaskTracker则负责实际执行任务。TaskTracker中可以生成多个JVM，从而并行地处理多map或reduce任务。