3

我有一个需要递归应用的过滤算法，我不确定 MapReduce 是否适合这项工作。如果没有放弃太多，我可以说每个被过滤的对象都以一个集合为特征，如果是有序列表或队列。

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

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

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

4

3 回答 3

1

Hadoop 的主要优势在于它能够透明地在大量机器上分配工作。为了充分受益于 Hadoop，您的应用程序必须至少具有以下三点特征：

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

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

考虑到您要处理的数据量，我看不出有什么理由不在一台机器上执行，完全在内存中。如果您认为您可以从并行处理少量数据中受益，我建议您关注多核处理而不是分布式数据密集型处理。当然，使用网络集群的处理能力很诱人，但这需要付出代价：主要是网络通信（网络是 hadoop 集群中竞争最激烈的资源）和 I/O 导致的时间效率低下。在非常适合 Hadoop 框架的场景中，这些低效率可以忽略不计，因为通过分发数据和对该数据的相关工作获得了效率。

如我所见，您需要 1000 个工作岗位。所有这些作业的设置和清理对于您的场景来说都是不必要的开销。此外，在我看来，网络传输的开销是不必要的。

于 2012-08-06T21:56:31.367 回答
0

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

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

分布式延续的试金石：尝试使用递归调用在分布式上下文中开发一个简单的斐波那契实现。这是 GridGain 的示例，它使用延续来实现这一点。

希望能帮助到你。

于 2012-08-07T16:19:07.590 回答
-1

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

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

于 2012-08-06T21:33:55.197 回答