Amazon EMR release 6.3.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

• AWS SDK for Java version 1.11.977

• CloudWatch Sink version 2.1.0

• DynamoDB Connector version 4.16.0

• EMRFS version 2.46.0

• Amazon EMR Goodies version 3.2.0

• Amazon EMR Kinesis Connector version 3.5.0

• Amazon EMR Record Server version 2.0.0

• Amazon EMR Scripts version 2.5.0

• Flink version 1.12.1

• Ganglia version 3.7.2

• AWS Glue Hive Metastore Client version 3.2.0

• Hadoop version 3.2.1-amzn-3

• HBase version 2.2.6-amzn-1

• HBase-operator-tools 1.0.0

• HCatalog version 3.1.2-amzn-0

• Hive version 3.1.2-amzn-4

• Hudi version 0.7.0-amzn-0

• Hue version 4.9.0

• Java JDK version Corretto-8.282.08.1 (build 1.8.0_282-b08)

• JupyterHub version 1.2.0

• Livy version 0.7.0-incubating

• MXNet version 1.7.0

• Oozie version 5.2.1

• Phoenix version 5.0.0

• Pig version 0.17.0

• Presto version 0.245.1-amzn-0

• PrestoSQL version 350

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

• ranger-plugins 2.0.1-amzn-0

• ranger-s3-plugin 1.1.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.1-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.4.14

• Connectors and drivers: DynamoDB Connector 4.16.0

New features

• Amazon EMR supports Amazon S3 Access Points, a feature of Amazon S3 that allows you to easily manage access for shared data lakes. Using your Amazon S3 Access Point alias, you can simplify your data access at scale on Amazon EMR. You can use Amazon S3 Access Points with all versions of Amazon EMR at no additional cost in all AWS regions where Amazon EMR is available. To learn more about Amazon S3 Access Points and Access Point aliases, see Using a bucket-style alias for your access point in the Amazon S3 User Guide.

• New DescribeReleaseLabel and ListReleaseLabel API parameters provide Amazon EMR release label details. You can programmatically list releases available in the region where the API request is run, and list the available applications for a specific Amazon EMR release label. The release label parameters also list Amazon EMR releases that support a specified application, such as Spark. This information can be used to programmatically launch Amazon EMR clusters. For example, you can launch a cluster using the latest release version from the ListReleaseLabel results. For more information, see DescribeReleaseLabel and ListReleaseLabels in the Amazon EMR API Reference.

• With Amazon EMR 6.3.0, you can launch a cluster that natively integrates with Apache Ranger. Apache Ranger is an open-source framework to enable, monitor, and manage comprehensive data security across the Hadoop platform. For more information, see Apache Ranger. With native integration, you can bring your own Apache Ranger to enforce fine-grained data access control on Amazon EMR. See Integrate Amazon EMR with Apache Ranger in the Amazon EMR Management Guide.

• Scoped managed policies: To align with AWS best practices, Amazon EMR has introduced v2 EMR-scoped default managed policies as replacements for policies that will be deprecated. See Amazon EMR Managed Policies.

• Instance Metadata Service (IMDS) V2 support status: For Amazon EMR 6.2 or later, Amazon EMR components use IMDSv2 for all IMDS calls. For IMDS calls in your application code, you can use both IMDSv1 and IMDSv2, or configure the IMDS to use only IMDSv2 for added security. If you disable IMDSv1 in earlier Amazon EMR 6.x releases, it causes cluster startup failure.

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.

• 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.

• Newer Amazon EMR releases fix the issue with a lower "Max open files" limit on older AL2 in Amazon EMR. Amazon EMR releases 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 and later now include a permanent fix with a higher "Max open files" setting.

• Spark SQL UI explain mode default changed from extended to formatted in Spark 3.1. Amazon EMR reverted it back to extended to include logical plan information in the Spark SQL UI. This can be reverted by setting spark.sql.ui.explainMode to formatted.

• The following commits were backported from the Spark master branch.

  - [SPARK-34752][BUILD] Bump Jetty to 9.4.37 to address CVE-2020-27223.

  - [SPARK-34534] Fix blockIds order when use FetchShuffleBlocks to fetch blocks.

  - [SPARK-34681] [SQL] Fix bug for full outer shuffled hash join when building left side with non-equal condition.

  - [SPARK-34497] [SQL] Fix built-in JDBC connection providers to restore JVM security context changes.

• To improve interoperability with Nvidia Spark RAPIDs plugin, Added workaround to address an issue preventing dynamic partition pruning from triggering when using Nvidia Spark RAPIDs with adaptive query execution disabled, see RAPIDS issue #1378 and RAPIDS issue ##1386. For details of the new configuration spark.sql.optimizer.dynamicPartitionPruning.enforceBroadcastReuse, see RAPIDS issue ##1386.

• The file output committer default algorithm has been changed from the v2 algorithm to the v1 algorithm in open source Spark 3.1. For more information, see this Amazon EMR optimizing Spark performance - dynamic partition pruning.

• Amazon EMR reverted to the v2 algorithm, the default used in prior Amazon EMR 6.x releases, to prevent performance regression. To restore the open source Spark 3.1 behavior, set spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version to 1. Open source Spark made this change because task commit in file output committer algorithm v2 is not atomic, which can cause an output data correctness issue in some cases. However, task commit in algorithm v1 is also not atomic. In some scenarios task commit includes a delete performed before a rename. This can result in a silent data correctness issue.

• Fixed Managed Scaling issues in earlier Amazon EMR releases and made improvements so application failure rates are significantly reduced.

• Installed the AWS Java SDK Bundle on each new cluster. This is a single jar containing all service SDKs and their dependencies, instead of individual component jars. For more information, see Java SDK Bundled Dependency.

Known issues

• For Amazon EMR 6.3.0 and 6.2.0 private subnet clusters, you cannot access the Ganglia web UI. You will get an "access denied (403)" error. Other web UIs, such as Spark, Hue, JupyterHub, Zeppelin, Livy, and Tez are working normally. Ganglia web UI access on public subnet clusters are also working normally. To resolve this issue, restart httpd service on the primary node with sudo systemctl restart httpd. This issue is fixed in Amazon EMR 6.4.0.

• When AWS Glue Data Catalog is enabled, using Spark to access a AWS Glue DB with null string location URI may fail. This happens to earlier Amazon EMR releases, but SPARK-31709 (https://issues.apache.org/jira/browse/SPARK-31709) makes it apply to more cases. For example, when creating a table within the default AWS Glue DB whose location URI is a null string, spark.sql("CREATE TABLE mytest (key string) location '/table_path';") fails with the message, "Cannot create a Path from an empty string." To work around this, manually set a location URI of your AWS Glue databases, then create tables within these databases using Spark.

• In Amazon EMR 6.3.0, PrestoSQL has upgraded from version 343 to version 350. There are two security related changes from the open source that relate to this version change. File-based catalog access control is changed from deny to allow when table, schema, or session property rules are not defined. Also, file-based system access control is changed to support files without catalog rules defined. In this case, all access to catalogs is allowed.

  For more information, see Release 344 (9 Oct 2020).

• Note that the Hadoop user directory (/home/hadoop) is readable by everyone. It has Unix 755 (drwxr-xr-x) directory permissions to allow read access by frameworks like Hive. You can put files in /home/hadoop and its subdirectories, but be aware of the permissions on those directories to protect sensitive information.

• Lower "Max open files" limit on older AL2 [fixed in newer releases]. Amazon EMR releases: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0, and emr-6.2.0 are based on older versions ofAmazon Linux 2 (AL2), which have a lower ulimit setting for "Max open files" when Amazon EMR clusters are created with the default AMI. Amazon EMR releases 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 and later include a permanent fix with a higher "Max open files" setting. Releases with the lower open file limit causes a "Too many open files" error when submitting Spark job. In the impacted releases, the Amazon EMR default AMI has a default ulimit setting of 4096 for "Max open files," which is lower than the 65536 file limit in the latestAmazon Linux 2 AMI. The lower ulimit setting for "Max open files" causes Spark job failure when the Spark driver and executor try to open more than 4096 files. To fix the issue, Amazon EMR has a bootstrap action (BA) script that adjusts the ulimit setting at cluster creation.

  If you are using an older Amazon EMR version that doesn't have the permanent fix for this issue, the following workaround lets you to explicitly set the instance-controller ulimit to a maximum of 65536 files.

  Explicitly set a ulimit from the command line

  1. Edit /etc/systemd/system/instance-controller.service to add the following parameters to Service section.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. Restart InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  Set a ulimit using bootstrap action (BA)

  You can also use a bootstrap action (BA) script to configure the instance-controller ulimit to 65536 files at cluster creation.

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• Important

  EMR clusters that run Amazon Linux or Amazon Linux 2 Amazon Machine Images (AMIs) use default Amazon Linux behavior, and do not automatically download and install important and critical kernel updates that require a reboot. This is the same behavior as other Amazon EC2 instances that run the default Amazon Linux AMI. If new Amazon Linux software updates that require a reboot (such as kernel, NVIDIA, and CUDA updates) become available after an Amazon EMR release becomes available, EMR cluster instances that run the default AMI do not automatically download and install those updates. To get kernel updates, you can customize your Amazon EMR AMI to use the latest Amazon Linux AMI.

• 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.