crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Wills (JIRA)" <>
Subject [jira] [Commented] (CRUNCH-211) Add one-to-many join functionality
Date Sun, 02 Jun 2013 16:51:20 GMT


Josh Wills commented on CRUNCH-211:

Nah, I'm on board with it-- especially if it provides a way for folks to do the "right thing"
(i.e., one MR job) instead of two (one to do the aggregation over the large collection and
a second job to do the join).

+1, but please remove the extra java.lang.* and org.apache.crunch.* names in the OneToManyDoFn.
> Add one-to-many join functionality
> ----------------------------------
>                 Key: CRUNCH-211
>                 URL:
>             Project: Crunch
>          Issue Type: Bug
>            Reporter: Gabriel Reid
>         Attachments: CRUNCH-211.patch
> A common pattern is a join between two tables where the left-side table contains a single
value per key, and the right-side table contains multiple values per key. An example of such
a join would be a join between users and web click entries:
>     PTable<Long,User> usersById = ...;
>     PTable<Long,WebClick> webClicksByUserId = ...;
> In this case, there can be some situations where it is desirable to bring the User together
with the iterable of all WebClicks. The current join functionality will replicate the User
for each WebClick that it's related to, but each WebClick then needs to be dealt with completely
> Currently, the only way of getting an iterable of WebClicks together with a single User
in a single method call is by materializing all WebClicks per user in memory using something
like PTable#collectValues, and this approach doesn't work when there are a large number of
> The intention of this ticket is to add functionality whereby the User and Iterable of
WebClicks are available in a single method call, without the Iterable of WebClicks being materialized
in memory (i.e. a feasible approach for millions or more WebClicks).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message