我管理一个小型开发团队，在任何时候我们都有几个可以被视为“Embarrassingly parallel”的正在进行的（一次性）数据项目 - 这些项目通常涉及在一台计算机上运行单个脚本有几天，一个典型的例子是处理几千个PDF文件，以提取一些关键文本并放入CSV文件，以便以后插入数据库。
我们现在正在做足够的这类任务，我开始研究使用带有一些备用服务器的RabbitMQ开发一个简单的作业队列系统（着眼于将Amazon SQS / S3 / EC2用于需要更大扩展的项目）
在搜索其他人这样做的例子时，我不断遇到经典的Hadoop纽约时报的例子：
纽约时报使用100个Amazon EC2实例和一个Hadoop应用程序，在24小时内将4 TB原始图像TIFF数据（存储在S3中）处理成1100万个已完成的PDF，计算成本约为240美元（不是包括带宽）
哪个听起来很完美？所以我研究了Hadoop和Map / Reduce。
但我无法解决的是他们是如何做到的？或者他们为什么这样做？
转换PDF中的TIFF肯定不是Map / Reduce问题吗？一个简单的工作队列不是更好吗？
另一个经典的Hadoop示例是来自Yahoo Hadoop Tutorial的“wordcount”似乎非常适合Map / Reduce，我可以看出为什么它是大数据的强大工具。
我不明白这些“令人尴尬的并行”任务是如何被放入Map / Reduce模式的？
TL; DR
这是一个非常概念化的问题，基本上我想知道如何处理“处理数千个PDF文件以提取一些关键文本并放入CSV文件”的任务到Map / Reduce模式中？
如果你知道任何完美的例子，我不是要你为我写的。
（注意：我们有处理PDF的代码，我不是要求它 - 它只是一个例子，它可能是任何任务。我要求将这样的流程放入Hadoop Map / Reduce模式 - 当任务没有明确的“Map”或“Reduce”元素时。）
干杯！
答案 0 :(得分：5)
你的想法是正确的。
您提到的上述示例仅使用了hadoop提供的解决方案的一部分。他们肯定使用hadoop和分布式文件系统的并行计算能力。您不必总是需要减少步骤。在运行的并行进程之间可能没有任何数据相互依赖性。在这种情况下，您将消除reduce步骤。
我认为您的问题也适合hadoop解决方案域。
你有庞大的数据 - 大量的PDF文件 还有一份长期工作
您可以通过将文件放在HDFS上并运行MapReduce作业来并行处理这些文件。理论上，您的处理时间会因群集上的节点数而增加。如果您认为不需要聚合由各个线程生成的数据集，则不需要使用reduce步骤，您还需要设计reduce步骤。
这里的问题是，如果你不需要减少步骤，你只需要利用hadoop的并行计算能力，你就可以在不那么昂贵的硬件上运行你的工作。
答案 1 :(得分：1)
我还需要添加一件事：错误处理和重试。在分布式环境中，节点故障非常常见。我经常运行由数百个节点组成的EMR集群，持续3-8天，并发现在此期间很可能发生3或4次失败。 Hadoop JobTracker将很好地在不同的节点中重新提交失败的任务（最多一定次数）。