虽然Spark自身还有待完善，但该数据处理引擎的使用正在快速增长。

例如，软件供应商Xactly Corp.正使用Spark来运行一个批处理和实时应用程序的组合。该公司的CTO兼工程部高级副总裁Ron Rasmussen这样认为，虽然Spark的高速性能让它成为了一款有价值的处理工具，但大数据技术的一些内容仍需改进。

Rasmussen说：“它还不成熟，但当你把它跟运行事务级别的Oracle进行比较的时候，它还是不能与之相提并论的。”例如，Xactly已经不得不对在内存使用中的特质进行故障排除，有时会转而向Hadoop的供应商MapR Technologies Inc.的技术支持人员寻求帮助。而且对于Rasmussen的团队来说，监控Spark查询有时就如同一项猜谜游戏。“很难知道哪些东西应该花费很长的时间，”他说。

由于在批处理应用性能方面的优势，Spark正在逐渐将MapReduce边缘化，而MapReduce是Hadoop最初的编程环境和执行引擎。但在MapReduce的某些功能类型上，Spark并不能完全符合标准，在线分析平台供应商Quaero的软件开发工程师主管Nitin Kak说道。在与Spark协作的过程中，Kak必须人工提供处理工作所需内存和CPU核心的数量，而对于MapReduce来说这一工作可以自动完成。

尽管如此，位于Charlotte, N.C.的Quaero已经建立了一套基于Spark的身份解析引擎来在点击流记录，在线事务和其他页面活动中寻找匹配数据元素来精确定位单个消费者以将网站变得个性化并进行有针对性的营销。该解析引擎的两个批处理应用程序模块之一是从一开始就为Spark而开发的；而另一个最初则是在MapReduce中编写的，Quaero将该项目在2015年晚些时候投入了生产，但在去年春季的第二个发布版本进行了重制以在Spark中运行。

从好的方面说，Kak表示比起用MapReduce，用Scala编程语言可以更快地编写Spark代码。Spark用户同样能够在内存中保存数据“并能重复进行，”他补充道。

性能方面对第二个模块进行了重写，在一个对大约有5亿条数据记录的试运行中削减了处理时间，而这些数据存储在一个基于Cloudera公司的Hadoop分布式系统的集群中，其处理时间从使用MapReduce的5个小时缩短到用Spark的90分钟。这些身份解析工作包括“很多的重复算法，数据匹配迭代和循环，” Dan Smith说，他是Quaero的平台开发副总。“对于一个偏重于算法，数学和计算的工作负载来说，Spark的效果非常好。”

Spark在过去所缺少的内容

Xactly为管理激励补偿计划销售云软件，它同样没有去等待该处理引擎进一步成熟才去加大对Spark的使用力度。

San Jose公司在2015年十月将一对基于Spark的应用程序投入生产使用：一个批处理应用程序用于给销售团队成员的订单打分，而这些成员是理应获得佣金的，另一个实时工具可以将那些为补偿经理的员工支出数据自定义视图聚合在一起。它在去年春季增加了第三个应用程序：一个为聚合销售补偿数据而提取，转换和加载（ETL）任务的批处理应用程序，而这些数据来自于客户并输入一个Oracle关系型数据库用于分析和报告。

Rasmussen说Xactly在Oracle上运行它自己的事务系统，但使用的是Spark和一个基于MapR的Hadoop集群的组合来将某些需要的批处理卸载到一个低成本平台。而对于使用大数据技术的订阅费用只是每年公司在Oracle软件上必须支付的支持费用的一小部分，他说。

此外，打分程序现在可以在销售订单数量正在处理的情况下进行线性销售。在Oracle系统中，随着数据量的增加性能会下降。“当前只需花费数分钟的任务则可能会花费数小时或是不会完成，” Rasmussen说，增加了该应用之后，打分记录会被送回至Oracle系统以供事务使用。

另一方面，该支付应用在Hadoop和Spark系统中是独立的。它创造了所谓的支付曲线，它为企业的销售代表们标绘出了销售配额和佣金数额，而这些数据是高度可变的，因为不同的激励和佣金比例会内置在进补偿计划中。Rasmussen说他的团队使用MapReduce把在Hadoop的伙伴HBase数据库中的支出基准数据进行聚合。但Spark则飞速计算着支出曲线，这是以那些拿佣金的经理们在开启查询时所设立的过滤集为基础的。

鉴于Spark正在快速更新，用户所面对的功能不足和技术问题取决于他们所运行的版本不同而不同，而这反过来或许也取决于他们是否正在从供应商获得该项技术，如果是，那么是哪家供应商呢？那些支持Spark的供应商在他们所提供的产品版本上并不总是因循守旧，这就可以把一些正等待技术改进的用户留给那些已经利用了改进技术的企业。

正确看待Spark的成熟度

Tony Baer是位于纽约的一家名为Ovum公司的分析师，他说由于Spark相对较新，因此对于其成熟度方面的一些观点是必要的。该处理引擎创建于2009年并在第二年开放了源码，但在2013年年中之前，还没有将其设立为Apache Software Foundation项目。“你必须记住当我们在谈论所有这些缺点的时候，该技术的出现实际上还不到五年时间，”Baer说，它在不断地增强，这方面的速度是惊人的。”

Celtra是一家位于波士顿为设计在线显示和视频广告提供平台的公司，它是Spark最早的采用者之一。它使用的Spark是0.5版的基本开源软件，该版本是在2012年Apache参与之前发布的。Celtra接下来成了Databricks 公司基于云的Spark实现的最早测试用户，而该产品在2015年一月开始投入生产。

Spark在功能和稳定性上与其早期相比都是有着极大的不同，Celtra分析部门的工程主管Grega Kespret说。

“我们在Spark的开始阶段有很多问题。我们花费了大量时间对其进行调试和优化，” Kespret说，他还特别指出在处理工作中的内存不足错误。“如今，Spark对我们来说相当稳定，我们看不到太多出错的现象发生；或是有错误出现，我们也知道如何进行修复。”有关Spark的技术归档同样得到了很大改进，他补充道。

Celtra继续使用开源的Spark和Databricks的版本——前者用于对数据进行ETL转换，而后者主要是作为公司的数据分析师的分析平台。而其内置了Amazon Web Services云的架构并不包含Hadoop。Kespret说，相反的是，Spark的ETL工作要处理超过20亿的数据点，这些数据点是每天在Amazon Simple Storage Service（一款MySQL操作数据存储）和一款Celtra于2016年早期部署的来自Snowflake Computing Inc.的云数据仓库的广告互动和其他可追踪事件上捕获的。

开源技术作为Spark的替代品呼之欲出

虽然Spark并不完全成熟，但它已经到了这样一个阶段，即更新的开源技术作为其替代品正呼之欲出，就像Spark的开发人员试图用它来取代MapReduce一样。例如，Apache Flink是一款诞生于德国的流处理引擎；Flink的支持者声称它能够比Spark更快地处理高强负荷的数据流，它使用微批处理方法将组合在一起的小批量数据进行分流并进行快速连续处理。

独立咨询师Thomas Dinsmore表示Flink与Spark不同，Flink是完全支持纯数据流的。“但微批处理并不坏，而且实际情况是很少有分析应用程序要求比Spark半秒更少的延时，” Dinsmore说。他还说，总体上他认为Spark是一款集流处理，机器学习，ETL和其他用途于一身的大数据处理和分析平台。

Novantas公司对Spark的使用有着确定而宏大的计划。这家位于纽约的公司为金融机构提供分析服务和工具，它正在使用基于Cloudera的Hadoop和Spark系统来运行一款称为MetricScape的应用程序，该应用程序是2016年早期为一家银行构建的。Kaushik Deka是Novantas Solutions技术部门的CTO和工程主管，他说该应用程序对客户和金融数据指标来说有点像是一个图书管理员，它提供的治理层可用于追踪数据沿袭，定义和依赖关系。

Deka说该应用是要帮助数据科学家将相关的数据集集中在一起用于分析。在最初用户的情况下，它包括查看客户账户历史，过去营销活动结果和其他数据以便根据数百万银行客户对已计划的优惠可能的反应来进行划分。Spark进行批量ETL处理来为MetricScape用户创建底层数据模型并对数据集进行分区。Deka说，Novantas没有采用MapReduce是因为Spark拥有更快的性能并且支持Scala和Python语言。

Novantas还在概念上致力于第二款应用程序的开发，它会将Hadoop和Spark置于自动规则引擎的核心，而该引擎旨在为银行员工实时提供分析信息。例如，对于那些寻求降低抵押贷款利率的客户，银行经理可以通过客户与银行总的关系来快速获得利率推荐并加以处理，Deka说。

Spark需要进一步发展以能够对成千上万的银行分支进行处理，他补充说。虽然他对该处理引擎充满了信心。“但我并不能确定它现在就为那些用例做好了准备，不过我认为它会做到的。”