Hadoop总结

Posted 2022-09-06 蓦然1607

一、Hadoop是什么？

Hadoop是一个Apache基金会所开发的分布式系统基础架构。

在工业界，Hadoop已经是公认的大数据通用存储和分析平台，它实现了分布式文件系统HDFS（ Hadoop Distributed File System）、分布式运行程序编程框架MapReduce以及资源管理系统YARN（ Yet Another Resource Negotiator），其中HDFS和MapReduce是它的核心设计部分。

二、Hadoop能够做什么？

Hadoop主要是为了解决海量数据的存储和分析计算问题

一则小故事：

假设老王在某不知名IT公司工作，由于最近太阳活动异常，引起了领导的外甥的读硕士的同学的关注，领导让老王把山西铁岛太阳射电望远镜观测到的近30年的太阳射电数据下载下来，让老王从里面找到最高的记录。老王毕竟搞挨踢已有多年，虽然技术不行，终日碌碌无为，但多年的直觉告诉老王这个很简单。老王立刻下载了其中一个文件并大致看了文件的机构：数据保存在txt文件里，每行N列，其中包含了时间和数据信息列，大约每0.1s记录一条数据，一个文件记录15分钟的数据，大约有9000条记录，1个小时4个文件，1天96个文件，30年大约1051200个文件，一共大约100亿条数据，这其中还有一些损坏的文件，还有一些用9999表示的未检测到值的占位数据需要特殊照顾。

老王觉得单机处理这些数据耗时太久，于是老王找来一些公司淘汰下来的旧服务器（一般小公司最破的机器都是服务器），准备每个机器负责一部分，最后把结果汇总，老王在开发的过程中还是遇到了很多问题，比如，如何分配任务，有的机器破，有的机器新，还有的文件大，有的文件小，总是不能保证所有的任务一起完成，先完成任务的机器闲置浪费掉了资源；还有最后把结果通过网络通信汇总起来，如何保证数据不丢失，不覆盖；还有如果某台机器出了问题，如何重新分配任务，这些非核心业务的开发使得老王心力憔悴，还好，老王最后找到了Hadoop这个工具，这个工具给老王提供了一个简单的编程模型，老王在map方法中写了分配的任务的逻辑，在reduce方法中写了合并结果的逻辑，然后Hadoop帮老王完成了其他所有事情，Hadoop就是干这个的。以上故事纯属虚构，如有雷同，实属巧合。 

其实上述的例子里的数据量不是很大，如果每天产生上TB级别的数据，就算是速度很快的固态硬盘也需要小时级时间才能读取一遍，速度还是远远跟不上，终归有上限，而且高性能主机价格不菲，不如把数据分开放到一个相对廉价又可扩展的计算机集群中，每个节点上运行一段程序并处理一小块数据，然后在汇总处理结果，使用Hadoop可以让开发者不必把精力放在集群的建设上，采用Hadoop提供的简单的编程模型就可以实现分布式处理。

三、Hadoop的特点

1）高可靠性：Hadoop底层维护多个数据副本，所以即使Hadoop某个计算元素或存储出现故障，也不会导致数据的丢失；

2）高扩展性：在集群间分配任务，可方便的扩展数以千计的节点；

3）高效性：在MapReduce的思想下，Hadoop是并行工作的，以加快任务处理速度；

4）高容错性：能够自动将失败的任务重新分配

四、Hadoop核心之HDFS

HDFS是分布式文件管理系统中的一种，它是以Google的GFS为基础开发的文件系统。HDFS是可以在普通硬件上提供可靠的、可伸缩的和容错的数据存储。它与MapReduce紧密合作，将存储和计算分布在大型集群中，并结合存储资源，这些存储资源可以根据请求和查询进行伸缩，同时保持低成本和预算。

1、HDFS架构

HDFS是利用主/从体系结构，也可以说是Master/Slave，也就是NameNode是运行在主属节点上，以及多个从节点是DataNode是运行在每个从属节点上，Secondary NameNode可以运行在主节点上，也可以通过用户配置运行在从节点上，HDFS Client是作为客户端存在的。这些节点都有着自己独有的特点和功能，它们之间能够相互配合。

2、HDFS重要节点

1）NameNode节点

① 管理文件系统的命名空间。

② 记录 每个文件数据块在各个Datanode上的位置和副本信息。

③ 协调客户端对文件的访问。

④ 记录命名空间内的改动或者空间本省属性的改动。

⑤ Namenode 使用事务日志记录HDFS元数据的变化。使用映像文件存储文件系统的命名空间，包括文件映射，文件属性等。

2）DataNode节点

① 负责所在物理节点的存储管理。

② 一次写入，多次读取（不修改）。

③ 文件由数据库组成，一般情况下，数据块的大小为128MB。

④ 数据尽量散步到各个节点。

3）Secondary NameNode节点

该节点主要是辅助NameNode节点，防止单点故障的发生，不过它不是NameNode节点的热备份，而是冷备份，也就说当NameNode节点挂掉之后，Secondary NameNode节点并不能马上替换NameNode节点并提供服务，而是在NameNode节点重启时加快其启动速度（一般重启情况较少）。

而且该节点能够定时从NameNode上获取FSImage和Edits来进行合并。

Secondary NameNode节点工作情况如下：

① Secondary NameNode会定期的从主节点NameNode节点拷贝相应的EditLogs日志，将它加载到内存合并到FSImage镜像文件。

② Secondary NameNode上的FSImage更新之后，生成FSImage.chkpoint文件，之后将新的镜像文件拷贝到NameNode节点。

③ NameNode节点将FSImage.chkpoint文件重新命名为FSImage，更新后的FSImage文件可以防止一些意外，这样就能节约NameNode节点下次的启动所需时间。

3、HDFS优缺点

1）优点

（1）处理超大文件

这里的超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

（2）流式的访问数据

HDFS的设计建立在更多地响应"一次写入、多次读写"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

（3）运行于廉价的商用机器集群上

Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。

2）缺点

（1）不适合低延迟数据访问

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

改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。

（2）无法高效存储大量小文件

因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。

改进策略：要想让HDFS能处理好小文件，有不少方法。

① 利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。

② 横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。

③ 多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。

④ 附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。

（3）不支持多用户写入及任意修改文件

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

4、HDFS数据流

这里总结了两个个版本的数据读写流程，第一个是简介版本，第二个是详细版本。

简洁版

写数据流程

步骤如下：

1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。   

2）NameNode返回是否可以上传。   

3）客户端请求第一个 block上传到哪几个datanode服务器上。   

4）NameNode返回3个datanode节点，分别为dn1、dn2、dn3。   

5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。   

6）dn1、dn2、dn3逐级应答客户端。   

7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。   

8）当一个block传输完成之后，客户端再次请求NameNode上传第二个block的服务器。（重复执行3-7步）。 

读数据流程

步骤如下：

1）客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。   

2）挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。   

3）DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以packet为单位来做校验）。   

4）客户端以packet为单位接收，先在本地缓存，然后写入目标文件。

详细版本

写数据流程

步骤如下：

1）Client将FileA按128M分块。分成两块，block1和Block2;

2）Client向nameNode发送写数据请求，如图蓝色虚线①------>。

3）NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②--------->。

    Block1: host2,host1,host6

    Block2: host7,host3,host4

4）client向DataNode发送block1；发送过程是以流式写入。

流式写入过程：

① 将64M的block1按64k的package划分;

② 然后将第一个package发送给host2;

③ host2接收完后，将第一个package发送给host1，同时client向host2发送第二个package；

④ host1接收完第一个package后，发送给host6，同时接收host2发来的第二个package。

⑤ 以此类推，如图红线实线所示，直到将block1发送完毕。

⑥ host2,host1,host6向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。

⑦ client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线

⑧ 发送完block1后，再向host7，host3，host4发送block2，如图蓝色实线所示。

⑨ 发送完block2后，host7,host3,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。

⑩ client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。

读数据流程

读数据流程：

1）client向namenode发送读请求。

2）namenode查看Metadata信息，返回fileA的block的位置。

    block1：host2，host1，host6

    block2：host7，host3，host4

3）block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取。

五、Hadoop核心之MapReduce

1、概述

Apache Foundation对MapReduce的介绍：“Hadoop MapReduce is a software framework for easily writing applications which process vast amounts of data (multi-terabyte data-sets) in-parallel on large clusters (thousands of nodes) of commodity hardware in a reliable, fault-tolerant manner.”

由此可知，Hadoop核心之MapReduce是一个软件框架，基于该框架能够容易地编写应用程序，这些应用程序能够运行在由上千个商用机器组成的大集群上，并以一种可靠的，具有容错能力的方式并行地处理上TB级别的海量数据集。这个定义里面有着这些关键词，一是软件框架，二是并行处理，三是可靠且容错，四是大规模集群，五是海量数据集。因此，对于MapReduce，可以简洁地认为，它是一个软件框架，海量数据是它的“菜”，它在大规模集群上以一种可靠且容错的方式并行地“烹饪这道菜”。

MapReduce的思想就是“分而治之”。Mapper负责“分”，即把复杂的任务分解为若干个“简单的任务”来处理。

“简单的任务”包含三层含义：一是数据或计算的规模相对原任务要大大缩小；二是就近计算原则，即任务会分配到存放着所需数据的节点上进行计算；三是这些小任务可以并行计算，彼此间几乎没有依赖关系。

Reducer负责对map阶段的结果进行汇总。至于需要多少个Reducer，用户可以根据具体问题，通过在mapred-site.xml配置文件里设置参数mapred.reduce.tasks的值，缺省值为1。

2、优缺点

优点：

1）MapReduce 易于编程

它简单的实现一些接口，就可以完成一个分布式程序，这个分布式程序可以分布到大量廉价的PC机器上运行。也就是说你写一个分布式程序，跟写一个简单的串行程序是一模一样的。就是因为这个特点使得MapReduce编程变得非常流行。

2）良好的扩展性

当你的计算资源不能得到满足的时候，你可以通过简单的增加机器来扩展它的计算能力。

3）高容错性

MapReduce设计的初衷就是使程序能够部署在廉价的PC机器上，这就要求它具有很高的容错性。比如其中一台机器挂了，它可以把上面的计算任务转移到另外一个节点上运行，不至于这个任务运行失败，而且这个过程不需要人工参与，而完全是由Hadoop内部完成的。

4）适合PB级以上海量数据的离线处理

可以实现上千台服务器集群并发工作，提供数据处理能力

缺点：

1）不擅长实时计算

MapReduce无法像mysql一样，在毫秒或者秒级内返回结果。

2）不擅长流式计算

流式计算的输入数据是动态的，而MapReduce的输入数据集是静态的，不能动态变化。这是因为MapReduce自身的设计特点决定了数据源必须是静态的。

3）不擅长DAG（有向图）计算

多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。在这种情况下，MapReduce并不是不能做，而是使用后，每个MapReduce作业的输出结果都会写入到磁盘，会造成大量的磁盘IO，导致性能非常的低下。

3、MapReduce工作机制

MapTask工作机制

详细步骤：

（1）Read阶段：MapTask通过用户编写的RecordReader，从输入InputSplit中解析出一个个key/value。

（2）Map阶段：该节点主要是将解析出的key/value交给用户编写map()函数处理，并产生一系列新的key/value。

（3）Collect收集阶段：在用户编写map()函数中，当数据处理完成后，一般会调用OutputCollector.collect()输出结果。在该函数内部，它会将生成的key/value分区（调用Partitioner），并写入一个环形内存缓冲区中。

（4）Spill阶段：即“溢写”，当环形缓冲区满后，MapReduce会将数据写到本地磁盘上，生成一个临时文件。需要注意的是，将数据写入本地磁盘之前，先要对数据进行一次本地排序，并在必要时对数据进行合并、压缩等操作。

（5）Combine阶段：当所有数据处理完成后，MapTask对所有临时文件进行一次合并，以确保最终只会生成一个数据文件。

ReduceTask工作机制

详细步骤：

（1）Copy阶段：ReduceTask从各个MapTask上远程拷贝一片数据，并针对某一片数据，如果其大小超过一定阈值，则写到磁盘上，否则直接放到内存中。

（2）Merge阶段：在远程拷贝数据的同时，ReduceTask启动了两个后台线程对内存和磁盘上的文件进行合并，以防止内存使用过多或磁盘上文件过多。

（3）Sort阶段：按照MapReduce语义，用户编写reduce()函数输入数据是按key进行聚集的一组数据。为了将key相同的数据聚在一起，Hadoop采用了基于排序的策略。由于各个MapTask已经实现对自己的处理结果进行了局部排序，因此，ReduceTask只需对所有数据进行一次归并排序即可。

（4）Reduce阶段：reduce()函数将计算结果写到HDFS上。

MapReduce作业工作原理

一个完整的mapreduce程序在分布式运行时有三类实例进程：

1）MrAppMaster：负责整个程序的过程调度及状态协调。

2）MapTask：负责map阶段的整个数据处理流程。

3）ReduceTask：负责reduce阶段的整个数据处理流程。

MapReduce整个工作过程有序地包含如下工作环节：

1）作业的提交

2）作业的初始化

3）任务的分配

4）任务的执行

5）进程和状态的更新

6）作业的完成

有关MapReduce的详细工作细节，请见:《Hadoop权威指南（第四版）》第七章 MapReduce工作机制。

4、MapReduce核心编程思想

通过一个WordCount案例的数据流完整的反映了MapReduce的核心编程思想，该案例的处理主要分为Map和Reduce阶段

具体步骤：

1）Map阶段

这个阶段主要是对数据进行过滤处理，将原本一个整体的数据进行分割，每一个Map对应一个数据块进行处理，通过对数据生成Key-Value对，按照Key进行统计排序生成新的Key-Value对，处理好各个分区的数据，用于后续Reduce阶段对数据进行处理，并发运行的MapTask是互不干扰的。

2）Reduce阶段

Reduce阶段就是讲前面Map阶段处理好的结果进行合并整合，得到最终结果的一个过程。

因为MapReduce的处理数据时只有一个Map阶段和一个Reduce阶段，所以当用户的业务非常复杂时，可以考虑使用多个MapReduce串行运行，以此达到想要的结果。

六、Hadoop之YARN

1、概述

Apache YARN（Yet Another Resource Negptiator）是Hadoop的集群资源管理系统。YARN被引入Hadoop 2，最初是为了改善MapReduce的实现，但它具有足够的通用性，同样可以支持其它的分布式计算模式。

Yarn作为一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。

2、YARN基本架构

YARN主要是由组件ResourceManager、NodeManager、ApplicationMaster以及Container等构成，如上图所示。

各组件主要作用：

1）ResourceManager

① 处理客户端请求

② 监控NodeManager

③ 启动或监控ApplicationMaster

④ 资源的分配与调度

2）NodeManager

① 管理每个节点上的资源

② 处理来自的ResourceManager的命令

③ 处理来自ApplicationMaster的命令

3）ApplicationMaster

① 负责数据的切分

② 为应用程序申请资源并分配给内部的任务

③ 任务的监控与容错

4）Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等。

3、YARN工作机制（作业提交过程）

工作机制详解：

（1）MR程序提交到客户端所在的节点。

（2）YarnRunner向ResourceManager申请一个Application。

（3）RM将该应用程序的资源路径返回给YarnRunner。

（4）该程序将运行所需资源提交到HDFS上。

（5）程序资源提交完毕后，申请运行mrAppMaster。

（6）RM将用户的请求初始化成一个Task。

（7）其中一个NodeManager领取到Task任务。

（8）该NodeManager创建容器Container，并产生MRAppmaster。

（9）Container从HDFS上拷贝资源到本地。

（10）MRAppmaster向RM 申请运行MapTask资源。

（11）RM将运行MapTask任务分配给另外两个NodeManager，另两个NodeManager分别领取任务并创建容器。

（12）MR向两个接收到任务的NodeManager发送程序启动脚本，这两个NodeManager分别启动MapTask，MapTask对数据分区排序。

（13）MrAppMaster等待所有MapTask运行完毕后，向RM申请容器，运行ReduceTask。

（14）ReduceTask向MapTask获取相应分区的数据。

（15）程序运行完毕后，MR会向RM申请注销自己。

4、资源调度器

YARN中有三种调度器可用：FIFO调度器（FIFO Scheduler），容量调度器（Capacity Scheduler）和公平调度器（Fair Scheduler）。

具体设置详见：yarn-default.xml文件

<property>    <description>The class to use as the resource scheduler.</description>    <name>yarn.resourcemanager.scheduler.class</name>    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value></property>

1）先进先出调度器（FIFO）

2）容量调度器（Capacity Scheduler）

（1）支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO调度策略。

（2）为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定。

（3）首先，计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列。

（4）其次，按照作业优先级和提交时间顺序，同时考虑用户资源量限制和内存限制对队列内任务排序。

（5）三个队列同时按照任务的先后顺序依次执行，比如，job11、job21和job31分 别排在队列最前面，是最先运行，也是同时运行。

3）公平调度器（Fair Scheduler）

支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源。

比如有三个队列: queueA、 queueB和queueC， 每个队列中的ob按照优先级分配资源，优先级越高分配的资源越多，但是每个job都会分配到资源以确保公平。在资源有限的情况下，每个job理想情况下获得的计算资源与实际获得的计算资源存在一种差距， 这个差距就叫做缺额。在同一一个队列中，job的资源缺额越大，越先获得资源优先执行。作业是按照缺额的高低来先后执行的，而且可以看到上图有多个作业同时运行。