基于spark排序的一種更廉價的實現方案-附基于spark的性能測試

排序可以說是很多日志系統的硬指標（如按照時間逆序排序），如果一個大數據系統不能進行排序，基本上是這個系統屬于不可用狀態，排序算得上是大數據系統的一個“剛需”,無論大數據采用的是hadoop,還是spark，還是impala,hive，總之排序是必不可少的，排序的性能測試也是必不可少的。

有著計算奧運會之稱的Sort Benchmark全球排序每年都會舉行一次，每年巨頭都會在排序上進行巨大的投入，可見排序速度的高低有多么重要！但是對于大多數企業來說，動輒上億的硬件投入，實在劃不來、甚至遠遠超出了企業的項目預算。相比大數據領域的暴力排序有沒有一種更廉價的實現方式？

  在這里，我們為大家介紹一種新的廉價排序方法，我們稱為blockSort。

500G的數據300億條數據，只使用4臺 16核，32G內存，千兆網卡的虛擬機即可實現 2~15秒的 排序 （可以全表排序，也可以與任意篩選條件篩選后排序）。
一、基本的思想是這樣的，如下圖所示：

1.將數據按照大小預先劃分好，如劃分成 大、中、小三個塊(block)。

2.如果想找最大的數據，那么只需要在最大的那個塊里去找就可以了。

3.這個快還是有層級結構的，如果每個塊內的數據量很多，可以到下面的子快內進行繼續查找，可以分多個層進行排序。

4.采用這種方法，一個億萬億級別的數據（如long類型），最壞最壞的極端情況也就進行2048次文件seek就可以篩選到結果。

怎么樣，原理是不是非常簡單，這樣數據量即使特別多，那么排序與查找的次數是固定的。

二、這個是我們之前基于spark做的性能測試，供大家參考

在排序上，YDB具有絕對優勢，無論是全表，還是基于任意條件組合過濾，基本秒殺Spark任何格式。

測試結果(時間單位為秒)

測試過程視頻地址

https://v.qq.com/x/page/q0371wjj8fb.html

https://v.qq.com/x/page/n0371l0ytji.html

感興趣的讀者也可以閱讀YDB編程指南 http://url.cn/42R4CG8 。也可以參考該書自己安裝延云YDB進行測試。
三、當然除了排序上，我們的其他性能也是遠遠高于spark，這塊大家也可以了解一下

1、與Spark txt在檢索上的性能對比測試。

注釋：備忘。下圖的這塊，其實沒什么特別的，只不過由于YDB本身索引的特性，不想spark那樣暴力，才會導致在掃描上的性能遠高于spark，性能高百倍不足為奇。

下圖為ydb相對于spark txt提升的倍數

2、這些是與 Parquet 格式對比（單位為秒） 
 
 
 
 
 
 

3、與ORACLE性能對比

跟傳統數據庫的對比，已經沒啥意義，Oracle不適合大數據，任意一個大數據工具都遠超oracle 性能。

4.稽查布控場景性能測試

四、YDB是怎么樣讓spark加速的？

     基于Hadoop分布式架構下的實時的、多維的、交互式的查詢、統計、分析引擎，具有萬億數據規模下的秒級性能表現，并具備企業級的穩定可靠表現。

      YDB是一個細粒度的索引，精確粒度的索引。數據即時導入，索引即時生成，通過索引高效定位到相關數據。YDB與Spark深度集成，Spark對YDB檢索結果集直接分析計算，同樣場景讓Spark性能加快百倍。

五、哪些用戶適合使用YDB？

1.傳統關系型數據，已經無法容納更多的數據，查詢效率嚴重受到影響的用戶。

2.目前在使用SOLR、ES做全文檢索，覺得solr與ES提供的分析功能太少，無法完成復雜的業務邏輯，或者數據量變多后SOLR與ES變得不穩定，在掉片與均衡中不斷惡性循環，不能自動恢復服務，運維人員需經常半夜起來重啟集群的情況。

3.基于對海量數據的分析，但是苦于現有的離線計算平臺的速度和響應時間無滿足業務要求的用戶。

4.需要對用戶畫像行為類數據做多維定向分析的用戶。

5.需要對大量的UGC（User Generate Content）數據進行檢索的用戶。

6.當你需要在大數據集上面進行快速的，交互式的查詢時。

7.當你需要進行數據分析，而不只是簡單的鍵值對存儲時。

8.當你想要分析實時產生的數據時。

視頻地址 （看不清的同學可以進入騰訊視頻 高清播放）

https://v.qq.com/x/page/q0371wjj8fb.html

https://v.qq.com/x/page/n0371l0ytji.html

感興趣的讀者也可以閱讀YDB編程指南 http://url.cn/42R4CG8 。也可以參考該書自己安裝延云YDB進行測試。

Tags: spark, hadoop, hive, lucene, 排序, 大數據