Soluciona problemas de cuellos de botella en Dataflow

Se produce un cuello de botella cuando un paso, una etapa o un trabajador ralentizan el trabajo general. Los embudos pueden generar trabajadores inactivos y aumentar la latencia.

Si Dataflow detecta un cuello de botella, el gráfico del trabajo muestra una alerta y el panel Información del paso enumera el tipo de cuello de botella y la causa, si se conoce. Dataflow también exporta la información de detección de cuellos de botella a una métrica de Stackdriver, que presenta los datos como una serie temporal. Esto te permite ver los embotellamientos a lo largo del tiempo o en el pasado.

Comprende los cuellos de botella

Cuando Dataflow ejecuta una canalización de transmisión, el trabajo consta de una serie de componentes, como shuffles de transmisión, subprocesos de procesamiento de función definida por el usuario (DoFn) y puntos de control de estado persistente. Para facilitar el flujo de datos, Dataflow usa colas para conectar estos componentes. Los datos se envían de la transmisión ascendente a la descendente.

En muchas canalizaciones, la capacidad de procesamiento general está limitada por un solo componente, lo que crea un cuello de botella en la canalización. La velocidad a la que los datos pueden pasar por un cuello de botella limita la rapidez con la que la canalización puede aceptar y procesar los datos de entrada.

Por ejemplo, considera una canalización en la que el procesamiento de DoFn ocurre después de una reproducción aleatoria de transmisión. Una cola entre ellos almacena en búfer los datos aleatorizados, pero sin procesar. Si el procesamiento de DoFn no puede consumir datos tan rápido como los produce el shuffle de transmisión, la cola crece. Un cuello de botella prolongado puede hacer que la fila alcance su capacidad. En ese punto, se detiene la reproducción aleatoria y la lista de reproducción se propaga de forma ascendente. Las colas más arriba también acumulan elementos pendientes, lo que, con el tiempo, provoca una desaceleración que se extiende a la fuente de datos, lo que significa que toda la canalización no puede seguir el ritmo de la entrada.

Cuando se produce un cuello de botella, es posible que una parte importante de la canalización parezca estar en mal estado, aunque un solo punto de la canalización esté causando la acumulación. Este comportamiento puede dificultar la depuración de los cuellos de botella. El objetivo de la detección de cuellos de botella es identificar la ubicación y la causa precisas, lo que elimina las conjeturas, para que puedas corregir la causa raíz.

Dataflow detecta un cuello de botella cuando una demora supera el umbral de cinco minutos. Si la demora no supera este umbral, Dataflow no detecta un cuello de botella.

La detección de cuello de botella no siempre requiere que tomes medidas y depende de tu caso de uso. Una canalización puede funcionar normalmente con retrasos transitorios de más de cinco minutos. Si esto es aceptable para tu caso de uso, es posible que no necesites resolver los cuellos de botella indicados.

Tipos de cuellos de botella

Cuando Dataflow detecta un cuello de botella, la interfaz de supervisión indica la gravedad del problema. Los embudos de conversión se dividen en las siguientes categorías:

El procesamiento se atascó y no avanza
El progreso de la canalización se detiene por completo en este paso.
El procesamiento está en curso, pero se está retrasando.
La canalización no puede procesar los datos entrantes con la misma rapidez con la que llegan. Como resultado, la lista de tareas pendientes está creciendo.
El procesamiento está en curso, pero las tareas pendientes son constantes
La canalización está progresando, y la tasa de procesamiento es comparable a la tasa de entrada. El procesamiento es lo suficientemente rápido como para que no aumenten las tareas pendientes, pero las tareas pendientes acumuladas tampoco disminuyen de manera significativa.
El procesamiento está en curso y se está poniendo al día con las tareas pendientes.
La cantidad de tareas pendientes está disminuyendo, pero el cuello de botella actual impide que la canalización se ponga al día más rápido. Si inicias una canalización con un backlog, este estado podría ser normal y no requerir ninguna intervención. Supervisa el progreso para ver si las tareas pendientes siguen disminuyendo.

Causas de los cuellos de botella

En esta sección, se enumeran las causas de los cuellos de botella que se pueden detectar. Usa esta información para resolver el problema. En algunos casos, puede haber varias causas presentes, y estas podrían estar relacionadas. Por ejemplo, si los trabajadores no tienen recursos suficientes, el uso de CPU virtuales podría ser alto. El uso alto de CPU virtual puede ralentizar las operaciones, lo que, a su vez, puede generar una demora elevada en la cola. El análisis de causa probable puede mostrar todas estas opciones como las causas del cuello de botella.

Operaciones con tiempo de procesamiento largo

El cálculo tiene un tiempo de procesamiento prolongado. Esto ocurre cada vez que se envía un paquete de entrada al trabajador que ejecuta el DoFn y transcurre un tiempo significativo sin que haya resultados disponibles.

Por lo general, esto se debe a una sola operación de larga duración en el código del usuario. Otros problemas pueden manifestarse como operaciones con tiempos de procesamiento largos. Por ejemplo, los errores que se arrojan y se vuelven a intentar dentro de DoFn, los reintentos durante períodos prolongados o las fallas del arnés del trabajador debido a factores como los errores de OOM pueden causar estos tiempos de procesamiento prolongados.

Si el cálculo afectado se encuentra en el código del usuario, busca formas de optimizar el código o limitar el tiempo de ejecución. Para ayudar con la depuración, los registros del trabajador muestran seguimientos de pila para cualquier operación que se detenga durante más de 5 minutos.

Lectura lenta de estado persistente

El cálculo dedica una cantidad significativa de tiempo a leer el estado persistente como parte de la ejecución de DoFn. Esto puede deberse a un estado persistente demasiado grande o a demasiadas lecturas. Considera reducir el tamaño del estado persistente o la frecuencia de las lecturas. También puede ser un problema transitorio debido a la lentitud del estado persistente subyacente.

Escritura lenta de estado persistente

La computación dedica una cantidad significativa de tiempo a escribir el estado persistente durante la confirmación de los resultados del procesamiento. Esto puede deberse a un estado persistente demasiado grande. Considera reducir el tamaño del estado persistente. También puede ser un problema transitorio debido a la lentitud del estado persistente subyacente.

Confirmación rechazada

No se puede confirmar el procesamiento de datos en el estado persistente porque no es válido. Por lo general, esto se debe a que se excedió uno de los límites operativos. Consulta los registros para obtener más detalles o comunícate con el equipo de asistencia.

Particiones de origen de Apache Kafka insuficientes

El cálculo de la fuente de Apache Kafka no tiene suficientes particiones. Para resolver este problema, prueba lo siguiente:

  • Aumenta la cantidad de particiones de Kafka.
  • Incluye la redistribución con .withRedistribute() cuando configures la lectura de E/S de Kafka para paralelizar los datos de manera más eficiente. Incluye .withRedistributeNumKeys(N), donde N > partitions proporciona un límite superior para la cantidad total de claves. Tener una cantidad limitada de claves proporciona eficiencia a través de la agrupación de registros.
  • Para minimizar el costo del Shuffle de redistribución, usa .withOffsetDeduplication(). Este modo minimiza la cantidad de datos que se deben conservar como parte del shuffle y, al mismo tiempo, proporciona un procesamiento exacto una sola vez.

Para obtener más información, consulta Paralelismo en la página Lee desde Apache Kafka a Dataflow.

La fuente de Apache Kafka tiene un gran volumen de estado persistido

El cálculo de la fuente de Apache Kafka está redistribuyendo un gran volumen de datos, lo que podría generar una latencia y un costo elevados. Para resolver este problema, prueba lo siguiente:

  • Si se requiere el procesamiento de tipo “exactamente una vez” para la canalización, minimiza el costo del Shuffle de redistribución utilizando el modo de anulación de duplicación por desplazamiento. Este modo minimiza la cantidad de datos que se deben conservar como parte del shuffle y, al mismo tiempo, proporciona un procesamiento exacto una sola vez.
  • Si el procesamiento al menos una vez es suficiente para la canalización, se puede habilitar la configuración de permitir duplicados.

Para obtener más información, consulta Lee desde Apache Kafka a Dataflow.

Paralelismo de fuente insuficiente

Un cálculo de fuente tiene paralelismo insuficiente. Si es posible, aumenta la paralelización dentro de la fuente. Si no puedes aumentar la paralelización y el trabajo usa el modo de al menos una vez, intenta agregar una transformación Redistribute a la canalización.

Claves populares o paralelismo de claves insuficiente

El trabajo tiene claves populares o paralelismo de claves insuficiente.

Para cada clave de fragmentación, Dataflow procesa los mensajes de forma serial. Mientras Dataflow procesa un lote de mensajes para una clave determinada, los demás mensajes entrantes para esa clave se ponen en cola hasta que se completa el lote actual.

Si Dataflow no puede procesar suficientes claves distintas en paralelo, se puede generar un cuello de botella. Por ejemplo, los datos pueden tener muy pocas claves distintas, o bien ciertas claves pueden estar sobrerrepresentadas en los datos ("claves activas"). Para obtener más información, consulta Soluciona problemas de trabajos de transmisión lentos o atascados.

CPUs virtuales con aprovisionamiento insuficiente

El trabajo no tiene suficientes CPU virtuales de trabajador. Esta situación se produce cuando el trabajo ya se ajustó a su capacidad máxima, el uso de CPU virtual es alto y aún hay una acumulación de tareas pendientes. Es posible que debas aumentar la cantidad máxima de trabajadores aprovisionados para este trabajo. Por ejemplo, podrías aumentar este número con una actualización del rango de ajuste de escala automático. Como alternativa, busca formas en las que se pueda reducir el uso de CPU virtuales con cambios en el código de la canalización o la carga de trabajo. Puedes usar Cloud Profiler para buscar oportunidades de optimización.

Uso alto de CPU virtual, esperando la mejora

El trabajo tiene un uso alto de CPU virtual, pero hay espacio para mejorar. Es probable que esta condición sea transitoria hasta que se pueda realizar el aumento de escala. Puedes supervisar el ajuste de escala automático para ver las decisiones de ajuste de escala automático. Si esta condición persiste durante mucho tiempo o se produce con frecuencia, es posible que debas cambiar la configuración del ajuste de escala automático estableciendo una sugerencia de uso del trabajador diferente para permitir que el trabajo aumente su escala de forma más proactiva.

Carga de CPU virtuales desequilibrada que crea cuellos de botella en algunos trabajadores atípicos

El trabajo tiene suficientes CPU virtuales de trabajador, pero algunos trabajadores muestran un uso de CPU virtuales muy alto. Esto suele deberse a una distribución desigual del trabajo. Entre las posibles causas, se incluyen las particiones de origen cargadas de forma desigual o las teclas de acceso rápido.

Para resolver este problema, realiza las siguientes acciones:

  • Determina la causa de la carga desigual y trata de corregirla. Por ejemplo, asegúrate de que las particiones de origen estén distribuidas de manera uniforme.
  • Si no es posible corregir la carga desigual, considera cambiar la forma de la VM de trabajador para aumentar las CPU virtuales por trabajador y reducir el uso máximo. Para obtener más información sobre la configuración de las CPU virtuales por trabajador, consulta Configura VMs de trabajador de Dataflow.
Problema de comunicación con los trabajadores

Dataflow no puede comunicarse con todas las VMs de trabajador. Verifica el estado de las VMs de los trabajadores del trabajo. Entre las posibles causas, se incluyen las siguientes:

  • Hay un problema con el aprovisionamiento de las VMs de trabajador.
  • El grupo de VM de trabajador se borra mientras se ejecuta el trabajo.
  • Problemas de red
La fuente de Pub/Sub tiene errores de extracción.

Hay errores de extracción de la fuente de Pub/Sub. Verifica que existan el tema y las suscripciones requeridos, y comprueba la cuota y la configuración. También puedes revisar los registros en busca de errores.

Fuente de Pub/Sub con paralelismo insuficiente

El cálculo de la fuente de Pub/Sub no tiene una cantidad suficiente de claves de Pub/Sub. Para aumentar la cantidad de claves, establece la opción de servicio num_pubsub_keys. Para obtener más información, consulta Paralelismo de la fuente de Pub/Sub.

Limitación de fuente de Pub/Sub por un motivo desconocido

El cálculo de la fuente de Pub/Sub se limita mientras se lee desde Pub/Sub por un motivo desconocido. Este problema puede ser transitorio. Verifica si hay problemas de configuración de Pub/Sub, permisos de IAM faltantes o límites de cuota. Sin embargo, si ninguna de las áreas anteriores es la causa raíz y el problema persiste, comunícate con el equipo de asistencia.

Publicación del receptor de Pub/Sub lenta o atascada

El cálculo del receptor de Pub/Sub es lento o está atascado. Este problema puede deberse a un problema de configuración o a un límite de cuota.

Tiempo de espera alto en la cola de trabajo

La antigüedad más alta de trabajo apta es alta debido a la gran cantidad de claves y a la velocidad a la que se procesan. En esta situación, es posible que cada operación no sea anormalmente larga, pero la demora general en la cola es alta.

Dataflow usa un solo subproceso de procesamiento por clave de fragmentación, y la cantidad de subprocesos de procesamiento es limitada. La demora en la cola es aproximadamente igual a la proporción entre las claves y los subprocesos, multiplicada por la latencia en el subproceso de cada paquete de procesamiento para una clave:

(key count / total harness threads) * latency per bundle

Prueba las siguientes soluciones:

Hay un problema transitorio con el backend de Streaming Engine

Hay un problema de configuración o de operación con el backend de Streaming Engine. Es posible que este problema sea transitorio. Si el problema persiste, comunícate con el equipo de asistencia.

Una causa indeterminada

No se puede determinar con certeza la causa del trabajo pendiente. Este problema puede ser transitorio. Si el problema persiste, comunícate con el equipo de asistencia.

Métricas de cuello de botella

Las siguientes métricas de trabajo proporcionan información sobre los embotellamientos:

  • job/is_bottleneck: Indica si una etapa específica de la canalización de Dataflow es un cuello de botella, junto con su tipo y la causa probable.

  • job/backlogged_keys: Es la cantidad de claves pendientes para una etapa de cuello de botella.

  • job/recommended_parallelism: Es el paralelismo recomendado para una etapa para reducir el cuello de botella.

¿Qué sigue?