Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAOeeJfgeZdRJw+D0F=sY-eexwCM1wM+OroUqJtupsr-WiES1Dw@mail.gmail.com>
References: 
 <CAOeeJfgeZdRJw+D0F=sY-eexwCM1wM+OroUqJtupsr-WiES1Dw@mail.gmail.com>
Date: Mon, 1 Oct 2012 21:12:58 -0700
Message-ID: 
 <CABCYYb-kZcougMSDdZqgsG2EEgXXkHq63A6qpP-cvuKB1PeD7A@mail.gmail.com>
Subject: Re: File block size use
From: Chris Nauroth <cnauroth@hortonworks.com>
To: user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=e89a8f234855c336d504cb0bbc4a

--e89a8f234855c336d504cb0bbc4a
Content-Type: text/plain; charset=ISO-8859-1

Hello Anna,

If I understand correctly, you have a set of multiple sequence files, each
much smaller than the desired block size, and you want to concatenate them
into a set of fewer files, each one more closely aligned to your desired
block size.  Presumably, the goal is to improve throughput of map reduce
jobs using those files as input by running fewer map tasks, reading a
larger number of input records.

Whenever I've had this kind of requirement, I've run a custom map reduce
job to implement the file consolidation.  In my case, I was typically
working with TextInputFormat (not sequence files).  I used IdentityMapper
and a custom reducer that passed through all values but with key set to
NullWritable, because the keys (input file offsets in the case of
TextInputFormat) were not valuable data.  For my input data, this was
sufficient to achieve fairly even distribution of data across the reducer
tasks, and I could reasonably predict the input data set size, so I could
reasonably set the number of reducers and get decent results.  (This may or
may not be true for your data set though.)

A weakness of this approach is that the keys must pass from the map tasks
to the reduce tasks, only to get discarded before writing the final output.
 Also, the distribution of input records to reduce tasks is not truly
random, and therefore the reduce output files may be uneven in size.  This
could be solved by writing NullWritable keys out of the map task instead of
the reduce task and writing a custom implementation of Partitioner to
distribute them randomly.

To expand on this idea, it could be possible to inspect the FileStatus of
each input, sum the values of FileStatus.getLen(), and then use that
information to make a decision about how many reducers to run (and
therefore approximately set a target output file size).  I'm not aware of
any built-in or external utilities that do this for you though.

Hope this helps,
--Chris

On Mon, Oct 1, 2012 at 11:30 AM, Anna Lahoud <annalahoud@gmail.com> wrote:

> I would like to be able to resize a set of inputs, already in SequenceFile
> format, to be larger.
>
> I have tried 'hadoop distcp -Ddfs.block.size=$[64*1024*1024]' and did not
> get what I expected. The outputs were exactly the same as the inputs.
>
> I also tried running a job with an IdentityMapper and IdentityReducer.
> Although that approaches a better solution, it still requires that I know
> in advance how many reducers I need to get better file sizes.
>
> I was looking at the SequenceFile.Writer constructors and noticed that
> there are block size parameters that can be used. Using a writer
> constructed with a 512MB block size, there is nothing that splits the
> output and I simply get a single file the size of my inputs.
>
> What is the current standard for combining sequence files to create larger
> files for map-reduce jobs? I have seen code that tracks what it writes into
> the file, but that seems like the long version. I am hoping there is a
> shorter path.
>
> Thank you.
>
> Anna
>
>

--e89a8f234855c336d504cb0bbc4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Anna,<div><br></div><div>If I understand correctly, you have a set of=
 multiple sequence files, each much smaller than the desired block size, an=
d you want to concatenate them into a set of fewer files, each one more clo=
sely aligned to your desired block size. =A0Presumably, the goal is to impr=
ove throughput of map reduce jobs using those files as input by running few=
er map tasks, reading a larger number of input records.</div>
<div><br></div><div>Whenever I&#39;ve had this kind of requirement, I&#39;v=
e run a custom map reduce job to implement the file consolidation. =A0In my=
 case, I was typically working with TextInputFormat (not sequence files). =
=A0I used IdentityMapper and a custom reducer that passed through all value=
s but with key set to NullWritable, because the keys (input file offsets in=
 the case of TextInputFormat) were not valuable data. =A0For my input data,=
 this was sufficient to achieve fairly even distribution of data across the=
 reducer tasks, and I could reasonably predict the input data set size, so =
I could reasonably set the number of reducers and get decent results. =A0(T=
his may or may not be true for your data set though.)</div>
<div><br></div><div>A weakness of this approach is that the keys must pass =
from the map tasks to the reduce tasks, only to get discarded before writin=
g the final output. =A0Also, the distribution of input records to reduce ta=
sks is not truly random, and therefore the reduce output files may be uneve=
n in size. =A0This could be solved by writing NullWritable keys out of the =
map task instead of the reduce task and writing a custom implementation of =
Partitioner to distribute them randomly.</div>
<div><br></div><div>To expand on this idea, it could be possible to inspect=
 the FileStatus of each input, sum the values of FileStatus.getLen(), and t=
hen use that information to make a decision about how many reducers to run =
(and therefore approximately set a target output file size). =A0I&#39;m not=
 aware of any built-in or external utilities that do this for you though.</=
div>
<div><br></div><div>Hope this helps,</div><div>--Chris</div><div><br></div>=
<div><div class=3D"gmail_quote">On Mon, Oct 1, 2012 at 11:30 AM, Anna Lahou=
d <span dir=3D"ltr">&lt;<a href=3D"mailto:annalahoud@gmail.com" target=3D"_=
blank">annalahoud@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I would like to be able to resize a set of i=
nputs, already in SequenceFile format, to be larger. <br><br>I have tried &=
#39;hadoop distcp -Ddfs.block.size=3D$[64*1024*1024]&#39; and did not get w=
hat I expected. The outputs were exactly the same as the inputs. <br>

<br>I also tried running a job with an IdentityMapper and IdentityReducer. =
Although that approaches a better solution, it still requires that I know i=
n advance how many reducers I need to get better file sizes. <br><br>I was =
looking at the SequenceFile.Writer constructors and noticed that there are =
block size parameters that can be used. Using a writer constructed with a 5=
12MB block size, there is nothing that splits the output and I simply get a=
 single file the size of my inputs. <br>

<br>What is the current standard for combining sequence files to create lar=
ger files for map-reduce jobs? I have seen code that tracks what it writes =
into the file, but that seems like the long version. I am hoping there is a=
 shorter path.<br>

<br>Thank you.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>Anna<b=
r><br>
</font></span></blockquote></div><br></div>

--e89a8f234855c336d504cb0bbc4a--