大數據認識篇

大數據認識篇 

什麼是大數據，爲何大數據，咱不說。

處理大數據。

從一個簡單的需求提及：

一、    假設公司有100個域名，各個域名下有更多的子域名，下文子域名也叫作域名。

每一個域名對應的nginx log 假設1G.

如今的需求是log數據得存儲一年，天天早上給出每一個域名對應的各類指標，多少ip，4xx，5xx and so on。

作法是：每一個機器上定時任務唄，處理腳本，發送結果到郵箱，每一個域名發一封，呵呵。優化：把結果寫到數據庫，而後寫個腳本處理數據庫，發送到郵箱，就是一封郵件了。

再優化：把日誌晚上切割後，壓縮發送到一個專門的機器上，寫一個腳本，能夠隨意修改，數據統一，處理方式統一，結果統一。

二、    業務擴大，域名多了，日誌數據從1G到1000G。

就拿單機來講，shell腳本很難作處理了，即便作到了，效果很差。這麼大的數據都集中到一個存儲機器，存一年，還佔用網絡速度，確定不行。再說1000G---切割到100G一個，而後shell處理100G這麼多，也耗時耗力。

好吧，大數據來了。

咱如今須要的次日早上發送報告，也就是處理冷數據。

數據集中：

hadoop的hdfs

每一個機器上的log文件是文本格式的，能夠存到每一個機器的數據庫，這樣一來，每一個機器上的log就能夠聯動，可是效率不高，hadoop的hdfs來了，這樣理解：這hdfs控制端查今天公司網站全部的總帶寬，一個命令就好了。看起來不是按個讀取文本文件去查，加起來。把分佈在各個服務器的數據看做了一個整體。

數據分析：

hadoop的MapReduce，不細說。

三、    實時大規模nginx日誌 elk

Elasticsearch + Logstash + Kibana（ELK）是一套開源的日誌管理方案，分析網站的訪問狀況時咱們通常會藉助Google/百度/CNZZ等方式嵌入JS作數據統計，可是當網站訪問異常或者被攻擊時咱們須要在後臺分析如Nginx的具體日誌，而Nginx日誌分割/GoAccess/Awstats都是相對簡單的單節點解決方案，針對分佈式集羣或者數據量級較大時會顯得愛莫能助，而ELK的出現可使咱們從容面對新的挑戰。

Logstash：負責日誌的收集，處理和儲存

Elasticsearch：負責日誌檢索和分析

Kibana：負責日誌的可視化

http://baidu.blog.51cto.com/71938/1676798

四、    如今公司有個計費系統，十分龐大。實時計算出需求用戶的各類指標。

存儲有了hadoop的hdfs，可是mapreduce壓根不對實時數據起做用，ok,storm來了，還有這個：spark

這麼多技術，說個大概吧，他們怎麼組合的。

組合：

    flume-ng+Kafka+Storm+HDFS 實時系統組合

     hadoop：hdfs mapreduce組合

……………………

我該怎麼選擇：spark storm hadoop 什麼關係，怎麼選擇

http://www.aboutyun.com/thread-7569-1-1.html

認識淺顯，歡迎指正