一種海量日誌存儲、分析解決方案V1.0

本方案試運行中，待觀測其性能、穩定性及健壯性，請勿直接應用生產。

涉及的技術棧。

    hadoop，版本2.6.0，主要用來存儲數據及進行離線分析。

    hive，版本1.2.1，主要用來管理數據（注意沒有用到MR分析）；

    hbase，版本1.2.4，主要用來存儲中間輸出數據（可看做緩存）；

    flume，版本1.7.0，主要用來從業務系統收集數據以及從jms收集數據。

    kafka，版本0.10.1.0，主要用來收集業務系統日誌數據和彙總日誌數據。

    spark，版本2.0.1，主要用來取代hive的MR分析，並針對基礎數據進行數據篩選分析等（可看做離線數據分析引擎）。

    redis，版本3.0.6，主要用來緩存分析中的增量數據，設定當天數據時效爲36小時，天天同步一次昨天的增量日誌數據到全量數據庫中。

    storm，版本0.10.2，主要用來日誌實時分析，如用戶畫像實時更新，PV統計等。

    mongodb，版本3.2.10，主要用來存儲終態數據，如用戶畫像、PV值等供業務系統使用。

    ganglia，版本3.2.0，主要用來監控各節點狀態。

    其它如haproxy、nginx等輔助ha工具這裏再也不贅述。

    首先看一張架構圖。

    根據架構圖設計出網絡拓撲圖

    最後是流程圖

如下是數據流向說明：

    一、業務系統收集日誌數據

    二、業務系統可發送日誌數據到消息集羣（kafka）

    三、採集器（flume）主動收集日誌數據，發送到消息集羣（kafka）

    四、全部日誌數據，最終流向消息集羣（kafka），而後分流到實時計算和離線計算兩個方向（注意一份日誌數據會被複制兩份，一份供實時計算使用，一份供離線計算使用，且hadoop集羣分爲實時計算hadoop集羣和離線分析hadoop集羣，二者互不干擾）

        4.一、實時計算

            4.1.一、storm從消息集羣（kafka）拉取數據，首先篩選出有用的數據（針對不一樣的topology），存儲到hbase。

            4.1.二、而後針對分析類型，預處理數據，預處理數據分兩種存儲，一種是增量，使用redis，一種是全量，使用hbase。當天數據所有存儲到增量表中，並設置時效36小時，自動清除過時數據，天天將增量數據，同步到全量數據中。同時更新一個key，還要把key發送到更新key消息集羣（kafka），供下一步分析使用。

            4.1.三、最後從更新key消息集羣（kafka）讀取更新key，而後獲取緩存數據，進行算法分析，分析結果更新到mongodb中。

    4.二、離線計算

        4.2.一、首先採集器（flume）從消息集羣（kafka）中拉取數據，而後將數據存儲到hive中

        4.2.二、創建shell定時任務，使用spark針對基礎數據，按天進行同實時計算一樣的分析，存儲到hbase中。並將最終結果存儲到mongodb（存儲時 注意不要和實時分析放在同一個document裏）。

    五、開放spark的thirfserver對外提供日誌數據查詢供運維定位問題。

    六、分析數據流向mongodb，供業務使用，基礎數據直接對外提供訪問供運維定位問題。

解釋一下爲何要離線和實時都進行一次一樣的操做。

    由於實時計算架構一旦中斷，雖然歷史數據不會丟失，但中斷那一段時間的數據就須要從新進行分析和計算，若是數據量比較大，分析任務比較多，那將會形成必定的損失。而使用加上離線後，由於架構中區別離線hadoop和實時hadoop，因此數據相對隔離的，實時hadoop丟失數據能夠從離線hadoop中同步過來，使用hbase的LoadIncrementalHFiles命令便可。

涉及到開發的部分：

    一、flume的過濾器：除了jms方式可以統一格式，flume自採就會採集到各類各樣格式的數據，這就須要一個轉換，將數據轉換成標準的格式。

    二、redis緩存數據同步hbase：將增量數據同步到hbase的系統

    三、topology：topology是storm的核心，須要用戶編寫spout、bolt、Topology來完成一些列分析處理操做

系統難點：

    一、flume從kafka拉取數據後，存入hive中：想要作到數據實時插入，而不是定時load數據到hive。但目前還沒一個完美的解決方案。一個變相的解決辦法是限定hive表，而後根據規則將數據寫入到hive表文件裏。如：表user，按date天分區，天天一個文件，那flume在插入數據的時候不走hive，直接將數據按天分文件，寫入到對應的hive表文件裏，這樣hive能夠讀取到新添進去的數據，變相實現實時插入。此種方法須要flume保證數據格式。

    二、因爲技術棧涉及較廣，須要多部分配合，資源調配，而且會增長必定的人員學習成本和運營成本。

建議：

    一、建議先實現一部分，好比先放棄實時計算，和離線計算，只運行基礎數據存儲，只供運維定位問題使用，總結經驗，而後根據需求一點一點擴充。

    二、根據不一樣技術特定，進行差別化的服務器硬件配置，好比spark須要高內存，低硬盤，那就能夠把硬盤容量調小點；好比hadoop須要高性能的io，對內存要求不高，那就把硬盤配置好點。還能夠兩者結合，互相彌補，可能性能也會有所提高。