Zookeeper在Hadoop与Storm中应用的区别

本文探讨了Hadoop与Storm两种大数据处理框架的主从架构差异。Hadoop采用直接汇报方式,适合批处理任务;而Storm则利用Zookeeper进行状态管理,更适合流处理场景,实现更低延迟和高可用性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Hadoop与Storm都是典型的主从架构,但是在使用 Zookeeper时还是不太一样的。
一、对于Hadoop来说,所有的 slaves都需要向master汇报状态信息,比如:MapReduce里的Tasktracker会向Jobtracker汇报,从而,Jobtracker所在节点内存中会有Tasktracker的状态信息,同时TaskTracker会收到JobTracker的响应信息,告诉TaskTracker需要做的任务。这种方式的优点是:直接、清晰,slave直接向master汇报状态,master返回给slave相关任务。但缺点是:因为这种“状态”进程的恢复是需要时间的,即有很大的延迟,而这种延迟在流式计算中的接受度是很低的,所以,Storm并没有采取这种模式。
二、对于Storm来说,它的主(nimbus),从(supervisor)。
首先,所有的supervisor会将自己的节点信息写至Zookeeper,之后nimbus会从Zookeeper上获取到supervisor的信息,再将topology里的workers按照负载均衡的思想分配至supervisor中,不过这个过程也是写入zookeeper中,而不是直接发送给supervisor,supervisor再从zookeeper上获取任务信息。再去调度Executors去执行。
从而,zookeeper对Storm来说就相当于一个高可用的kv,把节点的状态信息元数据都存入一个kv里,从而使得各个节点都是“无状态”的,那么任何节点崩溃后,都不存在“状态恢复的问题”。直接去zookeeper上拿就行了。比如:nimbus挂了,重启一个nimbus,直接去zookeeper上获取supervisor的信息即可,可以立即知道supervisor所处状态。supervisor挂了,不需要与nimbus通信,它的心跳 是写在zookeeper中的,启动Task也是直接从zookeeper上去(nimbus之前写进去的)。
所以,zookeeper相当于对nimbus与supervisor之间做了一个解耦,所以这种应用就比Hadoop的应用更先进。
唯一的问题是:当nimbus挂了的时候,无法将出错了的supervisor中的任务重新分配到其他supervisor

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值