大數據生態圈到底是一個什麼概念?

大數據這個概念本身就太大而且太寬,如果一定要嚴格定義是非常困難的一件事,不過Hadoop生態圈或者由其延伸的泛生態系統,基本上都是為了處理大量數據誕生的——一般而言,這種數據依賴單機很難完成。

這個圈子裏的工具,就像是我們廚房裏的各種廚具——各自都有不同的用處,但也有一部分功能重合,比如盆和豌都可以用來喝湯,削皮刀和菜刀都可以用來去皮。

但是,盆用來喝湯未免奇怪,削皮刀切菜也是萬萬不能。即使你強行要創造一些奇異的組合,即使最終完成工作,卻不一定是最快、最好的選擇。

大數據生態圈到底是一個什麼概念?
大數據生態圈到底是一個什麼概念?

大數據,首先你要能存的下大數據。

對傳統的單機文檔系統來説,橫跨不同機器幾乎是不可能完成的任務。而通過HDFS(Hadoop Distributed FileSystem),你可以通過橫跨上千甚至上萬台機器來完成大量數據得存儲,同時這些數據全部都能歸屬在同一個文檔系統之下。你可以通過引用一個文檔路徑獲取存儲在許多台機器上的數據文檔。作為一個用户,你完全不用去計較文檔具體存儲的位置,這個文檔系統會為你搞定一切。

我們當然不是為了蒐集數據而進行存儲,我們還要用數據做一些事情。雖然我們通過HDFS存下了橫跨上千台機器的數據,我們依然面臨一個問題——這些數據過於龐大,如果只交給一台機器處理,我們可能得等上幾周甚至更長。這些可能以T甚至於P來計量單位的數據,只靠一台機器真的能跑到地老天荒。

對於很多公司,這是無法接受的事情——我們都知道有各種熱度排行,加入一台機器處理這個數據、計算熱度、進行發佈,可能一週之後出來結果,但大家早已經不關心了。

所以使用大量機器進行處理是必然的選擇。在大量機器處理過程中,必須處理一些事務:任務分配、緊急情況處理、信息互通等等,這時候必須引入MapReduce / Tez / Spark 。這其中,前者可以成為計算引擎的第一代產品,後兩者則是經過優化後的下一代。MapReduce採用了非常簡單的計算模型設計,可以説只用了兩個計算的處理過程,但是這個工具已經足夠應付大部分的大數據工作了。

什麼是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小時甚至更長尺度的數據報告,而是一個隨時更新、隨時變化的榜單,這個榜單的更新最好在1分鐘甚至更短,那麼上述手段就無發滿足我的需要。

這時候,另一個工具即將登場——Streaming計算模型。這種模型通常被稱為流計算模型,使用最多的平台式Storm。這種模型會在數據開始蒐集的時候進行計算,而不是在蒐集完成後——你每獲得一個數據都會加入到實時計算中成為最終成果的一份子。這種方式處理的數據基本不會存在延遲問題。

但它並不是盡善盡美。在使用流計算之前,我們必須預先找到統計的核心,因為一段數據經過處理就會放在一邊——正如流過的河水無法倒回一樣——未能提前找到統計核心的時候數據就被浪費掉了。這也是流計算無法完全替代我們前文講過的工具的原因。

另一個比較獨立的工具是KV Store,類似於Cassandra,HBase,MongoDB等等非常非常多的其他東西。他是什麼意思呢,假如你有一堆鍵值,你就能通過某種方式快速獲得鍵值背後的一大堆數據。就好像你去銀行插入銀行卡就能取到錢一樣。

假如你特立獨行,使用MapReduce完成也沒有任何問題,但是由此帶來的不便就是掃描數據庫的時間會很長。如果我們採用了KV Store,這種專門為了鍵值訪問而設定的工具,那這個速度就會非常快。這個工具的核心就是快,其他的事情他一概不管,就是要快。

除此之外,還有一些更特製的系統/組件,比如Mahout是分佈式機器學習庫,Protobuf是數據交換的編碼和庫,ZooKeeper是高一致性的分佈訪問協同系統,等等。

當你拿到這麼多任務具(甚至多到連很多東西的名字都寫不熟練)之後,你把他們拼裝在一起,如果沒有一個完美的安排大家就會互相打架,造成效率低下,所以這個時候還要引入一個調度系統,專門給大家安排任務、安排時間,使系統能夠良好運轉。