[
https://issues.apache.org/jira/browse/CRUNCH-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679553#comment-13679553
]
Josh Wills commented on CRUNCH-215:
-----------------------------------
My thought was that we would want it for MSCR fusion, since we could take
multiple groupByKey operations over the same dataset and map them all to a
PTable<Pair<Integer, ByteBuffer>, ByteBuffer> (or the logical equivalent) in
the MSCRPlanner class, and then undo the byte mapping on the reduce side and
continue on our merry way. There would be restrictions on our ability to do
this (e.g., we couldn't do it for joins or other jobs that need custom
partitioners/sorts), but I think it would still be generally useful.
Again, not necessary for this JIRA, but we should keep it in mind for the
future.
> Add BloomFilterJoinStrategy
> ---------------------------
>
> Key: CRUNCH-215
> URL: https://issues.apache.org/jira/browse/CRUNCH-215
> Project: Crunch
> Issue Type: New Feature
> Reporter: Gabriel Reid
> Assignee: Gabriel Reid
> Attachments: CRUNCH-215.patch
>
>
> Bloom filters can be very effective for pre-filtering one side of a join when
> one side of the join has a small subset of the keys of the other side (i.e.
> there are many keys on one side that will not be joined).
> The Bloom filter can be built up based on the keys of one side of the join
> (the side with fewer keys), and then can be applied as a filter to the other
> side of the join before it is sent through the shuffle and reduce phases.
--
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: http://www.atlassian.com/software/jira
