1. 首頁
  2. 問答
  3. 關於Hadoop和壓縮輸入文件的非常基本的問題

關於Hadoop和壓縮輸入文件的非常基本的問題

2010-01-16 19 views
19

我已經開始研究Hadoop。如果我的理解是正確的，我可以處理一個非常大的文件，它會被分割到不同的節點上，但是如果文件被壓縮，那麼文件就不能被分割，並且需要由單個節點來處理（有效地破壞運行mapreduce並行機羣）。關於Hadoop和壓縮輸入文件的非常基本的問題

我的問題是，假設上述是正確的，是否有可能以固定大小的塊或日常塊手動拆分大文件，壓縮它們，然後傳遞壓縮輸入文件列表以執行映射精簡？

來源

2010-01-16 Luis Sisamon

回答

3

是的，你可以有一個大的壓縮文件或多個壓縮文件（使用-files或api指定的多個文件）。

TextInputFormat和後代應該自動處理.gz壓縮文件。你也可以實現自己的InputFormat（將輸入文件分割成塊進行處理）和RecordReader（即同時從塊中提取一個記錄）

另一種選擇仿製copmression可能是使用壓縮文件系統（如帶壓縮補丁，zfs，compFUSEd或FuseCompress的ext3 ...）

來源

2010-01-16 20:58:12 jspcal

+0

非常感謝。 – 2010-01-17 06:20:12

1

您可以使用bz2作爲壓縮編解碼器，並且此格式也可以被拆分。

來源

2010-01-22 09:15:33 zjffdu

5

考慮使用LZO壓縮。它是可拆分的。這意味着一個大的.lzo文件可以被許多映射器處理。 Bzip2可以做到這一點，但速度很慢。

Cloudera對此有一個introduction。對於MapReduce，LZO在壓縮率和壓縮/解壓縮速度之間聽起來很好的平衡。

來源

2010-01-30 09:42:09 Victor

+3

LZO不能單獨分割。您必須運行單獨的進程來索引LZO文件，以便壓縮塊與輸入拆分正確對齊。看到頁面最後一行的小寶貝：https：//github.com/kevinweil/hadoop-lzo – jerluc 2012-08-10 00:20:28

+3

@Luis但請記住，LZO是GPL許可的，因此適用常規條款和條件。另一種選擇是使用Google的Snappy壓縮。 [Google Snappy]（http://code.google.com/p/snappy/） 它默認使用Hadoop打包（我使用0.20。x）和其他生態系統框架（如Apache Flume等）在默認情況下也很好理解。 – arcamax 2013-02-28 11:15:56

6

BZIP2可以在hadoop中拆分 - 它提供了非常好的壓縮比，但是從CPU時間和性能不能提供最佳結果，因爲壓縮非常耗費CPU資源。

LZO是裂開的Hadoop中 - 利用hadoop-lzo你已經裂開的LZO壓縮文件。您需要具有外部.lzo.index文件才能夠並行處理。該庫提供了以本地或分佈方式生成這些索引的所有方法。

LZ4是裂開的Hadoop中 - 利用hadoop-4mc你已經裂開的壓縮4mc文件。您不需要任何外部索引，並且可以使用提供的命令行工具或Java/C代碼（在hadoop內部/外部）生成歸檔。 4mc可以在任何級別的速度/壓縮比下使用hadoop LZ4：從快速模式達到500 MB/s壓縮速度到高/超模式，提供更高的壓縮比，幾乎與GZIP相當。

來源

2014-09-18 09:18:51

+3

LZ4在Hadoop中不可拆分。 4mc是使用LZ4的文件格式，很像LZ4具有自己的Frame格式，而4mc文件格式是可拆分的。重要的是要做出這種區分：實際的.lz4文件在Hadoop中不可拆分：https：//issues.apache.org/jira/browse/HADOOP-12990。 – 2016-04-08 18:50:57

相關問題

 相關問題