[ In Action ] Ch5. Advanced MapReduce: Semijoin - reduce-side join with map-side filtering (Part4)

Preface (P121) 
One of the limitations in using replicated join is that one of the join tables has to be small enough to fit in memory. Even with the usual asymmetry of size in the input sources, the smaller one may still not be small enough. You can solve this problem by rearranging the processing steps to make them more efficient. For example, if you’re looking for the order history of all customers in the 415 area code, it’s correct but inefficient to join the Orders and the Customers tables first before filtering out records where the customer is in the 415 area code. Both the Orders and Customers tables may be too big for replicated join and you’ll have to resort to the inefficient reduce-side join. A better approach is to first filter out customers living in the 415 area code. We store this in a temporary file called Customers415. We can arrive at the same end result by joining Orders with Customers415, but now Customers415 is small enough that a replicated join is feasible. There is some overhead in creating and distributing the Customers415 file, but it’s often compensated by the overall gain in efficiency. 

Sometimes you may have a lot of data to analyze. You can’t use replicated join no matter how you rearrange your processing steps. Don’t worry. We still have ways to make reduce-side joining more efficient. Recall that the main problem with reduce-side joining is that the mapper only tags the data, all of which is shuffled across the network but most of which is ignored in the reducer. The inefficiency is ameliorated if the mapper has an extra prefiltering function to eliminate most or even all the unnecessary data before it is shuffled across the network. We need to build this filtering mechanism. 

Semijoin : reduce-side join with map-side filtering 
Continuing our example of joining Customers415 with Orders, the join key is Customer ID and we would like our mappers to filter out any customer not from the 415 area code rather than send those records to reducers. We create a data set CustomerID415 to store all the Customer IDs of customers in the 415 area code. CustomerID415 is smaller than Customers415 because it only has one data field. Assuming CustomerID415 can now fit in memory, we can improve reduce-side join by using distributed cache to disseminate CustomerID415 across all the mappers. When processing records from Customers and Orders, the mapper will drop any record whose key is not in the set CustomerID415. This is sometimes called a semijoin, taking the terminology from the database world. 

Last but not least, what if the file CustomerID415 is still too big to fit in memory? Or maybe CustomerID415 does fit in memory but it’s size makes replicating it across all the mappers inefficient. This situation calls for a data structure called a Bloom filter. A Bloom filter is a compact representation of a set that supports only the contain query. (“Does this set contain this element?”) Furthermore, the query answer is not completely accurate, but it’s guaranteed to have no false negatives and a small probability of false positives. The slight inaccuracy is the trade-off for the data structure’s compactness. By using a Bloom filter representation of CustomerID415, the mappers will pass through all customers in the 415 area code. It still guarantees the correctness of the data join algorithm. The Bloom filter will also pass a small portion of customers not in the 415 area code to the reduce phase. This is fine because those will be ignored in the reduce phase. We’ll still have improved performance by reducing dramatically the amount of traffic shuffled across the network. The use of Bloom filters is in fact a standard technique for joining in distributed databases, and it’s used in commercial products such as Oracle 11g. We’ll describe Bloom filter and its other applications in more details in the next section. 

Supplement 
* Chaining MapReduce jobs (Part1) 
* Joining data from different sources (Part2) 
* Replicated joins using DistributedCache (Part3) 
* reduce-side join with map-side filtering (Part4) 
* Creating a Bloom filter (Part5)