Amazon EMR versión 6.3.0

• Versiones de aplicaciones en las versiones EMR 7.x de Amazon

• Versiones de la aplicación en las versiones 6.x de Amazon EMR

• Versiones de la aplicación en las versiones 5.x de Amazon EMR

• Versiones de la aplicación en las versiones 4.x de Amazon EMR

Aplicaciones compatibles

• AWS SDK for Java versión 1.11.977

• CloudWatch Sink versión 2.1.0

• Conector de DynamoDB, versión 4.16.0

• EMRFSversión 2.46.0

• Amazon EMR Goodies versión 3.2.0

• Amazon EMR Kinesis Connector versión 3.5.0

• Amazon EMR Record Server versión 2.0.0

• Amazon EMR Scripts versión 2.5.0

• Flink, versión 1.12.1

• Versión de Ganglia 3.7.2

• AWS Cliente Glue Hive Metastore versión 3.2.0

• Hadoop, versión 3.2.1-amzn-3

• HBaseversión 2.2.6-amzn-1

• HBase-operator-tools 1.0.0

• HCatalogversión 3.1.2-amzn-0

• Hive, versión 3.1.2-amzn-4

• Hudi versión 0.7.0-amzn-0

• Hue versión 4.9.0

• JDKVersión de Java Corretto-8.282.08.1 (compilación 1.8.0_282-b08)

• JupyterHub versión 1.2.0

• Livy versión 0.7.0-incubating

• MXNetversión 1.7.0

• Oozie versión 5.2.1

• Versión de Phoenix 5.0.0

• Pig, versión 0.17.0

• Presto, versión 0.245.1-amzn-0

• Presto versión 3.50 SQL

• Apache Ranger KMS (cifrado transparente multimaestro) versión 2.0.0

• ranger-plugins 2.0.1-amzn-0

• ranger-s3-plugin 1.1.0

• SageMaker Spark versión 1.4.1 SDK

• Scala versión 2.12.10 (máquina virtual de servidor abierta de JDK 64 bits, Java 1.8.0_282)

• Spark, versión 3.1.1-amzn-0

• spark-rapids 0.4.1

• Sqoop, versión 1.4.7

• TensorFlow versión 2.4.1

• Tez, versión 0.9.2

• Zeppelin versión 0.9.0

• Versión de Zookeeper 3.4.14

• Conectores y controladores: conector de DynamoDB 4.16.0

Nuevas características

• Amazon EMR es compatible con los puntos de acceso Amazon S3, una función de Amazon S3 que le permite administrar fácilmente el acceso a los lagos de datos compartidos. Con su alias de punto de acceso Amazon S3, puede simplificar el acceso a los datos a gran escala en AmazonEMR. Puede utilizar los puntos de acceso Amazon S3 con todas las versiones de Amazon sin EMR coste adicional en todas AWS las regiones en las que Amazon EMR esté disponible. Para más información acerca de los puntos de acceso de Amazon S3 y los alias de punto de acceso, consulte Uso de un alias de estilo bucket para el punto de acceso en la Guía del usuario de Amazon S3.

• Las novedades DescribeReleaseLabel y ListReleaseLabel API los parámetros proporcionan los detalles de la etiqueta EMR de lanzamiento de Amazon. Puedes enumerar mediante programación las versiones disponibles en la región en la que se ejecuta la API solicitud y enumerar las aplicaciones disponibles para una etiqueta de EMR lanzamiento específica de Amazon. Los parámetros de las etiquetas de lanzamiento también muestran las EMR versiones de Amazon compatibles con una aplicación específica, como Spark. Esta información se puede utilizar para lanzar clústeres de Amazon EMR mediante programación. Por ejemplo, puede iniciar un clúster con la versión más reciente de los resultados de ListReleaseLabel. Para obtener más información, consulta DescribeReleaseLabely ListReleaseLabelsen Amazon EMR API Reference.

• Con Amazon EMR 6.3.0, puede lanzar un clúster que se integre de forma nativa con Apache Ranger. Apache Ranger es un marco de código abierto para habilitar, supervisar y administrar la seguridad integral de los datos en toda la plataforma Hadoop. Para obtener más información, consulte Apache Ranger. Con la integración nativa, puedes usar tu propio Apache Ranger para aplicar un control de acceso a los datos detallado en Amazon. EMR Consulte Integrar Amazon EMR con Apache Ranger en la Guía de EMR administración de Amazon.

• Políticas administradas por alcance: para alinearse con las AWS mejores prácticas, Amazon EMR ha introducido políticas EMR administradas predeterminadas con alcance v2 como sustitutas de las políticas que quedarán obsoletas. Consulta las políticas EMR gestionadas por Amazon.

• Estado de soporte de Instance Metadata Service (IMDS) V2: en Amazon EMR 6.2 o versiones posteriores, EMR los componentes de Amazon se utilizan IMDSv2 para todas las IMDS llamadas. Para IMDS las llamadas en el código de su aplicación, puede usar ambos IMDSv1 códigos o configurarlos para IMDS que se usen solo IMDSv2 para mayor seguridad. IMDSv2 Si lo inhabilitas IMDSv1 en versiones anteriores de Amazon EMR 6.x, se produce un error al iniciar el clúster.

Cambios, mejoras y problemas resueltos

• Esta es una versión para solucionar problemas con Amazon EMR Scaling cuando no logra escalar correctamente un clúster hacia arriba o hacia abajo o provoca errores en las aplicaciones.

• Se solucionó un problema por el que las solicitudes de escalado de un clúster grande y muy utilizado fallaban cuando los daemons del EMR clúster de Amazon ejecutaban actividades de comprobación de estado, como recopilar el estado y HDFS el estado del YARN nodo. Esto se debía a que los daemons del clúster no podían comunicar los datos del estado de salud de un nodo a los componentes internos de Amazon. EMR

• Se han mejorado los daemons EMR del clúster para realizar un seguimiento correcto de los estados de los nodos cuando se reutilizan las direcciones IP, a fin de mejorar la fiabilidad durante las operaciones de escalado.

• SPARK-29683. Se ha corregido un error que provocaba que se produjeran errores en los trabajos durante la reducción vertical del clúster, ya que Spark daba por sentado que todos los nodos disponibles estaban en la lista de denegados.

• YARN-9011. Se ha corregido un error que provocaba que se produjeran errores en los trabajos debido a una condición de carrera durante el YARN desmantelamiento, cuando el clúster intentaba ampliarse o reducirse.

• Se solucionó el problema que provocaba errores en los pasos o tareas durante el escalado del clúster al garantizar que los estados de los nodos fueran siempre coherentes entre los daemons del EMR clúster de Amazon y/. YARN HDFS

• Se ha corregido un problema que provocaba que las operaciones de clúster, como la reducción de escala y el envío por pasos, fallaran en EMR los clústeres de Amazon habilitados con la autenticación Kerberos. Esto se debió a que el daemon EMR integrado en el clúster de Amazon no renovó el ticket de Kerberos, que es necesario para comunicarse de forma segura conHDFS/que se YARN ejecuta en el nodo principal.

• Las EMR versiones más recientes de Amazon solucionan el problema con un límite de «máximo de archivos abiertos» inferior al anterior AL2 en AmazonEMR. Las EMR versiones 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 y posteriores ahora incluyen una corrección permanente con una configuración más alta de «Máximo de archivos abiertos».

• SQLEl modo de explicación de la extended formatted interfaz de usuario de Spark ha cambiado por defecto de a en Spark 3.1. Amazon lo EMR revirtió extended para incluir información del plan lógico en la SQL interfaz de usuario de Spark. Esto se puede revertir al establecer spark.sql.ui.explainMode en formatted.

• Se ha agregado portabilidad con versiones anteriores para las siguientes confirmaciones desde la ramificación maestra de Spark.

  - [SPARK-34752] [BUILD] Cambia Jetty a 9.4.37 para dirigirte a -2020-27223. CVE

  - [-34534] Se corrige el orden cuando se utilizan SPARK para buscar bloques. blockIds FetchShuffleBlocks

  - [SPARK-34681] [SQL] Se ha corregido un error que provocaba la unión completa del hash barajado exterior cuando se construía el lado izquierdo con condiciones desiguales.

  - [SPARK-34497] [SQL] Se corrigieron los proveedores de JDBC conexión integrados para restablecer los cambios en el contexto de seguridad. JVM

• Para mejorar la interoperabilidad con el RAPIDs complemento de Nvidia Spark, se ha añadido una solución alternativa para solucionar un problema que impedía que se activara la reducción dinámica de particiones al utilizar Nvidia Spark RAPIDs con la ejecución de consultas adaptativas deshabilitada, consulte los números #1378 y RAPIDS #1386. RAPIDS Para obtener más información sobre la nueva configuraciónspark.sql.optimizer.dynamicPartitionPruning.enforceBroadcastReuse, consulta el RAPIDSnúmero #1386.

• En Spark 3.1 de código abierto, se ha cambiado el algoritmo predeterminado del confirmador de salida de archivos de la versión 2 a la versión 1. Para obtener más información, consulta Amazon EMR Optimización del rendimiento de Spark: reducción dinámica de particiones.

• Amazon EMR volvió al algoritmo v2, el predeterminado utilizado en las versiones anteriores de Amazon EMR 6.x, para evitar la regresión del rendimiento. Para restaurar el comportamiento de Spark 3.1 de código abierto, establezca spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version en 1. Spark, de código abierto, ha realizado este cambio porque la confirmación de tareas en la versión 2 del algoritmo de confirmación de salida de archivos no es atómica, lo que puede provocar un problema de corrección de los datos de salida en algunos casos. Sin embargo, la confirmación de tareas en la versión 1 del algoritmo tampoco es atómica. En algunos escenarios, la confirmación de tareas incluye una eliminación realizada antes del cambio de nombre. Esto puede provocar un problema silencioso de corrección de los datos.

• Se corrigieron los problemas de Managed Scaling en EMR versiones anteriores de Amazon y se realizaron mejoras para reducir significativamente las tasas de errores de las aplicaciones.

• Se instaló el SDK paquete AWS Java en cada clúster nuevo. Se trata de un contenedor único que contiene todos los servicios SDKs y sus dependencias, en lugar de contenedores de componentes individuales. Para obtener más información, consulte Java SDK Bundled Dependency.

Problemas conocidos

• En el caso de los clústeres de subredes privadas de Amazon EMR 6.3.0 y 6.2.0, no puede acceder a la interfaz de usuario web de Ganglia. Aparecerá el error “Acceso denegado (403)”. Otras páginas webUIs, como Spark, Hue, Zeppelin JupyterHub, Livy y Tez, funcionan con normalidad. El acceso a la interfaz de usuario web de Ganglia en los clústeres de subredes públicas también funciona con normalidad. Para resolver este problema, reinicie el servicio httpd en el nodo principal con sudo systemctl restart httpd. Este problema se ha corregido en Amazon EMR 6.4.0.

• Cuando el catálogo de datos de AWS Glue está activado, es posible que no se URI pueda utilizar Spark para acceder a una base de datos de AWS Glue con una ubicación de cadena nula. Esto ocurre con las EMR versiones anteriores de Amazon, pero con la SPARK -31709 (https://issues.apache. org/jira/browse/SPARK-31709) hace que se aplique a más casos. Por ejemplo, al crear una tabla dentro de la base de datos AWS Glue predeterminada cuya ubicación URI es una cadena nula, se produce un spark.sql("CREATE TABLE mytest (key string) location '/table_path';") error con el mensaje «No se puede crear una ruta a partir de una cadena vacía». Para solucionar este problema, establece manualmente la ubicación URI de tus bases de datos de AWS Glue y, a continuación, crea tablas dentro de estas bases de datos con Spark.

• En Amazon EMR 6.3.0, Presto se SQL actualizó de la versión 343 a la versión 350. Hay dos cambios respecto a la seguridad en el código abierto que se relacionan con este cambio de versión. El control de acceso al catálogo basado en archivos cambia de deny a allow cuando las reglas de propiedades de la tabla, el esquema o la sesión no están definidas. Además, el control de acceso al sistema basado en archivos se ha modificado para admitir archivos sin reglas de catálogo definidas. En este caso, se permite todo el acceso a los catálogos.

  Para más información, consulte Release 344 (9 Oct 2020).

• Tenga en cuenta el directorio de usuarios de Hadoop (/) 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 y sus subdirectorios, pero tenga en cuenta los permisos de esos directorios para proteger la información confidencial.

• Reducir el límite de «máximo de archivos abiertos» en las versiones anteriores AL2 [corregido en las versiones más recientes]. EMRLas versiones de Amazon: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 y emr-6.2.0 se basan en versiones anteriores de Linux ofAmazon 2 (), que tienen un valor de límite inferior para el «Máximo número de archivos abiertos» cuando los clústeres de Amazon se crean con la AL2 configuración predeterminada. EMR AMI EMRLas versiones 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 y posteriores incluyen una corrección permanente con una configuración más alta de «Número máximo de archivos abiertos». Las versiones con el límite inferior de archivos abiertos provocan el error “Demasiados archivos abiertos” al enviar el trabajo de Spark. En las versiones afectadas, la configuración EMR predeterminada de Amazon AMI tiene una configuración de límite ulimit predeterminada de 4096 para el «Máximo de archivos abiertos», que es inferior al límite de 65536 archivos de Linux 2. latestAmazon AMI La configuración de ulimit inferior para “Máximo de archivos abiertos” provoca un fallo en el trabajo de Spark cuando el controlador y el ejecutor de Spark intentan abrir más de 4096 archivos. Para solucionar el problema, Amazon EMR tiene un script de acciones de arranque (BA) que ajusta la configuración ulimit al crear el clúster.

  Si utilizas una EMR versión anterior de Amazon que no tiene una solución permanente para este problema, la siguiente solución alternativa te permite establecer de forma explícita el límite ulimit del controlador de instancias en un máximo de 65536 archivos.

  Establecimiento explícito de un ulimit desde la línea de comandos

  1. Edite /etc/systemd/system/instance-controller.service para agregar los siguientes parámetros a la sección de servicio.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. Reinicie InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  Establecimiento de un ulimit mediante una acción de arranque (BA)

  También puede usar un script de acciones de arranque (BA) para configurar el ulimit del controlador de instancias en 65 536 archivos al crear el clúster.

  #!/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

• importante

  EMRlos clústeres que ejecutan Amazon Linux o Amazon Machine Images (AMIs) de Amazon Linux 2 utilizan el comportamiento predeterminado de Amazon Linux y no descargan e instalan automáticamente actualizaciones importantes y críticas del núcleo que requieren un reinicio. Este comportamiento es el mismo que el de otras EC2 instancias de Amazon que ejecutan el Amazon Linux predeterminadoAMI. Si aparecen nuevas actualizaciones de software de Amazon Linux que requieren un reinicio (como el núcleo y CUDA las actualizaciones) después de que esté disponible una EMR versión de Amazon, las instancias de EMR clúster que se ejecutan de forma predeterminada AMI no descargan e instalan automáticamente esas actualizaciones. NVIDIA Para obtener actualizaciones del núcleo, puedes personalizar tu Amazon EMR AMI para que utilice la versión más reciente de Amazon Linux AMI.

• Para utilizar las acciones de Spark con Apache Oozie, debe agregar la siguiente configuración al archivo workflow.xml de Oozie. De lo contrario, EMRFS faltarán varias bibliotecas críticas, como Hadoop, en la ruta de clases de los ejecutores de Spark que lanza Oozie.

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

• Si utiliza Spark con el formato de ubicación de particiones de Hive para leer datos en Amazon S3 y ejecuta Spark en las EMR versiones 5.30.0 a 5.36.0 y 6.2.0 a 6.9.0 de Amazon, es posible que se produzca un problema que impida que el clúster lea los datos correctamente. Esto puede ocurrir si las particiones tienen todas las características siguientes:

  • Se analizan dos o más particiones de la misma tabla.

  • Al menos una ruta de directorio de particiones es un prefijo de al menos otra ruta de directorio de particiones; por ejemplo, s3://bucket/table/p=a es un prefijo de s3://bucket/table/p=a b.

  • El primer carácter que sigue al prefijo en el otro directorio de particiones tiene un valor UTF -8 inferior al carácter (U+002F). / Por ejemplo, el carácter de espacio (U+0020) que aparece entre a y b en s3://bucket/table/p=a b entra en esta categoría. Tenga en cuenta que hay otros 14 caracteres que no son de control: !"#$%&‘()*+,-. Para obtener más información, consulte la tabla de codificación UTF -8 y los caracteres Unicode.

  Como solución alternativa a este problema, defina la configuración spark.sql.sources.fastS3PartitionDiscovery.enabled como false en la clasificación spark-defaults.