我们有一个关于amazonemrhadoop作业的压缩输入的问题。
根据aws:
“hadoop检查文件扩展名以检测压缩文件。hadoop支持的压缩类型有:gzip、bzip2和lzo。您不需要采取任何额外的行动来提取文件使用这些类型的压缩;hadoop为您处理它。”
q、 五、。,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只是一个数据压缩器。它不是一个像焦油或拉链档案;该程序本身没有用于多个文件、加密或存档拆分的功能,但在unix传统中,这些任务依赖于单独的外部实用程序,如tar和gnupg。”
q、 五、。,http://en.wikipedia.org/wiki/bzip2
我认为这两个语句的组合意味着bzip2是“可拆分的”,但它是以文件为基础的。
这是相关的,因为我们的作业将通过s3接收一个~800mib文件——这(如果我的解释是正确的)意味着ec2/hadoop将为作业分配一个Map器(对于一个文件),这至少是次优的。
(在这种情况下,在将bzip2作为解决方案应用之前,我们显然需要找到一种将输入划分为一组400个文件的方法)。
有人知道这是否是aws/emr hadoop作业内部的工作方式吗?
干杯!
2条答案
按热度按时间13z8s7eq1#
据我目前所知,bzip2文件可能是可拆分的,您可以在hadoop中实现,但在aws emr中仍然不支持它,至少“现在”不支持。因此,如果您只是用一个大的bzip2文件运行一个作业,那么您将在第一步得到一个Map器。我最近刚试过。显然,索引的lzo文件也会发生这种情况,除非你使用黑魔法。我不确定是否有相应的黑魔术分裂bzip2文件在电子病历了。
r6l8ljro2#
自从
.bz2
文件没有任何文件的概念。一个.bz2流包含一个4字节的头,后跟零个或多个压缩块
压缩块是这里的关键。一
.bz2
可以在块边界上拆分文件。因此,可以创建的拆分数目将取决于压缩块的大小。编辑(根据您的评论):
hadoop中的分裂边界经常会出现在记录的中间,不管数据是否被压缩。
TextInputFormat
将在hdfs块边界上拆分。诀窍在于RecordReader
.假设我们在一个文件的第10条记录中间有一个分割边界。读取第一个分割的Map器将读取到第10条记录的结尾,即使该记录的结尾超出了Map器分配的分割。然后,第二个Map器忽略其拆分中的第一个部分记录,因为它已经被第一个Map器读取。
只有在给定记录的任意字节偏移量的情况下,才能可靠地找到记录的结尾。