实时商业智能的想法并不是什么新鲜事物（早在2006年维基百科就出现了关于这个概念的页面）。但是，虽然多年来人们一直在谈论这些选择，但我发现许多公司并没有真正规划他们的前进方向，甚至没有真正意识到巨大的好处。为什么？原因之一是目前市场上的实时商业智能和分析工具仍然非常有限。传统的数据仓库环境主要针对批处理过程，这可能会导致极度延迟或成本过高，或两者兼而有之。然而，一些功能强大且易于使用的开源平台开始出现，试图彻底扭转目前的不利局面。最值得关注的两个项目是ApacheStorm和ApacheSpark，它们都可以为潜在用户提供良好的实时处理能力。这两种解决方案都属于Apache软件基金会，除了部分功能的交集之外，这两种工具也有自己独特的特点和市场定位。Storm：实时处理领域的Hadoop作为一个专门用于事件流处理的分布式计算框架，Storm的诞生可以追溯到最初由BackType——一家2011年被Twitter收购的营销情报公司——开发的项目。Twitter立即将该项目开源并推送到GitHub平台，但Storm最终加入了Apache孵化器计划，并于2014年9月正式成为Apache旗下的顶级项目之一。Storm有时被称为实时的Hadoop加工。Storm项目的描述文档似乎很符合这个标题：“Storm大大简化了对大规模数据流的处理机制，从而在实时处理领域发挥了Hadoop在批处理领域所发挥的重要作用加工。”为了实现上述目标，Storm在设计思路上充分考虑了大规模可扩展性，并采用了一套“故障快速，自动重启”的方案为处理提供容错支持，从而有效地保证了每个元组可以实际处理。Storm项目默认对消息采用“至少一次”的处理覆盖率保证，但用户也可以根据需要实现“仅一次”的处理。Storm项目主要用Clojure编写，既定的设计目标是支持“流”（如输入流）和“塞”（即处理和输出模块）的组合，形成一组有向无环图（DAG）简称））拓扑。Storm的拓扑运行在集群上，Storm调度器根据特定的拓扑配置将处理任务分配给集群中的各个worker节点。你可以粗略地把拓扑看作MapReduce在Hadoop中扮演的角色，但是Storm专注于实时的、基于流的处理机制，所以它的拓扑默认是永远运行或者直到它被手动终止。拓扑过程一旦启动，携带数据的流就会源源不断地涌入系统，将数据传递给插头（同时数据会通过这个过程不断地在插头之间传递），这就是整个的主要实现计算任务方式。随着处理的进行，一个或多个插件将数据写入数据库或文件系统，并向另一套外部系统发送消息或将处理得到的计算结果提供给用户。Storm生态系统的优势之一是其丰富的流类型集，足以从任何类型的源中提取数据。虽然您也可以为一些高度特定的应用程序编写自定义流，但您基本上可以从大量现有源类型中找到解决方案——从Twitter流API到ApacheKafka再到JMS代理，一切都包含在其中。存在适配器以实现与HDFS文件系统的轻松集成，这意味着Storm可以在必要时与Hadoop进行互操作。Storm的另一大优势是它能够支持多语言编程。尽管Storm本身基于Clojure并在JVM上运行，但它的流和插件仍然可以用几乎任何语言编写，包括那些可以利用JSON而不是标准输入/输出的语言，从而实现交互的优势-组件通信协议。非JVM语言。总的来说，Storm是一个开源分布式计算系统，具有极强的可扩展性、惊人的速度和容错能力，高度专注于流处理领域。Storm擅长事件处理和增量计算，可以根据不断变化的参数实时处理数据流。虽然Storm也提供了实现通用分布式RPC的原语，理论上可以作为任何分布式计算任务的一部分，但它最根本的优势还是在事件流处理上。Spark：ADistributedProcessingSolutionforEverything作为另一个致力于实时分布式计算任务的项目，Spark最初由加州大学伯克利分校的APMLab创建，后加入ApacheIncubator项目，最终于2014年2月推出.月成为顶级项目之一。与Storm类似，Spark也支持面向流的处理机制，但它是一个更加通用的分布式计算平台。鉴于此，我们不妨将Spark视为Hadoop替代MapReduce的潜在替代方案——两者的区别在于Spark可以运行在现有的Hadoop集群上，但需要依赖YARN来提供资源调度能力。除了HadoopYARN之外，Spark也可以基于Mesos实现相同的资源调度或者利用自身内置的调度度作为一个独立的集群运行。值得注意的是，如果不将Spark与Hadoop一起使用，在集群之上运行时仍然需要一些网络/分布式文件系统（包括NFS、AFS等），以便每个节点都能真正访问底层数据。Spark项目是用Scala编写的，和Storm一样，支持多语言编程——但Spark提供的特殊API只支持Scala、Java和Python。Spark没有像“流”这样的特殊抽象，但它确实有适配器可以处理存储在各种不同来源的数据——HDFS文件、Cassandra、HBase和S3。Spark项目最大的亮点是它对多处理模式和支持库的支持。没错，Spark当然是支持流模式的，但是这种支持能力只是来源于多个Spark模块中的一个。除了流处理，它的预设模块还支持SQL访问、图形操作和机器学习。Spark还提供了一组极其方便的交互式shell，允许用户使用Scala或PythonAPI快速实时构建原型和探索性数据分析机制。在使用这套交互式shell时，你会很快发现Spark和Storm的另一大区别：Spark清晰地展示了一个“函数式”的导向，其中大部分API的使用都是通过原始的操作导向的，这是通过顺序方法调用来实现的对象-与Storm遵循的模式完全不同，Storm更喜欢创建类并实现接口来完成此类任务。不管这两种解决方案是更好还是更差，单是风格上的巨大差异就足以帮助您决定哪种系统更适合您的需求。与Storm类似，Spark的设计也非常注重大规模可扩展性，Spark团队目前拥有大量用户文档，其中列出了运行具有数万个节点的生产集群的系统场景。此外，Spark还赢得了最近的2014年DaytonaGraySort竞赛，成为承载100TB级数据工作负载的最佳选择。Spark团队还维护着多个文档，记录了SparkETL如何负责多PB级生产工作负载的运行。Spark是一个开源的分布式计算平台，具有快速、优秀、可扩展和极其灵活的特点。它兼容Hadoop和Mesos，支持多种计算模式，包括流、以图形为中心的操作和SQL访问。加上分布式机器学习等等。Spark在扩展方面有着良好的记录，并且与Storm一样，是构建实时分析和商业智能系统的绝佳平台。你会如何选择那么你如何在Storm和Spark之间做出选择呢？如果你的需求主要集中在流处理和CEP（复杂事件处理）处理上，需要从零开始为项目搭建一套有针对性的集群设施，那我个人更倾向于选择Storm——尤其是在现有Storm流的情况下机制完全可以满足您的集成需求。这个结论不是硬性要求或强制规定，但以上因素的存在确实更适合Storm来照顾。另一方面，如果你打算使用现有的Hadoop或Mesos集群，和/或建立的流程需要涉及与图形处理、SQL访问或批处理相关的其他实质性需求，那么Spark值得优先考虑。另一个需要考虑的因素是两个系统支持多种语言的能力。比如你需要使用R语言或者其他Spark原生无法支持的语言编写的代码，那么Storm无疑拥有广泛的语言支持。领导。同理，如果一定要使用交互式shell通过API调用来实现数据探索，那么Spark也能带来Storm所不具备的优秀能力。***，您不妨对这两个平台进行详细的分析再做决定。我建议您从使用这两个平台中的每一个的小型概念验证项目开始——然后运行您自己的基准测试工作负载，在做出最终选择之前亲眼看看两者的工作负载处理能力是否符合预期。当然，您不必选择两者之一。根据您的工作负载、基础设施和具体要求，我们可能会找到Storm和Spark的理想组合——其他可能也发挥作用的工具包括Kafka、Hadoop和Flume。而这正是开源机制的亮点所在。无论您选择哪一组选项，这些工具的存在都真正表明实时BI市场的游戏规则已经改变。曾经只有少数精英才能获得的强大选择现在已经进入了普通人的家中——或者，至少，大多数中型或大型公司。不要浪费资源，充分享受它带来的便利。英文：http://www.infoworld.com/article/2854894/application-development/spark-and-storm-for-real-time-computation.html
