Hadoop的MapReduce

MapReduce

MapReduce的运行模式

MapReduce 的3种运行模式

(1)本地运行模式

 

1.1 src下不能有hadoop的配置文件

 

1.2如果处理的数据和输出的结果在hdfs上

需要指定active的namenode

 

 

 

为什么需要指定fs.defaultFs的值？

因为:再导入的jar包中hadoop-hdfs-2.2.5.jar中的hdfs-default.xml文件中有默认是从本地文件系统中寻找指定的文件

 

默认值:

 

 

如果程序中不指定fs.defaults,运行程序就会报错

 

1.3 在本地运行便于业务逻辑的debug

 

  1.3.1  需要在window系统中解压一份在集群中安装的hadoop的jar包

 1.3.2 同时配置window系统的环境变量

注意:必须写HADOOP_HOME不能直接在Path中配置

   E:\soft\hadoop\hadoop-2.5.1\bin

   

1.3.3 拷贝winutils.exe到hadoop的bin目录下:

 

1.4修改hadoop  NativeIo类中access方法的源码

 

暴力修改源码：

 

复制整个类，加入到本地代码中：

 

 

集群模式下都需要在src目录下导入集群的配置文件core-site.xml hdfs-site.xml yarn.site.xml mapred-site.xml

(2)集群运行模式一

将mapreduce提交到yarn集群的resourcemanger，分发给很多节点并发执行

  

2.1将MR程序 打成jar包，传到集群的任意一个节点上

 

 

 

2.2通过： hadoop jar jar路径  类的全限定名 启动

 

执行成功结果

 

(3)集群运行模式二

在本地调用，执行过程在集群上执行（真正的企业环境）

3.1指定本地jar包的路径

 

3.2 在本地执行运行

 

MapReduce 中的Combiner函数的理解

1.combiner是mapReduce程序中Mapper和Reducer之外的一种组件。

2.Combiner组件的父类是Reducer

3.Combiner和Reducer的区别在于运行的位置：

（1）Combiner是在每一个Maptask所在的节点上运行

（2）Reducer是接受全局所有的Maptask的输出结果

4.意义：

 

5.Combiner使用的前提是不能影响业务逻辑，同时Combiner的输出的KV，要符合Reducer的输入的KV类型的要求

为什么使用Combiner要慎重?

 

因为combiner在mapreducer的过程中可能调用也可能不调用，可能调用一次也可能是调用多次，无法确定。

6、具体的实现步骤：

  （1）自定义一个combiner类继承Reducer,重写reduce方法

 

   （2）在job中设置job.setCombinerClass(mycombiner.class);

 

7.Combiner加入后产生的效果：

MapReduce 底层原理详解

1、结构：

 一个完整的MapReduce在分布式上运行时有三类进程：

(1) MRAppMaster:负责整个程序的过程调度和状态协调

(2) mapTask :负责map阶段的整个数据处理流程

(3) ReduceTask:负责reduce阶段的数据处理流程

2、流程详解图

（1）切片详解图

 

切片过程分析:

 

  1.获取设置的文件的大小：通过fs.sizeOf(test.txt);

  2.计算切片大小

   computeSplitSize(Math.max(minSize,Math.max(maxSize,blocksize)))=blocksize；

  3.形成切片规划文件（假设test.txt文件的大小默认是300M）：

   第一个切片:test.txt---0-128M   第二个切片:test.txt -----128-256M   第三个   切片: test.txt  256M-300M

将上述信息写入到切片规划文件中:

  4.yarn 会启动MrAppMaster----->读取切片规划文件,启动相应的maptask进程,

Maptask进程会去fs.open(test.txt)获取到文件的流,读取指定的位置的字节数。

  5.以上split切片完成

 

（2）MAPReduce

 

1.maptask读取文件通过调用TextInputFormat中的RecordReader---->read()，返回Key,Value。

2.调用Mapper-----中的-->map(key, value,context)方法处理输入的数据 ----->context.write()方法写出------>outputCollector收集器------>写入环形缓冲区，默认100M，阈值80%，达到阈值开始清理工作，经过清理工作后写入磁盘

  当清理工作没有处理完，此时内存缓冲区已经写满，接下来outputCollector收集器还会继续写入环形缓冲区吗？

  在溢写的过程中，map输出继续写到缓冲区，如果此时缓冲区被填满map会被阻塞直到写磁盘的过程完成

3.清理工作主要:  分区  排序   (compiner)

  （1）分区:默认调用的HashPatitioner中的getPartition（K key，V value，

                                          Int numReduceTasks ）

 

 

如果自定义分区：需要继承Partitioner类重写getPartition方法

 

Key值经过getPartition方法后，返回结果相同的分到相同的区中。

在同一区中的key，value  再调用compareTo按照key排序。

 

（2）排序:默认是按照key的hash值递增排序

 

自定义排序规则：只需要在map 方法中context.write(Mykey,value);

Mykey对应的自定义类实现 WritableComparable<MyKey>  重写compareTo（）方法在compareTo()自定义排序规则:

 

经过sort排序后，同一个分区中的数据是按照key已经排好序。

在溢出的过程中可能产生多个溢出的小文件，如果没有调用combiner，接下来就是将多个溢出的文件合并

 

（3）合并:一个maptask只产生一个文件，多个溢出的小文件会经过merge合并为一个大文件；合并的过程中会调用到归并排序

 

如果调用了combiner,那么经过combiner后相同key的value就会进行累加(以wordcount为例)，然后通用可能有多次溢出产生多个溢出文件，在经过合并。这样有效的减少了maptask往reduceTack的文件传输量，提高效率，但是注意业务场景是否符合使用combinner.

以上maptask结束

reduceTask开始

(1)下载 ：下载maptask溢出的文件中的指定的分区的片段到相应的reduce的本地磁盘目录。

（2）归并排序:reducetask会取到同一个分区的来自不同maptask的结果文件，reducetask会将这些文件再进行合并（归并排序）

（3）分组:GroupComparaor----->相同的key一组------->结果

<key,list<IntWritable>>  如<success,[1,1,1,1,1,1]>

可以自定义分组规则:同年同月的分为一组中

 

（4）调用reduce方法:实现相应的业务逻辑一下是wordcount

 

(5)输出：默认调用TextOutputFormat 中的RecordWrite的Write(k,v)方法

 

 

 

MapReduce的数据压缩

1.概述

 这是mapReduce的一种优化策略:通过压缩编码对mapper或者reducer的输出进行压缩，减少磁盘的IO，提高了MapReduce的运行效率同时也增加了cpu的压力。

   （1）MapReduce支持将map的输出结果或reduce的输出结果进行压缩,以减少网络IO或最终输出数据的体积。

   (2)基本原则

     运算密集型,减少使用

     IO密集型,增加使用

 

MapReduce代码分析

单词统计

天气

好友推荐

 

 

Hive

Hive简介

Yarn

Yarn的基本组成结构

 

 

 

1.yarn总体上仍然是Master/Slave结构。在整个资源框架中，ResourceManager为Master,NodeManager为Slave.

2.ResourceManager负责对各个NodeManager上的资源进行统一的管理和调度，

NodeManage是每个节点资源和任务管理器.

3.当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster,它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。

4.ApplicationMaster被分布到不同的节点上，因此他们之间是互不影响的。

5.Yarn 主要由ResourceManager、NodeManager、ApplicationMaster（图中给出了MapReduce和MPI两种计算框架的ApplicationMaster ,分别是MR AppMstr和MPI AppMstr）和Container等几个组件构成

6.详细介绍各个

（1）ResourceManager（RM）

RM 是一个全局的资源管理器，负责整个系统的资源管理和分配。他主要由两个组件构成：调度器(Scheduler)和应用程序管理器(ApplicationsManager,ASM)。

调度器-----Scheduler

调度器根据容量、队列等限制条件(如每个队列分配一定的资源，最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。

调度器仅根据各个应用程序的资源需求进行资源分配而资源分配单位用一个抽象概念”资源容器”（Resource  Container  简称Container） 表示,Container是一个动态的资源分配单位，它将内存，CPU，磁盘，网络等资源封装在一起,从而限定每个任务使用的资源量。

此外，调度器是一个可插拔的组件,用户可以根据自己的需求设计新的调度器，Yarn提供了多种直接可用的调度器 。（比如Fair Scheduler 和 Capacity Scheduler等）

注意:该调度器是一个纯调度器,不从事任何与具体应用程序相关的工作,比如不负责监控或者跟踪应用的执行状态等,也不负责重新启动因应用执行失败或者硬件故障而产生的任务失败,这些均交给应用程序相关的ApplicationMaster完成.

 应用程序管理器-----Applications Manager(ASM）

应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与协调器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它

（2）ApplicatonMaster (AM)

 用户提交的每一个应用程序均包含1个AM，主要功能包括:

 

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

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

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

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

（3）NodeManager（NM）

 NodeManager是每个节点上的资源和任务管理器；

 A、它会定时地向ResourceManager汇报本节点上的资源使用情况和各个  Container的运行状态;

  B、它接受处理来自ApplicationMaster的启动/停止等各种请求

(4)Container

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

当ApplicationMaster向ResourceManager申请资源时，ResourceManager为ApplicationMaster返回的资源便是用Container表示的。

Yarn会为每个任务分配一个Container,且该任务只能使用该Container中扫描的资源

Container不同于MRv1中的slot,它是一个动态资源划分单位，是根据应用程序的需求动态生成的。

Yarn仅支持CPU和内存两种资源(截止本书完成时)，其实用了轻量级资源隔离机制Cgroups进行资源隔离

 

 

 

Yarn工作流程

当用户向Yarn中提交一个应用程序后,yarn将分两个阶段运行该应用程序:

(1)第一阶段是启动ApplicationMaster;

(2)第二阶段是由ApplicationMaster创建应用程序,为它申请资源，并监控它的整个运行过程，直到运行完成。

 

Yarn工作流程分为以下几个步骤:

 

1、 用户向Yarn中提交应用程序，其中包括ApplicationMaster程序，启动ApplicationMaster的命令、用户程序等

2、 ResouceManager为该应用程序分配第一个Container,并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster

3、 ApplicatonMaster首先向ResourceManager注册,这样用户可以直接通过ResoucerManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束。

4、 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

5、 一旦ApplicationMaster申请到资源后，便与对应NodeManager通信，要求它启动任务。

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

7、 各个任务通过某个RPC协议向ApplicationMaster汇报自己的进度和状态，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。

     在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前状态。

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

深入理解yarn中的Container概念

在yarn中，ResourceManager中包含一个插拔式的组件:资源调度器,他主要负责资源的管理和调度，是Yarn中最核心的组件之一。

 当向资源调度器申请资源时，需要向它发送一个ResourceRequest列表,其中，每个ResourceRequest描述了一个资源单元的详细需求,而资源调度器则为之返回分配到的资源描述Container。每个ReourceRequest可以看做一个可序列化Java对象,包含下面的字段信息：

 

 

从上面定义可以看出,可以为应用程序申请任意大小的资源量（CPU和内存），且默认情况下资源是本地性松弛的，即申请优先级为10，资源名称为“node11”,资源量为<2GB,1CPU>的5份资源时，如果节点node11上没有满足要求的资源，则优先找node11同机架上其他节点上满足要求的资源，如果仍找不到，则找其他机架上的资源，而如果你一定要node11上的节点，则将relax_locality置为false。

 

 

（1）发出资源请求后,资源调度器并不会立马为它返回满足要求的资源

（2）需要应用程序的ApplicationMaster不断与ResourceManager通信,探测分配到的资源，并拉取过来使用。

（3）一旦分配到资源后,ApplicationMaster可从资源调度器那获取以Container表示的资源,Container可看做一个可序列化Java对象，包含的字段信息如下:

 

(4)一般而言,每个Container可用于运行一个任务。ApplicationMaster收到一个或多个Container后,再次将该Container进一步分配给内部的某个任务,一旦确定该任务后，ApplicationMaster需将该任务运行环境(包含运行命令、环境变量、依赖的外部文件等)连同Container中的资源信息封装到ContainerLaunchContext对象中，进而与对应的NodeManager通信,以启动该任务。ContainerLaunchContext包含的字段信息如下:

 

（5）每个ContainerLaunchContext和对应的Container信息(被封装到了Container Token中)将再次被封装到StartContainerRequest中,也就是说,ApplicationMaster最终发送给NodeManager的是StartContainerRequest，每个StartContainerRequest对应一个Container和任务。

 

总结Container的一些基本概念和工作流程:

(1)Container是Yarn中资源的抽象，它封装了某个节点上一定量的资源(CPU和内存两类资源)。它跟Linux Container 没有任何关系,仅仅是Yarn提出的一个概念(从实际上看，可以看做一个可序列化/反序列化的java类)

(2)Container由ApplicationMaster向ResourceManager申请的,由ResourceManager中的资源调度器异步分配给ApplicationMaster.

(3)Container的运行是由ApplicationMaster向资源所在的NodeManager发起的,

Container运行时需提供内部执行的任务命令（可以是任何进程启动命令均可）以及该命令执行所需的环境变量和外部资源（比如字典文件、可执行文件、jar包等）

 

Container的分类:

一个应用程序所需的Container分为两类:

(1)运行ApplicationMaster的Container：是由ResourceManager向内部的资源调度器申请和启动的，用户提交应用程序时,可指定唯一的ApplicationMaster所需的资源.

(2)运行各类任务的Container：是由ApplicationMaster向ResourceManager申请的，并由ApplicationMaster与NodeManager通信以启动。

Hbase

Hbase是什么

Hbase是一种构建在HDFS上的分布式、面向列的存储系统。

 

Hbase的使用场景

(1)大数据量存储,大数据量高并发操作

(2)需要实时读写、随机访问超大规模的数据集

 Hbase逻辑数据模型

 

逻辑模型中的空白的cell，在物理上是不存储的

 

RowKey

(1)Rowkey是用来检索记录的主键.

(2)决定一行数据

(3)只能存储64K的字节数据（实际应用中长度一般为10~100bytes）

（4）在Hbase内部,Row Key保存为字节数组

(5)在存储时，数据按照Rowkey的字典序排序存储。

字典序对int排序的结果是1,10,100,11,12,....，9,91,92,.....99怎样保证整形的自然序?

RowKey用0进行左填充，保证位数相同（3位）；排序后的结果:001,002,003,...010,011,...,020....,099,100

时间戳

（1）HBase中的每个Cell都保存着同一份数据的多个版本。

（2）时间戳表示版本。版本通过时间戳来索引.

 （3）时间戳是64位整形.

(4)时间戳可以在hbase写入数据时自动赋值。此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由用户显示赋值。

如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。

 

 

Zookeeper

HDFS

Kafak

Redies