Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns

Solved Go to solution
Highlighted

ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns

Explorer

Hello everyone,

need help please.

when i execute the following request on the impala-shell (Cloudera cdh5.16)

CREATE TABLE FCT_OC_ACTIVE_ALARMS_COUNTERS (

       TIME TIMESTAMP NOT NULL ENCODING RLE,

       OPERATIONCONTEXTID BIGINT NOT NULL ENCODING RLE,

       SEVERITYID BIGINT NOT NULL ENCODING RLE,

       ALARMTYPEID BIGINT NOT NULL,

       PROBABLECAUSEID BIGINT NOT NULL,

       SPECIFICPROBLEMSID BIGINT,

       MANAGEDOBJECTNAME STRING NOT NULL,

           YEARMONTH INT NOT NULL,

           NEXTDELTATIME TIMESTAMP,

       AOACKNOWLEDGED BIGINT,

       AOHANDLED BIGINT,

       AONOTHANDLED BIGINT,

       AOOUTSTANDING BIGINT,

       UPDATE_TIMESTAMP TIMESTAMP,

           PRIMARY KEY(TIME, OPERATIONCONTEXTID, SEVERITYID, ALARMTYPEID, PROBABLECAUSEID, MANAGEDOBJECTNAME, SPECIFICPROBLEMSID, YEARMONTH)

) PARTITION BY RANGE (YEARMONTH) (

  PARTITION VALUE = 202001

) STORED AS KUDU

 

it works perfectly. but when i execute the same on impala-shell (Cloudera cdh 6.3.2) i get the following error:

ERROR: ImpalaRuntimeException: Error creating Kudu table 'impala::ci_inta_fas_oss_installer_cdh6.FCT_OC_ACTIVE_ALARMS_COUNTERS'
CAUSED BY: ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns in the table (expected leading columns ('time', 'operationcontextid', 'severityid', 'alarmtypeid', 'probablecauseid', 'managedobjectname', 'specificproblemsid', 'yearmonth') but found ('time', 'operationcontextid', 'severityid', 'alarmtypeid', 'probablecauseid', 'specificproblemsid', 'managedobjectname', 'yearmonth'))

 

Did i mess something in my configuration on cdh 6.3 ?

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Re: ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns

Master Collaborator

You need to either change the order of the columns in your table definition or the PRIMARY KEY definition so that they match. In your statement you have the order of MANAGEDOBJECTNAME and SPECIFICPROBLEMSID reversed in the two places.

 

MANAGEDOBJECTNAME, SPECIFICPROBLEMSID, YEARMONTH

 

       SPECIFICPROBLEMSID BIGINT,

       MANAGEDOBJECTNAME STRING NOT NULL,

           YEARMONTH INT NOT NULL,

 

We made this stricter because it previously silently ignored the order of columns in the PRIMARY KEY clause, which can have really bad performance implications -  https://issues.apache.org/jira/browse/IMPALA-8283

View solution in original post

3 REPLIES 3

Re: ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns

Master Collaborator

You need to either change the order of the columns in your table definition or the PRIMARY KEY definition so that they match. In your statement you have the order of MANAGEDOBJECTNAME and SPECIFICPROBLEMSID reversed in the two places.

 

MANAGEDOBJECTNAME, SPECIFICPROBLEMSID, YEARMONTH

 

       SPECIFICPROBLEMSID BIGINT,

       MANAGEDOBJECTNAME STRING NOT NULL,

           YEARMONTH INT NOT NULL,

 

We made this stricter because it previously silently ignored the order of columns in the PRIMARY KEY clause, which can have really bad performance implications -  https://issues.apache.org/jira/browse/IMPALA-8283

View solution in original post

Highlighted

Re: ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns

Explorer

Excellent. This is the solution i've applied. But i was not able to explain why it does not work anymore with cdh6.

Thanks

Highlighted

Re: ImpalaRuntimeException: Kudu PRIMARY KEY columns must be specified as the first columns

Master Collaborator

We made this stricter because it was easy to create tables with the wrong primary key order, which has perf consequences.

 

It was really a bug that we allowed creating tables with unclear primary key order.

Don't have an account?
Coming from Hortonworks? Activate your account here