[
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)
