Member since
09-28-2016
8
Posts
1
Kudos Received
0
Solutions
11-19-2018
02:24 PM
Hi @scuffster There are some interesting issues here with the different numeric data types here - INT, DOUBLE, DECIMAL, etc. The behaviour you're seeing is because the first input to round() is a DOUBLE expression, which cannot exactly represent all decimal values. Generally the output type of the round() function is the same as the input type. Impala does support precise decimal arithmetic with the DECIMAL type. If you are operating on DECIMAL columns or you cast the input to a decimal type with the right precision and scale, you may get the behaviour you're hoping for. Here's a query showing the type of your expressions and an alternative version with a cast to DECIMAL: > select typeof(269586/334026 * 100), typeof(round(269586/334026 * 100, 2)), round(269586/334026 * 100, 2), round(cast(269586/334026 * 100 as DECIMAL(20, 8)), 2);
+-------------------------------+-----------------------------------------+---------------------------------+--------------------------------------------------------+
| typeof(269586 / 334026 * 100) | typeof(round(269586 / 334026 * 100, 2)) | round(269586 / 334026 * 100, 2) | round(cast(269586 / 334026 * 100 as decimal(20,8)), 2) |
+-------------------------------+-----------------------------------------+---------------------------------+--------------------------------------------------------+
| DOUBLE | DOUBLE | 80.70999999999999 | 80.71 |
+-------------------------------+-----------------------------------------+---------------------------------+--------------------------------------------------------+
... View more
09-13-2018
10:25 AM
There is now a way to do this with .impalarc using the following: [impala.query_options] REQUEST_POOL=mypoolname
... View more
02-09-2018
11:46 PM
Thanks for you reply. I try to SET MT_DOP=0; before compute stats and it works! The impalad does not crash any more althougth compute stats still fail due to incompataible schema.
... View more
08-28-2017
09:03 AM
@hindog wrote: "Nor the browser column" -- What if the "browser" column WAS the primary key? Would increment be possible in similar fashion to upsert, the difference being that internally Kudu would read the existing value and add it to the increment value before saving? The other Kudu limitation that this runs into is that row key columns cannot be modified. It would be somewhat easier to implement atomic increments on non-key columns, but then that means doing a lot of updates and it's not something Kudu excels at e.g. it supports modifying data but the higher the rate the slower the reads are.
... View more
06-12-2017
10:20 AM
It is by design. The impala-shell scripts calls out that it will look in the current working directory. Either workaround it or submit a request or submit your change back to the Apache Impala project.
... View more
10-10-2016
09:55 AM
Hey, This looks like a bug and can be reproduced even on the latest versions of Impala. Thanks for sharing the repro steps with us. I created a jira https://issues.cloudera.org/browse/IMPALA-4266 with a simpler UDF so its easy to follow. Your UDF implementation looks fine and is likely not causing this issue. - Bharath
... View more