Impala Client Access

Application developers have a number of options to interface with Impala. The core development language with Impala is SQL. You can also use Java or other languages to interact with Impala through the standard JDBC and ODBC interfaces used by many business intelligence tools. For specialized kinds of analysis, you can supplement the Impala built-in functions by writing user-defined functions in C++ or Java.

You can connect and submit requests to the Impala through:

Impala clients can connect to the Coordinator Impala Daemon (impalad) via HiveServer2 over HTTP or over the TCP binary. Both HTTP and binary support the Kerberos SPNEGO and LDAP for authentication to Impala. See below for the default ports and the Impala flags to change the ports.

Protocol Default Port Flag to Specify an Alternate Port
HTTP 28000 ‑‑hs2_http_port
Binary TCP 21050 ‑‑hs2_port

Each impalad daemon process, running on separate nodes in a cluster, listens to several ports for incoming requests:

Impala Startup Options for Client Connections

Use the following flags when starting Impala Daemon coordinator to control client connections to Impala.

--accepted_client_cnxn_timeout
Controls how Impala treats new connection requests if it has run out of the number of threads configured by --fe_service_threads.

If --accepted_client_cnxn_timeout > 0, new connection requests are rejected if Impala can't get a server thread within the specified (in seconds) timeout.

If --accepted_client_cnxn_timeout=0, i.e. no timeout, clients wait indefinitely to open the new session until more threads are available.

The default timeout is 5 minutes.

The timeout applies only to client facing thrift servers, i.e., HS2 and Beeswax servers.

--disconnected_session_timeout
When a HiveServer2 session has had no open connections for longer than this value, the session will be closed, and any associated queries will be unregistered.

Specify the value in hours.

The default value is 1 hour.

This flag does not apply to Beeswax clients. When a Beeswax client connection is closed, Impala closes the session associated with that connection.

--fe_service_threads
Specifies the maximum number of concurrent client connections allowed. The default value is 64 with which 64 queries can run simultaneously.

If you have more clients trying to connect to Impala than the value of this setting, the later arriving clients have to wait for the duration specified by --accepted_client_cnxn_timeout. You can increase this value to allow more client connections. However, a large value means more threads to be maintained even if most of the connections are idle, and it could negatively impact query latency. Client applications should use the connection pool to avoid need for large number of sessions.

--hs2_http_port
Specifies the port for clients to connect to Impala server over HTTP.

The default port is 28000.

You can disable the HTTP end point for clients by setting the flag to 0.

To enable TLS/SSL for HiveServer2 HTTP endpoint use --ssl_server_certificate and --ssl_private_key. See Configuring TLS/SSL for Impala for detail.

--idle_client_poll_period_s
The value of this setting specifies how frequently Impala polls to check if a client connection is idle and closes it if the connection is idle. A client connection is idle if all sessions associated with the client connection are idle.

By default, --idle_client_poll_period_s is set to 30 seconds.

If --idle_client_poll_period_s is set to 0, idle client connections stay open until explicitly closed by the clients.

The connection will only be closed if all the associated sessions are idle or closed. Sessions cannot be idle unless either the flag --idle_session_timeout or the IDLE_SESSION_TIMEOUT query option is set to greater than 0. If idle session timeout is not configured, a session cannot become idle by definition, and therefore its connection stays open until the client explicitly closes it.

--max_cookie_lifetime_s
Starting in Impala 3.4.0, Impala uses cookies for authentication when clients connect via HiveServer2 over HTTP. Use the --max_cookie_lifetime_s startup flag to control how long generated cookies are valid for.

Specify the value in seconds.

The default value is 1 day.

Setting the flag to 0 disables cookie support.

When an unexpired cookie is successfully verified, the user name contained in the cookie is set on the connection.

Each impalad uses its own key to generate the signature, so clients that reconnect to a different impalad have to re-authenticate.

On a single impalad, cookies are valid across sessions and connections.