【眼前一亮!】看Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上?

简介: 这篇文章给大家聊聊Hadoop在部署了大规模的集群场景下,大量客户端并发写数据的时候,文件契约监控算法的性能优化。

一,这篇文章给大家聊聊Hadoop在部署了大规模的集群场景下,大量客户端并发写数据的时候,文件契约监控算法的性能优化。
二,背景引入

先给大家引入一个小的背景,假如多个客户端同时要并发的写Hadoop HDFS上的一个文件,大家觉得这个事儿能成吗?

明显不可以接受啊,兄弟们,HDFS上的文件是不允许并发写的,比如并发的追加一些数据什么的。

所以说,HDFS里有一个机制,叫做文件契约机制。

也就是说,同一时间只能有一个客户端获取NameNode上面一个文件的契约,然后才可以写入数据。此时如果其他客户端尝试获取文件契约的时候,就获取不到,只能干等着。

通过这个机制,就可以保证同一时间只有一个客户端在写一个文件。

在获取到了文件契约之后,在写文件的过程期间,那个客户端需要开启一个线程,不停的发送请求给NameNode进行文件续约,告诉NameNode:

NameNode大哥,我还在写文件啊,你给我一直保留那个契约好吗?

而NameNode内部有一个专门的后台线程,负责监控各个契约的续约时间。

如果某个契约很长时间没续约了,此时就自动过期掉这个契约,让别的客户端来写。

说了这么多,老规矩,给大家来一张图,直观的感受一下整个过程。

https://img2.mukewang.com/5ca311a00001d13306320294.jpg

三、问题凸现

好,那么现在问题来了,假如我们有一个大规模部署的Hadoop集群,同时存在的客户端可能多达成千上万个。

此时NameNode内部维护的那个文件契约列表会非常非常的大,而监控契约的后台线程又需要频繁的每隔一段时间就检查一下所有的契约是否过期。

比如,每隔几秒钟就遍历大量的契约,那么势必造成性能不佳,所以说这种契约监控机制明显是不适合大规模部署的hadoop集群的。

四、Hadoop的优化方案

那么Hadoop是如何对文件契约监控算法进行优化的呢?咱们来一步一步的看一下他的实现逻辑。

首先,我们一起来看看下面这张手绘图:

https://img3.mukewang.com/5ca311b30001cfb606360337.jpg

其实奥秘十分的简单,每次一个客户端发送续约请求之后,就设置这个契约的最近一次续约时间。

然后,基于一个TreeSet数据结构来根据最近一次续约时间对契约进行排序,每次都把续约时间最老的契约排在最前头,这个排序后的契约数据结构十分的重要。

TreeSet是一种可排序的数据结构,他底层基于TreeMap来实现。

TreeMap底层则基于红黑树来实现,可以保证元素没有重复,同时还能按照我们自己定义的排序规则在你每次插入一个元素的时候来进行自定义的排序。

所以这里我们的排序规则:就是按照契约的最近一次续约时间来排序。

其实这个优化就是如此的简单,就是维护这么一个排序数据结构而已。

我们现在来看一下Hadoop中的契约监控的源码实现:

https://img4.mukewang.com/5ca311c500014ffa04940305.jpg

每次检查契约是否过期的时候,你不要遍历成千上万的契约,那样遍历效率当然会很低下。

我们完全可以就从TreeSet中获取续约时间最老的那个契约,假如说连最近一次续约时间最老的那个契约都还没过期,那么就不用继续检查了啊!这说明续约时间更近的那些契约绝对不会过期!

举个例子:续约时间最老的那个契约,最近一次续约的时间是10分钟以前,但是我们判断契约过期的限制是超过15分钟不续约就过期那个契约。

这个时候,连10分钟以前续约的契约都没有过期,那么那些8分钟以前,5分钟以前续约的契约,肯定也不会过期啊!

这个机制的优化对性能的提升是相当有帮助的,因为正常来说,过期的契约肯定还是占少数,所以压根儿不用每次都遍历所有的契约来检查是否过期。

我们只需要检查续约时间最旧的那几个契约就可以了,如果一个契约过期了,那么就删掉那个契约,然后再检查第二旧的契约好了。以此类推。

通过这个TreeSet排序 + 优先检查最旧契约的机制,有效的将大规模集群下的契约监控机制的性能提升至少10倍以上,这种思想是非常值得我们学习和借鉴的。

给大家稍微引申一下,在Spring Cloud微服务架构中,Eureka作为注册中心其实也有续约检查的机制,跟Hadoop是类似的。

但是在Eureka中就没有实现类似的续约优化机制,而是暴力的每一轮都遍历所有的服务实例的续约时间。

如果你面对的是一个大规模部署的微服务系统呢,情况就不妙了!

部署了几十万台机器的大规模系统,有几十万个服务实例的续约信息驻留在Eureka的内存中,难道每隔几秒钟都要遍历几十万个服务实例的续约信息吗?

最后给大家提一句,优秀的开源项目,蕴含着很多优秀的设计思想。多看各种优秀开源项目的源码,是短时间内快速、大幅度提升一个人的技术功底和技术水平的方式,大家不妨尝试一下。

相关文章
|
1月前
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
162 6
|
18天前
|
机器学习/深度学习 算法 5G
基于MIMO系统的SDR-AltMin混合预编码算法matlab性能仿真
基于MIMO系统的SDR-AltMin混合预编码算法通过结合半定松弛和交替最小化技术,优化大规模MIMO系统的预编码矩阵,提高信号质量。Matlab 2022a仿真结果显示,该算法能有效提升系统性能并降低计算复杂度。核心程序包括预编码和接收矩阵的设计,以及不同信噪比下的性能评估。
36 3
|
21天前
|
机器学习/深度学习 算法 数据挖掘
提高时钟置换算法的性能
【10月更文挑战第25天】通过上述一种或多种方法的综合应用,可以在不同程度上提高时钟置换算法的性能,使其更好地适应各种复杂的系统环境和应用场景,提高虚拟内存管理的效率和系统的整体性能。
35 5
|
1月前
|
分布式计算 Hadoop Shell
Hadoop-35 HBase 集群配置和启动 3节点云服务器 集群效果测试 Shell测试
Hadoop-35 HBase 集群配置和启动 3节点云服务器 集群效果测试 Shell测试
71 4
|
1月前
|
SQL 分布式计算 Hadoop
Hadoop-37 HBase集群 JavaAPI 操作3台云服务器 POM 实现增删改查调用操作 列族信息 扫描全表
Hadoop-37 HBase集群 JavaAPI 操作3台云服务器 POM 实现增删改查调用操作 列族信息 扫描全表
33 3
|
1月前
|
分布式计算 Hadoop Shell
Hadoop-36 HBase 3节点云服务器集群 HBase Shell 增删改查 全程多图详细 列族 row key value filter
Hadoop-36 HBase 3节点云服务器集群 HBase Shell 增删改查 全程多图详细 列族 row key value filter
58 3
|
1月前
|
分布式计算 Java Hadoop
Hadoop-30 ZooKeeper集群 JavaAPI 客户端 POM Java操作ZK 监听节点 监听数据变化 创建节点 删除节点
Hadoop-30 ZooKeeper集群 JavaAPI 客户端 POM Java操作ZK 监听节点 监听数据变化 创建节点 删除节点
62 1
|
1月前
|
分布式计算 监控 Hadoop
Hadoop-29 ZooKeeper集群 Watcher机制 工作原理 与 ZK基本命令 测试集群效果 3台公网云服务器
Hadoop-29 ZooKeeper集群 Watcher机制 工作原理 与 ZK基本命令 测试集群效果 3台公网云服务器
42 1
|
30天前
|
缓存 分布式计算 监控
算法优化:提升程序性能的艺术
【10月更文挑战第20天】算法优化:提升程序性能的艺术
|
1月前
|
算法 安全 数据安全/隐私保护
基于game-based算法的动态频谱访问matlab仿真
本算法展示了在认知无线电网络中,通过游戏理论优化动态频谱访问,提高频谱利用率和物理层安全性。程序运行效果包括负载因子、传输功率、信噪比对用户效用和保密率的影响分析。软件版本:Matlab 2022a。完整代码包含详细中文注释和操作视频。
下一篇
无影云桌面