现在，我们手里有数据，大量的数据。我们的存储中有区块、文件和对象。我们的数据库中有表、键值以及图形。还有越来越多涌进来的媒体、机器数据和事件流。

成为企业数据架构师一定会很有趣，因为要找出如何最好地利用所有这些潜在的情报，而不会错过或者丢掉哪怕每一字节。

Spark等大数据平台可帮助您快速处理这些数据，并将传统的业务数据中心应用程序与高级的分析功能融合在一起。如果您尚未在您的数据中心生产端部署Spark，部署也是迟早的事。毕竟不愿意或不能将大数据平台加入到日常业务流程情报的组织，很快就会发现自己在竞争中落后的事实。

Spark具有分布式内存处理架构，以及提供专家级的机器学习和类SQL数据结构的本地库，均为提升大型数据集性能而设计的。即使已经拥有如此迅速的发展，市场占有率的竞争和对更大数据量的需求使得Spark的性能加速话题变得更加炙手可热。您可以在大数据展会中看到这种趋势，例如最近在波士顿火爆异常的Spark Summit，似乎每个供应商都在兜售自己有关加速Spark的方法。

如果Spark已经在内存中运行并扩展到大型群集的节点，那么如何更快地处理比以往更多的数据？我们注意到从以下五个方面可以考虑进行加速：

1.内存改进。Spark可以使用重内存的节点的分布式池。当然，如何进行内存管理工作仍然存在改进空间，例如分片和缓存——例如每个节点可以填充多少内存，以及多少集群可以有效扩展。最新版本的Spark使用原生Tungsten非堆内存管理方式，例如紧凑型数据编码，同时优化Catalyst查询规划器，以同时有效减少执行时间和内存需求。根据业界领先的Spark供应商Databricks的说法，我们将继续看到以后的Spark版本主动追求更高的性能。

2.本地流处理数据。大数据行业最热门的话题是如何处理流数据。现如今真的几乎可以做到在数据到达的同时对其进行处理了。然而实时流处理数据集需要特殊处理，这给管理带来了很大的挑战。在过去，这通常需要复杂的管理工作流程和消息传递以及队列算法；有时候答案是使用分离的基础架构集群来运行不同的软件堆栈。如今，我们看到流数据支持融合到和更加友好的范式中。例如，Spark 2.0现在原生支持结构化的流处理，可以将新型流处理数据源轻松地折叠到现存的有利开发人员的平台之中。

3.大数据的统一。像MapR、Alluxio和Splice Machine这样的产品旨在创建统一的数据源、数据库以及存储，这些数据源、数据库和存储可以吸收许多不同类型的数据，并以统一的方式向如Spark的下游应用程序提供服务。上述提到的一些工具将业务数据与其他大型数据类型进行融合，并提供对所有数据的SQL访问。其他工具将流数据合并到历史数据集中，提供一致的数据API。无论采用哪种方式，上游集成数据源可以帮助Spark应用程序更加集中和高效地处理数据。

4.硬件加速。当然，使用专门的硬件有很多加速方法。尽管许多人宁愿坚持使用严格的普通商品服务器基础设施，但显而易见的是，利用大量图形处理单元（GPU）或定制化的现场可编程门阵列，例如来自Kinetica或BigStream的产品，可极大地加速Spark的处理。除了密集计算方法，GPU卡中包含的视频RAM还提供另一级的内存；系统可以善加利用这部分内存，来加速Spark的特定功能。

5.专用平台。有一些极具吸引力的非商用平台和设备专门用于为Spark提供高端性能。这些供应商产品可能会收敛高性能计算、网络和存储方面的组件，使用密集的服务器端非易失性存储器的闪存，甚至是采用新型低级内存管理专门应用于Spark的加速。例如Cray Spark平台、Oracle Sparc服务器、DriveScale机架和Iguaz.io的设备。

在某些情况下，其他产品和开源项目可提供比Spark更佳的性能。例如，Apache Flink是为低延迟流处理所设计的。

然而，一般来说，Spark架构有足够的发展空间，至少在未来几年内仍然值得选择的平台。鉴于市场上对加速的努力，没有理由不继续推进Spark的应用。