Ajuste de escala automático de clústeres

¿Qué es el ajuste de escala automático?

La estimación de la cantidad “correcta” 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 escalamiento de clúster iniciado por el usuario aborda parcialmente este desafío, pero requiere la supervisión del uso del clúster y la intervención manual.

La API de AutoscalingPolicies de Dataproc proporciona un mecanismo para automatizar la administración de recursos del clúster y habilita el ajuste de escala automático. Una Autoscaling Policy es una configuración reutilizable que describe cómo se deben escalar los clústeres que usan la política de ajuste de escala automático. Define límites de escalamiento, frecuencia y agresividad para proporcionar un control detallado sobre los recursos del clúster durante la vida útil del clúster.

Cuándo usar el ajuste de escala automático

Usa el ajuste de escala automático:

en clústeres que almacenan datos en servicios externos, como Cloud Storage o BigQuery

en clústeres que procesan muchos trabajos

para escalar clústeres de un solo trabajo

El ajuste de escala automático no se recomienda para o con:

  • Clústeres de alta disponibilidad: En su lugar, usa clústeres estándar, que son más estables después de las operaciones de cambio de tamaño sucesivas.

  • HDFS: El ajuste de escala automático no está diseñado para escalar HDFS en el clúster. Si usas el ajuste de escala automático con HDFS, asegúrate de que la cantidad mínima de trabajadores principales sea suficiente para manejar todos los datos de HDFS. Además, ten en cuenta que el retiro de Datanodes de HDFS puede retrasar la eliminación de trabajadores.

  • Etiquetas de nodo de YARN: El ajuste de escala automático no admite etiquetas de nodo de YARN ni la propiedad dataproc:am.primary_only debido a YARN-9088. YARN informa de forma incorrecta las métricas del clúster cuando se usan etiquetas de nodo.

  • Spark Structured Streaming: El ajuste de escala automático no es compatible con la Spark Structured Streaming (consulta Ajuste de escala automático y Spark Structured Streaming).

  • Clústeres inactivos: No se recomienda el ajuste de escala automático para reducir el tamaño de un clúster al tamaño mínimo cuando este está inactivo. Dado que crear un clúster nuevo es tan rápido como cambiar el tamaño de uno, considera borrar clústeres inactivos y volver a crearlos. Las siguientes herramientas admiten este modelo "efímero":

    Usa flujos de trabajo de Dataproc para programar un conjunto de trabajos en un clúster dedicado y, luego, borra el clúster cuando finalicen los trabajos. Para obtener una organización más avanzada, usa Cloud Composer, que se basa en Apache Airflow.

    Para clústeres que procesan consultas ad hoc o cargas de trabajo programadas externamente, usa la eliminación programada de clústeres para borrar el clúster después de un período o duración de inactividad que se especificó, o en un momento en particular.

Habilita el ajuste de escala automático

Para habilitar el ajuste de escala automático en un clúster, haz lo siguiente:

  1. Crea una política de ajuste de escala automático

  2. Sigue uno de estos pasos:

    1. Crea un clúster de ajuste de escala automático
    2. Habilita el ajuste de escala automático en un clúster existente.

Crea una política de ajuste de escala automático

Comando de gcloud

Puedes usar el comando gcloud dataproc autoscaling-policies import para crear una política de ajuste de escala automático. Este lee un archivo YAML local que define una política de ajuste de escala automático. El formato y el contenido del archivo deben coincidir con los objetos de configuración y los campos que define la API de REST de autoscalingPolicies.

En el siguiente ejemplo de YAML, se define una política que especifica todos los campos obligatorios. También proporciona valores de maxInstances para trabajadores principales y secundarios (interrumpibles), y también especifica un cooldownPeriod de 4 minutos (el valor predeterminado es 2 minutos).

workerConfig:
  maxInstances: 100
secondaryWorkerConfig:
  maxInstances: 50
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    gracefulDecommissionTimeout: 1h

Este es otro ejemplo de YAML que especifica todos los campos opcionales y obligatorios de la política de ajuste de escala automático.

workerConfig:
  minInstances: 2
  maxInstances: 100
  weight: 1
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

Ejecuta el siguiente comando gcloud desde una terminal local o en Cloud Shell para crear la política de ajuste de escala automático. Proporciona un nombre para la política. Este nombre se convertirá en el id de la política, que puedes usar en comandos gcloud posteriores para hacer referencia a la política. Usa la marca --source a fin de especificar la ruta local y el nombre del archivo YAML de la política de ajuste de escala automático que se debe importar.

gcloud dataproc autoscaling-policies import policy-name \
    --source=filepath/filename.yaml

API de REST

Para crear una política de ajuste de escala automático, define una AutoscalingPolicy como parte de una solicitud autoscalingPolicies.create.

Console

Por el momento, no se admite la creación de una política de ajuste de escala automático en Google Cloud Console.

Crea un clúster de ajuste de escala automático

Después de crear una política de ajuste de escala automático, crea un clúster que use la política de ajuste de escala automático. El clúster debe estar en la misma región que la política de ajuste de escala automático.

Comando de gcloud

Ejecuta el siguiente comando gcloud desde una terminal local o en Cloud Shell para crear un clúster de ajuste de escala automático. Proporciona un nombre para el clúster y usa la marca --autoscaling-policy para especificar el policy id (el nombre de la política que especificaste cuando creaste la política) o el resource URI (resource name) de la política (consulta los campos id y name de la política de ajuste de escala automático).

gcloud dataproc clusters create cluster-name \
    --autoscaling-policy=policy id or resource URI

API de REST

Crea un clúster de ajuste de escala automático mediante la inclusión de un AutocalingConfig como parte de una solicitud clusters.create.

Console

Puedes seleccionar una política de ajuste de escala automático existente para aplicarla a un clúster nuevo en la sección Política de ajuste de escala automático de la página Crear un clúster de Dataproc en Cloud Console.

Habilita el ajuste de escala automático en un clúster existente

Después de crear una política de ajuste de escala automático, puedes habilitarla en un clúster existente en la misma región.

Comando de gcloud

Ejecuta el comando gcloud siguiente desde una terminal local o en Cloud Shell para habilitar una política de ajuste de escala automático en un clúster existente. Proporciona el nombre del clúster y usa la marca --autoscaling-policy para especificar el policy id (el nombre de la política que especificaste cuando creaste la política) o el resource URI (resource name) de la política (consulta los campos id y name de la política de ajuste de escala automático ).

gcloud dataproc clusters update cluster-name \
    --autoscaling-policy=policy id or resource URI

API de REST

Para habilitar una política de ajuste de escala automático en un clúster existente, configura el AutoscalingConfig.policyUri de la política en el updateMask de una solicitud clusters.patch.

Console

Actualmente, no se admite la habilitación de una política de ajuste de escala automático en un clúster existente en Google Cloud Console.

Cómo funciona el ajuste de escala automático

El ajuste de escala automático verifica las métricas de Hadoop YARN del clúster a medida que transcurre el período de enfriamiento para determinar si se debe escalar el clúster y, si es así, la magnitud de la actualización.

  1. En cada evaluación, el ajuste de escala automático examina el promedio de memoria pendiente y disponible del clúster durante el último cooldown_period para determinar el cambio exacto necesario en la cantidad de trabajadores:

    exact Δworkers = avg(pending memory - available memory) / memory per node manager

    • pending memory es una señal de que el clúster tiene tareas en cola, pero aún no se ejecutaron, y es posible que se deba escalar verticalmente para manejar mejor su carga de trabajo.
    • available memory es una señal de que el clúster tiene ancho de banda adicional y es posible que se debe reducir el escalamiento para conservar los recursos.
    • Consulta Ajuste de escala automático con Hadoop y Spark para obtener información adicional sobre estas métricas de Apache Hadoop YARN.
  2. Dado el cambio exacto necesario para la cantidad de trabajadores, el ajuste de escala automático usa un scaleUpFactor o scaleDownFactor para calcular el cambio real en la cantidad de trabajadores:

    if exact Δworkers > 0:
      actual Δworkers = ROUND_UP(exact Δworkers * scaleUpFactor)
      # examples:
      # ROUND_UP(exact Δworkers=5 * scaleUpFactor=0.5) = 3
      # ROUND_UP(exact Δworkers=0.8 * scaleUpFactor=0.5) = 1
    else:
      actual Δworkers = ROUND_DOWN(exact Δworkers * scaleDownFactor)
      # examples:
      # ROUND_DOWN(exact Δworkers=-5 * scaleDownFactor=0.5) = -2
      # ROUND_DOWN(exact Δworkers=-0.8 * scaleDownFactor=0.5) = 0
      # ROUND_DOWN(exact Δworkers=-1.5 * scaleDownFactor=0.5) = 0
    
    Un escalamiento o escalamiento de 1.0 significa que el ajuste de escala automático escalará para que la memoria pendiente o disponible sea 0 (uso perfecto).

  3. Una vez que se calcula el cambio real en la cantidad de trabajadores, scaleUpMinWorkerFraction y scaleDownMinWorkerFraction actúan como un umbral para determinar si el ajuste de escala automático escalará el clúster. Una fracción pequeña significa que el ajuste de escala automático debe escalar incluso si el valor de Δworkers es pequeño. Una fracción mayor significa que el escalamiento solo debe ocurrir cuando el valor de Δworkers es grande.

    if (Δworkers >  scaleUpMinWorkerFraction* cluster size) then scale up
    o
    if (abs(Δworkers) >  scaleDownMinWorkerFraction* cluster size) then scale down

  4. Si la cantidad de trabajadores que se escalan es lo suficientemente grande para activar el escalamiento, el ajuste de escala automático usa los límites de minInstances maxInstances de workerConfig,secondaryWorkerConfig y weight (proporción de trabajadores principales con respecto a los secundarios) para determinar cómo dividir la cantidad de trabajadores en los grupos de instancias de trabajadores principales y secundarios. El resultado de estos cálculos es el cambio final del ajuste de escala automático al clúster durante el período de escalamiento.

Retiro de servicio ordenado

El ajuste de escala automático admite el retiro de servicio ordenado de YARN cuando se quitan nodos de un clúster. El retiro de servicio ordenado permite que las aplicaciones terminen de redistribuir datos entre etapas para evitar configurar el progreso del trabajo. El ⁠tiempo de espera de retiro de servicio ordenado que se proporciona en una política de ajuste de escala automático es el límite superior de duración que esperará YARN para las aplicaciones en ejecución (aplicaciones que se estaban ejecutando cuando se inició el retiro) antes de quitar los nodos.

Uso de la política en varios clústeres

  • Una política de ajuste de escala automático define el comportamiento de escalamiento que se puede aplicar a varios clústeres. Una política de ajuste de escala automático se aplica mejor en varios clústeres cuando los clústeres compartirán cargas de trabajo similares o ejecutarán trabajos con patrones de uso de recursos similares.

  • Puedes actualizar una política que usan varios clústeres. Las actualizaciones afectan de inmediato el comportamiento del ajuste de escala automático en todos los clústeres que usan la política (consulta autoscalingPolicies.update). Si no quieres que una actualización de política se aplique a un clúster que usa la política, inhabilita el ajuste de escala automático en el clúster antes de actualizar la política.

Comando de gcloud

Ejecuta el comando de gcloud siguiente desde una terminal local o en Cloud Shell para inhabilitar el ajuste de escala automático en un clúster.

gcloud dataproc clusters update cluster-name --disable-autoscaling

API de REST

Para inhabilitar el ajuste de escala automático en un clúster, establece AutoscalingConfig.policyUri en la string vacía y establece update_mask=config.autoscaling_config.policy_uri en una solicitud clusters.patch.

Console

Actualmente, la inhabilitación del ajuste de escala automático en un clúster no es compatible con Google Cloud Console.

Recomendaciones de ajuste de escala automático

  • Período de inactividad: El valor mínimo y predeterminado de cooldownPeriod es de dos minutos. Si se establece un cooldownPeriod más corto en una política, los cambios en la carga de trabajo afectarán más rápidamente el tamaño del clúster, pero los clústeres pueden aumentar o reducir el escalamiento innecesariamente. Se recomienda configurar los valores scale_up, scale_down y min_worker_fractions de una política en un valor distinto de cero cuando uses un cooldownPeriod más corto. Esto garantiza que el clúster solo aumente o disminuya la escala cuando el cambio en el uso de la memoria sea suficiente para garantizar una actualización del clúster.

  • Reducción del escalamiento: MapReduce y Spark escriben datos aleatorios e intermedios en el disco local. Si se quitan trabajadores con datos aleatorios, se retrasará el progreso del trabajo, ya que se deberán volver a ejecutar las tareas de asignación para reproducir los datos aleatorios. Spark vuelve a ejecutar etapas completas si detecta que faltan archivos aleatorios.

    • Para reducir la escala solo cuando un clúster está inactivo, configura scale_down factor y scale_down min_worker_fraction en 1.0.

    • Para clústeres con carga continua, configura la reducción de escalamiento entre trabajos mediante la configuración del factor scale_down en 1.0 y de graceful_decommission_timeout en un valor distinto de cero para quitar los nodos del clúster cuando no están ejecutando contenedores de YARN (consulta Retiro de servicio ordenado). Configura graceful_decommission_timeout de modo que sea más largo que el trabajo del clúster más antiguo para asegurarte de que los nodos no se retiren a la fuerza antes de que finalice un trabajo.

    • Considera usar el modo de flexibilidad mejorada para evitar o reducir la posibilidad de perder el progreso del trabajo cuando se quitan nodos.

  • Trabajos de Spark con datos almacenados en caché: Configura spark.dynamicAllocation.cachedExecutorIdleTimeout o los conjuntos de datos no almacenados en caché cuando ya no sean necesarios. De forma predeterminada, Spark no elimina los ejecutores que tienen datos almacenados en caché.

Ajuste de escala automático con Apache Hadoop y Apache Spark

En las siguientes secciones, se analiza cómo el ajuste de escala automático interactúa (o no) con Hadoop YARN y Hadoop Mapreduce, y con Apache Spark, Spark Streaming y Spark Structured Streaming.

Métricas de Hadoop YARN

El ajuste de escala automático configura Hadoop YARN para programar trabajos basados en solicitudes de memoria YARN, no en solicitudes de núcleo YARN.

El ajuste de escala automático se centra en las siguientes métricas de YARN de Hadoop:

  1. Allocated memory se refiere al total de memoria YARN que ocupan los contenedores en todo el clúster. Si hay 6 contenedores en ejecución que pueden usar hasta 1 GB, hay 6 GB de memoria asignada.

  2. Available memory es la memoria de YARN en el clúster que no usan los contenedores asignados. Si hay 10 GB de memoria en todos los administradores de nodos y 6 GB de memoria asignada, hay 4 GB de memoria disponible. Si hay memoria disponible (sin usar) en el clúster, el ajuste de escala automático puede quitar trabajadores del clúster.

  3. Pending memory es la suma de las solicitudes de memoria YARN para contenedores pendientes. Los contenedores pendientes están esperando que haya espacio para ejecutarse en YARN. La memoria pendiente no es cero solo si la memoria disponible es cero o un valor demasiado pequeño para asignar al siguiente contenedor. Si hay contenedores pendientes, el ajuste de escala automático puede agregar trabajadores al clúster.

Puedes ver estas métricas en Cloud Monitoring. Como configuración predeterminada, la memoria YARN será 0.8 × la memoria total en el clúster, con la memoria restante reservada para otros daemons y uso del sistema operativo, como la caché de la página. Puedes anular el valor predeterminado con la configuración de configuración "yarn.nodemanager.resource.memory-mb" de YARN (consulta Apache Hadoop YARN, HDFS, Spark y propiedades relacionadas).

Ajuste de escala automático y MapReduce de Hadoop

MapReduce ejecuta cada asignación y reduce la tarea como un contenedor de YARN independiente. Cuando se inicia un trabajo, MapReduce envía solicitudes de contenedor a cada tarea de asignación, lo que da como resultado un gran aumento en la memoria YARN. A medida que finalizan las tareas de asignación, la memoria pendiente disminuye.

Cuando mapreduce.job.reduce.slowstart.completedmaps se completa (el 95% de forma predeterminada en Dataproc), MapReduce agrega a la cola las solicitudes de contenedor para todos los reductores, lo que da como resultado otro aumento en la memoria pendiente.

A menos que las tareas de asignación y reducción tomen varios minutos o más, no establezcas un valor alto para el ajuste de escala automático scaleUpFactor. Agregar trabajadores al clúster toma al menos 1.5 minutos, así que asegúrate de que haya suficiente trabajo pendiente para usar trabajadores nuevos durante varios minutos. Un buen punto de partida es configurar scaleUpFactor en 0.05 (5%) o 0.1 (10%) de memoria pendiente.

Ajuste de escala automático y Spark

Spark agrega una capa adicional de programación sobre YARN. En particular, la asignación dinámica de Spark Core realiza solicitudes de contenedores a YARN a fin de ejecutar los ejecutores de Spark y, luego, programa las tareas de Spark en los subprocesos de esos ejecutores. Los clústeres de Dataproc habilitan la asignación dinámica de forma predeterminada, por lo que se agregan y quitan ejecutores, según sea necesario.

Spark siempre solicita contenedores a YARN, pero sin asignación dinámica; solo solicita contenedores al comienzo del trabajo. Con la asignación dinámica, se quitarán los contenedores o se solicitarán nuevos.

Spark comienza con una pequeña cantidad de ejecutores (2 en los clústeres de ajuste de escala automático) y sigue duplicando la cantidad de ejecutores mientras hay tareas pendientes. Esto atenúa la memoria pendiente (menos picos de memoria pendientes). Se recomienda configurar el ajuste de escala automático scaleUpFactor en un número grande, como 1.0 (100%), para trabajos de Spark.

Inhabilita la asignación dinámica de Spark

Si ejecutas trabajos de Spark separados que no se benefician de la asignación dinámica de Spark, puedes inhabilitar la asignación dinámica de Spark si configuras spark.dynamicAllocation.enabled=false y spark.executor.instances. Aún puedes usar el ajuste de escala automático para aumentar o disminuir el escalamiento de los clústeres mientras se ejecutan los trabajos de Spark independientes.

Ajuste de escala automático y transmisión de Spark

  1. Dado que Spark Streaming tiene su propia versión de asignación dinámica que usa señales específicas de transmisión para agregar y quitar ejecutores, debes configurar spark.streaming.dynamicAllocation.enabled=true e inhabilitar la asignación dinámica de Spark Core mediante el establecimiento de spark.dynamicAllocation.enabled=false.

  2. No uses el retiro de servicio ordenado (ajuste de escala automático de gracefulDecommissionTimeout) con trabajos de Spark Streaming. En su lugar, para quitar trabajadores de forma segura con el ajuste de escala automático, configura el punto de control para obtener la tolerancia a errores.

Como alternativa, para usar Spark Streaming sin ajuste de escala automático, haz lo siguiente:

  1. Inhabilita la asignación dinámica de Spark Core (spark.dynamicAllocation.enabled=false)
  2. Establece la cantidad de ejecutores (spark.executor.instances) para tu trabajo. Consulta Propiedades del clúster.

Ajuste de escala automático y Spark Structured Streaming

El ajuste de escala automático no es compatible con Spark Structured Streaming porque este no admite la asignación dinámica (consulta SPARK-24815: Structured Streaming debe admitir la asignación dinámica).

Controla el ajuste de escala automático mediante particiones y paralelismo

Si bien el paralelismo suele establecerse o determinarse en función de los recursos del clúster (por ejemplo, la cantidad de bloques de HDFS controla la cantidad de tareas), con el ajuste de escala automático sucede lo contrario: el ajuste de escala automático establece la cantidad de trabajadores según el paralelismo de trabajo. A continuación, se incluyen lineamientos que te ayudarán a configurar el paralelismo de trabajos:

  • Si bien Dataproc establece la cantidad predeterminada de tareas de reducción de MapReduce en función del tamaño inicial del clúster, puedes configurar mapreduce.job.reduces para aumentar el paralelismo de la fase de reducción.
  • El paralelismo de Spark SQL y Dataframe está determinado por spark.sql.shuffle.partitions, que se establece de forma predeterminada en 200.
  • El valor predeterminado de las funciones de RDD de Spark es spark.default.parallelism, que se establece en la cantidad de núcleos en los nodos trabajadores cuando se inicia el trabajo. Sin embargo, todas las funciones de RDD que crean aleatoriamente toman un parámetro para la cantidad de particiones, que anula spark.default.parallelism.

Debes asegurarte de que tus datos estén particionados de forma uniforme. Si hay una desviación significativa de la clave, una o más tareas pueden tardar mucho más tiempo que otras tareas, lo que da como resultado un uso bajo.

Ajuste de escala automático de la configuración predeterminada de las propiedades de Spark y Hadoop

Los clústeres de ajuste de escala automático tienen valores de propiedad de clúster predeterminados que ayudan a evitar fallas en los trabajos cuando se quitan los trabajadores principales o se interrumpen los trabajadores secundarios. Puedes anular estos valores predeterminados cuando creas un clúster con ajuste de escala automático (consulta Propiedades del clúster).

Parámetros predeterminados de configuración para aumentar la cantidad máxima de reintentos de tareas, instancias principales y etapas:

yarn:yarn.resourcemanager.am.max-attempts=10
mapred:mapreduce.map.maxattempts=10
mapred:mapreduce.reduce.maxattempts=10
spark:spark.task.maxFailures=10
spark:spark.stage.maxConsecutiveAttempts=10

Parámetros predeterminados de configuración para restablecer los contadores de reintentos (útil para trabajos de Spark Streaming de larga duración):

spark:spark.yarn.am.attemptFailuresValidityInterval=1h
spark:spark.yarn.executor.failuresValidityInterval=1h

Configuración predeterminada para que el mecanismo de asignación dinámica de inicio lento de Spark comience desde un tamaño pequeño:

spark:spark.executor.instances=2

Ajuste de escala automático de registros y métricas

Los siguientes recursos y herramientas pueden ayudarte a supervisar las operaciones de ajuste de escala automático y su efecto en tu clúster y sus trabajos.

Cloud Monitoring

Usa Cloud Monitoring para hacer lo siguiente:

  • ver las métricas que usa el ajuste de escala automático
  • ver la cantidad de administradores de nodos en tu clúster
  • comprender por qué el ajuste de escala automático escaló o no tu clúster autoscaling-stackdriver1 autoscaling-stackdriver2 autoscaling-stackdriver3

Cloud Logging

Usa Cloud Logging para ver los registros del escalador automático de Cloud Dataproc.

1) Busca registros para tu clúster.

autoscaling-logs-for-cluster

2) Selecciona dataproc.googleapis.com/autoscaler.

autoscaling-log-file

3) Expande los mensajes de registro para ver el campo status. Los registros están en formato JSON, un formato legible por computadora.

autoscaling-three-logs autoscaling-update-operation

4) Expande el mensaje de registro para ver las recomendaciones de escalamiento, las métricas utilizadas a fin de tomar decisiones de escalamiento, el tamaño original del clúster y el tamaño nuevo del clúster de destino.

autoscaling-recommendation-message

Preguntas frecuentes

¿Se puede habilitar el ajuste de escala automático en clústeres de alta disponibilidad y de un solo nodo?

El ajuste de escala automático se puede habilitar en clústeres de alta disponibilidad, pero no en clústeres de un solo nodo (los clústeres de un solo nodo no admiten el cambio de tamaño).

¿Puedes cambiar el tamaño de un clúster de ajuste de escala automático de forma manual?

Sí. Puedes decidir cambiar el tamaño de un clúster de forma manual como una medida de detención cuando se modifica una política de ajuste de escala automático. Sin embargo, estos cambios solo tendrán un efecto temporal, y el ajuste de escala automático escalará el clúster luego.

En lugar de cambiar el tamaño de un clúster de ajuste de escala automático de forma manual, considera lo siguiente:

Actualiza la política de ajuste de escala automático. Todos los cambios realizados en la política de ajuste de escala automático afectarán a todos los clústeres que estén usando la política (consulta el Uso de la política en varios clústeres).

Desconecta la política y escala de forma manual el clúster hasta alcanzar el tamaño preferido.

Obtén asistencia de Dataproc.

¿Qué versiones de imagen admiten el ajuste de escala automático? ¿Qué versiones de la API lo admiten?

El ajuste de escala automático es compatible con la API v1 en las versiones de imagen de clúster 1.0.99+, 1.190+, 1.2.22+, 1.3.0+ y 1.4.0+ (consulta la Lista de versiones de Cloud Dataproc) y obtén información mediante los comandos gcloud dataproc autoscaling-policies.

¿En qué se diferencia Dataproc del ajuste de escala automático de Dataflow?

Consulta Compara el ajuste de escala automático de Cloud Dataflow con Spark y Hadoop