passing hive-site.xml to the workflow resolves this. ... View more

  Below is the error message i received .   1137 2017-11-07 03:55:11,536  [INFO ] There are no more tasks to run at this time 1138 Starting Impala Shell without Kerberos authentication 1140 Server version: impalad version 2.6.0-cdh5.8.4 RELEASE (build 207450616f75adbe082a4c2e1145a2384da83fa6) 1141 Invalidating Metadata 1142 Query: invalidate metadata 1143 1144 Fetched 0 row(s) in 4.11s 1145 Query: use `DBNAME` 1146 Query: insert overwrite table Table partition(recordtype) select adid,seg,profile,livecount, 1147 count(distinct mc) as nofs,stbnt,1 from table1 where livecount<>0 group by adid,seg,profile,livecount,stbnt 1148 WARNINGS: 1149 CatalogException: Table 'dbname.table' was modified while operation was in progress, aborting execution. 1150 1151 ... View more

Can you try to kinit at the beginning of your script, in R e.g. system("kinit username@REALM.COM -k -t username.keytab") Have you generated keytab on your own or got it from admin? ... View more

Hello, Receiving "Results Expired" error in Hue for Impala queries, is usually a symptom of having a misconfigured load-balancer in front of Impala. Impala has the assumption, that the query results will be downloaded from the same impalad where the query was issued. A load-balancer can break that assumption, if it sendis sequential connections of the same client to different impalad daemons. If Hue connects two a different impalads to run the query and download the results, the "Results Expired" error will appear. To avoid the above issue, it's required that the proxy routes subsequent connections of the same client to the same impalad. This proxy behavior is usually called sticky sessions. Our documentation has detailed information about impala load-balancer setup, includeing the above information as well: https://www.cloudera.com/documentation/enterprise/latest/topics/impala_proxy.html#proxy_overview ... View more

That query probably has multiple big joins and aggregations and needs more memory to complete. A very rough rule of thumb for minimum memory in releases CDH5.9-CDH5.12 is the following.   For each hash join, the minimum of 150MB or the amount of data on the right side of the node (e.g. if you have a few thousand rows on the right side, maybe a MB or two). For each merge aggregation, the minimum of 300MB or the size of grouped data in-memory (e.g. if you only have a few thousand groups, maybe a MB or two). For each sort, about 50-60MB For each analytic, about 20MB If you add all those up and add another 25% you'll get a ballpark number for how much memory the query will require to execute.   I'm working on reducing those numbers and making the system give a clearer yes/no answer on whether it can run the query before it starts executing. ... View more

JDBC Kerberos Ticket. Let me know, if you have any insight http://community.cloudera.com/t5/Interactive-Short-cycle-SQL/impala-kerberosed-jdbc-connection-from-SQL-Workbench-on-Windows/m-p/46415#M2142 ... View more

Thanks for sharing the root cause 🙂 ... View more