“大數據”這個詞兒已經在 IT 圈蔓延到各個領域，如果真要刨根問底的問一句“如何實現大數據分析”，恐怕是 IT
圈裏的好些人也一時半會兒解釋不清楚吧。所以嘗試把大數據分析這個事做個深入淺出的剖析還是很有意義的。仁者見仁智者見智，能力所限，表達如有不準確的地方希望你能用包容的心態多理解和指導。
首先，用5秒鐘的時間掃描一下下面的這段內容吧：
知道上面是一段日誌文件的片段的請舉手。敢問閣下您是一位受人尊敬的碼農吧？
看上面內容像天書的請舉手。請不要懷疑自己的能力，證明你是一個正常人，你的人生依然充滿希望和光明。
如果把上面的日誌信息歸納如下，看起來是不是有點感覺了。
每當你訪問一個網站時，從你打開網站首頁開始，到你離開那個網站，只要網站願意，你的一舉一動就會不停的產生類似上面這樣日誌記錄，無數人的訪問會產生大量的訪問記錄，這個網站的“用戶訪問情況大數據”就這樣產生了。
接着思考，這些用戶訪問情況的大數據有什麼價值呢？
沒錯！做網站用戶行爲分析呀，瞭解用戶在網站上的動向、喜好，然後給用戶推薦更他更有可能感興趣的內容，爲網站的運營決策提供數據參考等等，這個過程用一句帶點技術範兒的話總結就是：“日誌掘金“。
日誌掘金就是大數據分析的一個具體的應用場景。因爲原始的日誌文件（數據源）的信息是大而全的，而且結構有些複雜不易讀懂，所以日誌掘金就像淘金一樣，從茫茫的數據海洋中，通過過濾、清洗，篩出有價值的關鍵信息—— KPI（黃金）。
那麼繼續思考，如何通過技術實現從“數據源”過濾出“KPI”呢？下面是一個簡要的數據掘金流程圖，請稍微耐點心看看（圖下的文字解讀會讓你柳暗花明又一村）：
用戶上網產生的行爲被“日誌文件”記錄下來，因爲網站的訪問量很大，所以產生的日誌文件也很大，爲了能夠更高效的對這個文件進行分析，所以把它保存到一個叫“
HDFS
”的分佈式文件系統中。這個過程中一份完整的“日誌文件”會被拆分成n個小文件（按照每個小文件64MB等分），拆分後的每個小文件會再複製2個備份（n個小文件就變成了3n個），然後將這些小文件保存到“
HDFS
”系統的劃分出來的存儲節點上（一個存儲節點可以簡單理解爲一臺電腦），保存的過程中同一份小文件和它的拷貝要保存在不同的存儲節點上（目的是爲了防止某幾臺電腦壞了，沒有備份的話就會造成文件缺失）。
008.png953x550 55.5 KB
通過上面的過程，接下來從一個大日誌文件中查找數據就演變爲可以利用一羣計算節點（計算機），同時從n個小文件中並行的查找數據了，然後再將每個節點查找的結果進行合併彙總，這個過程就是 MapReduce 數據清洗。
這個過程有點複雜，舉個栗子：從一個包含一組單詞的文件中（理解爲“日誌文件”）統計每個單詞出現的次數。首先將一個大文件拆分爲三個小文件，然後分別統計每個小文件中每個單詞出現的次數，最後彙總每個小文件統計的結果。具體如下圖所示：
經過 MapReduce 數據清洗之後，從一個數據結構不規則、大而全的日誌文件中提取出需要的關鍵指標數據了，請注意提取後的數據依然保存在
HDFS
中。再深入思考一下，如何從提取後的數據進行統計呢？這個時候可以有多種方案了，下圖例舉了2個方案，這兩個方案我們不展開詳細說明了，總而言之是能夠從
HDFS 中進行數據的統計了。
最後再思考一個問題：既然已經能夠統計分析了，爲什麼還要再多此一舉將 HDFS 中的數據導入到 HBase 和 MySQL 數據庫中呢？這不是畫蛇添足嗎？
這是因爲需要把數據統計分析的結果和數據明細能夠方便的提供給別人（比如：前端開發同學）去使用，滿足別人坐享其成的快感！
舉個栗子吧：
小馬不懂大數據底層技術，但他在百度上找到了一個叫“圖表秀”的數據可視化分析軟件。他請團隊的技術大牛將公司產品網站運行的大數據進行採集、清洗，將網站
KPI 數據保存到本地的一個數據庫中，這樣每次給領導做月度彙報時，他就熟練的利用“圖表秀”來製作各種豐富多樣的數據圖表。
其實，上面這個日誌分析的過程還是蠻複雜的，市面上有一些專業的日誌分析軟件將數據採集、清洗、統計、可視化分析的過程做成了成熟的軟件產品，這就降低了技術門檻，提升了日誌掘金的效率。比較知名的有 SaCa DataInsight。（登陸網站，瞭解更多內容：https://platform.neusoft.com）