我管理着一个小型的开发团队,在任何时候我们都有几个可以被认为是" 令人尴尬的并行 "的正在进行的(一次性)数据项目- 这些项目通常涉及在一台计算机上运行一个脚本几天,一个经典的例如,处理数千个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模式 - 当那里没有明确的"地图"或"减少"元素来完成任务.)
干杯!
你的想法是对的.
您提到的上述示例仅使用hadoop提供的解决方案的一部分.他们肯定使用了hadoop和分布式文件系统的并行计算能力.您不必总是需要减少步骤.在运行的并行进程之间可能没有任何数据相互依赖性.在这种情况下,您将消除reduce步骤.
我认为你的问题也适合hadoop解决方案领域.
你有庞大的数据 - 大量的PDF文件和长期的工作
您可以通过将文件放在HDFS上并运行MapReduce作业来并行处理这些文件.理论上,您的处理时间会因群集上的节点数而增加.如果您没有看到需要聚合由各个线程生成的数据集,则不需要使用reduce步骤,您还需要设计reduce步骤.
这里的问题是,如果你不需要减少步骤,你只需要利用hadoop的并行计算能力,你就可以在不那么昂贵的硬件上运行你的工作.
| 归档时间： |
|
| 查看次数： |
11124 次 |
| 最近记录： |