解读2015之Spark篇：新生态系统的形成

摘自：易搜社区 http://bbs.easysoo.cn/?p=544 编者按：2015年，整个IT技术领域发生了许多深刻而又复杂的变化，InfoQ策划了“解读2015”年终技术盘点系列文章，希望能够给读者清晰地梳理出技术领域在这一年的发展变化，回顾过去，继续前行。本文是大数据解读2015之Spark篇，明略数据的梁堰波为大家解读Spark在2015年的快速发展，后续InfoQ会有更多关于大数据生态技术的总结。

2015年的Spark社区的进展实在是太快了，我发现1月份出版的一本参考书到现在已经有很多内容是过时的了。社区大踏步前行的同时，用户和应用案例也越来越多，应用行业越来越广泛。到年底了我们来梳理下Spark这快速发展的一年。
先从全局有个认识，我尝试用三句话来概括下Spark最主要的变化，然后在接下来的篇幅选取一些重点内容展开。

Spark生态系统渐趋完善。支持的外部数据源越来越多，支持的算子越来越丰富，自身的机器学习算法越来越完善。同时在API支持上也有很大进步，新增加的R语言API使得Spark能被更多的行业所接受。
Spark的应用范围和规模在不断扩大。在互联网和电子商务行业的应用不断增多、规模不断扩大的基础上，越来越多的金融、电信、制造业等传统行业也开始使用Spark解决他们遇到的大数据问题。
Spark自身的性能和稳定性在不断提升。Tungsten项目让Spark跑的越来越快，越来越多的代码贡献者和使用经验让Spark越来越稳定。相信明年发布的Spark 2.0将是一个里程碑式的版本。

转向以DataFrame为核心

在传统意义上Spark的核心是RDD和RDD之上的各种transformation和action，也就是各种算子，RDD可以认为是分布式的Java对象的集合。2013年推出了DataFrame，可以看做分布式的Row对象的集合。DataFrame除了提供了比RDD更丰富的算子以外，更重要的特点就是有执行计划的优化器，这样用户只需要指定自己的操作逻辑，DataFrame的优化器会帮助用户选择一条效率最优的执行路径。同时Tungsten优化（下一章重点讲）使得DataFrame的存储和计算效率比RDD高很多。Spark的机器学习项目MLlib的ML pipeline就是完全基于DataFrame的，而且未来Streaming也会以DataFrame为核心。



（图片引自Databricks）

Tungsten让Spark越来越快

那么为什么DataFrame比RDD在存储和计算上的效率更高呢？这主要得益于Tungsten项目。Tungsten做的优化概括起来说就是由Spark自己来管理内存而不是使用JVM，这样可以避免JVM GC带来的性能损失；内存中的Java对象被存储成Spark自己的二进制格式，更加紧凑，节省内存空间，而且能更好的估计数据量大小和内存使用情况；计算直接发生在二进制格式上，省去了序列化和反序列化时间。
像传统的Hadoop/Hive系统，磁盘IO是一个很大的瓶颈。而对于像Spark这样的计算框架，主要的瓶颈在于CPU和内存。下面看看Tungsten主要做了哪些优化：
1，基于JVM的语言带来的问题：GC问题和Java对象的内存开销。例如一个字符串”abcd”理论上只有4个bytes，但是用Java String类型来存储却需要48个bytes。Spark的改进就是自己管理内存，不用JVM来管理了，使用的工具是sun.misc.Unsafe。DataFrame的每一行就是一个UnsafeRow，这块内存存的啥东西只有Spark自己能读懂。有了这种特有的二进制存储格式后，DataFrame的算子直接操控二进制数据，同时又省去了很多序列化和反序列化的开销。
>>>未完，浏览下一节
>>>未完，浏览下一节