De forma predeterminada, Cloud Data Fusion usó el ajuste de escala automático como perfil de procesamiento. Calcular la mejor cantidad de trabajadores de clúster (nodos) para una carga de trabajo es difícil, y un solo tamaño de clúster para una canalización completa a menudo no es lo ideal. El ajuste de escala automático de Dataproc proporciona un mecanismo para automatizar la administración de recursos del clúster y habilita el ajuste de escala automático de VM de trabajador del clúster. Para obtener más información, consulta Ajuste de escala automático.
En la página Configuración de procesamiento, en la que puedes ver una lista de perfiles, hay una columna Total de núcleos, que tiene la cantidad máxima de CPU virtuales a las que el perfil puede escalar verticalmente, como Up to 84.
Si deseas usar el perfil de procesamiento de Dataproc , puedes administrar los tamaños de los clústeres 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 mantener el ritmo del flujo de trabajo. Para saber si necesitas nodos principales más grandes, puedes supervisar el uso de la memoria y de la CPU en el nodo. Recomendamos que establezcas el tamaño de tus nodos trabajadores con al menos 2 CPU y 8 GB de memoria. Si configuraste tus canalizaciones para que usen mayores 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 tamaño de los nodos trabajadores.
CPU y memoria
Recomendamos dimensionar tus nodos trabajadores con al menos 2 CPU y 8 GB de memoria. Si configuraste las canalizaciones para que usen mayores 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 ejecutores de 1 CPU y 8 GB, YARN no podrá ejecutar más de un contenedor por nodo trabajador. Cada nodo trabajador tendría 3 CPU y 4 GB adicionales que se desperdiciarían porque no se pueden usar para ejecutar nada. Para maximizar el uso de recursos en tu clúster, querrás que la memoria YARN y las CPU sean un múltiplo exacto de la cantidad necesaria por ejecutor de Spark. Puedes comprobar cuánta memoria reservó cada trabajador para YARN si revisas la propiedad yarn.nodemanager.resource.memory-mb en YARN.
Si usas Dataproc, la memoria disponible para los contenedores YARN será de alrededor del 75% de la memoria de la VM. El tamaño mínimo del contenedor de YARN también se ajusta según el tamaño de las VMs de trabajador. En la siguiente tabla, se muestran algunos tamaños comunes de trabajadores y su configuración de YARN correspondiente.
| CPU de trabajador | Memoria de trabajador (GB) | Memoria de 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 establecido para la canalización y que YARN redondea la cantidad solicitada. Por ejemplo, supongamos que configuraste la memoria del ejecutor en 2, 048 MB y no asignaste un valor a spark.yarn.executor.memoryOverhead, lo que significa que se usa el valor predeterminado de 384 MB. Esto 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, se redondea a 2.5 GB, debido a que la asignación mínima de YARN es de 512 MB. Esto significa que cada trabajador puede ejecutar dos contenedores con todas las CPU disponibles, pero dejando 1 GB de memoria YARN (de 6 GB a 2.5 GB a 2.5 GB) sin usar. Esto significa que el nodo trabajador puede tener un tamaño un poco menor o a los ejecutores se les puede dar 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 proporcionar contexto, en la siguiente tabla, se muestran los tamaños de trabajadores recomendados en función de algunos tamaños de ejecutores comunes.
| CPU del ejecutor | Memoria del ejecutor (MB) | CPU de trabajador | Memoria de trabajador ( GB) |
|---|---|---|---|
| 1 | 2,048 | 4 | 15 |
| 1 | 3072 | 4 | 21 |
| 1 | 4,096 | 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 configurada en 4 GB, se agrega 1 GB como sobrecarga, lo que significa 5 GB de contenedores YARN para cada ejecutor. Esto significa que el trabajador puede ejecutar cuatro contenedores sin restos de recursos adicionales. También puedes multiplicar el tamaño de los trabajadores. Por ejemplo, si la memoria del ejecutor está configurada en 4,096 GB, un trabajador con 8 CPU y 52 GB de memoria también funcionaría bien. Las VM de Compute Engine restringen la cantidad de memoria que puede tener en función de la cantidad de núcleos. Por ejemplo, una VM con 4 núcleos debe tener al menos 7.25 GB de memoria y un máximo de 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 están configurados para usar 2 CPU y 8 GB de memoria, se usan todas las CPU.
Disco
El disco es importante para algunas canalizaciones, pero no para todas. Si tu canalización no contiene Shuffles, el disco solo se usará cuando Spark se quede sin memoria y necesite derramar datos al disco. Para estos tipos de canalizaciones, el tamaño y el tipo de disco no suelen tener un gran impacto en el rendimiento. Si tu canalización redistribuye muchos datos, el rendimiento del disco marcará la diferencia. Si usas Dataproc, se recomienda que uses tamaños de disco de al menos 1 TB, ya que el rendimiento del disco escala verticalmente con el tamaño. Si deseas obtener más información sobre el rendimiento de los discos, consulta Configura discos para que cumplan 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 que pueda ejecutarse tanto como pueda en paralelo. Por ejemplo, si tu fuente de canalización lee datos con 100 divisiones, debes asegurarte de que el clúster sea lo suficientemente grande para ejecutar 100 ejecutores a la vez.
La forma más fácil de saber si tu clúster tiene un tamaño reducido es observar la memoria pendiente de YARN en el tiempo. Si usas Dataproc, hay un grafo en la página de detalles del clúster.
Si la memoria pendiente es alta durante largos períodos, puedes aumentar la cantidad de trabajadores para agregar tanta capacidad adicional a tu clúster. En el ejemplo anterior, el clúster debería aumentarse 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 participen los nodos trabajadores principales cuando se redistribuye los datos. Dado que los trabajadores secundarios ya no son responsables de los datos de Shuffle intermedios, cuando se quitan de un clúster, los trabajos de Spark no presentan retrasos ni errores. Como nunca se reduce la escala verticalmente de los trabajadores principales, el clúster reduce la escala verticalmente con más estabilidad y eficiencia. Si ejecutas canalizaciones con Shuffle en un clúster estático, se recomienda usar EFM.
Para obtener más información sobre EFM, consulta Modo de flexibilidad mejorada de Dataproc.