Hadoop原理学习

一. Mapreduce

目前 1TB的数据，传输速度是100MB/s，单独去读出这份数据需要花费2个多小时的时间，这已经就相当的耗时，且只是1TB的数据
那么 设想 有 100台机器存100份数据进行同时读写，那么我们可以在2min以内就完成了读写，
但是问题又来了，作为分析来讲，从一个磁盘读出的数据常常需要和其他的99个盘独处的数据合并使用，比如，排序，统计。 Hadoop就提供了这个功能，其存储依赖于 HDFS,分析计算依赖于 MapReduce

MapReduce程序本质上是并行运行的，因此可以将大规模的数据交给足够机器的集群去计算或运行
计算过程主要是通过Map和Reduce两个阶段完成，每个阶段都有键值对作为输入和输出（类型可以自定义）

以文本类型为例： MapReduce程序是按行读取处理数据

1）Map：

Hadoop为每一个分片创建一个map任务，这个分片是输入分片（注意这里的分片不等于分块），分片的数量默认不改配置的情况下是一个块就是一个map（具体需要参看mapreduce编程模型）
参考：

https://www.cnblogs.com/qinwangchen/p/5837940.html
（1）如果想增加map个数，则设置mapred.map.tasks 为一个较大的值。
（2）如果想减小map个数，则设置mapred.min.split.size 为一个较大的值。

有多个分片就意味着处理每个分片的时间与处理整个输入的时间相比是相较小的

反之，如果分片太小（意味着mapper数量多）那么管理分片的时间和map任务创建的时间就占据了大量时间，也不是最佳选择

对于大多数的作业，一个理想的分片就是一个hdfs块的大小。

map任务的执行节点和数据输入的存储节点是同一节点，hadoop的性能达到最佳，因此这也印证了 一个理想的分片就是一个hdfs块的大小 的说法；

但是map阶段的任务的输出不是最终结果的输出，它的输出是将输出写入本地的磁盘，而不是HDFS,它会等待reduce任务处理，一旦任务完成，输出就会被删除，如果此时任务在reduce处理之前崩溃就会由Hadoop的另一个节点创建map输出，再执行

2）Reduce

reduce的任务就是 将map阶段的所有输出 进行合并，是将本地的文件通过网络传输到reduce节点进行计算，它的输出是存储于 HDFS中的

在这俩个阶段中间，还有一个最重要的过程

3）shuffle：

map side
1.在写入磁盘之前，会先写入环形缓冲区(circular memory buffer 每个map都有一个),默认100M(mapreduce.task.io.sort.mb可修改),当缓冲区内容达到80M(mapreduce.map.sort.spill.percent可修改),缓冲区内容会被溢写到磁盘，形成一个spill file文件
2.分区（环形缓冲区中）：在写入磁盘之前，会先进行分区(partition),而partition的数量是由reducer的数量决定的job.setNumReduceTasks(2);默认是用map输出的<key,value>中key的hashcode…对NumReduceTasks的个数取余，相同的分到一个区
3.排序：在每一个partition中，都会有一个sort by key
4.combiner：如果有combiner function,在sort之后会执行combiner，相当于map阶段的reducer（在run方法中设置，在main方法中调用）
5.merge：数个spill files会合并，merge成一个分过区排过序的文件
6.compress压缩the map output

reduce side
1.解压缩:如果在map side 已经压缩过,在合并排序之前要先进行解压缩
2.sort phase(merge)
3.group phase:将相同key的value分到一组，形成一个集合

示例图解：来源网络

DHFS读写流程：

HDFS写流程

客户端发请求给NameNode，我想保存一个文件A，这时候在NameNode会有一个标识，标识为A_copy（文件不可用）。
根据副本放置策略，返回三个副本的可放置位置列表，且默认为sort排好顺序的。
客户端主动去和离自己最近的DataNode连接（暂且叫DN1）,然后DN1后续的DN2进行连接，DN2在和DN3进行连接。（串联方式Pipeline）
客户端读取源文件，对该Block进行更小的切割，
第一次：传递第一个Block中的第一个小包给DN1。
第二次：传递第一个Block中的第二个小包给DN1，与此同时，DN1中的第一个小包传递给DN2。
第三次：传递第一个Block中的第三个小包给DN1，与此同时，DN1中的第二个小包传递给DN2，DN2传递第一个小包给DN3.
依次类推
（Block切割更小的小包，这里这么设计的好处是时间不重叠。如果不切，一次性传递例如64M，当传递DN1时，等待，传递DN2时，继续等待，传递DN3时，还在等，造成时间浪费。另外的一个好处时，如果增加节点，时间影响不大）

最后通过DataNode与NameNode心跳，通知是否文件彻底传递完毕，补全NameNode中元数据的位置信息。

HDFS读流程：

客户端发请求给NameNode，NameNode将这个文件的元数据找到，告知给客户端（例如文件A，被切割为5个Block,元文件会纪录Block1：DN1,DN2,DN3,Block2：DN1,DN4,DN5等等依次类推）
客户端直接向DataNode请求Block数据（遵循距离优先）
当把所有的Block下载回本地后，进行验证每个Block元信息的MD5。如果每个Block都是正确的，没有被破坏，开始进行拼接，最终文件就被还原回来了。

读写流程链接自：链接：https://www.jianshu.com/p/b59690bcf868

二. Yarn

了解yarn之前我们先了解其中的一些组件：

1. Resource Manager

ResourceManager主要有两个组件：Scheduler和ApplicationManager
1） Scheduler 它是一个资源调度器，它只负责调度Containers，不会关心应用程序监控及其运行状态等信息
2）ApplicationManager
主要负责接收job的提交请求，为应用分配第一个Container来运行ApplicationMaster，还有就是负责监控ApplicationMaster，在遇到失败时重启ApplicationMaster运行的Container

1. NodeManager

接收ResourceManager的请求，分配Container给应用的某个任务

• 和ResourceManager交换信息以确保整个集群平稳运行。ResourceManager就是通过收集每个NodeManager的报告信息来追踪整个集群健康状态的，而NodeManager负责监控自身的健康状态。
• 管理每个Container的生命周期
• 管理每个节点上的日志
• 执行Yarn上面应用的一些额外的服务，比如MapReduce的shuffle过程

1. Containers

Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。

一个Container就是一组分配的系统资源，现阶段只包含两种系统资源（之后可能会增加磁盘、网络等资源）

运行流程：

客户端程序向ResourceManager提交应用并请求一个ApplicationMaster实例

ResourceManager找到可以运行一个Container的NodeManager，并在这个Container中启动ApplicationMaster实例

ApplicationMaster向ResourceManager进行注册，注册之后客户端就可以查询ResourceManager获得自己ApplicationMaster的详细信息，以后就可以和自己的ApplicationMaster直接交互了

在平常的操作过程中，ApplicationMaster根据resource-request协议向ResourceManager发送resource-request请求

当Container被成功分配之后，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container， container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料

应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster

在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议

一但应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统

参考： https://blog.csdn.net/amandalm/article/details/81630702