SparkSQL是Spark新推出來的一個模塊。關(guān)于SparkSQL的八卦其實(shí)知道的不多，但是技術(shù)上倒能說幾句。

早先我文章提到了Shark是個失敗的作品。這個觀點(diǎn)從Shark出來不久我就這樣覺得了。SparkSQL的論文承認(rèn)Spark團(tuán)隊也認(rèn)為Shark是一條胡同走到黑的選擇。既不能夠?qū)Ρ镜氐腞DD做查詢，也不能有效和其他的Spark的模塊交互。英雄所見略同。當(dāng)然狗熊所見也差不多。至于是英雄還是狗熊，各位看官自己判斷。

SparkSQL最主要的東西有兩個，一個是DataFrame全面取代了RDD。我必須為這個叫聲好。作為一個根紅苗正的關(guān)系數(shù)據(jù)庫思想熏陶出來的人，帶有RDD的Spark總給我一種干爹干媽做的數(shù)據(jù)處理的產(chǎn)品的感覺。用上DataFrame頓時有回到親爹親媽做的產(chǎn)品的感覺。期間的差距，可能是無法言語表達(dá)的。

DataFrame看起來像表了，有metadata了，既打開了做optimization的空間，又能夠很好的和其他的Spark模塊結(jié)合起來。的確是Spark一步領(lǐng)先步步領(lǐng)先的必然選擇，是大殺器。DataFrame一出，Spark的地位就真的牢固起來了。

第二個東西就是SparkSQL有了一個optimizer。這個optimizer粗看起來其實(shí)也沒什么特殊的。作為在好幾個optimizer里改過code的人，這個optimizer一看就是關(guān)系數(shù)據(jù)庫的套路。有l(wèi)ogical的pass有physical的pass。但是我覺得有幾點(diǎn)是不同的。***點(diǎn)是rule本身是用Scala寫的。作為一個functional programming的語言，寫tree matching寫起來是得心應(yīng)手。用Scala來寫rule的確是非常的有意思和有意義的一個選擇。第二是它有很多extension point。這就使得它用起來可獲展性好。至于CodeGen成JVM bytecode，自從有了LLVM在數(shù)據(jù)庫里面折騰，就算不上特別的驚艷了。但是起碼的好處是不管什么語言無論是python還是java用SparkSQL，性能差距都不大了。

至于這個東西的未來發(fā)展，我覺得optimization現(xiàn)在在SQL相關(guān)的操作和其他操作之間還是要間斷的。如果前面一堆sql的操作，中間有個machine learning的call，接下來又有一個sql的操作，optimization其實(shí)很難說把這三個捆在一起，做一個global的optimization。User-defined operator摻和的優(yōu)化是很有意思又很難的。

另外我很能理解為什么現(xiàn)在系統(tǒng)是rule-based。Cost-based的東西在這種大規(guī)模分布式的系統(tǒng)下，很多時候怎么去cost就是個問題，不如Rule來得實(shí)用。能做固然是牛逼，但是其實(shí)能起作用的地方有限。我想如果我來，也會先上rule看看再說，也許這輩子都不上cost-based了。當(dāng)然我聽說在Spark Summit上，華為來的同學(xué)們上了一個cost-based optimizer。我不知道是不是華為的底蘊(yùn)非常的牛，還是人有多大膽，地有多大產(chǎn)了。