10分鐘讓你明白大數(shù)據(jù) 網(wǎng)友觀點(diǎn)大拆解

大數(shù)據(jù)的概念被吵的越來(lái)越厲害，這對(duì)于一個(gè)新技術(shù)領(lǐng)域的誕生是一個(gè)必經(jīng)過(guò)程。對(duì)于“大數(shù)據(jù)”(Big Data)，研究機(jī)構(gòu)Gartner給出的定義是：“大數(shù)據(jù)”是需要新處理模式才能具有更強(qiáng)的決策力、洞察發(fā)現(xiàn)力和流程優(yōu)化能力的海量、高增長(zhǎng)率和多樣化的信息資產(chǎn)。

　　兩年前，《紐約時(shí)報(bào)》撰文“歡迎大數(shù)據(jù)的到來(lái)”，兩年后，大數(shù)據(jù)的商業(yè)價(jià)值已經(jīng)顯現(xiàn)。在各個(gè)行業(yè)，我們都已能看到大數(shù)據(jù)的身影。網(wǎng)友關(guān)于大數(shù)據(jù)生態(tài)這一話題也進(jìn)行了生動(dòng)激烈的探討，一起來(lái)看看他們的觀點(diǎn)吧!

　　xiaoyu Ma：大數(shù)據(jù)的討論，大數(shù)據(jù)本身是個(gè)很寬泛的概念，Hadoop生態(tài)圈(或者泛生態(tài)圈)基本上都是為了處理超過(guò)單機(jī)尺度的數(shù)據(jù)處理而誕生的。你可以把它比作一個(gè)廚房所以需要的各種工具。鍋碗瓢盆，各有各的用處，互相之間又有重合。你可以用湯鍋直接當(dāng)碗吃飯喝湯，你可以用小刀或者刨子去皮。但是每個(gè)工具有自己的特性，雖然奇怪的組合也能工作，但是未必是最佳選擇。

　　大數(shù)據(jù)，首先你要能存的下大數(shù)據(jù)。

　　傳統(tǒng)的文件系統(tǒng)是單機(jī)的，不能橫跨不同的機(jī)器。HDFS(Hadoop Distributed FileSystem)的設(shè)計(jì)本質(zhì)上是為了大量的數(shù)據(jù)能橫跨成百上千臺(tái)機(jī)器，但是你看到的是一個(gè)文件系統(tǒng)而不是很多文件系統(tǒng)。比如你說(shuō)我要獲取/hdfs /tmp/file1的數(shù)據(jù)，你引用的是一個(gè)文件路徑，但是實(shí)際的數(shù)據(jù)存放在很多不同的機(jī)器上。你作為用戶(hù)，不需要知道這些，就好比在單機(jī)上你不關(guān)心文件分散在什么磁道什么扇區(qū)一樣。HDFS為你管理這些數(shù)據(jù)。

　　存的下數(shù)據(jù)之后，你就開(kāi)始考慮怎么處理數(shù)據(jù)。雖然HDFS可以為你整體管理不同機(jī)器上的數(shù)據(jù)，但是這些數(shù)據(jù)太大了。一臺(tái)機(jī)器讀取成T上P的數(shù)據(jù)(很大的數(shù)據(jù)哦，比如整個(gè)東京熱有史以來(lái)所有高清電影的大小甚至更大)，一臺(tái)機(jī)器慢慢跑也許需要好幾天甚至好幾周。對(duì)于很多公司來(lái)說(shuō)，單機(jī)處理是不可忍受的，比如微博要更新24小時(shí)熱博，它必須在24小時(shí)之內(nèi)跑完這些處理。那么我如果要用很多臺(tái)機(jī)器處理，我就面臨了如何分配工作，如果一臺(tái)機(jī)器掛了如何重新啟動(dòng)相應(yīng)的任務(wù)，機(jī)器之間如何互相通信交換數(shù)據(jù)以完成復(fù)雜的計(jì)算等等。這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計(jì)算引擎，Tez和Spark是第二代。MapReduce的設(shè)計(jì)，采用了很簡(jiǎn)化的計(jì)算模型，只有Map和 Reduce兩個(gè)計(jì)算過(guò)程(中間用Shuffle串聯(lián))，用這個(gè)模型，已經(jīng)可以處理大數(shù)據(jù)領(lǐng)域很大一部分問(wèn)題了。

　　那什么是Map什么是Reduce?

　　考慮如果你要統(tǒng)計(jì)一個(gè)巨大的文本文件存儲(chǔ)在類(lèi)似HDFS上，你想要知道這個(gè)文本里各個(gè)詞的出現(xiàn)頻率。你啟動(dòng)了一個(gè)MapReduce程序。Map階段，幾百臺(tái)機(jī)器同時(shí)讀取這個(gè)文件的各個(gè)部分，分別把各自讀到的部分分別統(tǒng)計(jì)出詞頻，產(chǎn)生類(lèi)似(hello, 12100次)，(world，15214次)等等這樣的Pair(我這里把Map和Combine放在一起說(shuō)以便簡(jiǎn)化);這幾百臺(tái)機(jī)器各自都產(chǎn)生了如上的集合，然后又有幾百臺(tái)機(jī)器啟動(dòng)Reduce處理。Reducer機(jī)器A將從Mapper機(jī)器收到所有以A開(kāi)頭的統(tǒng)計(jì)結(jié)果，機(jī)器B將收到B開(kāi)頭的詞匯統(tǒng)計(jì)結(jié)果(當(dāng)然實(shí)際上不會(huì)真的以字母開(kāi)頭做依據(jù)，而是用函數(shù)產(chǎn)生Hash值以避免數(shù)據(jù)串化。因?yàn)轭?lèi)似X開(kāi)頭的詞肯定比其他要少得多，而你不希望數(shù)據(jù)處理各個(gè)機(jī)器的工作量相差懸殊)。然后這些Reducer將再次匯總，(hello，12100)+(hello，12311)+(hello，345881)= (hello，370292)。每個(gè)Reducer都如上處理，你就得到了整個(gè)文件的詞頻結(jié)果。

　　這看似是個(gè)很簡(jiǎn)單的模型，但很多算法都可以用這個(gè)模型描述了。

　　Map+Reduce 的簡(jiǎn)單模型很黃很暴力，雖然好用，但是很笨重。第二代的Tez和Spark除了內(nèi)存Cache之類(lèi)的新feature，本質(zhì)上來(lái)說(shuō)，是讓 Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，數(shù)據(jù)交換更靈活，更少的磁盤(pán)讀寫(xiě)，以便更方便地描述復(fù)雜算法，取得更高的吞吐量。

　　有了MapReduce，Tez和Spark之后，程序員發(fā)現(xiàn)，MapReduce的程序?qū)懫饋?lái)真麻煩。他們希望簡(jiǎn)化這個(gè)過(guò)程。這就好比你有了匯編語(yǔ)言，雖然你幾乎什么都能干了，但是你還是覺(jué)得繁瑣。你希望有個(gè)更高層更抽象的語(yǔ)言層來(lái)描述算法和數(shù)據(jù)處理流程。于是就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語(yǔ)言翻譯成MapReduce程序，丟給計(jì)算引擎去計(jì)算，而你就從繁瑣的 MapReduce程序中解脫出來(lái)，用更簡(jiǎn)單更直觀的語(yǔ)言去寫(xiě)程序了。

　　有了Hive之后，人們發(fā)現(xiàn)SQL對(duì)比Java有巨大的優(yōu)勢(shì)。一個(gè)是它太容易寫(xiě)了。剛才詞頻的東西，用SQL描述就只有一兩行，MapReduce寫(xiě)起來(lái)大約要幾十上百行。而更重要的是，非計(jì)算機(jī)背景的用戶(hù)終于感受到了愛(ài)：我也會(huì)寫(xiě)SQL!于是數(shù)據(jù)分析人員終于從乞求工程師幫忙的窘境解脫出來(lái)，工程師也從寫(xiě)奇怪的一次性的處理程序中解脫出來(lái)。大家都開(kāi)心了。Hive逐漸成長(zhǎng)成了大數(shù)據(jù)倉(cāng)庫(kù)的核心組件。甚至很多公司的流水線作業(yè)集完全是用SQL描述，因?yàn)橐讓?xiě)易改，一看就懂，容易維護(hù)。

　　自從數(shù)據(jù)分析人員開(kāi)始用Hive分析數(shù)據(jù)之后，它們發(fā)現(xiàn)，Hive在MapReduce上跑，真的太慢!流水線作業(yè)集也許沒(méi)啥關(guān)系，比如24小時(shí)更新的推薦，反正24小時(shí)內(nèi)跑完就算了。但是數(shù)據(jù)分析，人們總是希望能跑更快一些。比如我希望看過(guò)去一個(gè)小時(shí)內(nèi)多少人在充氣娃娃頁(yè)面駐足，分別停留了多久，對(duì)于一個(gè)巨型網(wǎng)站海量數(shù)據(jù)下，這個(gè)處理過(guò)程也許要花幾十分鐘甚至很多小時(shí)。而這個(gè)分析也許只是你萬(wàn)里長(zhǎng)征的第一步，你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD，以便跟老板匯報(bào)，我們的用戶(hù)是猥瑣男悶騷女更多還是文藝青年/少女更多。你無(wú)法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說(shuō)，快，快，再快一點(diǎn)!

　　于是Impala，Presto，Drill誕生了(當(dāng)然還有無(wú)數(shù)非著名的交互SQL引擎，就不一一列舉了)。三個(gè)系統(tǒng)的核心理念是，MapReduce引擎太慢，因?yàn)樗ㄓ?，太?qiáng)壯，太保守，我們SQL需要更輕量，更激進(jìn)地獲取資源，更專(zhuān)門(mén)地對(duì)SQL做優(yōu)化，而且不需要那么多容錯(cuò)性保證(因?yàn)橄到y(tǒng)出錯(cuò)了大不了重新啟動(dòng)任務(wù)，如果整個(gè)處理時(shí)間更短的話，比如幾分鐘之內(nèi))。這些系統(tǒng)讓用戶(hù)更快速地處理SQL任務(wù)，犧牲了通用性穩(wěn)定性等特性。如果說(shuō) MapReduce是大砍刀，砍啥都不怕，那上面三個(gè)就是剔骨刀，靈巧鋒利，但是不能搞太大太硬的東西。

　　這些系統(tǒng)，說(shuō)實(shí)話，一直沒(méi)有達(dá)到人們期望的流行度。因?yàn)檫@時(shí)候又兩個(gè)異類(lèi)被造出來(lái)了。他們是Hive on Tez / Spark和SparkSQL。它們的設(shè)計(jì)理念是，MapReduce慢，但是如果我用新一代通用計(jì)算引擎Tez或者Spark來(lái)跑SQL，那我就能跑的更快。而且用戶(hù)不需要維護(hù)兩套系統(tǒng)。這就好比如果你廚房小，人又懶，對(duì)吃的精細(xì)程度要求有限，那你可以買(mǎi)個(gè)電飯煲，能蒸能煲能燒，省了好多廚具。

　　上面的介紹，基本就是一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)架了。底層HDFS，上面跑MapReduce/Tez/Spark，在上面跑Hive，Pig?；蛘?a href='/map/hdfs/' style='color:#000;font-size:inherit;'>HDFS上直接跑Impala，Drill，Presto。這解決了中低速數(shù)據(jù)處理的要求。

　　那如果我要更高速的處理呢?

　　如果我是一個(gè)類(lèi)似微博的公司，我希望顯示不是24小時(shí)熱博，我想看一個(gè)不斷變化的熱播榜，更新延遲在一分鐘之內(nèi)，上面的手段都將無(wú)法勝任。于是又一種計(jì)算模型被開(kāi)發(fā)出來(lái)，這就是Streaming(流)計(jì)算。Storm是最流行的流計(jì)算平臺(tái)。流計(jì)算的思路是，如果要達(dá)到更實(shí)時(shí)的更新，我何不在數(shù)據(jù)流進(jìn)來(lái)的時(shí)候就處理了?比如還是詞頻統(tǒng)計(jì)的例子，我的數(shù)據(jù)流是一個(gè)一個(gè)的詞，我就讓他們一邊流過(guò)我就一邊開(kāi)始統(tǒng)計(jì)了。流計(jì)算很牛逼，基本無(wú)延遲，但是它的短處是，不靈活，你想要統(tǒng)計(jì)的東西必須預(yù)先知道，畢竟數(shù)據(jù)流過(guò)就沒(méi)了，你沒(méi)算的東西就無(wú)法補(bǔ)算了。因此它是個(gè)很好的東西，但是無(wú)法替代上面數(shù)據(jù)倉(cāng)庫(kù)和批處理系統(tǒng)。

　　還有一個(gè)有些獨(dú)立的模塊是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的(多到無(wú)法想象)。所以KV Store就是說(shuō)，我有一堆鍵值，我能很快速滴獲取與這個(gè)Key綁定的數(shù)據(jù)。比如我用身份證號(hào)，能取到你的身份數(shù)據(jù)。這個(gè)動(dòng)作用MapReduce也能完成，但是很可能要掃描整個(gè)數(shù)據(jù)集。而KV Store專(zhuān)用來(lái)處理這個(gè)操作，所有存和取都專(zhuān)門(mén)為此優(yōu)化了。從幾個(gè)P的數(shù)據(jù)中查找一個(gè)身份證號(hào)，也許只要零點(diǎn)幾秒。這讓大數(shù)據(jù)公司的一些專(zhuān)門(mén)操作被大大優(yōu)化了。比如我網(wǎng)頁(yè)上有個(gè)根據(jù)訂單號(hào)查找訂單內(nèi)容的頁(yè)面，而整個(gè)網(wǎng)站的訂單數(shù)量無(wú)法單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)，我就會(huì)考慮用KV Store來(lái)存。KV Store的理念是，基本無(wú)法處理復(fù)雜的計(jì)算，大多沒(méi)法JOIN，也許沒(méi)法聚合，沒(méi)有強(qiáng)一致性保證(不同數(shù)據(jù)分布在不同機(jī)器上，你每次讀取也許會(huì)讀到不同的結(jié)果，也無(wú)法處理類(lèi)似銀行轉(zhuǎn)賬那樣的強(qiáng)一致性要求的操作)。但是丫就是快。極快。

　　每個(gè)不同的KV Store設(shè)計(jì)都有不同取舍，有些更快，有些容量更高，有些可以支持更復(fù)雜的操作。必有一款適合你。

　　除此之外，還有一些更特制的系統(tǒng)/組件，比如Mahout是分布式機(jī)器學(xué)習(xí)庫(kù)，Protobuf是數(shù)據(jù)交換的編碼和庫(kù)，ZooKeeper是高一致性的分布存取協(xié)同系統(tǒng)，等等。

　　有了這么多亂七八糟的工具，都在同一個(gè)集群上運(yùn)轉(zhuǎn)，大家需要互相尊重有序工作。所以另外一個(gè)重要組件是，調(diào)度系統(tǒng)?，F(xiàn)在最流行的是Yarn。你可以把他看作中央管理，好比你媽在廚房監(jiān)工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。只要大家都服從你媽分配，那大家都能愉快滴燒菜。

　　你可以認(rèn)為，大數(shù)據(jù)生態(tài)圈就是一個(gè)廚房工具生態(tài)圈。為了做不同的菜，中國(guó)菜，日本菜，法國(guó)菜，你需要各種不同的工具。而且客人的需求正在復(fù)雜化，你的廚具不斷被發(fā)明，也沒(méi)有一個(gè)萬(wàn)用的廚具可以處理所有情況，因此它會(huì)變的越來(lái)越復(fù)雜。

　　夏磊洲：大數(shù)據(jù)應(yīng)用領(lǐng)域總結(jié)來(lái)講分為離線計(jì)算和實(shí)時(shí)計(jì)算。隨著數(shù)據(jù)量的增加，OLTP模式已經(jīng)難以勝任，于是OLAP逐漸成為主流。無(wú)論是實(shí)時(shí)計(jì)算還是離線計(jì)算，基本思想是相同的，即：分而治之。大型互聯(lián)網(wǎng)公司，單次業(yè)務(wù)需處理的數(shù)據(jù)量達(dá)到在TB級(jí)以上時(shí)，仿佛三維世界的小人不小心踏進(jìn)了四維空間碎片，就像星際穿越里的那位哥們，一切記憶中非常簡(jiǎn)單的事物此時(shí)都變得異常復(fù)雜。復(fù)雜到用diff來(lái)比較兩個(gè)文件都變得十分困難，復(fù)雜到我們給文件里地?cái)?shù)據(jù)排個(gè)序都似乎變得不可能。此時(shí)，我們就像浪潮之巔里地弄潮兒，不知不覺(jué)間遇到了技術(shù)瓶頸。我們想呼救，發(fā)現(xiàn)眾屌絲比我們還挫，我們?cè)噲D突破，但總是不盡如人意，有些人想到了用超大型計(jì)算機(jī)，然而處理結(jié)果還是跟不上數(shù)據(jù)量的增加，好痛苦，好無(wú)助....

　　然而就在此時(shí)，仿佛晴天一聲霹靂，谷歌的三篇論文給我們帶來(lái)了曙光，給了我們希望。GFS解決了海量數(shù)據(jù)存儲(chǔ)的問(wèn)題，MapReduce解決了分布式計(jì)算的問(wèn)題，BigTable幫助我們構(gòu)建分布式的數(shù)據(jù)倉(cāng)庫(kù)。我們歡呼，跪舔，并且對(duì)未來(lái)充滿了希望，but, 我們發(fā)現(xiàn)坑爹的谷歌只點(diǎn)化了大眾，缺沒(méi)有開(kāi)源代碼。怎么辦呢，只有自己挽起袖子擼一個(gè)出來(lái)了。于是，華強(qiáng)北山寨版大組合Hadoop出來(lái)了。hadoop完全一對(duì)一山寨了谷歌的三篇論文的思想，憋出了HDFS(山寨自GFS), MapReduce, Hbase(BigTable)……

　　紀(jì)路：我暫且就按照一個(gè)由遠(yuǎn)及近的順序，按照時(shí)間的早晚從大數(shù)據(jù)出現(xiàn)之前的時(shí)代講到現(xiàn)在。暫時(shí)按一個(gè)城市來(lái)比喻吧，反正Landscape的意思也大概是”風(fēng)景“的意思。

　　早在大數(shù)據(jù)概念出現(xiàn)以前就存在了各種各樣的關(guān)于數(shù)學(xué)、統(tǒng)計(jì)學(xué)、算法、編程語(yǔ)言的研究、討論和實(shí)踐。這個(gè)時(shí)代，算法以及各種數(shù)學(xué)知識(shí)作為建筑的原料(比如鋼筋、磚塊)，編程語(yǔ)言作為粘合劑(比如水泥)構(gòu)成了一座座小房子(比如一個(gè)應(yīng)用程序)，形成了一小片一小片的村莊(比如一臺(tái)服務(wù)器)。這個(gè)時(shí)代村與村之間還沒(méi)有高速公路(GFS, HDFS, Flume, Kafka等)，只有一條泥濘不好走的土路(比如RPC)，經(jīng)濟(jì)模式也是小作坊式的經(jīng)濟(jì)。一開(kāi)始互聯(lián)網(wǎng)并不發(fā)達(dá)，網(wǎng)速也不快，這種老土的方式完全應(yīng)付得來(lái)，可是隨著社交網(wǎng)絡(luò)和智能手機(jī)的興起，改變了這一切。網(wǎng)站流量成百上千倍的提高，數(shù)據(jù)變得更加多樣化，計(jì)算機(jī)硬件性能無(wú)法按照摩爾定律穩(wěn)定的提升，小村莊，小作坊生產(chǎn)的模式注定受到限制。人們需要更強(qiáng)大的模式...

　　起開(kāi)始，人們以為只要有一個(gè)強(qiáng)大的中央數(shù)據(jù)庫(kù)，也就是在所有的村莊之間建一座吞吐量巨大，并且兼容并蓄(非關(guān)系型，NoSQL)的倉(cāng)庫(kù)，用來(lái)中轉(zhuǎn)每個(gè)村莊生產(chǎn)的大量異質(zhì)貨物就能夠拉動(dòng)經(jīng)濟(jì)的增長(zhǎng)?？墒菦](méi)過(guò)多久，人們就意識(shí)到這是一個(gè)too young to simple的想法，因?yàn)檫@個(gè)倉(cāng)庫(kù)的大小也總是有上限的。

　　之后MapReduce的概念最早由google提出，用來(lái)解決大規(guī)模集群協(xié)同運(yùn)算的問(wèn)題，既然一臺(tái)計(jì)算機(jī)性能有限，何不將他們聯(lián)合起來(lái)?其野心勃勃，希望為每個(gè)村莊都建立一條”村村通“公路，也就是GFS了，就是Google分布式文件系統(tǒng)的意思，將不同服務(wù)器的硬盤(pán)連接起來(lái)，在外面看起來(lái)就好像一塊巨大的硬盤(pán)。然后構(gòu)建與其上的MapReduce就是一座工廠調(diào)度每個(gè)村莊的勞動(dòng)力和物資，讓這些村莊作為一個(gè)經(jīng)濟(jì)體運(yùn)轉(zhuǎn)起來(lái)。居民變得富裕起來(lái)了。

　　不過(guò)，富裕起來(lái)的只有“谷歌鎮(zhèn)”，世界的其他村鎮(zhèn)仍然過(guò)著原始的生活。這個(gè)時(shí)候雅虎和Apache的一幫人本著獨(dú)樂(lè)樂(lè)不如眾樂(lè)樂(lè)的精神，仿造google的思想，創(chuàng)建了HDFS(Hadoop 分布式文件系統(tǒng)，對(duì)應(yīng)GFS)、Hadoop(對(duì)應(yīng)google的MapReduce)，并公開(kāi)了全部的藍(lán)圖，供全世界免費(fèi)使用。這樣整個(gè)世界到處都建立起來(lái)了工廠，人們變得富裕起來(lái)了。這個(gè)時(shí)代，Hadoop叫做大數(shù)據(jù)基礎(chǔ)設(shè)施。俗話說(shuō)：飽暖思淫欲，工廠的領(lǐng)導(dǎo)不滿足于村鎮(zhèn)工廠的粗放型生產(chǎn)，也不再想雇用那么多的勞動(dòng)力，所以Mahout、HBase、Hive、Pig應(yīng)運(yùn)而生，他們都是數(shù)控機(jī)床，加工中心，只需要幾名操作手就能夠讓整個(gè)工廠運(yùn)轉(zhuǎn)起來(lái)，自此人們安居樂(lè)業(yè)，豐衣足食。

　　當(dāng)然，少數(shù)更有野心的資本家，不滿足于現(xiàn)在的生產(chǎn)力，為了追求更高的利潤(rùn)(這是資本主義的本質(zhì))，開(kāi)發(fā)了效率更高的系統(tǒng)Spark，可以10倍于Hadoop的速度生產(chǎn)產(chǎn)品，新的時(shí)代才剛剛拉開(kāi)序幕...