Member since
10-16-2013
307
Posts
77
Kudos Received
59
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
10119 | 04-17-2018 04:59 PM | |
5004 | 04-11-2018 10:07 PM | |
2916 | 03-02-2018 09:13 AM | |
20011 | 03-01-2018 09:22 AM | |
2108 | 02-27-2018 08:06 AM |
01-19-2016
10:27 PM
Yes, Impala is throwing that error. Impala has a few hard limitations on (1) the number of children an expression can have and (2) the depth of the expression tree. You can typically work around the problem by rephrasing the huge expression as a join on a new table. For example, in your example, you'd have something like: create table grid { lat_lower_bound double, lat_upper_bound double, long_lower_bound double, long_lower_bound } and then select ... from original_table t, grid g where t.longitude between g.lat_lower_bound and g.lat_upper_bound and t.latitute between g.long_lower_bound and g.long_upper_bound
... View more
01-13-2016
11:03 PM
1 Kudo
1. It's on our radar, but we don't have concrete plans yet. 2. Impala does not do query plan or result caching, so the differences you see are not due to Impala doing caching. There could be several reasons why you see a difference among runs, e.g., the OS buffer cache warming up The first step would be to study the runtime profiles of those queries. The exec summary is often enough to determine where time was saved the second time around,
... View more
01-13-2016
10:39 PM
1 Kudo
1. Impala does not support bucketed tables. 2. Your first run is likely slow because Impala first needs to load the table metadata from the catalogd (as explain in another thread). After the first reference to the table, the metadata is cached. So when perf testing you should discard the first run, unless you specifically want to test performance on a cold cache (which seems weird).
... View more
01-12-2016
09:59 PM
Those are all valid and understandable points, thanks for filing the JIRA and your feedback!
... View more
01-12-2016
07:06 PM
Hi! I'm afraid that Impala currently does not support resolving schema-to-file metadata by name - it does so only by index. There are tradeoffs between the two approaches, i.e., what ALTER TABLE operations are allowed. There's an old but still relevant and interesting discussion on this topic here: https://issues.cloudera.org/browse/IMPALA-779 For the time being, there is no way to make resolution by name work, but it's a frequently requested feature that we will consider adding. Alex
... View more
01-07-2016
05:23 PM
Yea :). Thanks everyone for your reports and JIRA contricutions!
... View more
01-07-2016
11:49 AM
Thanks for reporting this issue and filing a JIRA! Much appreciated 😉
... View more
01-07-2016
08:55 AM
Hi! I confirm that this is a problem in Impala 2.3. It stems from the fact that the type is stored as a string inside the Hive Metastore, and upon table loading, Impala parses the string into an internal representation. However, the types stored inside the Metastore are not quoted, so Impala fails to parse the reserved words. Would you mind filing a JIRA for this https://issues.cloudera.org with the info you provided below and my response above? Thanks! Alex
... View more
01-06-2016
11:27 PM
Hi! HBase tables are range partitioned by the key and Impala will do the equivalent of "partition pruning" for HBase resions if suitable predicates are available in the query. The "PARTITION" concept of HDFS tables is not really applicable to HBase tables. The docs explain this in more detail, including how to interpred Impala's explain plan to see whether region pruning is taking place or not: http://www.cloudera.com/content/www/en-us/documentation/archive/impala/2-x/2-1-x/topics/impala_hbase.html Does that answer your question?
... View more
01-06-2016
12:18 AM
1 Kudo
At the moment you cannot really prevent this issue. It is a warning indicating that some calculations may not be accurate due to overflow (e.g., when multiplying very large cardinalities). The values will be capped at MAX_LONG. If you don't have reason to believe that your query plans are bad because of this overflow, then I would not worry about those warnings.
... View more