Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates
 209.85.219.223 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Eh2/9sl9LmQlZK72kJt6jRIUKTCJfO4TbiAVq+sHW06sgMRP3fQ03XHtsXzRLcGbSa
         2HYXaqriFUhmw6IwPvmZPgSlPB4l/nFwy2ArgBvaddSYoKJWJ1wy72I61nN3gVOa7Ubw
         KajFCIQvLUWPo1mwuWsYtnZwv/ykmyW2uo2TA=
MIME-Version: 1.0
In-Reply-To: <f5f3a6290907282337t38e7028em82a1d879150fcfbf@mail.gmail.com>
References: <f5f3a6290907240123y22f065edp1649f7c5c1add491@mail.gmail.com>
	 <OFF7A9BC4F.A74D4FF4-ON882575FD.0056C4A0-882575FD.0058A694@us.ibm.com>
	 <e06563880907241000r5728a189g1b079921bea3b363@mail.gmail.com>
	 <f5f3a6290907282337t38e7028em82a1d879150fcfbf@mail.gmail.com>
Date: Thu, 30 Jul 2009 16:09:33 -0500
Message-ID: <e06563880907301409y3c4a1cffv59cdc2a87f568ae1@mail.gmail.com>
Subject: Re: hadoop tasks reading from cassandra
From: Jonathan Ellis <jbellis@gmail.com>
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Jul 29, 2009 at 1:37 AM, Jeff Hodges<jeff@somethingsimilar.com> wrote:
> Comments inline.
>
> On Fri, Jul 24, 2009 at 10:00 AM, Jonathan Ellis<jbellis@gmail.com> wrote:
>> On Fri, Jul 24, 2009 at 11:08 AM, Jun Rao<junrao@almaden.ibm.com> wrote:
>>> 1. In addition to OrderPreservingPartitioner, it would be useful to support
>>> MapReduce on RandomPartitioned Cassandra as well. We had a rough prototype
>>> that sort-of works at this moment. The difficulty with random partitioner
>>> is that it's a bit hard to generate the splits. In our prototype, we simply
>>> map each row to a split. This is ok for fat rows (e.g., a row includes all
>>> info for a user), but may be too fine-grained for other cases. Another
>>> possibility is to generate a split that corresponds to a set of rows in a
>>> hash-range (instead of key range). This requires some new apis in
>>> cassandra.
>>
>> -1 on adding new apis to pound a square peg into a round hole.
>>
>> like range queries, hadoop splits only really make sense on OPP.
>>
>
> Why would it only make sense on OPP? If it wasn't an externally
> exposed part of the api, what other concerns do you have about a hash
> range query? I can't think of any beyond the usual increased code
> complexity argument (i.e. development, testing and maintenance costs
> for it).

Because you have to violate encapsulation pretty badly and provide ops
acting on a hash instead of a key, so you'd be providing a parallel,
public api that only applies to the hash partitioner.

It's a bad enough hack that I'd say "feel free to maintain that in
your own tree, but not in the public repo." :)

> There is something in Hadoop that attempts to solve some of the data
> locality problem called NetworkTopology. It's used to provide data
> locality for CompileFileInputFormat (among, I'm sure, other things).
>
> Combining this with the knowledge we would have of which Node each key
> range would be from, there is a chance Hadoop could do some of the
> locality work for us. Looking at the code for CombineFileInputFormat,
> it doesn't seem to be particularly straightforward bit of work to
> translate to Cassandra, but I'm sure with a little time and maybe a
> little guidance from some Hadoop folks, we could make it happen.
>
> In any case, this seems to be evidence that locality can be added on
> later. It will not be a simple drop in deal, but it wouldn't seem to
> require us to completely overhaul how we think about the input
> splitting.

Jun mentioned #197 -- I'm still -1 on adding such a beast to the
thrift API, but I think it would be ok to expose it in
get_string_property, suitably (json?) encoded.

> (Oh, and has anyone got a mnemonic or anything to remember which of
> org.apache.hadoop.mapred and org.apache.hadoop.mapreduce is the new
> one? I'll be jiggered if I can keep it straight.)

mapreduce is the new one.  they got lucky and left the full name open
for their second try. :)

-Jonathan