總結：Hive，HiveonSpark和SparkSQL區別

Hive on Mapreduce 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)：由 Com piler 生成的執行計畫是階段性的 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特點 關係資料庫裡，表的載入模式是在資料載入時候強制確定的（表的載入模式是指資料庫存儲資料的檔案格式），如果載入資料時候發現載入的資料不符合模式，關係資料庫則會拒絕載入資料，這個就叫「寫時模式 」，寫時模式會在資料載入時候對資料模式進行檢查校驗的操作。 Hive在載入資料時候和關係資料庫不同，hive在載入資料時候不會對資料進行檢查，也不會更改被載入的資料檔案，而檢查資料格式的操作是在查詢操作時候執行，這種模式叫「讀時模式」。 在實際應用中，寫時模式在載入資料時候會對列進行索引，對資料進行壓縮，因此載入資料的速度很慢，但是當資料載入好了，我們去查詢資料的時候，速度很快。 但是當我們的資料是非結構化，存儲模式也是未知時候，關係資料操作這種場景就麻煩多了，這時候hive就會發揮它的優勢。 關係資料庫一個重要的特點是可以對某一行或某些行的資料進行更新、刪除操作，hive**不支援對某個具體行的操作，hive對資料的操作只支援覆蓋原資料和追加資料**。 Hive也不支援事務和索引。 更新、事務和索引都是關係資料庫的特徵，這些hive都不支援，也不打算支援，原因是hive的設計是海量資料進行處理，全資料的掃描時常態，針對某些具體資料進行操作的效率是很差的，對於更新操作，hive是通過查詢將原表的資料進行轉化最後存儲在新表裡，這和傳統資料庫的更新操作有很大不同。 Hive也可以在hadoop做即時查詢上做一份自己的貢獻，那就是和hbase集成，hbase可以進行快速查詢，但是hbase不支援類SQL的語句，那麼此時hive可以給hbase提供sql語法解析的外殼， 可以用類sql語句操作hbase資料庫。 Hive可以認為是MapReduce的一個封裝、包裝。 Hive的意義就是在業務分析中將使用者容易編寫、會寫的Sql語言轉換為複雜難寫的MapReduce程式，從而大大降低了Hadoop學習的門檻，讓更多的使用者可以利用Hadoop進行資料採礦分析。 比較項 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的兩個元件

SQLCoNtext：Spark SQL提供SQLCoNtext封裝Spark中的所有關系型功能。 可以用之前的示例中的現有SparkCoNtext創建SQLCoNtext。 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語句的順序

對讀入的SQL語句進行解析（Parse），分辨出SQL語句中哪些詞是關鍵字（如SELECT、FROM、WHERE），哪些是運算式、哪些是Projection、哪些是Data Source等， 從而判斷SQL語句是否規範；


Projection：簡單說就是select選擇的列的集合，參考：SQL Projection 將SQL語句和資料庫的資料字典（列、表、視圖等等）進行綁定（Bind），如果相關的Projection、Data Source等都是存在的話，就表示這個SQL語句是可以執行的； 一般的資料庫會提供幾個執行計畫，這些計畫一般都有運行統計資料，資料庫會在這些計畫中選擇一個最優計畫（Optimize）； 計畫執行（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) #基本查詢示例 inp ut.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）。

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性能對比

結論：sparksql和hive on spark時間差不多，但都比hive on mapreduce快很多，官方資料認為spark會被傳統mapreduce快10-100倍