Hadoop 是小数据的好解决方案吗？ [关闭]答案

【问题标题】：Is Hadoop a good solution for small data? [closed]Hadoop 是小数据的好解决方案吗？ [关闭]
【发布时间】：2013-09-18 12:25:54
【问题描述】：

我们在 MongoDB 中有一组数据，我们正在减少地图（两次），我们现在将使用 Mongo 的地图减少，但我正在考虑如何在未来扩展和提高性能，并且正在考虑关于 Hadoop。

我读到的关于 Hadoop 的大部分内容都是关于大数据、TB 级的内容，而当我们要处理兆字节、10 到 100 万条记录时。（虽然其中可能有许多同时运行，所以虽然单个任务很小，但总体可能很大）。

我们真的希望从小数据中获得疯狂的性能，而不是让大数据成为可能。即在 MongoDB 中获取 map reduce 结果需要 10 秒，而在 Hadoop 中需要几秒或亚秒。

这可能吗？
Hadoop 适合这个吗？
如果没有，还有哪些其他技术可以实现这一点？

这是需要的确切问题的详细信息以及我迄今为止的解决方案，可以在这个问题中找到：Linear funnel from a collection of events with MongoDB aggregation, is it possible?

【问题讨论】：

我不打算回答这个问题，因为我不了解 Hadoop，但是阅读这个问题的答案和链接的问题，我想知道是否考虑到所涉及的数据的大小，你可能会从将数据存储在内存中的自定义应用程序中获得更好的解决方案。计算方式不同，但我有类似的需求：最大速度。我们找到的唯一解决方案是更多 RAM！

标签： mongodb hadoop mapreduce

【解决方案1】：

这可能吗？

没有。无论您的数据多小，在运行 MR 作业时总会有一些初始延迟，这是因为很多事情发生在幕后，比如检查输入/输出路径、拆分创建、地图创建等。这是不可避免的。

Hadoop 是否适合这种情况？

没有。您不能指望 Hadoop 能在纳秒或几毫秒内为您提供结果。

如果不是，还有哪些其他技术可以实现这一点？

如果您需要一些真正快速且扩展性更好的东西，请查看 Storm。

【讨论】：

当我说亚秒时，我的意思是略低于。如果我们能在 3 秒内得到结果，那将是一个巨大的胜利。
3s还是太低了..

【解决方案2】：

我读到的关于 Hadoop 的大部分内容都是关于大数据、TB 级的东西，而我们要处理的是兆字节、10 到 10 万条记录。

使 hadoop 速度更快的原因之一是它使用 Map Reduce 的集群能力，当然，这些东西只真正适用于“大数据”（无论这意味着什么现在）。

事实上，map reduce 通常比小数据上的聚合框架慢，因为实际运行平均 map reduce 需要多长时间。

Map reduce 的真正设计目的不是为了您所做的事情。

您可以考虑将数据存储在传统数据库中并使用该数据库聚合框架，即 SQL 或 MongoDB。

【讨论】：

Map reduce 是我能够执行所需逻辑的唯一方法，复杂的因素是记录（在本例中为事件）发生的顺序。不是我以前必须做的事情，也不是我能找到任何其他人写的东西（这并不是说他们不是）。它存储在 mongo 中并尽我所能尝试我未能将逻辑放入聚合框架中。原问题详情在这里：stackoverflow.com/questions/18793035/…

【解决方案3】：

Hadoop 无法满足您的要求。首先是基础设施要求及其管理。如果您的数据以 MB 为单位，则在 hadoop 上运行 map-reduce 的成本将比在 Mongo 或其他类似技术中更高。

此外，我想建议您扩展您现有的 mongoDB 基础架构。 Hadoop 技术无法轻松实现查询和基于文档的灵活性（如简单的索引和数据检索）。

【讨论】：

由于我对 MongoDB 的问题是直线速度（MongoDB 的 map reduce 未分发），因此扩展 MongoDB 基础设施无济于事。
另外，如上编辑，任何一项工作的数据都会很小，但可能有很多。

【解决方案4】：

Hadoop“总体上”正朝着更低延迟的处理方向发展，例如通过Tez 之类的项目。还有类似 hadoop 的替代品，比如Spark。

但对于事件处理，通常这意味着 Storm，未来可能已经到来，请参阅 Storm and Hadoop: Convergence of Big-Data and Low-Latency Processing（另请参阅 slideshare from Hadoop Summit）。

Hadoop 是一个庞大的生态系统。旧版 (1.0)、新版 (1.3) 和最新版 (2.0 及更高版本) 在功能上存在巨大差异。其中一些技术能否取代 Mongo 自己的 M/R？我当然这么认为。您的问题可以拆分为许多并行任务（这实际上对我来说并不清楚）吗？然后在 Spark/YARN/Tez 之间的某个地方，有一个解决方案可以更快在你投入更多硬件时运行。

当然，对于首先在一个主机 RAM 中的工作集，总会有一个 SMP RDBMS 将围绕集群运行......

【讨论】：