hadoop 講解

大數據的5V特色（IBM提出）：

Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）
大數據的應用：

預測犯罪的發生；預測禽流感的散佈；美國選舉結果；利用手機定位數據和交通數據創建城市規劃；電商把假貨賣給誰等等。
大數據涉及到的技術：

數據採集；

數據存儲；

數據處理/分析/挖掘；

可視化。
Hadoop

Hadoop是一個由Apache基金會所開發的分佈式系統基礎架構。

Hadoop實現了一個分佈式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性的特色，而且設計用來部署在低廉的（low-cost）硬件上；並且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有着超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求，能夠以流的形式訪問（streaming access）文件系統中的數據。

Hadoop的框架最核心的設計就是：HDFS和MapReduce。HDFS爲海量的數據提供了存儲，則MapReduce爲海量的數據提供了計算。
什麼是分佈式系統？

分佈式系統是若干獨立計算機的集合，這計算機對用戶來講就像單個相關係統。也就是說分佈式系統背後是由一系列的計算機組成的，但用戶感知不到背後的邏輯，就像訪問單個計算機同樣。

一個標準的分佈式系統應該具備如下幾個主要特徵：

    分佈性

分佈式系統中的多臺計算機之間在空間位置上能夠隨意分佈，系統中的多臺計算機之間沒有主、從之分，即沒有控制整個系統的主機，也沒有受控的從機。

    透明性

系統資源被全部計算機共享。每臺計算機的用戶不只可使用本機的資源，還可使用本分佈式系統中其餘計算機的資源(包括CPU、文件、打印機等)。

    同一性

系統中的若干臺計算機能夠互相協做來完成一個共同的任務，或者說一個程序能夠分佈在幾臺計算機上並行地運行。

    通訊性

系統中任意兩臺計算機均可以經過通訊來交換信息。

在分佈式系統中：

一、應用能夠按業務類型拆分紅多個應用，再按結構分紅接口層、服務層；咱們也能夠按訪問入口分，如移動端、PC端等定義不一樣的接口應用；

二、數據庫能夠按業務類型拆分紅多個實例，還能夠對單表進行分庫分表；

三、增長分佈式緩存、搜索、文件、消息隊列、非關係型數據庫等中間件；

很明顯，分佈式系統能夠解決集中式不便擴展的弊端，咱們能夠很方便的在任何一個環節擴展應用，就算一個應用出現問題也不會影響到別的應用。

分佈式系統雖好，也帶來了系統的複雜性，如分佈式事務、分佈式鎖、分佈式session、數據一致性等都是如今分佈式系統中須要解決的難題，雖然已經有不少成熟的方案，但都不完美。分佈式系統也增長了開發測試運維成本，工做量增長，分佈式系統管理很差反而會變成一種負擔。

參考：https://blog.csdn.net/youanyyou/article/details/79406507
Hadoop能作什麼？

創建大型倉庫，PB級（1PB=1024TB 1TB=1024GB）數據的存儲、處理、分析、統計等業務；

搜索引擎，日誌分析，商業智能，數據挖掘等。

1，HDFS：

HDFS：分佈式文件系統，是Hadoop體系中數據存儲管理的基礎。它是一個高度容錯的系統，能檢測和應對硬件故障，用於在低成本的通用硬件上運行。HDFS簡化了文件的一致性模型，經過流式數據訪問（1一次寫入，屢次讀取。文件一旦寫入不能修改，只能追加。2，它能保證數據的一致性。），提供高吞吐量應用程序數據訪問功能，適合帶有大型數據集的應用程序。

將文件切分紅指定大小的數據塊並以多副本（默認：128M）的存儲在多個計算機上；

數據切分、多副本、容錯等操做是對用戶透明的。

特色：擴展性&容錯性&海量數量存儲

HDFS 缺點（不適用適用HDFS的場景）：
一、低延時數據訪問
        1)好比毫秒級的來存儲數據，這是不行的，它作不到。
       2)它適合高吞吐率的場景，就是在某一時間內寫入大量的數據。可是它在低延時的狀況下是不行的，好比毫秒級之內讀取數據，這樣它是很難作到的。

二、小文件存儲
        1)存儲大量小文件的話，它會佔用 NameNode大量的內存來存儲文件、目錄和塊信息。這樣是不可取的，由於NameNode的內存老是有限的。
        2)小文件存儲的尋道時間會超過讀取時間，它違反了HDFS的設計目標。
三、併發寫入、文件隨機修改

        1)一個文件只能有一個寫，不容許多個線程同時寫。
        2)僅支持數據 append（追加），不支持文件的隨機修改。

簡單的分佈式系統設計：

HDFS構架原則：

    元數據與數據分離：文件自己的屬性（即元數據）與文件所持有的數據分離
    主/從架構：一個HDFS集羣是由一個NameNode和必定數目的DataNode組成
    一次寫入屢次讀取：HDFS中的文件在任什麼時候間只能有一個Writer。當文件被建立，接着寫入數據，最後，一旦文件被關閉，就不能再修改
    移動計算比移動數據更划算：數據運算，越靠近數據（爲了儘可能減少全局帶寬的消耗和讀延時），執行運算的性能就越好，因爲hdfs數據分佈在不一樣機器上，要讓網絡的消耗最低，並提升系統的吞吐量，最佳方式是將運算的執行移到離它要處理的數據更近的地方，而不是移動數據

數據複製

HDFS被設計爲用於在大型集羣中的服務器之間可靠地存儲很是大的文件。它把每個文件存儲爲序列的塊，這些序列塊會被複制用於容錯，每一個文件的塊大小和複製因子是能夠配置的。同一文件中除了最後一個塊以外，其它塊的大小都是相同的，而在DistributedFileSystem.append和HdfsDataOutputStream.hsync方法支持參數flag後，用戶能夠隨時新建一個塊而不是默認地往最後一個塊添加數據直到配置的塊大小上限爲止。

應用程序能夠指定文件的副本數，複製因子能夠在建立文件的時候指定，也能夠在建立以後修改。HDFS中的文件是一次寫入的（除了追加和截斷以外），而且在任什麼時候候都只有一個寫操做。NameNode負責塊複製的全部決策，它週期地接收集羣中每一個DataNode的心跳和塊報告Blockreport，收到心跳意味着DataNode是正常工做的。一份Blockreport包含該DataNode全部塊的列表。
副本存放位置

副本的存放位置是會嚴重影響HDFS的可靠性和性能，它的優化是HDFS區分於其餘分佈式文件系統的的特色。HDFS使用機架感知rack-aware副本放置策略，它的意圖是提升數據可靠性，可用性和網絡帶寬的利用率。目前的副本放置策略的實現是朝着這個方向努力的第一步，實現這一策略的短時間目標是在生產系統上進行驗證，更多地瞭解其行爲，併爲對更復雜的策略進行測試和研究奠基基礎。

大型HDFS實例一般運行在跨多個機架上的服務器集羣。不一樣機架上的兩個節點是經過交換機實現通信的，在大多數狀況下，在同一機架上的服務器網絡帶寬要優於在不一樣機架上的服務器網絡帶寬。

NameNode經過Hadoop機架感知肯定每一個DataNode所屬的機架ID。一個簡單但不是最優的策略是將副本放在不一樣的機架上，這樣能夠防止當整個機架發生故障時丟失數據，而且在讀取數據時可使用不一樣機架的帶寬。該策略把副本均勻地分佈到集羣中，使得在組件故障的時候可以容易地實現負載均衡。可是，這種策略會對寫性能形成負影響，由於寫的時候須要把數據塊傳輸到多個不一樣的機架。

通常狀況下，當副本數設置爲3時，HDFS的副本放置策略是將一個副本放在本地節點，第二個副本放在同一機架的不一樣節點，第三個副本放在不一樣機架上。該策略減小機架間的寫流量，提升了寫性能。機架故障的概率遠遠低於節點的故障，該策略不會影響數據的可靠性和可用性保證。然而，當讀數據的時候會減小網絡帶寬的使用，由於數據塊僅存在兩個不一樣的機架，而不是三個。文件的副本不是均勻地分佈在不一樣的機架上，三分之一的副本在同一個節點，三分之二的副本在同一個機架，另外三分之一均勻地分佈在其他的機架上。這種策略提升了寫性能，並且不會影響數據的可靠性和讀性能。
目前，這裏描述的默認副本放置策略還處於開發之中。

副本選擇

爲了儘可能減少全局帶寬的消耗和讀延時，HDFS會嘗試從離請求最近的副本讀取數據。若是在同一個機架有請求數據的副本，就直接讀取，若是HDFS集羣是部署在多個數據中心，那麼會優先讀取本地數據中心的副本，而不是遠程的副本。
安全模式

在HDFS啓動的時候，NameNode會進入一個叫安全模式Safemode的特別狀態，在此模式下，數據塊還不會被複制。NameNode接收來自DataNodes的心跳和Blockreport信息，一份Blockreport包含該DataNode全部塊的列表。每個塊有一個特定的最小複製數，當數據塊的最小複製數被NameNode檢查後，就認爲是複製成功。當達到配置的塊複製安全比例時（加上額外的30秒），NameNode就退出安全模式狀態。而後，它會檢測數據塊的列表，把少於指定數量副本的數據塊複製到其它的DataNodes。

HDFS這一部分主要有如下幾個部分組成：

Client：客戶端，系統使用者。

       一、文件切分。文件上傳 HDFS 的時候，Client 將文件切分紅 一個一個的Block，而後進行存儲。

       二、與 NameNode 交互，獲取文件的位置信息。

       三、與 DataNode 交互，讀取或者寫入數據。

       四、Client 提供一些命令來管理 HDFS，好比啓動或者關閉HDFS。

       五、Client 能夠經過一些命令來訪問 HDFS。

NameNode：就是 master，它是一個主管、管理者。

       一、管理 HDFS 的名稱空間。

       二、管理數據塊（Block）映射信息

       三、配置副本策略

       四、處理客戶端讀寫請求。

DataNode：就是Slave。NameNode 下達命令，DataNode 執行實際的操做。

       一、存儲實際的數據塊。

       二、執行數據塊的讀/寫操做。

       三、按期向NameNode發送心跳信息，彙報自己及其全部的block信息，健康狀況。

Secondary NameNode：並不是 NameNode 的熱備。當NameNode 掛掉的時候，它並不能立刻替換 NameNode 並提供服務。注意：在hadoop 2.x 版本，當啓用 hdfs ha 時，將沒有這一角色

       一、輔助 NameNode，分擔其工做量。

       二、按期合併 fsimage和fsedits，並推送給NameNode。

       三、在緊急狀況下，可輔助恢復 NameNode。

熱備份：b是a的熱備份，若是a壞掉。那麼b當即運行代替a的工做

冷備份：b是a的冷備份，若是a壞掉。那麼b不能當即代替a工做。可是b上存儲a的一些信息，減小a壞掉以後的損失
HDFS存儲原理

下面以圖解的方式講述HDFS文件讀寫流程（兩種方式體現）：
數據寫入過程

客戶端：發送讀寫請求；

Namenode：把控全部請求

Datenede：數據存儲

一個客戶端建立一個文件的請求是不會當即發送到NameNode的，事實上在開始時，HDFS客戶端會先把數據緩存到本地的一個緩衝區。應用程序會把數據庫重定向寫入到此緩衝區，當緩衝區累積的數據（當客戶端向HDFS中寫入數據的時候，首先會讀取Hadoop的配置項，獲取數據塊的大小（大文件會被分割成多個Block進行存儲，通常爲64或128MB）以及備份數（每一個Block會在多個Datanode上存儲多份副本，通常爲3份），以後將數據寫到本地臨時文件（緩存）中）超過配置的一個數據塊大小時，客戶端纔會鏈接NameNode。

找空閒，均衡

NameNode將文件名插入到文件系統層次結構中併爲其分配存儲空間，接着向客戶端返回DataNode的標識和數據塊的路徑。而後客戶端將數據塊從本地緩衝區傳輸到指定的DataNode。

以流水線的方式寫完，

客戶端會從Namenode獲取一個Datanode列表用於存放數據塊（Datanaode列表列出了存儲數據塊的地址，並根據距離對他們進行了排序）。而後客戶端開始向第一個Datanode傳輸數據，第一個 Datanode 一小部分一小部分地接收數據，將每一部分寫入本地倉庫，並同時傳輸該部分到列表中 第二個 Datanode 節點。第二個 Datanode 也是這樣，一小部分一小部分地接收數據，寫入本地 倉庫，並同時傳給第三個 Datanode 。最後，第三個 Datanode 接收數據並存儲在本地。當完成該數據塊的存儲後，Datanode會向Namenode報告數據傳輸完成，Namenode通知客戶端該數據塊已成功存儲並複製在HDFS中，客戶端繼續重複發送下個數據塊，直至全部數據塊傳送完成。

這時客戶端向Namenode報告全部數據塊都已寫入，請求關閉文件。Namenode關閉文件，數據寫入完畢。

當關閉一個文件時，本地緩衝區剩餘的未傳輸的數據會傳輸到DataNode中，客戶端而後會告訴NameNode文件已經關閉。此時，NameNode會將文件建立操做提交到持久化存儲。若是NameNode在文件關閉以前宕機，文件將會丟失。
讀取數據

客戶端發送請求：元數據信息：幾個block，存放位置，編號，幾個副本

客戶端從HDFS中讀取文件，首先向Namenode請求要讀取文件的信息，Namenode遞給客戶端數據塊列表，客戶端知道了有多少個數據塊須要下載，也清楚了儲存每一個數據塊的Datanode位置，就會逐個下載全部數據塊（在寫數據過程當中，數據存儲已經按照客戶端與DataNode節點之間的距離進行了排序，距客戶端越近的DataNode節點被放在最前面，客戶端會優先從本地讀取該數據塊）

HDFS的文件寫入原理，主要包括如下幾個步驟：

1，客戶端經過調用DistributedFileSystem的create()方法建立新文件；

2，DistributedFileSystem經過RPC調用NameNode去建立一個沒有Blocks關聯的新文件，建立前NameNode會作各類校驗，好比文件是否存在、客戶端有無權限去建立等。若是校驗經過，NameNode會爲建立新文件記錄一條記錄，不然就會拋出IO異常；

前兩步結束後會返回FSDataOutputStream的對象，和讀文件的時候類似，

3，FSDataOutputStream被封裝成DFSOutputStream，DFSOutputStream能夠協調NameNode和Datanode。客戶端開始寫數據到DFSOutputStream，DFSOutputStream會把數據切成一個個小的數據包，並寫入內部隊列稱爲「數據隊列」(Data Queue)；

4，DataStreamer會去處理接受Data Queue，它先問詢NameNode這個新的Block最適合存儲的在哪幾個DataNode裏，好比重複數是3，那麼就找到3個最適合的DataNode，把他們排成一個pipeline.DataStreamer把Packet按隊列輸出到管道的第一個Datanode中，第一個DataNode又把Packet輸出到第二個DataNode中，以此類推；

5，DFSOutputStream還有一個對列叫Ack Quene，也是有Packet組成，等待DataNode的收到響應，當Pipeline中的全部DataNode都表示已經收到的時候，這時Akc Quene纔會把對應的Packet包移除掉；

6，客戶端完成寫數據後調用close()方法關閉寫入流；

7，DataStreamer把剩餘的包都刷到Pipeline裏而後等待Ack信息，收到最後一個Ack後，通知NameNode把文件標示爲已完成。

HDFS的文件讀取原理，主要包括如下幾個步驟：

1，客戶端經過調用FileSystem對象的open()方法來打開但願讀取的文件，對於HDFS來講，這個對象是分佈文件系統的一個實例；

2，DistributedFileSystem經過使用RPC（遠程過程調用）來調用NameNode以肯定文件起始塊的位置，同一Block按照重複數會返回多個位置，這些位置按照Hadoop集羣拓撲結構排序，距離客戶端近的排在前面；

3，前兩步會返回一個FSDataInputStream對象，該對象會被封裝成DFSInputStream對象，DFSInputStream能夠方便的管理datanode和namenode數據流，客戶端對這個輸入流調用read()方法；

4， 存儲着文件起始塊的DataNode地址的DFSInputStream隨即鏈接距離最近的DataNode，經過對數據流反覆調用read()方法，能夠將數據從DataNode傳輸到客戶端；

5，到達塊的末端時，DFSInputStream會關閉與該DataNode的鏈接，而後尋找下一個塊的最佳DataNode，這些操做對客戶端來講是透明的，客戶端的角度看來只是讀一個持續不斷的流；

6，一旦客戶端完成讀取，就對FSDataInputStream調用close()方法關閉文件讀取。
文件系統元數據的持久化

HDFS的命名空間是由命名節點NameNode來存儲的。NameNode使用了一個叫EditLog的事務日誌來持續記錄文件系統元數據的每一次更改，例如在HDFS建立一個新的文件，NameNode會在EditLog裏面插入一條這樣的記錄。相似地，修改文件的複製因子也會在EditLog裏面插入一條記錄。NameNode使用本地服務器操做文件系統中的文件來存儲EditLog。整個文件系統的命名空間，包括數據塊的映射和文件系統的屬性配置，都保存在一個叫FsImage的文件裏，這個FsImage文件也是保存在NameNode的本地文件系統裏。

NameNode將整個文件系統的命名空間和文件Blockmap的鏡像保存在內存中。關鍵的元數據被設計成緊湊存儲的，這使得一個有4GB內存的NameNode足以支持處理大量的文件和目錄。當NameNode啓動時，它從磁盤讀取FsImage和EditLog文件，將EditLog的全部事務應用於FsImage的內存中，而後將這個新版本的FsImage刷新到磁盤中。由於事務已經被持久化到FsImage中，因此能夠截去舊的EditLog，這個過程叫作檢查點checkpoint。在當前實現中，checkpoint僅在NameNode啓動時發生，而週期性的checkpoint功能正在實現中。

DataNode將HDFS的數據以文件形式存儲到本地的文件系統中，而它在存儲文件的時候又會將數據分紅多個數據塊分別存儲在不一樣的文件中。DataNode不會將全部的數據塊文件都存放到同一個目錄中，而是它使用啓發式方法來肯定每一個目錄的最佳文件數，並適當地建立子目錄。在本地同一個目錄下建立全部的數據塊文件不是最優的，由於本地文件系統可能沒法在單個目錄中有效地支持大量文件。當DataNode啓動的時候，它將掃描它的本地文件系統，生成與這些本地文件相對應的全部數據塊的列表，並將此列表發給NameNode，這個列表被稱爲Blockreport。
 通訊協議

全部HDFS的通訊協議都是構建在TCP/IP協議之上。一個客戶端和NameNode的一個可配置的TCP端口創建鏈接使用的是客戶端協議Client Protocol，DataNodes和NameNode通信使用的是數據節點協議DataNode Protocol，遠程程序調用(RPC)抽象封裝了Client Protocol和DataNode Protocol。按照設計，NameNode從不發起任何RPC。相反，它只會響應DataNodes或客戶端發出的RPC請求。
穩健性

HDFS設計的主要目標是即便出現故障的狀況下也可以可靠地存儲數據。三種常見的故障類型是NameNode故障，DataNode故障和網絡分裂。

 數據磁盤故障，心跳和從新複製數據

每個DataNode會週期性地向NameNode發送一個心跳包。網絡分裂出現時可能會形成部分DataNodes和NameNode斷開鏈接，NameNode會根據丟失心跳包檢測到此類狀況。NameNode會標記那些丟失心跳包的DataNodes爲dead狀態，而且不會再向其轉發任何新的IO請求，而它們存儲的數據將再也不可用。DataNode被標記爲dead可能會致使某些數據塊的複製因子低於其指定值。NameNode會不斷地跟蹤哪些數據塊須要複製，並在必要時啓動數據複製。從新複製數據的必要性有不少，例如：DataNode故障，副本損壞，DataNode所在的磁盤損壞，或者文件的複製因子增長。
爲了不因爲DataNodes狀態擺動引發的數據頻繁複制，標記DataNodes爲dead狀態的超時時間默認被設爲保守的10分鐘以上，計算公式爲：
2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval = 2 * 300000(ms) + 10 * 3(s) = 10.5 minutes

集羣數據從新均衡

HDFS的架構是與數據從新均衡方案兼容的。例如，若是一個DataNode的可用空間低於某個閥值，數據會自動從一個DataNode移動到另一個DataNode；若是對某些文件的訪問量忽然劇增，數據會被額外地複製和集羣的其它數據會被從新均衡。這些類型的數據從新均衡方案還沒有實現。

數據完整性

從DataNode讀取的數據塊有可能會損壞，這能夠是因爲存儲設備故障、網絡故障、或者有bugs的代碼而致使的。HDFS的客戶端軟件實現了checksum方法對文件內容進行校驗，當客戶端建立一個HDFS文件時，它會計算文件的每一個數據塊的校驗和，並將這些校驗和存儲在同一命名空間中的獨立隱藏文件中。當客戶端讀取文件時，它會驗證從DataNode讀取的數據與對應的校驗和文件是否匹配。若是不匹配，則客戶端會選擇從另一個有該數據副本的DataNode讀取數據。

元數據磁盤故障

FsImage和EditLog是HDFS的核心數據結構，這些文件的損壞能夠致使HDFS不能正常工做。所以，NameNode能夠配置支持維護多個FsImage和EditLog的副本。對FsImage或EditLog的任何更新都會觸發FsImage和EditLog副本的同步更新。多個FsImage和EditLog的副本同步更新會下降NameNode能夠支持處理的每秒事務效率。然而，這些影響是能夠接受的，由於儘管HDFS應用是數據密集型的，但它們不是元數據密集型的。當NameNode從新啓動時，它會選擇最近一致的FsImage和Editlog文件來使用。

 快照

快照支持保存在特定時刻的數據，此功能的一個用法是將損壞的HDFS實例回滾到以前的一個好的時間點。
如何數據訪問

應用程序能夠有不少方法訪問HDFS，HDFS自帶提供了一個FileSystem的Java API供應用程序使用，用C語言封裝此Java API的接口和REST API也可用。另外，HTTP瀏覽器也能夠用來瀏覽HDFS實例的文件。經過使用NFS網關，HDFS能夠被加載到客戶端的本地文件系統。（NFS（Network File System）即網絡文件系統，是FreeBSD支持的文件系統中的一種，它容許網絡中的計算機之間經過TCP/IP網絡共享資源。在NFS的應用中，本地NFS的客戶端應用能夠透明地讀寫位於遠端NFS服務器上的文件，就像訪問本地文件同樣。）

FS Shell

HDFS容許以文件和目錄的形式組織管理用戶數據，它提供了一個稱爲FS shell的命令行接口讓用戶與HDFS中的數據進行交互。該命令集的語法相似於用戶已經熟悉的其它shell(例如bach、csh)。下面是一些例子：

    在根目錄/下面建立一個foodir的子目錄：  bin/hadoop fs -mkdir /foodir
    刪除根目錄/下面的foodir子目錄：            bin/hadoop fs -rm -R /foodir
    查看文件/foodir/myfile.txt的內容：             bin/hadoop fs -cat /foodir/myfile.txt

FS shell是針對須要使用腳本語言與存儲數據進行交互的應用程序設計的。

DFSAdmin
DFSAdmin命令集是用於管理HDFS集羣，這些命令是僅供HDFS管理員使用。下面是一些例子：

    使集羣進入安全模式：  bin/hdfs dfsadmin -safemode enter
    生成DataNodes列表： bin/hdfs dfsadmin -report
    刷新DataNode(s)：   bin/hdfs dfsadmin -refreshNodes

瀏覽器接口
典型的HDFS安裝配置了Web服務器用於經過可配置的TCP端口訪問HDFS的namespace，這容許用戶經過Web瀏覽器訪問HDFS的namespace和查看其文件的內容。
空間回收

若是回收站被啓用，經過FS Shell刪除的文件不會被當即刪除，而是先移到一個垃圾目錄(每一個用戶在/user/<username>/.Trash下都有本身的垃圾文件目錄)，只要文件還保留在回收站就能夠被快速的恢復。
最近被刪除的文件會被移到/user/<username>/.Trash/Current目錄，在配置的間隔內，HDFS會在/user/<username>/.Trash/<date>建立文件的checkpoints目錄，把Current目錄下面的文件都移到該checkpoints目錄裏面，並刪除過時的checkpoints目錄。詳細請參考FS shell的expunge命令。
在回收站的文件過時後，NameNode會從HDFS的namespace刪除該文件，關聯的數據塊空間會被釋放。注意，在用戶執行刪除文件後和HDFS真正釋放空間會有一點延時。

下面是如何使用FS Shell刪除文件的一個例子：

    在delete目錄下面建立2個目錄test1和test2

    $ hadoop fs -mkdir -p delete/test1
    $ hadoop fs -mkdir -p delete/test2
    $ hadoop fs -ls delete/
    Found 2 items
    drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:39 delete/test1
    drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:40 delete/test2

    刪除test1，執行後會提示test1移動到用戶的.Trash/Current目錄

    $ hadoop fs -rm -r delete/test1
    Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current

    使用skipTrash參數直接刪除test2

    $ hadoop fs -rm -r -skipTrash delete/test2
    Deleted delete/test2

    查看回收站，只有test1，而沒有test2

    $ hadoop fs -ls .Trash/Current/user/hadoop/delete/
    Found 1 items
    drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1

減少複製因子
當減少文件複製因子時，NameNode會選擇能夠刪除的多餘副本。在下一個Heartbeat把此信息傳輸給DataNode，此DataNode而後刪除相應的數據塊並釋放空間。須要再次注意的是，調用setReplication API後和釋放空間會有一點延時。
2，YARN資源調度框架：
YARN產生背景

MapReduce1.x時所存在的問題：單點故障&節點壓力大&不易擴展

能夠看到，1.x時也是Master/Slave這種主從結構，在集羣上的表現就是一個JobTracker帶多個TaskTracker。

JobTracker：

JobTracker是一個後臺服務進程，啓動以後，會一直監聽並接收來自各個TaskTracker發送的心跳信息，包括資源使用狀況和任務運行狀況等信息。

負責資源管理和做業調度

    做業控制：在hadoop中每一個應用程序被表示成一個做業，每一個做業又被分紅多個任務，JobTracker的做業控制模塊則負責做業的分解和狀態監控。
    狀態監控：主要包括TaskTracker狀態監控、做業狀態監控和任務狀態監控。主要做用：容錯和爲任務調度提供決策依據。
    JobTracker只有一個，他負責了任務的信息採集整理，你就把它當作包工頭，把這個和採用Master/Slave結構中的Master保持一致
    JobTracker 對應於 NameNode
    通常狀況應該把JobTracker部署在單獨的機器上

TaskTracker：1，按期向JobTracker彙報本節點的健康情況、資源使用狀況以及做業執行狀況。

                         2， 接收來自JobTracker的命令，例如啓動任務或結束任務等。

MapTask

    本身開發的map任務交由該Task處理
    解析每條記錄的數據，交給本身的map方法處理；
    將map的輸出結果寫到本地磁盤（有些做業只有map沒有reduce==》HDFS）

ReduceTask

    將MapTask輸出數據進行讀取；
    按照數據進行分組傳給咱們本身編寫的reduce方法處理；
    輸出結果寫到HDFS。

那麼這種架構存在哪些問題呢：

    整個集羣中只有一個JobTracker，就表明着會存在單點故障的狀況
    JobTracker節點的壓力很大，不只要接收來自客戶端的請求，還要接收大量TaskTracker節點的請求
    因爲JobTracker是單節點，因此容易成爲集羣中的瓶頸，並且也不易域擴展
    JobTracker承載的職責過多，基本整個集羣中的事情都是JobTracker來管理
    1.x版本的整個集羣只支持MapReduce做業，其餘例如Spark的做業就不支持了

各個資源不能共享
YARN架構：

YARN：不一樣計算框架能夠共享同一個HDFS集羣上的數據，享受總體的資源調度

YARN的基本思想是將資源管理和做業調度/監控的功能分解爲單獨的守護進程（守護進程(daemon)是一類在後臺運行的特殊進程，用於執行特定的系統任務。不少守護進程在系統引導的時候啓動，而且一直運行直到系統關閉。另外一些只在須要的時候才啓動，完成任務後就自動結束。）。 這個想法是有一個全局的ResourceManager（RM）和每一個應用程序的ApplicationMaster（AM）。 應用程序能夠是單個做業，也能夠是DAG做業。

1. ResourceManager， 簡稱RM，ResourceManager是仲裁系統中全部應用程序之間資源的最終權威機構。（大管理員）

    整個集羣同一時間提供服務的RM只有一個，它負責集羣資源的統一管理和調度。
    處理客戶端的請求，例如：提交做業或結束做業等。
    監控集羣中的NM，一旦某個NM掛了，那麼就須要將該NM上運行的任務告訴AM來如何進行處理。

ResourceManager主要有兩個組件：Scheduler和ApplicationManager。

Scheduler是一個資源調度器，它主要負責協調集羣中各個應用的資源分配，保障整個集羣的運行效率。Scheduler的角色是一個純調度器，它只負責調度Containers，不會關心應用程序監控及其運行狀態等信息。一樣，它也不能重啓因應用失敗或者硬件錯誤而運行失敗的任務。Scheduler是一個可插拔的插件，它能夠調度集羣中的各類隊列、應用等。在Hadoop的MapReduce框架中主要有兩種Scheduler：Capacity Scheduler和Fair Scheduler。

參考:https://blog.csdn.net/suifeng3051/article/details/49508261

另外一個組件ApplicationManager主要負責接收job的提交請求，爲應用分配第一個Container來運行ApplicationMaster，還有就是負責監控ApplicationMaster，在遇到失敗時重啓ApplicationMaster運行的Container。

2. NodeManager， 簡稱NM，（執行者，小員工）

    整個集羣中會有多個NM，它主要負責本身自己節點的資源管理和使用，
    定時向RM彙報本節點的資源使用狀況。
    接收並處理來自RM的各類命令，例如：啓動Container。
    NM還須要處理來自AM的命令，例如：AM會告訴NM須要啓動多少個Container來跑task。
    單個節點的資源管理

NodeManager進程運行在集羣中的節點上，每一個節點都會有本身的NodeManager。NodeManager是一個slave服務：它負責接收ResourceManager的資源分配請求，分配具體的Container給應用。同時，它還負責監控並報告Container使用信息給ResourceManager。經過和ResourceManager配合，NodeManager負責整個Hadoop集羣中的資源分配工做。ResourceManager是一個全局的進程，而NodeManager只是每一個節點上的進程，管理這個節點上的資源分配和監控運行節點的健康狀態。下面是NodeManager的具體任務列表：

接收ResourceManager的請求，分配Container給應用的某個任務
和ResourceManager交換信息以確保整個集羣平穩運行。ResourceManager就是經過收集每一個NodeManager的報告信息來追蹤整個集羣健康狀態的，而NodeManager負責監控自身的健康狀態。

管理每一個Container的生命週期
管理每一個節點上的日誌
執行Yarn上面應用的一些額外的服務，好比MapReduce的shuffle過程

當一個節點啓動時，它會向ResourceManager進行註冊並告知ResourceManager本身有多少資源可用。在運行期，經過NodeManager和ResourceManager協同工做，這些信息會不斷被更新並保障整個集羣發揮出最佳狀態。

NodeManager只負責管理自身的Container，它並不知道運行在它上面應用的信息。負責管理應用信息的組件是ApplicationMaster。

3. ApplicationMaster， 簡稱AM，應用級別（小管理員）

    每一個應用程序都對應着一個AM。例如：MapReduce會對應一個、Spark會對應一個。它主要負責應用程序的管理，
    爲應用程序向RM申請資源（Core、Memory），將資源分配給內部的task。
    AM須要與NM通訊，以此來啓動或中止task。遇到失敗的任務還負責重啓它。

4. Container，

    封裝了CPU、Memory等資源的一個容器
    是一個任務運行環境的抽象。

Container是Yarn框架的計算單元，是具體執行應用task（如map task、reduce task）的基本單位。Container和集羣節點的關係是：一個節點會運行多個Container，但一個Container不會跨節點。

一個Container就是一組分配的系統資源，現階段只包含兩種系統資源（以後可能會增長磁盤、網絡等資源）：

    1. CPU core
    2. Memory in MB

既然一個Container指的是具體節點上的計算資源，這就意味着Container中一定含有計算資源的位置信息：計算資源位於哪一個機架的哪臺機器上。因此咱們在請求某個Container時，實際上是向某臺機器發起的請求，請求的是這臺機器上的CPU和內存資源。

任何一個job或application必須運行在一個或多個Container中，在Yarn框架中，ResourceManager只負責告訴ApplicationMaster哪些Containers能夠用，ApplicationMaster還須要去找NodeManager請求分配具體的Container。

5. Client， 客戶端，

    提交做業
    查詢做業的運行進度
    結束做業。

小結：

在MR1中，JobTracker即負責job的監控，又負責系統資源的分配。

    在MR2中，資源的調度分配由ResourceManager專門進行管理，
    每一個job或應用的管理、監控交由相應的分佈在集羣中的ApplicationMaster，若是某個ApplicationMaster失敗，ResourceManager還能夠重啓它，這大大提升了集羣的拓展性。

在MR1中，Hadoop架構只支持MapReduce類型的job，因此它不是一個通用的框架，由於Hadoop的JobTracker和TaskTracker組件都是專門針對MapReduce開發的，它們之間是深度耦合的。

    Yarn的出現解決了這個問題，關於Job或應用的管理都是由ApplicationMaster進程負責的，Yarn容許咱們本身開發ApplicationMaster，咱們能夠爲本身的應用開發本身的ApplicationMaster。這樣每個類型的應用都會對應一個ApplicationMaster，一個ApplicationMaster其實就是一個類庫。這裏要區分ApplicationMaster*類庫和ApplicationMaster實例*，一個ApplicationMaster類庫能夠對應多個實例，就行java語言中的類和類的實例關係同樣。總結來講就是，每種類型的應用都會對應着一個ApplicationMaster，每一個類型的應用均可以啓動多個ApplicationMaster實例。因此，在yarn中，是每一個job都會對應一個ApplicationMaster而不是每類。

Resource Request和Container

Yarn的設計目標就是容許咱們的各類應用以共享、安全、多租戶的形式使用整個集羣。而且，爲了保證集羣資源調度和數據訪問的高效性，Yarn還必須可以感知整個集羣拓撲結構。爲了實現這些目標，ResourceManager的調度器Scheduler爲應用程序的資源請求定義了一些靈活的協議，經過它就能夠對運行在集羣中的各個應用作更好的調度，所以，這就誕生了Resource Request和Container。

具體來說，一個應用先向ApplicationMaster發送一個知足本身需求的資源請求，而後ApplicationMaster把這個資源請求以resource-request的形式發送給ResourceManager的Scheduler，Scheduler再在這個原始的resource-request中返回分配到的資源描述Container。每一個ResourceRequest可看作一個可序列化Java對象，包含的字段信息以下：

    <resource-name, priority, resource-requirement, number-of-containers>
    <!--
    •resource-name：資源名稱，現階段指的是資源所在的host和rack，後期可能還會支持虛擬機或者更復雜的網絡結構
    •priority：資源的優先級
    •resource-requirement：資源的具體需求，現階段指內存和cpu需求的數量
    •number-of-containers：知足需求的Container的集合
    -->

number-of-containers中的Containers就是ResourceManager給ApplicationMaster分配資源的結果。Container就是受權給應用程序可使用某個節點機器上CPU和內存的數量。

ApplicationMaster在獲得這些Containers後，還須要與分配Container所在機器上的NodeManager交互來啓動Container並運行相關任務。固然Container的分配是須要認證的，以防止ApplicationMaster本身去請求集羣資源。
YARN執行流程：

一個做業提交上來後，先到ResourceManager，而後ResourceManager到任意一個結點上去請求一個ApplicationMaster，而後ApplicationMaster去爲做業向ResourceManager申請資源，申請資源後通知對應的NodeManager，而後NodeManager啓動container運行。

詳細流程：

    客戶端程序向ResourceManager提交應用並請求一個ApplicationMaster實例

    ResourceManager找到能夠運行一個Container的NodeManager，並在這個Container中啓動ApplicationMaster實例

    ApplicationMaster向ResourceManager進行註冊，註冊以後客戶端就能夠查詢ResourceManager得到本身ApplicationMaster的詳細信息，之後就能夠和本身的ApplicationMaster直接交互了

    在日常的操做過程當中，ApplicationMaster根據resource-request協議向ResourceManager發送resource-request請求

    當Container被成功分配以後，ApplicationMaster經過向NodeManager發送container-launch-specification信息來啓動Container， container-launch-specification信息包含了可以讓Container和ApplicationMaster交流所須要的資料

    應用程序的代碼在啓動的Container中運行，並把運行的進度、狀態等信息經過application-specific協議發送給ApplicationMaster

    在應用程序運行期間，提交應用的客戶端主動和ApplicationMaster交流得到應用的運行狀態、進度更新等信息，交流的協議也是application-specific協議

    一但應用程序執行完成而且全部相關工做也已經完成，ApplicationMaster向ResourceManager取消註冊而後關閉，用到全部的Container也歸還給系統。

Yarn 內存分配管理機制及相關參數配置

參考：https://blog.csdn.net/suifeng3051/article/details/48135521
3，MapReduce：分佈式處理框架

優勢：海量數據離線處理&易開發&易運行

缺點：不知足實時流式計算。它是離線處理，輸入級都是固定的，是靜態的，動態沒辦法識別：

多個應用程序存在依賴關係，dag不擅長處理。

橫向擴展結點，spark：易開發，易運行。

Hadoop核心之MapReduce是一個軟件框架，基於該框架可以容易地編寫應用程序，這些應用程序可以運行在由上千個商用機器組成的大集羣上，並以一種可靠的，具備容錯能力的方式並行地處理上TB級別的海量數據集。這個定義裏面有着這些關鍵詞，一是軟件框架，二是並行處理，三是可靠且容錯，四是大規模集羣，五是海量數據集。所以，對於MapReduce，能夠簡潔地認爲，它是一個軟件框架，海量數據是它的「菜」，它在大規模集羣上以一種可靠且容錯的方式並行地「烹飪這道菜」。

MapReduce擅長處理大數據，它爲何具備這種能力呢？這可由MapReduce的設計思想發覺。MapReduce的思想就是「分而治之」。Mapper負責「分」，即把複雜的任務分解爲若干個「簡單的任務」來處理。「簡單的任務」包含三層含義：一是數據或計算的規模相對原任務要大大縮小；二是就近計算原則，即任務會分配到存放着所需數據的節點上進行計算；三是這些小任務能夠並行計算，彼此間幾乎沒有依賴關係。Reducer負責對map階段的結果進行彙總。至於須要多少個Reducer，用戶能夠根據具體問題，經過在mapred-site.xml配置文件裏設置參數mapred.reduce.tasks的值，缺省值爲1。
經過wordcount詞頻統計分析工做流程：

將做業拆分紅Map階段和Reduce階段

Map階段：Map Tasks

Reduce階段：Reduce Tasks
MapReduce做業的輸入和輸出類型：

（輸入）<k1，v1> - > map - > <k2，v2> - > combine - > <k2，v2> - > reduce - > <k3，v3>（輸出）

接下來是總說，下面舉例細說
map task

程序會根據InputFormat將輸入文件分割成splits，每一個split會做爲一個map task的輸入，每一個map task會有一個內存緩衝區,輸入數據通過map階段處理後的中間結果會寫入內存緩衝區，而且決定數據寫入到哪一個partitioner，當寫入的數據到達內存緩衝區的的閥值(默認是0.8)，會啓動一個線程將內存中的數據溢寫入磁盤，同時不影響map中間結果繼續寫入緩衝區。在溢寫過程當中，MapReduce框架會對key進行排序，若是中間結果比較大，會造成多個溢寫文件，最後的緩衝區數據也會所有溢寫入磁盤造成一個溢寫文件(最少有一個溢寫文件)，若是是多個溢寫文件，則最後合併全部的溢寫文件爲一個文件。

split被送入map task後，程序庫決定數據結果數據屬於哪一個partitioner，寫入到內存緩衝區，到達閥值，開啓溢寫過程，進行key排序，若是有combiner步驟，則會對相同的key作歸併處理，最終多個溢寫文件合併爲一個文件。

MapReduce提供Partitioner接口，它的做用就是根據key或value及reduce的數量來決定當前的這對輸出數據最終應該交由哪一個reduce task處理。默認對key hash後再以reduce task數量取模。默認的取模方式只是爲了平均reduce的處理能力，若是用戶本身對Partitioner有需求，能夠訂製並設置到job上。

多個map task造成的最終文件的對應partitioner會被對應的reduce task拉取至內存緩衝區，對可能造成多個溢寫文件合併，最終做爲resuce task的數據輸入 。
reduce task

當全部的map task完成後，每一個map task會造成一個最終文件，而且該文件按區劃分。reduce任務啓動以前，一個map task完成後，就會啓動線程來拉取map結果數據到相應的reduce task，不斷地合併數據，爲reduce的數據輸入作準備，當全部的map tesk完成後，數據也拉取合併完畢後，reduce task 啓動，最終將輸出輸出結果存入HDFS上。
Map、Reduce任務中Shuffle和排序的過程

Shuffle的過程：描述數據從map task輸出到reduce task輸入的這段過程。

 Shuffle的正常意思是洗牌或弄亂，可能你們更熟悉的是Java API裏的Collections.shuffle(List)方法，它會隨機地打亂參數list裏的元素順序。

參考：http://langyu.iteye.com/blog/992916

           http://weixiaolu.iteye.com/blog/1474172
Map端：

1，在map task執行時，它的輸入數據來源於HDFS的block，固然在MapReduce概念中，map task只讀取split。Split與block的對應關係多是多對一，默認是一對一。在WordCount例子裏，假設map的輸入數據都是像「aaa」這樣的字符串。

2， 在通過mapper的運行後，咱們得知mapper的輸出是這樣一個key/value對： key是「aaa」， value是數值1。在咱們的例子中，「aaa」通過Partitioner後返回0，也就是這對值應當交由第一個reducer來處理。接下來，須要將數據寫入內存緩衝區中，緩衝區的做用是批量收集map結果，減小磁盤IO的影響。咱們的key/value對以及Partition的結果都會被寫入緩衝區。固然寫入以前，key與value值都會被序列化成字節數組。

3，當寫入的數據到達內存緩衝區的的閥值(默認是0.8)，會啓動一個線程將內存中的數據溢寫入磁盤，同時不影響map中間結果繼續寫入緩衝區。在溢寫過程當中，MapReduce框架會對key進行排序，

    溢寫過程一個很重要的細節在於，若是有不少個key/value對須要發送到某個reduce端去，那麼須要將這些key/value值拼接到一塊，減小與partition相關的索引記錄。 在針對每一個reduce端而合併數據時，有些數據可能像這樣：「aaa」/1， 「aaa」/1。對於WordCount例子，就是簡單地統計單詞出現的次數，若是在同一個map task的結果中有不少個像「aaa」同樣出現屢次的key，咱們就應該把它們的值合併到一塊，這個過程叫combine。

4，若是中間結果比較大，會造成多個溢寫文件，最後的緩衝區數據也會所有溢寫入磁盤造成一個溢寫文件(最少有一個溢寫文件)，若是是多個溢寫文件，則最後合併全部的溢寫文件爲一個文件。這個過程就叫作Merge。

    Merge是怎樣的？如前面的例子，「aaa」從某個map task讀取過來時值是5，從另一個map 讀取時值是8，由於它們有相同的key，因此得merge成group。什麼是group。對於「aaa」就是像這樣的：{「aaa」, [5, 8, 2, …]}，數組中的值就是從不一樣溢寫文件中讀取出來的，而後再把這些值加起來。請注意，由於merge是將多個溢寫文件合併到一個文件，因此可能也有相同的key存在，在這個過程當中若是client設置過Combiner，也會使用Combiner來合併相同的key。

map端的全部工做都已結束，最終生成的這個文件也存放在TaskTracker夠得着的某個本地目錄內。每一個reduce task不斷地經過RPC從JobTracker那裏獲取map task是否完成的信息，若是reduce task獲得通知，獲知某臺TaskTracker上的map task執行完成，Shuffle的後半段過程開始啓動。

到這裏，map端就分析完了。那到底什麼是Shuffle呢？Shuffle的中文意思是「洗牌」，若是咱們這樣看：一個map產生的數據，結果經過hash過程分區卻分配給了不一樣的reduce任務，是否是一個對數據洗牌的過程呢。
Reduce端：

1．Reduce會接收到不一樣map任務傳來的數據，而且每一個map傳來的數據都是有序的。若是reduce端接受的數據量至關小，則直接存儲在內存中（緩衝區大小由mapred.job.shuffle.input.buffer.percent屬性控制，表示用做此用途的堆空間的百分比），若是數據量超過了該緩衝區大小的必定比例（由mapred.job.shuffle.merge.percent決定），則對數據合併後溢寫到磁盤中。
2．隨着溢寫文件的增多，後臺線程會將它們合併成一個更大的有序的文件，這樣作是爲了給後面的合併節省時間。其實無論在map端仍是reduce端，MapReduce都是反覆地執行排序，合併操做，如今終於明白了有些人爲何會說：排序是hadoop的靈魂。
3．合併的過程當中會產生許多的中間文件（寫入磁盤了），但MapReduce會讓寫入磁盤的數據儘量地少，而且最後一次合併的結果並無寫入磁盤，而是直接輸入到reduce函數。
Reduce 端的Shuffle細節

1.Copy過程，簡單地拉取數據。Reduce進程啓動一些數據copy線程(Fetcher)，經過HTTP方式請求map task所在的TaskTracker獲取map task的輸出文件。由於map task早已結束，這些文件就歸TaskTracker管理在本地磁盤中。

2.Merge階段。這裏的merge如map端的merge動做，只是數組中存放的是不一樣map端copy來的數值。Copy過來的數據會先放入內存緩衝區中，這裏的緩衝區大小要比map端的更爲靈活，它基於JVM的heap size設置，由於Shuffle階段Reducer不運行，因此應該把絕大部分的內存都給Shuffle用。這裏須要強調的是，merge有三種形式：1)內存到內存  2)內存到磁盤  3)磁盤到磁盤。默認狀況下第一種形式不啓用。當內存中的數據量到達必定閾值，就啓動內存到磁盤的merge。與map 端相似，這也是溢寫的過程，這個過程當中若是你設置有Combiner，也是會啓用的，而後在磁盤中生成了衆多的溢寫文件。第二種merge方式一直在運行，直到沒有map端的數據時才結束，而後啓動第三種磁盤到磁盤的merge方式生成最終的那個文件。

3.Reducer的輸入文件。不斷地merge後，最後會生成一個「最終文件」。爲何加引號？由於這個文件可能存在於磁盤上，也可能存在於內存中。對咱們來講，固然但願它存放於內存中，直接做爲Reducer的輸入，但默認狀況下，這個文件是存放於磁盤中的。當Reducer的輸入文件已定，整個Shuffle才最終結束。而後就是Reducer執行，把結果放到HDFS上。
MapReduce編程主要組件

InputFormat類：分割成多個splits和每行怎麼解析。   

Mapper類：對輸入的每對<key,value>生成中間結果。

Combiner類：在map端，對相同的key進行合併。

Partitioner類：在shuffle過程當中，將按照key值將中間結果分爲R份，每一份都由一個reduce去完成。

Reducer類：對全部的map中間結果，進行合併。

OutputFormat類：負責輸出結果格式。

文件輸入格式InputFormat

1）定義了數據文件如何分割和讀取

2）InputFile提供瞭如下一些功能

選擇文件或者其它對象，用來做爲輸入

定義InputSplits，將一個文件分開成爲任務

爲RecordReader提供一個工廠，用來讀取這個文件

3）有一個抽象的類FileInputFormat，全部的輸入格式類都從這個類繼承這個類的功能以及特性。當啓動一個Hadoop任務的時候，一個輸入文件所在的目錄被輸入到FileInputFormat對象中。FileInputFormat從這個目錄中讀取全部文件。而後FileInputFormat將這些文件分割爲一個或者多個InputSplits。

4）經過在JobConf對象上設置JobConf.setInputFormat設置文件輸入的格式

輸入數據分塊InputSplits

1）InputSplit定義了輸入到單個Map任務的輸入數據

2）一個MapReduce程序被統稱爲一個Job，可能有上百個任務構成

3）InputSplit將文件分爲64MB的大小

配置文件hadoop-site.xml中的mapred.min.split.size參數控制這個大小

4）mapred.tasktracker.map.taks.maximum用來控制某一個節點上全部map任務的最大數目

數據記錄讀入RecordReader（RR）

1）InputSplit定義了一項工做的大小，可是沒有定義如何讀取數據

2）RecordReader實際上定義瞭如何從數據上轉化爲一個(key,value)對的詳細方法，並將數據輸出到Mapper類中

3）TextInputFormat提供了LineRecordReader

Mapper

1）每個Mapper類的實例生成了一個Java進程（在某一個InputSplit上執行）

2）有兩個額外的參數OutputCollector以及Reporter，前者用來收集中間結果，後者用來得到環境參數以及設置當前執行的狀態。

3）如今用Mapper.Context提供給每個Mapper函數，用來提供上面兩個對象的功能

Combiner

1）合併相同key的鍵值對，減小partitioner時候的數據通訊開銷

2）conf.setCombinerClass(Reduce.class)

Partitioner & Shuffle

在Map工做完成以後，每個 Map函數會將結果傳到對應的Reducer所在的節點，此時，用戶能夠提供一個Partitioner類，用來決定一個給定的(key,value)對傳輸的具體位置

Sort

傳輸到每個節點上的全部的Reduce函數接收到得Key,value對會被Hadoop自動排序（即Map生成的結果傳送到某一個節點的時候，會被自動排序）

Reducer

1）作用戶定義的Reduce操做

2）最新的編程接口是Reducer.Context

文件輸出格式OutputFormat

1）說明

寫入到HDFS的全部OutputFormat都繼承自FileOutputFormat

每個Reducer都寫一個文件到一個共同的輸出目錄，文件名是part-nnnnn，其中nnnnn是與每個reducer相關的一個號（partition id）

FileOutputFormat.setOutputPath()

JobConf.setOutputFormat()

2）接口定義

RecordWriter

TextOutputFormat實現了缺省的LineRecordWriter，以」key／value」形式輸出一行結果。
4，HIVE（數據倉庫）

解決含量結構化日誌，數據統計問題的，相似SQL語言。離線分析，SQL語句利用HIVE引擎轉化。

Hive--Hive相似於SQL高級語言，用於運行存儲在Hadoop上的查詢語句，Hive讓不熟悉MapReduce開發人員也能編寫數據查詢語句，而後這些語句被翻譯爲Hadoop上面的MapReduce任務。像Pig同樣，Hive做爲一個抽象層工具，吸引了不少熟悉SQL而不是Java編程的數據分析師。
5，RConnectors

解決統計分析的
6，Mahout：（數據挖掘算法庫）；

Mahout是一個機器學習和數據挖掘庫，它提供的MapReduce包含不少實現，包括聚類算法、迴歸測試、統計建模。經過使用 Apache Hadoop 庫，能夠將Mahout有效地擴展到雲中。
7，Pig（數據流處理）

經過腳本的方式轉成Map Reduce提交到集羣運算，離線分析；它是MapReduce編程的複雜性的抽象。Pig平臺包括運行環境和用於分析Hadoop數據集的腳本語言(Pig Latin)，其編譯器將Pig Latin翻譯成MapReduce程序序列。
8，Oozie 工做流調度引擎

Oozie是一個可擴展的工做體系，集成於Hadoop的堆棧，用於協調多個MapReduce做業的執行。它可以管理一個複雜的系統，基於外部事件來執行，外部事件包括數據的定時和數據的出現。

一層一層去審批，有必定的依賴關係，配置好，運行。
9，Zookeeper（分佈式協做服務）

分佈式的協調服務，管理框架，如解決單點故障切換問題；用於 Hadoop 的分佈式協調服務。Hadoop 的許多組件依賴於 Zookeeper，它運行在計算機集羣中，用於管理Hadoop集羣
10，Flume（日誌收集工具）

日誌收集框架，應用場景：日誌的統計分析操做。Flume提供了分佈式、可靠、高效的服務，用於收集、彙總大數據，並將單臺計算機的大量數據轉移到HDFS。它基於一個簡單而靈活的架構，並提供了數據流的流。它利用簡單的可擴展的數據模型，將企業中多臺計算機上的數據轉移到Hadoop中。
11，Sqoop（數據庫ETL工具）

與傳統數據庫（關係型數據庫）的數據傳輸與交換。Sqoop是一個鏈接工具，用於在關係數據庫、數據倉庫和Hadoop之間轉移數據。Sqoop利用數據庫技術描述架構，進行數據的導入/導出；利用MapReduce實現並行化運行和容錯技術。
12，Hbase（實時分佈式數據庫）：

鏈式的存儲，結構化數據的可伸縮可擴展高性能面向鏈的數據庫。很是大，快速查詢，秒級別查詢上億，可進行實時查詢HBase 是一個創建在 HDFS 之上，面向列的 NoSQL 數據庫，用於快速讀/寫大量數據，HBase 使用 Zookeeper 進行管理。