You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-user@hadoop.apache.org by "yoav.morag" <yo...@corrigon.com> on 2008/12/09 14:08:58 UTC

merging into MapFile

hi all -
can anyone comment on the performance cost of merging many small files into
an increasingly large MapFile ? will that cost be dependent on the size of
the larger MapFile (since I have to rewrite it) or is there a built-in
strategy to split it into smaller parts, affecting only those which were
touched ? 
thanks -
Yoav.
-- 
View this message in context: http://www.nabble.com/merging-into-MapFile-tp20914388p20914388.html
Sent from the Hadoop core-user mailing list archive at Nabble.com.


Re: merging into MapFile

Posted by "yoav.morag" <yo...@corrigon.com>.
let me rephrase my question : 
are all the parts of a MapFile necessarily affected by a merge ? if so, it's
not scalable, no matter what is the block size is.
however, since MapFile is essentially a directory and not a file, I don't
see a reason why all parts should be affected. can anyone comment on the
actual implementation of the merge algorithm ? 


Elia Mazzawi-2 wrote:
> 
> it has to do with the data block size,
> 
> I had many small files and the performance because much better when i 
> merged them,
> 
> the default block size is 64Mb so redo your files to <= 64MB (what i did 
> and recommend)
> or reconfigure your hadoop.
> 
> <property>
>   <name>dfs.block.size</name>
>   <value>67108864</value>
>   <description>The default block size for new files.</description>
> </property>
> 
> do something like
> cat * | rotatelogs ./merged/m 64M
> it will merge and chop the data for you.
> 
> yoav.morag wrote:
>> hi all -
>> can anyone comment on the performance cost of merging many small files
>> into
>> an increasingly large MapFile ? will that cost be dependent on the size
>> of
>> the larger MapFile (since I have to rewrite it) or is there a built-in
>> strategy to split it into smaller parts, affecting only those which were
>> touched ? 
>> thanks -
>> Yoav.
>>   
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/merging-into-MapFile-tp20914388p20930594.html
Sent from the Hadoop core-user mailing list archive at Nabble.com.


Re: merging into MapFile

Posted by Elia Mazzawi <el...@casalemedia.com>.
it has to do with the data block size,

I had many small files and the performance because much better when i 
merged them,

the default block size is 64Mb so redo your files to <= 64MB (what i did 
and recommend)
or reconfigure your hadoop.

<property>
  <name>dfs.block.size</name>
  <value>67108864</value>
  <description>The default block size for new files.</description>
</property>

do something like
cat * | rotatelogs ./merged/m 64M
it will merge and chop the data for you.

yoav.morag wrote:
> hi all -
> can anyone comment on the performance cost of merging many small files into
> an increasingly large MapFile ? will that cost be dependent on the size of
> the larger MapFile (since I have to rewrite it) or is there a built-in
> strategy to split it into smaller parts, affecting only those which were
> touched ? 
> thanks -
> Yoav.
>   


"HDFS bytes read" counter

Posted by Songting Chen <ke...@yahoo.com>.
I am reading the performance counter and having the following question:

Map Input Bytes = 6.8G, while HDFS Bytes Read = 10G.

What are the additional 3.2G?

Thanks
-Songting