阐明 Hadoop 与 RabbitMQ+Celery 的用例

Posted 2023-02-24

【中文标题】阐明 Hadoop 与 RabbitMQ+Celery 的用例

【英文标题】：Clarification of use-cases for Hadoop versus RabbitMQ+Celery

【发布时间】：2013-09-02 11:48:27

【问题描述】：

我知道有类似的问题，比如：

https://***.com/questions/8232194/pros-and-cons-of-celery-vs-disco-vs-hadoop-vs-other-distributed-computing-packag Differentiate celery, kombu, PyAMQP and RabbitMQ/ironMQ

但是我问这个是因为我正在寻找一个由几个用例示例支持的更特别的区别，拜托。

所以，我是一个 python 用户，想要制作一个/两个的程序：

太大而不能 花费太长时间

在一台机器上做，并在多台机器上处理它们。我熟悉python中的（单机）多处理包，我现在正在编写mapreduce风格的代码。例如，我知道我的函数很容易并行化。

在询问我通常的聪明的 CS 建议提供者时，我的问题是：

“我想拿一个任务，把它拆分成一堆子任务，在一堆机器上同时执行，然后这些结果被聚合并根据其他一些函数进行处理，这可能是一个reduce，或者例如，可能是串行添加到数据库的指令。”

根据我的用例分解，我认为我同样可以使用 Hadoop 或一组 Celery worker + RabbitMQ 代理。然而，当我向贤明的建议提供者询问时，他们的回答好像我完全疯了，将 Hadoop 和 Celery 视为可比较的解决方案。我已经阅读了很多关于 Hadoop 和 Celery 的文章——我认为我对两者的作用有很好的了解——我似乎不明白的是：

为什么它们被认为如此独立、如此不同？ 鉴于它们似乎被视为完全不同的技术——以什么方式？有哪些用例可以区分彼此或更好？ 两者都可以解决哪些问题，将其中一个用于哪些领域会特别愚蠢？ 是否有更好、更简单的方法来为多台机器实现类似于 Pool.map() 的多处理功能？让我们想象一下，我的问题不受存储限制，而是受计算所需的 CPU 和 RAM 的限制，因此没有空间太小来容纳从工作人员返回的结果。 （即，我正在做类似模拟的事情，我需要在由数据库中的值播种的较小机器上生成很多东西，但这些东西在返回到源机器/数据库之前会被减少。）

我知道 Hadoop 是大数据标准，但 Celery 看起来也得到了很好的支持；我很欣赏它不是 java（用于 hadoop 的流式 API python 对我来说看起来不舒服），所以我倾向于使用 Celery 选项。

【参考方案1】：

它们的相同之处在于它们都可以解决您描述的问题（map-reduce）。它们的不同之处在于 Hadoop 完全是为解决该用例而构建的，而 Celey/RabbitMQ 的构建是为了使用消息传递促进不同节点上的任务执行。 Celery 还支持不同的用例。

Hadoop 通过拥有一个大型且特殊的文件系统来解决 map-reduce 问题，mapper 从该文件系统中获取数据，将其发送到一组 map 节点，然后将其缩减为该文件系统。这样做的好处是速度非常快。缺点是它只对基于文本的数据输入进行操作，并不真正支持 Python，而且如果你不能（稍微）做不同的用例。 Celery 是一个基于消息的任务执行器。您可以在其中定义任务并将它们组合在一个工作流中（可以是map-reduce 工作流）。它的优点是它是基于 python 的，您可以在自定义工作流程中将任务拼接在一起。缺点是它依赖于单个代理/结果后端及其设置时间。

1234563如果您希望灵活地运行工作流程任务，请使用 Celery。或者.....

是的！其中一家公司有一个新项目帮助创建了 RabbitMQ（和其他人）使用的消息传递协议 AMQP。它被称为ZeroMQ，与 Celery 相比，它奇怪地降低了抽象级别，从而将分布式消息传递/执行提升到了一个新的水平。它定义了可以以各种方式链接在一起的套接字，以在节点之间创建消息链接。您想对这些消息做的任何事情都由您来写。尽管这听起来像是“围绕套接字的薄包装器有什么好处”，但实际上它处于正确的抽象级别。现在在我们公司，我们正在分解我们所有的 celery 消息并使用 ZeroMQ 重建它。我们发现 Celery 对如何执行任务过于固执己见，而且设置/配置通常很痛苦。此外，必须处理所有流量的中间代理也成为了很大的瓶颈。

简历：

用尽可能少的编程和大量的设置/配置时间计算书中“the”的出现次数：Hadoop 创建原子任务并能够让它们一起工作，无需太多编程和大量设置/配置时间：Celery 几乎无需设置/配置时间即可完全控制如何处理您的消息以及如何对其进行编程：ZeroMQ 没有设置/配置时间的痛苦：套接字

【讨论】：

我正在调查这个问题，我相信你是对的，这非常有帮助。到目前为止，ZeroMQ 是相当惊人的。这是分布式计算和适当的消息路由、网络编程之间的一个奇怪的漏洞。还在努力解决。

我喜欢 ZeroMQ。谢谢！

@Mittenchops 很高兴赢得了您的青睐。克服最初的障碍需要一些时间，但非常值得。