Fuzzy Joins in MapReduce: An Experimental Study

We report experimental results for the MapReduce algorithms proposed by Afrati, Das Sarma, Menestrina, Parameswaran and Ullman in ICDE’12 to compute fuzzy joins of binary strings using Hamming Distance. Their algorithms come with complete theoretical analysis, however, no experimental evaluation is provided. They argue that there is a tradeoff between communication cost and processing cost, and that there is a skyline of the proposed algorithms; i.e. none dominates another. We observe via experiments that, from a practical point of view, some algorithms are almost always preferable to others. We provide detailed experimental results and insights that show the different facets of each algorithm. 1. OBJECTIVES In [1] there are several algorithms proposed for performing “fuzzy join” (an operation that finds pairs of similar items) in MapReduce. The main part of [1] concentrates on binary strings and Hamming distance; this offers the clearest view of the various algorithmic approaches. The algorithms proposed are: Naive, which compares every string in the set with every other; Ball-Hashing, a family of two algorithms that send strings to a ‘ball’ of all ‘nearby strings’ within a certain similarity; Anchor Points, a randomized algorithm that selects a set of strings and compares any pair of strings that have a close enough distance to a member of the set; and Splitting, an algorithm that splits the strings into pieces and compares only strings with matching pieces. It is argued in [1] that there is a tradeoff between communication cost and processing cost, and that there is a skyline of the proposed algorithms; i.e. none dominates another. One of our objectives is to see whether we can observe this skyline in practical terms. We observe via experiments that, from a practical point of view, some algorithms are almost always preferable to others. For example in our experiments, Hamming Code is another algorithm that [1] considers, however, it is a special case of Anchor Points. This work is licensed under the Creative Commons AttributionNonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/. Obtain permission prior to any use beyond those covered by the license. Contact copyright holder by emailing [email protected]. Articles from this volume were invited to present their results at the 41st International Conference on Very Large Data Bases, August 31st September 4th 2015, Kohala Coast, Hawaii. Proceedings of the VLDB Endowment, Vol. 8, No. 12 Copyright 2015 VLDB Endowment 2150-8097/15/08. Splitting is a clear winner, whereas Ball-Hashing suffers for all distance thresholds except the very small ones. We provide detailed experiments and insights that show different facets of each algorithm. Another objective we set is to provide implementation optimizations whenever possible. Specifically, we provide optimizations for Naive and Ball Hashing, and clarify details for the others. 2. ALGORITHMS AND IMPLEMENTATION Naive algorithm. This algorithm sends a section of the input to every physical reducer. Each reducer checks every possible pair of strings (out of the set it received) to see if they are within distance d of one another. More specifically, let K = J(J + 1)/2 be the number of reducers. They are keyed by (i, j), where 0 ≤ i ≤ j < J , thus forming a triangular matrix, where only reducer (i, j) or (j, i) exists. Strings s ∈ S are hashed to values in [0, J). If a string s hashes to i, it is sent to reducer (i, j) or (j, i), whichever exists, for each j ∈ [0, J). So, each string is sent to exactly J reducers. Then, [1] suggests that each reducer should exhaustively compare each possible pair of strings from the portion of S it received. This, however, does not need to be so. Our optimization. Consider strings s and t that both hash to i. They will be sent to reducers (i, i), (i, i+1), . . . , (i, J−1), and each of these reducers will compare them for similarity. It is clear that only one of the reducers needs to compare s with t, say reducer (i, i); the other reducers should not compare s with t as this would be redundant. More formally, with our optimization, a reducer (i, j) only compares strings that hash to i with those that hash to j. This optimization reduces the amount of work in the reducers by about 2/3. Furthermore this eliminates duplicate output, one of the goals in [1]. The reduction of work by 2/3 is explained as follows. Let ni and nj be the numbers of strings hashing to i and j, respectively. An unoptimized reducer does (ni + n 2 j + ninj)/2 string comparisons and an optimized one does just ninj/2. Then the reduction of work is by (ni + n 2 j )/2 comparisons, which is (ni + n 2 j )/(n 2 i + n 2 j + ninj) = 2/3 of the work, if we assume ni ≈ nj in the average case. Ball-Hashing (BH). This is a family of two algorithms. For these algorithms there is one reducer for each of the possible strings in the universe, so in practice, the reducers are logical rather than physical. A reducer serving string s will receive input strings that are within a ball of a certain