November 17, 2023

Summary:

Removal of the engine.hive.enabled property

Before this release:

The engine.hive.enabled property was set to "true" to enable the creation of Hive-enabled Iceberg table.

After this release:

The engine.hive.enabled property is removed because Hive is already supported and SQL engines are not required to explicitly specify this property.

Summary:

Change in Backup and Restore

Before this release:

When backing up and restoring CDW, temporarily deploying at least one Virtual Warehouse that runs 2023.0.14.0-15 or later to your environment was not needed to back up Hue.

After this release:

Under certain conditions, you must deploy a Virtual Warehouse that runs 2023.0.14.0-15 or later for a successful Hue backup. For more information, see "Automatically backing up the environment" and "Backing up Hue".

Summary:

Change in supported Instance Metadata Service (IMDS) version

Before this release:

CDP supported AWS EC2 instance metadata from a running instance using only Instance Metadata Service V1 (IMDSv1).

After this release:

To enhance security in CDW clusters, CDP supports Instance Metadata Service V2 (IMDSv2) only in CDW clusters. CDP provisions instances for CDW clusters with IMDSv2. CDP no longer supports IMDSv1. Cloudera has removed the capability to access metadata using IMDSv1 in CDW clusters.

Summary:

Change in the way dates are parsed from string by ignoring trailing invalid characters

Before this release:

HIVE-20007 introduced changes in the way dates were parsed from strings. SQL functions or date operations involving invalid dates returned "null".

After this release:

HIVE-27586 extracts and returns a valid date from a string value if there is a valid date prefix in the string. This fix partially restores the behavior changes introduced as part of HIVE-20007 and also makes the current behavior of handling trailing invalid characters more consistent.

The following table illustrates the behavior changes before and after the fix:

Strong value	Behavior (before HIVE-20007)	Previous behavior (after HIVE-20007)	Current behavior (after HIVE-27586)
2023-08-03_16:02:00	2023-08-03	null	2023-08-03
2023-08-03-16:02:00	2023-08-03	null	2023-08-03
2023-08-0316:02:00	2024-06-11	null	2023-08-03
03-08-2023	0009-02-12	null	0003-08-20
2023-08-03 GARBAGE	2023-08-03	2023-08-03	2023-08-03
2023-08-03TGARBAGE	2023-08-03	2023-08-03	2023-08-03
2023-08-03_GARBAGE	2023-08-03	null	2023-08-03

This change affects various Hive SQL functions and operators that accept dates from string values, such as CAST (V AS DATE), CAST (V AS TIMESTAMP), TO_DATE, DATE_ADD, DATE_DIFF, WEEKOFYEAR, DAYOFWEEK, and TRUNC.

Summary:

Change in the way date and timestamp values are parsed.

Before this release:

Some of the Hive date and timestamp functions, such as unix_timestamp(), from_unixtime(), date_format(), and cast() were enhanced to use the DateTimeFormatter class for printing and parsing date and timestamp objects. Prior to this change, these functions used the SimpleDateFormat class.

After this release:

Starting from this release, a new configurable hive.datetime.formatter property is introduced through HIVE-25576 that enables you to choose between SimpleDateFormat and DateTimeFormatter for the unix_timestamp, from_unixtime, and date_format SQL functions.

Although the DateTimeFormatter class is an improvement over SimpleDateFormat, some users may want to retain the old behavior to ensure compatibility after migration, therefore, making it necessary for introducing this property.

The possible values for the hive.datetime.formatter property are 'DATETIME' and 'SIMPLE' representing DateTimeFormatter and SimpleDateFormat respectively. The default value is set to 'DATETIME'.

Summary:

Change in creation of Database Catalog

Before this release:

Cloudera Data Warehouse (CDW) supported default and non-default Database Catalogs for the latest release. When creating a Database Catalog you selected the type of data lake, depending on how you intend to use CDW.

After this release:

CDW supports default Database Catalogs only, and when you activate the Virtual Warehouse, the Database Catalog is created. A data lake is transparently associated with your Database Catalog based on your activation settings, such as managed storage access, and other factors. You no longer need to select a type of data lake.