选型的目光瞄准Spark

在Spark社区，众多参与者已经在为Spark 1.4.0(RC2)推出的特性投票了。我之遗憾，在于我们暂时还未参与这项工程的创造工作；我之欣喜，在于我们可以毫无顾虑地借用它；最后，得以帮助这座大集市在人声鼎沸中彰显不羁的个性。

♦ ♦

在大数据分析平台，我们选择了Spark。这源于它的效率，它的快速演化，更在于我对它的偏爱。在理性挑选的基础上，感情的抉择成了火箭发射时最后一级的助力。

从最早对0.9版本的使用到现在的1.3.1，我亲眼所见Spark迅猛的发展。它发力于通用与性能两大亮点之上，使得自己在众多大数据分析平台中卓尔不群，在迅速得到众多重量级客户的拥抱之后，它开始快速奔跑在大数据分析领域的前沿。

Spark开源社区极为活跃，它的每个版本发布都是在Databricks的规划下借助着社区力量开始推动的。在Spark 1.3.0版本推出时，Spark SQL与DataFrame成为了非常重要的一块拼图，它们的出现让Spark的通用性变得名符其实。机器学习的库虽然还待完善和优化，但诸多基本的算法已经开始得到了商业应用。Spark Streaming还是一如既往的稳健，在Spark的影响力下，开始渐渐占据原来属于Storm的市场。至于图运算，GraphX也开始初露峥嵘。

正是这些不停止的发展，使得我们在基于Spark进行数据分析时，既可以享受不断推出的新特性的福利，还可以让我们使用的技术不再乏味，总能找到新鲜的兴趣点。当然，这种迫使我们前进的压力，也会成为我们研发团队高效融合的催化剂。这是我乐意看到的。

我在考量Spark在自己产品中的运用时，一方面是因为看到了Spark SQL与Data Frame与目前我们业务的高度契合，另一方面则是从性能角度做出的权衡。单以Spark SQL来说，比较Shark、HIVE，得益于Catalyst优化器的引入，性能已有极大提升。而来自Databricks官方博客上对Tungsten项目的介绍，使得我对未来产品的前景报以极大自信。文中提到：

Tungsten项目将是Spark自诞生以来内核级别的最大改动，以大幅度提升Spark应用程序的内存和CPU利用率为目标，旨在最大程度上压榨新时代硬件性能。

显然，即使在我们对自己产品不做任何性能优化的前提下，Databricks的工程师也会间接地帮助我们解决这个问题。似乎，我们只需要做的是跟进Spark前进的步伐即可。

当然，从架构上，我们还可以做到在整体性能提升的自我把控。例如，我们在Spark之上一层引入Redis分布式缓存，从而减少对存储分析数据的服务器IO；例如，我们可以对存储层做一些改进，在Hadoop HDFS与Spark之间引入Tachyon会是一个不错的选择。

倘若引入Tachyon作为内存中的文件存储，则选择Parquet而非传统的关系型数据库也自有其合理之处。Parquet在数据压缩、列式数据展现等方面具有非常大的优势，Spark SQL对它的支持也非常合理到位。DataFrame起到了统一数据源接口的作用，使得我们在内存中对数据进行分析和处理时，几乎可以忽略数据源的区别。而在保存诸如Parquet文件时，又能合理地按照某些关键字段对数据文件进行分区。

性能的优化是无止境的，我们希望将Spark用到极致，同时又能在我们自己的应用场景中找到合理的平衡点。架构必须具有一定的前瞻性，Spark对我们产品的支撑使得这种前瞻成为了可能。