hadoop - mapreduce的缺点是什么？

Question

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

Answer 1

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

• 实时处理。
• 将每一个东西都实现为 MR 程序并不总是那么容易。
• 当您的中间进程需要相互通信时（作业单独运行）。
• 当您的处理需要通过网络对大量数据进行混洗时。
• 当您需要处理流数据时。MR 最适合批量处理您已经拥有的大量数据。
• 当您可以使用独立系统获得所需的结果时。与分布式系统相比，配置和管理独立系统显然不那么痛苦。
• 当您有OLTP需求时。MR不适合大量的短线在线交易。

可能还有其他几种情况。但这里重要的是你使用它的程度如何。例如，你不能指望 MR 工作在几毫秒内给你结果。你也不能把它算作它的缺点。只是你在错误的地方使用它。它适用于任何技术，恕我直言。长话短说，三思而后行。

如果你仍然想要，你可以把以上几点作为mapreduce的缺点:)

高温高压

Answer 2

以下是 MapReduce 不能很好地工作的一些用例。

1. 当您需要快速响应时。例如说<几秒钟（使用流处理，CEP等代替）
2. 处理图
3. 复杂算法，例如一些机器学习算法，如 SVM，还可以查看 13 个 drawfs（并行计算研究的景观：伯克利的观点）
4. 迭代 - 当您需要一次又一次地处理数据时。例如 KMeans - 使用 Spark
5. 当 map 阶段生成太多键时。然后排序永远需要。
6. 连接两个具有复杂条件的大型数据集（可以通过散列等处理相同的情况）
7. 有状态的操作 - 例如评估状态机一个接一个地级联任务 - 使用 Hive，Big 可能会有所帮助，但重读和解析数据的开销很大。

Answer 3

1. 您需要重新考虑/重写诸如 Joins、Filter 之类的琐碎操作以在 map/reduce/Key/value 模式中实现
2. MapReduce 假设作业可以并行化。但并非所有数据处理工作都如此。
3. 它与 Java 密切相关，当然你有 Pig 和 Hive 来拯救，但你失去了灵活性。

Answer 4

1. 首先，它流式传输地图输出，如果可以将其保存在内存中，这将更有效率。我最初使用 MPI 部署我的算法，但是当我扩大一些节点开始交换时，这就是我进行转换的原因。

2. Namenode 跟踪分布式文件系统中所有文件的元数据。我正在阅读一本 hadoop 书（Hadoop in action），其中提到 Yahoo 估计每个文件的元数据大约为 600 字节。这意味着如果您的文件过多，您的 Namenode 可能会遇到问题。

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

老实说，我真的不得不努力思考才能找到缺点。mapreduce 为我解决的问题比它引入的问题要大得多。这份清单绝对不完整，只是一些初步的评论。显然，你必须记住它是面向大数据的，这就是它表现最好的地方。还有许多其他具有自己特点的分发框架。