Amazon EMR release 6.4.0

• Application versions in Amazon EMR 7.x releases

• Application versions in Amazon EMR 6.x releases

• Application versions in Amazon EMR 5.x releases

• Application versions in Amazon EMR 4.x releases

Supported applications

• Amazon SDK for Java version 1.12.31

• CloudWatch Sink version 2.2.0

• DynamoDB Connector version 4.16.0

• EMRFS version 2.47.0

• Amazon EMR Goodies version 3.2.0

• Amazon EMR Kinesis Connector version 3.5.0

• Amazon EMR Record Server version 2.1.0

• Amazon EMR Scripts version 2.5.0

• Flink version 1.13.1

• Ganglia version 3.7.2

• Amazon Glue Hive Metastore Client version 3.3.0

• Hadoop version 3.2.1-amzn-4

• HBase version 2.4.4-amzn-0

• HBase-operator-tools 1.1.0

• HCatalog version 3.1.2-amzn-5

• Hive version 3.1.2-amzn-5

• Hudi version 0.8.0-amzn-0

• Hue version 4.9.0

• Java JDK version Corretto-8.302.08.1 (build 1.8.0_302-b08)

• JupyterHub version 1.4.1

• Livy version 0.7.1-incubating

• MXNet version 1.8.0

• Oozie version 5.2.1

• Phoenix version 5.1.2

• Pig version 0.17.0

• Presto version 0.254.1-amzn-0

• Trino version 359

• Apache Ranger KMS (multi-master transparent encryption) version 2.0.0

• ranger-plugins 2.0.1-amzn-0

• ranger-s3-plugin 1.2.0

• SageMaker Spark SDK version 1.4.1

• Scala version 2.12.10 (OpenJDK 64-Bit Server VM, Java 1.8.0_282)

• Spark version 3.1.2-amzn-0

• spark-rapids 0.4.1

• Sqoop version 1.4.7

• TensorFlow version 2.4.1

• tez version 0.9.2

• Zeppelin version 0.9.0

• Zookeeper version 3.5.7

• Connectors and drivers: DynamoDB Connector 4.16.0

New features

• [Managed scaling] Spark shuffle data managed scaling optimization - For Amazon EMR versions 5.34.0 and later, and EMR versions 6.4.0 and later, managed scaling is now Spark shuffle data aware (data that Spark redistributes across partitions to perform specific operations). For more information on shuffle operations, see Using EMR managed scaling in Amazon EMR in the Amazon EMR Management Guide and Spark Programming Guide.

• On Apache Ranger-enabled Amazon EMR clusters, you can use Apache Spark SQL to insert data into or update the Apache Hive metastore tables using INSERT INTO, INSERT OVERWRITE, and ALTER TABLE. When using ALTER TABLE with Spark SQL, a partition location must be the child directory of a table location. Amazon EMR does not currently support inserting data into a partition where the partition location is different from the table location.

• PrestoSQL has been renamed to Trino.

• Hive: Execution of simple SELECT queries with LIMIT clause are accelerated by stopping the query execution as soon as the number of records mentioned in LIMIT clause is fetched. Simple SELECT queries are queries that do not have GROUP BY / ORDER by clause or queries that do not have a reducer stage. For example, SELECT * from <TABLE> WHERE <Condition> LIMIT <Number>.

Hudi Concurrency Control

• Hudi now supports Optimistic Concurrency Control (OCC), which can be leveraged with write operations like UPSERT and INSERT to allow changes from multiple writers to the same Hudi table. This is file-level OCC, so any two commits (or writers) can write to the same table, if their changes do not conflict. For more information, see the Hudi concurrency control.

• Amazon EMR clusters have Zookeeper installed, which can be leveraged as the lock provider for OCC. To make it easier to use this feature, Amazon EMR clusters have the following properties pre-configured:

  hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.ZookeeperBasedLockProvider
  hoodie.write.lock.zookeeper.url=<EMR Zookeeper URL>
  hoodie.write.lock.zookeeper.port=<EMR Zookeeper Port>
  hoodie.write.lock.zookeeper.base_path=/hudi

  To enable OCC, you need to configure the following properties either with their Hudi job options or at the cluster-level using the Amazon EMR configurations API:

  hoodie.write.concurrency.mode=optimistic_concurrency_control
  hoodie.cleaner.policy.failed.writes=LAZY (Performs cleaning of failed writes lazily instead of inline with every write)
  hoodie.write.lock.zookeeper.lock_key=<Key to uniquely identify the Hudi table> (Table Name is a good option)

Hudi Monitoring: Amazon CloudWatch integration to report Hudi Metrics

• Amazon EMR supports publishing Hudi Metrics to Amazon CloudWatch. It is enabled by setting the following required configurations:

  hoodie.metrics.on=true
  hoodie.metrics.reporter.type=CLOUDWATCH

• The following are optional Hudi configurations that you can change:

  Setting	Description	Value
  hoodie.metrics.cloudwatch.report.period.seconds	Frequency (in seconds) at which to report metrics to Amazon CloudWatch	Default value is 60s, which is fine for the default one minute resolution offered by Amazon CloudWatch
  hoodie.metrics.cloudwatch.metric.prefix	Prefix to be added to each metric name	Default value is empty (no prefix)
  hoodie.metrics.cloudwatch.namespace	Amazon CloudWatch namespace under which metrics are published	Default value is Hudi
  hoodie.metrics.cloudwatch.maxDatumsPerRequest	Maximum number of datums to be included in one request to Amazon CloudWatch	Default value is 20, which is same as Amazon CloudWatch default

Amazon EMR Hudi configurations support and improvements

• Customers can now leverage EMR Configurations API and Reconfiguration feature to configure Hudi configurations at cluster level. A new file based configuration support has been introduced via /etc/hudi/conf/hudi-defaults.conf along the lines of other applications like Spark, Hive etc. EMR configures few defaults to improve user experience:

  — hoodie.datasource.hive_sync.jdbcurl is configured to the cluster Hive server URL and no longer needs to be specified. This is particularly useful when running a job in Spark cluster mode, where you previously had to specify the Amazon EMR master IP.

  — HBase specific configurations, which are useful for using HBase index with Hudi.

  — Zookeeper lock provider specific configuration, as discussed under concurrency control, which makes it easier to use Optimistic Concurrency Control (OCC).

• Additional changes have been introduced to reduce the number of configurations that you need to pass, and to infer automatically where possible:

  — The partitionBy keyword can be used to specify the partition column.

  — When enabling Hive Sync, it is no longer mandatory to pass HIVE_TABLE_OPT_KEY, HIVE_PARTITION_FIELDS_OPT_KEY, HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY. Those values can be inferred from the Hudi table name and partition field.

  — KEYGENERATOR_CLASS_OPT_KEY is not mandatory to pass, and can be inferred from simpler cases of SimpleKeyGenerator and ComplexKeyGenerator.

Hudi Caveats

• Hudi does not support vectorized execution in Hive for Merge on Read (MoR) and Bootstrap tables. For example, count(*) fails with Hudi realtime table when hive.vectorized.execution.enabled is set to true. As a workaround, you can disable vectorized reading by setting hive.vectorized.execution.enabled to false.

• Multi-writer support is not compatible with the Hudi bootstrap feature.

• Flink Streamer and Flink SQL are experimental features in this release. These features are not recommended for use in production deployments.

Changes, enhancements, and resolved issues

This is a release to fix issues with Amazon EMR Scaling when it fails to scale up/scale down a cluster successfully or causes application failures.

• Previously, manual restart of the resource manager on a multi-master cluster caused Amazon EMR on-cluster daemons, like Zookeeper, to reload all previously decommissioned or lost nodes in the Zookeeper znode file. This caused default limits to be exceeded in certain situations. Amazon EMR now removes the decommissioned or lost node records older than one hour from the Zookeeper file and the internal limits have been increased.

• Fixed an issue where scaling requests failed for a large, highly utilized cluster when Amazon EMR on-cluster daemons were running health checking activities, such as gathering YARN node state and HDFS node state. This was happening because on-cluster daemons were not able to communicate the health status data of a node to internal Amazon EMR components.

• Improved EMR on-cluster daemons to correctly track the node states when IP addresses are reused to improve reliability during scaling operations.

• SPARK-29683. Fixed an issue where job failures occurred during cluster scale-down as Spark was assuming all available nodes were deny-listed.

• YARN-9011. Fixed an issue where job failures occurred due to a race condition in YARN decommissioning when cluster tried to scale up or down.

• Fixed issue with step or job failures during cluster scaling by ensuring that the node states are always consistent between the Amazon EMR on-cluster daemons and YARN/HDFS.

• Fixed an issue where cluster operations such as scale down and step submission failed for Amazon EMR clusters enabled with Kerberos authentication. This was because the Amazon EMR on-cluster daemon did not renew the Kerberos ticket, which is required to securely communicate with HDFS/YARN running on the primary node.

• Configuring a cluster to fix Apache YARN Timeline Server version 1 and 1.5 performance issues

  Apache YARN Timeline Server version 1 and 1.5 can cause performance issues with very active, large EMR clusters, particularly with yarn.resourcemanager.system-metrics-publisher.enabled=true, which is the default setting in Amazon EMR. An open source YARN Timeline Server v2 solves the performance issue related to YARN Timeline Server scalability.

  Other workarounds for this issue include:

  • Configuring yarn.resourcemanager.system-metrics-publisher.enabled=false in yarn-site.xml.

  • Enabling the fix for this issue when creating a cluster, as described below.

  The following Amazon EMR releases contain a fix for this YARN Timeline Server performance issue.

  EMR 5.30.2, 5.31.1, 5.32.1, 5.33.1, 5.34.x, 6.0.1, 6.1.1, 6.2.1, 6.3.1, 6.4.x

  To enable the fix on any of the above specified Amazon EMR releases, set these properties to true in a configurations JSON file that is passed in using the aws emr create-cluster command parameter: --configurations file://./configurations.json. Or enable the fix using the reconfiguration console UI.

  Example of the configurations.json file contents:

  [
  {
  "Classification": "yarn-site",
  "Properties": {
  "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch": "true",
  "yarn.resourcemanager.system-metrics-publisher.enabled": "true"
  },
  "Configurations": []
  }
  ]

• WebHDFS and HttpFS server are disabled by default. You can re-enable WebHDFS using the Hadoop configuration, dfs.webhdfs.enabled. HttpFS server can be started by using sudo systemctl start hadoop-httpfs.

• HTTPS is now enabled by default for Amazon Linux repositories. If you are using an Amazon S3 VPCE policy to restrict access to specific buckets, you must add the new Amazon Linux bucket ARN arn:aws:s3:::amazonlinux-2-repos-$region/* to your policy (replace $region with the region where the endpoint is). For more information, see this topic in the Amazon discussion forums. Announcement: Amazon Linux 2 now supports the ability to use HTTPS while connecting to package repositories .

• Hive: Write query performance is improved by enabling the use of a scratch directory on HDFS for the last job. The temporary data for final job is written to HDFS instead of Amazon S3 and performance is improved because the data is moved from HDFS to the final table location (Amazon S3) instead of between Amazon S3 devices.

• Hive: Query compilation time improvement up to 2.5x with Glue metastore Partition Pruning.

• By default, when built-in UDFs are passed by Hive to the Hive Metastore Server, only a subset of those built-in UDFs are passed to the Glue Metastore since Glue supports only limited expression operators. If you set hive.glue.partition.pruning.client=true, then all partition pruning happens on the client side. If the you set hive.glue.partition.pruning.server=true, then all partition pruning happens on the server side.

Known issues

• Hue queries do not work in Amazon EMR 6.4.0 because Apache Hadoop HttpFS server is disabled by default. To use Hue on Amazon EMR 6.4.0, either manually start HttpFS server on the Amazon EMR primary node using sudo systemctl start hadoop-httpfs, or use an Amazon EMR step.

• The Amazon EMR Notebooks feature used with Livy user impersonation does not work because HttpFS is disabled by default. In this case, the EMR notebook cannot connect to the cluster that has Livy impersonation enabled. The workaround is to start HttpFS server before connecting the EMR notebook to the cluster using sudo systemctl start hadoop-httpfs.

• In Amazon EMR version 6.4.0, Phoenix does not support the Phoenix connectors component.

• To use Spark actions with Apache Oozie, you must add the following configuration to your Oozie workflow.xml file. Otherwise, several critical libraries such as Hadoop and EMRFS will be missing from the classpath of the Spark executors that Oozie launches.

  <spark-opts>--conf spark.yarn.populateHadoopClasspath=true</spark-opts>

• When you use Spark with Hive partition location formatting to read data in Amazon S3, and you run Spark on Amazon EMR releases 5.30.0 to 5.36.0, and 6.2.0 to 6.9.0, you might encounter an issue that prevents your cluster from reading data correctly. This can happen if your partitions have all of the following characteristics:

  • Two or more partitions are scanned from the same table.

  • At least one partition directory path is a prefix of at least one other partition directory path, for example, s3://bucket/table/p=a is a prefix of s3://bucket/table/p=a b.

  • The first character that follows the prefix in the other partition directory has a UTF-8 value that’s less than than the / character (U+002F). For example, the space character (U+0020) that occurs between a and b in s3://bucket/table/p=a b falls into this category. Note that there are 14 other non-control characters: !"#$%&‘()*+,-. For more information, see UTF-8 encoding table and Unicode characters.

  As a workaround to this issue, set the spark.sql.sources.fastS3PartitionDiscovery.enabled configuration to false in the spark-defaults classification.