hive,shark,sparkSQL,hive on spark,impala,drill比較

Hive on Mapreduce

Hive的原理你們能夠參考這篇大數據時代的技術hive：hive介紹，實際的一些操做能夠看這篇筆記：新手的Hive指南，至於還有興趣看Hive優化方法能夠看看我總結的這篇Hive性能優化上的一些總結

Hive on Mapreduce執行流程

執行流程詳細解析

• Step 1：UI(user interface) 調用 executeQuery 接口，發送 HQL 查詢語句給 Driver
• Step 2：Driver 爲查詢語句建立會話句柄，並將查詢語句發送給 Compiler， 等待其進行語句解析並生成執行計劃
• Step 3 and 4：Compiler 從 metastore 獲取相關的元數據
• Step 5：元數據用於對查詢樹中的表達式進行類型檢查，以及基於查詢謂詞調整分區，生成計劃
• Step 6 (6.1，6.2，6.3)：由 Compiler 生成的執行計劃是階段性的 DAG，每一個階段均可能會涉及到 Map/Reduce job、元數據的操做、HDFS 文件的操做，Execution Engine 將各個階段的 DAG 提交給對應的組件執行。
• Step 7, 8 and 9：在每一個任務（mapper / reducer）中，查詢結果會以臨時文件的方式存儲在 HDFS 中。保存查詢結果的臨時文件由 Execution Engine 直接從 HDFS 讀取，做爲從 Driver Fetch API 的返回內容。

Hive on Mapreduce特色

1. 關係數據庫裏，表的加載模式是在數據加載時候強制肯定的（表的加載模式是指數據庫存儲數據的文件格式），若是加載數據時候發現加載的數據不符合模式，關係數據庫則會拒絕加載數據，這個就叫「寫時模式」，寫時模式會在數據加載時候對數據模式進行檢查校驗的操做。Hive在加載數據時候和關係數據庫不一樣，hive在加載數據時候不會對數據進行檢查，也不會更改被加載的數據文件，而檢查數據格式的操做是在查詢操做時候執行，這種模式叫「讀時模式」。在實際應用中，寫時模式在加載數據時候會對列進行索引，對數據進行壓縮，所以加載數據的速度很慢，可是當數據加載好了，咱們去查詢數據的時候，速度很快。可是當咱們的數據是非結構化，存儲模式也是未知時候，關係數據操做這種場景就麻煩多了，這時候hive就會發揮它的優點。
2. 關係數據庫一個重要的特色是能夠對某一行或某些行的數據進行更新、刪除操做，hive**不支持對某個具體行的操做，hive對數據的操做只支持覆蓋原數據和追加數據**。Hive也不支持事務和索引。更新、事務和索引都是關係數據庫的特徵，這些hive都不支持，也不打算支持，緣由是hive的設計是海量數據進行處理，全數據的掃描時常態，針對某些具體數據進行操做的效率是不好的，對於更新操做，hive是經過查詢將原表的數據進行轉化最後存儲在新表裏，這和傳統數據庫的更新操做有很大不一樣。
3. Hive也能夠在hadoop作實時查詢上作一份本身的貢獻，那就是和hbase集成，hbase能夠進行快速查詢，可是hbase不支持類SQL的語句，那麼此時hive能夠給hbase提供sql語法解析的外殼，能夠用類sql語句操做hbase數據庫。
4. Hive能夠認爲是MapReduce的一個封裝、包裝。Hive的意義就是在業務分析中將用戶容易編寫、會寫的Sql語言轉換爲複雜難寫的MapReduce程序，從而大大下降了Hadoop學習的門檻，讓更多的用戶能夠利用Hadoop進行數據挖掘分析。

與傳統數據庫之間對比—From：Hive和傳統數據庫進行比較

比較項	SQL	HiveQL
ANSI SQL	支持	不徹底支持
更新	UPDATE\INSERT\DELETE	insert OVERWRITE\INTO TABLE
事務	支持	不支持
模式	寫模式	讀模式
數據保存	塊設備、本地文件系統	HDFS
延時	低	高
多表插入	不支持	支持
子查詢	徹底支持	只能用在From子句中
視圖	Updatable	Read-only
可擴展性	低	高
數據規模	小	大
….	……	……

SparkSQL

SparkSQL簡介

SparkSQL的前身是Shark，給熟悉RDBMS但又不理解MapReduce的技術人員提供快速上手的工具，hive應運而生，它是當時惟一運行在Hadoop上的SQL-on-hadoop工具。可是MapReduce計算過程當中大量的中間磁盤落地過程消耗了大量的I/O，下降的運行效率，爲了提升SQL-on-Hadoop的效率，Shark應運而生，但又由於Shark對於Hive的太多依賴（如採用Hive的語法解析器、查詢優化器等等),2014年spark團隊中止對Shark的開發，將全部資源放SparkSQL項目上

​ 其中SparkSQL做爲Spark生態的一員繼續發展，而再也不受限於Hive，只是兼容Hive；而Hive on Spark是一個Hive的發展計劃，該計劃將Spark做爲Hive的底層引擎之一，也就是說，Hive將再也不受限於一個引擎，能夠採用Map-Reduce、Tez、Spark等引擎。

• SparkSQL的兩個組件

  1. SQLContext：Spark SQL提供SQLContext封裝Spark中的全部關係型功能。能夠用以前的示例中的現有SparkContext建立SQLContext。
  2. DataFrame：DataFrame是一個分佈式的，按照命名列的形式組織的數據集合。DataFrame基於R語言中的data frame概念，與關係型數據庫中的數據庫表相似。經過調用將DataFrame的內容做爲行RDD（RDD of Rows）返回的rdd方法，能夠將DataFrame轉換成RDD。能夠經過以下數據源建立DataFrame：已有的RDD、結構化數據文件、JSON數據集、Hive表、外部數據庫。

SparkSQL運行架構

相似於關係型數據庫，SparkSQL也是語句也是由Projection（a1，a2，a3）、Data Source（tableA）、Filter（condition）組成，分別對應sql查詢過程當中的Result、Data Source、Operation，也就是說SQL語句按Operation–>Data Source–>Result的次序來描述的。

當執行SparkSQL語句的順序

1. 對讀入的SQL語句進行解析（Parse），分辨出SQL語句中哪些詞是關鍵詞（如SELECT、FROM、WHERE），哪些是表達式、哪些是Projection、哪些是Data Source等，從而判斷SQL語句是否規範； 
   • Projection：簡單說就是select選擇的列的集合，參考：SQL Projection
2. 將SQL語句和數據庫的數據字典（列、表、視圖等等）進行綁定（Bind），若是相關的Projection、Data Source等都是存在的話，就表示這個SQL語句是能夠執行的；
3. 通常的數據庫會提供幾個執行計劃，這些計劃通常都有運行統計數據，數據庫會在這些計劃中選擇一個最優計劃（Optimize）；
4. 計劃執行（Execute），按Operation–>Data Source–>Result的次序來進行的，在執行過程有時候甚至不須要讀取物理表就能夠返回結果，好比從新運行剛運行過的SQL語句，可能直接從數據庫的緩衝池中獲取返回結果。

Hive on Spark

​ hive on Spark是由Cloudera發起，由Intel、MapR等公司共同參與的開源項目，其目的是把Spark做爲Hive的一個計算引擎，將Hive的查詢做爲Spark的任務提交到Spark集羣上進行計算。經過該項目，能夠提升Hive查詢的性能，同時爲已經部署了Hive或者Spark的用戶提供了更加靈活的選擇，從而進一步提升Hive和Spark的普及率。

Hive on Spark與SparkSql的區別

​ hive on spark大致與SparkSQL結構相似，只是SQL引擎不一樣，可是計算引擎都是spark！敲黑板！這纔是重點！

咱們來看下，在pyspark中使用Hive on Spark是中怎麼樣的體驗

#初始化Spark SQL #導入Spark SQL from pyspark.sql import HiveContext,Row # 當不能引入Hive依賴時 # from pyspark.sql import SQLContext,Row # 注意，上面那一點纔是關鍵的，他兩來自於同一個包，大家區別能有多大 hiveCtx = HiveContext(sc) #建立SQL上下文環境 input = hiveCtx.jsonFile(inputFile) #基本查詢示例 input.registerTempTable("tweets") #註冊輸入的SchemaRDD（SchemaRDD在Spark 1.3版本後已經改成DataFrame） #依據retweetCount(轉發計數)選出推文 topTweets = hiveCtx.sql("SELECT text,retweetCount FROM tweets ORDER BY retweetCount LIMIT 10")

咱們能夠看到，sqlcontext和hivecontext都是出自於pyspark.sql包，能夠從這裏理解的話，其實hive on spark和sparksql並無太大差異

結構上Hive On Spark和SparkSQL都是一個翻譯層，把一個SQL翻譯成分佈式可執行的Spark程序。並且你們的引擎都是spark

SparkSQL和Hive On Spark都是在Spark上實現SQL的解決方案。Spark早先有Shark項目用來實現SQL層，不事後來推翻重作了，就變成了SparkSQL。這是Spark官方Databricks的項目，Spark項目自己主推的SQL實現。Hive On Spark比SparkSQL稍晚。Hive本來是沒有很好支持MapReduce以外的引擎的，而Hive On Tez項目讓Hive得以支持和Spark近似的Planning結構（非MapReduce的DAG）。因此在此基礎上，Cloudera主導啓動了Hive On Spark。這個項目獲得了IBM，Intel和MapR的支持（可是沒有Databricks）。—From SparkSQL與Hive on Spark的比較

Hive on Mapreduce和SparkSQL使用場景

Hive on Mapreduce場景

• Hive的出現可讓那些精通SQL技能、可是不熟悉MapReduce 、編程能力較弱與不擅長Java語言的用戶可以在HDFS大規模數據集上很方便地利用SQL 語言查詢、彙總、分析數據，畢竟精通SQL語言的人要比精通Java語言的多得多
• Hive適合處理離線非實時數據

SparkSQL場景

• Spark既能夠運行本地local模式，也能夠以Standalone、cluster等多種模式運行在Yarn、Mesos上，還能夠運行在雲端例如EC2。此外，Spark的數據來源很是普遍，能夠處理來自HDFS、HBase、 Hive、Cassandra、Tachyon上的各類類型的數據。
• 實時性要求或者速度要求較高的場所

Hive on Mapreduce和SparkSQL性能對比

具體實驗參見：Spark SQL & Spark Hive編程開發， 並和Hive執行效率對比

結論：sparksql和hive on spark時間差很少，但都比hive on mapreduce快不少，官方數據認爲spark會被傳統mapreduce快10-100倍

關於Spark

簡介

在Hadoop的整個生態系統中，Spark和MapReduce在同一個層級，即主要解決分佈式計算框架的問題。

 

架構

Spark的架構以下圖所示，主要包含四大組件：Driver、Master、Worker和Executor。

 

Spark特色

• Spark能夠部署在YARN上
• Spark原生支持對HDFS文件系統的訪問
• 使用Scala語言編寫

 

部署模型

1. 單機模型：主要用來開發測試。特色：Driver、Master、Worker和Executor都運行在同一個JVM進程之中。
2. 僞集羣模型：主要用來開發測試。特色：Master、Worker都運行在同一個JVM進程之中；Master、Worker和Executor都運行於同一臺機器，沒法跨機器運行；
3. 獨立集羣（又叫作原生集羣模式）：在集羣規模不是很是大的狀況下，可用於生產環境。特色：Master、Worker和Executor都運行於獨立的JVM進程。
4. YARN集羣：YARN生態中的ApplicationMaster角色使用Apache開發好的Spark ApplicationMaster代替，每個YARN生態中的NodeManager角色至關於一個Spark生態中的Worker角色，由NodeManger負責Executor的啓動。
5. Mesos集羣：暫無詳細調研。

關於Spark SQL

簡介

它主要用於結構化數據處理和對Spark數據執行類SQL的查詢。經過Spark SQL，能夠針對不一樣格式的數據執行ETL操做（如JSON，Parquet，數據庫）而後完成特定的查詢操做。通常來講，Spark每支持一種新的應用開發，都會引入一個新的Context及相應的RDD，對於SQL這一特性來講，引入的就是SQLContext和SchemaRDD。注意：在Spark1.3以後，SchemaRDD已經改名爲DataFrame，但它本質就相似一個RDD，由於能夠將DataFrame無縫的轉換成一個RDD。

 

架構

Spark要很好的支持SQL，要完成解析(parser)、優化(optimizer)、執行(execution)三大過程。

處理順序大體以下：

1. SQlParser生成LogicPlan Tree；
2. Analyzer和Optimizer將各類Rule做用於LogicalPlan Tree；
3. 最終優化生成的LogicalPlan生成SparkRDD；
4. 最後將生成的RDD交由Spark執行；

關於Hive on Spark

背景

Hive on Spark是由Cloudera發起，由Intel、MapR等公司共同參與的開源項目，其目的是把Spark做爲Hive的一個計算引擎，將Hive的查詢做爲Spark的任務提交到Spark集羣上進行計算。經過該項目，能夠提升Hive查詢的性能，同時爲已經部署了Hive或者Spark的用戶提供了更加靈活的選擇，從而進一步提升Hive和Spark的普及率。

 

簡介

Hive on Spark是從Hive on MapReduce演進而來，Hive的總體解決方案很不錯，可是從查詢提交到結果返回須要至關長的時間，查詢耗時太長，這個主要緣由就是因爲Hive原生是基於MapReduce的，那麼若是咱們不生成MapReduce Job，而是生成Spark Job，就能夠充分利用Spark的快速執行能力來縮短HiveQL的響應時間。

Hive on Spark如今是Hive組件(從Hive1.1 release以後)的一部分。

 

與SparkSQL的區別

SparkSQL和Hive On Spark都是在Spark上實現SQL的解決方案。Spark早先有Shark項目用來實現SQL層，不事後來推翻重作了，就變成了SparkSQL。這是Spark官方Databricks的項目，Spark項目自己主推的SQL實現。Hive On Spark比SparkSQL稍晚。Hive本來是沒有很好支持MapReduce以外的引擎的，而Hive On Tez項目讓Hive得以支持和Spark近似的Planning結構（非MapReduce的DAG）。因此在此基礎上，Cloudera主導啓動了Hive On Spark。這個項目獲得了IBM，Intel和MapR的支持（可是沒有Databricks）。

 

使用示例

大致與SparkSQL結構相似，只是SQL引擎不一樣。部分核心代碼以下：

val hiveContext = new HiveContext(sc)

import hiveContext._

hql("CREATE TABLE IF NOT EXIST src(key INT, value STRING)")

hql("LOAD DATA LOCAL PATH '/Users/urey/data/input2.txt' INTO TABLE src")

hql("FROM src SELECT key, value").collect().foreach(println)

•  

小結

結構上Hive On Spark和SparkSQL都是一個翻譯層，把一個SQL翻譯成分佈式可執行的Spark程序。好比一個SQL：

SELECT item_type, sum(price)
FROM item
GROUP item_type;

上面這個SQL腳本交給Hive或者相似的SQL引擎，它會「告訴」計算引擎作以下兩個步驟：讀取item表，抽出item_type,price這兩個字段；對price計算初始的SUM（其實就是每一個單獨的price做爲本身的SUM）由於GROUP BY說須要根據item_type分組，因此設定shuffle的key爲item_type從第一組節點分組後分發給聚合節點，讓相同的item_type彙總到同一個聚合節點，而後這些節點把每一個組的Partial Sum再加在一塊兒，就獲得了最後結果。無論是Hive仍是SparkSQL大體上都是作了上面這樣的工做。

須要理解的是，Hive和SparkSQL都不負責計算，它們只是告訴Spark，你須要這樣算那樣算，可是自己並不直接參與計算。

Spark Shark | 即 Hive on Spark

a.在實現上是把HQL翻譯成Spark上的RDD操做，而後經過Hive的metadata獲取數據庫裏的表信息，Shark獲取HDFS上的數據和文件夾放到Spark上運算。

b.它的最大特性就是快以及與Hive徹底兼容

c.Shark使用了Hive的API來實現query parsing和logic plan generation,最後的Physical Plan execution階段用Spark代替Hadoop MR。

d.經過配置Shark參數，Shark能夠自動在內存中緩存特定的RDD,實現數據重用，進而加快特定數據集的檢索。

e.Shark經過UDF實現特定的數據分析學習算法，使得SQL數據查詢和運算分析結合在一塊兒，最大化RDD的重複使用。

Spark SQL

a.是基於Catalyst(翻譯爲催化劑)引擎的交互式大數據SQL技術,使用SchemaRDD來操做SQL,比Shark支持更過的查詢表達式。

b.支持Hive|HBase|Oracle

交互式SQL處理框架Spark SQL

a.SparkSQL的四個特色：

1.能在Scala代碼裏寫SQL,支持簡單的SQL語法檢查，能把RDD指定爲Table存儲起來。對SQL的支持主要依賴Catalyst(催化劑)查詢優化框架，在把SQL解析成邏輯執行計劃以後，利用Catalyst包裏的一些類和接口，執行了一些簡單的執行計劃優化

最後變成RDD的計算。

2.支持Parquet(arquet是面向分析型業務的列式存儲格式)文件的讀寫，且保留Schem.Parquet是一個列式存儲格式的文件系統，使用Parquet進行文件讀寫能夠極大地下降對CPU和磁盤I/O的消耗。

3.支持直接多JSON格式數據的操做。

4.能在Scala代碼裏訪問Hive元數據，能執行hive語句，而且把結果取回做爲RDD使用。Shark依賴Hive的metastore,解析器能把hql執行變成Spark的計算，SparkSQL的前身是Shark，而Shark的前身是HIVE.

5.Shark對於Hive的依賴太多，爲了擺脫依賴性，SparkSQL不管在數據兼容|性能優化|組件擴展都獲得了極大的方便。

b.SparkSQL的性能：

1.Shark的出現，使得SQL-on-hadoop的性能比hive有了10~100倍的提升。擺脫Hive的限制，SSQL的性能也很優秀

在2014年7月1日的Spark Summit上，Databricks宣佈終止對Shark的開發，將重點放到Spark SQL上。Databricks表示，Spark SQL將涵蓋Shark的全部特性，用戶能夠從Shark 0.9進行無縫的升級。

本次Databricks推廣的Shark相關項目一共有兩個，分別是Spark SQL和新的Hive on Spark（HIVE-7292），在介紹這兩個項目以前，咱們首先關注下被終止的項目Shark。

Shark及項目終止緣由

About Shark

Shark發佈於3年前，那個時候，Hive能夠說是SQL on Hadoop的惟一選擇，負責將SQL編譯成可擴展的MapReduce做業。鑑於Hive的性能以及與Spark的兼容，Shark項目由此而生。

Shark即Hive on Spark，本質上是經過Hive的HQL解析，把HQL翻譯成Spark上的RDD操做，而後經過Hive的metadata獲取數據庫裏的表信息，實際HDFS上的數據和文件，會由Shark獲取並放到Spark上運算。

Shark的最大特性就是快和與Hive的徹底兼容，且能夠在shell模式下使用rdd2sql()這樣的API，把HQL獲得的結果集，繼續在scala環境下運算，支持本身編寫簡單的機器學習或簡單分析處理函數，對HQL結果進一步分析計算。

除去Spark自己的迭代計算，Shark速度快的緣由還在於其自己的改造，好比：

partial DAG execution：對join優化，調節並行粒度，由於Spark自己的寬依賴和窄依賴會影響並行計算和速度
基於列的壓縮和存儲：把HQL表數據按列存，每列是一個array，存在JVM上，避免了JVM GC低效，而壓縮和解壓相關的技術是Yahoo!提供的。
終止Shark的緣由

在會議上，Databricks表示，Shark更可能是對Hive的改造，替換了Hive的物理執行引擎，所以會有一個很快的速度。然而，不容忽視的是，Shark繼承了大量的Hive代碼，所以給優化和維護帶來了大量的麻煩。隨着性能優化和先進分析整合的進一步加深，基於MapReduce設計的部分無疑成爲了整個項目的瓶頸。

所以，爲了更好的發展，給用戶提供一個更好的體驗，Databricks宣佈終止Shark項目，從而將更多的精力放到Spark SQL上。

兩個相關/替代項目介紹

About Spark SQL

既然不是基於Hive，Spark SQL究竟有什麼樣的改變，這裏咱們不妨看向 張包峯的博客。Spark新發布的Spark SQL組件讓Spark對SQL有了別樣於Shark基於Hive的支持。參考官方手冊，具體分三部分：

其一，能在Scala代碼裏寫SQL，支持簡單的SQL語法檢查，能把RDD指定爲Table存儲起來。此外支持部分SQL語法的DSL。
其二，支持Parquet文件的讀寫，且保留Schema。
其三，能在Scala代碼裏訪問Hive元數據，能執行Hive語句，而且把結果取回做爲RDD使用。
第一點對SQL的支持主要依賴了Catalyst這個新的查詢優化框架（下面會給出一些Catalyst的簡介），在把SQL解析成邏輯執行計劃以後，利用Catalyst包裏的一些類和接口，執行了一些簡單的執行計劃優化，最後變成RDD的計算。雖然目前的SQL解析器比較簡單，執行計劃的優化比較通配，還有些參考價值，因此看了下這塊代碼。目前這個PR在昨天已經merge進了主幹，能夠在SQL模塊裏看到這部分實現，還有catalyst模塊看到Catalyst的代碼。下面會具體介紹Spark SQL模塊的實現。

第二點對Parquet的支持不關注，由於咱們的應用場景裏不會使用Parquet這樣的列存儲，適用場景不同。

第三點對Hive的這種結合方式，沒有什麼核心的進展。與Shark相比，Shark依賴Hive的Metastore，解析器等能把hql執行變成Spark上的計算，而Hive的如今這種結合方式與代碼裏引入Hive包執行hql沒什麼本質區別，只是把hive hql的數據與RDD的打通這種交互作得更友好了。

About HIVE-7292

HIVE-7292更像是Spark SQL成爲標準SQL on Spark項目的補充，首先它是一個Hive on Spark Project，旨在服務已有Hive投入的機構，這個項目將Spark做爲一個替代執行引擎提供給Hive，從而爲這些機構提供一個遷往Spark的途徑，提供一個更流暢的Hive體驗。

隨着Spark SQL的引入和新的Hive on Apache Spark方向的努力（HIVE-7292），許多人詢問咱們在這兩個項目中的位置，以及它們與Shark的關係。在今天的Spark峯會上，咱們宣佈，咱們中止了Shark的開發，並會專一於Spark SQL，它將提供Shark特性的超集，以便於現有的Shark用戶繼續使用。Spark SQL提供了從Shark 0.9的無縫升級，以及一些諸如通用Spark程序的集成等新特性。

Shark

三年前Shark項目開始的時候，Hive（on MapReduce）是SQL on Hadoop的惟一選擇。Hive把SQL編譯成可擴展的MapReduce做業，並且能夠支持多種格式（經過它的SerDes）。可是其性能並不理想。爲了交互式地執行查詢，許多公司部署了昂貴的專用企業數據倉庫（EDWs），這須要嚴格的、冗長的ETL流程。

Hive和EDWs之間的性能對比在工業界引發了關於在通用數據處理引擎上進行查詢處理的內在缺陷的巨大爭論。許多人認爲SQL交互須要一個昂貴的專用系統用於查詢處理（如EDWs）。Shark成爲了一種較早的交互式SQL on Hadoop系統，並且是惟一一種基於通用運行環境（Spark）構建的。它代表了全部致使Hive慢的缺陷都不是根本性的，像Spark這樣的通用引擎就能同時達到兩方面的要求：和EDW同樣快，和Hive/MapReduce同樣可擴展。

爲何你應該關注這個看似比較學術的爭論呢？各類組織都在尋找能給它們帶來商業優點的方法，它們使用了不少超出SQL提供的上卷和下鑽能力的技術。基於通用環境構建一個SQL查詢引擎統一了許多不一樣的、強大的模型，例如batch、streaming、機器學習。這使得數據科學家和工程師可以更快的執行更復雜的方法。Shark的觀點很快被接受了，甚至催生了Hive的一些重要改進。

從Shark到Spark SQL

Shark基於Hive源碼構建，並經過替換Hive的物理執行引擎得到了性能上的提高。雖然這種方法讓Shark用戶能更快的執行Hive查詢，可是Shark從Hive繼承了大量複雜的源碼，於是致使難以優化和維護。隨着咱們逐步逼近性能優化的極限和集成複雜的SQL分析，咱們被那些按照MapReduce設計的遺產所束縛。

正由於如此，咱們中止了Spark做爲一個單獨項目的開發，並把全部的開發資源轉向Spark SQL，Spark的一個新組件。咱們借鑑了Shark的經驗用到Spark SQL中，並從新設計以更好了利用Spark。這種新途徑讓咱們更快的創新，最終爲用戶交付更好的體驗。

對於SQL用戶，Spark SQL提供了最早進的SQL性能併兼容Shark/Hive。像Shark同樣，Spark SQL支持全部的Hive數據格式，用戶定義函數（UDF），和Hive metastore。Spark1.1.0引入新的特性後，TPC-DS performance中，Spark SQL性能比Shark高一個數量級。

對於Spark用戶，Spark SQL成爲了處理（半）結構化數據和諸如JSON、Parquet、Hive或EDWs等有模式的數據源的細腰（narrow-waist）。它確實統一了SQL和複雜分析，容許用戶混合SQL和更多編程API以實現高級分析。

對於開源黑客，Spark SQL提供了一種新的簡潔的方法去構建查詢計劃。在這個框架下添加新的優化很簡單。咱們已經徹底被開源社區對於Spark SQL的熱情所折服，多虧這個新設計。僅僅三個月，就有40多爲貢獻者提交了代碼。謝謝。

Hive on Spark（HIVE-7292）

雖然Spark SQL逐漸成爲SQL on Spark的標準，可是咱們知道許多組織已經使用了Hive。這裏面也有不少公司想遷移到Spark。Hive社區提出了一個新舉措，這樣能使Spark做爲Hive的一個可選執行引擎。對於上述組織，參照上述引文能夠把執行引擎遷移到Spark。咱們很高興能與Hive社區一塊兒爲用戶提供更平順的體驗。

總之，咱們堅信Spark SQL會是基於Spark的SQL和結構化數據處理的將來。咱們將努力工做，並在隨後幾個releases帶來更多特性。對於有遺留Hive部署的公司，Hive on Spark會爲他們提供支持。

英文原文：發表於2014年7月1日 
Shark, Spark SQL, Hive on Spark, and the future of SQL on Apache Spark

Impala與Shark，Drill等的比較

開源組織Apache也發起了名爲Drill的項目來實現Hadoop上的Dremel，目前該項目正在開發當中，相關的文檔和代碼還很少，能夠說暫時還未對Impala構成足夠的威脅。從Quora上的問答來看，Cloudera有7-8名工程師全職在Impala項目上，而相比之下Drill目前的動做稍顯遲鈍。具體來講，截止到2012年10月底，Drill的代碼庫裏實現了query parser, plan parser，及能對JSON格式的數據進行掃描的plan evaluator；而Impala同期已經有了一個比較完畢的分佈式query execution引擎，並對HDFS和HBase上的數據讀入，錯誤檢測，INSERT的數據修改，LLVM動態翻譯等都提供了支持。固然，Drill做爲Apache的項目，從一開始就避免了某個vendor的一家獨大，並且對全部Hadoop流行的發行版都會作相應的支持，不像Impala只支持Cloudera本身的發行版CDH。從長遠來看，誰會佔據上風還真不必定。

除此以外，加州伯克利大學AMPLab也開發了名爲Shark的大數據分析系統。從長遠目標來看，Shark想成爲一個既支持大數據SQL查詢，又能支持高級數據分析任務的一體化數據處理系統。從技術實現的角度上來看，Shark基於Scala語言的算子推導實現了良好的容錯機制，所以對失敗了的長任務和短任務都能從上一個「快照點」進行快速恢復。相比之下，Impala因爲缺失足夠強大的容錯機制，其上運行的任務一旦失敗就必須「從頭來過」，這樣的設計必然會在性能上有所缺失。並且Shark是把內存看成第一類的存儲介質來作的系統設計，因此在處理速度上也會有一些優點。實際上，AMPLab最近對Hive，Impala，Shark及Amazon採用的商業MPP數據庫Redshift進行了一次對比試驗，在Scan Query，Aggregation Query和Join Query三種類型的任務中對它們進行了比較。圖2就是AMPLab報告中Aggregation Query的性能對比。在圖中咱們能夠看到，商業版本的Redshift的性能是最好的， Impala和Shark則各有勝負，且二者都比Hive的性能高出了一大截。

參考：

Shark對Hive的兼容性總結

前世此生：Hive、Shark、spark SQL

impala與hive的比較以及impala的有缺點