hop

Hadoop最初设计成解决批处理任务的，用它来实现这种迭代式的算法时，只能在每次迭代后，由reducer将临时结果写入HDFS的文件；在下次迭代中，由mapper读入。这样需执行大量IO操作，开销很大，编程也比较麻烦些。如果MapReduce框架能支持类似于管道的方式，可将上一个Job的输出直接输入到下一个Job的mapper中，不仅可以节省大量IO的开销，对于众多迭代式的机器学习算法的实现将是莫大的福音。

UC Berkly的博士生Tyson Condie ，在他的一篇论文MapReduce Online中，提出了Pipelining Hadoop的想法,并实 现了一个原型 HOP - Hadoop Online Prototype project。 最初的MapReduce为简化容错处理，mapper和reducer都先将输出写入磁盘。HOP(Hadoop Online Prototype)在保留Hadoop的容错性前提下，使数据在各个任务间以管道的方式交互，可增加任务的并发性，缩短响应时间，而且拓宽了MapReduce框架的应用领域。

管道化同时面临一些设计上的挑战：

（1）需改进MapReduce简单容错机制以适应管道

中间结果写入磁盘简化了容错，任何任务失败后，JobTracker仅需简单的再分配一个新节点重新执行相同的任务即可，因为任务执行中并未输出任何数据。

（2）管道要求消费者“贪心”地获取生产者产生的数据，

这与MapReduce中的Combiner相冲突。Combiner与Mapper运行在同一节点，通常执行本地的数据压缩和运算，以减少网络通信量。

（3）管道需要解决生产者和消费者的并发和互斥问题。

HOP的设计策略：修改mapper任务，使其产生输出后将数据“推”给reducer

附件是一张hop和hadoop的比较图