实时商务智能这一设想早已算不得什么新生事物（早在2006年维基百科中就呈现了关于这一概念的页面）。但是虽然人们多年来一向在对此类计划进行讨论，我却发现许多企业实践上没有就此规划出清晰开展思路、乃至没能真实意识到其间包含的巨大效益。

为什么会这样？一大原因在于现在商场上的实时商务智能与剖析东西依然十分有限。传统数据仓库环境针对的首要是批量处理流程，这类计划要么推迟极高、要么本钱惊人——当然，也或许二者兼具。

但是现已有多款强壮并且易于运用的开源渠道开端鼓起，欲彻底改变现在的晦气局势。其间最值得重视的两大项目分别为Apache Storm与Apache Spark，它们都能为广阔潜在用户供给杰出的实时处理才能。两套计划都归归于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调度程序则依据详细拓扑装备将处理使命分发给集群傍边的各个作业节点。

咱们可以将拓扑结构大致视为MapReduce在Hadoop傍边所扮演的人物，只不过Storm的重视要点放在了实时、以流为根底的处理机制身上，因而其拓扑结构默许永久运转或许说直到手动间断。一旦拓扑流程发动，挟带着数据的流就会不断涌入体系并将数据交付给栓（而数据仍将在各栓之间循流程持续传递），而这也正是整个核算使命的首要完结办法。跟着处理流程的推动，一个或许多个栓会把数据写入至数据库或许文件体系傍边，并向另一套外部体系宣布音讯或许将处理取得的核算结果供给给用户。

Storm生态体系的一大优势在于其具有丰厚的流类型组合，足以从任何类型的来历处获取数据。虽然咱们也可以针对某些具有高度特别性的应用程序编写定制化流，但基本上咱们总能从巨大的现有源类型中找到合适需求的计划——从Twitter流API到Apache Kafka再到JMS broker，全部尽皆涵盖于其间。

适配器的存在使其可以轻松与HDFS文件体系进行集成，这意味着Storm可以在必要时与Hadoop间完结互操作。Storm的另一大优势在于它对多言语编程办法的支撑才能。虽然Storm本身依据Clojure且运转在JVM之上，其流与栓依然可以经过简直一切言语进行编写，其间包含那些可以充沛发挥在规范输入/输出根底上运用JSON、并由此完结组件间通信协议优势的非JVM言语。

整体而言，Storm是一套***可扩展才能、快速惊人且具有容错才能的开源散布核算体系，其高度专心于流处理范畴。Storm在事情处理与增量核算方面体现杰出，可以以实时办法依据不断改变的参数对数据流进行处理。虽然Storm一起供给原语以完结通用性散布RPC并在理论上可以被用于任何散布式核算使命的组成部分，但其最为底子的优势依然体现在事情流处理方面。

Spark:适用于全部的散布式处理计划

作为另一个专门面向实时散布式核算使命的项目，Spark开始由加州大学伯克利分校的APMLab实验室所打造，然后又加入到Apache孵化器项目并终究于2014年2月成为其间的***项目之一。与Storm相似，Spark也支撑面向流的处理机制，不过这是一套更具泛用性的散布式核算渠道。

有鉴于此，咱们无妨将Spark视为Hadoop傍边一套足以替代MapReduce的潜在备选计划——二者的差异在于，Spark可以运转在现有Hadoop集群之上，但需求依赖于YARN关于资源的调度才能。除了Hadoop YARN之外，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或许Python API以实时办法快速树立起原型及探究性数据剖析机制。在运用这套交互shell时，咱们会很快发现Spark与Storm之间的另一大差异地点：Spark显着体现出一种偏“功用”的取向，在这里大部分API运用都是由面向原始操作的连续性办法调用来完结的——这与Storm遵从的形式彻底不同，后者更倾向于经过创立类与完结接口来完结此类使命。先不管两种计划孰优孰劣，单单是风格的巨大差异现已足以协助咱们决议哪款体系更合适自己的需求了。

与Storm相似，Spark在规划傍边相同高度重视大规划可扩展才能，并且Spark团队现在现已具有一份大型用户文档、其间列出的体系计划都运转着包含不计其数个节点的出产性集群。除此之外，Spark还在最近的2014年Daytona GraySort比赛傍边取得了优胜，成为现在承载100TB等级数据作业负载的***挑选。Spark团队还保留了多份文档，其间记载着Spark ETL怎么担任数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等等。而这正是开源机制的***亮点地点。

不管咱们挑选哪一套计划，这些东西的存在都实在标明实时商务智能商场的游戏规矩现已发生了改变。从前只能为少量精英所把握的强壮选项现在现已进入寻常百姓家——或许说，至少适用于大都中等规划或许大型企业。不要浪费资源，充沛享用由此带来的便当吧。

英文：http://www.infoworld.com/article/2854894/application-development/Spark-and-Storm-for-real-time-computation.html