hadoop圖片存儲

① 基於hadoop的雲存儲實例

基於Hadoop平台的雲存儲應用實踐

http://cio.itxinwen.com/case_studies/2012/0327/402100.html

雲計算（CloudComputing）是一種基於網際網路的超級計算模式，在遠程的數據中心裡，成千上萬台電腦和伺服器連接成一片電腦雲。用戶通過電腦、筆記本、手機等方式接人數據中心，按自己的需求進行運算。目前，對於雲計算仍沒有普遍一致的定義。結合上述定義，可以總結出雲計算的一些本質特徵，即分布式計算和存儲特性、高擴展性、用戶友好性、良好的管理性。

1雲存儲架構圖

橘色的作為存儲節點（StorageNode）負責存放文件，藍色作為控制節點（（ControlNode）則是負責文件索引，並負責監控存儲節點間容量及負載的均衡，這兩個部分合起來便組成一個雲存儲。存儲節點與控制節點都是單純的伺服器，只是存儲節點的硬碟多一些，存儲節點伺服器不需要具備RAID的功能，只要能安裝Linux即可，控制節點為了保護數據，需要有簡單的RAIDlevelO1的功能。

雲存儲不是要取代現有的盤陣，而是為了應付高速成長的數據量與帶寬而產生的新形態存儲系統，因此雲存儲在設計時通常會考慮以下三點：

（1）容量、帶寬的擴容是否簡便

擴容是不能停機，會自動將新的存儲節點容量納入原來的存儲池。不需要做繁復的設定。

圖1雲存儲架構圖

（2）帶寬是否線形增長

使用雲存儲的客戶，很多是考慮未來帶寬的增長，因此雲存儲產品設計的好壞會產生很大的差異，有些十幾個節點便達到飽和，這樣對未來帶寬的擴容就有不利的影響，這一點要事先弄清楚，否則等到發現不符合需求時，已經買了幾百TB，後悔就來不及了。

（3）管理是否容易。

2雲存儲關鍵技術

雲存儲必須具備九大要素：①性能;②安全性;③自動ILM存儲;④存儲訪問模式;⑤可用性;⑥主數據保護;⑦次級數據保護;⑧存儲的靈活;⑨存儲報表。

雲計算的發展離不開虛擬化、並行計算、分布式計算等核心技術的發展成熟。下面對其介紹如下：

（1）集群技術、網格技術和分布式文件系統

雲存儲系統是一個多存儲設備、多應用、多服務協同工作的集合體，任何一個單點的存儲系統都不是雲存儲。

既然是由多個存儲設備構成的，不同存儲設備之間就需要通過集群技術、分布式文件系統和網格計算等技術，實現多個存儲設備之間的協同工作，使多個的存儲設備可以對外提供同一種服務，並提供更大更強更好的數據訪問性能。如果沒有這些技術的存在，雲存儲就不可能真正實現，所謂的雲存儲只能是一個一個的獨立系統，不能形成雲狀結構。

（2）CDN內容分發、P2P技術、數據壓縮技術、重復數據刪除技術、數據加密技術

CDN內容分發系統、數據加密技術保證雲存儲中的數據不會被未授權的用戶所訪問，同時，通過各種數據備份和容災技術保證雲存儲中的數據不會丟失，保證雲存儲自身的安全和穩定。如果雲存儲中的數據安全得不到保證，也沒有人敢用雲存儲了。

（3）存儲虛擬化技術、存儲網路化管理技術

雲存儲中的存儲設備數量龐大且分布多在不同地域，如何實現不同廠商、不同型號甚至於不同類型（例如FC存儲和IP存儲）的多台設備之間的邏輯卷管理、存儲虛擬化管理和多鏈路冗餘管理將會是一個巨大的難題，這個問題得不到解決，存儲設備就會是整個雲存儲系統的性能瓶頸，結構上也無法形成一個整體，而且還會帶來後期容量和性能擴展難等問題。

② hadoop是怎麼存儲大數據的

Hadoop中有很多方法可以加入多個數據集。MapRece提供了Map端和Rece端的數據連接。這些連接是非平凡的連接，並且可能會是非常昂貴的操作。Pig和Hive也具有同等的能力來申請連接到多個數據集。Pig提供了復制連接，合並連接和傾斜連接（skewed join），並且Hive提供了map端的連接和完整外部連接來分析數據。

一個重要的事實是，通過使用各種工具，比如MapRece、Pig和Hive等，數據可以基於它們的內置功能和實際需求來使用它們。至於在Hadoop分析大量數據，Anoop指出，通常，在大數據/Hadoop的世界，一些問題可能並不復雜，並且解決方案也是直截了當的，但面臨的挑戰是數據量。在這種情況下需要不同的解決辦法來解決問題。

一些分析任務是從日誌文件中統計明確的ID的數目、在特定的日期范圍內改造存儲的數據、以及網友排名等。所有這些任務都可以通過Hadoop中的多種工具和技術如MapRece、Hive、Pig、Giraph和Mahout等來解決。這些工具在自定義常式的幫助下可以靈活地擴展它們的能力。

③ 我要用hadoop來實現海量圖片的存儲，到底應該用raid來保證數據可靠性，還是用HDFS的冗餘機制呢

圖片這樣比較小的文件，不建議使用hadoop來做，用fastdfs之類的布置簡單，效果也比較好。raid5對於單點故障可以做到恢復，一旦多台機器同時出現問題，是沒辦法恢復的，單個圖片文件較小，一般也不能分成多塊，用raid5有點無力的感覺。當然如果你圖片經過打包司馬的，文件比較大（500MB以上），還是可以用的。

④ hadoop存儲方式

傳統化集中式存儲存在已有一段時間。但大數據並非真的適合集中式存儲架構。Hadoop設計用於將計算更接近數據節點，同時採用了HDFS文件系統的大規模橫向擴展功能。雖然，通常解決Hadoop管理自身數據低效性的方案是將Hadoop數據存儲在SAN上。但這也造成了它自身性能與規模的瓶頸。現在，如果你把所有的數據都通過集中式SAN處理器進行處理，與Hadoop的分布式和並行化特性相悖。你要麼針對不同的數據節點管理多個SAN，要麼將所有的數據節點都集中到一個SAN。但Hadoop是一個分布式應用，就應該運行在分布式存儲上，這樣存儲就保留了與Hadoop本身同樣的靈活性，不過它也要求擁抱一個軟體定義存儲方案，並在商用伺服器上運行，這相比瓶頸化的Hadoop自然更為高效。大數據培訓這么火的原因有很多。注意不要混淆超融合與分布式。某些超融合方案是分布式存儲，但通常這個術語意味著你的應用和存儲都保存在同一計算節點上。這是在試圖解決數據本地化的問題，但它會造成太多資源爭用。這個Hadoop應用和存儲平台會爭用相同的內存和CPU。Hadoop運行在專有應用層，分布式存儲運行在專有存儲層這樣會更好。之後，利用緩存和分層來解決數據本地化並補償網路性能損失。

⑤ 在中國有誰在用Hadoop

國內，有網路（集群的規模已經是千台了吧）、淘寶（有自己的文件處理系統TFS），中國移動、搜狗、華為（是社區排名靠前的貢獻者）等企業； hadoop的應用場景，給你美國著名科技博客GigaOM的專欄作家Derrick Harris的文章吧，他一直跟蹤雲計算和Hadoop技術，在最近的一篇文章中總結了10個Hadoop的應用場景：（1）在線旅遊：你知道嗎，目前全球范圍內80%的在線旅遊網站都是在使用Cloudera公司提供的Hadoop發行版，其中SearchBI網站曾經報道過的Expedia也在其中。 （2）移動數據：Cloudera運營總監稱，美國有70%的智能手機數據服務背後都是由Hadoop來支撐的，也就是說，包括數據的存儲以及無線運營商的數據處理等，都是在利用Hadoop技術。（3）電子商務：這一場景應該是非常確定的，eBay就是最大的實踐者之一。國內的電商在Hadoop技術上也是儲備頗為雄厚的。（4）能源開采：美國Chevron公司是全美第二大石油公司，他們的IT部門主管介紹了Chevron使用Hadoop的經驗，他們利用Hadoop進行數據的收集和處理，其中這些數據是海洋的地震數據，以便於他們找到油礦的位置。（5）節能：另外一家能源服務商Opower也在使用Hadoop,為消費者提供節約電費的服務，其中對用戶電費單進行了預測分析。（6）基礎架構管理：這是一個非常基礎的應用場景，用戶可以用Hadoop從伺服器、交換機以及其他的設備中收集並分析數據。（7）圖像處理：創業公司Skybox Imaging 使用Hadoop來存儲並處理圖片數據，從衛星中拍攝的高清圖像中探測地理變化。（8） 詐騙檢測：這個場景用戶接觸的比較少，一般金融服務或者政府機構會用到。利用Hadoop來存儲所有的客戶交易數據，包括一些非結構化的數據，能夠幫助機構發現客戶的異常活動，預防欺詐行為。（9） IT安全：除企業IT基礎機構的管理之外，Hadoop還可以用來處理機器生成數據以便甄別來自惡意軟體或者網路中的攻擊。（10）醫療保健：醫療行業也會用到Hadoop,像IBM的Watson就會使用Hadoop集群作為其服務的基礎，包括語義分析等高級分析技術等。醫療機構可以利用語義分析為患者提供醫護人員，並協助醫生更好地為患者進行診斷。

⑥ 1g的文件在hadoop是怎麼存儲的

hdfs是按塊進行存儲的。1GB文件會劃分成若干塊（默認64MB一個塊，也可以自己配置），然後分配到不同的存儲節點上存儲。
nameserver會記錄哪些塊存儲在哪個節點上，等讀的時候需要訪問nameserver，獲取到不同的數據節點，然後再訪問數據即可。

⑦ hadoop 中文件是怎麼存儲的

1、存儲文件的時候需要指定存儲的路徑，這個路徑是HDFS的路徑。而不是哪個節點的某個目錄。比如./hadoop fs -put localfile hdfspat
一般操作的當前路徑是/user/hadoop比如執行./hadoop fs -ls .實際上就相當於./hadoop fs -ls /user/hadoop
2、HDFS本身就是一個文件系統，在使用的時候其實不用關心具體的文件是存儲在哪個節點上的。如果需要查詢可以通過頁面來查看，也可以通過API來實現查詢。

⑧ 海量圖片存儲用hadoop是否合適存儲在哪個節點上能否由我們自己決定

hadoop可以實現海量數據的存儲，它包含分布式文件系統HDFS，所以您說的一部分存在節點1，一部分存在節點2上肯定可行
當你需要存儲比較大的文件時，HDFS會把它分成多個小塊（塊的大小可以自己定）來進行分布式存儲，而且名位元組點會記錄存的位置，當應用程序請求計算時，會將計算移到相應的數據附近，所以用hadoop，就相信它好了，當然你也可以在它上面附加一些自己的安全管理模塊，或其它中間件等，畢竟hadoop也有不盡人意的地方，還需要改進。
目前facebook，淘寶，yahoo！等都用hadoop構建了自己的數據中心來支持海量數據的存儲

⑨ hadoop的文件存儲方式與傳統的文件有什麼區別

1、存儲文件的時候需要指定存儲的路徑，這個路徑是hdfs的路徑。而不是哪個節點的某個目錄。比如./hadoop fs -put localfile hdfspat
一般操作的當前路徑是/user/hadoop比如執行./hadoop fs -ls .實際上就相當於./hadoop fs -ls /user/hadoop
2、hdfs本身就是一個文件系統，在使用的時候其實不用關心具體的文件是存儲在哪個節點上的。如果需要查詢可以通過頁面來查看，也可以通過api來實現查詢。

⑩ hadoop中存儲文件系統hdfs的冗餘機制是怎麼進行的有什麼特點

可以只用一行代碼來運行MapRece作業：JobClient.runJon(conf)，Job作業運行時參與的四個實體：

1.JobClient 寫代碼，配置作業，提交作業。

2.JobTracker:初始化作業，分配作業，協調作業運行。這是一個java程序，主類是JobTracker。

3.TaskTracker：運行作業劃分後的任務，即分配數據分配上執行Map或Rece任務。

4.HDFS：保存作業數據、配置信息等，保存作業結果。

Map/Rece 作業總體執行流程：

代碼編寫 ----> 作業配置 ---->作業提交---->Map任務分配和執行---->處理中間結果----> Rece任務分配與執行----> 輸出結果

而對於每個作業的執行，又包含：

輸入准備---->任務執行---->輸出結果

作業提交JobClient：

JobClient的runJob方法產生一個Jobclient實例並調用其submitJob方法，然後runJob開始循環嗎，並在循環中調用getTaskCompetionEvents方法，獲得TaskCompletionEvent實例，每秒輪詢作業進度（後面有介紹進度和狀態更新），把進度寫到控制台，作業完成後顯示作業計數器，若失敗，則把錯誤記錄到控制台。

submitJob方法作業提交的過程：

1.向JobTracker請求一個新的JobId。

2.檢查作業相關路徑，如果路徑不正確就會返回錯誤。

3.計算作業輸入分片及其劃分信息。

4.將作業運行需要的資源（jar文件、配置文件等）復制到Shared HDFS，並

復制多個副本（參數控制，默認值為10）供tasktracker訪問，也會將計算的分片復制到HDFS。

5.調用JobTracker對象的submitJob()方法來真正提交作業，告訴JobTracker作業准備執行。

作業的初始化JobTracker：

JobTracker收到submitJob方法調用後，會把調用放入到一個內部隊列，由作業調度器（Job scheler）進行調度並對其初始化。Job初始化即創建一個作業對象。

當作業被調度後，JobTracker會創建一個代表這個作業的JobInProgress對象，並將任務和記錄信息封裝在這個對象中，以便跟蹤任務狀態和進程。

初始化過程就是JobInProgress對象的initTasks方法進行初始化的。

初始化步驟：

1.從HDFS中讀取作業對應的job.split信息，為後面的初始化做好准備。

2.創建並初始化map和rece任務。根據數據分片信息中的個數確定map task的個數，然後為每個map task生成一個TaskInProgress對象來處理數據分片，先將其放入nonRunningMapCache,以便JobTracker分配任務的時候使用。接下來根據JobConf中的mapred.rece.tasks屬性利用setNumReceTasks()方法設置rece task的數量，然後同map task創建方式。

3.最後就是創建兩個初始化task，進行map和rece的初始化。

任務的分配JobTracker：

消息傳遞HeartBeat： tasktracker運行一個簡單循環定期發送心跳（heartbeat）給JobTracker。由心跳告知JobTracker自己是否存活，同時作為消息通道傳遞其它信息（請求新task）。作為心跳的一部分，tasktracker會指明自己是否已准備好運行新的任務，如果是，jobtracker會分配它一個任務。

分配任務所屬於的作業：在Jobtracker分配任務前需先確定任務所在的作業。後面會介紹到各種作業調度演算法，默認是一個FIFO的作業調度。

分配Map和Rece任務：tasktracker有固定數量的任務槽,一個tasktracker可以同時運行多個Map和Rece任務，但其准確的數量由tasktracker的核的數量和內存大小決定。默認調度器會先填滿Map任務槽，再填Rece任務槽。jobtracker會選擇距離離分片文件最近的tasktracker，最理想情況下，任務是數據本地化（data-local）的,當然也可以是機架本地化（rack-local），如果不是本地化的，那麼他們就需要從其他機架上檢索數據。Rece任務分配很簡單，jobtracker會簡單的從待運行的rece任務列表中選取下一個來執行，不用考慮數據本地化。

任務的執行TaskTracker：

TaskTracker收到新任務後，就要在本地運行任務了，運行任務的第一步就是通過localizedJob將任務本地化所需要的注入配置、數據、程序等信息進行本地化。

1.本地化數據：從共享文件系統將job.split 、job.jar (在分布式緩存中)復制本地，將job配置信息寫入job.xml。

2.新建本地工作目錄：tasktracker會加壓job.jar文件到本工作目錄。

3.調用launchTaskForJob方法發布任務（其中會新建TaskRunner實例運行任務），如果是Map任務就啟用MapTaskRunner，對於Rece就是ReceTaskRunner。

在這之後，TaskRunner會啟用一個新的JVM來運行每個Map/Rece任務，防止程序原因而導致tasktracker崩潰，但不同任務間重用JVM還是可以的，後續會講到任務JVM重用。

對於單個Map，任務執行的簡單流程是：

1.分配任務執行參數

2.在Child臨時文件中添加map任務信息（Child是運行Map和Rece任務的主進程）

3.配置log文件夾，配置map任務的通信和輸出參數

4.讀取input split，生成RecordReader讀取數據

5.為Map生成MapRunnable,依次從RecordReader中接收數據，並調用Map函數進行處理。

6.最後將map函數的輸出調用collect收集到MapOutputBuffer（參數控制其大小）中。

Streaming和Pipes:

Streaming和Pipes都運行特殊的Map和Rece任務，目的是運行用戶提供的可執行程序並與之通信。

Streaming:使用標准輸入輸出Streaming與進程進行通信。

Pipes:用來監聽套接字，會發送一個埠號給C++程序，兩者便可建立鏈接。

進度和狀態更新：

一個作業和它的任務都有狀態（status），其中包括：運行成功失敗狀態、Map/Rece進度、作業計數器值、狀態消息。

狀態消息與客戶端的通信：

1.對於Map任務Progress的追蹤：progress是已經處理完的輸入所佔的比例。

2.對於Rece：稍復雜，rece任務分三個階段（每個階段佔1/3），復制、排序和Rece處理，若rece已執行一半的輸入的話，那麼任務進度便是1/3+1/3+1/6=5/6。

3.任務計數器：任務有一組計數器，負責對任務運行各個事件進行計數。

4.任務進度報告：如果任務報告了進度，便會設置一個標記以表明狀態將被發送到tasktracker。有一個獨立線程每隔三秒檢查一次此標記，如果已設置，則告知tasktracker當前狀態。

5.tasktracker進度報告：tasktracker會每隔5秒（這個心跳是由集群大小決定，集群越大時間會越長）發送heartbeat到jobtracker，並且tasktracker運行的所有狀態都會在調用中被發送到jobtracker。

6.jobtracker合並各任務報告：產生一個表明所有運行作業機器所含任務狀態的全局視圖。

前面提到的JobClient就是通過每秒查詢JobTracker來接收最新狀態，而且客戶端JobClient的getJob方法可以得到一個RunningJob的實例，其包含了作業的所以狀態信息。

作業的完成：

當jobtracker收到作業最後一個任務已完成的通知後，便把作業狀態設置成成功。JobClient查詢狀態時，便知道任務已成功完成，於是JobClient列印一條消息告知用戶，然後從runJob方法返回。

如果jobtracker有相應設置，也會發送一個Http作業通知給客戶端，希望收到回調指令的客戶端可以通過job.end.notification.url屬性來進行設置。

jobtracker情況作業的工作狀態，指示tasktracker也清空作業的工作狀態，如刪除中間輸出。

失敗

實際情況下，用戶的代碼存在軟體錯誤進程會崩潰，機器也會產生故障，但Hadoop能很好的應對這些故障並完成作業。

1.任務失敗

子任務異常：如Map/Rece任務中的用戶代碼拋出異常，子任務JVM進程會在退出前向父進程tasktracker發送錯誤報告，錯誤被記錄用戶日誌。tasktracker會將此次task attempt標記為tailed，並釋放這個任務槽運行另外一個任務。

子進程JVM突然退出：可能由於JVM bug導致用戶代碼造成的某些特殊原因導致JVM退出，這種情況下，tasktracker會注意到進程已經退出，並將此次嘗試標記為failed。

任務掛起：一旦tasktracker注意一段時間沒有收到進度更新，便會將任務標記為failed，JVM子進程將被自動殺死。任務失敗間隔時間通常為10分鍾，可以以作業或者集群為基礎設置過期時間，參數為mapred.task.timeout。注意：如果參數值設置為0，則掛起的任務永遠不會釋放掉它的任務槽，隨著時間的推移會降低整個集群的效率。

任務失敗嘗試次數：jobtracker得知一個tasktracker失敗後，它會重新調度該任務執行，當然，jobtracker會嘗試避免重新調度失敗過的tasktracker任務。如果一個任務嘗試次數超過4次，它將不再被重試。這個值是可以設置的，對於Map任務，參數是mapred.map.max.attempts,對於rece任務，則由mapred.rece.max.attempts屬性控制。如果次數超過限制，整個作業都會失敗。當然，有時我們不希望少數幾個任務失敗就終止運行的整個作業，因為即使有些任務失敗，作業的一些結果可能還是有用的，這種情況下，可以為作業設置在不觸發作業失敗情況下的允許任務失敗的最大百分比，Map任務和Rece任務可以獨立控制，參數為mapred.max.map.failures.percent 和mapred.max.rece.failures.percent。

任務嘗試中止（kill）：任務終止和任務失敗不同，task attempt可以中止是因為他是一個推測副本或因為它所處的tasktracker失敗，導致jobtracker將它上面的所有task attempt標記為killed。被終止的task attempt不會被計入任務運行嘗試次數，因為嘗試中止並不是任務的錯。

2.tasktracker失敗

tasktracker由於崩潰或者運行過慢而失敗，他將停止向jobtracker發送心跳（或很少發送心跳）。jobtracker注意已停止發送心跳的tasktracker（過期時間由參數mapred.tasktracker.expiry.interval設置，單位毫秒），並將它從等待調度的tasktracker池中移除。如果是未完成的作業，jobtracker會安排次tasktracker上已經運行成功的Map任務重新運行，因為此時rece任務已無法訪問（中間輸出存放在失敗的tasktracker的本地文件系統上）。

即使tasktracker沒有失敗，也有可能被jobtracker列入黑名單。如果tasktracker上面的失敗任務數量遠遠高於集群的平均失敗任務次數，他就會被列入黑名單，被列入黑名單的tasktracker可以通過重啟從jobtracker黑名單中移除。

3.jobtracker失敗

老版本的JobTracker失敗屬於單點故障，這種情況下作業註定失敗。

作業調度：

早期作業調度FIFO：按作業提交順序先進先出。可以設置優先順序，通過設置mapred.job.priority屬性或者JobClient的setJobPriority()方法制定優先順序（優先順序別：VERY_HIGH,HIGH,NORMAL,LOW,VERY_LOW）。注意FIFO調度演算法不支持搶占（preemption）,所以高優先順序作業仍然會被那些已經開始的長時間運行的低優先順序作業所阻塞。

Fair Scheler：目標是讓每個用戶公平地共享集群能力。當集群存在很多作業時，空閑的任務槽會以」讓每個用戶共享集群「的方式進行分配。默認每個用戶都有自己的作業池。FairScheler支持搶占，所以，如果一個池在特定的一段時間未得到公平地資源共享，它會終止池中得到過多的資源任務，以便把任務槽讓給資源不足的池。FairScheler是一個後續模塊，使用它需要將其jar文件放在Hadoop的類路徑下。可以通過參數map.red.jobtracker.taskScheler屬性配置（值為org.apache.hadoop.mapred.FairScheler）

Capacity Scheler：

集群由很多隊列組成，每個隊列都有一個分配能力，這一點與FairScheler類似，只不過在每個隊列內部，作業根據FIFO方式進行調度。本質上說，Capacity Scheler允許用戶或組織為每個用戶模擬一個獨立使用FIFO的集群。

shuffle和排序：

MapRece確保每個Recer的輸入都是按鍵排序的。系統執行排序的過程-將map輸出作為輸入傳給recer的過程稱為shuffle。shuffle屬於不斷被優化和改進的代碼庫的一部分，從許多方面來看，shuffle是MapRece的心臟。

整個shuffle的流程應該是這樣：

map結果劃分partition 排序sort 分割spill 合並同一劃分 合並同一劃分 合並結果排序 rece處理 輸出

Map端：

寫入緩沖區：Map函數的輸出，是由collector處理的，它並不是簡單的將結果寫到磁碟。它利用緩沖的方式寫到內存，並處於效率的考慮進行預排序。每個map都有一個環形的內存緩沖區，用於任務輸出，默認緩沖區大小為100MB（由參數io.sort.mb調整），一旦緩沖區內容達到閾值（默認0.8），後台進程邊開始把內容寫到磁碟（spill），在寫磁碟過程中，map輸出繼續被寫到緩沖區，但如果緩沖區被填滿，map會阻塞知道寫磁碟過程完成。寫磁碟將按照輪詢方式寫到mapred.local.dir屬性制定的作業特定子目錄中。

寫出緩沖區：collect將緩沖區的內容寫出時，會調用sortAndSpill函數，這個函數作用主要是創建spill文件，按照key值對數據進行排序，按照劃分將數據寫入文件，如果配置了combiner類，會先調用combineAndSpill函數再寫文件。sortAndSpill每被調用一次，就會寫一個spill文件。

合並所有Map的spill文件：TaskTracker會在每個map任務結束後對所有map產生的spill文件進行merge，merge規則是根據分區將各個spill文件中數據同一分區中的數據合並在一起，並寫入到一個已分區且排序的map輸出文件中。待唯一的已分區且已排序的map輸出文件寫入最後一條記錄後，map端的shuffle階段就結束了。

在寫磁碟前，線程首先根據數據最終要傳遞到的recer把數據劃分成響應的分區（partition），在每個分區中，後台線程按鍵進行內排序，如果有一個combiner,它會在排序後的輸出上運行。

內存達到溢出寫的閾值時，就會新建一個溢出寫文件，因為map任務完成其最後一個輸出記錄之後，會有幾個溢出寫文件。在任務完成前，溢出寫文件會被合並成一個已分區且已排序的輸出文件。配置屬性io.sort.facor控制一次最多能合並多少流，默認值是10。

如果已經指定combiner,並且寫次數至少為3（通過min.mum.spills.for.combine設置）時，則combiner就會在輸出文件寫到磁碟之前運行。運行combiner的意義在於使map輸出更緊湊，捨得寫到本地磁碟和傳給recer的數據更少。

寫磁碟時壓縮：寫磁碟時壓縮會讓寫的速度更快，節約磁碟空間，並且減少傳給recer的數據量。默認情況下，輸出是不壓縮的，但可以通過設置mapred.compress.map.output值為true，就可以啟用壓縮。使用的壓縮庫是由mapred.map.output.compression.codec制定。

recer獲得文件分區的工作線程：recer通過http方式得到輸出文件的分區，用於文件分區的工作線程數量由tracker.http.threads屬性指定，此設置針對的是每個tasktracker，而不是每個map任務槽。默認值為40，在大型集群上此值可以根據需要而增加。

Rece端：

復制階段：rece會定期向JobTracker獲取map的輸出位置，一旦拿到輸出位置，rece就會從對應的TaskTracker上復制map輸出到本地（如果map輸出很小，則會被復制到TaskTracker節點的內存中，否則會被讓如磁碟），而不會等到所有map任務結束（當然這個也有參數控制）。

合並階段：從各個TaskTracker上復制的map輸出文件（無論在磁碟還是內存）進行整合，並維持數據原來的順序。

Rece階段：從合並的文件中順序拿出一條數據進行rece函數處理，然後將結果輸出到本地HDFS。

Map的輸出文件位於運行map任務的tasktracker的本地磁碟，現在，tasktracker要為分區文件運行rece任務。每個任務完成時間可能不同，但是只要有一個任務完成，rece任務就開始復制其輸出，這就是rece任務的復制階段（ phase）。rece任務有少量復制線程，因此能夠並行取得map輸出。默認值是5個線程，可以通過mapred.rece.parallel.copies屬性設置。

Recer如何得知從哪個tasktracker獲得map輸出：map任務完成後會通知其父tasktracker狀態已更新，tasktracker進而通知（通過heart beat）jobtracker。因此，JobTracker就知道map輸出和tasktracker之間的映射關系，recer中的一個線程定期詢問jobtracker以便獲知map輸出位置。由於recer有可能失敗，因此tasktracker並沒有在第一個recer檢索到map輸出時就立即從磁碟上刪除它們，相反他會等待jobtracker告示它可以刪除map輸出時才刪除，這是作業完成後最後執行的。

如果map輸出很小，則會被直接復制到rece tasktracker的內存緩沖區（大小由mapred.job.shuffle.input.buffer.percent控制，占堆空間的百分比），否則，map輸出被復制到磁碟。一旦內存緩沖區達到閾值大小（由mapred.iob.shuffle.merge.percent）

或達到map輸出閾值大小（mapred.inmem.threadhold），則合並後溢出寫到磁碟中。

隨著磁碟上副本增多，後台線程會將他們合並為更大的、排好序的文件。注意：為了合並，壓縮的map輸出必須在內存中被解壓縮。

排序階段：復制階段完成後，rece任務會進入排序階段，更確切的說是合並階段，這個階段將合並map輸出，維持其順序排列。合並是循環進行的，由合並因子決定每次合並的輸出文件數量。但讓有可能會產生中間文件。

rece階段：在最後rece階段，會直接把排序好的文件輸入rece函數，不會對中間文件進行再合並，最後的合並即可來自內存，也可來自磁碟。此階段的輸出會直接寫到文件系統，一般為hdfs。

細節：這里合並是並非平均合並，比如有40個文件，合並因子為10，我們並不是每趟合並10個，合並四趟。而是第一趟合並4個，後三趟合並10，在最後一趟中4個已合並的文件和餘下6個未合並會直接並入rece。