基於spark的排序及其性能測試

 

           排序能夠說是不少日誌系統的硬指標（如按照時間逆序排序），若是一個大數據系統不能進行排序，基本上是這個系統屬於不可用狀態，排序算得上是大數據系統的一個「剛需」,不管大數據採用的是hadoop,仍是spark，仍是impala,hive，總之排序是必不可少的，排序的性能測試也是必不可少的。

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


  在這裏，咱們爲你們介紹一種新的廉價排序方法，咱們稱爲blockSort。

     500G的數據300億條數據，只使用4臺 16核，32G內存，千兆網卡的虛擬機便可實現 2~15秒的 排序 （能夠全表排序，也能夠與任意篩選條件篩選後排序）。
   

   1、基本的思想是這樣的，以下圖所示：

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

    2.若是想找最大的數據，那麼只須要在最大的那個塊裏去找就能夠了。

     3.這個快仍是有層級結構的，若是每一個塊內的數據量不少，能夠到下面的子快內進行繼續查找，能夠分多個層進行排序。

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

怎麼樣，原理是否是很是簡單，這樣數據量即便特別多，那麼排序與查找的次數是固定的。

 

  2、這個是咱們以前基於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進行測試。

3、固然除了排序上，咱們的其餘性能也是遠遠高於spark，這塊你們也能夠了解一下

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

註釋：備忘。下圖的這塊，其實沒什麼特別的，只不過因爲YDB自己索引的特性，不想spark那樣暴力，纔會致使在掃描上的性能遠高於spark，性能高百倍不足爲奇。

 

 下圖爲ydb相對於spark txt提高的倍數

二、這些是與 Parquet 格式對比（單位爲秒） 
 
 
 
 
 
 

 

三、與ORACLE性能對比

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

 

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

 

4、YDB是怎麼樣讓spark加速的？

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

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

 

 

 

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

 

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

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

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

4.須要對用戶畫像行爲類數據作多維定向分析的用戶。

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

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

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

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

 

ps: 說了一大堆，說白了最適合的仍是蹤影分析由於數據量大，數據還要求實時，查詢還要求快。這纔是關鍵。