介绍
Apache Hadoop是最早和最有影响力的开源工具之一，用于存储和处理随着万维网的兴起积累的大量随时可用的数字数据。它从一个名为Nutch的项目演变而来，它试图找到一个更好的开源方式来爬网。 Nutch的创作者受到来自Google的两份关键文件的思考的深深影响，最初将其纳入Nutch，但最终存储和处理工作分为Hadoop项目，同时继续开发Nutch作为自己的网络爬行项目。 在本文中，我们将简要考虑数据系统和大数据系统的一些具体，区别的需求。然后我们将看看Hadoop如何演变以满足这些需求。
数据系统
数据存在于所有地方：纸张，书籍，照片，多媒体文件，服务器日志和网站上。当有意收集该数据时，它进入数据系统。 想象一下，一个学校项目，学生每天测量附近一条小溪的水位。他们在现场记录他们的测量在剪贴板上，返回到他们的教室，并在电子表格中输入该数据。当他们收集到足够的金额时，他们开始分析它。他们可以比较不同年份的相同月份，从最高水位到最低水位。他们可能构建图形以查找趋势。 这个学校项目说明了一个数据系统：
- 信息存在于不同地点（不同学生的现场笔记本）
- 它被收集到系统中（手工输入到电子表格中）
- 它被存储（保存到教室计算机上的磁盘;现场笔记本可能被复制或保留以验证数据的完整性）
- 它被分析（聚合，排序或以其它方式操纵）
- 显示处理的数据（表，图表，图形）
这个项目是在光谱的小端。单台计算机可以存储，分析和显示一条河的每日水位测量值。在频谱的另一端，世界上所有网页上的所有内容形成了更大的数据集。在其最基本的是大数据：这么多的信息，它不能适合在一个单一的计算机。 搜索引擎公司面临这一具体问题，因为网络内容在Dot-com时代爆炸。在2003年，谷歌发布了其影响力的论文，
在谷歌文件系统描述自己的专利软件如何处理他们的搜索引擎正在处理数据的海量存储。 它于2004年被谷歌遵循的
MapReduce：简化数据处理大型集群 ，里面详细介绍他们是如何简化处理如此大量的数据。这两篇文章强烈影响了Hadoop的架构。
大数据如何不同？
Google论文和Hadoop对这些想法的实现在于思考数据的四个主要变化，这些变化对于满足数据量是必要的：
- 大数据系统，不得不接受这些数据将被分发 。将数据集存储在一组机器上是不可避免的。
- 一旦集群成为存储基础，那么软件必须考虑到硬件故障 ，因为硬件故障是不可避免的，当你谈论在群集中运行的机器成百上千。
- 由于机器会失败，他们需要相互通信的新方式。 在日常数据计算中，我们习惯于某些特定机器，通常由IP地址或主机名标识，将特定数据发送到另一个特定机器。 这种明确的沟通必须与隐式通信 ，一些设备显示一些其他的机器，它必须处理一些具体的数据来代替 。否则，程序员将面临至少与数据处理问题本身一样大的验证问题。
- 最后， 计算需要去的数据并进行处理则分布式计算机上 ，而非通过网络移动大量数据。
在2007年发布的基于Java的编程框架Hadoop的1.0版本是第一个接受思维变化的开源项目。它的第一次迭代包括两个层：
- HDFS：Hadoop分布式文件系统，负责在多台计算机中存储数据。
- 的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是处理大数据的主要贡献。
MapReduce 1.0
第二层Hadoop，MapReduce，负责批量处理存储在HDFS上的数据。 Hadoop的Google MapReduce编程模型的实现使开发人员能够使用HDFS提供的资源，而无需对并行和分布式系统的经验。
MapReduce 1.0的工作原理
假设我们有一个文本集合，我们想知道每个单词在集合中出现的次数。文本分布在许多服务器上，因此映射任务在集群中具有集合中的数据块的所有节点上运行。每个映射器加载适当的文件，处理它们，并为每个事件创建一个键值对。 这些映射只有来自单个节点的数据，因此它们必须混合在一起，以便具有相同键值的所有值可以发送到reducer。当reducer完成时，输出被写入reducer的磁盘。这种隐式通信模式使Hadoop用户不必将信息从一台机器显式移动到另一台机器。 我们将用几句话来说明这一点： 她卖贝壳由六个海滨。 她肯定卖贝壳好。
MAPPING SHUFFLING REDUCING
{she, 1} {she, 1, 1} {she, 2}
{sells, 1} {sells, 1, 1} {sells, 2}
{seashells, 1} {seashells, 1, 1} {seashells, 2}
{by, 1} {by, 1} {by, 1}
{six, 1} {six, 1} {six, 1}
{seashores, 1} {seashores, 1, 1} {seashores, 2}
{she, 1} {sure, 1} {sure, 1}
{sure, 1} {well, 1} {well, 1}
{sells}
{seashells, 1}
{well, 1}
如果这种映射是在大型数据集上按顺序完成的，则需要花费太长时间，但并行完成，然后减少，它对大型数据集可扩展。 较高级别的组件可以插入到MapReduce层中以提供附加功能。例如，Apache Pig为开发人员提供了通过将Java MapReduce成语抽象到更高级别来编写数据分析程序的语言，类似于SQL对关系数据库的定义。 Apache Hive通过类似HDFS的接口支持数据分析和报告。它抽象化MapReduce Java API查询，为开发人员提供高级查询功能。许多额外的组件可用于Hadoop 1.x，但是生态系统受到MapReduce中的一些关键限制的约束。
MapReduce的限制1
- MapReduce和HDFS之间紧密耦合 在1.x实现中，MapReduce层的职责扩展到数据处理之外，包括集群资源管理，并且紧密耦合到HDFS。这意味着1.x的附加开发人员必须编写多次传递MapReduce程序，无论它是否适合任务，因为MapReduce是访问文件系统的唯一方法。
- 数据分析的静态插槽 映射和减少发生在DataNode上，这是处理大数据的关键，但每个DataNode上只有有限的静态数量的单用途插槽。映射槽只能映射，而reduce槽只能减少。在没有动态调整容量的配置中设置此编号，并且它们处于空闲状态，因此无论何时群集工作负载不适合配置，都会浪费该编号。插槽分配的刚性也使得非MapReduce应用程序难以适当调度。
- JobTracker：单点故障 Hadoop应用程序向JobTracker提交MapReduce任务，然后通过定位具有可用插槽或地理位置靠近数据的TaskTracker将这些任务分发到特定集群节点。 TaskTracker通知JobTracker任务是否失败。 JobTracker可以重新提交作业，将记录标记为从将来处理中排除，或者可能将不可靠的TaskTracker列入黑名单，但是如果JobTracker因任何原因而失败，则所有MapReduce任务都将暂停。
改进Hadoop 2.x
Hadoop的2.x分支在2011年12月发布，引入了四个主要改进，并更正了版本1的主要限制.Hadoop 2.0引入了HDFS联合，它将NameNode作为性能约束和单点故障删除。此外，通过引入YARN（又一个资源协商器），MapReduce与HDFS解耦，通过允许非MapReduce处理模型与HDFS交互并绕过MapReduce层，打开附加产品的生态系统。
1 - HDFS联合会
HDFS联合引入了命名空间和存储之间的明确分离，使得集群中的多个命名空间成为可能。这提供了一些关键的改进：
- 命名空间的可扩展性 ，以增加更多的NameNodes到群集允许水平扩展的能力。具有许多小文件的大集群或集群可以从添加其他NameNode中受益。
- 性能提升有限1.x的文件系统读取/写入吞吐量的单NameNode的。多个NameNode减轻了对文件系统操作的这个约束。
- 与单一的NameNode 的命名空间在多租户环境之间的隔离 ，这是可能的一个嘈杂的邻居影响系统中的所有其他用户。通过联合，可以隔离系统居民。
HDFS联合如何工作
Federated NameNodes管理文件系统命名空间。它们独立操作，彼此不协调。相反，集群中的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解耦。工作负载，多租户，安全控制和高可用性功能的管理分散到YARN（又一资源协商器）中。 YARN实质上是大数据应用程序的大规模分布式操作系统，使Hadoop非常适合MapReduce以及其他无法等待批处理完成的应用程序。 YARN消除了通过I / O密集型，高延迟MapReduce框架工作的需要，使得新的处理模型能够与HDFS一起使用。解耦MapReduce仍然是一个面向用户的框架，专门用于执行它打算执行的任务：批处理。 下面是一些可用于Hadoop 2.x用户的处理模型：
- 批量处理 批处理系统是非交互式的，并且在处理开始之前可以访问所有数据。此外，在处理开始之前必须知道在处理期间探索的问题。批处理通常是高延迟，大数据批处理作业的速度通常以分钟或更长时间来衡量。 凡批处理眼前一亮：索引数据，抓取网络内容和数据运算 有些程序可以为Hadoop的做到这一点：MapReduce的，TEZ，星火，配置单元，弗林克
- 交互处理 当您不知道所有的问题时，需要交互式处理系统。相反，用户解释查询的答案，然后制定新的问题。为了支持这种探索，响应必须比典型的MapReduce作业更快地返回。 凡交互处理眼前一亮：交互式处理支持数据的探索。 某些程序，对Hadoop的做到这一点：黑斑羚，钻，HAWQ，转眼间，涡和Vertica的SQL，TEZ
- 流处理 流处理系统需要大量的离散数据点并执行连续查询以在新数据到达系统时产生近实时结果。 其中，流处理眼前一亮：任何时候你有不断被已经产生的数字数据。示例包括监控社交媒体中的问题，事件或产品的公众情绪，以跟踪新趋势或监控服务器日志。 对于Hadoop的做到这一点的程序有：星火流，风暴
- 图处理 图形算法通常需要顶点或跳跃之间的通信，以便将边缘从一个顶点移动到另一个顶点，这在通过1.x MapReduce时需要大量不必要的开销。 凡图形眼前一亮：图是理想的展示事物之间的非线性关系：Facebook的好友关系，Twitter的追随者，分布式数据库的图形像在社会媒体网站的核心。 某些程序，对Hadoop的做到这一点：ApacheGiraph，Apache星火的GraphX，哈马，泰坦
这些只是一些替代处理模型和工具。对于除MapReduce的其他一个全面的指导，以开源的Hadoop生态系统，包括处理模型，看到
在Hadoop生态系统表
4 - ResourceManager高可用性
当它第一次发布时，YARN有自己的瓶颈：ResourceManager。 MapReduce 1.x中的单个JobTracker处理资源管理，作业调度和作业监视。 YARN的早期版本通过在全局ResourceManager和每个应用程序ApplicationMaster之间分担职责来改进这一点。 ResourceManager跟踪了集群资源并调度了应用程序，例如MapReduce Jobs，但是在2.4版本之前是一个单点故障，引入了一个主动/备用架构。 在Hadoop的2.4一个资源管理器是由一个
活跃的ResourceManager和一个或多个备用替换。如果活动ResourceManager发生故障，管理员可以手动触发从备用状态到活动状态的转换。他们还可以通过将Apache Zookeeper添加到它们的来启用自动故障转移。在Zookeeper的其他任务协调职责中，它可以跟踪YARN节点的状态，并在故障的情况下自动触发到待机状态的转换。
Hadoop 3.x
在撰写本文时，Hadoop 3.0.0-alpha1可用于测试。 3.x分支旨在提供改进，例如HDFS擦除编码以节省磁盘空间，改进YARN的时间轴服务以提高其可扩展性，可靠性和可用性，支持两个以上的NameNode和Intra-datanode平衡器等。要了解更多信息，请访问的概述
重大变化 。
结论
在本文中，我们研究了Hadoop如何发展以满足越来越大的数据集的需求。如果您有兴趣使用Hadoop尝试，你可能想看看
在Ubuntu 16.04在独立模式下安装的Hadoop 。 欲了解更多有关大数据的概念一般，看到
大数据概念和术语的介绍 。
