在MapReduce中輸入分裂的主要原因是什麼？

Question

在MapReduce papers中描述了輸入文件在M個輸入分割中被分割。我知道Hadoop中的HDFS會自動將分區分區爲64 MB（默認值）的塊，然後將這些塊複製到羣集中的其他幾個節點以提供容錯功能。我想知道在HDFS中對文件進行分區是否意味着在所提到的MapReduce論文中描述的輸入分裂。這是容錯的單一原因，還是有更重要的原因？

如果我在沒有分佈式文件系統的節點集羣上使用MapReduce（僅在具有公共文件系統的本地磁盤上的數據），該怎麼辦？在映射階段之前是否需要在本地磁盤上分割輸入文件？

謝謝你的回答。

Answer 1

想補充一些缺失的概念（ANS是混淆對我來說）

---

---

HDFS

的文件存儲爲塊（故障/節點公差 ）。塊大小（64MB-128MB）64MB。所以文件被分成塊，塊被存儲在簇上的不同節點上。一個塊正在被複制因子複製（默認值= 3）。

的map-reduce

已經被存儲在HDFS文件在邏輯上劃分爲INPUT-SPLITS。

MAX（的minimumSize，分鐘（MAXIMUMSIZE，BLOCKSIZE））： 的分割尺寸可以由用戶

Property name   Type Default value 

---

mapred.min.split.size int  1 
mapred.max.split.sizea long Long.MAX_VALUE. 

然後分割尺寸由下式計算來設定

NOTE：：分割是邏輯

---

---

希望能答您的問題現在

I'd like to know if this partitioning of files in HDFS means the input splitting described in mentioned MapReduce papers. 

不，不是在所有的HDFS塊和地圖，減少分割都是同樣的事情。

Is fault tolerance single reason of this splitting or are there more important reasons? 

不，分佈式計算將是原因。

And what if I have MapReduce over cluster of nodes without distributed file system (data only on local disks with common file sytem)? Do I need to split input files on local disk before map phase? 

在你的情況，我想，是的，你將不得不拆分輸入文件映射階段，還你將不得不拆分中間輸出（從映射器），用於簡化階段。 其他問題：數據的一致性，容錯性，數據丟失（在hadoop中= 1％）。

Map-Reduce用於分佈式計算，因此在非分佈式環境中使用Map-Reduce並不有用。

感謝

Answer 2

I'd like to know if this partitioning of files in HDFS means the input splitting described in mentioned MapReduce papers. 

不，在MapReduce中的輸入分割是爲了在縮小階段利用多個處理器的計算能力。映射器需要大量的數據並將數據分割成邏輯分區（大部分時間由程序員自定義映射器實現）。然後將這些數據發送到單獨的節點，在這些節點中，稱爲reducer的獨立進程執行數據處理，然後結果進行整理。

Is fault tolerance single reason of this splitting or are there more important reasons? 

不，這不是這樣做的唯一原因。您可以將其與文件系統級別塊大小進行比較，以確保將數據傳輸到塊中，以每塊爲基礎壓縮數據並分配I/O緩衝區。