对于Amazon EMR Hadoop作业上的压缩输入,我们有一个特定的问题。
根据AWS:
“Hadoop检查文件扩展名以检测压缩文件。Hadoop支持的压缩类型为:gzip,bzip2和LZO。您无需采取任何其他操作即可使用这些压缩类型提取文件; Hadoop会为您处理。 ”
q.v.,http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/HowtoProcessGzippedFiles.html
看起来不错,但是,查看BZip2,似乎“分割”边界将基于文件:
.magic:16 = 'BZ' signature/magic number
.version:8 = 'h' for Bzip2 ('H'uffman coding), '0' for Bzip1 (deprecated)
.hundred_k_blocksize:8 = '1'..'9' block-size 100 kB-900 kB (uncompressed)
**-->.compressed_magic:48 = 0x314159265359 (BCD (pi))**
.crc:32 = checksum for this block
.randomised:1 = 0=>normal, 1=>randomised (deprecated)
.origPtr:24 = starting pointer into BWT for after untransform
.huffman_used_map:16 = bitmap, of ranges of 16 bytes, present/not present
.huffman_used_bitmaps:0..256 = bitmap, of symbols used, present/not present (multiples of 16)
.huffman_groups:3 = 2..6 number of different Huffman tables in use
.selectors_used:15 = number of times that the Huffman tables are swapped (each 50 bytes)
*.selector_list:1..6 = zero-terminated bit runs (0..62) of MTF'ed Huffman table (*selectors_used)
.start_huffman_length:5 = 0..20 starting bit length for Huffman deltas
*.delta_bit_length:1..40 = 0=>next symbol; 1=>alter length
.contents:2..8 = Huffman encoded data stream until end of block
**-->.eos_magic:48 = 0x177245385090 (BCD sqrt(pi))**
.crc:32 = checksum for whole stream
.padding:0..7 = align to whole byte
声明如下:“像gzip一样,bzip2只是一个数据压缩器。它不是tar或ZIP之类的存档器;该程序本身不具有用于多个文件,加密或存档分割的功能,但在UNIX传统中,它依赖于在单独的外部实用程序(例如tar和GnuPG)上执行这些任务。”
q.v.,http://en.wikipedia.org/wiki/Bzip2
我认为这两个语句的组合意味着BZip2是“可拆分的”,但这样做是基于文件的。 。 。 。
这是相关的,因为我们的工作将通过S3-接收单个〜800MiB文件(如果我的解释是正确的话),这意味着EC2 / Hadoop将为该工作分配一个Mapper(对于一个文件),这将是-至少可以说是最佳的。
(在这种情况下,在应用BZip2作为解决方案之前,我们显然需要找到一种将输入划分为400个文件的方法)。
谁能确定这是否是AWS / EMR Hadoop作业内部运作的方式?
干杯!
最佳答案
由于.bz2
文件没有任何文件概念,因此可以在文件边界上进行拆分实际上没有任何意义。
压缩块是这里的关键。可以在块边界上分割.bz2
文件。因此,您可以创建的分割数将取决于压缩块的大小。
编辑(根据您的评论):
Hadoop中的分割边界通常可能发生在记录的一半,而不管数据是否被压缩。 TextInputFormat
将在HDFS块边界上分割。诀窍在RecordReader
中。
假设我们在文件的第10条记录的中间分割了边界。读取第一个拆分的映射器将读取到第10条记录的末尾,即使该记录在分配的拆分器之外终止。然后,第二个映射器将忽略其拆分中的第一个部分记录,因为第一个映射器已经读取了该记录。
仅当给定记录中的任意字节偏移量时,您才能可靠地找到记录的末尾,这才有效。