我管理着一个开发小组，在任何时候，我们都有几个正在进行的（一次性）数据项目，这些项目可能被认为是“令人尴尬的并行”——这些项目通常涉及在一台计算机上运行一个脚本好几天，一个典型的例子是处理几千个pdf文件来提取一些关键文本并放入csv文件中，以便以后插入数据库。
我们现在已经完成了足够多的此类任务，因此我开始研究使用rabbitmq和一些备用服务器开发一个简单的作业队列系统（着眼于将amazonsqs/s3/ec2用于需要更大规模扩展的项目）
在寻找其他人这样做的例子的过程中，我经常会遇到一个经典的hadoop纽约时报的例子：
《纽约时报》使用100个amazon ec2示例和一个hadoop应用程序在24小时内将4 tb的原始图像tiff数据（存储在s3中）处理成1100万个成品PDF，计算成本约为240美元（不包括带宽）
哪个听起来很完美？所以我研究了hadoop和map/reduce。
但我搞不懂他们是怎么做到的？或者他们为什么这么做？
转换pdf格式的tiff不是Map/缩小问题吗？简单的工作队列不是更好吗？
另一个经典的hadoop例子是yahoo hadoop教程中的“wordcount”似乎非常适合map/reduce，我可以理解为什么它是一个强大的大数据工具。
我不明白这些“令人尴尬的并行”任务是如何放入map/reduce模式的？
热释光；博士
这在很大程度上是一个概念性的问题，基本上我想知道如何将“处理几千个pdf文件以提取一些关键文本并放入csv文件”的任务整合到map/reduce模式中？
如果你知道任何完美的例子，我不是要你为我写。
（注：我们有代码来处理pdf的，我不是要求-这只是一个例子，它可以是任何任务。我想问的是，在没有明确的任务“map”或“reduce”元素的情况下，如何将这样的过程放入hadoop map/reduce模式中。）
干杯！
2条答案
按热度按时间ix0qys7i1#
你的想法是对的。
上面提到的示例只使用了hadoop提供的部分解决方案。他们肯定使用了hadoop的并行计算能力和分布式文件系统。你不必总是需要减少步骤。运行的并行进程之间可能没有任何数据相关性。在这种情况下，您将消除reduce步骤。
我认为你的问题也会进入hadoop解决方案领域。
你有大量的数据-大量的pdf文件和长时间运行的工作
通过将文件放在hdfs上并运行mapreduce作业，可以并行处理这些文件。从理论上讲，处理时间会随着集群中节点的数量而增加。如果不需要聚合各个线程生成的数据集，则不需要使用reduce步骤，否则还需要设计reduce步骤。
这里的问题是，如果您不需要reduce步骤，您只需要利用hadoop的并行计算能力，再加上您可以在不太昂贵的硬件上运行您的作业。
fkvaft9z2#
我还需要添加一件事：错误处理和重试。在分布式环境中，节点故障非常常见。我定期运行由几百个节点组成的emr集群，每次运行3-8天，发现在这段时间内有3到4个节点很可能失败。hadoop jobtracker可以很好地在不同的节点中重新提交失败的任务（最多提交一定次数）。