Skip to content

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.conf that reaches the realm.

    Authentication

  • Examples


    Worked scenarios: a partitioned Parquet warehouse, a database of mixed formats, object storage, and two Kerberized clusters.

    Examples

  • Best Practices


    Recommendations for planning the connection, splitting tables between the two Hive connectors, and keeping operations fast.

    Best Practices

  • Permissions


    The access your Hive cluster must grant, plus the Qualytics user role and team permission needed to manage the datastore.

    Permissions


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 New Connection

  • Add with Existing Connection


    Add another database from a cluster you already connected, reusing a saved Hive Native connection.

    Add with Existing Connection


Reference

  • Troubleshooting


    Known problems and how to resolve them, grouped by the step that failed: the metastore, Kerberos, storage, or a table.

    Troubleshooting

  • API


    Create, test, read, update, and delete Hive Native datastores over the API, including bulk creation from several databases.

    API

  • FAQ


    Short answers to the questions that come up most often about the two Hive connectors, formats, and Kerberos.

    FAQ