mapreduce的缺点是什么

Question

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

Answer 1

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

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

可能还有其他几种情况。但这里重要的是你用得有多好。例如，你不能指望MR工作能在几毫秒内给你结果。你也不能把它算作它的缺点。只是你用错地方了。这对任何技术都适用，IMHO。长话短说，三思而后行。

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

HTH

Answer 2

以下是MapReduce工作不太好的一些用例。

1. 当你需要快速回应时。例如说<几秒钟（使用流处理、CEP等）
2. 处理图形
3. 复杂的算法，例如一些机器学习算法，如SVM，也参见13张图（从伯克利看并行计算研究的前景）
4. 迭代—当您需要一次又一次地处理数据时。例如KMeans-使用Spark
5. 当映射阶段生成过多关键帧时。感官需要永远
6. 连接具有复杂条件的两个大型数据集（大小写相等）通过散列等处理）
7. 状态操作-例如评估状态机级联任务一个接一个-使用Hive，Big可能会有所帮助，但开销很大重新读取和解析数据

Answer 3

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

Answer 4

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

2. Name节点跟踪分布式文件系统中所有文件的元数据。我正在读一本hadoop书（hadoop在实际操作中），其中提到雅虎估计每个文件的元数据大约为600字节。这意味着，如果文件太多，Namenode可能会出现问题。

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

老实说，我真的必须认真思考才能找到缺点。mapreduce为我解决的问题比它引入的问题要大得多这个列表肯定不完整，只是第一句话。显然，您必须记住，它是面向大数据的，这是它的最佳表现。有很多其他的分发框架都有自己的特点。