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

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

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

  在這里，我們?yōu)榇蠹医榻B一種新的廉價排序方法，我們稱為blockSort。

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

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

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

3.這個快還是有層級結(jié)構(gòu)的，如果每個塊內(nèi)的數(shù)據(jù)量很多，可以到下面的子快內(nèi)進行繼續(xù)查找，可以分多個層進行排序。

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

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

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

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

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

測試過程視頻地址

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

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

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

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

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

下圖為ydb相對于spark txt提升的倍數(shù)

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

3、與ORACLE性能對比

跟傳統(tǒng)數(shù)據(jù)庫的對比，已經(jīng)沒啥意義，Oracle不適合大數(shù)據(jù)，任意一個大數(shù)據(jù)工具都遠(yuǎn)超oracle 性能。

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

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

     基于Hadoop分布式架構(gòu)下的實時的、多維的、交互式的查詢、統(tǒng)計、分析引擎，具有萬億數(shù)據(jù)規(guī)模下的秒級性能表現(xiàn)，并具備企業(yè)級的穩(wěn)定可靠表現(xiàn)。

      YDB是一個細(xì)粒度的索引，精確粒度的索引。數(shù)據(jù)即時導(dǎo)入，索引即時生成，通過索引高效定位到相關(guān)數(shù)據(jù)。YDB與Spark深度集成，Spark對YDB檢索結(jié)果集直接分析計算，同樣場景讓Spark性能加快百倍。

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

1.傳統(tǒng)關(guān)系型數(shù)據(jù)，已經(jīng)無法容納更多的數(shù)據(jù)，查詢效率嚴(yán)重受到影響的用戶。

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

3.基于對海量數(shù)據(jù)的分析，但是苦于現(xiàn)有的離線計算平臺的速度和響應(yīng)時間無滿足業(yè)務(wù)要求的用戶。

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

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

6.當(dāng)你需要在大數(shù)據(jù)集上面進行快速的，交互式的查詢時。

7.當(dāng)你需要進行數(shù)據(jù)分析，而不只是簡單的鍵值對存儲時。

8.當(dāng)你想要分析實時產(chǎn)生的數(shù)據(jù)時。

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

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, 排序, 大數(shù)據(jù)