Hadoop大数据简介

一.Hadoop概述

1.1 Hadoop简要概述

我们生活在这个数据大爆炸的时代 ，很难估算全球电子设备中存储的数据总共有多少 。当前一个中小型公司的数据量也达到数十TB，甚至更多。

有句话说得好 ：“ 大数据胜于好算法 。” 意思是说对于某些应用 （譬如根据以往的偏好来推荐电影和音乐），不论算法有多牛 ，基于小数据的推荐效果往往都不如基于大量可用数据的 一般算法的推荐效果 。

我们遇到的问题很简单：在硬盘存储容量多年来不断提升的同时，访问速 度（硬盘数据读取速度）却没有与时俱进 。
第二个问题是大多数分析任务需要以某种方式结合大部分数据来共同完成分析 ，即从一个硬盘读取的数据可能需要与从另外 99 个硬盘中读取的数据结合使用 。各种分布式系统允许结合不同来源的数据进行分析，但保证其正确性是一个非常大的挑战 。

MapReduce 提出一个编程模型 ，该模型抽象出这些硬盘读写问题井将其转换为对一个数据集（由键值对组成）的计算 。后文将详细讨论这个模型 ，这样的计算由 map 和 reduce 两部分组成 ，而且只有这两部分提供对外的接口 。与HDFS 类似，MapReduce自身也有很高的可靠性 。

MapReduce 看似采用了一种蛮力方法 。每个查询需要处理整个数据集或至少一个数据集的绝大部分 。但反过来想，这也正是它的能力 。MapReduce 是一个批量查询处理器 ，能够在合理的时间范围内处理针对整个数据集的动态查询 。它改变了我们对数据的传统看法 ，解放了以前只是保存在磁带和硬盘上的数据 。它让我们有机会对数据进行创新 。以前需要很长时间处理才能获得结果的问题 ，到现在变得顷刻之间就迎刃而解 ，同时还可以引发新的问题和新的见解 。

1.2 Hadoop发展历史

Hadoop 是 Apache Lucene 创始人Doug Cutting 创建的 ，Lucene 是一个应用 广 泛 的文本搜索系统库Hadoop起源于开 源的网络搜索引擎Apache Nutch，它本身也是 Lucene 项目的一部分 。

Hadoop 的得名
Hadoop不是缩写，它是一个生造出来的词 。Hadoop 之父Doug  Cutting这样解释Hadoop的来历：
“这个名字是我的小 孩给他的毛绒象玩具取的，我的命名标准是好拼读，含义宽泛，不会被用于其他地方，小孩子是这方  面的高手。Googol 就是小孩子起的名字 。”

Hadoop 的子项目及后续模块所使用的名称也往往与 其功 能不相关 ，通常也以大象或其他动物为主题取名（例如 Pig）. 较小一些的组件 ，名称通常都有较好的描述性（因此也史流俗）．这个原则很好 ，意味着我们可以望文 知义，例如 jobtracker，一看就知道它是用来跟踪MapReduce作业的 。

从头打造 一个网络搜索引擎是 一个雄心勃勃的计划 ，不只是因为写爬虫程序很复杂 ，更因为必须有 一个专职团队来实现一一项目中包含许许多多需要随时修改的活动部件 。同时，构建这样的系统代价非常高 一据 Mike Cafarella 和 Doug Cutting 估计 ，一个支持10亿网页的索引系统 ，单是硬件上的投入就高达50万美元 ，另外还有每月高达3万美元的运维费用。不过 ，他们认为这个工作仍然值得投入，因为它开创的是一个优化搜索引擎算法的平台。

Nutch 项目开始于2002年，一个可以运行的网页爬取 工具和搜索引擎系统 很快面试 。但后来 ，开发者认为这 一架构的灵活性不够 ，不足以解决数十 亿网页的搜索问题 。一篇发表于 2003 年的论文为此提供了帮助 ，文中描述的是谷歌产品架构 ，该架构称为 “ 谷歌分布式文件系统” ，简称 GFS 。GFS 或类似的架构，可以解决他们在网页爬取和索引过程中产生的超大文件的存储需求。特别关键的是，GFS 能够节省系统管理（如管理存储节点）所花的大量时间 。在2004，他们开始着手做开源版本的实现 ，即 Nutch 分布式 文件系统 NDFS。

2004年，谷歌发表论文向全世界介绍他们的 MapReduce系统 。2005年初，Nutch的开发人员在Nutcb上实现了一个 MapReduce系统，到年中，Nutcb 的所有主要算住均完成移植，用MapReduce和NDFS来运行 。

Nutch的NDFS和MapReduce 实现不只适用于搜索领域 。在2006年2月， 开发人员将NDFS和MapReduce移出Nutch形成 Lucene 的一个子项目 ，命名为Hadoop 。大约在同 一时间 ，Doug Cutting加入雅虎，雅虎为此组织了专门的团队和资源 ，将 Hadoop 发展成能够处理 Web 数据的系统。在2008年2月，雅虎宣布，雅虎搜索引擎使用的索引是在一个拥有上万个内核的Hadoop集群上构建的。

2008年1月，Hadoop已成为Apache的顶级项目，证明了它的成功 、多样化和生命力 。到目前为止，除雅虎之外，还有很多公司在用 Hadoop ，例如 Last.fm 、Facebook 和 《纽约时报》 等 。

《纽约时报》的案例广为流传 ，他们把1851年到1980年的存档扫描之后得到4TB的文件并用亚马逊的EC2 云服务将文件存为PDF格式放到网上共享 。整个过程 一共使用了100台计算机 ，所花的时间不到24小时。如果没有亚马逊的按小时付费模式（即允许《纽约时报》短期内访问大量机器） 和 Hadoop 好用的并发编程模型珠联璧合，这个项目不太可能这么快就启动和完成 。

2008年4月，Hadoop打破世界纪录，成为最快的TB级数据排序系统 。在 个 910 节点的群集 ，Hadoop 在 209 秒内（不到 3.5 分钟）完成了对 1TB 数据的排序，击 败了前 一年的 297 秒冠军。同年11月，谷歌在报告中 声称 ，它的 MapReduce 对 1TB数据排序只用了68秒 。从那以后 ，Hadoop 跃升为企业主流的部署系统 。在工业界 ，Hadoop 已经是 公认的大数据通用存储和分析平台 ，这一事实主要体现在大量直接使用或 者间接辅助Hadoop系统的产品如雨后春笋般大量涌现 。一些大公司也发布Hadoop发行版本，包括 EMC , IBM , Microsft 和 Oracle 以及一些专注于 Hadoop 的公司，如 Cloudera , Hortonworks和MapR 。

Eric Baldeschwieler(Eric14）组建了一个小团队，于是我们开始设计并在GFS和MapReduce上用 C＋＋来建立 一个新框架的原型，并打算用它来取代 Dreadnaught。尽管我们的当务之急是需要一个新的WebMap框架，但史清楚的是，建立 雅虎搜索引擎批处理平台的标准对我们更重要 。使平台是通用以便支持其他用户 ，才 能够史好地实现新平台的均衡性投资 。

与此同时，我们也关注在 Hadoop（当 时也是 Nutcb 的一部分）及其进展情 况. 2006年1月，雅虎聘请了Doug Cutting。一个月后 ，我们决定放弃原型，转而采用Hadoop. 与我们的原型和设计相比，Hadoop的优势在于它已经在 20个节点上实际应用过(Nutch）。这样一来，我们便能在两个月内搭建一个研究集群并能够以很快的速度帮 助我们的客户使用这个新的框架．另 一个显著的优点是 Hadoop 已经开源 ，比较容易（尽管也不是想象的那 么容易 ！）从雅虎法务部门获得许可对该开源系统进行进一步 研究 。因此 ，我们在 2006 年初建立 了一个 200  节点的研究 集群并暂时搁直 WebMap计划 ，转而为研究用户提供Hadoop支持和优化服务 。

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

二.Hadoop 生态系统

Hadoop由HDFS、MapReduce、HBase、Hive和ZooKeeper等成员组成，其中最基础最重要元素为底层用于存储集群中所有存储节点文件的文件系统HDFS（Hadoop Distributed File System）来执行MapReduce程序的MapReduce引擎。

常见成员描述

成员	功能描述
Pig	基于Hadoop的大规模数据分析平台，Pig为复杂的海量数据并行计算提供了一个简单的操作和编程接口
Hive	提供完整的SQL查询，可以将sql语句转换为MapReduce任务进行运行
ZooKeeper	高效的，可拓展的协调系统，存储和协调关键共享状态
HBase	开源的，基于列存储模型的分布式数据库
HDFS	分布式文件系统，有着高容错性的特点，适合那些超大数据集的应用程序；
MapReduce	编程模型，用于大规模数据集（大于1TB）的并行运算

下图是一个典型的Hadoop集群的部署结构：

三.Hadoop核心设计

3.1 HDFS

HDFS是一个高度容错性的分布式文件系统，可以被广泛的部署于廉价的PC上。它以流式访问模式访问应用程序的数据，这大大提高了整个系统的数据吞吐量，因而非常适合用于具有超大数据集的应用程序中。
HDFS的架构如图所示。HDFS架构采用主从架构（master/slave）。一个典型的HDFS集群包含一个NameNode节点和多个DataNode节点。NameNode节点负责整个HDFS文件系统中的文件的元数据的保管和管理，集群中通常只有一台机器上运行NameNode实例，DataNode节点保存文件中的数据，集群中的机器分别运行一个DataNode实例。在HDFS中，NameNode节点被称为名称节点，DataNode节点被称为数据节点。DataNode节点通过心跳机制与NameNode节点进行定时的通信。

3.1.1 数据块

HDFS被设计成支持大文件，适用HDFS的是那些需要处理大规模的数据集的应用。这些应用都是只写入数据一次，但却读取一次或多次，并且读取速度应能满足流式读取的需要。HDFS支持文件的“一次写入多次读取”语义。一个大文件会被拆分成一个个的块(block)，然后存储于不同的DataNode上。如果一个文件小于一个block的大小，那么实际占用的空间为其文件的大小。

DataNode将HDFS数据以文件的形式存储在本地的文件系统中，它并不知道有关HDFS文件的信息。它把每个HDFS数据块（block）存储在本地文件系统的一个单独的文件中,每个块都会被复制到多台机器，默认复制3份。在DataNode中block是基本的存储单位（每次都是读写一个块），默认大小为64M。配置大的块主要是因为：
(1) 减少搜寻时间，一般硬盘传输速率比寻道时间要快，大的块可以减少寻道时间；
(2) 减少管理块的数据开销，每个块都需要在NameNode上有对应的记录；
(3) 对数据块进行读写，减少建立网络的连接成本

3.1.2 NameNode和DataNode

成员	功能描述
NameNode	可以看作是分布式文件系统中的管理者，存储文件系统的meta-data，主要负责管理文件系统的命名空间，集群配置信息，存储块的复制。
DataNode	是文件存储的基本单元。它存储文件块在本地文件系统中，保存了文件块的meta-data，同时周期性的发送所有存在的文件块的报告给NameNode。
Client	就是需要获取分布式文件系统文件的应用程序

3.1.3 联邦HDFS

namenode是个单点，当数据量非常大的时候，namenode所在的主机内存就成了瓶颈，hadoop 2.X开始，引入了联邦HDFS允许系统通过添加namenode实现拓展。例如一个namenode管理/usr下所有的文件，一个namenode管理/share目录下所有文件。

3.1.4 HDFS高可用

通 过 联 合 使 用 在 多个 文 件 系 统中 备 份 namenode 的元 数 据 和 通 过 备 用 namenode 创建监测点能防止数据丢失 ，但是依旧无法实现文件系统的 高可 用性 。Namenode 依旧存 在单点失效（SPOF）的问题 。如果 namenode 失效 了，那么所有的客户端 一一包括MapReduce作业一一均无挂读 、写或列 (list）文件，因为 namenode 是唯一存储元数据与文件到数据块映射的地方 。 在这一情况下，Hadoop 系统无能提供服务直到有新的 namenode上线。
在这样 的情况下 ，要想从一个失效的 namenode 恢复 ，系统管理员得启动 一 个拥有文件系统元数据副本的新的 namenode ，并配置 datanode 和客户端以 便使用这个新的 namenode 。
新的namenode 直到满足以下情形才能响应服 务
：1）将命名空间的映像导人内存中 ；
2）重做编辑日 志 ；
3）接收到足够多的 来自 datanode 的数据块报告并退出安全模式 。
对于一个大型并拥有大量文 件和数据块的集群 ，name node 的冷启动需要 30 分钟 ，甚至更长时间 。
系统恢复时间太长 ，也会影响到日 常维护 。事实上，namenode 失效的可能性非常低 ，所以在实际应用中计划系统失效时间就显得尤为重要 。
Hadoop 的 2.x 发行版本系列针对 上述问题在 HDFS 中增加了对高可用性 (HA） 的支 持 。在 这 一 实 现 中 ，配 置 了一 对 活 动，备 用 （active-stand by) namenode 。当活动 namenode 失效 ，备用 namenode 就会接管它的任务井开 始服务于来自客户端的请求，不会有任何明显中断 。

NameNode：
节点中有多个(hdfs2.x 2个 3.x 支持多个)NameNode 中由一个Active状 和一个或多个Standby 状态节点 ，处于Active状态的NameNode对外提供服务，Standby状态的NameNode为Active状态NameNode的备，起到了高可用（HA）的作用

Standby 状态的NameNode 取代了SecondaryNameNode 的工作，对进行edits 和SImage 进行合并工作并推送回Active NameNode

JN（JournalNode）：
负责储存静态元数据信息（edits 操作日志，不包括Block信息，Block动态元数据信息由DataName实时汇报），用于同步Active 和 Standby状态NameNode节点信息

JournalNode 使用3台以上服务器实现高可用。JN之间采用弱一致性（过半机制）确认edits 是否成功上传。

DN（DataName）:
作用与上述 DataName 一致。但在汇报block块信息时会向所有NameNode节点进行汇报。

ZK （Zookeeper）:
使用ZK分部式协调系统实现NameNode 主备间切换

FalloverController （ZKFC）：
FalloverController 故障控制转移物理进程（ZKFC）即Zookeeper客户端，负责检测NameNode健康状态，当Active健康状态异常则进行切换操作

当Hadoop 集群启动时先注册到Zookeeper的NameNode 为Active 状态

当处于Active 状态的NameNode 节点发生异常时，Zookeeper会通过投票选举机制来决定哪个 Standby 状态的NameNode节点切换为Active 状态对外提供服务

3.2 MapReduce

MapReduce是一种编程模型，用于大规模数据集的并行运算。Map（映射）和Reduce（化简），采用分而治之思想，先把任务分发到集群多个节点上，并行计算，然后再把计算结果合并，从而得到最终计算结果。多节点计算，所涉及的任务调度、负载均衡、容错处理等，都由MapReduce框架完成，不需要编程人员关心这些内容。
下图是MapReduce的处理过程：

用户提交任务给JobTracer，JobTracer把对应的用户程序中的Map操作和Reduce操作映射至TaskTracer节点中；输入模块负责把输入数据分成小数据块，然后把它们传给Map节点；Map节点得到每一个key/value对，处理后产生一个或多个key/value对，然后写入文件；Reduce节点获取临时文件中的数据，对带有相同key的数据进行迭代计算，然后把终结果写入文件。

如果这样解释还是太抽象，可以通过下面一个具体的处理过程来理解：（WordCount实例）

Hadoop的核心是MapReduce，而MapReduce的核心又在于map和reduce函数。它们是交给用户实现的，这两个函数定义了任务本身。

map函数：接受一个键值对（key-value pair）（例如上图中的Splitting结果），产生一组中间键值对（例如上图中Mapping后的结果）。Map/Reduce框架会将map函数产生的中间键值对里键相同的值传递给一个reduce函数。
reduce函数：接受一个键，以及相关的一组值（例如上图中Shuffling后的结果），将这组值进行合并产生一组规模更小的值（通常只有一个或零个值）（例如上图中Reduce后的结果）

但是，Map/Reduce并不是万能的，适用于Map/Reduce计算有先提条件：
（1）待处理的数据集可以分解成许多小的数据集；
（2）而且每一个小数据集都可以完全并行地进行处理；
若不满足以上两条中的任意一条，则不适合适用Map/Reduce模式。

参考

1.Hadoop权威指南
2.https://blog.csdn.net/qq_24817093/article/details/79019529
3.https://blog.csdn.net/qq_26437925/article/details/78467216
4.https://blog.csdn.net/dgqg1223/article/details/104225737