简介
ApacheHadoop是最早和最有影响力的开源工具之一，用于存储和处理随着万维网的兴起而积累的大量随时可用的数字数据。它是从一个名为Nutch的项目发展而来的，该项目试图找到一种更好的开源方式来爬行网络。Nutch的创建者深受谷歌两篇关键论文中的想法的影响，最初将它们合并到Nutch中，但最终存储和处理工作拆分到Hadoop项目中，同时继续开发Nutch作为自己的网络爬行项目。
在本文中，我们将简要考虑数据系统和大数据系统的一些特定的、与众不同的需求。然后我们将看看Hadoop是如何发展来满足这些需求的。
数据系统
数据无处不在：在纸片上，在书籍、照片、多媒体文件、服务器日志和网站上。当这些数据被有目的地收集时，它就会进入数据系统。
想象一个学校项目，学生们每天测量附近一条小溪的水位。他们将测量结果记录在剪贴板上的现场，然后返回教室，并将数据输入电子表格。当他们收集到足够的数量时，他们就开始分析。他们可能会比较不同年份的相同月份，从最高水位到最低水位排序。他们可能会绘制图表来寻找趋势。
这个学校项目展示了一个数据系统：
- 信息存在于不同的位置(不同学生的野外笔记本)
- 收集到系统中(手动输入到电子表格中)
- 存储(保存到教室计算机上的磁盘；可能会复制或保留实地笔记本，以验证数据的完整性)
- 它被分析(聚合、排序或以其他方式操纵)
- 显示处理后的数据(表格、图表、图形)
这个项目是在频谱的小端。一台计算机可以存储、分析和显示一条小溪的每日水位测量值。在光谱的另一端，世界上所有网页上的所有内容形成了一个更大的数据集。最基本的就是大数据：如此多的信息，以至于一台计算机无法容纳。
搜索引擎公司正面临着这个特定的问题，因为网络内容在网络时代呈爆炸式增长。2003年，谷歌发布了其颇具影响力的论文The Google File System]，描述了他们的专有软件如何处理为他们的搜索引擎处理的海量数据的存储。2004年，谷歌发布了《地图简化：大型Clusters](http://research.google.com/archive/mapreduce.html)，上的简化数据处理》，详细介绍了他们如何简化对如此大量数据的处理。这两篇文章极大地影响了Hadoop的架构。
大数据有何不同？
谷歌的文件和Hadoop对这些想法的实施基于对数据思维的四个主要变化，这些变化是容纳数据量所必需的：
1.大数据系统必须接受数据将是分布式的 。将数据集分片存储在一群机器上是不可避免的。 2.一旦集群成为存储基础，那么软件必须考虑硬件故障 ，因为在集群中运行数百台或数千台机器时，硬件故障是不可避免的。 3.由于机器将会出现故障，它们需要一种新的相互沟通的方式。在日常数据计算中，我们习惯于一些特定的机器，通常由IP地址或主机名标识，将特定的数据发送到另一台特定的机器。这种显式通信必须被隐式通信 取代，在隐式通信中，某台机器告诉另一台机器它必须处理某些特定数据。否则，程序员将面临至少与数据处理问题本身一样大的验证问题。 4.最后，计算需要在分布式机器上处理数据 ，而不是在网络上移动海量数据。
2007年发布的基于Java的编程框架Hadoop的1.0版是第一个接受这些思想变化的开放源码项目。它的第一次迭代由两层组成：
1.HDFS： Hadoop分布式文件系统，负责跨多台机器存储数据。 2.MapReduce： 用于在每台机器上就地和并行处理数据，以及调度任务、监控任务和重新运行失败任务的软件框架。
HDFS 1.0
Hadoop分布式文件系统HDFS是Hadoop用来传播数据并确保其正确存储以实现高可用性的分布式存储层。
HDFS 1.0工作原理
HDFS使用块复制来可靠地在多台机器上存储非常大的文件，其中有两个不同的软件：NameNode服务器，它管理文件系统命名空间和客户端访问，以及DataNode，负责服务读取和写入请求，以及块创建，删除和复制。对复制模式的基本了解对开发人员和集群管理员很有帮助，因为虽然它通常工作得很好，但数据分布的不平衡会影响集群性能并需要调优。
HDFS将每个文件存储为数据块序列，除了最后一个数据块外，每个数据块的大小都相同。默认情况下，数据块复制三次，但可以按文件配置数据块的大小和复制副本的数量。文件是一次写入的，任何时候都只有一个写入器，以便实现高吞吐量数据访问并简化数据一致性问题。
NameNode根据从群集中每个DataNode收到的心跳和数据块报告做出有关数据块复制的所有决策。心跳信号表示DataNode运行状况良好，数据块报告提供DataNode上所有数据块的列表。
创建新数据块时，HDFS会将第一个复制副本放置在运行编写器的节点上。第二个复制副本被写入任何机架中的随机选择的节点上--除了写入第一个复制副本的机架。然后，第三个复制品被放置在第二个机架中随机选择的机器上。如果在配置中指定了三个以上的复制副本，则剩余的复制副本将随机放置，但任何一个节点上不得放置一个以上的复制副本，同一机架上不得放置两个以上的复制副本。
HDFS 1.0的局限性
HDFS 1.0确立了Hadoop作为存储大数据的早期开源领导者的地位。这种成功的部分原因是架构决策消除了分布式存储的一些复杂性，但这些选择并不是没有权衡。1.0版的主要限制包括：
- 不控制块的分布
HDFS的块复制模式是其高可用性的支柱。它可以非常有效，并且消除了管理员和开发人员对块存储级别的关注，但由于它不考虑空间利用率或节点的实时情况，因此集群管理员可能需要使用平衡器实用程序来重新分配块。
- NameNode：单点故障
与块的分布相比，NameNode是一个更重要的限制，它代表了单点故障。如果进程或机器出现故障，整个集群在NameNode服务器重新启动之前不可用，即使在重新启动之后，它也必须在它实际可用之前从集群中的每个节点接收心跳消息，这会延长停机时间，特别是对于大型集群。
尽管有这些限制，HDFS还是对大数据工作做出了重大贡献。
MapReduce1.0
Hadoop的第二层MapReduce负责批处理存储在HDFS上的数据。Hadoop对Google的MapReduce编程模型的实现使开发人员能够使用HDFS提供的资源，而不需要具有并行和分布式系统的经验。
MapReduce 1.0工作原理
假设我们有一个文本集合，我们想知道每个单词在集合中出现的次数。文本分布在多个服务器上，因此映射任务在集群中集合中具有数据块的所有节点上运行。每个映射器加载适当的文件，处理它们，并为每个匹配项创建一个键-值对。
这些映射只具有来自单个节点的数据，因此必须将它们混合在一起，以便可以将具有相同键的所有值发送到减法器。当减速器完成时，输出被写入减速器的磁盘。这种隐式通信模型使Hadoop用户不必显式地将信息从一台计算机移动到另一台计算机。
我们将用几句话来说明这一点：
她以六个海岸出售贝壳。 她的贝壳卖得很好。
1MAPPING SHUFFLING REDUCING
2{she, 1} {she, 1, 1} {she, 2}
3{sells, 1} {sells, 1, 1} {sells, 2}
4{seashells, 1} {seashells, 1, 1} {seashells, 2}
5{by, 1} {by, 1} {by, 1}
6{six, 1} {six, 1} {six, 1}
7{seashores, 1} {seashores, 1, 1} {seashores, 2}
8{she, 1} {sure, 1} {sure, 1}
9{sure, 1} {well, 1} {well, 1}
10{sells}
11{seashells, 1}
12{well, 1}
如果这个映射是在一个大的数据集上按顺序完成的，它会花费太长的时间，但是并行完成，然后减少，它变得可扩展的大数据集。
更高级别的组件可以插入MapReduce层以提供额外的功能。例如，Apache Pig通过将Java MapReduce习语抽象到更高的级别，为开发人员提供了一种用于编写数据分析程序的语言，类似于SQL对关系数据库的作用。Apache Hive支持数据分析和报告，具有类似SQL的HDFS接口。它抽象了MapReduce Java API查询，为开发人员提供高级查询功能。 Hadoop 1.x提供了许多额外的组件，但MapReduce中的一些关键限制限制了生态系统。
MapReduce 1的局限性
- MapReduce与HDFS紧耦合
在1.x实现中，MapReduce层的职责超越了数据处理，包括集群资源管理，并与HDFS紧密耦合。这意味着1.x的附加组件开发人员必须编写多遍MapReduce程序，无论它是否适合该任务，因为MapReduce是访问文件系统的唯一方式。
- 用于数据分析的静态槽
映射和缩减发生在DataNode上，这是处理大数据的关键，但每个DataNode上只有有限的静态数量的单一用途插槽可用。映射槽只能映射，而还原槽只能减少。这个数字是在配置中设置的，没有动态调整的容量，当集群工作负载不符合配置时，它们就会空闲，因此被浪费。时隙分配的刚性也使得非MapReduce应用程序很难适当地进行调度。
- JobTracker：单点故障
Hadoop应用程序将MapReduce任务提交给JobTracker，JobTracker通过定位具有可用插槽或地理位置靠近数据的TaskTracker将这些任务分发到特定的集群节点。如果任务失败，TaskTracker会通知JobTracker。JobTracker可能会重新提交作业，将记录标记为从未来处理中排除，或者可能将不可靠的TaskTracker列入黑名单，但如果JobTracker因任何原因失败，所有MapReduce任务都将暂停。
Hadoop 2.x的改进
Hadoop的2.x分支于2011年12月发布，引入了四个主要改进并更正了版本1的关键限制。Hadoop 2.0引入了HDFS联合，消除了NameNode这一性能约束和单点故障。此外，它通过引入YAR(还有另一个资源协商者)将MapReduce与HDFS解耦，通过允许非MapReduce处理模型与HDFS交互并绕过MapReduce层，打开了附加产品的生态系统。
1-HDFS联盟
HDFS联邦引入了名称空间和存储之间的明确分离，使集群中的多个名称空间成为可能。这提供了一些关键的改进：
*集群空间可扩展性 可向集群中添加更多NameNodes，支持水平扩展。大型集群或包含许多小文件的集群可以从添加额外的NameNodes中受益。 *性能提升 1.x的单个NameNode限制了文件系统的读写吞吐量。多个NameNode减轻了文件系统操作的这种约束。 *命名空间之间的隔离 在具有单个NameNode的多租户环境中，一个嘈杂的邻居可能会影响系统上的所有其他用户。通过联邦，隔离系统驻留者成为可能。
HDFS联合工作原理
联合命名节点管理文件系统命名空间。它们独立运作，不相互协调。相反，集群中的DataNode向每个NameNode注册，发送心跳和块报告，并处理来自NameNode的传入命令。
数据块以我们在Hadoop 1.x中看到的相同随机复制方式分布在公共存储中。属于单个命名空间的所有块称为块池。此类池是独立管理的，允许命名空间为新数据块生成数据块ID，而无需与其他命名空间协调。命名空间及其块池的组合称为命名空间卷，它形成一个独立的单元，因此当删除其中一个联合NameNode时，其块池也将被删除。
除了引入NameNode联合所提供的改进的可伸缩性、性能和隔离性之外，Hadoop 2.0还为NameNode引入了高可用性。
2-NameNode高可用性
在Hadoop 2.0之前，如果NameNode出现故障，则整个集群在重新启动或在新机器上启动之前不可用。NameNode的软件或硬件升级也同样造成了停机时间窗口。为了防止出现这种情况，Hadoop 2.0实现了主动/被动配置，以支持快速故障转移。
NameNode HA的工作原理
两台单独的计算机被配置为NameNode，一台处于活动状态，另一台处于备用状态。它们共享对共享存储设备上的公共目录的访问，并且当主动节点执行修改时，它将更改记录在存储在该公共目录中的日志文件中。备用节点持续监视目录，当发生编辑时，它会将这些编辑应用到它自己的命名空间。如果活动节点出现故障，备用节点将从共享存储中读取未应用的编辑，然后将自身升级为活动节点。
3-纱线
Hadoop 2.0将MapReduce从HDFS中分离出来。工作负载、多租户、安全控制和高可用性功能的管理被拆分成纱线(又一位资源谈判者)。从本质上讲，Year是一个用于大数据应用程序的大规模分布式操作系统，这使得Hadoop非常适合MapReduce以及其他不能等待批处理完成的应用程序。YAIN消除了通过通常是I/O密集型、高延迟的MapReduce框架工作的需要，使新的处理模型能够与HDFS一起使用。去耦合的MapReduce仍然是一个面向用户的框架，专门致力于执行它想要完成的任务：批处理。
以下是Hadoop 2.x用户可以使用的一些处理模型：
- 批量处理 批处理系统是非交互的，在处理开始之前可以访问所有数据。此外，在处理过程中探索的问题必须在处理开始之前知道。批处理通常具有高延迟，大数据批处理作业的速度通常以分钟或更长时间来衡量。 _批处理的闪光点：_索引数据、爬行Web和数据处理_一些可以为Hadoop执行此操作的程序：_MapReduceTez、Spark、Have和Flink
- 交互处理 当你不能提前知道你所有的问题时，就需要交互处理系统。相反，用户解释查询的答案，然后提出一个新的问题。为了支持这种探索，返回响应的速度必须比典型的MapReduceJOB快得多。 _交互处理的闪光点：_交互处理支持数据探索。 为Hadoop执行此操作的一些程序：_Impala、Drill、HAWQ、Presto、Vortex和Vertica SQL、Tez
- 流处理 流处理系统获取大量离散数据点，并在新数据到达系统时执行连续查询以产生接近实时的结果。 _在流处理方面大放异彩：_任何时候，您都可以随时获得持续生成的数字数据。例如，监控公众对社交媒体中某个问题、事件或产品的情绪，以便跟踪新出现的趋势或监控服务器日志。_一些为Hadoop执行此操作的程序：_Spark Stream、Storm
- 图形处理 图算法通常需要顶点或跳数之间的通信，以便将边从一个顶点移动到另一个顶点，这在通过1.x MapReduce时需要大量不必要的开销。 _图表大放异彩：_图表非常适合显示事物之间的非线性关系：Facebook的好友关系、Twitter的追随者、像社交媒体网站核心一样的分布式图表数据库。_一些为Hadoop做这些的程序：_ApacheGigraph，ApacheSpark的GraphX，Hama，Titan
这些只是替代处理模型和工具中的一小部分。有关开源Hadoop生态系统的全面指南，包括MapReduce以外的处理模型，请参阅Hadoop生态系统Table
4--资源管理器高可用性
当它第一次发布的时候，纱线有它自己的瓶颈：资源管理器。MapReduce1.x中的Single JobTracker负责资源管理、作业调度和作业监控。通过在全局资源管理器和每个应用程序的ApplicationMaster之间划分职责，Yar的早期版本确实改进了这一点。ResourceManager跟踪集群资源和调度应用程序，如MapReduceJobs，但在2.4版之前一直是单点故障，该版本引入了主用/备用体系结构。
在Hadoop 2.4中，单个资源管理器被Single_Active_ResourceManager和一个或多个备用管理器所取代。如果主用资源管理器发生故障，管理员可以手动触发从备用到主用的转换。他们还可以通过将Apache ZooKeeper添加到他们的堆栈中来启用自动故障转移。在ZooKeeper的其他任务协调职责中，它可以跟踪纱线节点的状态，并在发生故障时自动触发向备用状态的过渡。
Hadoop 3.x
在撰写本文时，Hadoop 3.0.0-alpha 1可供测试。3.x分支旨在提供改进，例如HDFS擦除编码以节省磁盘空间，改进YARN的时间轴服务以提高其可扩展性，可靠性和可用性，支持两个以上的NameNodes，以及Intra-datanode平衡器等。要了解更多信息，请访问[主要更改]概述(http：//hadoop.apache.org/docs/r3.0.0-alpha1)。
结论
在本文中，我们了解了Hadoop如何发展以满足日益庞大的数据集的需求。如果你对尝试Hadoop感兴趣，你可能会想看看在Ubuntu 16.04.上以独立模式安装Hadoop有关大数据概念的一般信息，请参阅大数据概念和Terminology.简介