比如K均值聚类，SVM等迭代式的算法，仅执行一次Job是不可能完成计算。而MapReduce框架，包括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
