SparkSQL是Spark新推出来的一个模块。关于SparkSQL的八卦其实知道的不多，但是技术上倒能说几句。
早先我文章提到了Shark是个失败的作品。这个观点从Shark出来不久我就这样觉得了。SparkSQL的论文承认Spark团队也认为Shark是一条胡同走到黑的选择。既不能够对本地的RDD做查询，也不能有效和其他的Spark的模块交互。英雄所见略同。当然狗熊所见也差不多。至于是英雄还是狗熊，各位看官自己判断。
SparkSQL最主要的东西有两个，一个是DataFrame全面取代了RDD。我必须为这个叫声好。作为一个根红苗正的关系数据库思想熏陶出来的人，带有RDD的Spark总给我一种干爹干妈做的数据处理的产品的感觉。用上DataFrame顿时有回到亲爹亲妈做的产品的感觉。期间的差距，可能是无法言语表达的。
DataFrame看起来像表了，有metadata了，既打开了做optimization的空间，又能够很好的和其他的Spark模块结合起来。的确是Spark一步领先步步领先的必然选择，是大杀器。DataFrame一出，Spark的地位就真的牢固起来了。
第二个东西就是SparkSQL有了一个optimizer。这个optimizer粗看起来其实也没什么特殊的。作为在好几个optimizer里改过code的人，这个optimizer一看就是关系数据库的套路。有logical的pass有physical的pass。但是我觉得有几点是不同的。***点是rule本身是用Scala写的。作为一个functional programming的语言，写tree matching写起来是得心应手。用Scala来写rule的确是非常的有意思和有意义的一个选择。第二是它有很多extension point。这就使得它用起来可获展性好。至于CodeGen成JVM bytecode，自从有了LLVM在数据库里面折腾，就算不上特别的惊艳了。但是起码的好处是不管什么语言无论是python还是java用SparkSQL，性能差距都不大了。
至于这个东西的未来发展，我觉得optimization现在在SQL相关的操作和其他操作之间还是要间断的。如果前面一堆sql的操作，中间有个machine learning的call，接下来又有一个sql的操作，optimization其实很难说把这三个捆在一起，做一个global的optimization。User-defined operator掺和的优化是很有意思又很难的。
另外我很能理解为什么现在系统是rule-based。Cost-based的东西在这种大规模分布式的系统下，很多时候怎么去cost就是个问题，不如Rule来得实用。能做固然是牛逼，但是其实能起作用的地方有限。我想如果我来，也会先上rule看看再说，也许这辈子都不上cost-based了。当然我听说在Spark Summit上，华为来的同学们上了一个cost-based optimizer。我不知道是不是华为的底蕴非常的牛，还是人有多大胆，地有多大产了。
