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。我不知道是不是華為的底蘊非常的牛，還是人有多大膽，地有多大產了。