Apache Hadoop 是一个开源软件框架，用于在商用硬件集群上存储和大规模处理数据集。Hadoop 是 Apache 顶级项目，由全球贡献者和用户社区构建和使用。它根据 Apache 许可证 2.0 获得许可。
Hadoop 由 Doug Cutting 和 Mike Cafarella 于 2005 年创建。它最初是为了支持 Nutch 搜索引擎项目的分发而开发的。当时在 Yahoo! 工作的 Doug，现在是 Cloudera 的首席架构师，以他儿子的玩具大象命名了这个项目。Cutting 的儿子当时 2 岁，刚开始说话。他称他心爱的黄色毛绒大象为“Hadoop”（重音在第一个音节上）。现在 12 岁，Doug 的儿子经常惊呼：“你们为什么不说我的名字，为什么我不获得版税？我应该因此而出名！”
Apache Hadoop 框架由以下模块组成
- Hadoop Common：包含其他 Hadoop 模块所需的库和实用程序
- Hadoop 分布式文件系统 (HDFS)：一种分布式文件系统，可在商用机器上存储数据，从而在整个集群中提供非常高的聚合带宽
- Hadoop YARN：一种资源管理平台，负责管理集群中的计算资源，并使用它们来调度用户的应用程序
- Hadoop MapReduce：一种用于大规模数据处理的编程模型
Hadoop 中的所有模块都基于一个基本假设而设计：硬件故障（单个机器或机器机架的故障）很常见，因此应由框架在软件中自动处理。Apache Hadoop 的 MapReduce 和 HDFS 组件最初分别源自 Google 的 MapReduce 和 Google 文件系统 (GFS) 论文。
除了 HDFS、YARN 和 MapReduce 之外，整个 Apache Hadoop“平台”现在通常被认为由许多相关项目组成，例如：Apache Pig、Apache Hive、Apache HBase 等。
对于最终用户而言，尽管 MapReduce Java 代码很常见，但任何编程语言都可以与“Hadoop Streaming”一起使用，以实现用户程序的“map”和“reduce”部分。Apache Pig 和 Apache Hive 等相关项目公开了更高级别的用户界面，例如 Pig latin 和 SQL 变体。Hadoop 框架本身主要用 Java 编程语言编写，其中一些本机代码是用 C 编写的，命令行实用程序是用 shell 脚本编写的。
HDFS 和 MapReduce
Apache Hadoop 1.x 的核心有两个主要组件：Hadoop 分布式文件系统 (HDFS) 和 MapReduce 并行处理框架。这些都是开源项目，其灵感来自 Google 内部创建的技术。
Hadoop 分布式文件系统
Hadoop 分布式文件系统 (HDFS) 是一种分布式、可扩展且可移植的文件系统，用 Java 编写，用于 Hadoop 框架。Hadoop 实例中的每个节点通常都有一个 namenode，而 datanode 集群形成 HDFS 集群。这种情况很典型，因为每个节点不需要存在 datanode。每个 datanode 使用特定于 HDFS 的块协议通过网络提供数据块。文件系统使用 TCP/IP 层进行通信。客户端使用远程过程调用 (RPC) 在彼此之间进行通信。
HDFS 在多台机器上存储大型文件（通常在千兆字节到太字节范围内）。它通过跨多个主机复制数据来实现可靠性，因此不需要主机上的 RAID 存储。使用默认复制值 3，数据存储在三个节点上：两个在同一机架上，一个在不同的机架上。数据节点可以相互通信以重新平衡数据、移动副本并保持数据的高复制率。HDFS 并非完全符合 POSIX 标准，因为 POSIX 文件系统的要求与 Hadoop 应用程序的目标不同。不使用完全符合 POSIX 标准的文件系统的权衡是提高了数据吞吐量的性能并支持非 POSIX 操作，例如 Append。
HDFS 为 2.x 版本添加了高可用性功能，允许主元数据服务器 (NameNode) 在发生故障时手动故障转移到备份，以及自动故障转移。
HDFS 文件系统包含所谓的辅助 namenode，这误导了一些人认为当主 namenode 脱机时，辅助 namenode 会接管。事实上，辅助 namenode 定期与主 namenode 连接，并构建主 namenode 目录信息的快照，系统随后将其保存到本地或远程目录。这些检查点映像可用于重启发生故障的主 namenode，而无需重放整个文件系统操作日志，然后编辑日志以创建最新的目录结构。由于 namenode 是元数据存储和管理的单点，因此它可能成为支持大量文件（尤其是大量小文件）的瓶颈。HDFS Federation 是一项新增功能，旨在通过允许多个由单独的 namenode 服务的命名空间，在一定程度上解决此问题。
使用 HDFS 的一个优点是作业跟踪器和任务跟踪器之间的数据感知。作业跟踪器根据数据位置将 map 或 reduce 作业调度到任务跟踪器。例如，如果节点 A 包含数据 (x, y, z)，节点 B 包含数据 (a, b, c)，则作业跟踪器调度节点 B 对 (a,b,c) 执行 map 或 reduce 任务，节点 A 将被调度为对 (x,y,z) 执行 map 或 reduce 任务。这减少了网络上的流量，并防止了不必要的数据传输。当 Hadoop 与其他文件系统一起使用时，此优势并非始终可用。这可能会对作业完成时间产生重大影响，这在使用数据密集型作业时已得到证明。HDFS 专为主要不可变的文件而设计，可能不适合需要并发写入操作的系统。
HDFS 的另一个限制是它不能由现有操作系统直接挂载。将数据移入和移出 HDFS 文件系统（通常需要在执行作业之前和之后执行的操作）可能很不方便。已开发用户空间文件系统 (FUSE) 虚拟文件系统来解决此问题，至少对于 Linux 和某些其他 Unix 系统而言是这样。
可以通过本机 Java API、Thrift API（用于生成用户选择的语言（C++、Java、Python、PHP、Ruby、Erlang、Perl、Haskell、C#、Cocoa、Smalltalk 或 OCaml）的客户端）、命令行界面或通过 HTTP 浏览 HDFS-UI Web 应用程序来实现文件访问。
JobTracker 和 TaskTracker：MapReduce 引擎
在文件系统之上是 MapReduce 引擎，它由一个 JobTracker 组成，客户端应用程序向其提交 MapReduce 作业。JobTracker 将工作推送给集群中可用的 TaskTracker 节点，力求使工作尽可能靠近数据。
借助机架感知文件系统，JobTracker 知道哪个节点包含数据，以及哪些其他机器在附近。如果工作无法托管在数据所在的实际节点上，则优先考虑同一机架中的节点。这减少了主干网络上的网络流量。
如果 TaskTracker 失败或超时，则重新调度该作业部分。每个节点上的 TaskTracker 会派生出一个单独的 Java 虚拟机进程，以防止 TaskTracker 本身在运行的作业使 JVM 崩溃时失败。TaskTracker 每隔几分钟向 JobTracker 发送一次心跳，以检查其状态。Job Tracker 和 TaskTracker 状态和信息由 Jetty 公开，可以从 Web 浏览器查看。
如果 JobTracker 在 Hadoop 0.20 或更早版本上失败，则所有正在进行的工作都将丢失。Hadoop 版本 0.21 为此过程添加了一些检查点。JobTracker 记录它在文件系统中的操作。当 JobTracker 启动时，它会查找任何此类数据，以便它可以从上次停止的地方重新启动工作。
Hadoop 1.x 中此方法的已知限制
向 TaskTracker 分配工作非常简单。每个 TaskTracker 都有许多可用槽位（例如“4 个槽位”）。每个活动的 map 或 reduce 任务占用一个槽位。Job Tracker 将工作分配给最靠近数据且具有可用槽位的跟踪器。不考虑已分配机器的当前系统负载，因此不考虑其实际可用性。如果一个 TaskTracker 非常慢，则可能会延迟整个 MapReduce 作业，尤其是在作业结束时，所有内容都可能最终等待最慢的任务。但是，启用推测执行后，可以在多个从属节点上执行单个任务。
Apache Hadoop NextGen MapReduce (YARN)
MapReduce 在 hadoop-0.23 中经历了彻底的改造，我们现在拥有所谓的 MapReduce 2.0 (MRv2) 或 YARN。
Apache™ Hadoop® YARN 是 Hadoop 2.0 中引入的 Apache 软件基金会的 Hadoop 子项目，它将资源管理和处理组件分离。YARN 的诞生源于需要为 HDFS 中存储的数据启用更广泛的交互模式，而不仅仅是 MapReduce。Hadoop 2.0 的基于 YARN 的架构提供了更通用的处理平台，该平台不限于 MapReduce。
MRv2 的基本思想是将 JobTracker 的两个主要功能（资源管理和作业调度/监控）拆分为单独的守护程序。这个想法是拥有一个全局 ResourceManager (RM) 和每个应用程序的 ApplicationMaster (AM)。应用程序可以是经典意义上的 Map-Reduce 作业的单个作业，也可以是作业的 DAG。
ResourceManager 和每个节点的从属节点 NodeManager (NM) 构成了数据计算框架。ResourceManager 是最终权威，可以在系统中所有应用程序之间仲裁资源。
每个应用程序的 ApplicationMaster 实际上是一个特定于框架的库，其任务是从 ResourceManager 协商资源，并与 NodeManager 协作来执行和监视任务。
作为 Hadoop 2.0 的一部分，YARN 采用了 MapReduce 中的资源管理功能，并将它们打包，以便新引擎可以使用它们。这也简化了 MapReduce，使其能够最好地完成数据处理工作。借助 YARN，您现在可以在 Hadoop 中运行多个应用程序，所有应用程序都共享一个公共资源管理。许多组织已经在 YARN 上构建应用程序，以便将它们引入 Hadoop。
作为 Hadoop 2.0 的一部分，YARN 采用了 MapReduce 中的资源管理功能，并将它们打包，以便新引擎可以使用它们。这也简化了 MapReduce，使其能够最好地完成数据处理工作。借助 YARN，您现在可以在 Hadoop 中运行多个应用程序，所有应用程序都共享一个公共资源管理。许多组织已经在 YARN 上构建应用程序，以便将它们引入 Hadoop。当企业数据在 HDFS 中可用时，拥有多种处理数据的方法非常重要。借助 Hadoop 2.0 和 YARN，组织可以将 Hadoop 用于流式处理、交互式处理以及各种其他基于 Hadoop 的应用程序。
YARN 的作用
YARN 通过以下方式增强了 Hadoop 计算集群的功能
- 可扩展性：数据中心的处理能力持续快速增长。由于 YARN ResourceManager 专门专注于调度，因此它可以更轻松地管理更大的集群。
- 与 MapReduce 的兼容性：现有的 MapReduce 应用程序和用户可以在 YARN 之上运行，而不会中断其现有流程。
- 改进的集群利用率：ResourceManager 是一个纯粹的调度程序，可根据容量保证、公平性和 SLA 等标准优化集群利用率。此外，与以前不同，没有命名的 map 和 reduce 槽位，这有助于更好地利用集群资源。
- 支持 MapReduce 以外的工作负载：现在可以使用其他编程模型（例如图形处理和迭代建模）进行数据处理。这些添加的模型使企业能够实现近乎实时的处理，并提高其 Hadoop 投资的 ROI。
- 敏捷性：随着 MapReduce 成为用户区库，它可以独立于底层资源管理器层发展，并以更加敏捷的方式发展。
YARN 的工作原理
YARN 的基本思想是将 JobTracker/TaskTracker 的两个主要职责拆分为单独的实体
- 全局 ResourceManager
- 每个应用程序的 ApplicationMaster
- 每个节点的从属 NodeManager 和
- 在 NodeManager 上运行的每个应用程序容器
ResourceManager 和 NodeManager 构成了新的通用系统，用于以分布式方式管理应用程序。ResourceManager 是最终权威，可以在系统中所有应用程序之间仲裁资源。每个应用程序的 ApplicationMaster 是一个特定于框架的实体，其任务是从 ResourceManager 协商资源，并与 NodeManager 协作来执行和监视组件任务。ResourceManager 有一个调度程序，负责根据队列容量、用户限制等约束，将资源分配给各种正在运行的应用程序。调度程序根据应用程序的资源需求执行其调度功能。NodeManager 是每台机器的从属节点，负责启动应用程序的容器，监视其资源使用情况（CPU、内存、磁盘、网络）并将相同的信息报告给 ResourceManager。每个 ApplicationMaster 都有责任从调度程序协商适当的资源容器，跟踪其状态并监视其进度。从系统角度来看，ApplicationMaster 作为普通容器运行。
最初发布在 Sachin Puttur 的大数据博客上。根据知识共享许可协议修订。
11 条评论