hadoop改进方面的胡思乱想

本文探讨了Hadoop在数据处理过程中的局限性,并提出了几项改进措施。包括:取消不必要的排序步骤以提高数据挖掘效率;引入转发机制提升灵活性;改进任务跟踪能力;优化mapper数量设置等。

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

1. 我做数据挖掘的时候, 经常需要只对key分组,不必排序。目前把sort类给设为null能处理,但还是不尽人意。hadoop的机制是通过一个circle buffer 收集mapper输出的东西, 到了io.sort.mb * percent量的时候,就spill到disk, 而spill前使用排序,默认快排。 之后reduce下载spill的东西, 进行merge, merge的时候使用了堆排。我的想法是通过一个hash,每个hash的元素是一个链表,存放相同key的所有值。不过这样就没circle buffer了,用不到其对stream缓存的优点,这个要仔细想想。

2. map之后要么直接写到hdfs(reducer 个数为0时), 要么同一道作业指定的reducer去处理这些东西. 这个机制很不灵活。有时候我的mapper输出,让不同的reducer处理不同的任务,输出不同的结果。 目前hadoop虽然能处理,但太牵强了。如果mapper处理完之后,加一层转发机制。这时候可以少一次io, 而且灵活,  NB. 如果能把数据像流一样处理,而且可以分流,汇集之类的,那更好。

3. 还是百度提出的老问题, 机器一般挂多块磁盘。 单块磁盘的故障会导致系统认为整个节点down了, 这个修改相应的代码应该可以实现。slave报告的时候准确一点, 就可以只复制坏了的磁盘的数据了。

4. hadoop的任务跟踪能力太弱了,如果能做到和erlang那么NB,就厉害了

5. mapper的个数实际上是根据block数来定的, 线程太多, 消耗太大。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值