如何籌建公司的大數據分析系統（一）

淺談下，如標題這個問題：

隨着大數據被不停的挖掘，天天有態度的人利用用戶數據信息，產生巨大的商業價值，以及風險告警，在籌建大數據分析系統時，你們都很熱衷新的東西，在作公司架構體系時，動不動就直接上新的技術，致使項目夭折，最後走人換公司的局面，後來不斷的有人去填坑。

隨着Splunk 的聲勢浩大，致使目前公司採用起來的成本過高，因此選擇方案的時候須要均衡發展，達到良性可伸縮的系統框架。

採用ELK框架進行日誌分析系統構建：

ELK是Elasticsearch、Logstash、Kibana的簡稱，這三者是核心套件

• Elasticsearch是實時全文搜索和分析引擎，提供蒐集、分析、存儲數據三大功能；是一套開放REST和JAVA API等結構提供高效搜索功能，可擴展的分佈式系統。它構建於Apache Lucene搜索引擎庫之上。

• Logstash是一個用來蒐集、分析、過濾日誌的工具。它支持幾乎任何類型的日誌，包括系統日誌、錯誤日誌和自定義應用程序日誌。它能夠從許多來源接收日誌，這些來源包括 syslog、消息傳遞（例如 RabbitMQ）和JMX，它可以以多種方式輸出數據，包括電子郵件、websockets和Elasticsearch。

• Kibana是一個基於Web的圖形界面，用於搜索、分析和可視化存儲在 Elasticsearch指標中的日誌數據。它利用Elasticsearch的REST接口來檢索數據，不只容許用戶建立他們本身的數據的定製儀表板視圖，還容許他們以特殊的方式查詢和過濾數據。

這種架構、驗證依賴、缺點是Logstash耗資源較大，運行佔用CPU和內存高，嚴重依賴RabbitMQ消息隊列緩存，存在丟失數據隱患，小型公司比較適合。

 

第二種架構、基於kafka 或者redis

Logstash中心節點和Elasticsearch節點都須要採用集羣節點，作相應的負載均衡，緩解服務器壓力，此方案適用於大型架構、雖然引用了消息隊列機制，Logstash佔用系統資源過分，須要龐大的集羣作支撐，建議對不一樣應用類型的數據進行分類展現，避免大面積分析系統不可用。

 

爲了很好的緩解logstash佔用系統過多的問題，將Logstash-forwarder替換爲Beats

Beats 平臺是 Elastic.co 從 packetbeat 發展出來的數據收集器系統。beat 收集器能夠直接寫入 Elasticsearch，也能夠傳輸給 Logstash。其中抽象出來的 libbeat，提供了統一的數據發送方法，輸入配置解析，日誌記錄框架等功能。

目前這種方案不少公司都在此基礎上作二次開發。

在海量日誌系統的運維中，如下幾個方面是必不可少的：

1. 分佈式日誌數據集中式查詢和管理

2. 系統監控，包含系統硬件和應用各個組件的監控

3. 故障排查

4. 安全信息和事件管理

5. 報表功能

怎麼基於數據提高自我價值，爲公司提供實時可靠的數據分析，讓市場部掌控着市場，讓營銷部定點的作業務推廣，從而實現技術價值，也實現這種方案的價值，發揮到極致。

根據龐大的應用日誌能夠分析出用戶分佈的位置、行爲、動態、習慣等等。