其中包括流、以图形为核心的操作、SQL访问外加分布式机器学习等。Spark的实际扩展记录令人满意，而且与Storm一样堪称构建实时分析与商务智能系统的卓越平台。
?
如何选择
?
如果大家的需求主要集中在流处理与CEP（即复杂事件处理）式处理层面，而且需要从零开始为项目构建一套目标明确的集群设施，那么我个人更倾向于选择Storm——特别是在现有Storm流机制能够确切满足大家集成需求的情况下。这一结论并不属于硬性要求或者强制规则，但上述因素的存在确实更适合由Storm出面打理。
?
在另一方面，如果大家打算使用现有Hadoop或者Mesos集群，而且/或者既定流程需要涉及与图形处理、SQL访问或者批量处理相关的其它实质性要求，那么Spark则值得加以优先考虑。
?
另一个需要考量的因素是两套系统对于多语言的支持能力，举例来说，如果大家需要使用由R语言或者其它Spark无法原生支持的语言所编写的代码，那么Storm无疑在语言支持宽泛性方面占据优势。同理可知，如果大家必须利用交互式shell通过API调用实现数据探索，那么Spark也能带来Storm所不具备的优秀能力。
?
最后，大家可能希望在做出决定前再对两套平台进行一番详尽分析。我建议大家先利用这两套平台各自建立一个小规模概念验证项目——而后运行自己的基准工作负载，借此在最终选择前亲身体验二者的工作负载处理能力是否与预期相一致。
?
当然，大家也不一定非要从二者之中选择其一。根据各位工作负载、基础设施以及具体要求的不同，我们可能会找出一种将Storm与Spark加以结合的理想方案——其它同样可能发挥作用的工具还包括Kafka、Hadoop以及Flume等等。而这正是开源机制的最大亮点所在。
?
无论大家选择哪一套方案，这些工具的存在都切实表明实时商务智能市场的游戏规则已经发生了变化。曾经只能为少数精英所掌握的强大选项如今已经进入寻常百姓家——或者说，至少适用于多数中等规模或者大型企业。不要浪费资源，充分享受由此带来的便利吧。