How did you solve this ? We are seeing - HIVE_BAD_DATA: Field UPDATETIME's type INT96 in parquet is incompatible with type string defined in table schema ... View more

Hi @Big   I checked on our latest build and it works for me - see below. Are you sure that you're not trying to query a table with a DATE type column?   [localhost:21000] default> create table foo2 (`date` int); Query: create table foo2 (`date` int) +-------------------------+ | summary | +-------------------------+ | Table has been created. | +-------------------------+ Fetched 1 row(s) in 1.19s [localhost:21000] default> select distinct `date` from foo2; Query: select distinct `date` from foo2 Fetched 0 row(s) in 0.12s ... View more

Nad1998, that's a different error - it means your 'products' table does not exist or is not visible to Impala (try running 'invalidate metadata products', then retry query). ... View more

This is my testing result at the Hadoop master node which used for namenode and hive server2.   When I executing beeline for local file loading to a table, I met same error. It was the permission issue on the file to the hive user which is the owner of HiveServer2 process.   It was solve when I grant read permission the file including whole path.   Please check the file accessible permission as this. sudo -u hive cat ~/test.txt     ... View more

In that case, can you suggest a way to speed up the SSL communication with Impala ? Currently we are using Tableau to extract data from Impala. And with SSL activated, the data extraction is at least 30x to 100x slower than before. Did you see this behavior ? Do you have a remedy for it ? Thanks in advance. ... View more

No, I directly added --ldap_domain=YourDomainName in Impala Daemon Command Line Argument Advanced Configuration Snippet (Safety Valve) field. ... View more

Hi Sreeman -    You're right, this is unrelated to Kerberos. The Impala shell is able to detect a Kerberos ticket in the cache, and tries to authenticate using that even though Kerberos isn't specified on the remote host. I think this is probably a bug if a separate kind of authentication (i.e. LDAP) is specified.   What's probably happening is that the password you are typing is not recognised for the user. The reason for that with LDAP is usually that the userid you're trying isn't actually the userid present in the LDAP database. For example, many deployments require usernames in the form user@DOMAIN.COM.   In Impala 1.4, there are options to map short userids onto the longer strings that an LDAP server requires. See http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Installing-and-Using-Impala/ciiu_ldap.html, under "Support for custom bind strings".    Best, Henry ... View more