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

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

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

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

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

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

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