spark 和 elk 技術棧對比？

12-29

網路相關大數據分析架構用kafka + spark + hadoop比較好，還是ELK的解決方案比較好？不考慮機器學習，主要是用到spark的sql和streaming來做定時處理和數據聚合查詢，發現elk也能完成同樣的功能，ELK是不是相對來說輕量很多，更容易部署和維護？

不是同一個領域的東西
elk主要做搜索，日誌，不太適合做大數據統計，當然數據量不大，或者在現有數據上順便支持還行的，但是在統計分析上和hadoop、spark之流不可比較。而且技術棧、工具鏈上也是天差地別。

與其將spark與elk 比較個天翻地覆，還不如握手言和，優勢互補呢？

下面是我們將spark與lucene進行了結合，大家可以參考一下，讓spark性能有質的提升，也讓lucene功能更加完畢。

基於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任何格式。

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

三、當然除了排序上，我們的其他性能也是遠遠高於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性能加快百倍。

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進行測試。

應付常見的日誌摘要和分析是沒問題的，上PB級的數據量也不是難事。
ELK簡單、輕量、易擴展倒是真的，但數據容量，二次抽洗，以及周邊生態，還是沒有Hadoop來得好。
elk在掌握簡單的正則以後即可對任意數據進行抽取（要求半格式化數據），處理同樣的數據spark還需要學一門編程語言。

網路流量分析？你指的是DPI分析還是全流量鏡像分析，如果是dpi分析的話直接把dpi結果放elk和放spark區別就在於elk操作會簡單些。但是具體情況具體分析，如果不嫌麻煩的話還是用spark吧

對比這兩套的時候考慮兩點：