如何籌建公司的大數據分析系統（一）
淺談下，如標題這個問題：
隨著大數據被不停的挖掘，每天有態度的人利用用戶數據信息，產生巨大的商業價值，以及風險告警，在籌建大數據分析系統時，大家都很熱衷新的東西，在做公司架構體系時，動不動就直接上新的技術，導致項目夭折，最後走人換公司的局面，後來不斷的有人去填坑。
隨著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，提供了統一的數據發送方法，輸入配置解析，日誌記錄框架等功能。
目前這種方案很多公司都在此基礎上做二次開發。
在海量日誌系統的運維中，以下幾個方面是必不可少的：
分布式日誌數據集中式查詢和管理
系統監控，包含系統硬件和應用各個組件的監控
故障排查
安全信息和事件管理
報表功能
怎麽基於數據提升自我價值，為公司提供實時可靠的數據分析，讓市場部掌控著市場，讓營銷部定點的做業務推廣，從而實現技術價值，也實現這種方案的價值，發揮到極致。
根據龐大的應用日誌可以分析出用戶分布的位置、行為、動態、習慣等等。
本文出自 “一杯水” 博客，請務必保留此出處http://yibeishui.blog.51cto.com/6518161/1970036
如何籌建公司的大數據分析系統（一）