Re: HBase unbalanced table regions after bulkload


Hi Ali,

OK, I overlooked your config line "storage.hbase.region-count=1024". This is far too large a number, since HBase likes regions with a size of the order of 10GB, rather than the 130MB you requested. This 10 GB region split is probably a HBase global setting. It could be a similar number in your HBase cluster, so HBase just ignores the superfluous regions, unless you would configure the region split to a lower number manually (not advised).

Other comments from HBase experts are welcomed (I do not consider myself one).

Cheers,    Marc

Op vrijdag 16 juni 2017 09:57:12 UTC+2 schreef Ali ÖZER:

Hi Marc,

As far as I know, even if yarn schedules executors unevenly, it does not mean that the data written across hbase will be uneven.

The data is written hbase according to the key of the datum and the key-ranges of the regions, it does nothing to do with the node that the writer jvm is working on.

My executors are working on %90 of my nodes (it is not that uneven) however percentage of my empty regions is %90(900 of 1024 regions). If you were right the latter percentage would be %10 instead of %90.

If there is some other mechanism while assigning ids in distributed fashion, may you please keep me updated and elaborate on the mechanism.


15 Haziran 2017 Perşembe 22:51:14 UTC+3 tarihinde HadoopMarc yazdı:

Hi Ali,

I have never tried to optimize this myself, but maybe you should also look into the docs at

12.3.30. storage.hbase



The number of initial regions set when creating JanusGraph’s HBase table


(no default value)



The number of regions per regionserver to set when creating JanusGraph’s HBase table


(no default value)


Normally, HBase does not want many regions, but the number of regions times hdfs replication factor should be at least the number of active datanodes for maximum performance. I think some unbalance is inevitable as yarn will schedule executors unevenly and each executor will try to have local data access.

Further, you can look into HBase's region load balancer configuration, which enables HBase to move regions automatically.

HTH,    Marc

Op donderdag 15 juni 2017 16:04:28 UTC+2 schreef Ali ÖZER:
We are using cloudera 5.7.0 with java 1.8.0_74 and we have spark 1.6.0, janusgraph 0.1.1, hbase 1.2.0.

I managed to bulkload 130GB of data into 1024 region hbase table in 2 hours 30 minute with 1024 spark executors (1-core,20gb memory). Each stage of blvp is configured to run 10240 tasks:

However I am unable to distribute the hbase data evenly across regions, they are pretty imbalanced. I suspect it is related to the conf value of ids.num-partitions.

Here is how I set the conf:





I even tried setting ids.num-partitions=10240; however the problem was not solved.

Should I still increase the ids.num-partitions value to an even higher value like 102400?
What is the difference cluster.max-partitions and ids.num-partitions. Is my problem related to cluster.max-partitions? Should I use it?

As far as I know ids.num-partitions value determines the number of randomly gathered prefixes that will be used in assigning ids to elements. And I read somewhere that setting ids.num-partitions to 10 times of region count will be enough; however it seems like that is not the case. And I do not want to increase ids.num-partitions further. Since I could not find any document related to the internals of cluster.max-partitions, I am really ignorant about it and need some help.

Thanks in advance,

Join to automatically receive all group messages.