Hadoop适用于递归数据处理

Question

我有一个需要递归应用的过滤算法，我不确定MapReduce是否适合这项工作。如果没有给出太多的东西，我可以说正在过滤的每个对象都是一个集合，如果有序列表或队列。

1. 当我从SQL导出时，数据并不大，只有250MB左右 CSV。
2. 映射步骤很简单：列表的头部包含一个对象，该对象可以将列表归类为属于 N 映射节点之一。每个节点的过滤算法对分配给节点的列表集合起作用，在过滤结束时，列表保持与过滤之前相同或列表头部被删除。
3. reduce功能也很简单：所有地图作业列表都汇集在一起​​，可能必须写回磁盘。
4. 当所有 N 节点都返回其输出时，将使用这组新数据重复映射步骤。

注意： N 可以多达2000个节点。 很简单，但在满足算法的终止条件之前，它最多需要1000次递归。

我的问题是这项工作是否适合Hadoop？如果没有，我的选择是什么？

Answer 1

Hadoop的主要优势在于它能够在大量机器上透明地分配工作。为了充分受益于Hadoop，您的应用程序必须至少通过以下三个方面进行表征：

1. 处理大量数据（分布在机器群集中的数据） - 这是不可能存储在一台机器上的
2. 可以数据并行化（即原始数据的块可以独立于其他块进行操作）
3. 应用程序试图解决的问题很好地适用于MapReduce（分散 - 聚集）模型。

似乎在这3个中，你的应用程序只有最后2个特征（观察到你试图以递归方式使用分散 - 收集程序 - 这意味着大量的作业 - 等于递归深度;见最后一段为什么这可能不适合hadoop）。

考虑到您尝试处理的数据量，我没有看到任何理由说明您不会在单个计算机上执行此操作，完全在内存中。如果您认为可以从并行处理少量数据中受益，我建议关注多核处理而不是分布式数据密集处理。当然，使用网络集群的处理能力很诱人，但这需要付出代价：主要是网络通信（网络是hadoop集群中最具竞争力的资源）和I / O给出的低效率。在适合Hadoop框架的场景中，由于通过分发数据和相关的数据工作所获得的效率，可以忽略这些低效率。

我可以看到，你需要1000个工作。所有这些作业的设置和清理对于您的方案来说将是不必要的开销。此外，在我看来，网络传输的开销并不是必需的。

Answer 2

递归算法在分布式系统中很难，因为它们可能导致快速饥饿。任何适用于此的中间件都需要支持分布式延续，即能够在不保持主叫侧资源（如线程）的情况下进行“递归”调用。

GridGain是一种原生支持分布式延续的产品。

对分布式延续的试金石：尝试使用递归调用在分布式上下文中开发一个天真的斐波纳契实现。这是使用continuation实现此目的的GridGain的example。

希望它有所帮助。

Answer 3

问：答案，但我建议您阅读MongoDB和Hadoop的比较： http://www.osintegrators.com/whitepapers/MongoHadoopWP/index.html

不知道更多，很难说。你可能想尝试两者。如果你发布你的结果！