1.

用图与自己的话，简要描述Hadoop起源与发展阶段。

Hadoop起源：Hadoop是道格·卡丁（Doug Cutting）创建的，Hadoop起源于开源网络搜索引擎Apache Nutch，后者本身也是Lucene项目的一部分。Nutch项目面世后，面对数据量巨大的网页显示出了架构的灵活性不够。当时正好借鉴了谷歌分布式文件系统，做出了自己的开源系统NDFS分布式文件系统。第二年谷歌又发表了论文介绍了MapReduce系统，Nutch开发人员也开发出了MapReduce系统。随后NDFS和MapReduce命名为Hadoop，成为了Apache*项目。

从Hadoop的发展历程来看，它的思想来自于google的三篇论文。

          GFS：Google File System 分布式处理系统 ------“解决存储问题”
          Mapreduce：分布式计算模型 ------“对数据进行计算处理”
          BigTable：解决查询分布式存储文件慢的问题，把所有的数据存入一张表中，通过牺牲空间换取时间。

时间线发展阶段（部分）：

2004年--由Doug Cutting 和Mike Cafarella实现了现在HDFS和MapReduce的最初版本。 2005年12月--Nutch移植到新框架，Hadoop在20 个节点上稳定运行。  2006年1月--Doug Cutting加入Yahoo！。  2006年2月--Apache Hadoop项目正式启动以支持MapReduce和HDFS的独立发展。  2006年2月--Yahoo！的网格计算团队采用Hadoop。  2006年4月--在188个节点上(每个节点10 GB)运行排序测试集需要47.9个小时。  2006年5月--Yahoo！建立了一个300个节点的Hadoop研究集群。  2006年5月--在500个节点上运行排序测试集需要42个小时(硬件配置比4月的更好)。  2006年11月--研究集群增加到600个节点。 2006年12月--排序测试集在20个节点上运行1.8个小时，100个节点上运行3.3小时，500个节点上运行5.2小时，900个节点上运行7.8个小时。  2007年1月--研究集群增加到900个节点。 2007年4月--研究集群增加到两个1000个节点的集群。  2008年4月--在900个节点上运行1 TB排序测试集仅需209秒，成为世界最快。  2008年10月--研究集群每天装载10 TB的数据。  2009年3月--17个集群总共24 000台机器。  2009年4月--赢得每分钟排序，59 秒内排序500 GB(在1400个节点上)和173分钟内排序100 TB 数据(在3400个节点上)。  

 发行版本的描述：

从与谷歌系统的关系，关键时间节点，1.x,2.x与3.x的区别，不同公司发行版本等方面来讲。

Hadoop是一个对海量数据存储和海量数据分析计算的分布式系统。
Hadoop 1.x
            海量数据存储 ----> HDFS
            海量数据分析计算 ----> MapReduce
Hadoop 2.x 增加
            资源调度系统 ----> Yarn
从hadoop最初的原型来看，hadoop已经远远超过了本身的批处理。从广义上来说，hadoop现在可以是指更广泛的一个hadoop生态了，而不仅仅是HDFS，MapReduce和Yarn。例如Hive，Hbase，Flume，Sqoop等等项目都属于这个生态。

从与谷歌系统的关系，关键时间节点，1.x,2.x与3.x的区别，不同公司发行版本等方面来讲：

 1.0版本和2.0版本，2011年11月，Hadoop 1.0.0版本正式发布，意味着可以用于商业化。但是，1.0版本中，存在一些问题：

（1）扩展性差，JobTracker负载较重，成为性能瓶颈。

（2）可靠性差，NameNode只有一个，万一挂掉，整个系统就会崩溃。

（3）仅适用MapReduce一种计算方式。

（4）资源管理的效率比较低。

所以，2012年5月，Hadoop推出了 2.0版本 。2.0版本中，在HDFS之上，增加了YARN（资源管理框架）层。它是一个资源管理模块，为各类应用程序提供资源管理和调度。此外，2.0版本还提升了系统的安全稳定性。所以，后来行业里基本上都是使用2.0版本。目前Hadoop又进一步发展到3.X版本。

 

2.用图与自己的话，简要描述名称节点、第二名称节点、数据节点的主要功能及相互关系。

     HDFS集群有两种节点，以管理者-工作者的模式运行，即一个名称节点(管理者)和多个数据节点(工作者)。名称节点管理文件系统的命名空间。它维护着这个文件系统树及这个树内所有的文件和索引目录。这些信息以两种形式将文件永久保存在本地磁盘上：命名空间镜像和编辑日志。名称节点也记录着每个文件的每个块所在的数据节点，但它并不永久保存块的位置，因为这些信息会在系统启动时由数据节点重建。
     客户端代表用户通过与名称节点和数据节点交互来访问整个文件系统。客户端提供一个类似POSIX(可移植操作系统界面)的文件系统接口，因此用户在编程时并不需要知道名称节点和数据节点及其功能。
数据节点是文件系统的工作者。它们存储并提供定位块的服务(被用户或名称节点调用时)，并且定时的向名称节点发送它们存储的块的列表。
没有名称节点，文件系统将无法使用。事实上，如果运行名称节点的机器被毁坏了，文件系统上所有的文件都会丢失，因为我们无法知道如何通过数据节点上的块来重建文件。因此，名称节点能够经受故障是非常重要的，Hadoop提供了两种机制来确保这一点。
     第一种机制就是复制那些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使名称节点在多个文件系统上写入其持久化状态。这些写操作是具同步性和原子性的。一般的配置选择是，在本地磁盘上写入的同时，写入一个远程NFS挂载(mount)。
     另一种可行的方法是运行一个二级名称节点，虽然它不能作为名称节点使用。这个二级名称节点的重要作用就是定期的通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个二级名称节点一般在其他单独的物理计算机上运行，因为它也需要占用大量CPU和内存来执行合并操作。它会保存合并后的命名空间镜像的副本，在名称节点失效后就可以使用。但是，二级名称节点的状态是比主节点滞后的，所以主节点的数据若全部丢失，损失仍在所难免。在这种情况下，一般把存在NFS上的主名称节点元数据复制到二级名称节点上并将其作为新的主名称节点运行。

4.梳理HBase的结构与运行流程，以用图与自己的话进行简要描述

（1）Master主服务器的功能