Hive Native FAQ
Answers to common questions about the Hive Native connector. Sections are grouped by topic; pick the heading closest to what you are working on.
Choosing a connector
Does Hive Native replace the Hive connector?
No. Both stay available, and they are good at different things. Hive Native is the faster path for Parquet and ORC tables; the Hive connector reads anything Hive itself can query, including views and transactional tables.
Can I connect both against the same cluster?
Yes, at the same time. A common arrangement is Hive Native for the large Parquet and ORC tables and the Hive connector for the handful of views or transactional tables alongside them.
Do I have to migrate my existing Hive datastores?
No. An existing Hive datastore keeps working exactly as before. Adding Hive Native is a new datastore on a new connection, not a change to the old one.
Why is it faster?
It leaves the cluster's query engine out of the read path. Instead of sending a query to HiveServer2 and waiting for the rows to come back, Qualytics reads the table's files directly. On a large table that difference is considerable.
What it reads
Which table formats are supported?
Parquet and ORC, managed or external, partitioned or not.
Why is one of my tables reported as unsupported?
Because reading it directly would return something different from what Hive reports, so Qualytics declines it instead. That covers transactional (ACID) tables, views, tables backed by a storage handler such as HBase or Kudu, Delta, Hudi and Iceberg tables registered in Hive, and formats other than Parquet and ORC. Read those through the Hive connector.
Does one unsupported table break the sync?
No. Each declined table is reported on its own, and every other table in the database syncs normally.
Can Qualytics write to my Hive cluster?
No. The connector is read-only, so it cannot be used as an enrichment datastore. Link a separate enrichment datastore as its destination for the anomalies and metadata Qualytics produces.
Connecting
Why is there no Catalog field?
Connectors such as Athena ask for a Catalog, the level above the database. Hive has no such level, only databases and tables, so there is nothing to name. Qualytics works one out from the metastore address, which also makes it impossible for two datastores to collide while pointing at different clusters.
Do I need the Warehouse Directory?
Not for reading. Qualytics takes each table's location from the metastore rather than from a warehouse root, so the field is optional.
My tables are in Amazon S3 rather than HDFS. Does that work?
Yes, and it needs less network access: only the metastore and the Key Distribution Center. Qualytics reads object storage with the credentials your deployment is already configured with.
The connection test passed and the sync worked, but the profile failed. Why?
Reading table information never touches storage, so a datastore whose storage is unreachable connects cleanly, syncs cleanly, and then fails on the first operation that reads data. Allow the NameNode and DataNode ports, and confirm that every hostname recorded in the table locations resolves from your Qualytics deployment. See Troubleshooting.
Kerberos
Is Kerberos the only option?
Yes. The metastore protocol has no username and password authentication of its own, so there is no other credential to collect. To connect to Hive as a specific named user, use the Hive connector.
Do I still need deployment-wide Kerberos configuration?
No. Each connection carries its own Service Principal and keytab, so reaching a Kerberized cluster is now a change to the connection rather than to your deployment. Leaving the keytab empty still falls back to the deployment's credentials if you prefer that.
Is the Service Principal my account?
No. It identifies the metastore you are connecting to, for example hive/_HOST@EXAMPLE.COM. The identity Qualytics presents comes from the keytab you upload. See Authentication.
Can I connect several Kerberized clusters?
Yes, each with its own identity and its own krb5.conf. The one arrangement that cannot work is two clusters using the same realm name with different Key Distribution Centers.
Do I need to renew tickets?
No. Qualytics renews them from the keytab on its own. The only thing to do by hand is upload a new keytab after a credential change.
My keytab upload was rejected.
The file has to be the keytab itself and has to be named with a .keytab extension. Uploading a krb5.conf into the Keytab field produces the same rejection.