[大資料概念]-- 大資料的技術生态比喻

作者：Xiaoyu Ma

    大資料本身是個很寬泛的概念，Hadoop生态圈（或者泛生态圈）基本上都是為了處理超過單機尺度的資料處理而誕生的。

你可以把它比作一個廚房是以需要的各種工具。鍋碗瓢盆，各有各的用處，互相之間又有重合。你可以用湯鍋直接當碗吃飯喝湯，

你可以用小刀或者刨子去皮。但是每個工具有自己的特性，雖然奇怪的組合也能工作，但是未必是最佳選擇。

大資料，首先你要能存的下大資料。傳統的檔案系統是單機的，不能橫跨不同的機器。

    HDFS（Hadoop Distributed FileSystem）的設計本質上是為了大量的資料能橫跨成百上千台機器，但是你看到的是一個檔案系統而不是

很多檔案系統。比如你說我要擷取/hdfs/tmp/file1的資料，你引用的是一個檔案路徑，但是實際的資料存放在很多不同的機器上。

你作為使用者，不需要知道這些，就好比在單機上你不關心檔案分散在什麼磁道什麼扇區一樣。

    HDFS為你管理這些資料。存的下資料之後，你就開始考慮怎麼處理資料。雖然HDFS可以為你整體管理不同機器上的資料，但是這些資料太大了。

一台機器讀取成T上P的資料（很大的資料哦，比如整個東京熱有史以來所有高清電影的大小甚至更大），一台機器慢慢跑也許需要好幾天甚至好

幾周。對于很多公司來說，單機處理是不可忍受的，比如微網誌要更新24小時熱博，它必須在24小時之内跑完這些處理。

那麼我如果要用很多台機器處理，我就面臨了如何配置設定工作，如果一台機器挂了如何重新啟動相應的任務，

機器之間如何互相通信交換資料以完成複雜的計算等等。

    這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，采用了很簡化的計算模型，

隻有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經可以處理大資料領域很大一部分問題了。

    那什麼是Map什麼是Reduce？考慮如果你要統計一個巨大的文本檔案存儲在類似HDFS上，你想要知道這個文本裡各個詞的出現頻率。

你啟動了一個MapReduce程式。

    Map階段，幾百台機器同時讀取這個檔案的各個部分，分别把各自讀到的部分分别統計出詞頻，産生類似（hello, 12100次），

（world，15214次）等等這樣的Pair（我這裡把Map和Combine放在一起說以便簡化）；這幾百台機器各自都産生了如上的集合，

然後又有幾百台機器啟動Reduce處理。Reducer機器A将從Mapper機器收到所有以A開頭的統計結果，機器B将收到B

開頭的詞彙統計結果（當然實際上不會真的以字母開頭做依據，而是用函數産生Hash值以避免資料串化。

因為類似X開頭的詞肯定比其他要少得多，而你不希望資料處理各個機器的工作量相差懸殊）。

    然後這些Reducer将再次彙總，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每個Reducer都如上處理，

你就得到了整個檔案的詞頻結果。這看似是個很簡單的模型，但很多算法都可以用這個模型描述了。Map＋Reduce的簡單模型很黃很暴力，

雖然好用，但是很笨重。第二代的Tez和Spark除了記憶體Cache之類的新feature，本質上來說，是讓Map/Reduce模型更通用，

讓Map和Reduce之間的界限更模糊，資料交換更靈活，更少的磁盤讀寫，以便更友善地描述複雜算法，取得更高的吞吐量。

    有了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是大砍刀，砍啥都不怕，那上面三個就是剔骨刀，靈巧鋒利，

但是不能搞太大太硬的東西。這些系統，說實話，一直沒有達到人們期望的流行度。

   因為這時候又兩個異類被造出來了。他們是Hive on Tez / Spark和SparkSQL。它們的設計理念是，MapReduce慢，但是如果我用新一代通用計算引擎Tez

或者Spark來跑SQL，那我就能跑的更快。而且使用者不需要維護兩套系統。這就好比如果你廚房小，人又懶，對吃的精細程度要求有限，那你可以買個

電鍋，能蒸能煲能燒，省了好多廚具。上面的介紹，基本就是一個資料倉庫的構架了。

   底層HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。這解決了中

低速資料處理的要求。那如果我要更高速的處理呢？如果我是一個類似微網誌的公司，我希望顯示不是24小時熱博，我想看一個不斷變化的熱播榜，

更新延遲在一分鐘之内，上面的手段都将無法勝任。于是又一種計算模型被開發出來，這就是Streaming（流）計算。

   Storm是最流行的流計算平台。流計算的思路是，如果要達到更實時的更新，我何不在資料流進來的時候就處理了？

比如還是詞頻統計的例子，我的資料流是一個一個的詞，我就讓他們一邊流過我就一邊開始統計了。流計算很牛逼，基本無延遲，但是它的短處是，

不靈活，你想要統計的東西必須預先知道，畢竟資料流過就沒了，你沒算的東西就無法補算了。是以它是個很好的東西，但是

無法替代上面資料倉庫和批處理系統。還有一個有些獨立的子產品是KV Store，比如Cassandra，HBase，MongoDB

以及很多很多很多很多其他的（多到無法想象）。是以KV Store就是說，我有一堆鍵值，我能很快速滴擷取與這個Key綁定的資料。

比如我用身份證号，能取到你的身份資料。

    這個動作用MapReduce也能完成，但是很可能要掃描整個資料集。而KV Store專用來處理這個操作，所有存和取都專門為此優化了。

從幾個P的資料中查找一個身份證号，也許隻要零點幾秒。這讓大資料公司的一些專門操作被大大優化了。

比如我網頁上有個根據訂單号查找訂單内容的頁面，而整個網站的訂單數量無法單機資料庫存儲，我就會考慮用KV Store來存。

    KV Store的理念是，基本無法處理複雜的計算，大多沒法JOIN，也許沒法聚合，沒有強一緻性保證（不同資料分布在不同機器上，你每次

讀取也許會讀到不同的結果，也無法處理類似銀行轉賬那樣的強一緻性要求的操作）。但是丫就是快。極快。

    每個不同的KV Store設計都有不同取舍，有些更快，有些容量更高，有些可以支援更複雜的操作。必有一款

适合你。除此之外，還有一些更特制的系統／元件，比如Mahout是分布式機器學習庫，Protobuf是資料交換的編碼和庫，ZooKeeper是高一緻性的分布存取協同系統，等等。

    有了這麼多亂七八糟的工具，都在同一個叢集上運轉，大家需要互相尊重有序工作。是以另外一個重要元件是，排程系統。

現在最流行的是Yarn。你可以把他看作中央管理，好比你媽在廚房監工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。

    隻要大家都服從你媽配置設定，那大家都能愉快滴燒菜。你可以認為，大資料生态圈就是一個廚房工具生态圈。為了做不同的菜，中國菜，日本

菜，法國菜，你需要各種不同的工具。而且客人的需求正在複雜化，你的廚具不斷被發明，也沒有一個萬用

的廚具可以處理所有情況，是以它會變的越來越複雜。