如何使用Python并行化CPU-intertive数据处理任务？

Question

我创建了一些代码来对大型pdfs数据集执行OCR，并将提取的文本写入csv。这是使用Imagemagick，Pillow，PyOCR（Tesseract）等库的组合完成的，并且已经在一小部分数据样本上进行了测试。

数据包含大量文件夹（~2500），每个文件夹大约有15个pdf。为每个文件夹中的pdfs创建一个csv，处理每个文件夹大约需要10分钟。这意味着在所有2500个文件夹上运行OCR大约需要18天，这太长了。我需要能够在7天或更短的时间内完成整个过程。

因此，我正在研究并行化每个子文件夹的处理，因为每个子文件夹的处理独立于任何其他子文件夹。我的第一种方法是使用concurrent.futures模块创建一个ProcessPool，如下所示：

executor = concurrent.futures.ProcessPoolExecutor(4)
futures = ([executor.submit(run_pdf_to_text_ocr, folder) for folder in sub_folders])
concurrent.futures.wait(futures)

此处run_pdf_to_text_ocr()是运行每个文件夹处理的主要功能。进程使用相同资源存在一些问题，我正在解决这些问题，以便每个文件夹（进程/线程）在其资源使用中被隔离。

当然，这个处理管道非常占用CPU，并且在处理器运行时会最大化它。我将启动一个大型AWS EC2实例，最终完成全部运行。所以，在我开始之前我想知道的是：

  

如果我采取的这种方法是正确的吗？   我是否可以采取其他方法以更好的方式做到这一点？使用分布式处理我应该做些什么呢？我该怎么做才能正确监控这条长期运行的管道，以便了解处理过程中可能出现的任何问题？

我对Python很满意，并且希望尽可能使用它的解决方案。

Answer 1

我认为multiprocessing模块就是你想要的。

from multiprocessing import Pool

workers = Pool()
workers.apply_async(your_task_function, args=(args_for_this_task))
workers.join()

因此，您可以轻松地将整个任务拆分为小任务，然后传递给多个cpu。您应用的任务将放在workers的队列中。

此外，要监控错误，您可以传递错误回调，如下所示：workers.apply_async(your_task_function, args=(args_for_this_task), error_callback=error_callback)

此外，您可以使用multiprocessing.Manager轻松共享流程中的变量，甚至可以在不同的计算机上共享变量。

Answer 2

序言

这项工作可以在一天内完成，也可以在一夜之间完成，但这不适用于任何并行处理架构。为什么呢？

• 在{thread- |的队列中保持并行性是零的需要过程 - } - 执行

• 牧群中的任何一对/群组之间存在零依赖/互通/同步

• 零个需要共享个人独立OCR作业的内容/背景

• 那么为什么要支付所有这些巨大的性能成本，还有更多，Python GIL锁定惩罚（许多线程，但只是GIL锁定到只执行1次 + < strong>所有其他人在队列中等待以获得GIL锁定权限以再次向前运行几步，然后退回并在纯粹的SEQ-relay-race中释放GIL锁定（？！？！ ））

因此，换句话说，正确的架构应该寻求可行的性能扩展（越线性越好），而不是在其他只是顺序的命令式代码中利用真正的并行部分。在强调AWS扩展时，也可能是人为的昂贵租用一个恐龙大小的模拟代码执行实例，只是为了许多刚刚并发的线程执行（仍然存在所有被破坏的风险） GIL步骤SEQ-relay 1-works + ALL-wait），而其他场景可以自适应且经济高效地工作。

最后一个主要的反对意见是，智能系统架构首先遵循工作流程执行的逻辑并首先优化性能约束部分，而不是试图用一些在教科书示例中看起来很酷的SLOC来说服设计板，从来没有。

Smarter way goes into Adaptive, Distributed-processing Architecture

为什么？

• 可以即时添加性能（添加更轻量级的工作单元，如果时间需要，预算允许，直到所有CPU容量稳定地达到100％）

• 可以从分布式处理中收到增量交付（已完成的工作单元（OCR'd PDF）），因为它们看起来已经完成，而不是在等待之后，在任何处理控制之外，7天获得第一个或什么都没有如果在引擎盖下出现问题，

• 甚至可以进行原型/部署/调整/修改/更新/重新设计处理的方式，同时仍然保持工作 - 实时更新可以顺利进行，而不会浪费任何时间执行的工作单位，由前一个工人版本处理。

总而言之，忘记使用Python内置插件（即使加入努力将其修改为GIL发布的格式和形状），而是完全评估大规模可扩展分布式处理的性能，扩展和ROI优势溶液

• 在需要时添加工作人员节点以及需要多少工作节点（在办公室类型的环境中或在可用的IaaS优惠券或其他（几乎） - 零成本处理节点授权的情况下，甚至数百或数千个进入夜间班次）
• 根据需要使用其他信令工具（可以向终端询问工人报告他们的实际状态/ ETA /远程CPU负载/ ...）
• 运行 tcp:// ，确实是异构分布式系统（AWS和其他外部IaaS配置工具）和许多其他{ inproc:// | ipc:// | pgm:// | epgm:// }传输类，实际上所有强大的设计方法都可以实现 - 性能设计。

后记：无需警告你PIL非常慢，所以如果需要加速单个文档 - 作业处理，探查器很可能会指向这一个热点。