1，YARN组件

1.1YARN简介

YARN表示分布式资源调度，简单地说，就是：以分布式技术完成资源的合理分配，让MapReduce能高效完成计算任务。
YARN是Hadoop核心组件之一，用于提供分布式资源调度服务。
而在Hadoop 1.x时，这个过程主要是通过MapReduce中的TaskTracker、JobTracker通信来完成。

这种架构方案主要缺点是:
1）服务器集群资源调度管理和MapReduce执行过程耦合在一起;
2）如果想在当前集群中运行其他计算任务，比如Spark、Storm，则无法统一使用集群中的资源。

在早期Hadoop时，大数据技术就只有Hadoop一家，这个缺点并不明显。
但随着大数据技术的发展，各种新的计算框架不断出现，我们不可能为每一种计算框架部署一个服务器集群，而且就算能部署新集群，数据还是在原来集群的HDFS上，这严重阻碍了大数据技术的发展。
由此，在Hadoop 2.x引来了最主要变化：将Yarn从MapReduce中分离出来，成为一个独立的资源调度框架。
可别小瞧了这个做法，单独分离出YARN带来的优势尤其明显：

（1）解耦了MapReduce框架，专注于计算；
（2）分工更加明确、精细化；[专业的事由专业的人去做]
（3）正因为有了分离YARN，后期诞生了一个个优秀的专注于计算引擎的大数据框架，比如Spark、Flink等。

Yarn是"Yet Another Resource Negotiator"的缩写，字面意思就是：另一种资源调度器。主要区别于当时已有的另一些资源调度器产品，比如Mesos等。通常情况下，YARN是与MapReduce交互配合使用，并给MapReduce合理分配资
源。
比如，MapReduce程序向YARN申请资源，YARN合理分配资源。
当成功分配好资源后，MapReduce即可完成计算任务，而空闲资源也可供其它程序使用。
Hadoop架构有三大核心组件，分别是：HDFS、MapReduce、YARN。

1.2YARN架构组成

在了解YARN架构之前，先来了解一下三个名词：
（1）资源
服务器硬件资源，如CPU、内存、硬盘、网络等
（2）资源调度
管控硬件资源，提升服务器的利用率
（3）分布式资源调度
管控整个分布式服务器集群的全部资源，并整合进行统一调度
YARN架构是由四个模块组成，分别是：
a）ResourceManager（资源管理器）：用于接收用户的计算请求任务，并负责集群
的资源分配；
b）NodeManager（节点管理器）：单个服务器的资源调度者，负责调度单个服务
器资源并提供给程序使用；
c）ApplicationMaster（任务管理器）：单个任务运行的管理者；
d）Client Application：客户端提交的应用程序。
会发现，ResourceManager与NodeManager是Yarn资源调度的核心模块。
YARN分布式资源调度，也遵循中心化模式（主从模式），有两个核心角色：

（1）主（Master）角色：ResourceManager
（2）从（Slave） 角色：NodeManager 

1.3YARN提交MR的流程

了解YARN的基本执行流程？

1）我们向Yarn提交应用程序，包括ApplicationMaster、我们的MapReduce程序，以及MapReduce程序启动命令；
2）ResourceManager进程和NodeManager进程通信，根据集群资源，为用户程序分配第一个容器，并将ApplicationMaster分发到这个容器上面，并在容器里面启ApplicationMaster；
3）ApplicationMaster启动后，立即向ResourceManager进程注册，并为自己的应用程序申请容器资源；
4）ApplicationMaster申请到需要的容器后，立即和相应的NodeManager进程通信，将用户MapReduce程序分发到NodeManager进程所在服务器，并在容器中运行，运行的就是Map或者Reduce任务；
5）Map或者Reduce任务在运行时，和ApplicationMaster通信，汇报自己的运行状态。
如果运行结束，ApplicationMaster向ResourceManager进程注销并释放所有的容器资源。到这里，MapReduce程序已执行完成!

1.4 YARN的三大调度器

1，先进先出调度器
FIFO Scheduler表示先进先出调度器。
先进先出调度器指的是：把应用按提交的顺序排成一个队列，在进行资源分配时，先给队列中【队头】的应用进行分配资源，待【队头】的应用需求满足后，再给下一个
应用分配，以此类推。

（1）优点
能够保证每一个任务都能拿到充足的资源, 对于大任务的运行非常有好处。
（2）缺点
如果先有大任务后有小任务, 会导致后续小任务无资源可用, 长期处于等待状态。

一般地，在普通数据量提交计算时，几乎不会涉及调度器的设定，但海量数据处理时，要多考虑下调度器的设定。
2，公平调度器
Fair Scheduler表示公平调度器。
Fair Scheduler不需要保留集群的资源，因为它会动态在所有正在运行的作业之间平衡资源。
Fair Scheduler 当一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当后面有小任务提交后，公平调度器会分配一半资源给这个小任务，让这两个
任务公平的共享集群资源。通常情况下，各分享50%资源！
公平调度器执行效果：
（1）优点
能够保证每个任务都有资源可用, 不会有大量的任务等待在资源分配中。
（2）缺点
如果大任务非常的多, 就会导致每个任务获取资源都非常的有限, 也会导致执行时间会拉长。
相比较而言，公平调度器相对来说，分配资源时较为公平公正。
3，容量调度器
Capacity Scheduler表示容量调度器。
Capacity Scheduler为每个组织分配专门的队列和一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。
在每个队列内部，资源的调度是采用的是先进先出(FIFO)策略。

（1）优点
可以保证多个任务都可以使用一定的资源, 提升资源的利用率。
（2）缺点
如果遇到非常大的任务, 此任务不管运行在哪个队列中, 都无法使用到集群中所有的资源, 导致大任务执行效率比较低, 当任务比较繁忙时, 依然会出现等待状态。

（1）调度器的使用，是通过/export/server/hadoop-3.3.0/etc/hadoop/yarnsite.xml配置文件中的。

yarn.resourcemanager.scheduler.class参数进行配置的，默认采用
Capacity Scheduler调度器。

（1）在这个配置中，在root队列下面定义了两个子队列prod和dev，分别占40%和60%的容量；
（2）prod由于没有设置maximum-capacity属性，它有可能会占用集群全部资源；
（3）dev的maximum-capacity属性被设置成了75%，所以即使prod队列完全空闲
dev也不会占用全部集群资源，也就是说，prod队列仍有25%的可用资源用来应急。

2， ZooKeeper概述

2.1ZooKeeper简介

Zookeeper（动物管理员）是一个分布式协调服务的开源框架，简要地说，就是管理大数据生态圈的各类"动物"。
ZooKeeper本质上是一个分布式的小文件存储系统。
采用树形层次结构，ZooKeeper树中的每个节点被称为Znode，且树中的每个节点可以拥有子节点。
Zookeeper具有如下特性：

1）全局数据一致：集群中每个服务器保存一份相同的数据副本，Client客户端无论连接哪个服务器，展示的数据都是一致的；[最重要]
2）可靠性：如果消息被其中一台服务器接收，那么将被所有的服务器接受；
3）顺序性：包括全局有序和偏序两种。
全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；
偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
4）数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；
5）实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

2.2集群角色

Zookeeper表示分布式协调服务。
使用Zookeeper时至少需要两个Hadoop服务，一主一备，主服务对外提供业务功能，备用等待主服务不可用时，启用备用服务器对外提供业务功能。
在Zookeeper中，可供服务的角色有三类，分别是：

（1）leader：管理者，负责管理follower，处理所有的事务请求(数据的保存，修改，删除)；
（2）follower：追随者，负责选举(选举leader)和数据的同步及获取；
（3）observer：观察者，负责数据的同步及获取(需要在配置文件中指定才能生效)。

（1）leader管理者

leader管理者是Zookeeper集群工作的核心。负责管理follower，处理所有的事务请求（包括数据的保存，修改，删除）。

（2）follower追随者

follower追随者负责处理客户端非事务（读操作）请求，并转发事务请求给leader管理者。
同时，follower还会参与集群Leader选举投票。

（3）observer观察者
而针对访问量比较大的Zookeeper集群，还可新增observer观察者角色

负责数据的同步及获取（需要在配置文件中指定才能生效）。

Zookeeper的集群常见角色有三个，分别是：leader、follower、observer。

2.3 ZooKeeper服务

1，配置环境变量
（1）未配置环境变量 按Shell脚本方式完成执行。此时，需要依次执行命令：
leader管理者是Zookeeper集群工作的核心。负责管理follower，处理所有的事务
请求（包括数据的保存，修改，删除）。
follower追随者负责处理客户端非事务（读操作）请求，并转发事务请求给leader管理者。
同时，follower还会参与集群Leader选举投票。
负责数据的同步及获取（需要在配置文件中指定才能生效）。
（1）未配置环境变量
按Shell脚本方式完成执行
（2）先配置环境变量，再直接执行
cd /export/server/zookeeper/bin 1./zkServer.sh status 1
（2）先配置环境变量，再直接执行
此时，需要来配置zookeeper环境变量，注意：三台虚拟机都要进行配置。

echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >>
/etc/profile
echo 'export PATH=$PATH:$ZOOKEEPER_HOME/bin' >> /etc/profile
source /etc/profile

此时，可以在虚拟机的任意位置执行命令：

zkServer.sh status

我们会发现，配置环境变量的好处是能让命令在不同路径下，都能成功执行。

2.4启动ZooKeeper

对于ZooKeeper的服务，需要在虚拟机中启动后才能使用。启动ZooKeeper命令：

zkServer.sh start

对于ZooKeeper的服务，还可以查看状态与关闭服务，命令：

# 查看状态
zkServer.sh status
# 如果想关闭可以使用stop
zkServer.sh stop

一般地，当仅在一台服务器上启动了ZooKeeper服务，可能无法查看到它所对应的服务角色。
此时，可以多开启一台虚拟机的ZooKeeper服务，再查看角色信息。
当要启动Zookeeper服务时，可以执行zkServer.sh start；命令
在查看服务时，记住三个关键字：start启动、status状态、stop停止。

3，使用ZooKeeper

3.1，客户端连接

当已经成功开启了Zookeeper服务后，则可以使用客户端来连接服务并执行相应操作了。
连接Zookeeper服务时，有两种方式：

# 方式1:连接其他节点
[root@node1 ~]# zkCli.sh -server IP地址
# 方式2:直接连接本地
[root@node1 ~]# zkCli.sh

采用zkCli.sh直接连接本地的zkServer，并完成常见命令的使用。
（1）当要远程连接不同服务器的Zookeeper服务时，使用zkCli.sh -server IP地址命令；
（2）注意，当想要快速查看zookeeper客户端的操作命令，可以直接执行help命令。

3.2数据模型

ZooKeeper的数据模型称为Znode，一般有两种体现：
（1）目录：可以存储数据，也可以当做目录使用
（2）文件：可以存储数据，也可以当做目录使用
ZooKeeper的数据模型也有一些不同之处：

（1）Znode兼具文件和目录两种特点：Znode没有文件和目录之分，Znode既能像文件一样存储数据，也能像目录作为路径标识的一部分；
（2）Znode具有原子性操作: 读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据；
（3）Znode存储数据大小有限制: 每个Znode的数据大小至多1M，但是在常规使用中，应该远小于此值；
（4）Znode通过路径引用: 路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。
并且，会发现：默认有/zookeeper节点用以保存关键的管理信息。

在zookeeper中的节点是目录或文件都能存储数据，这个描
述正确
（2）通常地，zookeeper数据模型分为目录、文件，但本质上区别不大。

3.3节点类型

create [-e] 节点路径名 数据值
创建数据节点。
当添加-e后，表示临时节点；当创建多层节点时，要保证
已创建最后子节点前的所有节点。
Znode节点类型有两类，分别为：

（1）永久节点
该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作时，他们才能被删除;
注意: 永久节点可以拥有子节点。
（2）临时节点
该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，也可手动删除；
注意: 临时节点不允许拥有子节点。

当然了，可以通过创建节点是否添加-e选项或ls2能查看到节点类型：

# 添加了-e表示临时节点，否则为永久节点
create [-e] 节点路径名 数据值
# 查看ephemeralOwner字段为0x0时，为永久节点; 结果值较长的为临时节点
ls2 节点路径名

cZxid：Znode创建的事务id。
ctime：Znode创建时的时间戳。
mZxid：Znode被修改的事务id，即每次对当前znode的修改都会更新mZxid。
mtime：Znode最新一次更新发生时的时间戳。
pZxid：Znode的子节点列表变更的事务ID，添加子节点或删除子节点就会影响子节点列表。
cversion：子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号。
dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增
加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
aclVersion：权限变化列表版本 access control list Version。
ephemeralOwner：字面翻译临时节点拥有者，持久节点值为0x0，非持久节点不为0（会话ID）。
dataLength：Znode数据长度。
numChildren：当前Znode子节点数量(不包括子子节点）。

当在使用create关键字创建节点时，添加-e表示创建临时节点
（2）当在查看节点详细信息时，可以通ephemeralOwner字段值来区分临时或永久节点

3.4Watch监听机制

通常地，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态发生变化时，会通知所有订
阅者，使他们能够做出相应的处理。
ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
watch监听机制过程有：
（1）客户端向服务端注册Watcher；
（2）服务端事件发生触发Watcher；
（3）客户端回调Watcher得到触发事件情况
仅需到某客户端中设定监听机制格式为
get /节点名 watch
Watch监听机制有如下特点:

a）先注册再触发: Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，并通知给客户端;
b）一次性触发: 事件发生触发监听后，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发；
c）异步发送: watcher的通知事件从服务端发送到客户端是异步的；（同时进行）
d）通知内容: 通知状态（keeperState），事件类型（EventType）和节点路径（path）。

3.5选举机制

（1）数据发布/订阅
数据发布/订阅系统，就是发布者将数据发布到ZooKeeper的一个节点上，提供订阅者进行数据订阅，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。监听机制就是[数据发布/订阅]快速实现。
（2）提供集群选举
在分布式环境下，不管是主从架构集群，还是主备架构集群，要求在服务时，有且仅有一个正常的对外提供服务的主服务器，我们称之为Master。
当master出现故障之后，需要重新选举出新的Master，用以保证服务的连续可用性。
而Zookeeper则可以提供这样的功能服务，但一般会涉及到：znode唯一性、临时节点短暂性、监听机制等知识使用。
通常情况下，选举机制要求：过半原则。
所以，我们会发现搭建集群一般都是奇数，即只要某个node节点票数过半立刻成为leader。
当然了，选举机制下，也有两个特殊情况：
（1）集群第一次启动
启动follower每次投票后，他们会相互同步投票情况，如果票数相同，谁的myid大，谁就当选leader。
一旦确定了leader，后面来的默认就是follower，即使它的myid大，leader也不会改变（除非leader宕机了）。

# 进入数据目录
cd /export/server/zookeeper/zkdatas
# 查看myid值大小
cat myid

（2）leader宕机后，再次启动
每一个leader当老大时，都会产生新纪元epoch，且每次操作完节点数据都会更新事务id(高32位_低32位) ，而当leader宕机后，剩下的follower就会综合考虑几个因素
选出最新的leader。先比较最后一次更新数据事务id（高32位_低32位），谁的事务id最大，谁就当选leader。
如果更新数据的事务id都相同的情况下，就需要再次考虑myid，谁的myid大，谁就当选leader。

（1）通常情况下，不管选举时属于哪种情况，都有考虑myid值的大小