Skip to content

Hive Native Best Practices

Recommendations for getting reliable results and predictable run times from a Hive Native datastore.

Plan the connection

Confirm storage reachability before the first profile, not after. A datastore whose metastore is reachable but whose storage is not will connect, sync, and list every table without complaint, then fail on the first operation that reads records. Checking the NameNode and DataNode ports and the hostname resolution up front turns a confusing failure into a five-minute setup step. See Permissions.

Use one connection per cluster and reuse it. Every datastore that reads from the same metastore should share one saved connection. The credentials then live in one place, so changing a keytab is a single edit rather than one per database. Add further databases with Add with an Existing Connection.

Leave Warehouse Directory empty unless you have a reason not to. Qualytics takes each table's location from the metastore, so the warehouse root is not consulted when reading. Filling it in suggests to the next reader that it matters.


Choose the right connector per table

Send Parquet and ORC through Hive Native and everything else through Hive. The native path is the faster one, and it is the one that declines views, transactional tables, and other formats. Pointing both connectors at the same cluster, and splitting the tables between them, gets you the speed where it applies and full coverage where it does not.

Do not treat a declined table as a failure to work around. A refusal means reading those files directly would disagree with what Hive itself returns. Rewriting the table to satisfy the native path is rarely worth it; reading it through the Hive connector is.


Keep operations fast

Keep Hive's table statistics current. When Hive vouches for a table's statistics, Qualytics uses the row count Hive already recorded instead of counting the rows itself, which removes a full pass over a very large table at profile time. Running Hive's own statistics collection after a significant load keeps that fast path available.

Narrow the datastore to the databases you actually monitor. A datastore over a database with a very large number of partitions spends real time on partition metadata. Selecting only the databases you intend to profile keeps sync and scan times proportional to what you care about.

Filter scans on partition columns. A scan whose conditions name the partition columns lets Qualytics ask the metastore for just those partitions rather than fetching the whole partition list, which is the difference between reading one day and enumerating every day the table holds.


Keep Kerberos manageable

Put the credentials on the connection. Uploading the keytab and krb5.conf on the connection means reaching a secured cluster is a change to the connection rather than to your deployment. It also makes a second cluster a matter of adding a connection.

Give each cluster a distinct realm name. Two clusters sharing a realm name with different Key Distribution Centers cannot coexist on one deployment, and the second connection is refused. This is worth settling before it becomes an obstacle.

Keep one identity per purpose. The keytab identifies the account Qualytics reads as, and every table read is checked against it. An identity scoped to the databases Qualytics monitors makes an access problem obvious in your cluster's own audit trail rather than hidden behind a shared service account.

Upload the new keytab as soon as a credential changes. Qualytics renews tickets from the keytab on its own, so there is nothing to run on a schedule, but a keytab from before a change stops working the moment the old key is retired.


Keep the data readable

Keep column-name case consistent. Hive records column names in lower case while the data files keep the case they were written with. Where they disagree, Qualytics refuses the scan rather than returning a column full of empty values. Writing files with the names Hive records avoids the situation entirely.

Prefer partitioned, columnar tables for the data you monitor. Partitioning is what lets a scan read a slice instead of the whole table, and Parquet and ORC are what the native path reads at all. A table that is both is the case this connector is built for.


See Also