Amazon EMR, versión 6.0.0

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

• 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 para Java versión 1.11.711

• Versión de Ganglia 3.7.2

• Versión de Hadoop 3.2.1

• HBase versión 2.2.3

• HCatalog versión 3.1.2

• Versión de Hive 3.1.2

• Versión de Hudi 0.5.0-incubating

• Versión de Hue 4.4.0

• JupyterHub versión 1.0.0

• Versión de Livy 0.6.0

• MXNet versión 1.5.1

• Versión de Oozie 5.1.0

• Versión de Phoenix 5.0.0

• Versión de Presto 0.230

• Versión de Spark 2.4.4

• TensorFlow versión 1.14.0

• Versión de Zeppelin 0.9.0-SNAPSHOT

• Versión de Zookeeper 3.4.14

• Conectores y controladores: DynamoDB Connector 4.14.0

Nuevas características

• Soporte de tiempo de ejecución para YARN Docker: las aplicaciones de YARN, como los trabajos de Spark, ahora pueden ejecutarse en el contexto de un contenedor de Docker. Esto le permite definir fácilmente dependencias en una imagen de Docker sin necesidad de instalar bibliotecas personalizadas en su clúster de Amazon EMR. Para más información, consulte Configurar la integración de Docker y Ejecutar aplicaciones de Spark con Docker mediante Amazon EMR 6.0.0.

• Soporte LLAP de Hive: Hive ahora admite el modo de ejecución LLAP para mejorar el rendimiento de las consultas. Para obtener más información, consulte Uso de Hive LLAP.

Cambios, mejoras y problemas resueltos

• Esta es una versión para solucionar problemas con el escalado de Amazon EMR cuando no logra escalar o reducir verticalmente de forma correcta un clúster 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 en el clúster de Amazon EMR ejecutaban actividades de comprobación de estado, como recopilar el estado del nodo de YARN y el estado del nodo de HDFS. Esto se debía a que los daemons en el clúster no podían comunicar los datos del estado de un nodo a los componentes internos de Amazon EMR.

• Se han mejorado los daemons de EMR en el 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 la retirada de YARN cuando el clúster intentaba escalarse o reducirse verticalmente.

• Se ha solucionado el problema que provocaba errores en los pasos o trabajos durante el escalado del clúster al garantizar que los estados de los nodos sean siempre coherentes entre los daemons en el clúster de Amazon EMR y YARN o HDFS.

• Se ha solucionado un problema por el que las operaciones de clúster, como la reducción vertical y el envío escalonado, fallaban en los clústeres de Amazon EMR habilitados con la autenticación de Kerberos. Esto se debía a que el daemon en el clúster de Amazon EMR no renovó el ticket de Kerberos, que es necesario para comunicarse de forma segura con HDFS o YARN en ejecución en el nodo principal.

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

• Amazon Linux

  • Amazon Linux 2 es el sistema operativo de la serie de versiones 6.x de EMR.

  • Para la administración de servicios se utiliza systemd en lugar de upstart que se utilizaba en Amazon Linux 1.

• Kit de desarrollo de Java (JDK)

  • Corretto JDK 8 es el JDK predeterminado para la serie de versiones de EMR 6.x.

• Scala

  • Scala 2.12 se utiliza con Apache Spark y Apache Livy.

• Python 3

  • Python 3 es ahora la versión predeterminada de Python en EMR.

• Etiquetas de nodo YARN

  • A partir de la serie de versiones 6.x de Amazon EMR, la característica de etiquetas de nodo YARN está desactivada de forma predeterminada. De forma predeterminada, los procesos maestros de la aplicación se pueden ejecutar tanto en nodos principales como en nodos de tareas. Puede habilitar la función de etiquetas de nodo YARN configurando las siguientes propiedades: yarn.node-labels.enabled y yarn.node-labels.am.default-node-label-expression. Para más información, consulte Comprensión de los nodos principales, básicos y de tareas.

Problemas conocidos

• Reducir el límite máximo de archivos abiertos en las versiones anteriores AL2 [corregido en las versiones más recientes]. Versiones de Amazon EMR: 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 Amazon Linux 2 (), que AL2 tienen una configuración de límite inferior para el «Máximo número de archivos abiertos» cuando los clústeres de Amazon EMR se crean con la AMI predeterminada. Las 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 de Amazon EMR ahora incluyen una corrección permanente con una configuración más alta de “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 AMI predeterminada de Amazon EMR tiene una configuración de ulimit predeterminada de 4096 para “Máximo de archivos abiertos”, una cantidad inferior al límite de 65 536 archivos de la AMI de Amazon Linux 2 más reciente. 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 de ulimit al crear el clúster.

  Si utiliza una versión anterior de Amazon EMR que no tiene una corrección permanente para este problema, la siguiente solución alternativa le permite establecer explícitamente el ulimit del controlador de instancias en un máximo de 65 536 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

• El shell interactivo de Spark, que incluye PySpark SparkR y spark-shell, no admite el uso de Docker con bibliotecas adicionales.

• Para utilizar Python 3 con la versión 6.0.0 de Amazon EMR, debe agregar PATH a yarn.nodemanager.env-whitelist.

• La funcionalidad Live Long and Process (LLAP) no se admite cuando se utiliza el catálogo de datos de AWS Glue como metaalmacén de Hive.

• Al utilizar Amazon EMR 6.0.0 con la integración de Spark y Docker, debe configurar las instancias del clúster con el mismo tipo de instancia y la misma cantidad de volúmenes de EBS para evitar errores al enviar un trabajo de Spark con el tiempo de ejecución de Docker.

• En Amazon EMR 6.0.0, el modo de almacenamiento de Amazon HBase S3 se ve afectado por el problema del HBASE-24286. HBase el maestro no se puede inicializar cuando se crea el clúster con los datos de S3 existentes.

• Problema conocido en clústeres con varios nodos principales y autenticación de Kerberos

  Si ejecuta clústeres con varios nodos principales y autenticación de Kerberos en las versiones 5.20.0 y posteriores de Amazon EMR, es posible que tenga problemas con las operaciones del clúster, como la reducción vertical o el envío escalonado, después de que el clúster se haya estado ejecutando durante algún tiempo. El periodo de tiempo depende del periodo de validez del ticket de Kerberos que se haya definido. El problema de la reducción vertical afecta tanto a las solicitudes de reducción vertical automática como a las solicitudes de reducción vertical explícita que haya enviado. Las operaciones adicionales del clúster también pueden verse afectadas.

  Solución:

  • SSH como usuario de hadoop con el nodo principal líder del clúster de EMR con varios nodos principales.

  • Ejecute el siguiente comando para renovar el ticket de Kerberos para el usuario de hadoop.

    kinit -kt <keytab_file> <principal>

    Normalmente, el archivo keytab se encuentra en /etc/hadoop.keytab y la entidad principal tiene la forma de hadoop/<hostname>@<REALM>.

  nota

  Esta solución alternativa estará en vigor durante el periodo de validez del ticket de Kerberos. Esta duración es de 10 horas de forma predeterminada, pero se puede configurar con los ajustes de Kerberos. Debe volver a ejecutar el comando anterior una vez que venza el ticket de Kerberos.