Hi @cardozogp , With sqoop import (DB -> HDFS) sqoop will submit just a couple of (or in range of max 100s) of queries to the database: - 1 query to get the table schema - a couple of queries to determine the split ranges (see "split-by") - and every mapper starts 1 select statement with their own split key range. The mappers from then on just call "getNext" on the result sets to fetch the next batch of results from the DB.   With sqoop export (HDFS->DB) however the mappers are calling separate insert statements for every "batch" (~100 s of records), so there may be millions of insert statements submitted, in that case this indeed has an impact.   As there are really just a few queries in play with sqoop import, the usage of prepared statements does not have a significant benefit. Let us know if your DBA team has some other insights which we may not be aware of.   Best regards  Miklos ... View more

Hi, This use case seems to be similar to queries which have a filter "WHERE 1=0" - those also do not return any data. See for example such a discussion why that is needed/used in some places: https://stackoverflow.com/questions/9140606/why-would-you-use-where-1-0-statement-in-sql My best guess would be that the application calling such queries needs the schema of the result set in advance - for example to create and render the layout (columns) or autofilters or to prepare another subsequent query properly (for example it has to do some decisions - which filters the next query needs to contain, maybe they are different for a string and for a date column, etc)   Best regards  Miklos   Miklos Szurap Customer Operations Engineer, Cloudera ... View more

Hi, the complex MAP data type is supported, however it may not be as usable as other simple types. Please see: https://docs.cloudera.com/runtime/7.2.10/impala-sql-reference/topics/impala-map.html and https://docs.cloudera.com/runtime/7.2.10/impala-sql-reference/topics/impala-complex-types.html#complex_types/complex_sample_schema  There is a similar "GET_JSON_OBJECT" built-in UDF, which may help you - depending what you need to achieve, please see: https://docs.cloudera.com/runtime/7.2.10/impala-sql-reference/topics/impala-misc-functions.html#misc_functions__get_json_object  ... View more

You've mentioned that even if you intentionally "break" the workflow with changing the class name it still does not throw an error message. Can you check what's in the workflow.xml when you change the workflow? This would help to decide is Hue not saving the workflow properly or is the logging broken only. Is the workflow successful even with a wrong classname? ... View more

Hi Zara,   You need to check a couple of things - which may give more clues on the why. 1. Are you using the latest Hive JDBC driver? (is it HDP or CDH/CDP?)  Check out https://www.cloudera.com/downloads/connectors/hive/jdbc/2-6-11.html 2. Do you get the same error if you use backticks for the database name and/or for the table name? select count(*) from `dbname`.`tablename` where partition_key='xxxxx'; 3. Did you look at the HiveServer2 logs? What do they show you? What was the real query submitted to the HS2 and what was the failure there? What does it look like for a non-partitioned table? 4. The "UseNativeQuery" option of the JDBC driver sometimes can solve such interesting issues - as it is a flag whether the Hive query is already translated to a Hive native format. Check the docs. https://docs.cloudera.com/documentation/other/connectors/hive-jdbc/2-6-11/Cloudera-JDBC-Driver-for-Apache-Hive-Install-Guide.pdf 5. Also you can turn on debug level logs at the JDBC driver side, see LogLevel and LogPath JDBC connection string properties. ... View more