No I don't think you're missing any obvious optimisation. Yes we only use a single core per aggregation per Impala daemon. This is obviously not ideal so we have a big push right now to do full parallelization of every operator. ... View more

This is a known issue that we're actively working on: https://issues.cloudera.org/browse/IMPALA-2567   Your analysis is accurate. Part of the problem is the number of connections and the other part is the # of threads per connection. You may be able to change some operating system config settings to increase limits here (depending on which limit you're hitting).   In order to reduce the # of tcp conncetions required you would either need to reduce the number of fragments or reduce the number of node executing the query.   You could reduce the # of fragments by breaking up the query into smaller queries. E.g. creating temporary tables with the results of some of the subqueries.  You could also try executing the query on a single node by setting num_nodes=1 if the data size is small enough that this makes sense. I suspect your query is too large for that to work, but it's hard to tell (that's a huge query plan!) ... View more

I'm not the most knowledgeable person about this part of the code, but what you're saying is correct. One of the likely causes of long wait times is if the receiver is consuming data slower than the sender is sending it. ... View more

I think we already have an open issue for this that is being actively worked on https://issues.cloudera.org/browse/IMPALA-3210   I.e. we don't support it yet but it's in the pipeline. ... View more

The only way to do this with zero work would be to use a view. http://www.cloudera.com/documentation/enterprise/latest/topics/impala_create_view.html    Otherwise you do have to run the queries as part of your data pipeline as you mentioned.     ... View more

The main difference seems to be execution skew. In the second profile the max time for the join is over 3 minutes, compared to much lower in first profile. The average time isn't very different between the profiles. Probably the partitioning resulted in the data being distributed differently between the nodes, and for some reason that one node is slower. It doesn't look like it's necessarily processing more data, but maybe the node is more heavily loaded, or the data is somehow different.   Is the join condition something complicated? It's only processing a few thousand rows per second through the join, which is very low. ... View more