1.2 Hadoop核心

1.2.1 分布式文件系统——HDFS

1.HDFS架构及简介

HDFS是以分布式进行存储的文件系统，主要负责集群数据的存储与读取。HDFS是一个主/从（Master/Slave）体系结构的分布式文件系统，从某个角度看，它就和传统的文件系统一样。HDFS 支持传统的层次型文件组织结构，用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似，可以通过文件路径对文件执行创建、读取、更新和删除操作。但是由于分布式存储的性质，它又和传统的文件系统有明显的区别。它的基本架构如图1-2所示。

HDFS文件系统主要包括一个NameNode、一个Secondary NameNode和多个DataNode。

（1）元数据

元数据不是具体的文件内容，它有三类重要信息：第一类是文件和目录自身的属性信息，例如文件名、目录名、父目录信息、文件大小、创建时间、修改时间等；第二类记录文件内容存储的相关信息，例如文件分块情况、副本个数、每个副本所在的DataNode信息等；第三类用来记录HDFS中所有DataNode的信息，用于DataNode管理。

（2）NameNode

NameNode 用于存储元数据以及处理客户端发出的请求。在 NameNode中存放元信息的文件是 fsimage 文件。在系统运行期间，所有对元数据的操作都保存在内存中，并被持久化到另一个文件edits中。当NameNode启动的时候，fsimage会被加载到内存，然后对内存里的数据执行edits所记录的操作，以确保内存所保留的数据处于最新的状态。

（3）Secondary NameNode

Secondary NameNode用于备份NameNode的数据，周期性将edits文件合并到fsimage文件并在本地备份，将新的fsimage文件存储到NameNode，取代原来的fsimage，删除edits文件，创建一个新的edits继续存储文件修改状态。

（4）DataNode

DataNode是真正存储数据的地方。在 DataNode中，文件以数据块的形式进行存储。当文件传到HDFS端时以128MB的数据块将文件进行切割，将每个数据块存到不同的或相同的DataNode并且备份副本，一般默认3个，NameNode会负责记录文件的分块信息，确保在读取该文件时可以找到并整合所有块。

（5）数据块

文件在上传到HDFS时根据系统默认文件块大小把文件分成一个个数据块，Hadoop 2.x默认128MB为一个数据块，比如存储大小为129MB的文件，则被分为两个块来存储。数据块会被存储到各个节点，每个数据块都会备份副本。

2.HDFS分布式原理

什么是分布式系统？分布式系统会划分成多个子系统或模块，各自运行在不同的机器上，子系统或模块之间通过网络通信进行协作，实现最终的整体功能。利用多个节点共同协作完成一项或多项具体业务功能的系统就是分布式系统。

分布式文件系统是分布式系统的一个子集，其解决的问题就是数据存储。换句话说，它是横跨在多台计算机上的存储系统。存储在分布式文件系统上的数据自动分布在不同的节点上。

HDFS作为一个分布式文件系统，主要体现在以下三个方面。

（1）HDFS 并不是一个单机文件系统，它是分布在多个集群节点上的文件系统。节点之间通过网络通信进行协作，提供多个节点的文件信息，让每个用户都可以看到文件系统的文件，让多机器上的多用户分享文件和存储空间。

（2）文件存储时被分布在多个节点上。这里涉及一个数据块的概念，数据存储不是按一个文件存储，而是把一个文件分成一个或多个数据块存储，数据块的概念在前面已经描述过。数据块在存储时并不是都存储在一个节点上，而是被分布存储在各个节点中，并且数据块会在其他节点存储副本。

（3）数据从多个节点读取。读取一个文件时，从多个节点中找到该文件的数据块，分布读取所有数据块，直到最后一个数据块读取完毕。

3.HDFS宕机处理

数据存储在文件系统中，如果某个节点宕机了，就很容易造成数据流失，HDFS 针对这个问题提供了有效的保护措施。

（1）冗余备份

在数据存储的过程中，对每个数据块都进行了副本备份，副本个数可以自行设置。

（2）副本存放

仅仅对数据进行冗余备份还不够，假设所有的备份都在一个节点上，那么该节点宕机后，数据一样会丢失，因此HDFS要有一个更有效的副本存放策略。目前使用的策略是，以dfs.replication=3为例，在同一机器的两个节点上各备份一个副本，然后在另一台机器的某个节点上再放一个副本。前者防止该机器的某个节点宕机，后者防止某个机器宕机。

（3）宕机处理

① 当一切运行正常时，DataNode 会周期性发送心跳信息给 NameNode（默认是每 3s一次）。如果 NameNode在预定的时间内没有收到心跳信息（默认是10min），它会认为DataNode出问题了，把它从集群中移除。对于HDFS来说，丢失一个DataNode意味着丢失了存储在它的硬盘上的数据块的副本。HDFS 会检测到存储在该硬盘的数据块的副本数量低于要求，且主动对副本数量不符合要求的数据块创建需要的副本，以达到满副本数状态。DataNode可能因为多种原因脱离集群，如硬件故障、主板故障、电源老化和网络故障等。

② 当HDFS读取某个数据块时，如果正好该节点宕机了，客户端就会到存储该数据块的其他节点上读取，除非其他节点损坏或者该数据块在存储时损坏，否则依然可以得到该数据块的信息。HDFS也会检测到该数据块副本个数不符合要求而重新补全副本。

③ 当HDFS存储数据时，如果要存放数据的节点宕机，HDFS会再分配一个节点给数据块，然后备份宕机节点的数据。

4.HDFS特点

（1）优点

① 高容错性。

HDFS 上传的数据自动保存多个副本，通过增加副本的数量来增加它的容错性。如果某一个副本丢失，HDFS机制会复制其他机器上的副本，而我们不必关注它的实现。

② 适合大数据的处理。

HDFS能够处理GB、TB甚至PB级别的数据，规模达百万，数量非常大。

③ 流式数据访问。

HDFS以流式数据访问模式来存储超大文件，“一次写入，多次读取”。文件一旦写入，不能修改，只能增加。这样可以保证数据的一致性。

（2）缺点

① 不适合低延迟数据访问。

如果要处理一些用户要求时间比较短的低延迟应用请求，则 HDFS不适合。HDFS是为了处理大型数据集分析任务而设计的，目的是为达到高的数据吞吐量，这就可能要求以高延迟作为代价。

② 无法高效存储大量小文件。

因为NameNode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由NameNode的内存大小来决定的，即每存入一个文件都会在NameNode中写入文件信息。如果写入太多小文件，NameNode 内存会被占满而无法写入文件信息。而与多个小文件大小相同的单一文件只会写入一次文件信息到内存中，所以更适合大文件存储。

③ 不支持多用户写入及任意修改文件。

在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

1.2.2 分布式计算框架——MapReduce

1.MapReduce简介

MapReduce是Hadoop的核心计算框架，是用于大规模数据集（大于1TB）并行运算的编程模型，主要包括 Map（映射）和 Reduce（规约）两部分。当启动一个 MapReduce任务时，Map端会读取HDFS上的数据，将数据映射成所需要的键值对类型并传到Reduce端。Reduce端接收Map端传过来的键值对类型的数据，根据不同键进行分组，对每一组键相同的数据进行处理，得到新的键值对并输出到HDFS，这就是MapReduce的核心思想。

2.MapReduce工作原理

MapReduce作业执行流程如图1-3所示。

一个完整的 MapReduce 过程包含数据的输入与分片、Map 阶段数据处理、Reduce 阶段数据处理、数据输出等阶段。

（1）读取输入数据：MapReduce过程中的数据是从HDFS分布式文件系统中读取的。文件在上传到HDFS时，一般按照128MB分成了几个数据块，所以在运行MapReduce程序时，每个数据块都会生成一个Map，但是也可以通过重新设置文件分片大小调整Map的个数，在运行 MapReduce 时会根据所设置的分片大小对文件重新分割（Split），一个分片大小的数据块就会对应一个Map。

（2）Map阶段：程序有一个或多个Map，由默认存储或分片个数决定。针对Map阶段，数据以键值对的形式读入，键的值一般为每行首字符与文件最初始位置的偏移量，即中间所隔字符个数，值为这一行的数据记录。根据需求对键值对进行处理，映射成新的键值对，将新的键值对传到Reduce端。

（3）Shuffle/Sort阶段：此阶段是指从Map输出开始，传送Map输出到Reduce作为输入的过程。该过程会将同一个Map中输出的键相同的数据先进行一步整合，减少传输的数据量，并且在整合后将数据按照键排序。

（4）Reduce阶段：Reduce任务也可以有多个，按照Map阶段设置的数据分区确定，一个分区数据被一个 Reduce 处理。针对每一个 Reduce 任务，Reduce 会接收到不同 Map任务传来的数据，并且每个Map传来的数据都是有序的。一个Reduce任务中的每一次处理都是针对所有键相同的数据，对数据进行规约，以新的键值对输出到HDFS。

根据上述内容分析，其实MapReduce的本质用一张图可以完整地表现出来，如图1-4所示。

MapReduce 的本质就是把一组键值对<K1,V1>经过 Map 阶段映射成新的键值对<K2,V2>，接着经过 Shuffle/Sort 阶段进行排序和“洗牌”，把键值对排序，同时把相同的键的值整合，最后经过Reduce阶段，把整合后的键值对组进行逻辑处理，输出新的键值对<K3,V3>。

通过图1-5的小例子简单理解MapReduce本质，理解MapReduce的Map端和Reduce端的基本运行原理。

例子中的键值对（1,3）、（2,7）、（1,4）、（2,8）分别在两个Map中，Map阶段的处理是对键值对的值进行平方，则两个Map输出分别为（1,9）、（2,49）和（1,16）、（2,64）。Reduce阶段是对一个或多个Map输出按键进行处理，这里是对同一个键的值求和，Reduce把两个Map的输出整合到一起，对键都为1的值相加，键都为2的值相加，得到新的键值对（1,25）、（2,113）。

1.2.3 集群资源管理器——YARN

1.YARN简介

Hadoop YARN的目的是使得Hadoop数据处理能力超越MapReduce。众所周知，Hadoop HDFS是Hadoop的数据存储层，Hadoop MapReduce是数据处理层。然而，MapReduce已经不能满足今天广泛的数据处理需求，如实时/准实时计算、图计算等。而 Hadoop YARN提供了一个更加通用的资源管理和分布式应用框架。在这个框架上，用户可以根据自己的需求实现定制化的数据处理应用。而Hadoop MapReduce也是YARN上的一个应用。YARN的另一个目标就是拓展 Hadoop，使得它不仅可以支持 MapReduce 计算，还能很方便地管理诸如Hive、HBase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过YARN从系统层面进行统一的管理。也就是说，有了YARN，各种应用就可以互不干扰地运行在同一个Hadoop系统中，共享整个集群资源。

2.YARN的基本架构和任务流程

Hadoop 1.0版本中还没有YARN框架，Hadoop 1.0中的MapReduce框架（简称MRv1）由Client、JobTracker和TaskTracker三个部分组成，Client负责提交任务，JobTracker负责资源管理和任务调度，TaskTracker负责执行任务和汇报任务情况。YARN是Hadoop 2.0中的资源管理系统，它的基本设计思想是将MRv1的JobTracker拆分成两个独立的服务：一个全局的资源管理器 ResourceManager 和每个应用程序特有的 ApplicationMaster。其中， ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。

（1）YARN的基本组成结构

YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用于跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。本节将对YARN的基本组成结构进行介绍。

图1-6描述了YARN的基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster和Client Application等构成。

① ResourceManager（RM）。是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。

调度器负责将系统中的资源分配给各个正在运行的应用程序，它不从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。

应用程序管理器负责处理客户端提交的Job以及协商第一个Container（包装资源的对象）以供ApplicationMaster运行，并且在ApplicationMaster失败的时候会将其重新启动。

② NodeManager（NM）。是每个节点上的资源和任务管理器。一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自ApplicationMaster的Container启动/停止等各种请求。其中，Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等。当ApplicationMaster向RM申请资源时，RM为ApplicationMaster返回的资源便是用Container表示的。YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。

③ ApplicationMaster（AM）。在用户提交每个应用程序时，系统都会生成一个ApplicationMaster并包含到提交的程序里，主要功能如下。

与ResourceManager调度器协商以获取资源（用Container表示）。

将得到的任务进一步分配给内部的任务。

与NodeManager通信以启动/停止任务。

监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

④ Client Application。Client Application是客户端应用程序，客户端将应用程序提交到RM，首先会创建一个Application上下文件对象，并设置AM必需的资源请求信息，然后提交到RM。

（2）YARN工作流程

接下来详细描述YARN从提交任务到完成任务的整个工作流程。如图1-7所示，YARN的工作流程分为以下几个步骤。

① 用户通过客户端 Client 提交一个应用程序到 YARN 中进行处理，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

② ResourceManager为该应用程序分配第一个 Container，并与分配的Container所在位置的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster。该Container用于启动ApplicationMaster和ApplicationMaster后续命令。

③ ApplicationMaster 启动后先向 ResourceManager 注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后开始为提交的应用程序所需要执行的各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤④～⑦。这个示例应用中需要执行两个Map任务和一个Reduce任务，所以需要轮番执行步骤④～⑦3次，先执行Map任务，再执行Reduce任务。

④ ApplicationMaster采用轮流询问的方式通过RPC协议向ResourceManager申请和领取资源。所以多个应用程序同时提交时，不一定是第一个先执行。

⑤ 一旦 ApplicationMaster 申请到资源，便与资源对应的 NodeManager 通信，要求它在分配的资源中启动任务。

⑥ NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。

⑦ 被启动的任务开始执行，各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

⑧ 应用程序运行完成后，ApplicationMaster向ResourceManager注销自己。

⑨ 关闭客户端与ApplicationMaster。