Performance Hadoop-CPU密集型应用程序-小数据

Hadoop是CPU密集型作业的合适解决方案，并且需要处理500 MB左右的小文件吗？我已经读到Hadoop旨在处理所谓的大数据，我想知道它如何处理少量数据（但CPU密集型工作负载）

---

我主要想知道这个场景是否有更好的方法，或者我应该坚持使用Hadoop。

Hadoop是一个分布式计算框架，提出了一个MapReduce引擎。如果您可以使用此范例（或Hadoop模块支持的任何其他范例）来表达可并行化的cpu密集型应用程序，那么您可以利用Hadoop。 Hadoop计算的一个经典例子是Pi的计算，它不需要任何输入数据。正如您将看到的，由于Hadoop，yahoo成功地确定了pi的两个四分之一位数

然而，Hadoop确实是专门用于大数据的，因为它是为此目的而开发的。例如，您处理了一个设计用于包含大型文件的文件系统。这些巨大的文件通过大量的节点被分块成许多块。为了确保数据完整性，必须将每个块复制到其他节点

最后，我想说，如果您已经处理了Hadoop集群，您可能希望利用它。

---

如果不是这样的话，虽然我不能推荐任何东西，因为我不知道您到底需要什么，但我认为您可以找到比Hadoop更多的轻量级框架。

很多公司都在转向Spark，我个人认为这是并行处理的未来

听起来您想要做的是在多个节点上使用多个CPU。为此，您应该使用专门为这个问题设计的可伸缩语言——换句话说，Scala。与hadoop相比，将Scala与Spark一起使用要容易得多，速度也快得多

如果您无法访问群集，那么无论如何都可以使用Spark，以便将来更轻松地使用它。或者只需在Scala中使用

.par

，这将并行化您的代码并使用本地计算机上的所有CPU

---

最后，Hadoop确实是面向大数据的，而Spark实际上只是一个非常通用的MPP框架。

您正面临着我们为数据规范化所做的计算问题。这需要在廉价的硬件和软件上进行易于使用的并行处理，而不是进行传统并行处理的所有特殊编程。Hadoop诞生于计算相对简单的大规模分布式数据复制。事实上，仍在分发的测试应用程序WordCount过于简单。这是因为Hadoop的起源是为了处理大量的数据和搜索的并发处理，之后又加入了“大数据”分析运动，试图找到更通用的业务用例。因此，Hadoop的通用形式并不是针对您和我们的用例。但是，Hadoop确实提供了对具有自定义和复杂编程逻辑的“小数据”进行廉价、简单、快速并行处理的关键功能

---

事实上，我们已经调整Hadoop来实现这一点。我们有一个专门构建的硬件环境PSIKLOPS，它对小型集群（1-10）节点非常强大，具有足够的功耗，可以低成本运行4-20个并行作业。2014年8月初，我们将在题为“技术实验室与Cloudera联合”的内部分析的一系列网络广播中展示这一点。我们将此功能视为像您这样的人的关键促成因素。以我们将展示的方式使用Hadoop并不需要PSIKLOPS，但它被配置为最大限度地易于使用，以启动多个自定义Java并发容器

如果您可以将处理任务框架化为“MapReduce”算法，那么Hadoop就可以了。否则，您应该首先尝试找到并行化任务的算法。第二，选择任何适合的工具。实际上，我有一个适用于我的应用程序的Hadoop解决方案，但我正在寻找更好的方法（如果存在）。我实际上想从一个小文件（约500 MB）中读取数据，并对每行进行一些CPU密集型计算。我已经在Amazon Elastic MapReduce集群上使用Hadoop，但我担心部署和分发开销可能会超过我所能接受的时间。如你所说，如果Spark比Hadoop快得多，我会认真考虑在我的项目中使用它。我也读过有关Storm项目的文章，但由于我的应用程序根本不需要实时处理，我想它可能对我的目的毫无用处。这并不能回答实际问题。Spark可能是件好事，Scala也是，但问题非常具体@Frunsi的问题是“Hadoop是一个合适的解决方案吗…”我的回答基本上是“是的，但是spark会是一个更好的解决方案”怎么不回答这个问题？！？！这显然是一个开放式的问题，有一个稍微开放的答案。请收回你的否决票。别忘了“MapReduce”只是一个算法，它不是终点，它从来都不是，好吧，它只是一个快速而肮脏的架构，解决一个实际的算法。然而，MapReduce从来都不是，也永远不会是您问题的解决方案。就连谷歌最近也意识到了这一点：我已经在亚马逊的弹性MapReduce基础设施中使用了Hadoop方法，但由于我正处于项目的早期阶段，所以选择正确的方法对我来说很重要。我的目标是生成一个可扩展的基础架构，使系统能够将其资源主要集中在计算时间上，而不是部署和分发时间上。