Given the encoding used internally by HBase, the only way to achieve this would be to apply a UDF on top of the returned binary data that decodes the value to an integer. You can use the HBase API of http://archive.cloudera.com/cdh5/cdh/5/hbase/apidocs/org/apache/hadoop/hbase/util/Bytes.html#toLong(byte[]) to perform the transformation within the UDF. X-Ref: https://github.com/cloudera/hbase/blob/cdh5.7.1-release/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L7546-L7618 ... View more

 HDFS currently is deeply tested only with 2x NameNodes, so while you can technically run 3x NNs, not everything would behave as intended. There is work ongoing to have 2+ NameNodes in future of HDFS.   HDFS HA architecture is also Active-Standby based, so 2x NNs being active is not possible by at least HDFS HA design. If you're using CDH, then this certainly isn't available, so am unsure what they are trying to mean by 3x Active NameNodes.   As to HA configuration, it involves a few configurations that are associated to one another. Here's an example core-site.xml and hdfs-site.xml properties that are relevant to HA config description from one such cluster. You can adapt them to your hostnames, but once again I'd like to recommend you obtain a client configuration zip from your administrator to make it easier in deploying with your cluster's configs, vs. hand-setting each relevant property. If you have access to some form of command/gateway/edge host, you can also usually find such config files under its /etc/hadoop/conf/ directory:   core-site.xml   <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://ha-nameservice-name</value> </property> … </configuration> hdfs-site.xml   <configuration> <property> <name>dfs.nameservices</name> <value>ha-nameservice-name</value> </property> <property> <name>dfs.client.failover.proxy.provider.ha-nameservice-name</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <property> <name>dfs.ha.automatic-failover.enabled.ha-nameservice-name</name> <value>true</value> </property> <property> <name>ha.zookeeper.quorum</name> <value>ZKHOST:2181</value> </property> <property> <name>dfs.ha.namenodes.ha-nameservice-name</name> <value>namenode10,namenode142</value> </property> <property> <name>dfs.namenode.rpc-address.ha-nameservice-name.namenode10</name> <value>NN1HOST:8020</value> </property> <property> <name>dfs.namenode.servicerpc-address.ha-nameservice-name.namenode10</name> <value>NN1HOST:8022</value> </property> <property> <name>dfs.namenode.http-address.ha-nameservice-name.namenode10</name> <value>NN1HOST:20101</value> </property> <property> <name>dfs.namenode.https-address.ha-nameservice-name.namenode10</name> <value>NN1HOST:20102</value> </property> <property> <name>dfs.namenode.rpc-address.ha-nameservice-name.namenode142</name> <value>NN2HOST:8020</value> </property> <property> <name>dfs.namenode.servicerpc-address.ha-nameservice-name.namenode142</name> <value>NN2HOST:8022</value> </property> <property> <name>dfs.namenode.http-address.ha-nameservice-name.namenode142</name> <value>NN2HOST:20101</value> </property> <property> <name>dfs.namenode.https-address.ha-nameservice-name.namenode142</name> <value>NN2HOST:20102</value> </property> … </configuration> With this configuration in place, all HDFS URIs must be accessed with FS URI hdfs://ha-nameservice-name. Ideally you want to use the same name your cluster uses, so remote services can reuse the name too, which is why grabbing an actual cluster client configuration set is important.       ... View more

In checking with CM Engg. internally, it appears I was mistaken in believing that the service/config endpoint was supposed to return *all* configs. Its only designed to emit service config, and the gateway configs which are separately maintained in each service should be gotten from the role group config endpoint instead. This is by design. ... View more

This is good, it looks like your server does use privacy and expect it. The new error is cause your cluster has HA HDFS but you are passing only a single hostname for the NN which is currently not the active one. You will need to use the entire HA config set, or for the moment pass in the other NN hostname. As to client configs, you can perhaps request your admin to generate a Zip from CM -> Cluster -> Actions -> Client Configuration URLs option visible to them. You'll have an easier time developing apps once you have all the required properties set, which is what the client configuration download in CM is designed for. ... View more

The simplest way is to disable ACLs in ZK, and restarting ZK. Append the below Java system property to CM -> Zookeeper -> Configuration -> "ZooKeeper Service Environment Advanced Configuration Snippet (Safety Valve)" field: -Dzookeeper.skipACL=true Save and restart ZK. Run your rmr command. You can revert that change back and re-restart if you want ACLs feature kept after. Another way is to declare a ZK superuser digest and using that whenever you face this (i.e. whenever you've lost the identity or mechanism of authentication to the ACL'd znode). This is documented at http://zookeeper.apache.org/doc/r3.4.8/zookeeperAdmin.html#sc_authOptions, and the option can be similarly added. ... View more

That is an Apache Hadoop upstream version. Please add Cloudera's repository: cloudera https://repository.cloudera.com/artifactory/cloudera-repos/ And the right version dependency (the hadoop-client wrapper one needs to be used generally, not specific ones such as common/hdfs/etc.): org.apache.hadoop hadoop-client 2.5.0-cdh5.3.10 That said, did you check up what protection mode the server configuration is expecting? ... View more

You certainly do need to set hadoop.rpc.protection to the exact value the cluster expects. While "authentication" is the default, the other values your cluster services may be using/enforcing are "privacy" or "integrity". If your cluster is run via CM, I highly recommend downloading a client configuration zip from its services and looking over all the properties present in it, and applying the same into your project (simplest way is to place the *.xml files into your src/main/resources, if you use maven, but you can also apply them programmatically). That said, from 5.1.0 onwards the clients are designed to auto-negotiate the SASL QOP properties from the server so you never have to specify the hadoop.rpc.protection accurately. This feature, combined with the error you face, leads me to believe that perhaps your hadoop-client dependency libraries are much older than 5.1.0. ... View more

Glad to hear @AxelJ! Feel free to mark the thread resolved so its easier for others with similar problems to locate your solution. ... View more

If you use manually managed CDH with packages, it'd involve restarting the HBase Master and RegionServer services: ~> service hbase-master restart # On Master host ~> service hbase-regionserver restart # On all RS hosts If you use Cloudera Manager instead, simply hit Restart on the HBase service on its homepage. ... View more