@Rak ,   I'm suspecting you are using Impala, because of the statement of the values returning null, but please confirm so I can properly label this question so others can see it.   Please see the following in the Impala documentation regarding the proper format for casting a string into a timestamp datatype:   https://docs.cloudera.com/documentation/enterprise/latest/topics/impala_timestamp.html   Restrictions: If you cast a  STRING  with an unrecognized format to a  TIMESTAMP , the result is  NULL  rather than an error. Make sure to test your data pipeline to be sure any textual date and time values are in a format that Impala  TIMESTAMP  can recognize. Currently, Avro tables cannot contain  TIMESTAMP  columns. If you need to store date and time values in Avro tables, as a workaround you can use a  STRING  representation of the values, convert the values to  BIGINT  with the  UNIX_TIMESTAMP()  function, or create separate numeric columns for individual date and time fields using the  EXTRACT()  function. Examples: The following examples demonstrate using  TIMESTAMP  values with built-in functions: select cast('1966-07-30' as timestamp); select cast('1985-09-25 17:45:30.005' as timestamp); select cast('08:30:00' as timestamp); select hour('1970-01-01 15:30:00'); -- Succeeds, returns 15. select hour('1970-01-01 15:30'); -- Returns NULL because seconds field required. select hour('1970-01-01 27:30:00'); -- Returns NULL because hour value out of range. select dayofweek('2004-06-13'); -- Returns 1, representing Sunday. select dayname('2004-06-13'); -- Returns 'Sunday'. select date_add('2004-06-13', 365); -- Returns 2005-06-13 with zeros for hh:mm:ss fields. select day('2004-06-13'); -- Returns 13. select datediff('1989-12-31','1984-09-01'); -- How many days between these 2 dates? select now(); -- Returns current date and time in local timezone.   ... View more

I wanted to interject that while both the above are definite valid possible causes of Oozie jobs stuck in PREP state, there may be several other possible causes which may need to be resolved such as:   1.  Issues with the Yarn Resource Manager / MR Job Tracker, lack of resources either for the RM or queues for the user running the job. 2.  Problems with the Oozie server getting to the oozie database server, the database server itself, or locks on tables. 3.  Lack of resources to Oozie such as callable queues, java heap, GC thrashing, etc.   The above is a brief shortlist from review of support cases relating to Oozie jobs stuck in PREP.   I want to emphasize that deleting records from the Oozie database should be ONLY done the last resort to solving this problem, and only needed if you have a very large mass of oozie workflows that cannot be killed in a timely fashion by an oozie CLI script.   This should be only done at the direction of support, people knowledgeable with SQL, and the relationship between tables, columns, and rows in the oozie database as referential integrity and constraints are lacking in the schema design.  The above post from 2017 also missed one key table COORD_ACTIONS, where if this data was not properly cleaned up, would break your Oozie purge and possibly cause other serious problems. ... View more

As upsert is not SQL-92 syntax, the Impala JDBC driver does not currently support it.   However, we are currently testing a newer version of JDBC driver and hope to support upsert in the near future.  For the time being, please break these statements into a combination of insert and update statements. ... View more

Yes, I found the jar in other places, I remove the link, now the oozie web ui work fine! Thank you! Now I try to fix the oozie ha problem. ... View more

In the Sentry logs, shows this error:   mismatch: Client thrift version is: 1 , server thrift version is 2   In Impala, it throws this error:   org.apache.impala.catalog.AuthorizationException: User 'xxxxx' does not have privileges to access: server   I tried to see if there is any mismatch in the cloudera libraries but didnt find anything... Any clue about it?  ... View more

There is no new product name.  This will be a new feature within Sentry called Attribute Based Access Control using Navigator Lineage tags for metadata.  At present, there is no estimated release date, but we will be sure to announce that. ... View more