mapreduce 的缺点是什么？

Question

MapReduce 的缺点是什么？ MapReduce 有很多优点。但我也想知道mapreduce的缺点。

Answer 1

我宁愿问什么时候mapreduce不是合适的选择？我认为如果您按预期使用它，您不会看到任何缺点。话虽如此，在某些情况下，mapreduce 不是一个合适的选择：

• 实时处理。
• 将每件事都实现为 MR 程序并不总是那么容易。
• 当您的中间进程需要相互通信时（作业独立运行）。
• 当您的处理需要通过网络“打乱”大量数据时。 当您需要处理流数据时。 MR 最适合
批处理
• 您已有的大量数据。 当您可以使用独立系统获得所需的结果时。与分布式系统相比，配置和管理独立系统显然不那么痛苦。
• 当您有
OLTP
• 需求时。 MR不适合大量短线在线交易。
可能还有其他几种情况。但这里重要的是你使用它的程度如何。例如，您不能指望 MR 作业会在几毫秒内给出结果。你也不能把它算作它的缺点。只是你用错了地方而已。恕我直言，这对于任何技术都适用。长话短说，行动前请三思。

如果你还想的话，你可以把以上几点当作mapreduce的缺点:)

HTH

Answer 2

当您需要快速响应时。例如说

1. 处理图表< few seconds (Use stream processing, CEP etc instead)
2. 复杂的算法，例如一些机器学习算法，例如 SVM，还可以看到 13 个drawfs （并行计算研究的前景：来自伯克利的观点）
3. 迭代 - 当您需要一次又一次处理数据时。例如KMeans - 使用 Spark
4. 当map阶段生成过多的key。那么排序就需要永远进行。
5. 连接两个具有复杂条件的大型数据集（相同的情况可以 通过哈希等处理）
6. 有状态操作 - 例如评估状态机级联任务 一个接一个 - 使用 Hive，Big 可能会有所帮助，但开销很大 重新读取和解析数据。

Answer 3

您需要重新思考/重写诸如连接、过滤之类的琐碎操作，以在映射/归约/键/值模式中实现

1. MapReduce 假设作业可以并行化。但并非所有数据处理作业都是如此。
2. 它与Java紧密相连，当然你有Pig和Hive来救援，但你失去了灵活性。

Answer 4

首先，它
1. 流式传输地图输出

   ，如果可以将其保留在内存中，这将更加高效。我最初使用 MPI 部署算法，但当我扩大一些节点开始交换时，这就是我进行转换的原因。

2. Namenode 跟踪分布式文件系统中所有文件的元数据

   。我正在读一本 hadoop 书（Hadoop in action），其中提到雅虎估计每个文件的元数据约为 600 字节。这意味着如果您有太多文件，您的 Namenode 可能会遇到问题。

如果您不想使用
3. streaming API

   ，您必须使用java语言编写程序。例如，我从 C++ 进行了翻译。这有一些副作用，例如，与 C 相比，Java 的字符串开销很大。由于我的软件都是关于字符串的，所以这是某种缺点。

说实话我真的费了好大劲才找到缺点。 MapReduce 为我解决的问题比它引入的问题要大得多。

这个列表绝对不完整

，只是一些初步评论。显然，您必须记住，它是面向“大数据”的，而这正是它发挥最佳性能的地方。还有很多其他的分发框架，各有自己的特点。 MapReduce 有一些缺点，

Answer 5

MapReduce

不适合实时计算和流计算

。它专为大型数据集的批处理而设计，这可能需要很长时间才能完成。

• MapReduce 有一个固定的处理管道并且
不支持迭代
• 。它还缺乏对多输入运算符的支持。 MapReduce 对配置参数敏感，需要复杂的调优。