Hadoop各模块的具体分析

Hadoop集群架构

Hadoop集群由一个Master主节点和若干个Slave节点组成。其中，Master节点上运行NameNode和JobTracker守护进程；Slave节点上运行DataNode和TaskTracker守护进程。 
Hadoop分别从三个角度将集群中的主机划分为两种角色：

Hadoop集群主机角色划分

1. 从主机服务角度 
     从主机服务功能上将集群中的主机分为Master和Slave。Master主机负责分布式文件系统的元数据管理和分布式计算的做业调度，通常在一个集群中有一到数台Master主机；Slave主机负责具体的数据存储和计算。
2. 从文件系统HDFS的角度 
     从文件系统HDFS的的角度将主机划分为NameNode和DatanNode。Namenode存储分布式文件系统中的元数据信息，换句话说也就是命名空间，它维护着文件系统树及整课树内全部文件和目录，这些信息以两个文件形式永久的保存在本地磁盘上：命名空间镜像文件和编辑日志文件。同时namenode也记录每一个文件中各个块所在的数据节点信息，可是不会永久保留这些信息，由于这些信息系会在系统启动的时候由数据节点重建；DataNode存储文件系统中实际文件数据，它们根据须要储存和检索数据块(受客户端或namenode调度)，而且按期的向namenode发送他们所存储的块列表(所谓的心跳检测)。

换句话说，namenode的安全机制很重要，若是丢失或者损坏了namenode，文件系统上全部的文件就将丢失。由于咱们不知道如何根据datanode块重建文件。Hadoop提供了两种保护机制：

• 冗余备份namenode
• 另外一种方式是运行辅助namenode，它按期经过编辑日志合并命名空间镜像，以防止编辑日志过大。

而实际上，这两种方法在后来咱们会继续讨论，更重要的是，namenode HA的机制众多大牛已经将其设计的很是科学了，咱们能够参考一下这篇文章：namenode的HA原理详解。

实际上，Hadoop的文件系统远不止HDFS一种，它整合了众多的文件系统，首先提供了一个高层的文件系统抽象org.apache.hadoop.fs.FileSystem，该抽象类展现了一个分布式文件系统，并有几个具体的实现，见下表：

Hadoop文件系统

文件系统	URI方案	java实现org.apache.hadoop	定义
Local	file	fs.LocalFileSystem	支持有客户端校检和的本地文件系统。
HDFS	hdfs	hdfs.DistributedFileSystem	Hadoop的分布式文件系统。
HFTP	hftp	hdfs.HftpFileSystem	支持经过HTTP方式以只读的方式访问HDFS，distcp常常用在不一样的HDFS集群间复制数据。
HSFTP	hsftp	fs.HsftpFileSystem	支持经过HTTPS方式以只读的方式访问HDFS。
HAR	har	fs.HarFileSystem	构建在其余文件系统上进行归档文件的文件系统。Hadoop归档文件主要来减小NameNode的内存使用。
KFS	kfs	fs.kfs.Kosmos.FileSystem	相似于GFS和HDFS，用C++编写
FTP	ftp	fs.ftp.FtpFileSystem	由FTP服务器支持的文件系统
S3(本地)	s3n	fs.s2native.NativeS3FileSystem	基于Amazon S3的文件系统
S3(基于块)	s3	fs.s3.NativeS3FileSystem	基于Amazon S3的文件系统，以块格式储存解决了S3的5GB文件大小的限制。

    3.  从MapReduce角度 

  从MapReduce角度将主机划分为JobTracker和TaskTracker。JobTracker是做业的调度与管理者，属于master;TaskTracker是任务的实际执行者，属于slave。

因此HDFS只是其中的一个文件系统之一

HDFS简介

  HDFS是Hadoop使用的标准存储系统，是基于网络环境下的分布式文件系统。它是基于流数据模式访问和处理超大文件的需求开发的，实际上，这并非什么新颖的事情，80年代左右就已经有人这么去实现了。存储在HDFS上的数据文件首先进行分块，每一个分块建立多个副本，并存储在集群的不一样节点上，Hadoop MapReduce程序能够在全部节点上处理这些数据。HDFS上数据存储和处理过程以下所示。

Hadoop上的数据存储和处理模型

HDFS的两个主要组件

  HDFS的设计听从主从体系结构，每一个HDFS集群都有一个名字节点（NameNode)和若干数据节点（DataNode)。HDFS存储文件的机制是将数据文件分块，这里的文件块指的是系统读写操做的最小文件大小，文件系统每次只能处理磁盘块大小的整数倍数据。而后将这些数据块按照必定的策略存放在数据节点上。NameNode节点管理文件系统的命名空间、文件、目录操做，同时也负责肯定数据节点和文件块的映射关系。DataNode节点负责来自客户端的文件读/写请求，同时还要执行块的建立、删除以及来自名字节点的文件和块的操做命令。 
  NameNode和DataNode在功能上的区别： 

 

HDFS的系统架构

HDFS的架构如图所示: 

HDFS读取文件流程

HDFS中客户端读取文件的流程以下所示:

HDFS读取文件流程

读取操做的具体流程以下： 
1. 客户端(client)用FileSystem的open()函数打开文件。 
2. DistributedFileSystem用RPC和NameNode通讯，获得文件的全部数据块信息以及这些数据块所在节点的地址信息。 
3. DistributedFileSystem将获取的数据块信息保存在FSDataInputStream中，而后返回给客户端，用来读取数据。 
4. 客户端根据NameNode返回的信息，链接到存有数据块的数据节点，而后调用stream的read()函数开始读取数据。 
5. DFSInputStream链接保存此文件第一个数据块的最近的数据节点。 
6. Data从数据节点读到客户端(client)。 
7. 当此数据块读取完毕时，DFSInputStream关闭和此数据节点的链接，而后链接此文件下一个数据块的最近的数据节点。 
8. 当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。 
9. 在读取数据的过程当中，若是客户端在与数据节点通讯出现错误，则尝试链接包含此数据块的下一个数据节点。 
10. 失败的数据节点将被记录，之后再也不链接。

3.五、HDFS写入文件流程

HDFS写入文件流程以下所示。

HDFS写入文件流程

写入操做的具体流程以下： 
1. 客户端调用create()来建立文件 
2. DistributedFileSystem用RPC调用元数据节点，在文件系统的命名空间中建立一个新的文件。 
3. 元数据节点首先肯定文件原来不存在，而且客户端有建立文件的权限，而后建立新文件。 
4. DistributedFileSystem返回DFSOutputStream，客户端用于写数据。 
5. 客户端开始写入数据，DFSOutputStream将数据分红块，写入data queue。 
6. Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。 
7. Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。 
8. DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。 
 若是数据节点在写入的过程当中失败： 
 关闭pipeline，将ack queue中的数据块放入data queue的开始。 
 当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后可以察觉其数据块是过期的，会被删除。 
 失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。 
 元数据节点则被通知此数据块是复制块数不足，未来会再建立第三份备份。 
9. 当客户端结束写入数据，则调用stream的close函数。此操做将全部的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。

一些补充的地方：

1. NameNode启动后会进入一个成为安全模式的特殊状态。此时NameNode不会进行数据块复制。NameNode从全部的DataNode接收心跳信号和块状态报告。块状态报告包括了某个DataNode全部的数据块列表。每一个数据块都有一个指定的最小副本数，当NameNode检测确认某个数据块的副本数达到要求的时候，该数据块就会被认为是副本安全的。等安全DataNode达到了必定比率，NameNode就会推出安全模式，接下来还会继续肯定还有哪些数据的副本没有达到指定数目。

2. Hadoop的优缺点

优势：

• 处理超大文件
• 流式的访问数据
• 运行于廉价的商用机器集群上

缺点：

• 不适合低延迟访问
• 没法高效存储大量小文件

MapReduce

MapReduce做业执行过程当中涉及到的实体

• 客户端 
  做用是提交MapReduce做业到集群的计算机主节点JobTracker上。客户端能够是集群上的节点也能够不是集群上的节点，从集群外的节点提交做业时须要制定JobTRacker的地址。
• 计算主节点JobTracker 
  JobTracker 的功能主要是负责做业的任务分配，计算任务的管理和监控。
• 从节点TaskTracker 
  运行JobTracker分配给他的任务。
• HDFS 
  计算开始的时候，程序从HDFS中读入数据；计算结束后，将数据保存到HDFS中。

MapReduce的工做流程

整个MapReduce做业的工做工程，以下所示：

MapReduce工做流程

1. 做业的提交 
客户端调用JobClient的runjob()方法建立一个 JobClient实例，而后调用submitJob()方法提交做业到集群，其中主要包括如下步骤： 
1）经过JobTracker的getNewJobId()请求一个新的做业ID； 
2）检查做业的输出（好比没有指定输出目录或输出目录已经存在，就抛出异常），以避免覆盖原有文件内容； 
3）计算做业的输入分片，为了高效，分片大小最好和HDFS块的大小相同（当分片没法计算时，好比输入路径不存在等缘由，就抛出异常）； 
4）将运行做业所需的资源（好比做业Jar文件，配置文件，计算所得的输入分片等）复制到一个以做业ID命名的目录中。（集群中有多个副本可供TaskTracker访问）； 
5）经过调用JobTracker的submitJob()方法告知做业准备执行； 
6）JobTracker调度任务到工做节点上执行。runjob每隔1秒轮训一次节点，看看执行进度，指导任务执行完毕。 

2. 做业的初始化 
1）JobTracker接收到对其submitJob()方法的调用后，就会把这个调用放入一个内部队列中，交由做业调度器（好比先进先出调度器，容量调度器，公平调度器等）进行调度； 
2）初始化主要是建立一个表示正在运行做业的对象——封装任务和记录信息，以便跟踪任务的状态和进程； 
3）为了建立任务运行列表，做业调度器首先从HDFS中获取JobClient已计算好的输入分片信息； 
4）而后为每一个分片建立一个MapTask，而且建立ReduceTask。（Task在此时被指定ID，请区分清楚Job的ID和Task的ID）。 

3. 任务的分配 
1）TaskTracker按期经过“心跳”与JobTracker进行通讯，主要是告知JobTracker自身是否还存活，以及是否已经准备好运行新的任务等； 
2）JobTracker在为TaskTracker分配一个Task前，JobTracker须要按照优先级选择一个做业，在最高优先级的job中选择一个task。Hadoop默认的做业调度Map Task优先级比Reduce Task高； 
3）TaskTracker根据必定的策略运行必定数量的map task和reduce task。可运行的数量有TaskTracker的数量和内存大小决定

4. 任务的执行 
1）TaskTracker分配到一个任务后，经过从HDFS把做业的Jar文件复制到TaskTracker所在的文件系统（Jar本地化用来启动JVM），同时TaskTracker将应用程序所须要的所有文件从分布式缓存复制到本地磁盘； 
2）TaskTracker为任务新建一个本地工做目录，并把Jar文件中的内容解压到这个文件夹中； 
3）TaskTracker启动一个新的JVM来运行每一个Task（包括MapTask和ReduceTask），这样Client的MapReduce就不会影响TaskTracker守护进程（好比，致使崩溃或挂起等）。 
子进程经过umbilical接口与父进程进行通讯，Task的子进程每隔几秒便告知父进程它的进度，直到任务完成。

5. 进程和状态的更新 
一个做业和它的每一个任务都有一个状态信息，包括做业或任务的运行状态，Map和Reduce的进度，计数器值，状态消息或描述（能够由用户代码来设置）。这些状态信息在做业期间不断改变，它们是如何与Client通讯的呢？

任务在运行时，对其进度（即任务完成的百分比）保持追踪。对于MapTask，任务进度是已处理输入所占的比例。对于ReduceTask，状况稍微有点复杂，但系统仍然会估计已处理Reduce输入的比例；

这些消息经过必定的时间间隔由Child JVM—>TaskTracker—>JobTracker汇聚。JobTracker将产生一个代表全部运行做业及其任务状态的全局视图。能够经过Web UI查看。同时JobClient经过每秒查询JobTracker来得到最新状态，而且输出到控制台上。

4.三、Shuffle和Sort

Shuffle阶段是指从Map的输出开始，包括系统执行排序以及传送Map输出到Reduce做为输入的过程。Sort阶段是指对Map端输出的Key进行排序的过程。不一样的Map可能输出相同的Key，相同的Key必须发送到同一个Reduce端处理。Shuffle阶段能够分为Map端的Shuffle和Reduce端的Shuffle。Shuffle阶段和Sort阶段的工做过程，以下所示：

一、Map端的Shuffle 
Map函数开始产生输出时，并非简单地把数据写到磁盘，由于频繁的磁盘操做会致使性能严重降低。它的处理过程更复杂，数据首先写到内存中的一个缓冲区，并作一些预排序，以提高效率；

每一个MapTask都有一个用来写入输出数据的循环内存缓冲区（默认大小为100MB），当缓冲区中的数据量达到一个特定阈值时（默认是80%）系统将会启动一个后台线程把缓冲区中的内容写到磁盘（即spill阶段）。在写磁盘过程当中，Map输出继续被写到缓冲区，但若是在此期间缓冲区被填满，那么Map就会阻塞直到写磁盘过程完成；

在写磁盘前，线程首先根据数据最终要传递到的Reducer把数据划分红相应的分区（partition）。在每一个分区中，后台线程按Key进行排序（快速排序），若是有一个Combiner（即Mini Reducer）便会在排序后的输出上运行；

一旦内存缓冲区达到溢出写的阈值，就会建立一个溢出写文件，所以在MapTask完成其最后一个输出记录后，便会有多个溢出写文件。在在MapTask完成前，溢出写文件被合并成一个索引文件和数据文件（多路归并排序）（Sort阶段）；

溢出写文件归并完毕后，Map将删除全部的临时溢出写文件，并告知TaskTracker任务已完成，只要其中一个MapTask完成，ReduceTask就开始复制它的输出（Copy阶段）；

Map的输出文件放置在运行MapTask的TaskTracker的本地磁盘上，它是运行ReduceTask,TaskTracker所须要的输入数据，可是Reduce输出不是这样的，它通常写到HDFS中（Reduce阶段）。

二、Reduce端的Shuffle 
Copy阶段：Reduce进程启动一些数据copy线程，经过HTTP方式请求MapTask所在的TaskTracker以获取输出文件。 

Merge阶段：将Map端复制过来的数据先放入内存缓冲区中，Merge有3种形式，分别是内存到内存，内存到磁盘，磁盘到磁盘。默认状况下第一种形式不启用，第二种Merge方式一直在运行（spill阶段）直到结束，而后启用第三种磁盘到磁盘的Merge方式生成最终的文件。 

Reduce阶段：最终文件可能存在于磁盘，也可能存在于内存中，可是默认状况下是位于磁盘中的。当Reduce的输入文件已定，整个Shuffle就结束了，而后就是Reduce执行，把结果放到HDFS中。

HBase

HBase表的特色

一、大：一个表能够有数十亿行，上百万列； 
二、无模式：每行都有一个可排序的主键和任意多的列，列能够根据须要动态的增长，同一张表中不一样的行能够有大相径庭的列； 
三、面向列：面向列（族）的存储和权限控制，列（族）独立检索； 
稀疏：空（null）列并不占用存储空间，表能够设计的很是稀疏； 
四、数据多版本：每一个单元中的数据能够有多个版本，默认状况下版本号自动分配，是单元格插入时的时间戳； 
五、数据类型单一：Hbase中的数据都是字符串，没有类型。

HBase的物理集群架构

HBase集群在物理组成上由一个Zookeeper集群、一个Master主服务器、多个RegionServer从服务器组成，同时，HBse在底层依赖于HDFS集群。总体系统架构以下所示：

HBase的物理集群架构

HBase集群运行依赖于Zookeeper，默认状况下，它管理一个Zookeeper实例，做为集群“权威”。若是区域分配过程当中有服务器崩溃，就须要Zookeeper来协调分配。客户端读写HBase中的数据时也须要先访问Zookeeper，了解集群属性。

在底层，HBase的全部信息都保存在HDFS中，HBase是构建在HDFS上的分布式数据库。

HBase的存储架构

HBase的存储架构以下所示：

HBase的存储架构

HBASE集群种重要的角色就是其守护进程。包括运行在集群Master节点上的HMaster进程和运行在每一个从节点RegionServer节点上的HRegionServer进程，初次以外，还包括若干Zookeeper进程。具体组件实体以下： 
一、Client 
HBse Client使用HBase的RPC机制与HMaster（进行管理操做）和HRegionServer（进行读写操做）进行通讯。 

二、HMaster 
HMaster是集群Master节点的主进程，HMaster没有单点问题，HBase中能够启动多个HMaster，经过Zookeper的Master Election机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工做。包括：Table的增删该查、Region分布等。 

三、HRegionServer 
HRegionServer进程运行在集群从节点上，主要负责响应用户的IO请求，向HDFS系统中读写数据。其内部功能结构图以下： 

HRegionServer内部功能结构图

从图上能够看出，HRegionServer管理一系列HRegion对象，每个HRegion又由多个HStore组成。HRegion对应Table中的一个Region;HStore对应Table中的一个列簇。每一个列簇就是一个存储单元。 
HStore由两部分组成：MemStore和StoreFile。用户写入的数据首先会放入MemSore,MemStore满了以后，flush成一个StoreFile.

四、Zookeeper 
Zookeeper中除了存储-ROOT表的地址和Master的地址，还会有HRegionServer的信息，使得Hmaster能够随时知道HRegionServer的情况。

五、Hlog 
每个HRegionServer都有一个Hlog对象，用户写入数据时，会备份一份到HLOG中，以便出现意外好恢复。

5.四、HBase运行时特色

一、Hbase中的区域 
当HBase中数据记录数不断增多时，达到阈值后，就会从行的方向分裂成多份，每份是一个region,一个region由【startkey,endkey】表示。不一样的region会被集群的Master分配给相应的RegionServer进行管理。 

二、HBse中两种特殊表 
运行中的HBase内部保留了2中特殊的目录表：-ROOT- 和 .META. 。-ROOT-表包含了.META.表的全部区域列表的信息，而.META.表保存了全部用户空间的区域列表信息，以及RegionServer的服务器地址。

HBse中两种特殊表

6、Hive

6.一、Hive简介

Hive是创建在Hadoop之上的数据仓库软件工具，它提供了一系列的工具，帮助用户对大规模的数据进行提取、转换和加载，即ETL操做。Hive定义了简单的类SQL查询语言，称为HiveSql。从本质上讲，Hive其实就是一个SQL解释器，它可以将用户输入的HiveSql语句转换成MapReduce做业在Hadoop集群上执行。

6.二、Hive的体系结构

Hive的体系结构