我有一个需要递归应用的过滤算法，我不确定MapReduce是否适合这份工作。在没有透露太多信息的情况下，我可以说，每个被过滤的对象都由一个集合if有序列表或队列来表征。
- 数据并不庞大，当我从SQL导出到CSV
- 映射步骤很简单：列表的头部包含一个对象，该对象可以将列表分类为属于N映射节点之一。每个节点的过滤算法处理分配给该节点的列表集合，在过滤结束时，列表与过滤前保持不变，或者删除列表的头部
- reduce函数也很简单：所有映射作业的列表都被放在一起，可能需要写回磁盘
- 当所有N节点都返回了它们的输出时，将使用这组新数据重复映射步骤
注意：N可以多达2000个节点。很简单，但在满足算法的终止条件之前，它可能需要多达1000次递归。
我的问题是这个工作适合Hadoop吗？如果没有，我有什么选择？
Hadoop的主要优势在于它能够在大量机器上透明地分配工作。为了充分受益于Hadoop，您的应用程序必须至少通过以下三件事来表征：
- 处理大量数据（分布在机器集群中的数据），这是不可能存储在一台机器上的
- 数据可并行化（即原始数据块可以独立于其他块进行操作）
- 应用程序试图解决的问题很好地适用于MapReduce（散射-聚集）模型
在这3个特性中，您的应用程序似乎只有最后2个特性（观察到您正试图递归地使用分散-聚集过程，这意味着大量的作业，等于递归深度；请参阅最后一段，为什么这可能不适合hadoop）。
考虑到你试图处理的数据量，我看不出有任何理由不在一台机器上完全在内存中进行处理。如果您认为可以从并行处理少量数据中获益，我建议您将重点放在多核处理上，而不是分布式数据密集型处理上。当然，使用网络集群的处理能力是很诱人的，但这是有代价的：主要是网络通信（网络是hadoop集群中竞争最激烈的资源）和I/O造成的时间效率低下。在非常适合Hadoop框架的场景中，由于通过分发数据和对该数据的相关工作所获得的效率，可以忽略这些低效率。
正如我所看到的，你需要1000个工作岗位。所有这些作业的设置和清理对于您的场景来说将是不必要的开销。此外，在我看来，网络传输的开销是没有必要的。
递归算法在分布式系统中很难实现，因为它们会导致快速饥饿。任何适用于此的中间件都需要支持分布式延续，即在不占用调用方资源（如线程）的情况下进行"递归"调用的能力。
GridGain是一款本机支持分布式延续的产品。
分布式延续的试金石：尝试使用递归调用在分布式上下文中开发一个简单的fibonacci实现。下面是GridGain的例子，它使用continuations实现了这一点。
希望能有所帮助。
Q&D、 但我建议您阅读MongoDB和Hadoop的比较：http://www.osintegrators.com/whitepapers/MongoHadoopWP/index.html
如果不了解更多，就很难说。你可能想两者都试试。如果你这样做了，请发布你的结果！