Establishing a Connection
The Lyftrondata Provider for Apache HBase connects to Apache HBase via the HBase REST (Stargate) server. Set the Port and Server properties to connect to Apache HBase. The Server property will typically be the host name or IP address of the server hosting Apache HBase. If there are multiple nodes, you will use the host name or IP address of the machine running the REST (Stargate) server.
Starting the Server
Different Hadoop distributions contain different interfaces and means of starting and stopping the HBase REST server, along with different default port settings. In most distributions, the HBase REST server can be started in the foreground by running the following command: "hbase rest start -p <port>". Please consult your Hadoop distribution's documentation for further information regarding the HBase REST server.
Authenticating to Apache HBase
If authentication is configured for your server, set AuthScheme to NEGOTIATE and set the User and Password, if necessary, to authenticate through Kerberos.
This section shows how to use the provider to authenticate to Apache HBase using Kerberos.
Authenticating with Kerberos
To authenticate to Apache HBase using Kerberos, set the following properties:
- AuthScheme: Set this to NEGOTIATE
- KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.
- KerberosSPN: Set this to the service and host of the Apache HBase Kerberos Principal. This will be the value prior to the '@' symbol (for instance, hbase/MyHost) of the hbase.regionserver.kerberos.principal of the hbase-site.xml file (for instance, hbase/MyHost@EXAMPLE.COM).
Retrieve the Kerberos Ticket
You can use one of the following options to retrieve the required Kerberos ticket.
MIT Kerberos Credential Cache File
This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you won't need to set the User or Password connection properties with this option.
- Ensure that you have an environment variable created called KRB5CCNAME.
- Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file will be created when generating your ticket with MIT Kerberos Ticket Manager.
- To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information will appear in Kerberos Ticket Manager and will now be stored in the credential cache file.
- Now that the credential cache file has been created, the provider will use the cache file to obtain the kerberos ticket to connect to Apache HBase.
As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the provider will use the specified cache file to obtain the kerberos ticket to connect to Apache HBase.
If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do this, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.
User and Password
If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a User and Password combination. To do this, set the User and Password properties to the user/password combo that you use to authenticate with Apache HBase.
More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g. where one realm/KDC is used for user authentication and another realm/KDC used for obtaining the service ticket).
In such an environment, the KerberosRealm and KerberosKDC properties can be set to the values required for user authentication. The KerberosServiceRealm and KerberosServiceKDC properties can be set to the values required to obtain the service ticket.
Fine-Tuning Data Access
You can use the following properties to configure automatic data type detection, which is enabled by default.
- TypeDetectionScheme: You can use this property to enable or disable automatic type detection based on the value specified in RowScanDepth.
- RowScanDepth: This property determines the number of rows that will be scanned to determine column data types.
Customizing the SSL Configuration
By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.
Connecting Through a Firewall or Proxy
To connect through the Windows system proxy, you do not need to set any additional connection properties. To connect to other proxies, set ProxyAutoDetect to false.
In addition, to authenticate to an HTTP proxy, set ProxyAuthScheme, ProxyUser, and ProxyPassword, in addition to ProxyServer and ProxyPort.
Set the following properties:
- To use a proxy-based firewall, set FirewallType, FirewallServer, and FirewallPort.
- To tunnel the connection, set FirewallType to TUNNEL.
- To authenticate, specify FirewallUser and FirewallPassword.
- To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.
Troubleshooting the Connection
To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.
- Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.
- Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.
- The certificate presented by the server cannot be validated: This error indicates that the provider cannot validate the server's certificate through the chain of trust. If you are using a self-signed certificate, there is only one certificate in the chain.
To resolve this error, you must verify yourself that the certificate can be trusted and specify to the provider that you trust the certificate. One way you can specify that you trust a certificate is to add the certificate to the trusted system store; another is to set SSLServerCert.