问将工作分配到多个内核: Hadoop还是Scala的并行集合？

EN

答案取决于以下问题-您的Scala代码是否能够充分利用所有可用的核心。如果你有很好的内在同步性来处理文档的各个部分，或者通过其他方式来实现无锁争用的并行算法，那么“B”就是解决方案。如果是这样的话，配置一个映射器节点，让你的映射器以最好的方式利用内核。

如果您从并行化中获得的收益不是很好，并且向处理中添加更多的线程(核心)并不能以线性的方式提高性能-那么"A“可能是更好的方法。"A“的效率还取决于RAM的大小--每个节点需要足够的ram来支持10个映射器。

我可以怀疑，理想的解决方案可能介于两者之间。因此，我的建议是开发mapper，它将使用的线程数量作为参数，然后进行一些测试，增加每个mapper的线程数量，减少每个节点的mapper数量。

Hadoop提供的不仅仅是并行化。它提供了一个分发工作的平台、一个用于处理并发作业的调度器、一个分布式文件系统、执行分布式reduce的能力以及容错能力。也就是说，它是一个复杂的系统，有时很难使用。

如果您计划让多个用户提交许多不同的作业，则Hadoop是最佳选择(两个选项中的一个)。但是，如果您打算让集群始终通过相同的函数处理文档，那么您可以毫不费力地开发一个使用Scala并行集合和actors进行机器间通信的系统。Scala解决方案将为您提供更多的控制，系统可以实时响应，并且您不必处理大量与您的任务无关的Hadoop配置。

如果您需要对大量数据(大于单个节点所能容纳的数据量)运行不同的作业，那么使用Hadoop。如果你更详细地描述你的需求，我可以给你更多的信息。

更新:一百万是一个相当小的数字。您可能希望进行一些计算，看看在具有并行集合的单台机器上需要多长时间。这样做的好处是开发时间很短！

Hadoop不适合处理大量小文件，但适用于处理少量非常大的文件。有没有什么方法可以在处理文件之前合并它们，或者它们是完全不同的吗？Hadoop本身负责分发和并行性，因此不需要显式地将X个文档发送到Y台机器。而且我认为你不应该仅仅将hadoop作为一种分发机制来使用，这不是它的目的。您应该使用真正的map/reduce，或者为您正在尝试做的任何事情构建自己的系统，但不要试图让hadoop屈从于您的意愿。