Jon,<div><br></div><div>The cookbook is asciidoc located at: <a href="http://www.ci.uchicago.edu/swift/cookbook/cookbook-asciidoc.html">http://www.ci.uchicago.edu/swift/cookbook/cookbook-asciidoc.html</a></div><div><br></div>
<div><br><div class="gmail_quote">On Sun, Aug 28, 2011 at 1:37 PM, Jonathan Monette <span dir="ltr"><<a href="mailto:jonmon@mcs.anl.gov">jonmon@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'll add it to the cookbook because I am not sure what mappers it works for and what options work. I only know that it works for those two mappers so testing to see exactly what works is needed. Is the cookbook in asciidoc or is it the ci swift wiki one? <br>
<div><div></div><div class="h5"><br>----- Reply message -----<br>From: "Michael Wilde" <<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>><br>Date: Sun, Aug 28, 2011 12:11 pm<br>Subject: [Swift-devel] MapReduce, doubts<br>
To: "Jonathan Monette" <<a href="mailto:jonmon@mcs.anl.gov" target="_blank">jonmon@mcs.anl.gov</a>><br>Cc: "Yadu Nand" <<a href="mailto:yadudoc1729@gmail.com" target="_blank">yadudoc1729@gmail.com</a>>, "swift-devel" <<a href="mailto:swift-devel@ci.uchicago.edu" target="_blank">swift-devel@ci.uchicago.edu</a>><br>
<br><br>Jon, yes, thats right. Can you add the info below to the User Guide, or if time is pressing, to the cookbook?<br><br>Thanks,<br><br>- Mike<br><br>----- Original Message -----<br>> From: "Jonathan Monette" <<a href="mailto:jonmon@mcs.anl.gov" target="_blank">jonmon@mcs.anl.gov</a>><br>
> To: "Michael Wilde" <<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>><br>> Cc: "Yadu Nand" <<a href="mailto:yadudoc1729@gmail.com" target="_blank">yadudoc1729@gmail.com</a>>, "swift-devel" <<a href="mailto:swift-devel@ci.uchicago.edu" target="_blank">swift-devel@ci.uchicago.edu</a>><br>
> Sent: Sunday, August 28, 2011 11:32:44 AM<br>> Subject: Re: [Swift-devel] MapReduce, doubts<br>> On Aug 28, 2011, at 10:15 AM, Michael Wilde wrote:<br>> <br>> > ----- Original Message -----<br>> >> From: "Yadu Nand" <<a href="mailto:yadudoc1729@gmail.com" target="_blank">yadudoc1729@gmail.com</a>><br>
> >> To: "swift-devel" <<a href="mailto:swift-devel@ci.uchicago.edu" target="_blank">swift-devel@ci.uchicago.edu</a>>, "Justin M Wozniak"<br>> >> <<a href="mailto:wozniak@mcs.anl.gov" target="_blank">wozniak@mcs.anl.gov</a>>, "Mihael Hategan"<br>
> >> <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>>, "Michael Wilde" <<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>><br>> >> Sent: Sunday, August 28, 2011 8:03:29 AM<br>
> >> Subject: MapReduce, doubts<br>> >> Hi,<br>> >><br>> >> I was going through some materials ([1], [2] , [3]) to understand<br>> >> Google's MapReduce system and I have a couple of queries :<br>
> >><br>> >> 1. How do we address the issue of data locality ?<br>> >> When we run a map job, it is a priority to run it such that least<br>> >> network overhead is incurred, so preferably on the same system<br>
> >> holding the data (or one which is nearest , I don't know how this<br>> >> works).<br>> ><br>> > Currently, we dont. We have discussed a new feature to do this (its<br>> > listed as a GSoC project and I can probably locate a discussion with<br>
> > a 2010 GSoC candidate in which I detailed a possible strategy).<br>> ><br>> > We can current implement a similar scheme using an external mapper<br>> > to select input files from multiple sites and map them to gsiftp<br>
> > URIs. Then an enhancement in the scheduler could select a site based<br>> > on the URI of some or all or the input files.<br>> <br>> In my work with GOSwift I found that mappers will follow the GSIURI<br>
> path.<br>> <br>> For a single file:<br>> file input1<br>> <“gsiftp://<a href="http://gridftp.pads.ci.uchicago.edu//gpfs/pads/swift/jonmon/data/input1.txt" target="_blank">gridftp.pads.ci.uchicago.edu//gpfs/pads/swift/jonmon/data/input1.txt</a>”>;<br>
> <br>> The above will map the file input1.txt that resides on PADS.<br>> <br>> For a group of files:<br>> file inputs[] <filesys_mapper; location =<br>> "gsiftp://<a href="http://gridftp.pads.ci.uchicago.edu//gpfs/pads/swift/jonmon/data" target="_blank">gridftp.pads.ci.uchicago.edu//gpfs/pads/swift/jonmon/data</a>”,<br>
> suffix=“.txt”>;<br>> <br>> The above will map all files with a ".txt" extension in the directory<br>> data on PADS.<br>> <br>> I think this is what you were talking about having the external mapper<br>
> do.<br>> <br>> ><br>> >> 2. Is it possible to somehow force the reduce tasks to wait till<br>> >> all<br>> >> map jobs are done ?<br>> ><br>> > Isn't that just normal swift semantics? If we coded a simple-minded<br>
> > reduce job whose input was the array of outputs from the map()<br>> > stage, the reduce (assuming its an app function) would wait for all<br>> > the map() ops to finish, right?<br>> ><br>> > I would ask instead "do we want to?". Do the distributed reduce ops<br>
> > in map-reduce really wait? Doesn't MR do distributed reduction in<br>> > batches, asynchronously to the completion of the map() operations?<br>> > Isnt this a key property that is made possible by the name/value<br>
> > pair-based nature of the MR data model? I thought MR reduce ops take<br>> > place at any location, in any input chunk size, in a tree-based<br>> > manner, and that this is possible because the reduction operator is<br>
> > "distributed" in the mathematical sense.<br>> ><br>> >> The MapReduce uses a system which permits reduce to run only<br>> >> after all the map jobs are done executing. I'm not entirely sure<br>
> >> why<br>> >> this is a requirement but this has its own issues, such as a single<br>> >> slow mapper. This is usually tackled by the main-controller<br>> >> noticing<br>> >> the slow one and running multiple instances of the map job to get<br>
> >> results faster. Does swift at some level use the concept of a<br>> >> central<br>> >> controller ? How do we tackle this ?<br>> >><br>> >> 3. How does swift handle failures ? Is there a facility for<br>
> >> re-execution ?<br>> ><br>> > Yes, Swift retries failing app invocations as controlled by the<br>> > properties execution.retries and lazy.errors. You can read on these<br>> > in the users guide and in the properties file.<br>
> ><br>> >> Is this documented somewhere ? Do we use any file-system that<br>> >> handles loss of a particular file /input-set ?<br>> ><br>> > No, we dont, but some of this would come with using a<br>
> > replication-based model for the input dataset where the mapper could<br>> > supply a list of possible inputs instead of one, and the scheduler<br>> > could pick a replica each time it selects a site for a (retried)<br>
> > job.<br>> ><br>> > Also, we might think of a "forMostOf" statement which could<br>> > implement semantics that would be suitable for runs in which you<br>> > dont need every single map() to complete. I.e. the target array can<br>
> > be considered closed when "most of" (tbd) the input collection had<br>> > been processed. The formost() could complete when it enters the<br>> > "tail" of the loop (see Tim Armstrong's paper on the tail<br>
> > phenomenon).<br>> <br>> I think this has been discussed before. In the Montage application<br>> there is a step where I map more filenames than will be created. So I<br>> don't need all the maps to complete for the workflow to keep<br>
> progressing. I made a workaround but I think this "forMostOf" feature<br>> would be useful. I will locate the thread in which Mihael and I had<br>> this discussion.<br>> ><br>> >> I'm stopping here, there are more questions nagging me, but its<br>
> >> probably best to not blurt it out all at once :)<br>> ><br>> > I think you are hitting the right issues here, and I encourage you<br>> > to keep pushing towards something that you could readily experiment<br>
> > with. This si exactly where we need to go to provide a convenient<br>> > method for expressing map-reduce as an elegant high-level script.<br>> ><br>> > I also encourage you to read on what Ed Walker did for map-reduce in<br>
> > his parallel shell.<br>> ><br>> > - Mike<br>> ><br>> >> [1] <a href="http://code.google.com/edu/parallel/mapreduce-tutorial.html" target="_blank">http://code.google.com/edu/parallel/mapreduce-tutorial.html</a><br>
> >> [2] <a href="http://www.youtube.com/watch?v=-vD6PUdf3Js" target="_blank">http://www.youtube.com/watch?v=-vD6PUdf3Js</a><br>> >> [3]<br>> >> <a href="http://code.google.com/edu/submissions/mapreduce-minilecture/listing.html" target="_blank">http://code.google.com/edu/submissions/mapreduce-minilecture/listing.html</a><br>
> >> --<br>> >> Thanks and Regards,<br>> >> Yadu Nand B<br>> ><br>> > --<br>> > Michael Wilde<br>> > Computation Institute, University of Chicago<br>> > Mathematics and Computer Science Division<br>
> > Argonne National Laboratory<br>> ><br>> > _______________________________________________<br>> > Swift-devel mailing list<br>> > <a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
> > <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br><br>-- <br>Michael Wilde<br>Computation Institute, University of Chicago<br>
Mathematics and Computer Science Division<br>Argonne National Laboratory<br><br><br><br></div></div><br>_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ketan<br><br><br>
</div>