任何新技术的引入都会历经陌生到熟悉，从最初新技术带来的惊喜，到后来遇到困难时的一筹莫展和惆怅，再到问题解决后的愉悦，大数据新贵Spark同样不能免俗。大数据Hadoop与Spark架构应用实战》专家钟老师介绍了Spark过程中常见的一些问题

问题一：跑很大的数据集的时候，会遇到org.apache.spark.SparkException: Error communicating with MapOutputTracker

这个错误报得很隐晦，从错误日志看，是Spark集群partition了，但如果观察物理机器的运行情况，会发现磁盘I/O非常高。进一步分析会发现原因是Spark在处理大数据集时的shuffle过程中生成了太多的临时文件，造成了操作系统磁盘I/O负载过大。找到原因后，解决起来就很简单了，设置spark.shuffle.consolidateFiles为true。这个参数在默认的设置中是false的，对于linux的ext4文件系统，建议大家还是默认设置为true吧。Spark官方文档的描述也建议ext4文件系统设置为true来提高性能。

问题二：运行时报Fetch failure错

在大数据集上，运行Spark程序，在很多情况下会遇到Fetch failure的错。由于Spark本身设计是容错的，大部分的Fetch failure会经过重试后通过，因此整个Spark任务会正常跑完，不过由于重试的影响，执行时间会显著增长。造成Fetch failure的根本原因则不尽相同。从错误本身看，是由于任务不能从远程的节点读取shuffle的数据，具体原因则需要利用：    

查看Spark的运行日志，从而找到造成Fetch failure的根本原因。其中大部分的问题都可以通过合理的参数配置以及对程序进行优化来解决。2014年Spark Summit China上陈超的那个专题，对于如何对Spark性能进行优化，有非常好的建议。

当然，在使用Spark过程中还遇到过其他不同的问题，不过由于Spark本身是开源的，通过源代码的阅读，以及借助开源社区的帮助，大部分问题都可以顺利解决。

钟老师最后总结道，Spark目前已经取得了长足的发展，围绕Spark的大数据生态系统也逐渐的完善。Spark 1.3引入了一个新的DataFrame API，这个新的DataFrame API将会使得Spark对于数据的处理更加友好。同样出自于AMPLab的分布式缓存系统Tachyon因为其与Spark的良好集成也逐渐引起了人们的注意。鉴于在业务场景中，很多基础数据是需要被多个不同的Spark任务重复使用，下一步，我们将会在架构中引入Tachyon来作为缓存层。另外，随着SSD的日益普及，我们后续的计划是在集群中每台机器都引入SSD存储，配置Sparkshuffle的输出到SSD，利用SSD的高速随机读写能力，进一步提高大数据处理效率。

在机器学习方面，H2O机器学习引擎也和Spark有了良好的集成从而产生了Sparkling-water。相信利用Sparking-water，作为一家创业公司，我们也可以利用深度学习的力量来进一步挖掘数据的价值。