使用消息队列 VS Map/Reduce 的分布式计算答案

【问题标题】：Distributed computing using message queue VS Map/Reduce使用消息队列 VS Map/Reduce 的分布式计算
【发布时间】：2012-05-02 23:11:28
【问题描述】：

上下文：

我们正在考虑采用符合 AMQP 的解决方案来计算每天 90 GB 的恒定实时数据流。我们想要实现的是实时统计数据，或多或少，基于我们观察到的所有或某些指标的组合。考虑的策略是在队列中发送数据并让工作进程处理数据的增量，将数据作为原始数据的聚合发送回队列。

观察：

对我来说，这看起来像是 Hadoop 之类的工作，但提出了一些担忧（和防护），主要是关于速度。我没有时间对两者进行基准测试，但我们希望通过队列（在 10~100 mb/s 附近的任何地方）抽取大量数据。我仍然认为它看起来像是分布式计算系统的工作，而且我也觉得队列解决方案的扩展性会比分布式计算解决方案差。

问题：

简单地说，我说的对吗？我读过一些关于 Hadoop + HDFS 的文章，我正在考虑使用另一个 FS，比如 Lustre 之类的东西，来规避 NodeName SPOF，并使用某种解决方案来对任何类型的节点故障有某种容忍度整个集群。

【问题讨论】：

看来您的问题是：我应该使用现有的 map-reduce 框架还是自己编写一个。答案是：取决于你的目标。如果您需要一些可以正常工作的东西（即使涉及一些学习），请使用现有的。如果你想创造一些新的东西 - 写你自己的。
是的，我不介意制作一个或使用一个，我真的在寻找最好的方法来实时剔除每天几十 GB 的数据以从数据中提取实时统计数据.我们目前正在研究一个消息队列来实现它，但我认为使用 Map/Reduce 的分布式计算可能更适合我这样做。
那么，Hadoop 是适合您的工具。当然，您需要将数据复制到 HDFS（但每天 90gb 并不多）。

标签： hadoop mapreduce amqp hdfs

【解决方案1】：

当您需要容错、良好的平衡等时，编写自己的“分布式环境”解决方案真的很困难。如果您需要近乎实时的 map/reduce，您应该查看storm，这是 twitter 用于他们巨大的数据需求。它不如 hadoop 复杂，并且在消耗队列类型输入方面更好（在我看来）。

另外，如果你决定在 hadoop 上分析你的数据，不要太担心名称节点的 SPOF，有some ways 可以避免它。

【讨论】：

真正有趣的阅读/谈话！对于 Hadoop hdfs spof，我正在考虑使用分布式文件系统（有些显然与 hadoop 兼容）。这可行吗？
hadoop 主要用于批处理操作，因此无法满足您的“实时”要求。我每周/每天/每小时使用 hadoop 对相对大的数据（~500gb）进行复杂的操作。对于近乎实时的操作，我更喜欢storm + kafka。