⑴ 深入淺出Spark什麼是Spark
Spark是基於內存，是雲計算領域的繼Hadoop之後的下一代的最熱門的通用的並行計算框架開源項目，尤其出色的支持Interactive Query、流計算、圖計算等。
Spark在機器學習方面有著無與倫比的優勢，特別適合需要多次迭代計算的演算法。同時Spark的擁有非常出色的容錯和調度機制，確保系統的穩定運行，Spark目前的發展理念是通過一個計算框架集合sql、Machine Learning、Graph Computing、Streaming Computing等多種功能於一個項目中，具有非常好的易用性。
目前SPARK已經構建了自己的整個大數據處理生態系統，如流處理、圖技術、機器學習、NoSQL查詢等方面都有自己的技術，並且是Apache頂級Project，可以預計的是2014年下半年在社區和商業應用上會有爆發式的增長。
國內的淘寶、優酷土豆等已經使用Spark技術用於自己的商業生產系統中，國內外的應用開始越來越廣泛，國外一些大型互聯網公司已經部署了Spark。甚至連Yahoo是Hadoop的早期主要貢獻者，現在也在多個項目中部署使用Spark，國內我們已經在運營商、電商等傳統行業部署了Spark.
網路傳送門：http://ke..com/link?url=-_JZlyizhEYJFsZ1e
⑵ 如何使用Spark SQL 的JDBC server
Spark SQL主要的推動者是Databricks。提到Spark SQL不得不提的就是Shark。Shark可以理解為Spark社區這邊搞的一個」Hive on Spark」，把Hive的物理執行計劃使用Spark計算引擎去執行。這裡面會有一些問題，Hive社區那邊沒有把物理執行計劃到執行引擎這個步驟抽象出公共API，所以Spark社區這邊要自己維護一個Hive的分支，而且Hive的設計和發展不太會考慮到如何優化Spark的Job。但是前面提到的Hive on Spark卻是和Hive一起發布的，是由Hive社區控制的。所以後來Spark社區就停止了Shark的開發轉向Spark SQL（「坑了」一部分當時信任Shark的人）。Spark SQL是把SQL解析成RDD的transformation和action，而且通過catalyst可以自由、靈活的選擇最優執行方案。對資料庫有深入研究的人就會知道，SQL執行計劃的優化是一個非常重要的環節，Spark SQL在這方面的優勢非常明顯，提供了一個非常靈活、可擴展的架構。但是Spark SQL是基於內存的，元數據放在內存裡面，不適合作為數據倉庫的一部分來使用。所以有了Spark SQL的HiveContext，就是兼容Hive的Spark SQL。它支持HiveQL, Hive Metastore, Hive SerDes and Hive UDFs以及JDBC driver。這樣看起來很完美，但是實際上也有一些缺點：Spark SQL依賴於Hive的一個snapshot，所以它總是比Hive的發布晚一個版本，很多Hive新的feature和bug fix它就無法包括。而且目前看Spark社區在Spark的thriftserver方面的投入不是很大，所以感覺它不是特別想朝著這個方向發展。還有一個重要的缺點就是Spark SQL目前還不能通過分析SQL來預測這個查詢需要多少資源從而申請對應的資源，所以在共享集群上無法高效地分配資源和調度任務。
⑶ 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
大數據Spark就業火爆-魅力:1 行業壓力競爭小 2 高薪沒商量 3 男女都可學 4 崗位多
⑸ dateframe和spark sql相比有優勢么
json File 日期類型 怎樣處理？怎樣從字元型，轉換為Date或DateTime類型？
json文件如下，有字元格式的日期類型
```
{ "name" : "Andy", "age" : 30, "time" :"2015-03-03T08:25:55.769Z"}
{ "name" : "Justin", "age" : 19, "time" : "2015-04-04T08:25:55.769Z" }
{ "name" : "pan", "age" : 49, "time" : "2015-05-05T08:25:55.769Z" }
{ "name" : "penny", "age" : 29, "time" : "2015-05-05T08:25:55.769Z" }
```
默認推測的Schema：
```
root
|-- _corrupt_record: string (nullable = true)
|-- age: long (nullable = true)
|-- name: string (nullable = true)
|-- time200: string (nullable = true)
```
測試代碼
```
val fileName = "person.json"
val sc = SparkUtils.getScLocal("json file 測試")
val sqlContext = new org.apache.spark.sql.SQLContext(sc)
val jsonFile = sqlContext.read.json(fileName)
jsonFile.printSchema()
```
⑹ 基於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:說了一大堆，說白了最適合的還是蹤跡分析因為數據量大，數據還要求實時，查詢還要求快。這才是關鍵。
⑺ sparkcore spark sql 什麼情況下使用
Spark Core就是一個通用的批處理計算引擎，用來開發離線的批處理作業，它與Hadoop的MapRece的區別就是，spark core基於內存計算，在速度方面有優勢，尤其是機器學習的迭代過程。
Spark SQL就是Spark生態系統中一個開源的數據倉庫組件，可以認為是Hive在Spark的實現，用來存儲歷史數據，做OLAP、日誌分析、數據挖掘、機器學習等等
⑻ Kylin 與 Spark SQL相比，有哪些差異和優勢
SparkSQL本質上是基於DAG模型的MPP。而Kylin核心是Cube(多維立方體)。關於MPP和Cube預處理的差異，重復如下：
>
MPP [1]
的基本思路是增加機器來並行計算，從而提高查詢速度。比如掃描8億記錄一台機器要處理1小時，但如果用100台機器來並行處理，就只要一分鍾不到。再配合
列式存儲和一些索引，查詢可以更快返回。要注意這里在線運算量並沒有減小，8億條記錄還是要掃描一次，只是參與的機器多了，所以快了。
>
MOLAP Cube [2][3]
是一種預計算技術，基本思路是預先對數據作多維索引，查詢時只掃描索引而不訪問原始數據從而提速。8億記錄的一個3維索引可能只有幾萬條記錄，規模大大縮
小，所以在線計算量大大減小，查詢可以很快。索引表也可以採用列存儲，並行掃描等MPP常用的技術。但多維索引要對多維度的各種組合作預計算，離線建索引
需要較大計算量和時間，最終索引也會佔用較多磁碟空間。
除
了有無預處理的差異外，SparkSQL與Kylin對數據集大小的偏好也不一樣。如果數據可以基本放入內存，Spark的內存緩存會讓SparkSQL
有好的表現。但對於超大規模的數據集，Spark也不能避免頻繁的磁碟讀寫，性能會大幅下降。反過來Kylin的Cube預處理會大幅減小在線數據規模，
對於超大規模數據更有優勢。
⑼ 為什麼說Spark SQL遠遠超越了MPP SQL
這里說的並不是性能，因為我沒嘗試對比過（下文會有簡單的說明），而是嘗試從某種更高一層次的的角度去看，為什麼Spark SQL 是遠遠超越MPP SQL的。
Spark SQL 和 MPP SQL 其實不在一個維度上。簡而言之，
MPP SQL 是 Spark SQL 的一個子集
Spark SQL 成為了一種跨越領域的交互形態
MPP SQL 是 Spark SQL 的一個子集
MPP SQL 要解決的技術問題是海量數據的查詢問題。這里根據實際場景，你還可以加上一些修飾詞彙，譬如秒級，Ad-hoc 之類。
在實際業務中
探索類業務，比如KPI多維分析，用戶畫像查詢，數據科學家摸底數據等
運營類業務，比如報表（現在很多BI系統基本上完全基於SQL來構建），各種運營臨時統計需求
分析類業務，不過這個會比較淺顯。顯然，真實的的分析應該主要依託一些統計類，機器學習等技術的支持
運維類業務，比如實時查詢查看海量的系統日誌等
MPP SQL 是有一定的性能優勢的，從HAWQ,Impala 等都是基於MPP架構的。然而僅限於此。這些功能Spark SQL 目前都已經涵蓋了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。
依託於Spark 自身的全平台性(漂亮的DataSource API以及各個廠商的努力適配),Spark SQL 基本上可以對接任意多個異構數據源進行分析和查詢。大家可參考我的一個簡略實現 利用StreamingPro實現SQL-互動式查詢。
關於性能可以再多說兩句：
得益於一些具有復雜存儲格式的文件的誕生，譬如CarbonData, Spark SQL 已經實現海量數據的秒級查詢
Spark 自身通過Tungsten等項目的優化(尤其是代碼自動生成)，速度越來越生猛，而JVM譬如GC帶來的問題則可以進一步通過off-heap的方式減少。
所以 Spark SQL 和 MPP SQL在性能上的差距也會越來越小。
Spark SQL 成為了一種跨越領域的交互形態
Spark 通過使用DS（2.0統一了DF 和 DS，使用一套SQL引擎）極大的增強了交互語意，意味著你可以用SQL（DS）作為統一的交互語言完成流式，批處理，互動式查詢，機器學習等大數據領域常見場景。這在任何一個系統都是不多見的，也可見Spark團隊的抽象能力。
引言中的那篇文章其實是作者吐槽Spark 團隊對Spark core（RDD）那層關注太少了，所以開始發牢騷。
現在我們再回過頭來看我們常見的一些業務：
實時分析類業務
探索類業務
分析預測類業務
運營報表類業務
首先這些業務都可以使用Spark 來實現。其次統一的交互介面都是DS(DF/SQL),並且DS/SQL 是一套極度易用並且廣泛普及和接受的。
當然Spark 也不是一步就做到這點的，原來流式計算和批量計算就是兩套API, DF 和 DS 也是兩套API,後面經過發展，Databricks 團隊也在積極思考和慢慢成長，經過先前已經有的積累，才做到現在的這一步。
所以本質上DS/SQL 已經成為除了RDD API 以外，另外一套通用的，統一的互動式API，涵蓋了流式，批處理，互動式查詢，機器學習等大數據領域。這也是我們第一次達成這樣的統一，目前來看也僅在Spark平台上得以實現，它是的大數據的使用和學習門檻進一步降低，功在千秋。
RDD VS DS/SQL
DS/SQL 是一套數據類型首先，操作種類受限的表達語言，意味著Spark 團隊可以做更好的性能優化，也意味著門檻更低，在易用性和性能上都能取得良好的平衡
⑽ Spark SQL 和 Shark 在架構上有哪些區別將來會合並嗎
Shark為了實現Hive兼容，在HQL方面重用了Hive中HQL的解析、邏輯執行計劃翻譯、執行計劃優化等邏輯，可以近似認為僅將物理執行計劃從MR作業替換成了Spark作業（輔以內存列式存儲等各種和Hive關系不大的優化）；同時還依賴Hive Metastore和Hive SerDe（用於兼容現有的各種Hive存儲格式）。這一策略導致了兩個問題，第一是執行計劃優化完全依賴於Hive，不方便添加新的優化策略；二是因為MR是進程級並行，寫代碼的時候不是很注意線程安全問題，導致Shark不得不使用另外一套獨立維護的打了補丁的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作為引擎，不僅僅是查詢優化方面。
此外，除了兼容HQL、加速現有Hive數據的查詢分析以外，Spark SQL還支持直接對原生RDD對象進行關系查詢。同時，除了HQL以外，Spark SQL還內建了一個精簡的SQL parser，以及一套Scala DSL。也就是說，如果只是使用Spark SQL內建的SQL方言或Scala DSL對原生RDD對象進行關系查詢，用戶在開發Spark應用時完全不需要依賴Hive的任何東西。
能夠對原生RDD對象進行關系查詢，個人認為大大降低了用戶門檻。一方面當然是因為熟悉SQL的人比熟悉Spark API的人多，另一方面是因為Spark SQL之下有Catalyst驅動的查詢計劃優化引擎。雖然在很多方面Spark的性能完爆Hadoop MapRece好幾條街，但Spark的運行時模型也比MapRece復雜不少，使得Spark應用的性能調優比較tricky。雖然從代碼量上來看，Spark應用往往是對等的MR應用的好幾分之一，但裸用Spark API開發高效Spark應用還是需要花些心思的。這就體現出Spark SQL的優勢了：即便用戶寫出的查詢不那麼高效，Catalyst也可以自動應用一系列常見優化策略。
。。