Hadoop基礎(chǔ)概念

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡(jiǎn)單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名與空間、虛擬空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、新林網(wǎng)站維護(hù)、網(wǎng)站推廣。

作者：Xiaoyu Ma
鏈接：https://www.zhihu.com/question/27974418/answer/38965760
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

大數(shù)據(jù)本身是個(gè)很寬泛的概念，Hadoop生態(tài)圈（或者泛生態(tài)圈）基本上都是為了處理超過單機(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)。比如你說我要獲取/hdfs/tmp/file1的數(shù)據(jù)，你引用的是一個(gè)文件路徑，但是實(shí)際的數(shù)據(jù)存放在很多不同的機(jī)器上。你作為用戶，不需要知道這些，就好比在單機(jī)上你不關(guān)心文件分散在什么磁道什么扇區(qū)一樣。HDFS為你管理這些數(shù)據(jù)。

存的下數(shù)據(jù)之后，你就開始考慮怎么處理數(shù)據(jù)。雖然HDFS可以為你整體管理不同機(jī)器上的數(shù)據(jù)，但是這些數(shù)據(jù)太大了。一臺(tái)機(jī)器讀取成T上P的數(shù)據(jù)（很大的數(shù)據(jù)哦，比如整個(gè)東京熱有史以來所有高清電影的大小甚至更大），一臺(tái)機(jī)器慢慢跑也許需要好幾天甚至好幾周。對(duì)于很多公司來說，單機(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ì)算過程（中間用Shuffle串聯(lián)），用這個(gè)模型，已經(jīng)可以處理大數(shù)據(jù)領(lǐng)域很大一部分問題了。
那什么是Map什么是Reduce？
考慮如果你要統(tǒng)計(jì)一個(gè)巨大的文本文件存儲(chǔ)在類似HDFS上，你想要知道這個(gè)文本里各個(gè)詞的出現(xiàn)頻率。你啟動(dòng)了一個(gè)MapReduce程序。Map階段，幾百臺(tái)機(jī)器同時(shí)讀取這個(gè)文件的各個(gè)部分，分別把各自讀到的部分分別統(tǒng)計(jì)出詞頻，產(chǎn)生類似
（hello, 12100次），（world，15214次）等等這樣的Pair（我這里把Map和Combine放在一起說以便簡(jiǎn)化）；這幾百臺(tái)機(jī)器各自都產(chǎn)生了如上的集合，然后又有幾百臺(tái)機(jī)器啟動(dòng)Reduce處理。Reducer機(jī)器A將從Mapper機(jī)器收到所有以A開頭的統(tǒng)計(jì)結(jié)果，機(jī)器B將收到B開頭的詞匯統(tǒng)計(jì)結(jié)果（當(dāng)然實(shí)際上不會(huì)真的以字母開頭做依據(jù)，而是用函數(shù)產(chǎn)生Hash值以避免數(shù)據(jù)串化。因?yàn)轭愃芚開頭的詞肯定比其他要少得多，而你不希望數(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之類的新feature，本質(zhì)上來說，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，數(shù)據(jù)交換更靈活，更少的磁盤讀寫，以便更方便地描述復(fù)雜算法，取得更高的吞吐量。

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

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

自從數(shù)據(jù)分析人員開始用Hive分析數(shù)據(jù)之后，它們發(fā)現(xiàn)，Hive在MapReduce上跑，真×××慢！流水線作業(yè)集也許沒啥關(guān)系，比如24小時(shí)更新的推薦，反正24小時(shí)內(nèi)跑完就算了。但是數(shù)據(jù)分析，人們總是希望能跑更快一些。比如我希望看過去一個(gè)小時(shí)內(nèi)多少人在充氣娃娃頁(yè)面駐足，分別停留了多久，對(duì)于一個(gè)巨型網(wǎng)站海量數(shù)據(jù)下，這個(gè)處理過程也許要花幾十分鐘甚至很多小時(shí)。而這個(gè)分析也許只是你×××長(zhǎng)征的第一步，你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD，以便跟老板匯報(bào)，我們的用戶是猥瑣男悶騷女更多還是文藝青年／少女更多。你無法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說，快，快，再快一點(diǎn)！
于是Impala，Presto，Drill誕生了（當(dāng)然還有無數(shù)非著名的交互SQL引擎，就不一一列舉了）。三個(gè)系統(tǒng)的核心理念是，MapReduce引擎太慢，因?yàn)樗ㄓ茫珡?qiáng)壯，太保守，我們SQL需要更輕量，更激進(jìn)地獲取資源，更專門地對(duì)SQL做優(yōu)化，而且不需要那么多容錯(cuò)性保證（因?yàn)橄到y(tǒng)出錯(cuò)了大不了重新啟動(dòng)任務(wù)，如果整個(gè)處理時(shí)間更短的話，比如幾分鐘之內(nèi)）。這些系統(tǒng)讓用戶更快速地處理SQL任務(wù)，犧牲了通用性穩(wěn)定性等特性。如果說MapReduce是大砍刀，砍啥都不怕，那上面三個(gè)就是剔骨刀，靈巧鋒利，但是不能搞太大太硬的東西。

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

上面的介紹，基本就是一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)架了。底層HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig?；蛘逪DFS上直接跑Impala，Drill，Presto。這解決了中低速數(shù)據(jù)處理的要求。

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

還有一個(gè)有些獨(dú)立的模塊是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的（多到無法想象）。所以KV Store就是說，我有一堆鍵值，我能很快速滴獲取與這個(gè)Key綁定的數(shù)據(jù)。比如我用身 份 證號(hào)，能取到你的身份數(shù)據(jù)。這個(gè)動(dòng)作用MapReduce也能完成，但是很可能要掃描整個(gè)數(shù)據(jù)集。而KV Store專用來處理這個(gè)操作，所有存和取都專門為此優(yōu)化了。從幾個(gè)P的數(shù)據(jù)中查找一個(gè)身 份 證號(hào)，也許只要零點(diǎn)幾秒。這讓大數(shù)據(jù)公司的一些專門操作被大大優(yōu)化了。比如我網(wǎng)頁(yè)上有個(gè)根據(jù)訂單號(hào)查找訂單內(nèi)容的頁(yè)面，而整個(gè)網(wǎng)站的訂單數(shù)量無法單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)，我就會(huì)考慮用KV Store來存。KV Store的理念是，基本無法處理復(fù)雜的計(jì)算，大多沒法JOIN，也許沒法聚合，沒有強(qiáng)一致性保證（不同數(shù)據(jù)分布在不同機(jī)器上，你每次讀取也許會(huì)讀到不同的結(jié)果，也無法處理類似銀行轉(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)。現(xiàn)在最流行的是Yarn。你可以把他看作中央管理，好比你媽在廚房監(jiān)工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。只要大家都服從你媽分配，那大家都能愉快滴燒菜。

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

Hadoop架構(gòu)

Write：Client向HDFS文件系統(tǒng)保存數(shù)據(jù)的過程

1、HDFS Client通過HDFS文件系統(tǒng)的API，將數(shù)據(jù)劃分成指定大小的數(shù)據(jù)塊

2、向NameNode發(fā)起存儲(chǔ)請(qǐng)求，NameNode會(huì)告知Client端，數(shù)據(jù)可以存放在哪些DataNode上

3-5：Client端通FSData OutputStream將數(shù)據(jù)存儲(chǔ)在2中NameNode返回的DataNode上，在不同的DataNode上保存至少三份，每一份保存完成后，DataNode會(huì)向ClientNode發(fā)送ACK確認(rèn)

6、Client端關(guān)閉FSData OutputStream 數(shù)據(jù)流，并告知NameNode，數(shù)據(jù)存儲(chǔ)完成。

Read：Client向HDFS文件系統(tǒng)讀取數(shù)據(jù)的過程

1、Client 通過Distributed FileSystem的API向NameNode發(fā)起打開文件，并讀取文件的請(qǐng)求

2、NameNode在收到請(qǐng)求后，會(huì)查找本地維護(hù)的兩張?jiān)獢?shù)據(jù)表（一個(gè)是所持有的塊信息表，一個(gè)是每一個(gè)數(shù)據(jù)塊存放的DataNode路徑信息）返回給客戶端

3-5、客戶端會(huì)根據(jù)NameNode返回的表查找離自己最近的數(shù)據(jù)節(jié)點(diǎn)來獲取數(shù)據(jù)，比如第一個(gè)數(shù)據(jù)塊從datanode4上讀取，第2個(gè)從datanode5上讀取

6、數(shù)據(jù)讀取完成后，Client關(guān)閉FSData InputStream

mapreduce的過程：

mapreduce主要是用來處理文件的，這個(gè)文件上的數(shù)據(jù)可能是雜亂無章的，hadoop的reduce只能處理鍵值對(duì)格式的數(shù)據(jù)，因此必須將數(shù)據(jù)抽取成鍵值對(duì)數(shù)據(jù)。

過程如下：

split：?jiǎn)?dòng)一個(gè)split任務(wù)，將文件中的每一個(gè)數(shù)據(jù)按照用戶所指定的標(biāo)準(zhǔn)切割或者抽取成鍵值對(duì)。如,

map：將這些鍵值對(duì)發(fā)送給各個(gè)mapper worker進(jìn)程，mapper worker收到鍵值對(duì)后，會(huì)對(duì)數(shù)據(jù)做出第一次處理，結(jié)束后形成另外一種鍵值對(duì)。如、。 這些數(shù)據(jù)是reducer可折疊的數(shù)據(jù)。

shuffle&sort：mapper將處理后的數(shù)據(jù)進(jìn)行洗牌和排序，發(fā)給reduce進(jìn)行折疊操作，同一個(gè)key和其對(duì)應(yīng)的數(shù)據(jù)發(fā)送給同一個(gè)reducer。

store：reduce之后的數(shù)據(jù)進(jìn)行存儲(chǔ)

HBase：

Master：用來做請(qǐng)求調(diào)度的，協(xié)調(diào)各個(gè)RegionServers工作。用來控制數(shù)據(jù)發(fā)給哪一個(gè)RegionServer的哪一個(gè)位置進(jìn)行存儲(chǔ)。借助于zookeeper來完成調(diào)度，比如說某一個(gè)RegionServer宕機(jī)了怎么辦？Master會(huì)借助于zookeeper將該RegionServer上原有的數(shù)據(jù)從其他RegionServer上重新構(gòu)建出來。

RegionServers： 真正用來做數(shù)據(jù)存取的服務(wù)器

Hive：它把mapreduce的API給封裝成類似于關(guān)系型數(shù)據(jù)庫(kù)語法的SQL接口，它能支持增刪改查語句。

Hadoop生態(tài)圈

Pig

Pig是一種數(shù)據(jù)流語言，用來快速輕松的處理巨大的數(shù)據(jù)。Pig包含兩個(gè)部分：Pig Interface,Pig Latin。Pig可以非常方便的處理HDFS和HBase的數(shù)據(jù)，和Hive一樣,Pig可以非常高效的處理其需要做的，通過直接操作Pig查詢可以節(jié)省大量的勞動(dòng)和時(shí)間。

當(dāng)你想在你的數(shù)據(jù)上做一些轉(zhuǎn)換，并且不想編寫MapReduce jobs就可以用Pig.

Hive

起源于FaceBook,Hive在Hadoop中扮演數(shù)據(jù)倉(cāng)庫(kù)的角色。建立在Hadoop集群的最頂層，對(duì)存儲(chǔ)在Hadoop群上的數(shù)據(jù)提供類SQL的接口進(jìn)行操作。你可以用 HiveQL進(jìn)行select,join,等等操作。

如果你有數(shù)據(jù)倉(cāng)庫(kù)的需求并且你擅長(zhǎng)寫SQL并且不想寫MapReduce jobs就可以用Hive代替。

HBase

HBase作為面向列的數(shù)據(jù)庫(kù)運(yùn)行在HDFS之上，HDFS缺乏隨即讀寫操作，HBase正是為此而出現(xiàn)。HBase以Google BigTable為藍(lán)本，以鍵值對(duì)的形式存儲(chǔ)。項(xiàng)目的目標(biāo)就是快速在主機(jī)內(nèi)數(shù)十億行數(shù)據(jù)中定位所需的數(shù)據(jù)并訪問它。

HBase是一個(gè)數(shù)據(jù)庫(kù)，一個(gè)NOSQL的數(shù)據(jù)庫(kù)，像其他數(shù)據(jù)庫(kù)一樣提供隨即讀寫功能，Hadoop不能滿足實(shí)時(shí)需要，HBase正可以滿足。如果你需要實(shí)時(shí)訪問一些數(shù)據(jù)，就把它存入HBase。

你可以用Hadoop作為靜態(tài)數(shù)據(jù)倉(cāng)庫(kù)，HBase作為數(shù)據(jù)存儲(chǔ)，放那些進(jìn)行一些操作會(huì)改變的數(shù)據(jù)。

Pig VS Hive

Hive更適合于數(shù)據(jù)倉(cāng)庫(kù)的任務(wù)，Hive主要用于靜態(tài)的結(jié)構(gòu)以及需要經(jīng)常分析的工作。Hive與SQL相似促使 其成為Hadoop與其他BI工具結(jié)合的理想交集。

Pig賦予開發(fā)人員在大數(shù)據(jù)集領(lǐng)域更多的靈活性，并允許開發(fā)簡(jiǎn)潔的腳本用于轉(zhuǎn)換數(shù)據(jù)流以便嵌入到較大的 應(yīng)用程序。

Pig相比Hive相對(duì)輕量，它主要的優(yōu)勢(shì)是相比于直接使用Hadoop Java APIs可大幅削減代碼量。正因?yàn)槿绱耍琍ig仍然是吸引大量的軟件開發(fā)人員。

Hive和Pig都可以與HBase組合使用，Hive和Pig還為HBase提供了高層語言支持，使得在HBase上進(jìn)行數(shù)據(jù)統(tǒng)計(jì)處理變的非常簡(jiǎn)單

Hive VS HBase

Hive是建立在Hadoop之上為了減少M(fèi)apReduce jobs編寫工作的批處理系統(tǒng)，HBase是為了支持彌補(bǔ)Hadoop對(duì)實(shí)時(shí)操作的缺陷的項(xiàng)目 。

想象你在操作RMDB數(shù)據(jù)庫(kù)，如果是全表掃描，就用Hive+Hadoop,如果是索引訪問，就用HBase+Hadoop 。

Hive query就是MapReduce jobs可以從5分鐘到數(shù)小時(shí)不止，HBase是非常高效的，肯定比Hive高效的多。