accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3913) Add per table sampling
Date Mon, 22 Jun 2015 23:40:03 GMT


Keith Turner commented on ACCUMULO-3913:

bq. What's the tangible benefit for users that you're going for here, Keith? I assume this
is just one piece of a bigger picture.

Over the years I have heard multiple request for sampling.   Recently someone was asking about
the feasibility of supporting scanning the RFile indexes as an approximate sample.  This was
interesting idea, but it bugged me that different rfile indexes would have different subsets
of keys.  So if one RFile index had a key that was deleted in a later RFile, you would likely
not see the delete.   So I started thinking about pre-generating a sample that had a consistent
set of keys.

bq.  is there a reason that the Sampler isn't a specialization of SKVI? Seems very close to
what Filter already does.

I have not put a lot of thought into this particular aspect.  I mainly wanted to do a quick
end to end prototype to see if there were any big gotcha's with the overall idea.  One issue
w/ using Filter for the sample function, may be that seek support is not needed.

> Add per table sampling
> ----------------------
>                 Key: ACCUMULO-3913
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>            Reporter: Keith Turner
>             Fix For: 1.8.0
> I am working on prototyping adding hash based sampling to Accumulo.  I am trying to accomplish
the following goals in the prototype.
>   # Have each RFile store a sample per locality group.  Also store the configuration
used to generate the sample.
>   # Use sampling functions that ensure the same row columns exist across the samples
in all rfiles. Hash mod is a good candidate that gives a random sample thats consistent across
>   # Have scanners support scanning RFile's samples sets.  Scan should fail if RFiles
have different sample configuration.  Different sampling config implies the RFile's sample
sets contain a possibly disjoint set of row columns.
>   # Support generating sample data for RFiles generated for bulk import
>   # Support sample data in in memory map
>   # Support enabling and disabling sampling per table AND configuring a sample function.
> I am currently using the following function in my prototype to determine what data an
RFile stores in its sample set.  This code will always select same subset of rows for each
RFile's sample set.  I have not yet made the function configurable.
> {code:java}
> public class RowSampler implements Sampler {
>   private HashFunction hasher = Hashing.murmur3_32();
>   @Override
>   public boolean accept(Key k) {
>     ByteSequence row = k.getRowData();
>     HashCode hc = hasher.hashBytes(row.getBackingArray(), row.offset(), row.length());
>     return hc.asInt() % 1009 == 0;
>   }
> }
> {code}
> Although not yet implemented, the divisor in this RowSample could be configurable. RFiles
with sample data would store the fact that a RowSample with a divisor of 1009 was used to
generate sample data.

This message was sent by Atlassian JIRA

View raw message