引言

Apache Hadoop 是最早和最有影响力的开源工具之一,用于存储和处理随着万维网的兴起而积累的大量随时可用的数字数据。 它是从一个叫做 Nutch 的项目发展而来的,该项目试图找到一种更好的开源方式来爬网。 的创建者深受谷歌两篇关键论文的思想影响,最初将其整合到 Nutch 中,但最终存储和处理工作分离到 Hadoop 项目中,同时继续开发 Nutch 作为自己的 web 爬行项目。

在本文中,我们将简要地讨论数据系统和大数据系统的一些特定的、不同的需求。 然后我们将看看 Hadoop 是如何进化来满足这些需求的。

数据系统

数据无处不在: 纸片、书籍、照片、多媒体文件、服务器日志和网站。 当有目的地收集这些数据时,它们就进入了一个数据系统。

设想一个学校项目,学生们每天测量附近一条小溪的水位。 他们把测量结果记录在一个剪贴板上,回到他们的教室,然后把数据输入到电子表格中。 当他们收集到足够的数量时,他们就开始分析。 他们可能会比较不同年份相同的月份,从最高水位到最低水位排序。 他们可能会建立图表来寻找趋势。

这个学校项目展示了一个数据系统:

  • 信息存在于不同的地方(不同学生的实地笔记本)
  • 它被收集到一个系统中(手工输入到电子表格中)
  • 它被存储(保存在教室计算机的磁盘上; 野外笔记本可能被复制或保存以验证数据的完整性)
  • 对其进行分析(聚合、排序或以其他方式操作)
  • 显示处理过的数据(表格、图表、图表)

这个项目属于范围很小的一部分。 一台计算机可以存储、分析和显示一条小溪的日水位测量数据。 另一方面,世界上所有网页上的所有内容组成了一个更大的数据集。 最基本的就是大数据: 这么多的信息,一台电脑都装不下。

搜索引擎公司正面临着这个特殊的问题,因为网络内容在互联网时代呈爆炸式增长。 2003年,谷歌发表了一篇颇具影响力的论文---- 《谷歌文件系统》 ,其中描述了谷歌专有软件如何处理为其搜索引擎处理的海量数据的存储。 2004年,谷歌推出了 MapReduce: 大型集群上的简化数据处理,详细介绍了他们如何简化处理如此大量的数据。 这两篇论文强烈地影响了 Hadoop 的体系结构。

大数据有什么不同?

谷歌的论文和 Hadoop 对这些想法的实施基于对数据的四个主要改变,这些改变是适应数据量所必需的:

  1. 大数据系统必须接受数据会被分发的事实。 将数据集存储在一个机器集群中是不可避免的。
  2. 一旦集群成为存储的基础,那么软件就必须考虑硬件故障,因为当你在集群中运行成百上千台机器时,硬件故障是不可避免的。
  3. 由于机器会出故障,它们需要一种新的相互沟通的方式。 在日常的数据计算中,我们习惯于一些特定的机器,通常由一个 IP 地址或主机名来识别,并将特定的数据发送到另一个特定的机器。 这种显式通信必须被隐式通信所取代,在这种通信中,一些机器告诉另一些机器它必须处理一些特定的数据。 否则,程序员将面临至少与数据处理问题本身一样大的验证问题。
  4. 最后,计算需要在分布式计算机上处理数据,而不是通过网络传输大量数据。

2007年发布的基于 java 的编程框架 Hadoop 的1.0版本是第一个在思维上接受这些变化的开源项目。 它的第一次迭代由两个层次组成:

  1. Hdfs: Hadoop 分散式档案系统,负责在多台机器之间存储数据。
  2. Mapreduce: 软件框架,用于处理每台机器上的现有和并行数据,以及调度任务、监视任务和重新运行失败的任务。

1.0

是一个分布式存储层,Hadoop 使用它来分散数据,并确保数据能够被正确地存储到下一个分散式档案系统。

1.0是如何工作的

使用块复制在多台计算机上可靠地存储非常大的文件,它有两个不同的软件: NameNode 服务器,管理文件系统名称空间和客户端访问; DataNodes,负责服务读写请求,以及块创建、删除和复制。 对复制模式的基本理解有助于开发人员和集群管理员,因为虽然它通常工作良好,但数据分布的不平衡可能影响集群性能,需要进行调优。

Hdfs 将每个文件存储为一个块序列,除了最后一个文件,每个文件的大小相同。 默认情况下,块被复制三次,但是块的大小和副本的数量都可以根据每个文件进行配置。 文件只写一次,并且在任何时候只有一个写入器,以便实现高吞吐量数据访问并简化数据一致性问题。

Namenode 根据从集群中的每个 DataNode 接收到的心跳和块报告来决定块复制。 心跳信号表明 DataNode 是健康的,块报告提供了 DataNode 上所有块的列表。

创建新块时,HDFS 将第一个副本放在编写器运行的节点上。 第二个副本是写在一个随机选择的节点在任何机架,除了机架上的第一个副本是写。 然后把第三个复制品放在随机选择的机器上,放在第二个机架上。 如果配置中指定的三个副本超过默认值,那么剩下的副本就是随机放置的,限制是在任何一个节点上放置不超过一个副本,在同一个机架上放置不超过两个副本。

Hdfs 1.0的限制

1.0确立了 Hadoop 作为存储大数据的早期开源领导者的地位。 这种成功的部分原因在于体系结构的决策消除了分布式存储的一些复杂性,但这些选择并非没有折衷。 版本1.0的主要限制包括:

  • 块的分布没有控制 HDFS 的块复制模式是其高可用性的骨干。 它可以非常有效,消除了管理员和开发人员在块存储级别上的关注,但是由于它没有考虑空间利用率或节点的实时情况,集群管理员可能需要使用平衡器实用程序来重新分配块。
  • Namenode: 单点故障与块的分布相比,NameNode 有一个更重要的限制,它代表单点故障。 如果进程或计算机出现故障,整个集群在 NameNode 服务器重新启动之前都不可用,而且即使重新启动,它也必须在集群中的每个节点实际可用之前接收来自它的心跳消息,这会延长停机时间,特别是在大型集群中。

尽管有这些限制,HDFS 对于处理大数据是一个重大贡献。

1.0

Hadoop 的第二层 MapReduce 负责批量处理存储在 HDFS 上的数据。 Hadoop 实现了 Google 的 MapReduce 编程模型,使得开发人员可以使用 HDFS 提供的资源,而无需具备并行和分布式系统的经验。

Mapreduce 1.0是如何工作的

假设我们有一个文本集合,我们想知道每个单词在集合中出现多少次。 文本分布在许多服务器上,因此映射任务在集群中拥有数据块的所有节点上运行。 每个映射器加载适当的文件,处理它们,并为每个匹配项创建键值对。

这些映射只有来自单个节点的数据,因此必须将它们混合在一起,以便将具有相同键的所有值发送到一个 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 支持数据分析和报告,并提供一个类似 sql 的 HDFS 接口。 它抽象了 MapReduce javaapi 查询,为开发人员提供高级查询功能。 Hadoop 1. x 有许多附加组件,但是 MapReduce 的一些关键限制限制了生态系统。

Mapreduce 1的限制

  • Mapreduce 和 HDFS 之间的紧密耦合在1.x 实现中,MapReduce 层的职责超越了数据处理,包括集群资源管理,并与 HDFS 紧密耦合。 这意味着1.x 的附加组件开发人员必须编写多路 MapReduce 程序,不管这个程序是否适合任务,因为 MapReduce 是访问文件系统的唯一方式。
  • 数据分析映射和缩减的静态插槽发生在 DataNode 上,这是处理大数据的关键,但是每个 DataNode 上只有有限的、静态的单用途插槽。 映射时隙只能映射,而 reduce 时隙只能减少。 这个数字是在配置中设置的,没有动态调整的能力,它们是空闲的,因此在集群工作负载不适合配置时就会浪费掉。 时隙分配的刚性也使得非 mapreduce 应用程序难以适当调度。
  • Jobtracker: a Single Point of Failure Hadoop 应用程序将 MapReduce 任务提交给 JobTracker,后者通过定位一个带有可用插槽或靠近数据的地理位置的 TaskTracker,将这些任务分配给特定的集群节点。 如果任务失败,TaskTracker 会通知 JobTracker。 Jobtracker 可能会重新提交作业,将记录标记为不包含在未来处理中,或者可能将不可靠的 TaskTracker 列入黑名单,但是如果 JobTracker 由于任何原因出现故障,所有 MapReduce 任务都会停止。

2. x 的改进

2011年12月发布的 Hadoop 的2. x 分支引入了四个主要的改进并纠正了版本1的关键限制。 Hadoop 2.0引入了 HDFS 联合,去除了 NameNode 作为性能约束和单点故障的作用。 此外,通过引入 YARN (Another Resource Negotiator) ,它将 MapReduce 与 HDFS 解耦,通过允许非 MapReduce 处理模型与 HDFS 交互并绕过 MapReduce 层,打开了附加产品的生态系统。

1ー HDFS Federation

Hdfs 联合引入了名称空间和存储之间的明确分离,使集群中的多个名称空间成为可能。 这提供了一些关键的改进:

  • 名称空间可伸缩性向集群添加更多 NameNodes 的能力允许水平伸缩。 具有许多小文件的大型集群或集群可以从添加额外的 NameNodes 中获益。
  • 性能提高单个 NameNode 限制了文件系统的读 / 写吞吐量。多个 NameNode 减轻了对文件系统操作的限制。
  • 名称空间之间的隔离在使用单个 NameNode 的多租户环境中,一个噪声邻居可能会影响系统上的其他所有用户。 有了联邦,隔离系统居民成为可能。

Hdfs 联邦是如何工作的

联邦 NameNodes 管理文件系统名称空间。 它们独立运作,不相互协调。 相反,集群中的 datanode 使用每个 NameNode 寄存器,发送心跳和阻塞报告,并处理从 NameNode 传入的命令。

块与 Hadoop 1. x 中的随机复制一样分布在公共存储中。 属于一个名称空间的所有块都称为块池。 这些池是独立管理的,允许名称空间为新块生成块 id,而无需与其他名称空间协调。 名称空间及其块池的组合称为名称空间卷(Namespace Volume) ,它形成一个自包含的单元,因此当删除一个联邦 NameNodes 时,也会删除其块池。

除了引入 NameNode 联合提供了更好的可伸缩性、性能和隔离性之外,Hadoop 2.0还引入了 NameNode 的高可用性。

2ー NameNode 高可用性

在 Hadoop 2.0之前,如果 NameNode 失败,则整个集群在重新启动或在新机器上启动之前都不可用。 对 NameNode 的软件或硬件的升级同样创建了停机时间窗口。 为了防止这种情况,Hadoop 2.0实现了一个主动 / 被动配置,以支持快速故障转移。

Namenode HA 是如何工作的

两台独立的计算机配置为 NameNodes,一台处于活动状态,另一台处于备用状态。 它们共享对共享存储设备上的公共目录的访问,当主动节点执行修改时,它将记录存储在该公共目录中的日志文件中的更改。 备用节点不断监视目录,并在编辑时将这些编辑应用到自己的名称空间。 如果活动节点失败,备用节点将从共享存储读取未应用的编辑,然后将自己提升为活动节点。

3ー纱线

2.0与 HDFS 分离的 MapReduce。 工作负载管理、多租户、安全控制和高可用性特性被剥离出来成为纱(又一个资源谈判者)。 本质上讲,YARN 是一个大规模的大数据应用分布式操作系统,它使 Hadoop 非常适合 MapReduce 和其他不能等待批处理完成的应用程序。 通过使用常常 i / o 密集、高延迟的 MapReduce 框架,YARN 不再需要工作,从而使新的处理模型能够与 HDFS 一起使用。 解耦的 mapreduce 仍然是一个面向用户的框架,专门用于执行它原本打算执行的任务: 批处理。

下面是 Hadoop 2. x 用户可用的一些处理模型:

  • 批处理批处理系统是非交互式的,在处理开始之前可以访问所有数据。 此外,在处理过程中所探讨的问题必须在处理开始之前知道。 批处理通常具有较高的延迟,大数据批处理作业的速度通常以分钟或更长时间来衡量。 批量处理的亮点: 索引数据、网络爬行和数据处理一些可以为 Hadoop 做到这一点的程序: MapReduce、 Tez、 Spark、 Hive 和 Flink
  • 当你不能提前知道所有的问题时,交互式处理系统是必需的。 相反,用户解释一个查询的答案,然后形成一个新的问题。 为了支持这种探索,必须比典型的 MapReduce 作业更快地返回响应。 交互式处理的亮点: 交互式处理支持数据探索。 一些为 Hadoop 做这些的程序: Impala,Drill,HAWQ,Presto,Vortex,和 Vertica SQL,Tez
  • 流处理流处理系统采用大量的离散数据点,并在新数据到达系统时执行连续查询以产生接近实时的结果。 流处理的亮点: 任何时候你已经有数字化的数据正在不断地产生。 例如,为了跟踪新兴趋势或监视服务器日志,监视社交媒体中对某个问题、事件或产品的公众情绪。 一些为 Hadoop 做这些的程序: 火花流,暴风雨
  • 图处理图算法通常需要顶点或跳点之间的通信,以便将一条边从一个顶点移动到另一个顶点,这在通过1. x MapReduce 时需要大量不必要的开销。 图表闪耀之处: 图表是显示事物之间非线性关系的理想工具: Facebook 的朋友关系,Twitter 的追随者,分布式图表数据库,就像社交媒体网站的核心。 一些为 Hadoop 做这些的程序: Apache Giraph,Apache Spark 的 GraphX,Hama,Titan

这些只是一些可供选择的处理模型和工具。 有关开源 Hadoop 生态系统的全面指南,包括 MapReduce 以外的处理模型,请参阅 Hadoop 生态系统表

4ー ResourceManager 高可用性

当它第一次发布的时候,纱线有它自己的瓶颈: ResourceManager。 Mapreduce 1. x 中的单个 JobTracker 处理资源管理、作业调度和作业监视。 纱线的早期版本通过在全球资源管理器和每个应用程序应用程序 master 之间分配职责的方式对此进行了改进。 Resourcemanager 跟踪集群资源和调度应用程序,比如 MapReduce Jobs,但是在2.4版本引入了 active / standby 体系结构之前,它一直是单点故障。

在 Hadoop 2.4中,单个资源管理器被单个主动资源管理器和一个或多个备用资源所取代。 在活动 ResourceManager 出现故障时,管理员可以手动触发从备用到活动的转换。 它们还可以通过在堆栈中添加 Apache ZooKeeper 来启用自动故障转移。 在 Zookeeper 的其他任务协调职责中,它可以跟踪 YARN 节点的状态,并在发生故障时自动触发向备用节点的转换。

3. x

在撰写本文时,Hadoop 3.0.0-alpha1可用于测试。 3.x 分支旨在提供改进,例如 HDFS 擦除编码以节省磁盘空间,改进 YARN 的时间轴服务以提高其可伸缩性、可靠性和可用性,支持两个以上的 NameNodes 和 Intra-datanode 平衡器等等。 要了解更多,请访问主要变化的概述。

总结

在这篇文章中,我们研究了 Hadoop 是如何进化来满足日益增长的大型数据集的需求的。 如果你对 Hadoop 的实验感兴趣,你可以看看在 ubuntu16.04上的单机模式下的 Hadoop 安装。 有关大数据概念的详细信息,请参阅大数据概念和术语介绍。