Spark SQL 和 Shark 在架構上有哪些區別？將來會合並嗎

Shark為了實現Hive兼容，在HQL方面重用了Hive中HQL的解析、邏輯執行計劃翻譯、執行計劃優化等邏輯，可以近似認為僅將物理執行計劃從MR作業替換成了Spark作業（輔以內存列式存儲等各種和Hive關系不大的優化）；同時還依賴Hive Metastore和Hive SerDe（用於兼容現有的各種Hive存儲格式）。這壹策略導致了兩個問題，第壹是執行計劃優化完全依賴於Hive，不方便添加新的優化策略；二是因為MR是進程級並行，寫代碼的時候不是很註意線程安全問題，導致Shark不得不使用另外壹套獨立維護的打了補丁的Hive源碼分支（至於為何相關修改沒有合並到Hive主線，我也不太清楚）。

此外，除了兼容HQL、加速現有Hive數據的查詢分析以外，Spark SQL還支持直接對原生RDD對象進行關系查詢。同時，除了HQL以外，Spark SQL還內建了壹個精簡的SQL parser，以及壹套Scala DSL。也就是說，如果只是使用Spark SQL內建的SQL方言或Scala DSL對原生RDD對象進行關系查詢，用戶在開發Spark應用時完全不需要依賴Hive的任何東西。

Spark SQL解決了這兩個問題。第壹，Spark SQL在Hive兼容層面僅依賴HQL parser、Hive Metastore和Hive SerDe。也就是說，從HQL被解析成抽象語法樹（AST）起，就全部由Spark SQL接管了。執行計劃生成和優化都由Catalyst負責。借助Scala的模式匹配等函數式語言特性，利用Catalyst開發執行計劃優化策略比Hive要簡潔得多。去年Spark summit上Catalyst的作者Michael Armbrust對Catalyst做了壹個簡要介紹：2013 | Spark Summit（知乎竟然不能自定義鏈接的文字？）。第二，相對於Shark，由於進壹步削減了對Hive的依賴，Spark SQL不再需要自行維護打了patch的Hive分支。Shark後續將全面采用Spark SQL作為引擎，不僅僅是查詢優化方面。

能夠對原生RDD對象進行關系查詢，個人認為大大降低了用戶門檻。壹方面當然是因為熟悉SQL的人比熟悉Spark API的人多，另壹方面是因為Spark SQL之下有Catalyst驅動的查詢計劃優化引擎。雖然在很多方面Spark的性能完爆Hadoop MapReduce好幾條街，但Spark的運行時模型也比MapReduce復雜不少，使得Spark應用的性能調優比較tricky。雖然從代碼量上來看，Spark應用往往是對等的MR應用的好幾分之壹，但裸用Spark API開發高效Spark應用還是需要花些心思的。這就體現出Spark SQL的優勢了：即便用戶寫出的查詢不那麽高效，Catalyst也可以自動應用壹系列常見優化策略。

.

上一篇:如何使用php函數

下一篇:安卓rmvb播放器安卓rmvb播放器