Introduction to the Hive Native Connector
Apache Hive organizes data held in HDFS or cloud object storage into databases and tables, and records in its metastore where every table and partition lives. Most Hive environments expose that data through HiveServer2, which compiles each query, runs it on the cluster, and returns the rows.
The Qualytics Hive Native connector takes a shorter path. It reads table information from the metastore and then reads the underlying Parquet and ORC files directly, leaving the cluster's query engine out of the read path, which is considerably faster on large tables. Partitions come from the metastore rather than from listing storage, so Qualytics profiles tables, runs scheduled scans, and surfaces record- and schema-level anomalies on results that match what Hive itself reports.
Source datastores only
Hive Native is read-only, so it cannot be used as an enrichment datastore. Link a separate enrichment datastore as its destination to store the anomalies and metadata Qualytics produces, either during creation or afterwards.
Notes
Choosing between the two Hive connectors. Qualytics keeps both, and they are good at different things. Use Hive Native for the Parquet and ORC tables that make up most large Hive environments, and the Hive connector for anything the native path declines to read. Both can be connected against the same cluster at the same time.
| Hive Native | Hive | |
|---|---|---|
| How it reads data | Reads the table's data files directly | Runs queries through HiveServer2 |
| Speed on large tables | Considerably faster | Limited by HiveServer2 |
| Table formats | Parquet and ORC | Any format Hive can query |
| Views | Not supported | Supported |
| Transactional (ACID) tables | Not supported | Supported |
| Connects to | The Hive metastore | HiveServer2 |
| Authentication | Kerberos | Kerberos, or user and password |
Supported tables and formats. The connector reads tables stored as Parquet or ORC, managed or external, partitioned or not. Anything else is declined rather than read incorrectly, and each declined table is reported on its own while the rest of the database syncs normally. Use the Hive connector for the tables on this list.
| Declined | Why |
|---|---|
| Transactional (ACID) tables | Reading the files directly would ignore delete records and return rows Hive itself would not return |
| Views | The native path reads tables, not query definitions |
| Delta, Hudi, and Iceberg tables registered in Hive | These formats decide which files are current, so their own reader is required |
| Tables backed by a storage handler, such as HBase or Kudu | Their data is only reachable through the handler |
| Text, Avro, JSON, and other formats | The native path reads Parquet and ORC files |
What the form does not ask for. There is no Catalog field of the kind Athena asks for, because Hive has no level above the database, only databases and tables. Qualytics works the rest out from the metastore address, which also makes it impossible for two datastores to collide while pointing at different clusters. There is no question about reaching storage by hostname either, because that depends on where your Qualytics deployment runs rather than on the datastore, so Qualytics handles it.
Row counts and column names. When Hive's own table statistics are current, Qualytics uses the row count Hive recorded instead of counting the rows itself, which makes profiling a very large table noticeably quicker; when the statistics are stale or absent, Qualytics counts the rows. Hive also records column names in lower case while the data files keep the case they were written with, so Qualytics confirms the two agree before a scan reads any data and refuses the scan if they differ, rather than returning a column full of empty values.
Deep Dive
-
Authentication
Kerberos on this connector: the service principal, the keytab Qualytics presents, and the
krb5.confthat reaches the realm. -
Examples
Worked scenarios: a partitioned Parquet warehouse, a database of mixed formats, object storage, and two Kerberized clusters.
-
Best Practices
Recommendations for planning the connection, splitting tables between the two Hive connectors, and keeping operations fast.
-
Permissions
The access your Hive cluster must grant, plus the Qualytics user role and team permission needed to manage the datastore.
How-tos
-
Add with New Connection
Add Hive Native as a source datastore and create its connection at the same time, field by field.
-
Add with Existing Connection
Add another database from a cluster you already connected, reusing a saved Hive Native connection.
Reference
-
Troubleshooting
Known problems and how to resolve them, grouped by the step that failed: the metastore, Kerberos, storage, or a table.
-
API
Create, test, read, update, and delete Hive Native datastores over the API, including bulk creation from several databases.
-
FAQ
Short answers to the questions that come up most often about the two Hive connectors, formats, and Kerberos.