大數(shù)據(jù)本身是個很寬泛的概念，Hadoop生態(tài)圈(或者泛生態(tài)圈)基本上都是為了處理超過單機尺度的數(shù)據(jù)處理而誕生的。你可以把它比作一個廚房所以需要的各種工具衣厘。鍋碗瓢盆，各有各的用處，互相之間又有重合妆兑。你可以用湯鍋直接當碗吃飯喝湯，你可以用小刀或者刨子去皮。但是每個工具有自己的特性棍矛，雖然奇怪的組合也能工作蝶桶，但是未必是最佳選擇厌小。
大數(shù)據(jù)讨韭，首先你要能存的下大數(shù)據(jù)
傳統(tǒng)的文件系統(tǒng)是單機的，不能橫跨不同的機器埋泵。HDFS(Hadoop Distributed FileSystem)的設(shè)計本質(zhì)上是為了大量的數(shù)據(jù)能橫跨成百上千臺機器，但是你看到的是一個文件系統(tǒng)而不是很多文件系統(tǒng)。比如你說我要獲取/hdfs/tmp/file1的數(shù)據(jù)霉撵，你引用的是一個文件路徑箍鼓，但是實際的數(shù)據(jù)存放在很多不同的機器上。你作為用戶海洼，不需要知道這些赘被，就好比在單機上你不關(guān)心文件分散在什么磁道什么扇區(qū)一樣。HDFS為你管理這些數(shù)據(jù)事秀。
存的下數(shù)據(jù)之后，你就開始考慮怎么處理數(shù)據(jù)供炼。雖然HDFS可以為你整體管理不同機器上的數(shù)據(jù)考余，但是這些數(shù)據(jù)太大了身冬。一臺機器讀取成T上P的數(shù)據(jù)(很大的數(shù)據(jù)哦，比如整個東京熱有史以來所有高清電影的大小甚至更大)，一臺機器慢慢跑也許需要好幾天甚至好幾周丧凤。對于很多公司來說仍侥，單機處理是不可忍受的，比如微博要更新24小時熱博，它必須在24小時之內(nèi)跑完這些處理批糟。那么我如果要用很多臺機器處理否淤，我就面臨了如何分配工作啰扛，如果一臺機器掛了如何重新啟動相應(yīng)的任務(wù)，機器之間如何互相通信交換數(shù)據(jù)以完成復雜的計算等等摄凡。這就是MapReduce / Tez / Spark的功能谷扣。MapReduce是第一代計算引擎裹匙，Tez和Spark是第二代惰匙。MapReduce的設(shè)計，采用了很簡化的計算模型，只有Map和Reduce兩個計算過程(中間用Shuffle串聯(lián))沦零，用這個模型寻拂，已經(jīng)可以處理大數(shù)據(jù)領(lǐng)域很大一部分問題了。
那什么是Map垮卓，什么是Reduce?
考慮如果你要統(tǒng)計一個巨大的文本文件存儲在類似HDFS上疼鸟，你想要知道這個文本里各個詞的出現(xiàn)頻率吴攒。你啟動了一個MapReduce程序茴厉。Map階段，幾百臺機器同時讀取這個文件的各個部分友瘤，分別把各自讀到的部分分別統(tǒng)計出詞頻，產(chǎn)生類似(hello, 12100次)柿究，(world狡孔，15214次)等等這樣的Pair(我這里把Map和Combine放在一起說以便簡化);這幾百臺機器各自都產(chǎn)生了如上的集合辱揭，然后又有幾百臺機器啟動Reduce處理。Reducer機器A將從Mapper機器收到所有以A開頭的統(tǒng)計結(jié)果熟呛，機器B將收到B開頭的詞匯統(tǒng)計結(jié)果(當然實際上不會真的以字母開頭做依據(jù)覆致，而是用函數(shù)產(chǎn)生Hash值以避免數(shù)據(jù)串化笔链。因為類似X開頭的詞肯定比其他要少得多莱预，而你不希望數(shù)據(jù)處理各個機器的工作量相差懸殊)。然后這些Reducer將再次匯總危喉，(hello薄嫡，12100)+(hello岂座，12311)+(hello鸳址，345881)= (hello，370292)。每個Reducer都如上處理，你就得到了整個文件的詞頻結(jié)果媚送。
這看似是個很簡單的模型中燥，但很多算法都可以用這個模型描述了。
Map+Reduce的簡單模型很黃很暴力塘偎，雖然好用疗涉，但是很笨重。第二代的Tez和Spark除了內(nèi)存Cache之類的新feature吟秩，本質(zhì)上來說咱扣，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊涵防，數(shù)據(jù)交換更靈活闹伪，更少的磁盤讀寫，以便更方便地描述復雜算法壮池，取得更高的吞吐量偏瓤。
有了MapReduce，Tez和Spark之后椰憋，程序員發(fā)現(xiàn)厅克，MapReduce的程序?qū)懫饋碚媛闊Ｋ麄兿Ｍ喕@個過程橙依。這就好比你有了匯編語言证舟，雖然你幾乎什么都能干了，但是你還是覺得繁瑣窗骑。你希望有個更高層更抽象的語言層來描述算法和數(shù)據(jù)處理流程女责。于是就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce慧域，Hive則用的是SQL鲤竹。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算昔榴，而你就從繁瑣的MapReduce程序中解脫出來辛藻，用更簡單更直觀的語言去寫程序了。
有了Hive之后互订，人們發(fā)現(xiàn)SQL對比Java有巨大的優(yōu)勢吱肌。一個是它太容易寫了。剛才詞頻的東西仰禽，用SQL描述就只有一兩行氮墨，MapReduce寫起來大約要幾十上百行纺蛆。而更重要的是，非計算機背景的用戶終于感受到了愛：我也會寫SQL!于是數(shù)據(jù)分析人員終于從乞求工程師幫忙的窘境解脫出來规揪，工程師也從寫奇怪的一次性的處理程序中解脫出來桥氏。大家都開心了。Hive逐漸成長成了大數(shù)據(jù)倉庫的核心組件猛铅。甚至很多公司的流水線作業(yè)集完全是用SQL描述字支，因為易寫易改，一看就懂奸忽，容易維護堕伪。
自從數(shù)據(jù)分析人員開始用Hive分析數(shù)據(jù)之后，它們發(fā)現(xiàn)栗菜，Hive在MapReduce上跑欠雌，真雞巴慢!流水線作業(yè)集也許沒啥關(guān)系，比如24小時更新的推薦疙筹，反正24小時內(nèi)跑完就算了富俄。但是數(shù)據(jù)分析，人們總是希望能跑更快一些腌歉。比如我希望看過去一個小時內(nèi)多少人在充氣娃娃頁面駐足蛙酪，分別停留了多久，對于一個巨型網(wǎng)站海量數(shù)據(jù)下翘盖，這個處理過程也許要花幾十分鐘甚至很多小時。而這個分析也許只是你萬里長征的第一步凹蜂，你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD馍驯，以便跟老板匯報，我們的用戶是猥瑣男悶騷女更多還是文藝青年/少女更多玛痊。你無法忍受等待的折磨汰瘫，只能跟帥帥的工程師蟈蟈說，快擂煞，快混弥，再快一點!
于是Impala，Presto对省，Drill誕生了(當然還有無數(shù)非著名的交互SQL引擎蝗拿，就不一一列舉了)。三個系統(tǒng)的核心理念是蒿涎，MapReduce引擎太慢哀托，因為它太通用，太強壯劳秋，太保守仓手，我們SQL需要更輕量胖齐，更激進地獲取資源，更專門地對SQL做優(yōu)化嗽冒，而且不需要那么多容錯性保證(因為系統(tǒng)出錯了大不了重新啟動任務(wù)呀伙，如果整個處理時間更短的話，比如幾分鐘之內(nèi))添坊。這些系統(tǒng)讓用戶更快速地處理SQL任務(wù)剿另，犧牲了通用性穩(wěn)定性等特性。如果說MapReduce是大砍刀帅腌，砍啥都不怕驰弄，那上面三個就是剔骨刀，靈巧鋒利速客，但是不能搞太大太硬的東西戚篙。
這些系統(tǒng)，說實話溺职，一直沒有達到人們期望的流行度岔擂。因為這時候又兩個異類被造出來了。他們是Hive on Tez / Spark和SparkSQL浪耘。它們的設(shè)計理念是乱灵，MapReduce慢，但是如果我用新一代通用計算引擎Tez或者Spark來跑SQL七冲，那我就能跑的更快痛倚。而且用戶不需要維護兩套系統(tǒng)。這就好比如果你廚房小澜躺，人又懶蝉稳，對吃的精細程度要求有限，那你可以買個電飯煲掘鄙，能蒸能煲能燒耘戚，省了好多廚具。
上面的介紹操漠，基本就是一個數(shù)據(jù)倉庫的構(gòu)架了收津。底層HDFS，上面跑MapReduce/Tez/Spark浊伙，在上面跑Hive撞秋，Pig“苫疲或者HDFS上直接跑Impala部服，Drill，Presto拗慨。這解決了中低速數(shù)據(jù)處理的要求廓八。
那如果我要更高速的處理呢奉芦？
如果我是一個類似微博的公司，我希望顯示不是24小時熱博剧蹂，我想看一個不斷變化的熱播榜声功，更新延遲在一分鐘之內(nèi)，上面的手段都將無法勝任宠叼。于是又一種計算模型被開發(fā)出來先巴，這就是Streaming(流)計算。Storm是最流行的流計算平臺冒冬。流計算的思路是伸蚯，如果要達到更實時的更新，我何不在數(shù)據(jù)流進來的時候就處理了?比如還是詞頻統(tǒng)計的例子简烤，我的數(shù)據(jù)流是一個一個的詞剂邮，我就讓他們一邊流過我就一邊開始統(tǒng)計了。流計算很牛逼横侦，基本無延遲挥萌，但是它的短處是，不靈活枉侧，你想要統(tǒng)計的東西必須預先知道引瀑，畢竟數(shù)據(jù)流過就沒了，你沒算的東西就無法補算了榨馁。因此它是個很好的東西憨栽，但是無法替代上面數(shù)據(jù)倉庫和批處理系統(tǒng)。
還有一個有些獨立的模塊是KV Store翼虫，比如Cassandra徒像，HBase，MongoDB以及很多很多很多很多其他的(多到無法想象)蛙讥。所以KV Store就是說，我有一堆鍵值灭衷，我能很快速滴獲取與這個Key綁定的數(shù)據(jù)次慢。比如我用身份證號，能取到你的身份數(shù)據(jù)翔曲。這個動作用MapReduce也能完成迫像，但是很可能要掃描整個數(shù)據(jù)集。而KV Store專用來處理這個操作瞳遍，所有存和取都專門為此優(yōu)化了闻妓。從幾個P的數(shù)據(jù)中查找一個身份證號，也許只要零點幾秒掠械。這讓大數(shù)據(jù)公司的一些專門操作被大大優(yōu)化了由缆。比如我網(wǎng)頁上有個根據(jù)訂單號查找訂單內(nèi)容的頁面注祖，而整個網(wǎng)站的訂單數(shù)量無法單機數(shù)據(jù)庫存儲，我就會考慮用KV Store來存均唉。KV Store的理念是是晨，基本無法處理復雜的計算，大多沒法JOIN舔箭，也許沒法聚合罩缴，沒有強一致性保證(不同數(shù)據(jù)分布在不同機器上，你每次讀取也許會讀到不同的結(jié)果层扶，也無法處理類似銀行轉(zhuǎn)賬那樣的強一致性要求的操作)箫章。但是丫就是快。極快镜会。
每個不同的KV Store設(shè)計都有不同取舍檬寂，有些更快，有些容量更高稚叹，有些可以支持更復雜的操作焰薄。必有一款適合你。
除此之外扒袖，還有一些更特制的系統(tǒng)/組件塞茅，比如Mahout是分布式機器學習庫，Protobuf是數(shù)據(jù)交換的編碼和庫季率，ZooKeeper是高一致性的分布存取協(xié)同系統(tǒng)野瘦，等等。
有了這么多亂七八糟的工具飒泻，都在同一個集群上運轉(zhuǎn)鞭光，大家需要互相尊重有序工作。所以另外一個重要組件是泞遗，調(diào)度系統(tǒng)《栊恚現(xiàn)在最流行的是Yarn。你可以把他看作中央管理史辙，好比你媽在廚房監(jiān)工汹买，哎，你妹妹切菜切完了聊倔，你可以把刀拿去殺雞了晦毙。只要大家都服從你媽分配，那大家都能愉快滴燒菜耙蔑。
你可以認為见妒，大數(shù)據(jù)生態(tài)圈就是一個廚房工具生態(tài)圈。為了做不同的菜甸陌，中國菜须揣，日本菜盐股，法國菜，你需要各種不同的工具返敬。而且客人的需求正在復雜化遂庄，你的廚具不斷被發(fā)明，也沒有一個萬用的廚具可以處理所有情況劲赠，因此它會變的越來越復雜涛目。
最后
小編這里有一份大數(shù)據(jù)的實戰(zhàn)PDF文檔可以免費分享給大家。
其中包含有spark凛澎、redis霹肝、微服務(wù)、Netty 與RPC 塑煎、Kafka沫换、設(shè)計模式、Zookeeper最铁、hadoop讯赏、hbase、RabbitMQ冷尉、 分布式緩存漱挎、數(shù)據(jù)結(jié)構(gòu)等等
需要免費獲取的朋友：加VX：mxm1073 即可免費獲取
