hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16894) Create more than 1 split per region, generalize HBASE-12590
Date Fri, 18 Nov 2016 23:01:58 GMT

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

Enis Soztutar commented on HBASE-16894:
---------------------------------------

Thanks [~easyliangjob] for picking up this. My suggestion is to start with at least these
requirements: 
For jobs that READ from HBase, we would like the user to be able to use any of these three
methods:  
(1) Users should be able to specify total number of maps desired, and HBase comes up with
Splits grouping / splitting regions based on sizes and number of required maps. Example is
that if table has 100 regions, but we want the MR jobs to run with 200 splits, or if table
has 100 regions but we want to run only 50 map tasks. 
(2) Users should be able to specify the input split size, which will then determine how many
map tasks are created. User will specify the size as let's say 2GB, and HBase TableInputFormat
will create 1 split per roughly 2 GB of data depending on existing region sizes (An 8GB region
will be split into 4, two 1GB neighbor regions are combined into 2GB regions, etc). 
(3) Users should be able to specify how many splits per region she wants. If 100 regions,
and tasks per region is 3, then we will generate 300 splits. The current way HBase works will
be using 1 task-per-region as default. 

For Jobs that WRITE to HBase, then we should be able to specify any of these two methods:

(1) Users should be able to specify total number of reducers desired, and HBase comes up with
partitioning based on region boundaries. Note that especially in bulk load, we do not want
to group more than 1 region per task (unlike the map case). The number of requested reducers
will be just a hint, and HBase might end up generating more reducers. 
(2) Users should be able to specify how many reducers per region we want. 

Let me know if makes sense or not. There is usually no good way to know the exact split points
within the region to see how you can divide the region into N pieces. The code that HBASE-12590
assumes text or binary keys and uniform distribution. We can also look into improving that,
by asking the region server hosting the region about the split points (which should be calculated
from hfile indexes, similar to the mid point calculation that we have in region splits) or
we can look into maintaining equi-width histograms for keys (Phoenix guideposts). We can do
these suggestions in a follow up issue. 

> Create more than 1 split per region, generalize HBASE-12590
> -----------------------------------------------------------
>
>                 Key: HBASE-16894
>                 URL: https://issues.apache.org/jira/browse/HBASE-16894
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Enis Soztutar
>            Assignee: Yi Liang
>              Labels: beginner, beginners
>
> A common request from users is to be able to better control how many map tasks are created
per region. Right now, it is always 1 region = 1 input split = 1 map task. Same goes for Spark
since it uses the TIF. With region sizes as large as 50 GBs, it is desirable to be able to
create more than 1 split per region.
> HBASE-12590 adds a config property for MR jobs to be able to handle skew in region sizes.
The algorithm is roughly: 
> {code}
> If (region size >= average size*ratio) : cut the region into two MR input splits
> If (average size <= region size < average size*ratio) : one region as one MR input
split
> If (sum of several continuous regions size < average size * ratio): combine these
regions into one MR input split.
> {code}
> Although we can set data skew ratio to be 0.5 or something to abuse HBASE-12590 into
creating more than 1 split task per region, it is not ideal. But there is no way to create
more with the patch as it is. For example we cannot create more than 2 tasks per region. 
> If we want to fix this properly, we should extend the approach in HBASE-12590, and make
it so that the client can specify the desired num of mappers, or desired split size, and the
TIF generates the splits based on the current region sizes very similar to the algorithm in
HBASE-12590, but a more generic way. This also would eliminate the hand tuning of data skew
ratio.
> We also can think about the guidepost approach that Phoenix has in the stats table which
is used for exactly this purpose. Right now, the region can be split into powers of two assuming
uniform distribution within the region. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message