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