知识点整理

最新推荐文章于 2023-05-03 16:22:11 发布

月暖.如梵音

最新推荐文章于 2023-05-03 16:22:11 发布

阅读量729

点赞数

分类专栏： Zookeeper 文章标签：大数据

本文链接：https://blog.csdn.net/qq_42160456/article/details/114805520

版权

Zookeeper 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1、zookeeper中有那些类型的节点, 各个类型有什么特点

zookeeper的节点（Znode）类型一共有两大类，分别是：临时节点和永久节点
临时节点：
	1、节点的生命周期依赖于创建它的会话，一旦会话结束，节点将被自动删除，也可以进行手动删除
	2、临时节点不允许拥有子节点
永久节点：
	1、节点的生命周期不依赖于创建它的会话，只有在客户端执行删除操作的时候，才会删除节点
Znode的特性：
	序列化特性，如果创建节点进行制定，Znode名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，
	这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10位数字，没有数值的数位用0补充，例如“0000000001”)。

2、zookeeper中如何进行选举

zookeeper默认的选举算法是FastLeaderElection，采用投票数大于半数则胜出的逻辑。
服务器ID：
	比如有三台服务器，编号分别是1,2,3。
	编号越大在选择算法中的权重越大。
选举状态
	LOOKING，竞选状态。
	FOLLOWING，随从状态，同步leader状态，参与投票。
	OBSERVING，观察状态,同步leader状态，不参与投票。
	LEADING，领导者状态。
数据ID
	服务器中存放的最新数据version。
	值越大说明数据越新，在选举算法中数据越新权重越大。
逻辑时钟
	也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器
返回的投票信息中的数值相比，根据不同的值做出不同的判断。
	全新集群选举
假设目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
1、服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
2、服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，
所以两个服务器的状态依然是LOOKING。
3、 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，
所以服务器3成为leader，服务器1,2成为follower。
4、服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4
只能成为follower。
5、服务器5启动，后面的逻辑同服务器4成为follower。
 非全新集群选举
	对于运行正常的zookeeper集群，中途有机器down掉，需要重新选举时，选举过程就需要加入数据ID、服务器ID和逻辑时钟。
	数据ID：数据新的version就大，数据每次更新都会更新version。
	服务器ID：就是我们配置的myid中的值，每个机器一个。
	逻辑时钟：这个值从0开始递增,每次选举对应一个值。 如果在同一次选举中,这个值是一致的。
	这样选举的标准就变成：
		1、逻辑时钟小的选举结果被忽略，重新投票；
		2、统一逻辑时钟后，数据id大的胜出；
		3、数据id相同的情况下，服务器id大的胜出；
根据这个规则选出leader。

3、zookeeper中watch机制

zookeeper的watch机制，主要是为了辅助实现分布式数据发布/订阅功能，一个典型的发布/订阅功能是一种一对多的关系，能够让多个订阅者
监听一个主题的变化。当监听到变化之后，随之做出相应的改变。
	具体的实现方式是，监听主题的客户端向服务器注册一个watch监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发
	送一个事件通知来实现分布式的通知功能。
	触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。
	总的来说可以概括Watcher为以下三个过程：客户端向服务端注册Watcher、服务端事件发生触发Watcher、客户端回调Watcher得到触
	发事件情况
	watch机制特点：
		一次性触发  
			事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不
			会再次触发。
		事件封装
			ZooKeeper使用WatchedEvent对象来封装服务端事件并传递。
		WatchedEvent包含了每一个事件的三个基本属性：
			通知状态（keeperState），事件类型（EventType）和节点路径（path）
		event异步发送  
			watcher的通知事件从服务端发送到客户端是异步的。
		先注册再触发
			Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

通知状态和事件类型
4、hadoop的三大发行版本, 各有什么优缺点

1、免费开源版本Apache：
	优点：拥有全世界的开源贡献者，代码更新迭代版本比较快，
	缺点：版本的升级，版本的维护，版本的兼容性，版本的补丁都可能考虑不太周到
2、免费开源版本HortonWorks：
	hortonworks主要是雅虎主导Hadoop开发的副总裁，带领二十几个核心成员成立Hortonworks，核心产品软件HDP（ambari），
	HDF免费开源，并且提供一整套的web管理界面，供我们可以通过web界面管理我们的集群状态，web管理界面软件
	HDF网址（http://ambari.apache.org/），2018年，大数据领域的两大巨头公司Cloudera和Hortonworks宣布平等合并，
	Cloudera以股票方式收购Hortonworks，Cloudera股东最终获得合并公司60%的股份
3、软件收费版本Cloudera: CDH  
	优点：loudera主要是美国一家大数据公司在apache开源hadoop的版本上，通过自己公司内部的各种补丁，实现版本之间的稳定运行，
	大数据生态圈的各个版本的软件都提供了对应的版本，解决了版本的升级困难，版本兼容性等各种问题
	缺点：更新不及时、收费

5、hadoop的架构, 各个架构主要有那些节点构成, 以及每个节点有什么作用

HADOOP集群具体来说包含两个集群：HDFS集群和YARN集群，两者逻辑上分离，但物理上常在一起
	文件系统核心模块：
		NameNode：集群当中的主节点，管理元数据(文件的大小，文件的位置，文件的权限)，主要用于管理集群当中的各种数据
		SecondaryNameNode：主要能用于hadoop当中元数据信息的辅助管理
		DataNode：集群当中的从节点，主要用于存储集群当中的各种数据
	数据计算核心模块：
		JobTracker：接收用户的计算请求任务，并分配任务给从节点
		TaskTracker：负责执行主节点JobTracker分配的任务
		ResourceManager：接收用户的计算请求任务，并负责集群的资源分配
		NodeManager：负责执行主节点ResourceManager分配的任务

6、hdfs的三个机制: 心跳机制负载均衡机制副本机制

心跳机制 ：HDFS的心跳机制主要用于高可用集群中
高可用集群机制：
	1、NameNode之间通过journalNode集群同步Edits文件的方式同步元数据
	2、zookeeper通过ZKFC(ZKFailoverController、HealthMonitor 和 ActiveStandbyElector)来协同实现主备切换
	3、主备切换流程：
		1. HealthMonitor 初始化完成之后会启动内部的线程来定时调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法，对 NameNode 的健康状态进行检测。
		2. HealthMonitor 如果检测到 NameNode 的健康状态发生变化，会回调 ZKFailoverController 注册的相应方法进行处理。
		3. 如果 ZKFailoverController 判断需要进行主备切换，会首先使用 ActiveStandbyElector 来进行自动的主备选举。
		4. ActiveStandbyElector 与 Zookeeper 进行交互完成自动的主备选举。
		5. ActiveStandbyElector 在主备选举完成后，会回调 ZKFailoverController 的相应方法来通知当前的 NameNode 成为主 NameNode 或备 NameNode。
		6. ZKFailoverController 调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法将 NameNode 转换为 Active 状态或 Standby 状态。
总结：HealthMonitor 监控NameNode 的健康状况时，通过心跳机制来实现

在这里插入图片描述高可用集群运行图

负载均衡
负载均衡描述、副本摆放策略（数据负载均衡原理）
副本机制

HDFS为保证数据安全，会对每一份数据切片后并放置多份（副本数量和切片大小可自行调节）
副本摆放策略：
	第一副本：放置在上传文件的DataNode上；如果是集群外提交，则随机挑选一台磁盘不太慢、CPU不太忙的节点上；
	第二副本：放置在于第一个副本不同的机架的节点上；
	第三副本：与第二个副本相同机架的不同节点上；
	如果还有更多的副本：随机放在节点中；
注意：
	HDFS中存储的文件的副本数由上传文件时设置的副本数决定。无论以后怎么更改系统副本系数，这个文件的副本数都不会改变；
    在上传文件时优先使用启动命令中指定的副本数，如果启动命令中没有指定则使用hdfs-site.xml中dfs.replication设置的默认值；

7、hdfs的读写数据的流程
HDFS写数据流程

详细步骤解析：
1、client发起文件上传请求，通过RPC与NameNode建立通讯，NameNode检查目标文件是否已存在，父目录是否存在，返回是否可以上传；
2、client请求第一个 block该传输到哪些DataNode服务器上；
3、NameNode根据配置文件中指定的备份数量及副本放置策略进行文件分配，返回可用的DataNode的地址，如：A，B，C；
4、client请求3台DataNode中的一台A上传数据（本质上是一个RPC调用，建立pipeline），A收到请求会继续调用B，然后B调用C，
将整个pipeline建立完成，后逐级返回client；
5、client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（默认64K），A收到一个packet就会
传给B，B传给C；A每传一个packet会放入一个应答队列等待应答。
6、数据被分割成一个个packet数据包在pipeline上依次传输，在pipeline反方向上，逐个发送ack（命令正确应答），最终由
pipeline中第一个DataNode节点A将pipeline ack发送给client;
7、当一个block传输完成之后，client再次请求NameNode上传第二个block到服务器。

在这里插入图片描述文件上传流程图

HDFS读数据流程

详细步骤解析：
1、 Client向NameNode发起RPC请求，来确定请求文件block所在的位置；
2、 NameNode会视情况返回文件的部分或者全部block列表，对于每个block，NameNode都会返回含有该block副本的DataNode地址；
3、 这些返回的DN地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离
Client近的排靠前；心跳机制中超时汇报的DN状态为STALE，这样的排靠后；
4、 Client选取排序靠前的DataNode来读取block，如果客户端本身就是DataNode,那么将从本地直接获取数据；底层上本质是建立
Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，直到这个块上的数据读取完毕；
5、 当读完列表的block后，若文件读取还没有结束，客户端会继续向NameNode获取下一批的block列表；
6、 读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，客户端会通知NameNode，然后再从下一个拥有该
block副本的DataNode继续读。
7、 read方法是并行的读取block信息，不是一块一块的读取；NameNode只是返回Client请求包含块的DataNode地址，
并不是返回请求块的数据；最终读取来所有的block会合并成一个完整的最终文件。

HDFS文件流程图

8、hdfs的seconderyNameNode辅助管理元数据的流程

HDFS的元数据辅助管理
	当 Hadoop 的集群当中, NameNode的所有元数据信息都保存在了 FsImage 与 Eidts 文件当中, 这两个文件就记录了
	所有的数据的元数据信息, 元数据信息的保存目录配置在了 hdfs-site.xml 当中
edits：
	edits 是在NameNode启动时对整个文件系统的快照存放了客户端最近一段时间的操作日志
	客户端对 HDFS 进行写文件时会首先被记录在 edits 文件中
	edits 修改时元数据也会更新
fsimage：
	fsimage是在NameNode启动时对整个文件系统的快照
	NameNode 中关于元数据的镜像, 一般称为检查点, fsimage 存放了一份比较完整的元数据信息
	因为 fsimage 是 NameNode 的完整的镜像, 如果每次都加载到内存生成树状拓扑结构，这是非常耗内存和CPU, 所以一般开始时对
	NameNode 的操作都放在 edits 中
	随着edits 内容增大, 就需要在一定时间点和 fsimage 合并
SecondaryNameNode的作用
	SecondaryNameNode的作用是合并fsimage和edits文件。
	NameNode的存储目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候会首先读取整个fsimage文件，将
	信息装载到内存中。
	Edits文件存储日志信息，在NameNode上所有对目录的最新操作，增加，删除，修改等都会保存到edits文件中，并不会同步到
	fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并。
	所以当NameNode启动的时候，首先装载fsimage文件，然后按照edits中的记录执行一遍所有记录的操作，最后把信息的目录树写入
	fsimage中，并删掉edits文件，重新启用新的edits文件。
	但是如果NameNode执行了很多操作的话，就会导致edits文件会很大，那么在下一次启动的过程中，就会导致NameNode的启动速度很慢，
	慢到几个小时也不是不可能，所以出现了SecondNameNode。
SecondaryNameNode唤醒合并的规则
	SecondaryNameNode 会按照一定的规则被唤醒，进行fsimage和edits的合并，防止文件过大。
	合并的过程是，将NameNode的fsimage和edits下载到SecondryNameNode 所在的节点的数据目录，然后合并到fsimage文件，最后
	上传到NameNode节点。合并的过程中不影响NameNode节点的操作
	SecondaryNameNode被唤醒的条件可以在core-site.xml中配置：
	fs.checkpoint.period：单位秒，默认值3600(1小时)，检查点的间隔时间，当距离上次检查点执行超过该时间后启动检查点
	fs.checkpoint.size：单位字节，默认值67108864(64M)，当edits文件超过该大小后，启动检查点

9.MR的思想

MR的核心思想是分而治之，简单来说就是执行一个任务的时候，先对任务进行分割执行，最终将各个分割部分的
执行结果进行合并
map：负责把复杂的任务分解为若干个简单的任务来进行处理，这些任务能进行分割的前提是它们能够并行计算，
彼此之间没有依赖关系
reduce：负责合并结果，即对map执行结果进行全局汇总

月暖.如梵音

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
知识点整理

1、zookeeper中有那些类型的节点, 各个类型有什么特点zookeeper的节点（Znode）类型一共有两大类，分别是：临时节点和永久节点临时节点： 1、节点的生命周期依赖于创建它的会话，一旦会话结束，节点将被自动删除，也可以进行手动删除 2、临时节点不允许拥有子节点永久节点： 1、节点的生命周期不依赖于创建它的会话，只有在客户端执行删除操作的时候，才会删除节点Znode的特性：序列化特性，如果创建节点进行制定，Znode名字后面会自动追加一个不断增加的序列号。序列号对于此节点的.
复制链接

扫一扫