spark源码分析

SparkSQL主要的推动者是Databricks。提到SparkSQL不得不提的就是Shark。Shark可以理解为Spark社区这边搞的一个”HiveonSpark”，把Hive的物理执行计划使用Spark计算引擎去执行。这里面会有一些问题，Hive社区那边没有把物理执行计划到执行引擎这个步骤抽象出公共API，所以Spark社区这边要自己维护一个Hive的分支，而且Hive的设计和发展不太会考虑到如何优化Spark的Job。但是前面提到的HiveonSpark却是和Hive一起发布的，是由Hive社区控制的。所以后来Spark社区就停止了Shark的开发转向SparkSQL（“坑了”一部分当时信任Shark的人）。SparkSQL是把SQL解析成RDD的transformation和action，而且通过catalyst可以自由、灵活的选择最优执行方案。对数据库有深入研究的人就会知道，SQL执行计划的优化是一个非常重要的环节，SparkSQL在这方面的优势非常明显，提供了一个非常灵活、可扩展的架构。但是SparkSQL是基于内存的，元数据放在内存里面，不适合作为数据仓库的一部分来使用。所以有了SparkSQL的HiveContext，就是兼容Hive的SparkSQL。它支持HiveQL,HiveMetastore,HiveSerDesandHiveUDFs以及JDBCdriver。这样看起来很完美，但是实际上也有一些缺点：SparkSQL依赖于Hive的一个snapshot，所以它总是比Hive的发布晚一个版本，很多Hive新的feature和bugfix它就无法包括。而且目前看Spark社区在Spark的thriftserver方面的投入不是很大，所以感觉它不是特别想朝着这个方向发展。还有一个重要的缺点就是SparkSQL目前还不能通过分析SQL来预测这个查询需要多少资源从而申请对应的资源，所以在共享集群上无法高效地分配资源和调度任务。