De forma predeterminada, Cloud Data Fusion usaba Autoscale como perfil de computación. Estimar el número óptimo de trabajadores (nodos) de un clúster para una carga de trabajo es difícil, y un único tamaño de clúster para toda una canalización no suele ser lo ideal. El autoescalado de Dataproc es un mecanismo de automatización de la gestión de los recursos de clústeres que permite el autoescalado de las VMs de los trabajadores del clúster. Para obtener más información, consulta Autoescalado.
En la página Configuración de proceso, donde se muestra una lista de perfiles, hay una columna Total de núcleos, que indica el número máximo de vCPUs al que se puede ampliar el perfil, como Up to 84.
Si quieres usar el perfil de computación de Dataproc , puedes gestionar los tamaños de los clústeres en función del tamaño de la canalización.
Nodo maestro
Los nodos maestros usan recursos proporcionales al número de canalizaciones o aplicaciones adicionales que se ejecutan en el clúster. Si ejecutas canalizaciones en clústeres efímeros, usa 2 CPUs y 8 GB de memoria para los nodos maestros. Si usas clústeres persistentes, puede que necesites nodos maestros más grandes para mantener el ritmo del flujo de trabajo. Para saber si necesitas nodos maestros más grandes, puedes monitorizar el uso de memoria y CPU en el nodo. Te recomendamos que dimensionen los nodos de trabajo con al menos 2 CPUs y 8 GB de memoria. Si has configurado tus canalizaciones para que usen cantidades de memoria mayores, debes usar trabajadores más grandes.
Para minimizar el tiempo de ejecución, asegúrate de que tu clúster tenga suficientes nodos para permitir el mayor procesamiento en paralelo posible.
Trabajadores
En las siguientes secciones se describen aspectos del tamaño de los nodos de trabajo.
CPU and Memory
Te recomendamos que asignes a tus nodos de trabajo al menos 2 CPUs y 8 GB de memoria. Si has configurado tus canalizaciones para que usen cantidades de memoria más grandes, usa trabajadores más grandes. Por ejemplo, con un nodo de 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 podrá ejecutar más de un contenedor por nodo de trabajador. Cada nodo de trabajo tendría 3 CPUs y 4 GB adicionales que no se utilizarían porque no se pueden usar para ejecutar nada. Para maximizar la utilización de recursos en tu clúster, te recomendamos que la memoria y las CPUs de YARN sean un múltiplo exacto de la cantidad necesaria por ejecutor de Spark. Para comprobar cuánta memoria ha reservado cada trabajador para YARN, consulta la propiedad yarn.nodemanager.resource.memory-mb en YARN.
Si usas Dataproc, la memoria disponible para los contenedores de YARN será aproximadamente el 75% de la memoria de la VM. El tamaño mínimo del contenedor YARN también se ajusta en función del tamaño de las VMs de trabajador. En la siguiente tabla se muestran algunos tamaños de trabajador habituales y sus ajustes de YARN correspondientes.
| CPU de trabajador | Memoria de trabajador (GB) | Memoria de nodo de 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 definida para la canalización y que YARN redondea esa cantidad solicitada. Por ejemplo, supongamos que has definido la memoria del ejecutor en 2048 MB y no has asignado ningún valor a spark.yarn.executor.memoryOverhead, lo que significa que se usa el valor predeterminado de 384 MB. Esto significa que Spark solicita 2048 MB + 384 MB por cada ejecutor, que YARN redondea a un múltiplo exacto de la asignación mínima de YARN. Cuando se ejecuta en un nodo de trabajador de 8 GB, como 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, utilizando todas las CPUs disponibles, pero dejando 1 GB de memoria YARN (6 GB - 2,5 GB - 2,5 GB) sin usar. Esto significa que el nodo de trabajo puede ser un poco más pequeño o que los ejecutores pueden tener un poco más de memoria.
Cuando se ejecuta en un nodo de trabajador de 16 GB, 2048 MB + 1024 MB se redondea a 3 GB porque la asignación mínima de YARN es de 1024 MB.
Esto significa que cada nodo de trabajador puede ejecutar cuatro contenedores, con todas las CPUs y la memoria de YARN en uso.
Para ofrecer contexto, en la siguiente tabla se muestran los tamaños de trabajador recomendados para algunos tamaños de ejecutor habituales.
| CPU del ejecutor | Memoria del ejecutor (MB) | CPU de trabajador | Memoria de los trabajadores ( GB) |
|---|---|---|---|
| 1 | 2048 | 4 | 15 |
| 1 | 3072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
Por ejemplo, un nodo de trabajo de 26 GB se traduce en 20 GB de memoria utilizable para ejecutar contenedores YARN. Si la memoria del ejecutor es de 4 GB, se añade 1 GB como sobrecarga, lo que significa que cada ejecutor tiene contenedores YARN de 5 GB. Esto significa que el trabajador puede ejecutar cuatro contenedores sin que le sobren recursos. También puedes multiplicar el tamaño de los trabajadores. Por ejemplo, si la memoria del ejecutor se define en 4096 GB, un trabajador con 8 CPUs y 52 GB de memoria también funcionaría bien. Las máquinas virtuales de Compute Engine restringen la cantidad de memoria que pueden tener en función del número de núcleos. Por ejemplo, una máquina virtual 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 CPUs y 26 GB de memoria en la VM. Si los ejecutores se configuran para usar 2 CPUs y 8 GB de memoria, se utilizarán todas las CPUs.
Disco
El disco es importante para algunas canalizaciones, pero no para todas. Si tu canalización no contiene ninguna aleatorización, el disco solo se usará cuando Spark se quede sin memoria y necesite volcar datos en el disco. En estos tipos de canalizaciones, el tamaño y el tipo de disco no suelen influir mucho en el rendimiento. Si tu pipeline está barajando muchos datos, el rendimiento del disco marcará la diferencia. Si usas Dataproc, te recomendamos que utilices tamaños de disco de al menos 1 TB, ya que el rendimiento del disco aumenta con el tamaño del disco. Para obtener información sobre el rendimiento de los discos, consulta Configurar discos para cumplir los requisitos de rendimiento.
Número de trabajadores
Para minimizar el tiempo de ejecución, debes asegurarte de que tu clúster sea lo suficientemente grande como para ejecutar el máximo posible en paralelo. Por ejemplo, si la fuente de tu canalización lee datos mediante 100 divisiones, deberás asegurarte 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 consultar la memoria pendiente de YARN a lo largo del tiempo. Si usas Dataproc, puedes encontrar un gráfico en la página de detalles del clúster.
Si la memoria pendiente es alta durante periodos prolongados, puedes aumentar el número de trabajadores para añadir esa capacidad adicional a tu clúster. En el ejemplo anterior, el clúster debería aumentar en unos 28 GB para asegurarse de que se alcanza el nivel máximo de paralelismo.
Modo de flexibilidad mejorado (EFM)
EFM te permite especificar que solo participen los nodos de trabajo principales al aleatorizar datos. Como los trabajadores secundarios ya no son responsables de los datos de orden aleatorio intermedios, cuando se eliminan de un clúster, los trabajos de Spark no sufren retrasos ni errores. Como los trabajadores principales nunca se reducen, el clúster se reduce con más estabilidad y eficiencia. Si ejecutas canalizaciones con mezclas en un clúster estático, te recomendamos que uses EFM.
Para obtener más información sobre el modo de flexibilidad mejorada, consulta Modo de flexibilidad mejorada de Dataproc.