hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Esteban Gutierrez <este...@cloudera.com>
Subject Re: ACLs/Quotas for HBase structures
Date Sat, 20 Dec 2014 07:42:06 GMT
Hello Manoj,

Thats a very interesting requirement, unfortunately the existing HBase
directory structure needs to be owned by the user that started HBase
(usually the 'hbase' user) and HBase will handle all the permissions and
ACL rules without exposing details from HDFS to the client API. Even if you
change the ownership of Hfiles under a specific namespace or table,
compactions or splits will create new files as the HBase superuser. Also,
running multiple HBase clusters under the same HDFS cluster to go around
this limitation should be avoided since it can make things really hard to

Regarding the quota requirement, probably HBASE-8410/HBASE-11999 (work in
progress) will be the best option in order to support quotas in a reliable
way. Keep in mind that using HDFS quotas with HBase doesn't work well since
compactions and splits can increase the space utilization beyond the quota
sometimes and that could trigger failures in the Region Servers.

Probably your only option for now is to monitor the namespace utilization,
use Kerberos for authentication and specify a set of ACL rules that will
guarantee that users cannot access namespaces that are not allowed to.


Cloudera, Inc.

On Fri, Dec 19, 2014 at 10:31 PM, Manoj Murumkar <manoj.murumkar@gmail.com>
> Folks,
> We are trying to control space usage and manage security at HBase namespace
> level. Think of it in terms of a RDBMS (database and superuser for a
> database). Is there a simple way to do this?
> This is what I have in mind. Does it make sense?
>    - Space quotas: Namespace is managed under
> /apps/hbase/data/data/<namespace>
>    directory. We'll  use "dfsadmin -setQuota" to set appropriate quotas.
>    - Make <superuser> owner of /apps/hbase/data/data/<namespace> directory
>    in hdfs.
> Thanks for any pointers from folks who have done this kind of thing.
> Appreciate the time.
> Manoj

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message