Hadoop
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
讲到Hadoop起源，就不得不提Hadoop之父Doug Cutting：
上面就是Doug Cutting。Cutting于1985年毕业于斯坦福大学，第一份工作在Xerox做实习生。Xerox的工作让他在搜索引擎技术的知识有了很大提高。他花了四年的时间搞研发，这四年中，他阅读了大量的论文，同时，自己也发表了很多论文，用Cutting自己的 话说——“我的研究生是在Xerox读的。”尽管Xerox让Cutting积累了不少技术知识，但他却认为，自己当时搞的这些研究只是纸上谈兵，没有人试验过这些理论的可实践性。于是，他决定勇敢地迈出这一步，让搜索技术可以为更多人所用。1997年底，Cutting开始以每周两天的时间投入，在家里试着用Java把这个想法变成现实，不久之后，Lucene诞生了。作为第一个提供全文文本搜索的开源函数库，Lucene的伟大自不必多言。
之后，Cutting再接再厉，在 Lucene的基础上将开源的思想继续深化。2004年，Cutting和同为程序员出身的Mike Cafarella决定开发一款可以代替当时的主流搜索产品的开源搜索引擎，这个项目被命名为Nutch。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。
幸运的是，在2003年、2004年谷歌发表的两篇论文为该问题提供了可行的解决方案：
分布式文件系统（GFS），即Google File System，可用于处理海量网页的存储
分布式计算框架MAPREDUCE，它运行在GFS之上，负责分布式大规模数据；可用于处理海量网页的索引计算问题
Nutch的开发人员完成了相应的开源实现HDFS和MAPREDUCE，并从Nutch中剥离成为独立项目HADOOP，到2008年1月，HADOOP成为Apache顶级项目 (同年，cloudera公司成立)，迎来了它的快速发展期。
从狭义上来说，hadoop就是单独指代hadoop这个软件，
从广义上来说，hadoop指代大数据的一个生态圈，包括很多其他的软件
总的来说，Hadoop就是一个大数据以及分布式计算的解决方案。
同Linux相同，Hadoop也有很多不同的发行版：
优点：拥有全世界的开源贡献者，代码更新迭代版本比较快
缺点：版本的升级，版本的维护，版本的兼容性，版本的补丁都可能考虑不太周到，学习可以用，实际生产工作环境尽量不要使用
下载地址：http://archive.apache.org/dist/hadoop/
hortonworks主要是雅虎主导Hadoop开发的副总裁，带领二十几个核心成员成立Hortonworks，核心产品软件HDP（ambari），HDF免费开源，并且提供一整套的web管理界面，供我们可以通过web界面管理我们的集群状态，web管理界面软件HDF
cloudera主要是美国一家大数据公司在apache开源hadoop的版本上，通过自己公司内部的各种补丁，实现版本之间的稳定运行，大数据生态圈的各个版本的软件都提供了对应的版本，解决了版本的升级困难，版本兼容性等各种问题，生产环境推荐使用， 通常简称为CDH
Hadoop至今已经经历了3个大版本，分别是0.x、1.x、2.x：
0.x系列版本：hadoop当中最早的一个开源版本，在此基础上演变而来的1.x以及2.x的版本
1.x版本系列：hadoop版本当中的第二代开源版本，主要修复0.x版本的一些bug等
2.x版本系列：架构产生重大变化，引入了yarn平台等许多新特性
如上图，Hadoop1.x架构主要由两个主要部分组成：
文件系统核心模块(HDFS) :假设有100T的文件，单机无法存储这么大的文件数量，所以就需要将数据分散在多台机器上，通过HDFS存储获取文件，并且不用关心数据具体的存储方式
数据计算核心模块(MapReduce)：单机无法从如此大的数据中找出某个关键字，所以需要分布式计算
存储是大数据技术的基础(HDFS),分布式计算是大数据应用的解决方案(MapReduce)
HDFS 用于解决大数据存储的问题，它由多个节点组成，并分为三种节点角色：
NameNode:集群当中的主节点，主要用于管理集群当中的各种源数据，通过元数据可以所引到指定DataNode，类似目录的作用
secondaryNameNode:主要能用于hadoop当中元数据信息的辅助管理
DataNode:集群当中的从节点，主要用于存储集群当中的各种数据
用于分布式计算，分为两个角色
JobTracker：接收用户的计算请求任务，并分配任务给从节点
TaskTracker：负责执行主节点JobTracker分配的任务
上述架构缺点很明显，NameNode与JobTracker存在中心化的问题，当发生单节点故障问题，整个集群都将失效。
2.x版本架构仍然由两个部分组成：
HDFS文件存储系统
Yarn资源调度系统
其中HDFS没有发生明显变化，而MapReduce则被替换为了Yarn。Yarn主要由以下几个部分组成：
ResourceManager：主要用于接收用户提交的计算任务并且分配资源(CPU、内存、磁盘、网络)，不再进行任务分配。当接收到到用户提交的计算任务时，ResourceManager将会在某个NodeManager上启动一个ApplicationMaster的进程，此进程将会负责将任务分配到其他NodeManager上。
NodeManager：负责执行主节点 ApplicationMaster分配的任务
AppMaster: 由ResourceManager启动，负责资源申请、任务调配
在Hadoop1.x中，存在HDFS于MapReduce单点故障的问题，所以，2.x为了解决此问题，提供了堆NameNode以及ResourceManager的主备策略，从而实现高可用。根据自己的业务员情况，来决定自己的架构是否需要添加高可用的支持，共分为四种情况：
NameNode与ResourceManager单节点架构模型
NameNode单节点与ResourceManager高可用架构模型
NameNode高可用与ResourceManager单节点架构模型
NameNode与ResourceManager高可用架构模型
不过多赘述
ResourceManager高可用方案如下：
添加ResouceManager备份节点，采用主备策略进行故障转移
使用Zookeeper作为注册中心，负责主备切换
如果NameNode进行了高可用，那么secondaryNameNode角色就会被journalNode替代
NameNode采用主备策略，主即Active启用状态，备即时StandBy后备状态
journalNode主要用于文件系统元数据信息管理； 他会同步元数据信息，从而保证主备NameNode中数据的一致性
这里以2.7.5为示例，解压后可以看到Apache Hadoop的目录结构如下：
如果配置了 etc/hadoop/slaves 和 ssh 免密登录，则可以使用程序脚本启动所有Hadoop 两个集群的相关进程，在主节点所设定的机器上执行。这些脚本位于sbin目录下：
HDFS集群访问管理页面：http://192.168.52.101:50070/dfshealth.html#tab-overview
yarn集群访问管理页面：http://192.168.52.101:8088/cluster
jobhistory访问地址：http://192.168.52.100:19888/jobhistory
