[大數據]一個大數據的故事

大數據自己是個很寬泛的概念，Hadoop生態圈（或者泛生態圈）基本上都是爲了處理超過單機尺度的數據處理而誕生的；

大數據，首先你要能存的下大數據。
傳統的文件系統是單機的，不能橫跨不一樣的機器。HDFS（Hadoop Distributed FileSystem）的設計本質上是爲了大量的數據能橫跨成百上千臺機器，可是你看到的是一個文件系統而不是不少文件系統。好比你說我要獲取/hdfs/tmp/file1的數據，你引用的是一個文件路徑，可是實際的數據存放在不少不一樣的機器上。你做爲用戶，不須要知道這些，就比如在單機上你不關心文件分散在什麼磁道什麼扇區同樣。HDFS爲你管理這些數據。

存的下數據以後，你就開始考慮怎麼處理數據。雖然HDFS能夠爲你總體管理不一樣機器上的數據，可是這些數據太大了。一臺機器讀取成T上P的數據（很大的數據哦，好比整個東京熱有史以來全部高清電影的大小甚至更大），一臺機器慢慢跑也許須要好幾天甚至好幾周。對於不少公司來講，單機處理是不可忍受的，好比微博要更新24小時熱博，它必須在24小時以內跑完這些處理。那麼我若是要用不少臺機器處理，我就面臨瞭如何分配工做，若是一臺機器掛了如何從新啓動相應的任務，機器之間如何互相通訊交換數據以完成複雜的計算等等。這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經能夠處理大數據領域很大一部分問題了;

有了MapReduce，Tez和Spark以後，程序員發現，MapReduce的程序寫起來真麻煩。他們但願簡化這個過程。這就比如你有了彙編語言，雖然你幾乎什麼都能幹了，可是你仍是以爲繁瑣。你但願有個更高層更抽象的語言層來描述算法和數據處理流程。因而就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算，而你就從繁瑣的MapReduce程序中解脫出來，用更簡單更直觀的語言去寫程序了

有了Hive以後，人們發現SQL對比Java有巨大的優點。一個是它太容易寫了。剛纔詞頻的東西，用SQL描述就只有一兩行，MapReduce寫起來大約要幾十上百行。而更重要的是，非計算機背景的用戶終於感覺到了愛：我也會寫SQL！因而數據分析人員終於從乞求工程師幫忙的窘境解脫出來，工程師也從寫奇怪的一次性的處理程序中解脫出來。你們都開心了。Hive逐漸成長成了大數據倉庫的核心組件。甚至不少公司的流水線做業集徹底是用SQL描述，由於易寫易改，一看就懂，容易維護。

自從數據分析人員開始用Hive分析數據以後，它們發現，Hive在MapReduce上跑，真雞巴慢！流水線做業集也許沒啥關係，好比24小時更新的推薦，反正24小時內跑完就算了。可是數據分析，人們老是但願能跑更快一些。好比我但願看過去一個小時內多少人在充氣娃娃頁面駐足，分別停留了多久，對於一個巨型網站海量數據下，這個處理過程也許要花幾十分鐘甚至不少小時。而這個分析也許只是你萬里長征的第一步，你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD，以便跟老闆彙報，咱們的用戶是猥瑣男悶騷女更多仍是文藝青年／少女更多。你沒法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說，快，快，再快一點！
因而Impala，Presto，Drill誕生了（固然還有無數非著名的交互SQL引擎，就不一一列舉了）。三個系統的核心理念是，MapReduce引擎太慢，由於它太通用，太強壯，太保守，咱們SQL須要更輕量，更激進地獲取資源，更專門地對SQL作優化，並且不須要那麼多容錯性保證（由於系統出錯了大不了從新啓動任務，若是整個處理時間更短的話，好比幾分鐘以內）。這些系統讓用戶更快速地處理SQL任務，犧牲了通用性穩定性等特性。若是說MapReduce是大砍刀，砍啥都不怕，那上面三個就是剔骨刀，靈巧鋒利，可是不能搞太大太硬的東西。

若是我是一個相似微博的公司，我但願顯示不是24小時熱博，我想看一個不斷變化的熱播榜，更新延遲在一分鐘以內，上面的手段都將沒法勝任。因而又一種計算模型被開發出來，這就是Streaming（流）計算。Storm是最流行的流計算平臺。流計算的思路是，若是要達到更實時的更新，我何不在數據流進來的時候就處理了？好比仍是詞頻統計的例子，個人數據流是一個一個的詞，我就讓他們一邊流過我就一邊開始統計了。流計算很牛逼，基本無延遲，可是它的短處是，不靈活，你想要統計的東西必須預先知道，畢竟數據流過就沒了，你沒算的東西就沒法補算了。所以它是個很好的東西，可是沒法替代上面數據倉庫和批處理系統。

 

故事還在繼續………………