JavaSpaces (Blitz?) and hadoop - comparison?

[Tomi N/A <he...@gmail.com>]

I just came across a technology which sounded interesting, but doesn't
seem very wide spread called JavaSpaces. An implementation is Blitz
(http://www.dancres.org/blitz/).

>From what I see, it seems to be a distributed computation and
persistence engine so it made me wonder if anyone on this list would
know anything about it and, maybe, compare the two technologies. Well?
:)

Cheers,
t.n.a.

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Torsten Curdt <tc...@apache.org>]

>> In a data center there are typically 5 chubby instances and
>> their locations are stored in DNS. A client reads their location from
>> DNS and then traverses them to locate the Chubby master. After
>> [snipped the rest]
>
> This manual configuration in Hadoop was a limitation I noticed  
> first thing and have suggested Zeroconf (dynamic multicast central- 
> server-optional service-discovering DNS) as a solution.

I would loooooove to see that happen!

cheers
--
Torsten

Initial number of Maps on the machine

[심탁길 <10...@nhncorp.com>]

When I run Simple MR Job such as grep (about 200Maps & 4 Reduces) with 20 Opeteron Servers ( 2Way Dual-Core, 4GB RAM)

Only 2 maps are instatantiated on one machine and each map task takes 5~6 seconds to be done.  

As a result, about 50% CPU is unsed during the MR Job and the overall performance is not that good as I expected 

Configuration "mapred.tasktracker.tasks.maximum ==> 10", It only works when each map tasks last more than 10 seconds

It seemds that Hadoop framework starts MR job with the limit of 2 maps on one machine.  

When running two similar MR Jobs concurrently, the number of maps on one machine is still 2 and CPU usage is about 50% and each MR Jobs takes almost 2times longer to be done.

Then, How can I change the initial limit of map's count on the machine ?

 

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Dan Creswell <da...@lonecrusader.co.uk>]

Alan D. Cabrera wrote:
>
> On Mar 2, 2007, at 5:06 AM, Jim White wrote:
>
>> Doğacan Güney wrote:
>>
>>> On 3/2/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
>>>> Nigel Daley wrote:
>>>> > One more difference...
>>>> > ,,,
>>>> > OTOH, Hadoop servers and clients are currently pre-configured with
>>>> > necessary host/ports.
>>>> >
>>>> Indeed - I was toying with doing something about removing this
>>>> pre-configuration - worthwhile?
>>> ...
>>> In a data center there are typically 5 chubby instances and
>>> their locations are stored in DNS. A client reads their location from
>>> DNS and then traverses them to locate the Chubby master. After
>>> [snipped the rest]
>>
>> This manual configuration in Hadoop was a limitation I noticed first
>> thing and have suggested Zeroconf (dynamic multicast
>> central-server-optional service-discovering DNS) as a solution.
>>
>> http://www.zeroconf.org/
>>
>> I've haven't looked into the details yet, but it is clear to me that
>> DNS Service Discovery would work dandy for implementing auto
>> configuration for Hadoop.
>>
>> http://www.dns-sd.org/
>>
>> Multicast also has good potential to enhance Hadoop networking
>> performance, but that is a separate issue.
>>
>> And for those concerned that Zeroconf is something exotic, it turns
>> out Amazon EC2 is already using it for the parameterized launch. 
>> That's where the funny "169.254.169.254" address comes from.
>>
>> http://docs.amazonwebservices.com/AmazonEC2/dg/2006-10-01/TechnicalFAQ.html#d0e14061
>>
>>
>> A few notes I've collected on Zeroconf:
>>
>> http://www.ifcx.org/wiki/LocalNetworking.html
>
> There's another protocol that is similar called Service Location
> Protocol, SLP.  Thoughts?
>

Looks an awful lot like the Jini service location protocol - seems like
it got published out of Sun in a similar timeframe too.

I'm somewhat biased but I'd be looking at SLP and/or Jini although
ZeroConf might be a quicker initial hack.  Not sure whether ZeroConf'd
be the right solution over the long term or with larger clusters -
anybody got experience there?

Dan.

Re: JavaSpaces (Blitz?) and hadoop - comparison?

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Mar 2, 2007, at 5:06 AM, Jim White wrote:

> Doğacan Güney wrote:
>
>> On 3/2/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
>>> Nigel Daley wrote:
>>> > One more difference...
>>> > ,,,
>>> > OTOH, Hadoop servers and clients are currently pre-configured with
>>> > necessary host/ports.
>>> >
>>> Indeed - I was toying with doing something about removing this
>>> pre-configuration - worthwhile?
>> ...
>> In a data center there are typically 5 chubby instances and
>> their locations are stored in DNS. A client reads their location from
>> DNS and then traverses them to locate the Chubby master. After
>> [snipped the rest]
>
> This manual configuration in Hadoop was a limitation I noticed  
> first thing and have suggested Zeroconf (dynamic multicast central- 
> server-optional service-discovering DNS) as a solution.
>
> http://www.zeroconf.org/
>
> I've haven't looked into the details yet, but it is clear to me  
> that DNS Service Discovery would work dandy for implementing auto  
> configuration for Hadoop.
>
> http://www.dns-sd.org/
>
> Multicast also has good potential to enhance Hadoop networking  
> performance, but that is a separate issue.
>
> And for those concerned that Zeroconf is something exotic, it turns  
> out Amazon EC2 is already using it for the parameterized launch.   
> That's where the funny "169.254.169.254" address comes from.
>
> http://docs.amazonwebservices.com/AmazonEC2/dg/2006-10-01/ 
> TechnicalFAQ.html#d0e14061
>
> A few notes I've collected on Zeroconf:
>
> http://www.ifcx.org/wiki/LocalNetworking.html

There's another protocol that is similar called Service Location  
Protocol, SLP.  Thoughts?


Regards,
Alan

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Jim White <ji...@pagesmiths.com>]

Doğacan Güney wrote:

> On 3/2/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
> 
>> Nigel Daley wrote:
>> > One more difference...
>> > ,,,
>> > OTOH, Hadoop servers and clients are currently pre-configured with
>> > necessary host/ports.
>> >
>> Indeed - I was toying with doing something about removing this
>> pre-configuration - worthwhile?
> 
> ...
> In a data center there are typically 5 chubby instances and
> their locations are stored in DNS. A client reads their location from
> DNS and then traverses them to locate the Chubby master. After
> [snipped the rest]

This manual configuration in Hadoop was a limitation I noticed first 
thing and have suggested Zeroconf (dynamic multicast 
central-server-optional service-discovering DNS) as a solution.

http://www.zeroconf.org/

I've haven't looked into the details yet, but it is clear to me that DNS 
Service Discovery would work dandy for implementing auto configuration 
for Hadoop.

http://www.dns-sd.org/

Multicast also has good potential to enhance Hadoop networking 
performance, but that is a separate issue.

And for those concerned that Zeroconf is something exotic, it turns out 
Amazon EC2 is already using it for the parameterized launch.  That's 
where the funny "169.254.169.254" address comes from.

http://docs.amazonwebservices.com/AmazonEC2/dg/2006-10-01/TechnicalFAQ.html#d0e14061

A few notes I've collected on Zeroconf:

http://www.ifcx.org/wiki/LocalNetworking.html

Jim

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Doğacan Güney <do...@gmail.com>]

Hi,

On 3/2/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
> Nigel Daley wrote:
> > One more difference...
> >
> > Being that JavaSpaces is a Jini service, its host/port can be
> > dynamically discovered (and rediscovered else where if it fails) at
> > run time by clients.
> > OTOH, Hadoop servers and clients are currently pre-configured with
> > necessary host/ports.
> >
> Indeed - I was toying with doing something about removing this
> pre-configuration - worthwhile?

Here is a description of how Google does this (As far as I understand
it) (Everyone here probably knows this but anyway). Google uses Chubby
to locate GFS and Bigtable masters (also probably jobtracker master
too). In a data center there are typically 5 chubby instances and
their locations are stored in DNS. A client reads their location from
DNS and then traverses them to locate the Chubby master. After
locating it, the client reads a predefined file in Chubby to locate
the GFS/Bigtable/MR master. If, say, a GFS namenode dies, a GFS
datanode becomes the namenode and updates the file in Chubby. If the
Chubby master dies, a Chubby slave becomes the master.  If a client
tries to connect to the old Chubby master, the connection will timeout
and client will retraverse all Chubby instances to find out which is
the master.

[snipped the rest]

-- 
Doğacan Güney

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Dan Creswell <da...@lonecrusader.co.uk>]

Nigel Daley wrote:
> One more difference...
>
> Being that JavaSpaces is a Jini service, its host/port can be
> dynamically discovered (and rediscovered else where if it fails) at
> run time by clients.
> OTOH, Hadoop servers and clients are currently pre-configured with
> necessary host/ports.
>
Indeed - I was toying with doing something about removing this
pre-configuration - worthwhile?

Dan.

> Nige
>
> On Mar 1, 2007, at 6:00 AM, Dan Creswell wrote:
>
>> Tom White wrote:
>>> Good question. JavaSpaces is actually very general, so I would ask how
>>> the Replicated Worker Pattern, which is fits nicely with JavaSpaces
>>> (http://today.java.net/pub/a/today/2005/04/21/farm.html,
>>> https://computeserver.dev.java.net/) compares with Hadoop and
>>> MapReduce.
>>>
>>> My take is that at a high level JavaSpaces RWP is good for
>>> distributing jobs that don't operate on large datasets whereas Hadoop
>>> (MapReduce) is good for operating on very large datasets. JavaSpaces
>>> doesn't really have mechanisms for distributing large quantities of
>>> data in the way that HDFS does. On the other hand, JavaSpaces is good
>> Indeed JavaSpaces doesn't provide support for shipping around large
>> quantities of data however I wouldn't usually pass this kind of data
>> through the JavaSpace, I pass a reference to those chunks of data.
>>
>> This reference can be to some filesystem or another, an http or ftp
>> URI etc.
>>
>> In loose terms I'd use the JavaSpace to co-ordinate the MapReduce effort
>> whilst having some other infrastructure element handle the
>> access/distribution of data (which I guess could be HDFS?)
>>
>> I'm not sure if, under the covers, Hadoop doesn't have a similar
>> division of responsibility for co-ordination and data-distribution?
>>> for sharing modest sized data objects - with MapReduce you are sharing
>>> data, so you have to think carefully how to encode the data that the
>>> map and reduce tasks operate on. JavaSpaces in general allows you a
>>> richer computational model (compared to MapReduce) - but this
>>> generality comes at the price of being able to perform well for
>>> certain classes of application.
>>>
>> Based on what I say above, I'd refine this statement and say if you want
>> to use JavaSpaces alone to solve the entire problem it may not perform
>> well but if you use JavaSpaces as part of a complete solution it will
>> perform pretty well.
>>> Put another way: JavaSpaces RWP is a good fit for writing a program to
>>> calculate if a large number is prime (since the subtasks don't need to
>>> use much intermediate data), whereas Hadoop MapReduce is a good fit
>>> for counting web server access hits by host (since the object is to
>>> analyse a large set of data).
>>>
>>> (I think they're both great pieces of technology BTW.)
>>>
>> Me too!
>>
>> Dan.
>>
>>> Tom
>>>
>>> On 01/03/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
>>>> Hi,
>>>>
>>>> I'm the author of Blitz as it happens :)
>>>>
>>>> Blitz has various different modes of operation.  It can be persistent
>>>> but also can operate in "memory-only" configuration.
>>>>
>>>> The basic difference would be that Blitz is just a core element around
>>>> which you could build a MapReduce implementation (in fact I have
>>>> done in
>>>> the past) etc. Hadoop by contrast has a core of it's own based on a
>>>> GFS
>>>> equivalent and also includes the framework for MapReduce etc.
>>>>
>>>> In conclusion, Blitz provides the base of a stack and Hadoop has that
>>>> base (in another form) plus additional layers (MapReduce etc).
>>>>
>>>> Hope that helps,
>>>>
>>>> Dan.
>>>>
>>>> Tomi N/A wrote:
>>>>> I just came across a technology which sounded interesting, but
>>>>> doesn't
>>>>> seem very wide spread called JavaSpaces. An implementation is Blitz
>>>>> (http://www.dancres.org/blitz/).
>>>>>
>>>>>> From what I see, it seems to be a distributed computation and
>>>>> persistence engine so it made me wonder if anyone on this list would
>>>>> know anything about it and, maybe, compare the two technologies.
>>>>> Well?
>>>>> :)
>>>>>
>>>>> Cheers,
>>>>> t.n.a.
>>>>>
>>>>
>>>>
>>>
>>
>
>

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Nigel Daley <nd...@yahoo-inc.com>]

One more difference...

Being that JavaSpaces is a Jini service, its host/port can be  
dynamically discovered (and rediscovered else where if it fails) at  
run time by clients.
OTOH, Hadoop servers and clients are currently pre-configured with  
necessary host/ports.

Nige

On Mar 1, 2007, at 6:00 AM, Dan Creswell wrote:

> Tom White wrote:
>> Good question. JavaSpaces is actually very general, so I would ask  
>> how
>> the Replicated Worker Pattern, which is fits nicely with JavaSpaces
>> (http://today.java.net/pub/a/today/2005/04/21/farm.html,
>> https://computeserver.dev.java.net/) compares with Hadoop and
>> MapReduce.
>>
>> My take is that at a high level JavaSpaces RWP is good for
>> distributing jobs that don't operate on large datasets whereas Hadoop
>> (MapReduce) is good for operating on very large datasets. JavaSpaces
>> doesn't really have mechanisms for distributing large quantities of
>> data in the way that HDFS does. On the other hand, JavaSpaces is good
> Indeed JavaSpaces doesn't provide support for shipping around large
> quantities of data however I wouldn't usually pass this kind of data
> through the JavaSpace, I pass a reference to those chunks of data.
>
> This reference can be to some filesystem or another, an http or ftp  
> URI etc.
>
> In loose terms I'd use the JavaSpace to co-ordinate the MapReduce  
> effort
> whilst having some other infrastructure element handle the
> access/distribution of data (which I guess could be HDFS?)
>
> I'm not sure if, under the covers, Hadoop doesn't have a similar
> division of responsibility for co-ordination and data-distribution?
>> for sharing modest sized data objects - with MapReduce you are  
>> sharing
>> data, so you have to think carefully how to encode the data that the
>> map and reduce tasks operate on. JavaSpaces in general allows you a
>> richer computational model (compared to MapReduce) - but this
>> generality comes at the price of being able to perform well for
>> certain classes of application.
>>
> Based on what I say above, I'd refine this statement and say if you  
> want
> to use JavaSpaces alone to solve the entire problem it may not perform
> well but if you use JavaSpaces as part of a complete solution it will
> perform pretty well.
>> Put another way: JavaSpaces RWP is a good fit for writing a  
>> program to
>> calculate if a large number is prime (since the subtasks don't  
>> need to
>> use much intermediate data), whereas Hadoop MapReduce is a good fit
>> for counting web server access hits by host (since the object is to
>> analyse a large set of data).
>>
>> (I think they're both great pieces of technology BTW.)
>>
> Me too!
>
> Dan.
>
>> Tom
>>
>> On 01/03/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
>>> Hi,
>>>
>>> I'm the author of Blitz as it happens :)
>>>
>>> Blitz has various different modes of operation.  It can be  
>>> persistent
>>> but also can operate in "memory-only" configuration.
>>>
>>> The basic difference would be that Blitz is just a core element  
>>> around
>>> which you could build a MapReduce implementation (in fact I have  
>>> done in
>>> the past) etc. Hadoop by contrast has a core of it's own based on  
>>> a GFS
>>> equivalent and also includes the framework for MapReduce etc.
>>>
>>> In conclusion, Blitz provides the base of a stack and Hadoop has  
>>> that
>>> base (in another form) plus additional layers (MapReduce etc).
>>>
>>> Hope that helps,
>>>
>>> Dan.
>>>
>>> Tomi N/A wrote:
>>>> I just came across a technology which sounded interesting, but  
>>>> doesn't
>>>> seem very wide spread called JavaSpaces. An implementation is Blitz
>>>> (http://www.dancres.org/blitz/).
>>>>
>>>>> From what I see, it seems to be a distributed computation and
>>>> persistence engine so it made me wonder if anyone on this list  
>>>> would
>>>> know anything about it and, maybe, compare the two technologies.  
>>>> Well?
>>>> :)
>>>>
>>>> Cheers,
>>>> t.n.a.
>>>>
>>>
>>>
>>
>

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Dan Creswell <da...@lonecrusader.co.uk>]

Tom White wrote:
> Good question. JavaSpaces is actually very general, so I would ask how
> the Replicated Worker Pattern, which is fits nicely with JavaSpaces
> (http://today.java.net/pub/a/today/2005/04/21/farm.html,
> https://computeserver.dev.java.net/) compares with Hadoop and
> MapReduce.
>
> My take is that at a high level JavaSpaces RWP is good for
> distributing jobs that don't operate on large datasets whereas Hadoop
> (MapReduce) is good for operating on very large datasets. JavaSpaces
> doesn't really have mechanisms for distributing large quantities of
> data in the way that HDFS does. On the other hand, JavaSpaces is good
Indeed JavaSpaces doesn't provide support for shipping around large
quantities of data however I wouldn't usually pass this kind of data
through the JavaSpace, I pass a reference to those chunks of data.

This reference can be to some filesystem or another, an http or ftp URI etc.

In loose terms I'd use the JavaSpace to co-ordinate the MapReduce effort
whilst having some other infrastructure element handle the
access/distribution of data (which I guess could be HDFS?)

I'm not sure if, under the covers, Hadoop doesn't have a similar
division of responsibility for co-ordination and data-distribution?
> for sharing modest sized data objects - with MapReduce you are sharing
> data, so you have to think carefully how to encode the data that the
> map and reduce tasks operate on. JavaSpaces in general allows you a
> richer computational model (compared to MapReduce) - but this
> generality comes at the price of being able to perform well for
> certain classes of application.
>
Based on what I say above, I'd refine this statement and say if you want
to use JavaSpaces alone to solve the entire problem it may not perform
well but if you use JavaSpaces as part of a complete solution it will
perform pretty well.
> Put another way: JavaSpaces RWP is a good fit for writing a program to
> calculate if a large number is prime (since the subtasks don't need to
> use much intermediate data), whereas Hadoop MapReduce is a good fit
> for counting web server access hits by host (since the object is to
> analyse a large set of data).
>
> (I think they're both great pieces of technology BTW.)
>
Me too!

Dan.

> Tom
>
> On 01/03/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
>> Hi,
>>
>> I'm the author of Blitz as it happens :)
>>
>> Blitz has various different modes of operation.  It can be persistent
>> but also can operate in "memory-only" configuration.
>>
>> The basic difference would be that Blitz is just a core element around
>> which you could build a MapReduce implementation (in fact I have done in
>> the past) etc. Hadoop by contrast has a core of it's own based on a GFS
>> equivalent and also includes the framework for MapReduce etc.
>>
>> In conclusion, Blitz provides the base of a stack and Hadoop has that
>> base (in another form) plus additional layers (MapReduce etc).
>>
>> Hope that helps,
>>
>> Dan.
>>
>> Tomi N/A wrote:
>> > I just came across a technology which sounded interesting, but doesn't
>> > seem very wide spread called JavaSpaces. An implementation is Blitz
>> > (http://www.dancres.org/blitz/).
>> >
>> >> From what I see, it seems to be a distributed computation and
>> > persistence engine so it made me wonder if anyone on this list would
>> > know anything about it and, maybe, compare the two technologies. Well?
>> > :)
>> >
>> > Cheers,
>> > t.n.a.
>> >
>>
>>
>

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Tomi N/A <he...@gmail.com>]

Thanks everyone,

I get the general idea. Hope your explanations interested others, as well.
I was always interested in distributed processing so asking a question
about the general trade-offs between the two technologies was kind of
a reflex for me. :)

Cheers,
t.n.a.

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Tom White <to...@gmail.com>]

Good question. JavaSpaces is actually very general, so I would ask how
the Replicated Worker Pattern, which is fits nicely with JavaSpaces
(http://today.java.net/pub/a/today/2005/04/21/farm.html,
https://computeserver.dev.java.net/) compares with Hadoop and
MapReduce.

My take is that at a high level JavaSpaces RWP is good for
distributing jobs that don't operate on large datasets whereas Hadoop
(MapReduce) is good for operating on very large datasets. JavaSpaces
doesn't really have mechanisms for distributing large quantities of
data in the way that HDFS does. On the other hand, JavaSpaces is good
for sharing modest sized data objects - with MapReduce you are sharing
data, so you have to think carefully how to encode the data that the
map and reduce tasks operate on. JavaSpaces in general allows you a
richer computational model (compared to MapReduce) - but this
generality comes at the price of being able to perform well for
certain classes of application.

Put another way: JavaSpaces RWP is a good fit for writing a program to
calculate if a large number is prime (since the subtasks don't need to
use much intermediate data), whereas Hadoop MapReduce is a good fit
for counting web server access hits by host (since the object is to
analyse a large set of data).

(I think they're both great pieces of technology BTW.)

Tom

On 01/03/07, Dan Creswell <da...@lonecrusader.co.uk> wrote:
> Hi,
>
> I'm the author of Blitz as it happens :)
>
> Blitz has various different modes of operation.  It can be persistent
> but also can operate in "memory-only" configuration.
>
> The basic difference would be that Blitz is just a core element around
> which you could build a MapReduce implementation (in fact I have done in
> the past) etc. Hadoop by contrast has a core of it's own based on a GFS
> equivalent and also includes the framework for MapReduce etc.
>
> In conclusion, Blitz provides the base of a stack and Hadoop has that
> base (in another form) plus additional layers (MapReduce etc).
>
> Hope that helps,
>
> Dan.
>
> Tomi N/A wrote:
> > I just came across a technology which sounded interesting, but doesn't
> > seem very wide spread called JavaSpaces. An implementation is Blitz
> > (http://www.dancres.org/blitz/).
> >
> >> From what I see, it seems to be a distributed computation and
> > persistence engine so it made me wonder if anyone on this list would
> > know anything about it and, maybe, compare the two technologies. Well?
> > :)
> >
> > Cheers,
> > t.n.a.
> >
>
>

Re: JavaSpaces (Blitz?) and hadoop - comparison?

[Dan Creswell <da...@lonecrusader.co.uk>]

Hi,

I'm the author of Blitz as it happens :)

Blitz has various different modes of operation.  It can be persistent
but also can operate in "memory-only" configuration.

The basic difference would be that Blitz is just a core element around
which you could build a MapReduce implementation (in fact I have done in
the past) etc. Hadoop by contrast has a core of it's own based on a GFS
equivalent and also includes the framework for MapReduce etc.

In conclusion, Blitz provides the base of a stack and Hadoop has that
base (in another form) plus additional layers (MapReduce etc).

Hope that helps,

Dan.

Tomi N/A wrote:
> I just came across a technology which sounded interesting, but doesn't
> seem very wide spread called JavaSpaces. An implementation is Blitz
> (http://www.dancres.org/blitz/).
>
>> From what I see, it seems to be a distributed computation and
> persistence engine so it made me wonder if anyone on this list would
> know anything about it and, maybe, compare the two technologies. Well?
> :)
>
> Cheers,
> t.n.a.
>