hadoop改进方面的胡思乱想

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数来定的, 线程太多, 消耗太大。

你可能感兴趣的:(hadoop,erlang,数据挖掘,百度,CouchDB)