瞭解大資料的技術生態系統 Hadoop,hive,spark(轉載)

標籤：

首先給出原文連結： 原文連結

大資料本身是一個很寬泛的概念，Hadoop生態圈（或者泛生態圈）基本上都是為了處理超過單機尺度的資料處理而誕生的。你能夠把它比作一個廚房所以須要的各種工具。

鍋碗瓢盆，各有各的用處。互相之間又有重合。你能夠用湯鍋直接當碗吃飯喝湯，你能夠用小刀或者刨子去皮。

可是每一個工具有自己的特性，儘管奇怪的組合也能工作，可是未必是最佳選擇。

大資料，首先你要能存的下大資料。

傳統的檔案系統是單機的，不能橫跨不同的機器。

HDFS（Hadoop Distributed File System）的設計本質上是為了大量的資料能橫跨成百上千台機器，可是你看到的是一個檔案系統而不是非常多檔案系統。比方你說我要擷取/hdfs/tmp/file1的資料，你引用的是一個檔案路徑，可是實際的資料存放在非常多不同的機器上。你作為使用者。不須要知道這些，就好比在單機上你不關心檔案分散在什麼磁軌什麼扇區一樣。

HDFS為你管理這些資料。

存下的資料之後，你就開始考慮怎麼處理資料。儘管HDFS能夠為你總體管理不同機器上的資料，可是這些資料太大了。

一台機器讀取成T上P的資料（非常大的資料哦。比方整個東京熱有史以來全部高畫質 DVD的大小甚至更大）。一台機器慢慢跑或許須要好幾天甚至好幾周。對於非常多公司來說，單機處理是不可忍受的，比方微博要更新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都如上處理，你就得到了整個檔案的詞頻結果。

這看似是個非常easy的模型，但非常多演算法都能夠用這個模型描寫敘述了。

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有巨大的優勢。一個是它太easy寫了。

剛才詞頻的東西。用SQL描寫敘述就僅僅有一兩行，MapReduce寫起來大約要幾十上百行。而更重要的是，非電腦背景的使用者最終感受到了愛：我也會寫SQL。於是資料分析人員最終從乞求project師幫忙的窘境解脫出來，project師也從寫奇怪的一次性的處理常式中解脫出來。

大家都開心了。Hive逐漸成長成了大資料倉儲的核心組件。甚至非常多公司的流水線作業集全然是用SQL描寫敘述。由於易寫易改，一看就懂，easy維護。

自從資料分析人員開始用Hive分析資料之後，它們發現，Hive在MapReduce上跑。太慢了！流水線作業集或許沒啥關係，比方24小時更新的推薦，反正24小時內跑完就算了。可是資料分析，人們總是希望能跑更快一些。比方我希望看過去一個小時內多少人在可穿戴手環頁面駐足。分別停留了多久。對於一個巨型網站海量資料下，這個處理過程或許要花幾十分鐘甚至非常多小時。而這個分析或許僅僅是你萬裡長征的第一步，你還要看多少人瀏覽了電子產品多少人看了拉赫曼尼諾夫的CD，以便跟老闆彙報。我們的使用者是屌絲男悶騷女很多其它還是文藝青年／少女很多其它。你無法忍受等待的折磨，僅僅能跟project師說。快。快，再快一點。

於是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是最流行的StreamCompute平台。StreamCompute的思路是。假設要達到更即時的更新，我何不在資料流進來的時候就處理了？比方還是詞頻統計的範例。我的資料流是一個一個的詞，我就讓他們一邊流過我就一邊開始統計了。

StreamCompute非常牛逼，基本無延遲，可是它的短處是。不靈活。你想要統計的東西必須預Crowdsourced Security Testing道，畢竟資料流過就沒了。你沒算的東西就無法補算了。因此它是個非常好的東西。可是無法替代上面資料倉儲和批處理系統。

另一個有些獨立的模組是KV Store，比方Cassandra。HBase。MongoDB以及非常多非常多非常多非常多其它的（多到無法想象）。所以KV Store就是說，我有一堆索引值，我能非常快速滴擷取與這個Key繫結資料。比方我用社會安全號碼，能取到你的身份資料。這個動作用MapReduce也能完畢。可是非常可能要掃描整個資料集。而KV Store專用來處理這個操作，全部存和取都專門為此最佳化了。從幾個P的資料中尋找一個社會安全號碼，或許僅僅要零點幾秒。這讓大資料公司的一些專門操作被大大最佳化了。比方我網頁上有個根據訂單號尋找訂單內容的頁面，而整個網站的訂單數量無法單機資料庫儲存，我就會考慮用KV Store來存。KV Store的理念是，基本無法處理複雜的計算。大多沒法JOIN。或許沒法彙總。沒有強一致性保證（不同資料分布在不同機器上。你每次讀取或許會讀到不同的結果，也無法處理相似銀行轉賬那樣的強一致性要求的操作）。

可是丫就是快。極快。

每一個不同的KV Store設計都有不同取捨，有些更快，有些容量更高，有些能夠支援更複雜的操作。必有一款適合你。
除此之外。另一些更特製的系統／組件，比方Mahout是分布式機器學習庫，Protobuf是資料交換的編碼和庫，ZooKeeper是高一致性的分布存取協同系統，等等。

有了這麼多亂七八糟的工具。都在同一個叢集上運轉，大家須要互相尊重有序工作。

所以另外一個重要組件是，調度系統。如今最流行的是Yarn。

你能夠把他看作中央管理，好比你媽在廚房監工，哎，你妹妹切菜切完了，你能夠把刀拿去殺雞了。

僅僅要大家都服從你媽分配，那大家都能愉快滴燒菜。

你能夠覺得，大資料生態圈就是一個廚房工具生態圈。為了做不同的菜。中國菜。日本菜，法國菜，你須要各種不同的工具。

並且客人的需求正在複雜化。你的廚具不斷被發明，也沒有一個萬用的廚具能夠處理全部情況，因此它會變的越來越複雜。

著作權聲明：本文部落格原創文章。部落格，未經同意，不得轉載。

瞭解大資料的技術生態系統 Hadoop,hive,spark(轉載)