Hadoop基礎原理

                  Hadoop基礎原理
html

                              做者:尹正傑java

版權聲明:原創做品,謝絕轉載!不然將追究法律責任。node

 

 

  業內有這麼一句話說:雲計算可能改變了整個傳統IT產業的基礎架構,而大數據處理,尤爲像Hadoop組件這樣的技術出現,將是改變IT業務模式的一種技術。mysql

  另外,不少小夥伴可能還搞不明白雲和Hadoop有什麼關係,事實上這是兩種大相徑庭的技術。雖然從某種意義上來說,他們都是在大規模的計算機集羣上來完成的。可是openstack或其它的paas或sas的雲環境,他們所指的是所謂的雲計算的方式,一般是來說是用於指定如何將用戶本地完成的運算遷移到雲上去,讓用戶無需得知其計算能力,存儲能力等各類能力來自任何一個地方的機制。程序員

 

 

一.數據的存儲方式(就是對數據的建模)web

1>.結構化數據:算法

  即行數據,存儲在數據庫中,用二維表來存儲的數據。sql

2>.非結構化數據:shell

  難以使用數據庫二維表來存儲的數據,如文檔,圖片等,字段可變,字段內容可變或不可變組成的。數據庫

3>.半結構化數據:

  可以實現自我描述的數據,將結構和數據自己混在一塊兒,xml,json,html。

 

二.Hadoop的由來

1>.GFS文件系統誕生

  2003年,The Google File System(簡稱GFS)誕生了,GFS採起了數據塊的方式管理數據,將一個單獨的大文件切割成N個指定的小片斷,然後在每一個節點上存儲單個片斷而且經過在集羣中的多個節點上存儲同一個數據塊的多份冗餘副本以實現容災的功能。站在這個角度來說,GFS的設計主要是用來支持大規模數據密集型的分佈式應用程序的運行。存儲過程以下圖:

2>..MapReduce相繼開源

  繼2003發佈GFS文件系統開源後,2004年又發表了關於MapReduce的文章,即Simplify Data Processing On Large Clusters。MapReduce定義了一種編程模型及其運行框架,它提供了集中的多個節點上自動並行容錯及可處理TB規模數據,甚至可以達到PB規模的數據處理平臺。事實上MapReduce是GFS集羣的組成部分,他要工做在GFS的基礎之上纔可以完成處理操做的。所以MapReduce與GFS一同構成了所謂的大數據存儲及並行處理平臺。

 

  MapReduce的特性:

    a>.向外擴展;

    b>.假設故障常見,自我完成數據冗餘,並自我完成故障處理;

    c>.將程序移向數據;

    d>.順序處理數據,並避免隨機訪問;

    e>.向程序員隱藏系統級別的細節;

    f>.實現平滑擴展;

3>.Nutch搜索平臺誕生

  該搜索引擎用Java語言編寫而成,該搜索引擎在工做一段時間後,做者發現了一個難題,這個搜索引擎爬來的數據難以有效存儲,在小規模存儲中還能正常應用,可是到大規模應用該存儲的很讓然頭疼了,正在爲這個問題發愁時,做者看到了Google公司公開的論文,也就是上面咱們介紹的GFS文件系統,做者看到以後如獲至寶。所以做者傾注了心血在Nutch搜索引擎的應用,因而在Google的GFS基礎上,山寨出來了一個DFS和MapReduce平臺。後來做者看見他的還在在玩一個玩具象,給其平臺取名爲Hadoop。

  Hadoop徹底由Java語言實現的DFS和MapReduce。因爲DFS是分佈式文件系統的統稱,回來乾脆取Hadoop首字母,稱之爲HDFS,所以咱們能夠說Hadoop是由HDFS和MapReduce組成。因此Hadoop在某種意義上來說,就是Google處理平臺的山寨版本,固然我更喜歡稱它開源實現。比較有意思的是整個程序都是由Java語言編寫的,所以HDFS和MapReduce都要依賴JDK才能跑起來。換句話說,MapReduce的原生接口就是由Java實現的,因此咱們要在他的MapReduce框架上去寫MapReduce程序的話,很顯然Java是首選語言喲!

4>.Hadoop的應用平臺

  當咱們把一個Hadoop集羣構建出來以後,未來是要在該集羣上跑上面任務呢?固然咱們不是爲了在這個平臺上跑一些單詞統計(wordCount)程序,而是跑一些有意義的事情,好比對日誌進行分析等等。要怎麼對這些日誌進行處理呢?此時就須要Hadoop程序員來研發MapReduce程序了。

  所以Hadoop的應用平臺主要有兩個層次,即Hadoop運維和Hadoop開發工程師,然後者的需求量是遠遠大於前者的。而安裝Hadoop服務對運維而言天然是小菜一碟啦,若是對Java自己進行研究的話,運維還得對JDK進行優化,這樣能夠保證Java程序跑的更靈活。Hadoop運維就是無非就是對其進行優化的(後期我會寫一片關於Hadoop運維的技能)而真正更多的需求就是在運維搭建好的Hadoop環境上跑一個個的特定任務。

  Hadoop自己還只是一個基礎框架。收集數據並存放在Hadoop中的HDFS中就是一個難題。另外,咱們傳統意義上的不少數據早起是存在數據庫中的,若是咱們想要用Hadoop對數據庫裏面的數據進行處理,那麼就須要一個ETL工具,來幫咱們實現收集數據,轉換和裝載。

  一個公司Hadoop集羣若只是不熟在三四十臺服務器上,咱們稱之爲入門級應用。一百臺兩百臺服務器都很差意思說是Hadoop集羣的,聽說騰訊和淘寶他們單一的Hadoop集羣在4000個節點左右。

Hadoop不建議跑在虛擬機上的,所以Hadoop和openstack結合使用仍是不多見的!由於Hadoop對磁盤的IO要求是至關的高的,若你用虛擬機進行存儲性能上得打上一個大大的問號!

 

三.開源大數據處理平臺開源解決方案

 

.HDFS各節點詳解

1>.NameNode

  HDFS的名稱節點,在內存中保存全部文件的元數據,所以任何客戶端想要獲取文件時,要到namenode節點上來獲取該文件的元數據信息。因此咱們文件想外展現時是單個文件但卻能夠分割起來進行存儲的。所謂的元數據,我們能夠理解爲NameNode的文件名稱空間。對於分佈式文件系統來說,從分佈式文件訪問的入口開始被稱爲分佈式文件系統的根,在跟目錄下能夠存放文件或者子目錄。要注意的是,這裏的文件或子目錄並非保存真正的數據,而是存放的是路徑映射。在各個路徑映射下有不一樣的文件,每一個文件能夠被分割成了多個數據塊,每一個塊默認最少有三個副本,這三個副本分別位於不一樣的DataNode節點上,這些信息都記錄在NameNode服務器中。

2>.SecondaryNameNode

  爲了保證NameNode的可用性,最簡答的方式就是將名稱節點上的持久元數據信息實時存儲多個副本於不一樣的存儲設備中,或者是提供第二名稱節點,即Secondary NameNode。

  第二名稱節點並不真正扮演名稱節點角色,它的主要認識是週期性地將編譯日誌合併至名稱空間鏡像文件中以避免編譯日誌變得過大;它運行在一個獨立的物理主機上,並須要跟名稱節點一樣大的內存資源來完成文件合併;另外,它還保存一份名稱空間鏡像的副本;然而,根據其工做機制可知,第二名稱節點要滯後與主節點,所以名稱節點故障時,部分數據丟失仍然不可避免。

  綜上所述,你們應該很清楚的知道NameNode是整個HDFS文件系統的關鍵入口,它頗有可能出現單點故障,爲了不這種狀況(NameNode服務器過長時間宕機),就有了另一個離線冗餘備份,即SecondaryNameNode。輔助NameNode節點(即SecondaryNameNode)會幫助NameNode不斷去合併內存中所謂元數據的映像信息,簡單的來說,就是對文件的刪除,修改,建立等不斷修改元數據的操做獲取到本地進行持久化存儲(你也能夠理解是SecondaryNameNode獲得了一個離線的副本),當NameNode宕機之後,SecondaryNameNode能夠替換成以前的NameNode,只不過這個提高過程是至關漫長的(可能要20~30分鐘不等)。由於當NameNode宕機後,各類元數據必需要在指定時間內收到各個DataNode對於其所持有的數據模塊的報告並最終彙總到本地真正去獲取到每個數據的副本信息之後才能夠完成替換NameNode流程。

3>.HDFS的Client(Hadoop的API)

  那麼客戶端是如何跟咱們的HDFS進行交互呢?很顯然他們之間交互是要基於HDFS自帶的API進行的。HDFS的Client到NameNode獲取元數據,在獲得元數據以後,元數據的節點會告訴Client其想要訪問文件被分割成了多少個塊,以及每一個塊都在哪一個DataNode服務器上存儲着,這個時候Client再去相應的DataNode服務器上拿數據。也就是說Client不只要和NameNode打交道,還要跟DataNode打交道。換句話說,Client存儲和讀取數據都是Client自我直接實現的。

4>.DataNode

  負責存儲真實數據。

5>.HDFS故障分類

  a>.Namenode故障

    若是NameNode故障發生時,這就意味着整個集羣掛掉了,所以咱們能夠說NameNode是整個集羣的單點故障所在。

  b>.網絡故障

    爲了不網絡故障,每次發送數據包報文時,咱們的DataNode服務器都須要作確認的,若沒有收到DataNode服務器的確認信息,咱們就能夠認爲其可能存在故障。所以他們傳輸數據是可靠的,是基於TCP這種協議進行傳輸的。

  c>.數據節點故障

    事實上,每一個DataNode每隔三秒鐘就會向NameNode發送本身的心跳信息(還要報告其存放的數據塊列表的相關信息),目的是告訴NameNode服務器當前的DataNode依然是存活狀態,也就是正常工做狀態。當NameNode在一段時間內(默認是10分鐘)一直沒有收到某個DataNode的心跳信息, 那麼NameNode就職務該DataNode已經掛掉了,並將以前存在該DataNode服務器上的數據重寫在其它節點中重寫拷貝一份。

  d>.數據故障

    每一個數據塊在發送數據給接收端時,會將該數據塊的校驗碼一塊兒發送給接收端,接收端接受數據後會重寫生成校驗碼並與發送端發來的校驗碼進行比較,若兩個校驗碼一致則說明數據是完整的,不然接收端會認爲該數據塊是損壞的。DataNode節點除了想NameNode發送心跳信息外,還要按期的發送其存放的數據塊列表信息,當發現本身存放的數據塊是損壞的時候,並不會將該損壞的數據塊加入在列表中發送給NameNode,而是將完整的數據塊發送給NameNode,NameNode服務器會按期整理全部的DataNode發來的數據列表信息,當發現有的數據塊存儲不足指定的份數(默認是3份)時,NameNode會自動新生成相應的份數進行備份。

6>.HDFS的機架感知

  咱們知道Hadoop默認會將每一個數據塊複製三分。若是想往HDFS分佈式文件系統中寫數據,而寫須要寫的客戶端剛好也是DateNode,那麼這臺服務器就優先被存放爲第一份副本的存放位置,不然的話就從衆多的DataNode中隨機挑選一個存放副本(假設數據要保留三份,當第一臺DataNode存入數據時,並不會等到其將數據第一份數據存儲完畢,因而同時,會自動向第二臺服務器上拷貝數據進行備份,而第二臺服務器也不會等到數據拷貝完畢,而是繼續拷貝到其它節點中去,咱們稱之爲管線操做(英文:Pipe Line))。而剩下的兩份數據應該存放在不一樣的機架上或者是相鄰機架的兩臺服務器中,也就是說同一個機架上要求最多存放兩個副本。(我大膽猜想設計者是爲了方式一個機櫃斷電時,DateNode訪問不到狀況。)固然,具體如何存儲仍是靠咱們手動配置,若是你非要放在同一個機櫃上誰也那你沒轍。詳情請參考:「http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-common/RackAwareness.html

7>.向HDFS文件系統保存數據

 

  上圖連接所畫的連接工具爲JVM,實際上HDFS的API已經支持不一樣的編程語言了,咱們能夠用不只僅能夠用Java,還能夠用咱們運維拿手的編程語言Python或者是shell進行編程喲。

五.MapReduce詳解

1>.Hadoop的MapReduce的工做流程

  結合上圖來看,說明Hadoop的MapReduce所能處理的數據僅簡單的鍵值數據,Hadoop的MapReduce的工做流程大體分爲五個步驟:

  a>.Split

     咱們知道咱們寫的MapReduce任務主要是用來處理文件的,這個文件的輸入(Input)有多是來自某個DataNode的一個數據塊而已,也有多是來自多個不一樣的DataNode的多個數據副本(注意:這些副本是指的是不一樣的數據喲)。而這些數據塊未必就是鍵值數據(好比日誌文件),因爲Hadoop是沒法處理非鍵值數據的,咱們必需要把數據作成模型化,把一些雜亂無章的非結構化數據抽取成鍵值數據對。這個時候就須要MapReduce提供一個Split程序(這個程序能夠是程序員本身編寫),這個split程序可以將文件中的每個數據按照用戶所指定的標準給它切割成理想的鍵值對(如上圖:<key1,value1>),並將切割後的鍵值對發送給第二階段的mapper任務(maper worker,即map工做進程)。【咱們以Wordcount爲例,此時Split切割的方式就是將文件的行號做爲鍵,將每行的內容做爲值,併發送給map程序】

  b>.map

     map的工做進程(mapper)在收到工做進程之後,會對其作進一步處理,在處理結束以後,造成另一個鍵值對(如上圖:<ikey1,ivalue1>),新生成的鍵值對是可讓reduce程序進行摺疊的!【咱們仍然一Wordcount爲例,Split程序發來行號和行號對應的數據,mapper接受後,會將Split的結果的每一個單詞切割好的單詞取出來做爲key,並對其每一個單詞賦初始值爲1。】須要注意的是,map的數據量若是很是大的話,會臨時將數據保存到當前節點的臨時目錄中生成臨時文件,當全部的mapper都處理完任務時,纔會將數據發送給reduce。

  c>.Shuffle & Sort

     map的工做進程mapper將數據發送給reduce以前,會進行排序操做,並將排序的結果發送給reducer。【由MapReduce框架(framework)決策將相應的key發送給具體的reducer

  d>.reduce

     一個reduce能夠處理多個鍵,它所處理的每個鍵對應的全部數據都必須由這個reduce來處理,它能夠根據鍵對每一個數據進行摺疊。【咱們仍是以Wordcount爲例,把同一個單詞出現的次數都交給同一個reducer,此時reducer就會將這些key作一個聚合,就是將將多個相同的key合併成同一個key,而後把每個key的value進行累加操做,最終多個reducer將處理的結果進行存儲】

  e>.Store

    多個reducer處理的結果整合到一塊兒,就是Input數據中每一個單詞出現的頻次,最終結果默認會存入到HDFS系統中。若是處理的文件較小的話咱們也能夠存入到本地喲。

2>.單reduce任務的MapReduce數據流(此圖摘自「Hadoop權威指南")

  咱們來闡述一下單reduce任務的MapReduce數據流處理過程,如上圖所示:

    a>.Split程序將數據切割成三分,分別發送給3個map去處理;

    b>.map將數據處理的數據臨時存在本地,等到map程序執行完畢後,在對這些臨時數據進行排序併發送給reduce;

    c>.此圖只有一個reduce,所以它拿到了全部的鍵值對,這個時候由它執行merge操做,將多個重複的key進行聚合並排序,再由reduce進行摺疊,摺疊後的數據結果就只有一份,由於reduce就只有一個,然後數據保存在HDFS文件系統之上;

    d>.將數據存放在HDFS以後,須要執行replication來保存多個副本。

3>.多reduce任務的MapReduce數據流(此圖摘自「Hadoop權威指南") 

  咱們來闡述一下多reduce任務的MapReduce數據流處理過程,如上圖所示:

    a>.Split程序將數據切割成三分,分別發送給3個map去處理;

    b>.map將數據處理的數據臨時存在本地,等到map程序執行完畢後,在對這些臨時數據進行排序(排序可讓相同的鍵都相鄰)並把相同的鍵發給同一個reduce;

    c>.在數據發送給reduce以前,數據須要進行merge操做(這裏的merge僅是指的的將數據流進行合併成單獨的一個流);,

    d>.數據在本地完成merge操做以後,會將結果發送給reduce,由reduce完成摺疊操做,即將重複的key進行合併,每一個reduce處理的結果手動合併起來就是最終的結果(結合上圖來看的話,「part 0」和「part 1」就是兩個reduce的輸出結果);

4>.沒有reducer的MapReduce做業(此圖摘自「Hadoop權威指南")

  事實上,咱們的做業徹底能夠沒有reduce,如上圖所示:

    若是咱們map輸出的結果自己已經就是最終結果的話,就無效reduce再次處理,你們應該都知道reduce的主要目的就是將相同的key摺疊起來,若map處理後的結果自己就無序摺疊的話就徹底沒有必要在執行reduce任務啦!所以咱們能夠說在MapReduce程序中,能夠沒有reduce,單必須得有map程序。

5>.MapReduce客戶端提交一個做業

  接下來咱們闡述一下MapReduce客戶端提交一個做業的過程:

    a>.MapReduce的客戶端提交一個做業請求(這客戶端能夠是一個開發人員針對MapReduce的maste的API發起的做業請求);

    b>.MapReduce在拿到做業後,會將這個做業分割成多個小做業去執行。如上圖所示,master將任務分爲兩個部分,一部分是map做業,另外一部分是reduce做業,由MapReduce的master決定map運行在哪一個物理節點上,在map啓動後不久就要啓動reduce,這些操做都是由MapReduce來調度的;

    c>.接下來的處理過程請參考上面的「多reduce任務的MapReduce數據流」。

6>.MapReduce邏輯架構

   經過上圖能夠看出,咱們能夠了解到MapReduce的邏輯架構:

    a>.同一個集羣內部,能夠同時運行N個做業的,這些N個做業可能提早完成任務,那麼就會騰出空間來讓master調度執行下一個做業;

    b>.當任何一個做業提交結束了,提交完成以後,他就成了歷史列表中的歷史做業,如上圖的「Historical jobs」;

    c>."job Tracker"在接受到每個做業以後,就要把做業自己完成分割然後將其發送至各「task Tracker」給予運行的;

    d>.若是是很是繁忙的Hadoop集羣的話,頗有可能整個集羣的全部的物理節點都比較繁忙,而對於Hadoop來講,不管是對於IO資源(磁盤I/O和網絡帶寬)的佔用仍是對CPU資源的佔用都很密集,所以,Hadoop集羣不多運行在虛擬環境中的。

7>.partitioner和combiner(下圖摘自互聯網)

  在瞭解基本的MapReduce的宏觀框架以後,咱們能夠結合上圖來了解MapReduce的微觀框架:

    a>.Combiner是MapReduce的一種優化機制,它的主要功能是在「shuffle and sort」以前先在本地將中間鍵值對進行聚合,以減小在網絡上發送的中間鍵值對數據量。所以能夠把combiner視做在「shuffle and sort」階段以前對mapper的輸出結果所進行聚合操做的「mini-reducer」。在實現中,各combiner之間的操做是隔離的,所以,它不會涉及到其它mapper的數據結果。須要注意的是,就算是某combiner能夠有機會處理某鍵相關的全部中間數據,也不能將其視做reducer的替代品,由於combiner輸出的鍵值對類型必需要與mapper輸出的鍵值對類型相同。不管如何,combiner的恰當應用將有機會有效提升做業的性能。簡單的來講,combiner的主要做用就是在各mapper程序執行完畢以後,能夠將相同的key進行本地合併,這樣就能夠避免本地的同一個key進行屢次發送的狀況,從而達到節省網絡帶寬的目的(從上圖可知,combiner只能作簡單的合併操做,並不能實現摺疊的功能,它的讀入和輸出的數據類型都是一致的);

    b>.Partitioner負責分割中間鍵值對數據的鍵空間(即前面所謂的「分組」),並將中間分割後的中間鍵值對發往對應的reducer,也即partitioner負責完成爲一箇中間鍵值對指派一個reducer。最簡單的partitioner實現是將鍵的hash碼對reducer進行取餘計算,並將其發往餘數對應編號的reducer,這能夠盡力保證每一個reducer獲得的鍵值對數目大致上是相同的。不過,因爲partitioner僅考慮鍵而不考慮「值」,所以,發往每一個reducer的鍵值對在鍵數目上的近似未必意味着數據量的近似。簡單的來講,partitioner的主要做用就是將各mapper輸出的鍵值對在「shuffle & sort」完成以後,將不一樣的鍵值對進行分離操做,將分離後的同一個鍵值對發送同一個reducer的做用,partitioner也是能夠程序員本身開發的,簡單的來講,partitioner就是傳輸功能;

    c>.partiontioner和combiner只是MapReduce的兩個組件,combiner和partitioner並不必定要存在,若是沒有它們的話,他們的任務都會被堆積到reduce,讓reduce執行combiner和partitioner的操做。

8>.Hadoop的小缺陷

  各位要注意的是,有些任務很是複雜,它可能須要N輪的MapReduce處理,即第一輪MapReduce處理的結果會調用第二次MapReduce,第二次的MapReduce結果繼續調用第三次的MapReduce等等,只不過每一輪所須要運行的程序可能各不同。好比分析淘寶網站的日誌,分析出來自哪一個區域訪問量最大,統計出北京,上海,深圳,西安,天津的訪問量。若是每輪MapReduce處理結果須要等待兩天時間,那麼要把整個任務執行完畢估計就一個星期以後了,這個分析的結果並非實時的,就沒法提供有效的數據支持了。這也是Hadoop爲人詬病的主要緣由。

  Hadoop還有一個缺陷,HDFS設計用來存儲單個大文件的,但事實上不少時候不少的數據都是很短小的數據信息,好比咱們想把日誌信息實時的收集過來,若咱們有100多萬臺服務器,每一萬臺服務器產生一行日誌,此時每一行的數據你有打算怎麼存儲呢?所以,Hadoop僅適用於存儲批量的,單個大文件,HDFS僅適於處理流式數據,不支持隨機模式的數據訪問,若是想要存儲相似於數據庫中存的一行短小的數據信息的話(或者是隨機性數據),HDFS就特別的不適用。這個時候HBase就出現了。

 

六.Yarn(資源管理系統)

  Yarn是Hadoop2.0新增的系統,負責集羣的資源管理和調度,使得多種計算框架能夠運行在一個集羣中。Apache Hadoop YARN (Yet Another Resource Negotiator,另外一種資源協調者)是一種新的 Hadoop 資源管理器,它是一個通用資源管理系統,可爲上層應用提供統一的資源管理和調度,它的引入爲集羣在利用率、資源統一管理和數據共享等方面帶來了巨大好處。

  詳情請參考:https://baike.baidu.com/item/yarn

 

 

七.HBase   

1>.什麼是HBase

  咱們知道HDFS很難實現隨機數據處理的,所以咱們要引入HBase。它也是一個HBase是一個分佈式的、面向列的開源數據庫,該技術來源於 Fay Chang 所撰寫的Google論文「Bigtable:一個結構化數據的分佈式存儲系統」。就像Bigtable利用了Google文件系統(File System)所提供的分佈式數據存儲同樣,HBase在Hadoop之上提供了相似於Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不一樣於通常的關係數據庫,它是一個適合於非結構化數據存儲的數據庫。另外一個不一樣的是HBase基於列的而不是基於行的模式。

  HBase能夠單機運行,可是它的冗餘能力就無法保證了,所以HBase最好的工做方式仍是在Hadoop集羣上工做。

2>.HBase的組成

  a>.Master

    咱們知道HBase也是一個分佈式系統,這個分佈式系統也是有個主從節點組成的,只不過它的主節點叫作HMaster,它的從節點叫作HRegionServers。咱們通常把HMaster簡寫爲Master,它是用來作請求調度的。換句話說,Master是協調各個RegionServers工做過程的,比方說,咱們寫一個數據時,應該發往哪一個RegionServers的那個位置進行存儲等;

    Master想要研發協調多個RegionServers過程的話會比較困難,所以Master藉助一個現有的項目叫ZooKeeper來完成各RegionServers的協調。簡單的來講,若是某個RegionServer宕機時,那麼此前的RegionServer保存的數據應該其它那些HRegionServers中從新構建出來呢?這就是由ZooKeeper來協調完成的。

  b>.RegionServers

    HRegionServers是用來真正存取的服務器。

  c>.ZooKeeper

    在經過一組服務器向客戶端提供服務的場景中,須要客戶端能定位各服務器以便使用其提供的服務。然而這面臨的挑戰之一即是如何維持這個服務器列表——其顯然不能放置於網絡中的某單個節點上,不然此節點故障將致使整個系統不可用。即使咱們有辦法保證存儲此服務器列表的節點不會出現故障,但當列表中的某服務器故障時將其移出列表仍然會是個問題,故障的服務器沒法自行退出列表,所以這須要外部的一組處理動做來完成。Zookeeper正是設計用來提供這種服務。

    能夠把Zookeeper想像成爲一個提供高可用功能的文件系統,它沒有文件或目錄,而用znode來統一實現目錄及文件的功能,它既能夠存儲數據,又能夠包含其它的znode。全部的znodes組成一個層次性的名稱空間,父節點的名稱爲某服務器組的名稱,其子節點的名稱爲此組中的各服務器名稱。

固然,ZooKeeper還有着諸多優勢:
  
1、簡潔:ZooKeeper的核心是一個精簡的文件系統,它僅提供了幾個簡單操做和一些額外的抽像機制如排序和通知等功能;   2、富於表現力:ZooKeeper的本體是一組豐富的可用於構建大規模協做式數據結構和協議的代碼塊,這包括分佈式隊列、分佈式鎖以及在一組節點中推舉主導節點等;   3、高可用:ZooKeeper運行於一組主機,設計人員在對其進行設計時就充分考慮到節點故障的可能性並由此給系統帶來的問題,由此爲其添加了高可用能力;   4、鬆耦合的交互性:ZooKeeper的交互式並不要求協做方事先互相知悉彼此的存在,甚至也不要求各協做方預先進行同步;   5、開源:ZooKeeper是一個開源項目;   6、高性能

 3>.HBase特性:

  a>.線性及模塊可擴展性;
  b>.嚴格一致性讀寫;
  c>.可配置表的自動切分策略;
  d>.RegionServer自動故障恢復;
  e>.便利的API;
  f>.實時查詢緩存;

 

八.Hive

1>.什麼是Hive

  HDFS的訪問接口只有一個,即MapReduce編程接口,要想對HDFS系統中的數據進行處理,程序員就只能編程了,好在MapReduce能夠支持多種API了,好比Python,shell等等,只不過沒有Java的速度更快而已(由於Hadoop整個生態圈都是用Java語言實現的,若是你用其它的語言進行交互,必然會存在一個翻譯的過程,而這個翻譯過程天然而然是須要佔用必定時間的!)所以咱們若是真的想要對MapReduce進行研發,最好仍是以Java編程語言爲主。可是不能讓全部使用Hadoop軟件的IT人員都成爲程序員,這個時候Facebook就在Hadoop的基礎之上,給他引入了一個新的使用接口,即Hive。

  hive是基於Hadoop的一個數據倉庫工具,能夠將結構化的數據文件映射爲一張數據庫表,並提供簡單的sql查詢功能,能夠將sql語句轉換爲MapReduce任務進行運行。 其優勢是學習成本低,能夠經過類SQL語句快速實現簡單的MapReduce統計,沒必要開發專門的MapReduce應用,十分適合數據倉庫的統計分析。簡單的來講,Hive就是把MapReduce的API給封裝成了相似與關係型數據庫的SQL接口,它裏面支持相似與SQL語法的insert,delete,update,select等操做。咱們能夠把Hive編寫的SQL語句稱爲Hive查詢語言,簡稱HQL。所以,咱們根據Hive的HQL編寫的語句以後,Hive內部會負責實現將SQL語句轉移成MapReduce做業。

  因爲Hadoop是批處理的,可能咱們填寫的HQL語句轉移成MapReduce做業後,可能過了半小時仍然沒有返回結果,所以Hive查詢的結果不想SQL查詢是實時的,固然,究其根本緣由並不在於Hive,而是Hadoop的鍋,但好在是Hive給總算給咱們提供了一個簡單的接口,不是嗎?

2>.Hive的適用場景

  Hive 構建在基於靜態批處理的Hadoop 之上,Hadoop 一般都有較高的延遲而且在做業提交和調度的時候須要大量的開銷。所以,Hive 並不可以在大規模數據集上實現低延遲快速的查詢,例如,Hive 在幾百MB 的數據集上執行查詢通常有分鐘級的時間延遲。所以,
  Hive 並不適合那些須要低延遲的應用,例如,聯機事務處理(OLTP)。Hive 查詢操做過程嚴格遵照Hadoop MapReduce 的做業執行模型,Hive 將用戶的HiveQL 語句經過解釋器轉換爲MapReduce 做業提交到Hadoop 集羣上,Hadoop 監控做業執行過程,而後返回做業執行結果給用戶。Hive 並不是爲聯機事務處理而設計,Hive 並不提供實時的查詢和基於行級的數據更新操做。Hive 的最佳使用場合是大數據集的批處理做業,例如,網絡日誌分析。
  鑑於Hive自己的限制,若是指望在大數據集上實現OLTP式的特性,就得認真考慮NoSQL數據庫了,好比HBase、Cassandra和DynamoDB等。

3>.Hive的特性

  a>.支持索引,加快數據查詢。
  b>.不一樣的存儲類型,例如,純文本文件、HBase 中的文件。
  c>.將元數據保存在關係數據庫中,大大減小了在查詢過程當中執行語義檢查的時間。
  d>.能夠直接使用存儲在Hadoop 文件系統中的數據。
  e>.內置大量用戶函數UDF 來操做時間、字符串和其餘的數據挖掘工具,支持用戶擴展UDF 函數來完成內置函數沒法實現的操做。
  f>.類SQL 的查詢方式,將SQL 查詢轉換爲MapReduce 的job 在Hadoop集羣上執行。
 
 
九.pig
   從某種意義上來說,Hive是基於Hadoop文件系統之上數據倉庫的工具,它爲數據倉庫的管理提供了諸多功能來完成數據的ETL工具(收集數據,轉換數據,加載數據),同時又是數據存儲管理和大型數據集查詢和分析的工具。不過,Hive僅僅是其衆多實現方案中的一個,由於Hive的接口是相似於SQL接口的,可是這種接口自己是否好用,若是你以前學過SQL語句的話,想要使用Hive並非一件難事,若是以前沒有學習過SQL編程語言的話,好比你只學習過腳本編程語言並不會SQL語言,對於這一類的用戶雅虎又研發了另一個項目叫作"pig"。
  Pig是一種數據流語言和運行環境,用於檢索很是大的數據集。爲大型數據集的處理提供了一個更高層次的抽象。Pig包括兩部分:一是用於描述數據流的語言,稱爲Pig Latin;二是用於運行Pig Latin程序的執行環境。
  Apache Pig 是一個高級過程語言,適合於使用 Hadoop 和 MapReduce 平臺來查詢大型半結構化數據集。經過容許對分佈式數據集進行相似 SQL 的查詢,Pig 能夠簡化 Hadoop 的使用。 [1] 
  用MapReduce進行數據分析。當業務比較複雜的時候,使用MapReduce將會是一個很複雜的事情,好比你須要對數據進行不少預處理或轉換,以便可以適應MapReduce的處理模式。另外一方面,編寫MapReduce程序,發佈及運行做業都將是一個比較耗時的事情。Pig的出現很好的彌補了這一不足。Pig可以讓你專心於數據及業務自己,而不是糾結於數據的格式轉換以及MapReduce程序的編寫。本質是上來講,當你使用Pig進行處理時,Pig自己會在後臺生成一系列的MapReduce操做來執行任務,可是這個過程對用戶來講是透明的。 [2] 
  Pig相比Hive到底哪一個更好,咱們無從而知,不過兩種實現方式都得去花費時間和精力學習,由於Pig畢竟不是腳本,Hive畢竟不是SQL語句。選擇適合你用的就好。我在網上找到了Pig和Hive的比較以下圖所示:

 

 
十.日誌收集工具
  目前爲止,Hadoop的一個主流應用就是對於大規模web日誌的分析和處理,所以想要把web服務的日誌導入到Hadoop來進行分析就得藉助日誌收集工具了。目前主流的Hadoop日誌收集工具可以跟Hadoop進行交接的有三個工具,即flume,scribe和chukwa。
1>.flume
  Flume是Cloudera提供的一個高可用的,高可靠的,分佈式的海量日誌採集、聚合和傳輸的系統,Flume支持在日誌系統中定製各種數據發送方,用於收集數據;同時,Flume提供對數據進行簡單處理,並寫到各類數據接受方(可定製)的能力。
  當前Flume有兩個版本Flume 0.9X版本的統稱Flume-og,Flume1.X版本的統稱Flume-ng。因爲Flume-ng通過重大重構,與Flume-og有很大不一樣,使用時請注意區分。
  Flume最先是Cloudera提供的日誌收集系統,目前是Apache下的一個孵化項目,Flume支持在日誌系統中定製各種數據發送方,用於收集數據。詳情請參考:http://flume.apache.org/
2>.scribe
  Scribe是Facebook開源的日誌收集系統,在Facebook內部已經獲得的應用。它可以從各類日誌源上收集日誌,存儲到一箇中央存儲系統(能夠是NFS,分佈式文件系統 等)上,以便於進行集中統計分析處理
3>.chukwa
  Apache 的開源項目 hadoop, 做爲一個分佈式存儲和計算系統,已經被業界普遍應用。不少大型企業都有了各自基於 hadoop 的應用和相關擴展。當 1000+ 以上個節點的 hadoop 集羣變得常見時,集羣自身的相關信息如何收集和分析呢?針對這個問題, Apache 一樣提出了相應的解決方案,那就是 chukwa。
  chukwa 的官方網站是這樣描述本身的: chukwa 是一個開源的用於監控大型分佈式系統的數據收集系統。這是構建在 hadoop 的 hdfs 和 map/reduce 框架之上的,繼承了 hadoop 的可伸縮性和健壯性。 Chukwa 還包含了一個強大和靈活的工具集,可用於展現、監控和分析已收集的數據。 在一些網站上,甚至聲稱 chukwa 是一個「日誌處理/分析的full stack solution」。 說了這麼多,你心動了嗎?詳情請參考:http://chukwa.apache.org/
 
十一.數據導入HDFS的工具
  Sqoop(發音:skup)是一款開源的工具,主要用於在Hadoop(Hive)與傳統的數據庫(mysql、postgresql...)間進行數據的傳遞,能夠將一個關係型數據庫(例如 : MySQL ,Oracle ,Postgres等)中的數據導進到Hadoop的HDFS中,也能夠將HDFS的數據導進到關係型數據庫中。
  Sqoop項目開始於2009年,最先是做爲Hadoop的一個第三方模塊存在,後來爲了讓使用者可以快速部署,也爲了讓開發人員可以更快速的迭代開發,Sqoop獨立成爲一個Apache項目。詳情請參考:http://sqoop.apache.org/
 
十二.Mahout 
   Mahout 是 Apache Software Foundation(ASF) 旗下的一個開源項目,提供一些可擴展的機器學習領域經典算法的實現,旨在幫助開發人員更加方便快捷地建立智能應用程序。Mahout包含許多實現,包括聚類、分類、推薦過濾、頻繁子項挖掘。此外,經過使用 Apache Hadoop 庫,Mahout 能夠有效地擴展到雲中。詳情請參考:https://www.ibm.com/developerworks/cn/java/j-mahout/
 
十三.Hadoop生態圈
2) Nutch,互聯網數據及Nutch搜索引擎應用 3) HDFS,Hadoop的分佈式文件系統 5) MapReduce,分佈式計算框架 6) Flume、Scribe,Chukwa數據收集,收集非結構化數據的工具。 7) Hiho、Sqoop,講關係數據庫中的數據導入HDFS的工具 8) Hive數據倉庫,pig分析數據的工具 10)Oozie做業流調度引擎 11)Hue,Hadoop本身的監控管理工具 12)Avro 數據序列化工具 13)mahout數據挖掘工具 14)Hbase分佈式的面向列的開源數據庫
相關文章
相關標籤/搜索