So, continuing this discussion further, I've been working on getting the application running under Swift on the Cornell's Redcloud infrastructure. It works and seems to be as fast as Hadoop but I have not yet done any measurements.<div>
<br></div><div>Application has 2 stages: for n first stage (~map) instances there is one second (and final) stage (~reduce) instance.</div><div><br></div><div>Currently running this app under Coaster setup from a local workstation; I see that there are unnecessary (from app point of view) data movements involved.</div>
<div><br></div><div>In the first stage, n datasets are staged out to n cloud VMs to perform the computation which is followed by staging in of the results of this stage back to the submit host. This is followed by staging out of these results back to a single cloud VM to perform the final stage.</div>
<div><br></div><div>Can we tell Swift to:</div><div><br></div><div>1. Do not stage back the data at the end of first stage but keep it on the respective VMs on cloud.</div><div>2. Predesignate a VM (with an IP) to perform the reduce step and as soon as first step is over, stage the result of this step to that predesignated VM.</div>
<div><br></div><div>I think, if we have some way of marking an app as "map" or "reduce" kind and a way of telling Swift if we care for intermediate results, this could be easy to achieve.</div><div><br>
</div><div>Wondering if there is some configuration that already does this today? I think 2 can be achieved with site and tc settings may be.</div><div><br></div><div><br></div><div>Regards,</div><div>Ketan</div><div><br>
<div class="gmail_quote">On Mon, May 14, 2012 at 8:54 PM, Ketan Maheshwari <span dir="ltr"><<a href="mailto:ketancmaheshwari@gmail.com" target="_blank">ketancmaheshwari@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tim,<div><br></div><div>From your description and my limited experience (~3 weeks) with Hadoop, I want to say that the differences between Hadoop and Swift are really "soft" ones. I have a feeling that since MapReduce happened to be used for internet scale/style reliability, Hadoop developers developed tools that you described (compression, checksum, serialization, etc.) around it.</div>
<div><br></div><div>I want to think that Swift is in a sense superset of Hadoop or Hadoop+ in that it essentially provides the same or similar functionality as one would expect out of Hadoop with an added advantage of having an ability to express the computation as a chained stages.</div>
<div><br></div><div>I do not really think the argument of running either on reliable or unreliable systems really holds, since, Swift could be easily adapted to unreliable systems by building functionalities (eg. data replication) around it.</div>
<div><br></div><div>In another sense, I want to think Hadoop and Swift as tools solving same class of problems with a huge overlap between them among functionalities and only the extra 'muscles' bit which makes them different.</div>
<div><br></div><div>From a user's point of view, I still think Hadoop is difficult to setup and work with on medium sized applications (tens to hundreds of tasks). In terms of application performance, I want to think, it depends on how good a job one does tuning Hadoop and/or Swift for the application and infrastructure at hand. This particular thing, I am in the process of doing and soon will come up with some concrete numbers.</div>
<div><br></div><div>Regards,</div><div>Ketan </div><div><div><div class="h5"><br><div class="gmail_quote">On Mon, May 14, 2012 at 5:15 PM, Tim Armstrong <span dir="ltr"><<a href="mailto:tim.g.armstrong@gmail.com" target="_blank">tim.g.armstrong@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be clear, I'm not making the case that it's <i>impossible</i> to
implement things in Swift that are implemented in MapReduce, just that
Swift isn't well suited to them, because it wasn't designed with them in
mind. I've seen the argument before that MapReduce is a particular
data flow DAG, and that you can express arbitrary data flow DAGs in
other systems, but I think that somewhat misses the point of what
MapReduce is trying to provide to application developers. By treating
all tasks and data dependencies as equivalent, it ignores all of the
runtime infrastructure that MapReduce inserts into the processes, and
ignores, for example, some of the details of how data is moved between mappers and
reducers.<br>
<br>
For example, a substantial amount of code in the Hadoop MapReduce code
base has to do with a) file formats b) compression c) checksums d) serialization e) buffering input and output data and f) bucketing/sorting the data. This is all difficult to implement well
and important for many big data applications. I think that scientific workflow systems don't take any of these things seriously since it isn't important for most canonical scientific workflow applications.<br><br>
I think one of the other big differences is that Hadoop assumes that all you have are a bunch of unreliable machines on a network, so that it must provide its own a job scheduler and replicated distributed file system. Swift, in contrast, seems mostly designed for systems where there is a reliable shared file system, and where it acquires compute resources for a fixed blocks of time from some existing cluster manager. I know there are ways you can have Swift/Coaster/Falkon run on networks of unreliable machines, but it's not quite like Hadoop's job scheduler which is designed to actually be the primary submission mechanism for a multi-user cluster.<br>
<br>I don't think it would make much sense to run Swift on a network of unreliable machines and then to just leave your data on those machines (you would normally stage the final data to some backed-up file system), but it would make perfect sense for Hadoop, especially if the data is so big that it's difficult to find someplace else to put it. In contrast, you can certainly stand up a Hadoop instance on a shared cluster for a few hours to run your jobs, and stage data in and out of HDFS, but that use case isn't what Hadoop was designed or optimized for. Most of the core developers on Hadoop are working in environments where they have devoted Hadoop clusters, where they can't afford much cluster downtime and where they need to reliably persist huge amounts of data for years on unreliable hardware. E.g. at the extreme end, this is the kind of thing Hadoop developers are thinking about: <a href="https://www.facebook.com/notes/paul-yang/moving-an-elephant-large-scale-hadoop-data-migration-at-facebook/10150246275318920" target="_blank">https://www.facebook.com/notes/paul-yang/moving-an-elephant-large-scale-hadoop-data-migration-at-facebook/10150246275318920</a><span><font color="#888888"><br>
<br>- Tim</font></span><div><div><br><br><br><div class="gmail_quote">On Sun, May 13, 2012 at 3:57 PM, Ioan Raicu <span dir="ltr"><<a href="mailto:iraicu@cs.iit.edu" target="_blank">iraicu@cs.iit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div>Hi Tim,</div><div>I always thought of MapReduce being a subset of workflow systems. Can you give me an example of an application that can be implemented in MapReduce, but not a workflow system such as Swift? I can't think of any off the top of my head. <div>
<br><br><div><span>Ioan</span></div><div><br></div><div>-- </div><div>=================================================================</div><div>Ioan Raicu, Ph.D.</div><div>Assistant Professor</div><div>=================================================================</div>
<div>Computer Science Department</div><div>Illinois Institute of Technology</div><div>10 W. 31st Street Chicago, IL 60616 =================================================================</div><div>Cel: <a href="tel:1-847-722-0876" value="+18477220876" target="_blank">1-847-722-0876</a></div>
<div>Email: <a href="mailto:iraicu@cs.iit.edu" target="_blank">iraicu@cs.iit.edu</a></div><div>Web: <a href="http://www.cs.iit.edu/%7Eiraicu/" target="_blank">http://www.cs.iit.edu/~iraicu/</a></div><div>=================================================================</div>
<div>=================================================================</div><div><br></div><div><br></div></div></div><div><div><div><br>On May 13, 2012, at 1:09 PM, Tim Armstrong <<a href="mailto:tim.g.armstrong@gmail.com" target="_blank">tim.g.armstrong@gmail.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div>I've worked on both Swift and Hadoop implementations and my tendency is to say that there isn't actually any deep similarity beyond them both supporting distributed data processing/computation. They both make fundamentally different assumptions about the clusters they run on and the applications they're supporting.<br>
<br>Swift is mainly designed for time-shared clusters with reliable shared file systems. Hadoop assumes that it will be running on unreliable commodity machines with no shared file system, and will be running continuously on all machines on the cluster. Swift is designed for orchestrating existing executables with their own file formats, so mostly remains agnostic to the contents of the files it is processing. Hadoop needs to have some understanding of the contents of the files it is processing, to be able to segment them into records and perform key comparisons so it can do a distributed sort, etc. It provides its own file formats (including compression, serialization, etc) that users can use, although is extensible to custom file formats. <br>
<ul><li>Hadoop implements its own distributed file-system with software redundancy, Swift uses an existing cluster filesystem or node-local file systems. For bulk data processing, this means Hadoop will generally be able to deliver more disk bandwidth and has a bunch of other implications.<br>
</li><li>Hadoop has a record-oriented view of the world, i.e. it is built around the idea that you are processing a record at at time, rather than a file at a time as in Swift</li><li>As a result, Hadoop includes a bunch of functionality to do with file formats, compression, serialization etc: Swift is B.Y.O. file format<br>
</li><li>Hadoop's distributed sort is a core part of the MapReduce (and something that a lot of effort has gone into implementing and optimizing), Swift doesn't have built-in support for anything similar<br></li>
<li>
Swift lets you construct arbitrary dataflow graphs between tasks, so in some ways is less restrictive than the map-reduce pattern (although it doesn't directly support some things that the map-reduce pattern does, so I wouldn't say that it is strictly more general)</li>
</ul><p> I'd say that some applications might fit in both paradigms, but that
neither supports a superset of the applications that the other supports. Performance would depend to a large extent on the application. Swift might actually be quicker to start up a job and dispatch tasks (Hadoop is notoriously slow on that front), but otherwise I'd say it just depends on the application, how you implement the application, the cluster, etc. I'm not sure that there is a fair comparison between the two systems since they're just very different: most of the results would be predictable just be looking at the design of the system (e.g. if the application needs to do a big distributed sort, Hadoop is much better) . If the application is embarrassingly parallel (like it sounds like your application is), then you could probably implement it in either, but I'm not sure that it would actually stress the differences between the systems if data sizes are small and runtime is mostly dominated by computation.<br>
</p>I think the Cloudera Hadoop distribution is well documented reasonably easy to set up and run, provided that you're not on a time-shared cluster. Apache Hadoop is more of a pain to get working.<br><br>- Tim<br><br>
<br><div class="gmail_quote">On Sun, May 13, 2012 at 9:27 AM, Ketan Maheshwari <span dir="ltr"><<a href="mailto:ketancmaheshwari@gmail.com" target="_blank">ketancmaheshwari@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<div><br></div><div>We are working on a project from GE Energy corporation which runs independent MonteCarlo simulations in order to find device reliability leading to a power grid wise device replacement decisions. The computation is repeated MC simulations done in parallel.</div>
<div><div><br></div><div>Currently, this is running under Hadoop setup on Cornell Redcloud and EC2 (10 nodes). Looking at the computation, it struck me this is a good Swift candidate. And since the performance numbers etc are already extracted for Hadoop, it might also be nice to have a comparison between Swift and Hadoop.</div>
<div><br></div><div>However, some reality check before diving in: has it been done before? Do we know how Swift fares against map-reduce? Are they even comparable? I have faced this question twice here: Why use Swift when you have Hadoop?</div>
<div><br></div><div>I could see Hadoop needs quite a bit of setup effort before getting it to run. Could we quantify usability and compare the two?</div><div><br></div><div>Any ideas and inputs are welcome.</div><div><br>
</div><div>Regards,</div><span><font color="#888888">-- <br><font face="'courier new', monospace">Ketan</font><br><br><br>
</font></span></div>
<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></blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Swift-devel mailing list</span><br><span><a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a></span><br>
<span><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></span><br></div></blockquote></div></div></div></blockquote>
</div><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><font face="'courier new', monospace">Ketan</font><br><br><br>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="'courier new', monospace">Ketan</font><br><br><br>
</div>