选型的目光瞄准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对我们产品的支撑使得这种前瞻成为了可能。

2015-05-27 19:5628Spark