首先，dannyhow是对的-这不是实时处理的意义所在。有一本好书http://www.manning.com/marz/ 这说明了很多关于lambda建筑。
你提到的这两种方式有着完全不同的目的，并且与“任务”一词的定义有关。例如，spark会把你为他得到的一份工作分成“任务”，但一个任务的结果对你来说是无用的，你仍然需要等待整个工作完成。您可以在同一个数据集上创建小作业，并使用spark的缓存来加速它。但是这样的话，您就不会从分发中获得太多的优势（如果它们必须一个接一个地运行的话）。
文件大吗？它们之间有某种联系吗？如果是的话，我会和斯帕克一起去。如果没有，则为分布式队列。

这在很大程度上取决于你“处理”的性质。此处适用的一些尺寸为：
记录是相互独立的还是需要某种形式的聚合？i、 e：你需要一些数据来配合吗？例如，来自单个用户帐户的所有事务。
你正在处理cpu限制吗？内存受限？文件系统绑定？
会坚持什么？你将如何坚持下去？
每当您看到新数据时，是否需要重新计算旧数据？
你能丢弃数据吗？
数据是否有序？
预期负荷是多少？
一个好的解决方案将取决于这些问题的答案（可能还有其他我忘记的问题）。例如：
如果计算很简单，但是存储和检索是主要考虑的问题，那么您应该考虑分布式数据库，而不是您的任何一个选择。
最好的方法可能是将内容记录到一个分布式文件系统（如hdfs）中，然后使用spark运行批处理计算（通常应该比普通的hadoop更好）。
也许不是，你可以使用spark流来处理你收到的数据。
如果顺序和一致性很重要，那么发布/订阅体系结构可能会更好地为您提供服务，特别是当您的负载可能超过两台服务器所能处理的负载时，但是在高峰和慢速时段，您的工作人员可以赶上。
因此，“如何选择？”的答案是“通过仔细研究特定问题的约束条件，估计系统的负载需求，并选择与之匹配的解决方案”。所有这些解决方案和框架都支配着其他解决方案和框架，这就是为什么它们都是活跃的。选择完全取决于你愿意/能够做出的权衡。
希望有帮助。