Phoenix is unable to find the location of the hbase:meta region. This is likely caused by one of two reasons: First, make sure that HBase is actually running and healthy. Second, it may be that Phoenix is not looking at the correct place in ZK to find your HBase instance. You can try to use the "-z" option to specify the ZK quorum for your environment (e.g. localhost:2181:/hbase-unsecure). ... View more

Remember that HBase is ultimately handling the access to HDFS for the HBase API calls that you make. One simple example of this is that even though you may issue a request to read a record from a table, the files in HDFS are owned by "hbase" and your user would be unable to read them directly. The same extends to the encryption zones. HBase is capable of reading the data, but your user isn't. You can still read the data in HBase as that user as HBase is only enforcing authorization of your user's request into HBase. Your user isn't directly reading the data. ... View more

The HBase Region Normalizer sounds like it would be a good fit. https://community.hortonworks.com/articles/54987/hbase-region-normalizer.html https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html ... View more

#1 See https://hbase.apache.org/book.html#_client_side_configuration_for_secure_operation. Set hbase.rpc.protection=true #2 There is no sensitive data that clients read out of ZooKeeper. #3 I don't know this means. Phoenix uses HBase's RPC mechanism which is already encompassed by #1 #4 No, but HBase already sets up ACLs to protect all information that users should not see/modify. Table data is not stored in ZooKeeper. ... View more

The "fat" Phoenix client jar is not presently published via Maven. https://issues.apache.org/jira/browse/PHOENIX-1567 ... View more