海量日誌分析怎麼處理？

現在公司要做1個產品、監控網站的PV和網頁載入時間，然後做多維度（瀏覽器、運行商、省份地域）的分析，需要進行降噪處理（比如過濾5%-85%的數據），要做實時展現。

現在在數據收集方面遇到問題，現在的方案是將每條數據再後端進行累加，然後按一定的時間粒度（比如30秒）進行入庫，但是如果要做直方圖展示，比如0-1秒之內有多少用戶訪問，1-2秒之間有多少用戶訪問，比如我要過濾掉性能最慢的15%的噪點數據，豈不是要保留每條數據，數據量=PV是很大的，希望能給我1個解決思路和方案

【大數據乾貨】輕鬆處理每天2TB的日誌數據，支撐運營團隊進行大數據分析挖掘，隨時洞察用戶個性化需求。-博客-雲棲社區-阿里雲

「用戶每天產生的日誌量大約在2TB。我們需要將這些海量的數據導入雲端，然後分天、分小時的展開數據分析作業，分析結果再導入資料庫和報表系統，最終展示在運營人員面前。」墨跡天氣運維部經理章漢龍介紹，整個過程中數據量龐大，且計算複雜，這對雲平台的大數據能力、生態完整性和開放性提出了很高的要求。

關於墨跡天氣

北京墨跡風雲科技股份有限公司於2010年成立，是一家以「做卓越的天氣服務公司」為目標的新興移動互聯網公司，主要開發和運營的「墨跡天氣」是一款免費的天氣信息查詢軟體。「墨跡天氣」APP目前在全球約有超過5億人在使用，支持196個國家70多萬個城市及地區的天氣查詢，分鐘級、公里級天氣預報，實時預報雨雪。提供15天天氣預報，5天空氣質量預報，實時空氣質量及空氣質量等級預報，其短時預報功能，可實現未來2小時內，每10分鐘一次，預測逐分鐘逐公里的天氣情況。特殊天氣提前發送預警信息，幫助用戶更好做出生活決策。在墨跡天氣上，每天有超過 5 億次的天氣查詢需求和將近20億次的廣告請求，這個數字甚至要大於 Twitter 每天發帖量。墨跡天氣已經集成了多語言版本，可根據手機系統語言自動適配，用戶覆蓋包括中國大陸、港澳台，日韓及東南亞、歐美等全球各地用戶。

挑戰

墨跡運營團隊每天最關心的是用戶正在如何使用墨跡，在他們操作中透露了哪些個性化需求。這些數據全部存儲在墨跡的API日誌中，對這些數據分析，就變成了運營團隊每天的最重要的工作。墨跡天氣的API每天產生的日誌量大約在2TB左右，主要的日誌分析場景是天氣查詢業務和廣告業務。
「用戶每天產生的日誌量大約在2TB。我們需要將這些海量的數據導入雲端，然後分天、分小時的展開數據分析作業，分析結果再導入資料庫和報表系統，最終展示在運營人員面前。」墨跡天氣運維部經理章漢龍介紹，整個過程中數據量龐大，且計算複雜，這對雲平台的大數據能力、生態完整性和開放性提出了很高的要求。 之前墨跡使用國外某雲計算服務公司的雲伺服器存儲這些數據，利用Hadoop的MapReducer和Hive對數據進行處理分析，但是存在以下問題：
1.成本：包括存儲、計算及大數據處理服務成本對比阿里雲成本很高。
2.網路帶寬：移動端業務量大，需要大量的網路帶寬資源支持，但數據上傳也需要佔用網路帶寬，彼此之間相互干擾造成數據傳輸不穩定。

解決方案及架構

針對上述情況，墨跡將日誌分析業務逐步遷移到阿里雲大數據平台-數加平台之上。
新的日誌分析架構如頁面下方架構圖所示。
方案涉及的阿里雲數加平台組件有：
? 阿里雲數加-大數據計算服務MaxCompute產品地址：https://www.aliyun.com/product/odps
? 大數據開發套件（DataIDE）https://data.aliyun.com/product/ide
? 流計算（StreamCompute,規劃中）https://data.aliyun.com/product/sc
? 流式數據發布和訂閱（DataHub）
另外，由於每天產生的數據量較大，上傳數據會佔用帶寬，為了不影響業務系統的網路資源，客戶開通了阿里雲高速通道，用於數據上傳。通過此種手段解決了網路帶寬的問題。
通過阿里雲數加日誌分析解決方案，墨跡的業務得到以下提升：
1.充分利用移動端積累下來的海量日誌數據。
2.對用戶使用情況和廣告業務進行大數據分析。
3.利用阿里雲數加大數據技術，基於對日誌數據的分析，支持運營團隊和廣告團隊優化現有業務。

收益

1.遷移到MaxCompute後，流程上做了優化，省掉了編寫MR程序的工作，日誌數據全部通過SQL進行分析,工作效率提升了5倍以上。
2.存儲方面，MaxCompute的表按列壓縮存儲，更節省存儲空間，整體存儲和計算的費用比之前省了70%，性能和穩定性也有很大提升。
3.可以藉助MaxCompute上的機器學習演算法，對數據進行深度挖掘，為用戶提供個性化的服務。
4.阿里雲MaxCompute提供更為易用、全面的大數據分析功能。MaxCompute可根據業務情況做到計算資源自動彈性伸縮，天然集成存儲功能。通過簡單的幾項配置操作後，即可完成數據上傳，同時實現了多種開源軟體的對接。

架構圖

如果只是監控用的，可以直接搭建一個ELK平台。如果日誌業務非常重視，而且公司未來很多都要集成上面，那的確可以自己開發一套日誌分析系統，可控性強。

之前也設計、開發過一個大型日誌分析系統，日誌採集的話你可以使用flume或者Logstach等。

真正有瓶頸的應該是後端如何處理海量數據，消費速度，是否引起堆積等？

採用storm流處理方式，還是批量入庫方式？這個根據實際場景進行權衡

日誌的統計規則梳理？網站數據如何採集？架構的可靠性？

都需要設計清楚在動手

日誌易可以實現【實時】的海量日誌的可視化統一管理及搜索分析。

可接收處理多類型日誌數據：網路設備日誌、Web日誌、應用日誌、伺服器日誌······

看樓主的需求，應該是在降噪處理（數據過濾）、實時、可視化。

目前已經有上百家大客戶在選擇使用日誌易，這應該可以成為你的解決方案。

我是看到海量日誌分析進來的 可能有點文不對題。

之前在國內某（聊天）廠處理每天3600條的日誌，需要對日誌即席的進行檢索與分析，所以介紹下騰訊hermes（現在的延雲YDB）。

排序可以說是很多日誌系統的硬指標（如按照時間逆序排序），如果一個大數據系統不能進行排序，基本上是這個系統屬於不可用狀態，排序算得上是大數據系統的一個「剛需」,無論大數據採用的是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性能加快百倍。

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

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

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

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

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

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

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

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

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

ps: 說了一大堆，說白了最適合的還是蹤跡分析因為數據量大，數據還要求實時，查詢還要求快。這才是關鍵。

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

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

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

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

『比如我要過濾掉性能最慢的15%的噪點數據，豈不是要保留每條數據，數據量=PV是很大的』

是的，data is data，為了支持靈活全面的分析，最好把所有的數據都保留下來。至於你說的數據量大，那是存儲的問題。

請從三方面來看待海量數據分析：

百度指數可以隨時統計到流量，搜數可以為你隨時爬取後台數據！