[ 
https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655793#action_12655793
 ] 

stack commented on HADOOP-3063:
-------------------------------

Reviewing the patch, it looks great.  The above failure would seem to be 
because the last two arguments need to be flipped:

{code}
 236 +      bloomFilter = new DynamicBloomFilter(vectorSize, HASH_COUNT, 
numKeys,
 237 +          Hash.getHashType(conf));
{code}

....the DBF constructor looks like this:

{code}
1528 +  public DynamicBloomFilter(int vectorSize, int nbHash, int hashType, int 
nr) {
{code}

Test still fails with an assertion error so maybe the above is not right.

There is an hbasism still in the code that you probably want to remove:

{code}
408 +    String name = conf.get("hbase.hash.type", "murmur");
{code}

> BloomMapFile - fail-fast version of MapFile for sparsely populated key space
> ----------------------------------------------------------------------------
>
>                 Key: HADOOP-3063
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3063
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: io
>    Affects Versions: 0.20.0
>            Reporter: Andrzej Bialecki 
>             Fix For: 0.20.0
>
>         Attachments: bloommap-v2.patch, bloommap-v3.patch, bloommap.patch
>
>
> The need for this improvement arose when working with large ancillary 
> MapFile-s (essentially used as external dictionaries). For each invokation of 
> map() / reduce() it was necessary to perform several look-ups in these 
> MapFile-s, and in case of sparsely populated key-space the cost of finding 
> that a key is absent was too high.
> This patch implements a subclass of MapFile that creates a Bloom filter from 
> all keys, so that accurate tests for absence of keys can be performed quickly 
> and with 100% accuracy.
> Writer.append() operations update a DynamicBloomFilter, which is then 
> serialized when the Writer is closed. This filter is loaded in memory when a 
> Reader is created. Reader.get() operation first checks the filter for the key 
> membership, and if the key is absent it immediately returns null without 
> doing any further IO.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to