一、MapReduce理論基礎
每個MapReduce job都是Hadoop客戶端想要執行的一個工作單元，它一般由輸入數據、MapReduce程序和配置信息組成，而Hadoop會把每個job分隔成兩類任務(task)：map任務和reduce任務。在Hadoop集群中有兩類節點來執行兩類job進程的執行
1.1 大數據處理
任何基礎業務包含了收集、分析、監控、過濾、搜索或組織web內容的公司或組織都面臨著所謂的“大數據”問題：“web規模”處理即海量數據處理的代名詞。社交類網站的興起也使得這些組織面臨著另一個問題：用戶行為數據分析，這涉及到通過日志文件記錄用戶的對web頁面瀏覽、點擊、停留時長等，而后對日志文件中的大量數據進行分析以支持進行合理、正確的商業決策。
大數據問題的處理需要以與傳統數據處理方式所不同的方法去實現，這正是MapReduce思想得以大放光彩的核心所在。MapReduce在實現大數據處理上有著多個基礎理論思想的支撐，然而這些基礎理論甚至實現方法都未必是MapReduce所創，它們只是被MapReduce采用獨特的方式加以利用而已。
(1) 向外擴展(Scale out)而非向上擴展(Scale up)：大數據的處理更適合采用大量低端商業服務器(scale out)而非少量高端服務器(scale up)。后者正是向上擴展的系統性能提升方式，它通常采用有著SMP架構的主機，然而有著大量的CPU插槽(成百上千個)及大量的共享內存(可以多達數百GB)的高端服務器非常昂貴，但其性能的增長卻非線性上升的，因此性價比很一般。而大量的低端商業服務器價格低廉、易于更換和伸縮等特性有效避免了向上擴展的敝端。
(2)假設故障很常見(Assume failures are common)：在數據倉庫架構級別，故障是不可避免且非常普遍的。假設一款服務器出故障的平均概率為1000天1次，那么10000臺這種服務器每天出錯的可能性將達到10次。因此，大規模向外擴展的應用場景中，一個設計優良且具有容錯能力的服務必須能有效克服非常普遍的硬件故障所帶來的問題，即故障不能導致用戶應用層面的不一致性或非確定性。MapReduce編程模型能通過一系列機制如任務自動重啟等健壯地應付系統或硬件故障。
(3)將處理移向數據(Move processing to the data)：傳統高性能計算應用中，超級計算機一般有著處理節點(processing node)和存儲節點(storage node)兩種角色，它們通過高容量的設備完成互聯。然而，大多數數據密集型的處理工作并不需要多么強大的處理能力，于是把計算與存儲互相分開將使得網絡成為系統性能瓶頸。為了克服計算如此類的問題，MapReduce在其架構中將計算和存儲合并在了一起，并將數據處理工作直接放在數據存儲的位置完成，只不過這需要分布式文件系統予以支撐。
(4)順序處理數據并避免隨機訪問(Process data sequentially and avoid random access)：大數據處理通常意味著海量的數量難以全部載入內存，因而必須存儲在磁盤上。然而，機械式磁盤尋道操作的先天性缺陷使得隨機數據訪問成為非常昂貴的操作，因此避免隨機數據訪問并以順序處理為目的完成數據組織成為亟待之需。固態磁盤雖然避免了機械磁盤的某此缺陷，然而其高昂的價格以及并沒有消除的隨機訪問問題仍然無法帶來性能上的飛躍發展。MapReduce則主要設計用來在海量數據集上完成批處理操作，即所有的計算被組織成較長的流式處理操作，以延遲換取較大的吞吐能力。
(5)向程序員隱藏系統級別的細節(Hide system-level details from the application developer)：
(6)無縫擴展(Seamless scalability)：
1.2 MapReduce和大數據問題
海量數據處理的核心思想無非是將一個較大的問題進行“分割包圍、逐個殲滅”。然而其難點和關鍵點在于如何將一個大的問題分分割成多個可以分別在不同的CPU上或不同的主機上進行處理的獨立小問題，而且這些獨立進行處理的小問題所產生的中間結果又該如何合并成最終結果并予以輸出。因此，看似簡單的化整為零的處理思想卻不得不面臨如下的難題：
(1) 如何將大問題分割為小任務？進一步地，如何將大問題分解為可以并行處理的小任務？
(2) 如何將分解好的小任務派送給分布式系統中的某主機且是較為適合解決此問題的主機上的worker完成處理？
(3) 如何保證某worker獲取所需的數據？
(4) 如何協調不同worker之間進行同步？
(5) 如何將某worker的部分結果共享給其它需要此結果的worker？
(6) 如何在出現軟件或硬件故障時仍然能保證上述工作的順利進行？
在傳統的并行或分布式編程模型中，程序員不得不顯式地解決上述的部分甚至是全部問題，而在共享內存編程中，程序員需要顯式地協調對共享數據結構的如互斥鎖的訪問、顯式地通過柵(barrier)等設備解決進程同步問題、并得時刻警惕著程序中可能出現的死鎖或競爭條件。雖然有些編程語言也或多或少地規避了讓程序員面對上述問題，但卻也避免不了將資源分配給各worker的問題。MapReduce的優勢之一便是有效地向程序員隱藏了這些問題。
1.3 函數式編譯語言
MapReduce是一種類似于Lisp或ML的函數式編程語言。函數式編程的核心特性之一是基于高階函數，即能夠接受其它函數作為參數的函數完成編程。MapReduce有兩個常見地內置高階函數map和fold。
如圖所示，給定一個列表，map(接受一個參數)以函數f為其參數并將其應用于列表中的所有元素；fold(接受兩個參數)以函數g和一個初始值作為參數，然后將g應用于初始值和列表中的第一個元素，結果被放置于中間變量中。中間變量和第二個元素將作為g函數下一次應用時的參數，而后如此操作直至將列表中的所有元素處理完畢后，fold會將最終處理結果保存至一個中間變量中。
于是，基于上述過程，我們可以把map視作利用f函數將給定數據集完成形式轉換的操作，同樣地，fold就可以被看作利用g函數完成數據聚合的操作。我們就可以由此得知，各函數式程序在運行時彼此間是隔離的，因此，在map中將f函數應用于列表中每一個元素的操作可以并行進行，進一步地講，它們可以分布于集群中的不同節點上并行執行。然而，受限于數據的本地性，fold操作需要等到列表中的每一個元素都準備停當之后才能進行。幸運地是，現實生活中的應用程序并不要求g函數應用于列表中的所有元素，因此，列表中元素可以被分為多個邏輯組，并將fold操作并行地應用在這些邏輯組上即可。由此，fold操作也可以以并行的方式高效完成。
MapReduce有兩個常見地內置高階函數map和reduce，其map就類似于上述過程中的map操作，reduce對應于上述過程中的fold操作。只不過，MapReduce的執行框架能自行協調map與reduce并將其應用于在商業服務器硬件平臺上并行處理海量數據。
更為精確地說，MapReduce有三個相互關聯卻各不相同的概念。首先，MapReduce是一個如上所述的函數式編程語言。其次，MapReduce也是一個運行框架，它能夠協調運行基于MapReduce思想開發的程序。最后，MapReduce還可以被看作編程模型和執行框架的軟件實現，如Google的專有實現和另一個開源實現Hadoop等。
1.4 mapper和reducer
鍵值對兒(Key-value pair)是MapReduce的基礎數據結構。Key和Value可以是基礎類型數據，如整數、浮點數、字符串或未經加工的字節數據，也可以是任意形式的復雜數據類型。程序員可以自行定義所需的數據類型，也可借助于Protocol Buffer、Thrift或Avro提供的便捷方式完成此類工作。
MapReduce算法設計的工作之一就是在給定數據集上定義“鍵-值”數據結構，比如在搜索引擎搜集、存儲網頁類工作中，key可以使用URL來表示，而value則是網頁的內容。而在有些算法中，Key也可以是沒有任何實際意義的數據，其在數據處理過程中可被安全忽略。在MapReduce中，程序員需要基于如下方式定義mapper和reducer：
map: (k1,v1)–>[(k2,v20)]
reduce: (k2,[v2])–>[(k3,v3)]
其中[…]意味著其可以是一個列表。這些傳遞給MapReduce進行處理的數據存儲于分布式文件上，mapper操作將應用于每一個傳遞過來的鍵-值對并生成一定數量的中間鍵值對(intermediate key-value)，而后reduce操作將應用于這些中間鍵值對并輸出最終的鍵值對。然而，mapper操作和reducer操作之間還隱含著一個應用于中間鍵值對的“分組”操作，同一個鍵的鍵值對需要被歸類至同一組中并發送至同一個reducer，而傳送給每個reducer的分組中的鍵值對是基于鍵進行排序后的列表。reducer生成的結果將會保存至分布式文件系統，并存儲為一個或多個以r(即reducer號碼)結尾的文件，但mapper生成的中間鍵值對數據則不會被保存。
在Hadoop中，mapper和reducer是分別由MAP和REDUCE方法實現的對象。每個map任務(接收一個稱作input split的鍵值對列表)都被初始化一個mapper對象，并會由執行框架為每個輸入的鍵值對調用一次其map方法。程序員可以配置啟動的map任務個數，但其真正啟動的數目則由執行框架根據數據的物理分布最終給定。類似地，每個reduce任務由REDUCE方法初始化為一個reduce對象，并會由執行框架為其接受的每個中間鍵值對調用一次REDUCE方法，所不同的是，程序員可以明確限定啟動的reduce任務的個數。
mapper和reducer可以直接在各自接收的數據上執行所需要的操作，然而，當使用到外部資源時，多個mapper或reducer之間可能會產生資源競爭，這勢必導致其性能下降，因此，程序員必須關注其所用資源的競爭條件并加入適當處理。其次，mapper輸出的中間鍵值對與接受的鍵值對可以是不同的數據類型，類似地，reducer輸出的鍵值對與其接收的中間鍵值對也可以是不同的數據類型，這可能會給編程過程及程序運行中的故障排除帶來困難，但這也正是MapReduce強大功能的體現之一。
除了常規的兩階段MapReduce處理流外，其還有一些變化形式。比如將mapper輸出的結果直接保存至磁盤中(每個mapper對應一個文件)的沒有reducer的MapReduce作業，不過僅有reducer而沒有mapper的作業是不允許的。不過，就算用不著reducer處理具體的操作，利用reducer將mapper的輸出結果進行重新分組和排序后進行輸出也能以另一種形式提供的完整MapReduce模式。
MapReduce作業一般是通過HDFS讀取和保存數據，但它也可以使用其它滿足MapReduce應用的數據源或數據存儲，比如Google的MapReduce實現中使用了Bigtable來完成數據的讀入或輸出。BigTable屬于非關系的數據庫，它是一個稀疏的、分布式的、持久化存儲的多維度排序Map，其設計目的是可靠的處理PB級別的數據，并且能夠部署到上千臺機器上。在Hadoop中有一個類似的實現HBase可用于為MapReduce提供數據源和數據存儲。
1.5 Hadoop運行框架
MapReduce程序也稱作為MapReduce作業，一般由mapper代碼、reducer代碼以及其配置參數(如從哪兒讀入數據，以及輸出數據的保存位置)組成。準備好的作業可通過JobTracker(作業提交節點)進行提交，然后由運行框架負責完成后續的其它任務。這些任務主要包括如下幾個方面。
(1) 調度
每個MapReduce作業都會劃分為多個稱作任務(task)的較小單元，而較大的作業劃分的任務數量也可能會超出整個集群可運行的任務數，此時就需要調度器程序維護一個任務隊列并能夠追蹤正在運行態任務的相關進程，以便讓隊列中處于等待狀態的任務派送至某轉為可用狀態的節點運行。此外，調度器還要負責分屬于不同作業的任務協調工作。
對于一個運行中的作業來說，只有所用的map任務都完成以后才能將中間數據分組、排序后發往reduce作業，因此，map階段的完成時間取決于其最慢的一個作業的完成時間。類似的，reduce階段的最后一個任務執行結束，其最終結果才為可用。因此，MapReduce作業完成速度則由兩個階段各自任務中的掉隊者決定，最壞的情況下，這可能會導致作業長時間得不到完成。出于優化執行的角度，Hadoop和Google MapReduce實現了推測執行(Speculative execution)機制，即同一個任務會在不同的主機上啟動多個執行副本，運行框架從其最快執行的任務中取得返回結果。不過，推測執行并不能消除其它的滯后場景，比如中間鍵值對數據的分發速度等。
(2) 數據和代碼的協同工作(data/code co-location)
術語“數據分布”可能會帶來誤導，因為MapReduce盡力保證的機制是將要執行的代碼送至數據所在的節點執行，因為代碼的數據量通常要遠小于要處理的數據本身。當然，MapReduce并不能消除數據傳送，比如在某任務要處理的數據所在的節點已經啟動很多任務時，此任務將不得不在其它可用節點運行。此時，考慮到同一個機架內的服務器有著較充裕的網絡帶寬，一個較優選擇是從數據節點同一個機架內挑選一個節點來執行此任務。
(3) 同步(Synchronization)
異步環境下的一組并發進程因直接制約而互相發送消息而進行互相合作、互相等待，使得各進程按一定的速度執行的過程稱為進程間同步，其可分為進程同步(或者線程同步)和數據同步。就編程方法來說，保持進程間同步的主要方法有內存屏障(Memory barrier)，互斥鎖（Mutex），信號量(Semaphore)和鎖(Lock)，管程(Monitor)，消息(Message)，管道(Pipe)等。MapReduce是通過在map階段的進程與reduce階段的進程之間實施隔離來完成進程同步的，即map階段的所有任務都完成后對其產生的中間鍵值對根據鍵完成分組、排序后通過網絡發往各reducer方可開始reduce階段的任務，因此這個過程也稱為“shuffle and sort”。
(4) 錯誤和故障處理(Error and fault handling)
MapReduce運行框架本身就是設計用來容易發生故障的商用服務器上了，因此，其必須有著良好的容錯能力。在任何類別的硬件故障發生時，MapReduce運行框架均可自行將運行在相關節點的任務在一個新挑選出的節點上重新啟動。同樣，在任何程序發生故障時，運行框架也要能夠捕獲異常、記錄異常并自動完成從異常中恢復。另外，在一個較大規模的集群中，其它任何超出程序員理解能力的故障發生時，MapReduce運行框架也要能夠安全挺過。
1.6 partitioner和combiner
除了前述的內容中的組成部分，MapReduce還有著另外兩個組件：partiontioner和combiner。
Partitioner負責分割中間鍵值對數據的鍵空間(即前面所謂的“分組”)，并將中間分割后的中間鍵值對發往對應的reducer，也即partitioner負責完成為一個中間鍵值對指派一個reducer。最簡單的partitioner實現是將鍵的hash碼對reducer進行取余計算，并將其發往余數對應編號的reducer，這可以盡力保證每個reducer得到的鍵值對數目大體上是相同的。不過，由于partitioner僅考慮鍵而不考慮“值”，因此，發往每個reducer的鍵值對在鍵數目上的近似未必意味著數據量的近似。
Combiner是MapReduce的一種優化機制，它的主要功能是在“shuffle and sort”之前先在本地將中間鍵值對進行聚合，以減少在網絡上發送的中間鍵值對數據量。因此可以把combiner視作在“shuffle and sort”階段之前對mapper的輸出結果所進行聚合操作的“mini-reducer”。在實現中，各combiner之間的操作是隔離的，因此，它不會涉及到其它mapper的數據結果。需要注意的是，就算是某combiner可以有機會處理某鍵相關的所有中間數據，也不能將其視作reducer的替代品，因為combiner輸出的鍵值對類型必須要與mapper輸出的鍵值對類型相同。無論如何，combiner的恰當應用將有機會有效提高作業的性能。
二、分布式文件系統
前面的討論中，我們已經了解了Hadoop中實現的MapReduce是一個編程模型和運行框架，它能夠通過JobTracker接收客戶提交的作業而后將其分割為多個任務后并行運行在多個TaskTracker上。而問題是，這些TaskTracker如何高效獲取所要處理的數據？
在傳統的高性能集群中，計算節點和存儲節點是各自獨立的，它們之間通過高速網絡完成互聯，然而，在面臨海量數據處理的問題時，網絡必然會成為整個系統的性能瓶頸，這就需要引入超高速的網絡如萬兆以太網或Infiniband。然而，對大數場景來講它們屬于“奢侈品”，且昂貴的投入并不能帶來網絡性能的線性提升，因此性價比不高。面對這種問題，MapReduce采取了將計算節點與存儲節點合二為一的集群模型，它利用分布式文件系統將數據存儲于多個節點上，而后讓處理過程在各數據節點本地直接進行，從而極大地降低了數據通過網絡傳送的需求。不過，這里仍然需要說明的是，MapReduce并非依賴于分布式文件系統，只不過運行在非分布式文件系統的MapReduce的諸多高級特性將無用武之地。
事實上，分布式文件系統并非MapReduce帶來的新生事物，只不過，MapReduce站在前人的基礎上將分布式文件系統進行了改造以使得它更能夠適用于在MapReduce中完成海量數據處理。Google為在他們的MapReduce中實現的分布式文件系統為GFS(Google File System)，而Hadoop的實現稱作HDFS(Hadoop Distributed File System)。
2.1 HDFS的設計理念
HDFS專為存儲大文件而設計，可運行于普通的商業服務器上，基于流式數據訪問模型完成數據存取。HDFS將所有文件的元數據存儲于名稱節點(NameNode)的內存中，能夠利用分布式特性高效地管理“大”文件(GB級別甚至更大的文件)，對于有著海量小文件的應用場景則會給名稱節點帶去巨大壓力并使得其成為系統性能瓶頸。再者，HDFS為MapReduce的計算框架而設計，存儲下來數據主要用于后續的處理分析，其訪問模型為“一次寫入、多次讀取”；因此，數據在HDFS中存儲完成后，僅能在文件尾部附加新數據，而不能對文件進行修改。另外，HDFS專為了高效地傳輸大文件進行了優化，其為了完成此目標，在“低延遲”特性上做出了很大讓步，因此，其不適用于較小訪問延遲的應用。
2.2 HDFS架構
2.2.1 HDFS數據塊
與傳統文件系統一樣，HDFS也在“塊(block)”級別存取文件，所不同的是，傳統文件系統數據塊一般較小(1KB、2KB或4KB等)，HDFS的數據塊大小默認為64MB，甚至可以使用128MB或256MB級別的數據塊。HDFS使用塊抽象層管理文件，可以實現將分塊分為多個邏輯部分后分布于多個存儲節點，也能夠有效簡化存儲子系統。而對于存儲節點來說，較大的塊可以減少磁盤的尋道次數，進而提升I/O性能。
2.2.2 名稱節點(NameNode)和數據節點(DataNode)
HDFS集群中節點的工作模型為“master-worker”：其包含一個名稱節點(master)和多個數據節點(worker)。
名稱節點負責管理HDFS的名稱空間，即以樹狀結構組織的目錄及文件的元數據信息，這些信息持久存儲于名稱節點本地磁盤上并保存為名稱空間鏡像(namespace image)和編輯日志(edit log)兩個文件。名稱節點并不存儲數據塊，它僅需要知道每個文件對應數據塊的存儲位置，即真正存儲了數據塊的數據節點。然而，名稱節點并不會持久存儲數據塊所與其存儲位置的對應信息，因為這些信息是在HDFS集群啟動由名稱節點根據各數據節點發來的信息進行重建而來。這個重建過程被稱為HDFS的安全模式。數據節點的主要任務包括根據名稱節點或客戶的要求完成存儲或讀取數據塊，并周期性地將其保存的數據塊相關信息報告給名稱節點。
默認情況下，HDFS會在集群中為每個數據塊存儲三個副本以確保數據的可靠性、可用性及性能表現。在一個大規模集群中，這三個副本一般會保存至不同機架中的數據節點上以應付兩種常見的故障：單數據節點故障和導致某機架上的所有主機離線的網絡故障。另外，如前面MapReduce運行模型中所述，為數據塊保存多個副本也有利于MapReduce在作業執行過程中透明地處理節點故障等，并為MapReduce中作業協同處理以提升性能提供了現實支撐。名稱節點會根據數據節點的周期性報告來檢查每個數據塊的副本數是否符合要求，低于配置個數要求的將會對其進行補足，而多出的將會被丟棄。
HDFS提供了POSIX網絡的訪問接口，所有的數據操作對客戶端程序都是透明的。當客戶端程序需要訪問HDFS中的數據時，它首先基于TCP/IP協議與名稱節點監聽的TCP端口建立連接，接著通過客戶端協議(Client Protocol)發起讀取文件的請求，而后名稱節點根據用戶請求返回相關文件的塊標識符(blockid)及存儲了此數據塊的數據節點。接下來客戶端向對應的數據節點監聽的端口發起請求并取回所需要數據塊。當需要存儲文件并寫數據時，客戶端程序首先會向名稱節點發起名稱空間更新請求，名稱節點檢查用戶的訪問權限及文件是否已經存在，如果沒有問題，名稱空間會挑選一個合適的數據節點分配一個空閑數據塊給客戶端程序。客戶端程序直接將要存儲的數據發往對應的數據節點，在完成存儲后，數據節點將根據名稱節點的指示將數據塊復制多個副本至其它節點。
2.2.3 名稱節點的可用性
由前一節所述的過程可以得知，名稱節點的宕機將會導致HDFS文件系統中的所有數據變為不可用，而如果名稱節點上的名稱空間鏡像文件或編輯日志文件損壞的話，整個HDFS甚至將無從重建，所有數據都會丟失。因此，出于數據可用性、可靠性等目的，必須提供額外的機制以確保此類故障不會發生，Hadoop為此提供了兩種解決方案。
最簡單的方式是將名稱節點上的持久元數據信息實時存儲多個副本于不同的存儲設備中。Hadoop的名稱節點可以通過屬性配置使用多個不同的名稱空間存儲設備，而名稱節點對多個設備的寫入操作是同步的。當名稱節點故障時，可在一臺新的物理主機上加載一份可用的名稱空間鏡像副本和編輯日志副本完成名稱空間的重建。然而，根據編輯日志的大小及集群規模，這個重建過程可能需要很長時間。
另一種方式是提供第二名稱節點(Secondary NameNode)。第二名稱節點并不真正扮演名稱節點角色，它的主要任務是周期性地將編輯日志合并至名稱空間鏡像文件中以免編輯日志變得過大。它運行在一個獨立的物理主機上，并需要跟名稱節點同樣大的內存資源來完成文件合并。另外，它還保存一份名稱空間鏡像的副本。然而，根據其工作機制可知，第二名稱節點要滯后于主節點，因此名稱節點故障時，部分數據丟失仍然不可避免。
盡管上述兩種機制可以最大程序上避免數據丟失，但其并不具有高可用的特性，名稱節點依然是一個單點故障，因為其宕機后，所有的數據將不能夠被訪問，進而所有依賴于此HDFS運行的MapReduce作業也將中止。就算是備份了名稱空間鏡像和編輯日志，在一個新的主機上重建名稱節點并完成接收來自各數據節點的塊信息報告也需要很長的時間才能完成。在有些應用環境中，這可能是無法接受的，為此，Hadoop 0.23引入了名稱節點的高可用機制——設置兩個名稱節點工作于“主備”模型，主節點故障時，其所有服務將立即轉移至備用節點。進一步信息請參考官方手冊。
在大規模的HDFS集群中，為了避免名稱節點成為系統瓶頸，在Hadoop 0.23版本中引入了HDFS聯邦(HDFS Federation)機制。HDFS聯邦中，每個名稱節點管理一個由名稱空間元數據和包含了所有塊相關信息的塊池組成名稱空間卷(namespace volume)，各名稱節點上的名稱空間卷是互相隔離的，因此，一個名稱節點的損壞并不影響其它名稱節點繼續提供服務。進一步信息請參考官方手冊。
ZooKeeper
在通過一組服務器向客戶端提供服務的場景中，需要客戶端能定位各服務器以便使用其提供的服務。然而這面臨的挑戰之一便是如何維持這個服務器列表——其顯然不能放置于網絡中的某單個節點上，否則此節點故障將導致整個系統不可用。即便我們有辦法保證存儲此服務器列表的節點不會出現故障，但當列表中的某服務器故障時將其移出列表仍然會是個問題，故障的服務器無法自行退出列表，因此這需要外部的一組處理動作來完成。Zookeeper正是設計用來提供這種服務。
可以把Zookeeper想像成為一個提供高可用功能的文件系統，它沒有文件或目錄，而用znode來統一實現目錄及文件的功能，它既可以存儲數據，又可以包含其它的znode。所有的znodes組成一個層次性的名稱空間，父節點的名稱為某服務器組的名稱，其子節點的名稱為此組中的各服務器名稱。
開發分布式程序是比較困難的，主要原因在于“部分性錯誤”——當報文通過網絡在兩個節點間傳遞的過程中發生了網絡錯誤，此時，發送方對數據是否已經完整發送至對方無從知曉。惟一可以獲知此相關信息的途徑是重新連接收方并向其發出詢問，但這本身也還是一個問題——我們無法得知詢問本身是否正常完成。
ZooKeeper并不能消除“部分性錯誤”，因為其本質上也是分布式系統。因此，其當然也無法隱藏“部分性錯誤”。然而，ZooKeeper提供了一組工具，它們能夠幫助程序員構建可安全處理“部分式錯誤”的分布式應用程序。當然，ZooKeeper還有著諸多優點：
1、簡潔：ZooKeeper的核心是一個精簡的文件系統，它僅提供了幾個簡單操作和一些額外的抽像機制如排序和通知等功能；
2、富于表現力：ZooKeeper的本體是一組豐富的可用于構建大規模協作式數據結構和協議的代碼塊，這包括分布式隊列、分布式鎖以及在一組節點中推舉主導節點等；
3、高可用：ZooKeeper運行于一組主機，設計人員在對其進行設計時就充分考慮到節點故障的可能性并由此給系統帶來的問題，由此為其添加了高可用能力；
4、松耦合的交互性：ZooKeeper的交互式并不要求協作方事先互相知悉彼此的存在，甚至也不要求各協作方預先進行同步；
5、開源：ZooKeeper是一個開源項目；
6、高性能
Pig:
Hive:
適用于數據倉庫類的應用程序，但其并不是一個全狀態的數據庫，這主要受限于Hadoop自身設計的缺陷。其最大的缺陷在于Hive不支持行級別的更新、插入和刪除操作。其次，Hadoop是面向批處理的系統，其MapReduce job的啟動有著很大的開銷，因此Hive查詢有著很高的延遲，通常在傳統數據上可以幾秒鐘完成的查詢操作在Hive需要更長的時間，即使數據集非常小也無法避免。再次，Hive無法支持OLTP(Online Transaction Processing)的關鍵特性，而是接近于OLAP(Online Analytic Processing)，然而在Online能力方面的表現仍然與期望有著一定的差距。故此，Hive最適用于數據倉庫類的應用場景，即通過數據挖掘完成數據分析、生成報告并支持智能決策等。
鑒于Hive本身的限制，如果期望在大數據集上實現OLTP式的特性，就得認真考慮NoSQL數據庫了，比如HBase、Cassandra和DynamoDB等。
Namenodes彼此間是聯合(federated)關系，因此各節點均是獨立的。對于Namenodes來說，Datanodes就像是普通的塊設備，它們需要在各Namenodes注冊后才能使用，同時Datanodes則周期性地向Namenodes發送心跳信息、數據塊的使用情況，并負責響應來自Namenodes的各種命令。
Block pool:
隸屬于同一個Namenodes的所有數據塊的集合稱作“塊池”。為了便于Namespace為新加入到當前Namespace的中塊分派Block ID，不同的塊池被設計為彼此間相互獨立，這樣每個Namespace選擇Block ID無須與其它的Namenodes進行協調，同時，任何namenode故障也會影響到datanodes向其它namenodes提供服務。
Namespace和其塊池組合起來稱作Namespace卷——一個自包含的管理單元。當刪除一個Namenode/Namespace時，與之相關的塊池亦會從datanode上刪除。同時，當集群升級時，namespace卷也被當作一個獨立的單元進行升級。
ClusterID
ClusterID用于標識隸屬于某集群的所有節點，任何一個新的namenode在格式化時，集群會自動將當前集群的ClusterID標識于此節點。
優勢：
Namespace Scalability —— HDFS集群存儲進行水平伸縮時namespace不受影響，因此，部署大型HDFS集群或將HDFS集群用于海量小文件時，可通過簡單的添加節點對集群進行擴展。
Performance —— HDFS文件系統的吞吐能力取決于namende，因此，單一namenode很容易成為整個系統性能的瓶頸；而多namenode便于擴展系統性能。
Isolation ——
HBase特性：
線性及模塊可擴展性
嚴格一致性讀寫
可配置表的自動切分策略
RegionServer自動故障恢復
便利的API
實時查詢緩存
Pig: 利用Hadoop的大規模數據分析的腳本語言和運行框架
Zookeeper: 為分布式應用設計的開源的、用于協調服務，可以為用戶提供同步、配置管理、分組和名稱空間管理的功能；
zookeeper至少要三個節點，要盡可能是奇數個節點；
Impala: 實時分析和處理， chubby
發行版：
Cloudera
Hortonworks
intel (hadoop)
EMC (hawq)
R: 開源，統計的語言
三、Hadoop
3.1 Hadoop的配置文件：
1）hadoop-env.sh: 用于定義hadoop運行環境相關的配置信息，比如配置JAVA_HOME環境變量、為hadoop的JVM指定特定的選項、指定日志文件所在的目錄路徑以及master和slave文件的位置等；
2）core-site.xml: 用于定義系統級別的參數，如HDFS URL、Hadoop的臨時目錄以及用于rack-aware集群中的配置文件的配置等，此中的參數定義會覆蓋core-default.xml文件中的默認配置；
3）hdfs-site.xml: HDFS的相關設定，如文件副本的個數、塊大小及是否使用強制權限等，此中的參數定義會覆蓋hdfs-default.xml文件中的默認配置；
4）mapred-site.xml：HDFS的相關設定，如reduce任務的默認個數、任務所能夠使用內存的默認上下限等，此中的參數定義會覆蓋mapred-default.xml文件中的默認配置；
5）masters: hadoop的secondary-masters主機列表，當啟動Hadoop時，其會在當前主機上啟動NameNode和JobTracker，然后通過SSH連接此文件中的主機以作為備用NameNode;
6）slaves：Hadoop集群的slave主機列表，master啟動時會通過SSH連接至此列表中的所有主機并為其啟動DataNode和taskTracker進程；
3.2Hadoop的分布式模型
Hadoop通常有三種運行模式：本地(獨立)模式、偽分布式(Pseudo-distributed)模式和完全分布式(Fully distributed)模式。
1）安裝完成后，Hadoop的默認配置即為本地模式，此時Hadoop使用本地文件系統而非分布式文件系統，而且其也不會啟動任何Hadoop守護進程，Map和Reduce任務都作為同一進程的不同部分來執行。因此，本地模式下的Hadoop僅運行于本機。此種模式僅用于開發或調試MapReduce應用程序但卻避免了復雜的后續操作。
2）偽分布式模式下，Hadoop將所有進程運行于同一臺主機上，但此時Hadoop將使用分布式文件系統，而且各jobs也是由JobTracker服務管理的獨立進程。同時，由于偽分布式的Hadoop集群只有一個節點，因此HDFS的塊復制將限制為單個副本，其secondary-master和slave也都將運行于本地主機。此種模式除了并非真正意義的分布式之外，其程序執行邏輯完全類似于完全分布式，因此，常用于開發人員測試程序執行。
3）要真正發揮Hadoop的威力，就得使用完全分布式模式。由于ZooKeeper實現高可用等依賴于奇數法定數目(an odd-numbered quorum)，因此，完全分布式環境需要至少三個節點。
原創文章，作者：nene，如若轉載，請注明出處：http://www.www58058.com/89711
