❶ Hadoop、Hive、Spark三者的區別和關系
Hadoop分為兩大部分：HDFS、Maprece。
HDFS為海量的數據提供了存儲，而MapRece則為海量的數據提供了計算。
由於編寫MapRece程序繁瑣復雜，而sql語言比較簡單，程序員就開發出了支持sql的hive。hive的出現方便了程序員和沒有計算機背景的數據分析人員。我們只需要編寫相對簡單的sql命令，hive會幫我們翻譯為maprece程序交給計算機去執行。
mapreceh這個計算框架每次執行都是從磁碟中讀取的，而spark則是直接從內存中讀取的。由於MapRece 的框架限制，一個 MapRece 任務只能包含一次 Map 和一次 Rece，計算完成之後，MapRece 會將運算結果寫回到磁碟中（更准確地說是分布式存儲系統）供下次計算使用。如果所做的運算涉及大量循環，比如估計模型參數的梯度下降或隨機梯度下降演算法就需要多次循環使用訓練數據，那麼整個計算過程會不斷重復地往磁碟里讀寫中間結果。這樣的讀寫數據會引起大量的網路傳輸以及磁碟讀寫，極其耗時，而且它們都是沒什麼實際價值的廢操作。因為上一次循環的結果會立馬被下一次使用，完全沒必要將其寫入磁碟。
所以spark可以理解為maprece的改進升級版
❷ Spark SQL（十）：Hive On Spark
Hive是目前大數據領域，事實上的SQL標准。其底層默認是基於MapRece實現的，但是由於MapRece速度實在比較慢，因此這幾年，陸續出來了新的SQL查詢引擎，包括Spark SQL，Hive On Tez，Hive On Spark等。
Spark SQL與Hive On Spark是不一樣的。Spark SQL是Spark自己研發出來的針對各種數據源，包括Hive、JSON、Parquet、JDBC、RDD等都可以執行查詢的，一套基於Spark計算引擎的查詢引擎。因此它是Spark的一個項目，只不過提供了針對Hive執行查詢的工功能而已，適合在一些使用Spark技術棧的大數據應用類系統中使用。
而Hive On Spark，是Hive的一個項目，它是將Spark作為底層的查詢引擎（不通過MapRece作為唯一的查詢引擎）。Hive On Spark，只適用於Hive，在可預見的未來，很有可能Hive默認的底層引擎就從MapRece切換為Spark了；適合於將原有的Hive數據倉庫以及數據統計分析替換為Spark引擎，作為全公司通用的大數據統計分析引擎。
Hive On Spark做了一些優化：
1、Map Join
Spark SQL默認對join是支持使用broadcast機制將小表廣播到各個節點上，以進行join的。但是問題是，這會給Driver和Worker帶來很大的內存開銷。因為廣播的數據要一直保留在Driver內存中。所以目前採取的是，類似乎MapRece的Distributed Cache機制，即提高HDFS replica factor的復制因子，以讓數據在每個計算節點上都有一個備份，從而可以在本地進行數據讀取。
2、Cache Table
對於某些需要對一張表執行多次操作的場景，Hive On Spark內部做了優化，即將要多次操作的表cache到內存中，以便於提升性能。但是這里要注意，並不是對所有的情況都會自動進行cache。所以說，Hive On Spark還有很多不完善的地方。
Hive QL語句 =>
語法分析 => AST =>
生成邏輯執行計劃 => Operator Tree =>
優化邏輯執行計劃 => Optimized Operator Tree =>
生成物理執行計劃 => Task Tree =>
優化物理執行計劃 => Optimized Task Tree =>
執行優化後的Optimized Task Tree
❸ 【數倉】對比spark-hive的兩種分布式計算模式
最近在學習過程中發現SparkSQL、Hive on Spark、Spark on Hive是非常容易混淆的的概念。了解三者的關系前，先要先明白幾個概念。
相對於HIve on MapRece，本質上來說，Hive on Spark是Hive把自己的引擎從MapRece替換為更高效的SparkRDD。數據源是hive本身，當我們執行HQL時底層已經不再是將HQL轉換為MapRece任務，而是跑SparkRDD任務。
在hive-site-xml中把hive.execution.engine配置換成spark，在hive所在節點安裝Spark並配置環境變數。外部遠程登錄或者hive命令行模式就會執行spark任務了。
即：Hive on Spark = HQL解析 + SparkRDD引擎
Spark on Hive是以Spark角度看Hive是數據源，在Spark中配置Hive，並獲取Hive中的元數據，然後用SparkSQL操作hive表的數據並直接翻譯成SparkRDD任務。Hive只是作為一個Spark的數據源。
bin/spark-sql、bin/spark-submit採用的是這種方式。提交任務的jar必須帶著hive-site.xml的配置。
即：Spark on Hive = SparkSql解析 + SparkRDD引擎
Spark on Hive的模式更加絲滑，性能更好。
HIve on Spark的模式對大數據周邊組件的支持兼容性更好。
❹ sparkSQL用jdbc連接hive和用元數據連接hive的區別，各自優缺點
spark on hive : 是spark 通過spark-sql 使用hive 語句操作hive ,底層運行的還是 spark rdd.
*（1）就是通過sparksql，載入hive的配置文件，獲取到hive的元數據信息
* （2）spark sql獲取到hive的元數據信息之後就可以拿到hive的所有表的數據
* （3）接下來就可以通過spark sql來操作hive表中的數據
hive on spark: 是hive 等的執行引擎變成spark , 不再是maprece. 相對於上一項,這個要實現責麻煩很多, 必須重新編譯你的spark. 和導入jar包,
❺ 基於spark SQL之上的檢索與排序對比性能測試
之前做過一年的spark研發，之前在阿里與騰訊也做了很久的hive，所以對這方面比較了解。
第一：其實快多少除了跟spark與hive本身的技術實現外，也跟機器性能，底層操作系統的參數優化息息相關，不能一概而論。
第二：hive 目前應該還是業界的主流，畢竟快與慢很多時候並非是至關重要的，對於一個生產系統來說，更重要的應該是穩定性，spark畢竟還算是比較新興的事務，快確實快，但是穩定性上距離hive相差甚遠。關於spark我們也修復了很多關於內存泄露的BUG，因為您問的是性能，所以不過多介紹（可以跟我要YDB編程指南，裡面有我對這些BUG的修正）
第三：關於性能，我測試的可能不夠全面，只能在排序與檢索過濾上提供我之前的基於YDB的BLOCK sort測試報告供您參考（網路上貼word太費勁，您可以跟我要 word文檔）。
排序可以說是很多日誌系統的硬指標（如按照時間逆序排序），如果一個大數據系統不能進行排序，基本上是這個系統屬於不可用狀態，排序算得上是大數據系統的一個「剛需」,無論大數據採用的是hadoop,還是spark，還是impala,hive，總之排序是必不可少的，排序的性能測試也是必不可少的。
有著計算奧運會之稱的Sort Benchmark全球排序每年都會舉行一次，每年巨頭都會在排序上進行巨大的投入，可見排序速度的高低有多麼重要！但是對於大多數企業來說，動輒上億的硬體投入，實在劃不來、甚至遠遠超出了企業的項目預算。相比大數據領域的暴力排序有沒有一種更廉價的實現方式？
在這里，我們為大家介紹一種新的廉價排序方法，我們稱為blockSort。
500G的數據300億條數據，只使用4台 16核，32G內存，千兆網卡的虛擬機即可實現 2~15秒的 排序 （可以全表排序，也可以與任意篩選條件篩選後排序）。
一、基本的思想是這樣的，如下圖所示：
1.將數據按照大小預先劃分好，如劃分成 大、中、小三個塊(block)。
2.如果想找最大的數據，那麼只需要在最大的那個塊里去找就可以了。
3.這個快還是有層級結構的，如果每個塊內的數據量很多，可以到下面的子快內進行繼續查找，可以分多個層進行排序。
4.採用這種方法，一個億萬億級別的數據（如long類型），最壞最壞的極端情況也就進行2048次文件seek就可以篩選到結果。
五、哪些用戶適合使用YDB？
1.傳統關系型數據，已經無法容納更多的數據，查詢效率嚴重受到影響的用戶。
2.目前在使用SOLR、ES做全文檢索，覺得solr與ES提供的分析功能太少，無法完成復雜的業務邏輯，或者數據量變多後SOLR與ES變得不穩定，在掉片與均衡中不斷惡性循環，不能自動恢復服務，運維人員需經常半夜起來重啟集群的情況。
3.基於對海量數據的分析，但是苦於現有的離線計算平台的速度和響應時間無滿足業務要求的用戶。
4.需要對用戶畫像行為類數據做多維定向分析的用戶。
5.需要對大量的UGC（User Generate Content）數據進行檢索的用戶。
6.當你需要在大數據集上面進行快速的，互動式的查詢時。
7.當你需要進行數據分析，而不只是簡單的鍵值對存儲時。
8.當你想要分析實時產生的數據時。
ps:說了一大堆，說白了最適合的還是蹤跡分析因為數據量大，數據還要求實時，查詢還要求快。這才是關鍵。
❻ spark SQL和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作為引擎，不僅僅是查詢優化方面。
❼ spark sql能替代hive嗎
Spark SQL解決了這兩個問題。 第一，Spark SQL在Hive兼容層面僅依賴HQL parser、Hive Metastore和Hive SerDe。也就是說，從HQL被解析成抽象語法樹（AST）起，就全部由Spark SQL接管了。執行計劃生成和優化都由Catalyst負責。藉助Scala的模式匹配...
❽ spark與hive查詢得出的數據不同
在實際工作的情況中，經常有spark與hive查詢出來的數據存在不一樣的情況，基本的原因如下： 1、由於精度不一樣導致的 2、更多的時候確實是由於元數據混亂導致的 （就是說hive中能讀到這個欄位的值，但是在spark中卻無法讀取到該欄位的值。 很多時候可能還是由於大小寫的混亂所導致的） 同一條sql,hive能生成表,而spark卻生成的一張空表,或者數據缺少,存在null值,與hive結果不一致 設置 spark.sql.hive.convertMetastoreOrc=false convertMetastoreParquet=false 原因: spark用自己的格式讀取hive文件後進行自動轉換後進行操作 官方說明❾ 大數據如何入門
首先我們要了解Java語言和Linux操作系統，這兩個是學習大數據的基礎，學習的順序不分前後。
大數據
Java ：只要了解一些基礎即可，做大數據不需要很深的Java 技術，學java SE 就相當於有學習大數據基礎。
Linux：因為大數據相關軟體都是在Linux上運行的，所以Linux要學習的扎實一些，學好Linux對你快速掌握大數據相關技術會有很大的幫助，能讓你更好的理解hadoop、hive、hbase、spark等大數據軟體的運行環境和網路環境配置，能少踩很多坑，學會shell就能看懂腳本這樣能更容易理解和配置大數據集群。還能讓你對以後新出的大數據技術學習起來更快。
Hadoop：這是現在流行的大數據處理平台幾乎已經成為大數據的代名詞，所以這個是必學的。Hadoop裡麵包括幾個組件HDFS、MapRece和YARN，HDFS是存儲數據的地方就像我們電腦的硬碟一樣文件都存儲在這個上面，MapRece是對數據進行處理計算的，它有個特點就是不管多大的數據只要給它時間它就能把數據跑完，但是時間可能不是很快所以它叫數據的批處理。
Zookeeper：這是個萬金油，安裝Hadoop的HA的時候就會用到它，以後的Hbase也會用到它。它一般用來存放一些相互協作的信息，這些信息比較小一般不會超過1M，都是使用它的軟體對它有依賴，對於我們個人來講只需要把它安裝正確，讓它正常的run起來就可以了。
Mysql：我們學習完大數據的處理了，接下來學習學習小數據的處理工具mysql資料庫，因為一會裝hive的時候要用到，mysql需要掌握到什麼層度那?你能在Linux上把它安裝好，運行起來，會配置簡單的許可權，修改root的密碼，創建資料庫。這里主要的是學習SQL的語法，因為hive的語法和這個非常相似。
Sqoop：這個是用於把Mysql里的數據導入到Hadoop里的。當然你也可以不用這個，直接把Mysql數據表導出成文件再放到HDFS上也是一樣的，當然生產環境中使用要注意Mysql的壓力。
Hive：這個東西對於會SQL語法的來說就是神器，它能讓你處理大數據變的很簡單，不會再費勁的編寫MapRece程序。有的人說Pig那?它和Pig差不多掌握一個就可以了。
Oozie：既然學會Hive了，我相信你一定需要這個東西，它可以幫你管理你的Hive或者MapRece、Spark腳本，還能檢查你的程序是否執行正確，出錯了給你發報警並能幫你重試程序，最重要的是還能幫你配置任務的依賴關系。我相信你一定會喜歡上它的，不然你看著那一大堆腳本，和密密麻麻的crond是不是有種想屎的感覺。
Hbase：這是Hadoop生態體系中的NOSQL資料庫，他的數據是按照key和value的形式存儲的並且key是唯一的，所以它能用來做數據的排重，它與MYSQL相比能存儲的數據量大很多。所以他常被用於大數據處理完成之後的存儲目的地。
Kafka：這是個比較好用的隊列工具，隊列是干嗎的?排隊買票你知道不?數據多了同樣也需要排隊處理，這樣與你協作的其它同學不會叫起來，你干嗎給我這么多的數據(比如好幾百G的文件)我怎麼處理得過來，你別怪他因為他不是搞大數據的，你可以跟他講我把數據放在隊列里你使用的時候一個個拿，這樣他就不在抱怨了馬上灰流流的去優化他的程序去了，因為處理不過來就是他的事情。而不是你給的問題。當然我們也可以利用這個工具來做線上實時數據的入庫或入HDFS，這時你可以與一個叫Flume的工具配合使用，它是專門用來提供對數據進行簡單處理，並寫到各種數據接受方(比如Kafka)的。
Spark：它是用來彌補基於MapRece處理數據速度上的缺點，它的特點是把數據裝載到內存中計算而不是去讀慢的要死進化還特別慢的硬碟。特別適合做迭代運算，所以演算法流們特別稀飯它。它是用scala編寫的。Java語言或者Scala都可以操作它，因為它們都是用JVM的。
❿ spark SQL和hive到底什麼關系
Hive是一種基於HDFS的數據倉庫，並且提供了基於SQL模型的，針對存儲了大數據的數據倉庫，進行分布式交互查詢的查詢引擎。
SparkSQL並不能完全替代Hive，它替代的是Hive的查詢引擎，SparkSQL由於其底層基於Spark自身的基於內存的特點，因此速度是Hive查詢引擎的數倍以上，Spark本身是不提供存儲的，所以不可能替代Hive作為數據倉庫的這個功能。
SparkSQL相較於Hive的另外一個優點，是支持大量不同的數據源，包括hive、json、parquet、jdbc等等。SparkSQL由於身處Spark技術堆棧內，基於RDD來工作，因此可以與Spark的其他組件無縫整合使用，配合起來實現許多復雜的功能。比如SparkSQL支持可以直接針對hdfs文件執行sql語句。