sparksql查詢

『壹』 SparkAPI中的spark.sql(sql)支持limit查詢嗎例如select * from tablename limit 1,10。

支持limit的，但不支持limit(2,10),想要分頁還得使用類似hive的開窗函數row_number

『貳』 基於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:說了一大堆，說白了最適合的還是蹤跡分析因為數據量大，數據還要求實時，查詢還要求快。這才是關鍵。