Known Limitations in Apache Kudu

This page describes current limitations in Apache Kudu related to Impala compatibility, partitioning, authentication mapping, and version-specific support.

Known Limitations Factor into System Design

For details about known limitations that factor into system design, see Apache Kudu Known Limitations.

Impala Compatibility

Non-unique Primary Keys

• Kudu 1.17 supports non-unique primary keys by automatically adding an auto_increment_id column.

• The version of Impala shipped with ODP 3.2.3.2 (v4.1.2) does not support creating tables with non-unique keys.

• This feature is supported in Impala v4.3.0 and later.

• Client libraries are not affected.

• Reference: IMPALA-11809

Custom Hash Partitions at the Range Level

• Kudu supports specifying custom hash partitions at the range partition level.

• Impala v4.1.2 does not support this syntax.

• Support is available in Impala v4.2.0 and later.

• Reference: IMPALA-11430

Authentication and User Mapping

• Auth-to-local mapping support

  • As of ODP 3.3.6.3-1, Kudu supports auth-to-local mapping.

  • Work is in progress to upstream this feature, expected in Kudu 1.18.x (not in 1.17.x).

• Older ODP versions

  • Kudu does not support local-to-auth mapping from core-site.xml.

  • Instead, it reads from /etc/krb5.conf if available.

  • This may cause issues with Ranger and Kerberos. Example:

    • If Spark runs as the spark user, but the Kerberos principal is spark-clustername, Ranger will receive spark-clustername instead of spark.

    • Since spark-clustername has no matching permissions, access is denied.

• Workarounds:

  1. Add the local-to-auth mapping to /etc/krb5.conf.

  2. Add a new user in Ranger matching the principal.

  3. Change the principal to match a local UNIX username.

  • Reference: KUDU-2198