Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 22 Jun 2015 23:40:03 +0000 (UTC)
From: "Keith Turner (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12839708.1435014442000.142006.1435016403354@Atlassian.JIRA>
In-Reply-To: <JIRA.12839708.1435014442000@Atlassian.JIRA>
References: <JIRA.12839708.1435014442000@Atlassian.JIRA>
 <JIRA.12839708.1435014442155@arcas>
Subject: [jira] [Commented] (ACCUMULO-3913) Add per table sampling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596857#comment-14596857 ] 

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: https://issues.apache.org/jira/browse/ACCUMULO-3913
>             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 files.
>   # 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
(v6.3.4#6332)