De forma predeterminada, Cloud Data Fusion usaba Autoscale como perfil de procesamiento. Es difícil calcular la cantidad adecuada de trabajadores (nodos) del clúster para una carga de trabajo, y un tamaño único del clúster para toda la canalización no suele ser lo ideal. El ajuste de escala automático de Managed Service para Apache Spark proporciona un mecanismo para automatizar la administración de recursos del clúster y habilitar el ajuste de escala automático de la VM de trabajador del clúster. Para obtener más información, consulta Ajuste de escala automático
En la página Compute config, en la que puedes ver una lista de perfiles, hay una columna Total cores, que tiene la cantidad máxima de CPU virtuales a la que se puede escalar el perfil, como Up to 84.
Si deseas usar el perfil de procesamiento de Managed Service para Apache Spark , puedes administrar los tamaños del clúster según el tamaño de la canalización.
Nodo principal
Los nodos de instancia principal usan recursos de forma proporcional a la cantidad de canalizaciones o aplicaciones adicionales que se ejecutan en el clúster. Si ejecutas canalizaciones en clústeres efímeros, usa 2 CPU y 8 GB de memoria para los nodos principales. Si usas clústeres persistentes, es posible que necesites nodos principales más grandes para mantenerse al día con el flujo de trabajo. Para comprender si necesitas nodos principales más grandes, puedes supervisar el uso de la memoria y la CPU en el nodo. Recomendamos que dimensiones tus nodos trabajadores con al menos 2 CPU y 8 GB de memoria. Si configuraste tus canalizaciones para usar grandes cantidades de memoria, debes usar trabajadores más grandes.
A fin de minimizar el tiempo de ejecución, asegúrate de que tu clúster tenga suficientes nodos para permitir el procesamiento lo más paralelo posible.
Trabajadores
En las siguientes secciones, se describen aspectos del dimensionamiento de los nodos trabajadores.
CPU y memoria
Recomendamos que dimensiones tus nodos trabajadores con al menos 2 CPU y 8 GB de memoria. Si configuraste tus canalizaciones para usar grandes cantidades de memoria, usa trabajadores más grandes. Por ejemplo, con un nodo trabajador de 4 CPU y 15 GB, cada trabajador tendrá 4 CPU y 12 GB disponibles para ejecutar contenedores YARN. Si tu canalización está configurada para ejecutar 1 CPU y ejecutores de 8 GB, YARN no puede ejecutar más de un contenedor por nodo trabajador. Cada nodo trabajador tendría 3 CPU y 4 GB adicionales que se desperdician porque no se pueden usar para ejecutar nada. Para maximizar el uso de recursos en tu clúster, querrás que
la memoria y las CPU de YARN sean un múltiplo exacto de la cantidad necesaria por
ejecutor de Spark. Para verificar cuánta memoria reservó cada trabajador para YARN, consulta la propiedad yarn.nodemanager.resource.memory-mb en YARN.
Si usas Managed Service para Apache Spark, la memoria disponible para los contenedores YARN será aproximadamente el 75% de la memoria de la VM. El tamaño mínimo del contenedor YARN también se ajusta según el tamaño de las VMs de trabajador. En la siguiente tabla, se indican algunos tamaños de trabajador comunes y su configuración de YARN correspondiente.
| CPU del trabajador | Memoria del trabajador (GB) | Memoria del nodo YARN (GB) | Memoria de asignación mínima de YARN (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1024 |
| 8 | 32 | 24 | 1024 |
| 16 | 64 | 51 | 1024 |
Ten en cuenta que Spark solicita más memoria que la memoria del ejecutor establecida para la canalización y que YARN redondea esa cantidad solicitada. Por ejemplo, supongamos que estableciste la memoria del ejecutor en 2, 048 MB y no proporcionaste un valor para spark.yarn.executor.memoryOverhead, lo que significa que se usa el valor predeterminado de 384 MB. Eso significa que Spark solicita 2,048 MB + 384 MB para cada ejecutor, que YARN redondea a un múltiplo exacto de la asignación mínima de YARN. Cuando se ejecuta en un nodo trabajador de 8 GB, debido a que la asignación mínima de YARN es de 512 MB, se redondea a 2.5 GB. Esto significa que cada trabajador puede ejecutar dos contenedores, usar todas las CPU disponibles, pero dejar 1 GB de memoria YARN (6 GB - 2.5 GB - 2.5 GB) sin usar. Esto significa que el nodo trabajador puede tener un tamaño un poco más pequeño o que los ejecutores pueden tener un poco más de memoria.
Cuando se ejecuta en un nodo trabajador de 16 GB, 2,048 MB + 1,024 MB se redondean a 3 GB porque la asignación mínima de YARN es de 1,024 MB.
Esto significa que cada nodo trabajador puede ejecutar cuatro contenedores, con todas las CPU
y la memoria YARN en uso.
Para ayudar a dar contexto, en la siguiente tabla, se muestran los tamaños de trabajador recomendados para algunos tamaños de ejecutor comunes.
| CPU del ejecutor | Memoria del ejecutor (MB) | CPU del trabajador | Memoria del trabajador ( GB) |
|---|---|---|---|
| 1 | 2,048 | 4 | 15 |
| 1 | 3,072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
Por ejemplo, un nodo trabajador de 26 GB se traduce en 20 GB de memoria que se pueden usar para ejecutar contenedores YARN. Con la memoria del ejecutor establecida en 4 GB, se agrega 1 GB como sobrecarga, lo que significa contenedores YARN de 5 GB para cada ejecutor. Esto significa que el trabajador puede ejecutar cuatro contenedores sin recursos adicionales. También puedes multiplicar el tamaño de los trabajadores. Por ejemplo, si la memoria del ejecutor se establece en 4,096 GB, un trabajador con 8 CPU y 52 GB de memoria también funcionaría bien. Las VMs de Compute Engine restringen la cantidad de memoria que puede tener la VM según la cantidad de núcleos. Por ejemplo, una VM con 4 núcleos debe tener al menos 7.25 GB de memoria y, como máximo, 26 GB de memoria. Esto significa que un ejecutor configurado para usar 1 CPU y 8 GB de memoria usa 2 CPU y 26 GB de memoria en la VM. Si los ejecutores se configuran para usar 2 CPU y 8 GB de memoria, se utilizan todas las CPU.
Disco
El disco es importante para algunas canalizaciones, pero no para todas. Si tu canalización no contiene ninguna redistribución, el disco solo se usará cuando Spark se quede sin memoria y necesite volcar datos en el disco. Para estos tipos de canalizaciones, el tamaño y el tipo de disco no afectarán de forma significativa el rendimiento. Si tu canalización redistribuye muchos datos, el rendimiento del disco marcará la diferencia. Si usas Managed Service para Apache Spark, te recomendamos que uses tamaños de disco de al menos 1 TB, ya que el rendimiento de disco escala verticalmente con el tamaño del disco. Para obtener información sobre el rendimiento del disco, consulta Configura discos para cumplir con los requisitos de rendimiento.
Cantidad de trabajadores
Para minimizar el tiempo de ejecución, asegúrate de que tu clúster sea lo suficientemente grande como para ejecutar la mayor cantidad posible de procesos en paralelo. Por ejemplo, si la fuente de tu canalización lee datos con 100 divisiones, asegúrate de que el clúster sea lo suficientemente grande como para ejecutar 100 ejecutores a la vez.
La forma más sencilla de saber si tu clúster es demasiado pequeño es observar la memoria YARN pendiente a lo largo del tiempo. Si usas Managed Service para Apache Spark, puedes encontrar un gráfico en la página de detalles del clúster.
Si la memoria pendiente es alta durante períodos prolongados, puedes aumentar la cantidad de trabajadores para agregar esa capacidad adicional a tu clúster. En el ejemplo anterior, el clúster debe aumentarse en alrededor de 28 GB para garantizar que se alcance el nivel máximo de paralelismo.
Modo de flexibilidad mejorada (EFM)
EFM te permite especificar que solo se incluyan nodos trabajadores principales cuando se redistribuyen datos. Como los trabajadores secundarios ya no son responsables de los datos de redistribución intermedios, cuando se quitan de un clúster, los trabajos de Spark no sufren demoras ni errores. Como los trabajadores principales nunca se reducen, el clúster se reduce con más estabilidad y eficiencia. Si ejecutas canalizaciones con redistribuciones en un clúster estático, te recomendamos que uses EFM.
Para obtener más información sobre EFM, consulta Modo de flexibilidad mejorada de Managed Service para Apache Spark.