Hadoop

Posted 2021-01-05 pipipi

官网：http://hadoop.apache.org/

The Apache? Hadoop? project develops open-source software for reliable, scalable, distributed computing.

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. Rather than rely on hardware to deliver high-availability, the library itself is designed to detect and handle failures at the application layer, so delivering a highly-available service on top of a cluster of computers, each of which may be prone to failures.

以上为官网首页介绍，大致翻译过来如下：

Apache?Hadoop?项目开发了用于可靠，可扩展的分布式计算的开源软件。

Apache Hadoop软件库是一个框架，允许使用简单的编程模型跨计算机集群分布式处理大型数据集。 它旨在从单个服务器扩展到数千台计算机，每台计算机都提供本地计算和存储。 库本身不是依靠硬件来提供高可用性，而是设计用于检测和处理应用程序层的故障，从而在计算机集群之上提供高可用性服务，每个计算机都可能容易出现故障。

1.什么是hadoop  1.x和2.x区别

hadoop1.x版本只有hdfs和mapreduce，而2.x包含hdfs，mapreduce,yarn

hdfs:分布式文件存储系统，它存储 Hadoop 集群中所有存储节点上的文件。对外部客户机而言，HDFS 就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件，等等。hdfs存储文件其实分为两个部分，一个是存储文件元数据的namenode（文件系统的命名空间，文件名称，文件目录结构，文件的属性[权限,创建时间,副本数]，文件对应哪些数据块–>数据块对应哪些datanode节点，当然namenode节点不会持久的存储这种映射关系,是通过集群在启动和运时,datanode定期发送blockReport给namenode,以此namenode在内存中来动态维护的这种映射关系）节点，另一个是存储文件实际数据的datanode（数据块和数据块校验和、与Namenode通信、每隔3秒发送一个心跳包、每十次心跳发送一次blockReport）节点。其中namenode维护文件系统元数据是根据两个文件进行的，一个是记录文件最新数据的fsimage文件，另一个则是记录修改历史的editlog文件。存储文件是以block块的方式进行存储的，一个block默认128M，也有很少的64M。这里就存在了一个容错机制他的一个副本策略的问题，默认一份数据会有三个block，当前机器存储一份（数据本地化），另外一个机架存储一份，该机架的不同机器存储一份。

 

1. 第一副本：放置在上传文件的DataNode上;如果是集群外提交，则随机挑选一台磁盘不太慢、CPU不太忙的节点上;
2. 第二副本：放置在于第一个副本不同的机架的节点上;
3. 第三副本：与第二个副本相同机架的不同节点上;
4. 如果还有更多的副本：随机放在节点中; 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　副本放置策略

 

hdfs文件的读写流程：

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　文件写流程

 

1. Client调用FileSystem.creat(filePath)方法，创建文件； 
2. FileSystem与元数据节点进行RPC通信，在文件系统的命名空间中创建一个新的文件，元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件，但是并不关联任何block。(假如不成功,就返回错误信息,所以写代码要try-catch)； 
3. FileSystem返回FSDataOutputStream对象，客户端进行写数据；在client写入数据时，FSDataOutputStream对象将它分成一个个的包，写入内部队列，称为数据队列（data queue）。数据流（Data Streamer）处理数据队列，数据流的责任是根据适合的datanode的列表要求namenode分配适合的新块来存储数据副本。这一组datanode列表形成一个管线（pipeline）————默认副本数是3，所以有3个节点在管线中； 
4. 数据流将包分流给管线中第一个的datanode，这个节点会存储包并且发送给管线中的第二个datanode。同样地，第二个datanode存储包并且传给管线中的第三个数据节点； 
5. DFSOutputStream也有一个内部的数据包队列来等待数据节点（datanode）收到确认，称为确认队列。一个包只有在被管线中所有的节点确认后才会被移除出确认队列，此时数据写入成功； 
6. 当客户端结束写入数据，则调用stream的close函数。 
7. 最后再调用FileSystem.complete()方法,告诉元数据节点写入成功。 
注意：如果数据节点（datanode）在写入的过程中失败，关闭管线（pipeline），确认队列中的任何包都会被添加回数据队列的前面，当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。失败的数据节点从管线（pipeline）中移除，另外的数据块则写入pipeline中的另外两个数据节点。元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。

总结：这一方法不仅提供了很好的稳定性（数据块存储在两个机架中）并实现很好的负载均衡，包括写入带宽（写入操作只需要遍历一个交换机）、读取性能（可以从两个机架中选择读取）和集群中块的均匀分布（客户端只在本地机架上写入一个块）。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　文件读流程

 1. 初始化FileSystem，然后客户端(client)用FileSystem的open()函数打开文件； 
2. FileSystem用RPC调用元数据节点，得到文件的数据块信息，对于每一个数据块，元数据节点返回保存数据块的数据节点的地址； 
3. FileSystem返回FSDataInputStream给客户端，用来读取数据，客户端调用stream的read()函数开始读取数据（当然读操作对于Client端是透明的）； 
4. 这些datanode根据他们与client的距离来排序（根据网络集群的拓扑）。如果该client本身就是一个datanode，便从本地datanode中读取；（体现了数据本地化） 
5. 当此数据块读取完毕时，FSDataInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点； 
6. 当客户端读取完毕数据的时候，调用FSDataInputStream的close函数，关闭输入流。 

注意：在读取的时候，如果client与datanode通信时遇到一个错误，那么它就会去尝试对这个块来说下一个最近的块。它也会记住那个故障节点的datanode，以保证不会再对之后的块进行徒劳无益的尝试。client也会确认datanode发来的数据的校验和。如果发现一个损坏的块，它就会在client试图从别的datanode中读取一个块的副本之前报告给namenode。 

这个设计的一个重点是，client直接联系datanode去检索数据，并被namenode指引到块中最好的datanode。因为数据流在此集群中是在所有datanode分散进行的。所以这种设计能使HDFS可扩展到最大的并发client数量。同时，namenode只不过提供块的位置请求（存储在内存中，十分高效），不是提供数据。否则如果客户端数量增长，namenode就会快速成为一个“瓶颈”。

 

mapreduce:

mapreduce1.x：

• 首先客户端要编写好mapreduce程序，然后提交作业也就是job，job的信息会发送到JobTracker上，并为该job分配一个ID值，接下来做检查操作，确认输入目录是否存在，如果不存在，则会抛错，如果存在继续检查输出目录是否存在，如果存在则会抛错，否则继续运行；当检查工作都做好了JobTracker就会配置Job需要的资源了。
• JobTracker: 主要负责资源监控管理和作业调度 
  （a）监控所有TaskTracker 与job的健康状况,一旦发现失败,就将相应的任务转移到其他节点； 
  （b）同时JobTracker会跟踪任务的执行进度、资源使用量等信息,并将这些信息告诉任务调度器,而调度器会在资源出现空闲时,选择合适的任务使用这些资源。
• TaskTracker：是JobTracker与Task之前的桥梁 
  （a）从JobTracker接收并执行各种命令:运行任务、提交任务、Kill任务、重新初始化任务; 
  （b）周期性地通过心跳机制,将节点健康情况和资源使用情况、各个任务的进度和状态等汇报给JobTracker。
• Task Scheduler: 任务调度器(默认FIFO,先按照作业的优先级高低,再按照到达时间的先后选择被执行的作业)

缺点：

• Hadoop1.x的MapReduce框架的主要局限： 
  （1）JobTracker 是 Map-reduce 的集中处理点，存在单点故障，可靠性差； 
  （2）JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker 失效的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限，扩展性能差。 
  （3）可预测的延迟：这是用户非常关心的。小作业应该尽可能快得被调度，而当前基于TaskTracker->JobTracker ping（heartbeat）的通信方式代价和延迟过大，比较好的方式是JobTracker->TaskTracker ping, 这样JobTracker可以主动扫描有作业运行的TaskTracker。

mapreduce2.x:

 MapReduce2组成部分

• ResourceManager（RM）包含两个主要的组件：定时调用器(Scheduler)以及应用管理器(ApplicationManager) 
  （1）调度器（Scheduler）：根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用。这里的调度器是一个“纯调度器”，因为它不再负责监控或者跟踪应用的执行状态等，此外，他也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。调度器仅根据各个应用的资源需求进行调度，这是通过抽象概念“资源容器”完成的，资源容器（Resource Container）将内存，CPU，磁盘，网络等资源封装在一起，从而限定每个任务使用的资源量。总而言之，定时调度器负责向应用程序分配资源，它不做监控以及应用程序的状态跟踪，并且它不保证会重启由于应用程序本身或硬件出错而执行失败的应用程序。 
  （2）应用管理器（ApplicationsManager，ASM）：ASM主要负责接收作业，协商获取第一个容器用于执行AM和提供重启失败AM container的服务。

• NodeManager：NM是每个节点上的框架代理，主要负责启动应用所需的容器，监控资源（内存，CPU，磁盘，网络等）的使用情况并将之汇报给调度器（Scheduler）。

• ApplicationMaster：每个应用程序的ApplicationMaster负责从Scheduler申请资源，以及跟踪这些资源的使用情况以及任务进度的监控。

• Container：是YARN中资源的抽象，它将内存、CPU、磁盘、网络等资源封装在一起。当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。

 MapReduce2提交应用程序的过程分析

1. 在作业的提交阶段，client向RM提交一个job，这时RM会进行检查，如果没有问题，会返回作业文件提交的路径和jod id；client向HDFS上传文件，准备就绪后请求RM运行作业；

2. 作业初始化阶段，用户将应用程序提交到ResourceManager后，RM为该作业分配第一个Container，并与对应的NM通信，在Container中启动作业的MRAppMaster；

3. MRAppMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态；

4. MRAppMaster采用轮询的方式式通过RPC协议向RM申请任务所需资源；

5. 一旦MRAppMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；

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

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

8. 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

Yarn作为集群的资源管理框架，由ResourceManager资源管理器和NodeManager每个节点上的框架代理组成。 
我们需要知道的点是当用户向YARN中提交一个应用程序后，怎样进行资源管理和调度完成job的。 
可以简单的分两个阶段运行该应用程序： 

a. 第一个阶段是启动ApplicationMaster； 
b. 第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完