我知道也有类似的问题，比如：
- https://stackoverflow.com/questions/8232194/pros-and-cons-of-celery-vs-disco-vs-hadoop-vs-other-distributed-computing-packag
- 区分芹菜、康普、PyAMQP和拉比MQ/铁MQ
但我之所以这么问，是因为我正在寻找一个由几个用例示例支持的更特殊的区别。
所以，我是一个python用户，他想制作以下两种程序之一：
- 太大了
- 花费太长时间
在一台机器上进行，并在多台机器上处理它们。我熟悉python中的（单机）多处理包，现在我正在编写mapreduce风格的代码。例如，我知道我的函数很容易并行化。
在询问我通常聪明的CS建议者时，我将我的问题表述为：
"我想接受一项任务，将其拆分为一堆在一堆机器上同时执行的子任务，然后将这些结果聚合起来，并根据其他功能进行处理，例如，这些功能可能是reduce，也可能是串行添加到数据库的指令。"
根据我的用例分解，我认为我同样可以使用Hadoop或一组Celery workers+RabbitMQ broker。然而，当我问贤者的建议时，他们的回答就像我完全疯了一样，把Hadoop和Celery视为可比较的解决方案。我读过很多关于Hadoop的文章，也读过Celery的文章——我想我对两者的作用都很了解——我似乎不明白的是：
- 为什么他们被认为如此分离，如此不同
- 考虑到它们似乎被视为完全不同的技术——以什么方式？区分一个用例和另一个用例或者对一个用例比另一个更好的用例是什么
- 两者都能解决什么问题，把其中一个或另一个用于哪些领域会特别愚蠢
- 有没有更好、更简单的方法可以实现多处理，比如Pool.map（）-多台机器的功能？让我们想象一下，我的问题不受存储的限制，而是受计算所需的CPU和RAM的限制，所以存储工人返回的结果的空间太小并不存在问题。（也就是说，我正在做一些类似模拟的事情，我需要在较小的机器上生成很多由数据库中的值播种的东西，但在它们返回到源机器/数据库之前，这些东西会减少。）
我知道Hadoop是大数据标准，但Celery看起来也得到了很好的支持；我很感激它不是java（python必须用于hadoop的流式API让我感到不舒服），所以我倾向于使用Celery选项。
-
它们的相同之处在于，两个都可以解决您描述的问题（map reduce）。它们的不同之处在于，Hadoop的构建完全是为了解决该用例，而Celey/RabbitMQ的构建是为了使用消息传递在不同节点上促进任务执行。Celery还支持不同的用例。
-
Hadoop通过拥有一个大型且特殊的文件系统来解决映射减少问题，映射器从该文件系统中获取数据，将其发送到一组映射节点，并将其减少到该文件系统。这样做的好处是速度非常快。缺点是它只对基于文本的数据输入进行操作，Python并不是真正受支持的，如果你不能做（稍微）不同的用例。Celery是一个基于消息的任务执行器。在其中，您可以定义任务，并在工作流中将它们分组在一起（可以是地图缩减工作流）。它的优点是基于python，可以在自定义工作流中将任务缝合在一起。缺点是它依赖于单个代理/结果后端及其设置时间。
-
因此，如果您有几个Gb的日志文件，并且不想用Java编写，并且有一些专门用于运行Hadoop的服务器可用，请使用它。如果您希望在运行工作流任务时具有灵活性，请使用Celery。或
-
是的！其中一家公司的一个新项目帮助创建了RabbitMQ（和其他公司）使用的消息传递协议AMQP。它被称为ZeroMQ，它将分布式消息传递/执行提升到了下一个级别，与Celery相比，它在抽象上奇怪地下降了一个级别。它定义了可以通过各种方式链接在一起的套接字，以在节点之间创建消息传递链接。你想用这些信息做什么都由你自己写。尽管这听起来像是"套接字周围的薄包装器有什么好处"，但它实际上处于正确的抽象级别。现在，在我们公司，我们正在考虑所有的芹菜消息，并使用ZeroMQ进行重建。我们发现Celery对如何执行任务过于固执己见，而设置/配置通常是一种痛苦。此外，中间那个必须处理所有流量的代理也成为了很大的瓶颈。
简历：
- 在一本书中用尽可能少的编程和大量的设置/配置时间来计算"the"的出现次数：Hadoop
- 创建原子任务，并能够让它们一起工作，而不需要太多编程和大量的设置/配置时间：Celery
- 完全控制如何处理消息以及如何在几乎没有设置/配置时间的情况下对其进行编程：ZeroMQ
- 在没有设置/配置时间的情况下感到痛苦：套接字