Solucionar problemas de tareas de streaming lentas o bloqueadas

En esta página se explica cómo solucionar problemas habituales que provocan que los trabajos de streaming de Dataflow se ejecuten lentamente o se queden bloqueados.

Si observas los siguientes síntomas, es posible que tu tarea de streaming de Dataflow se esté ejecutando lentamente o se haya bloqueado:

Utiliza la información de las siguientes secciones para identificar y diagnosticar el problema.

Identificar la causa principal

  1. Consulta las métricas Actualidad de los datos y Bytes pendientes.

    • Si ambas métricas aumentan de forma monótona, significa que la canalización está bloqueada y no avanza.
    • Si la actualización de datos aumenta, pero los bytes pendientes se mantienen en niveles normales, significa que uno o varios elementos de trabajo están bloqueados en la canalización.

    Busca las fases en las que aumentan estas métricas para identificar cualquier fase que tenga problemas y las operaciones realizadas en ella.

  2. Consulta el gráfico de procesamiento en paralelo para ver si alguna fase se ha bloqueado debido a un paralelismo excesivo o insuficiente. Consulta Solucionar problemas de paralelismo.

  3. Consulta los registros de trabajos para ver si hay algún problema, como límites de cuota, problemas de falta de stock o agotamiento de direcciones IP.

  4. Comprueba si hay advertencias y errores en los registros de los trabajadores.

    • Si los registros de trabajadores contienen errores, consulta el seguimiento de pila. Investiga si el error se debe a un error en tu código.
    • Busca errores de Dataflow. Consulta Solucionar errores de Dataflow.
    • Busca errores que indiquen que el trabajo ha superado un límite, como el tamaño máximo de los mensajes de Pub/Sub.
    • Busca errores de falta de memoria, que pueden provocar que la canalización se quede bloqueada. Si ves errores de falta de memoria, sigue los pasos que se indican en el artículo Solucionar errores de falta de memoria de Dataflow.
    • Para identificar un paso lento o bloqueado, consulta los registros del trabajador para ver los mensajes Operation ongoing. Consulta el rastreo de la pila para ver dónde se está invirtiendo el tiempo. Para obtener más información, consulta Procesamiento bloqueado u operación en curso.

  5. Si un elemento de trabajo se queda bloqueado en un trabajador específico, reinicia la VM de ese trabajador.

  6. Si no usas Streaming Engine, consulta los registros del mezclador para ver si hay advertencias o errores. Si aparece un error de tiempo de espera de RPC en el puerto 12345 o 12346, es posible que falte una regla de cortafuegos en tu trabajo. Consulta Reglas de cortafuegos de Dataflow.

  7. Comprueba si hay teclas de acceso rápido.

  8. Si Runner v2 está habilitado, comprueba si hay errores en los registros de arnés. Para obtener más información, consulta Solucionar problemas de Runner v2.

Investigar fallos repetidos

En un trabajo de streaming, algunos errores se reintentan indefinidamente. Estos reintentos impiden que el flujo de trabajo avance. Para identificar los errores repetidos, consulta los registros de los trabajadores para ver si hay excepciones.

  • Si la excepción se debe al código de usuario, depura y corrige el problema en el código o en los datos.
  • Para evitar que los fallos inesperados detengan tu flujo de procesamiento, implementa una cola de mensajes fallidos. Para ver un ejemplo de implementación, consulta Patrones de BigQuery en la documentación de Apache Beam.
  • Si la excepción es un error de falta de memoria (OOM), consulta Solucionar problemas de falta de memoria de Dataflow.
  • Para ver otras excepciones, consulta Solucionar problemas de Dataflow.

Identificar trabajadores poco saludables

Si los trabajadores que procesan el trabajo de streaming no están en buen estado, el trabajo puede ir lento o parecer que se ha bloqueado. Para identificar los trabajadores que no están en buen estado, sigue estos pasos:

Identificar los elementos que se han quedado atrás

Un elemento de trabajo rezagado es un elemento de trabajo que es lento en comparación con otros elementos de trabajo de la fase. Para obtener información sobre cómo identificar y corregir los elementos rezagados, consulta el artículo Solucionar problemas de elementos rezagados en tareas de streaming.

Solucionar problemas de paralelismo

Para mejorar la escalabilidad y la eficiencia, Dataflow ejecuta las fases de tu pipeline en paralelo en varios trabajadores. La unidad más pequeña de procesamiento paralelo en Dataflow es una clave. Los mensajes entrantes de cada fase combinada se asocian a una clave. La clave se define de una de las siguientes formas:

  • La clave se define implícitamente mediante las propiedades de la fuente, como las particiones de Kafka.
  • La clave se define explícitamente mediante la lógica de agregación de la canalización, como GroupByKey.

En Dataflow, los subprocesos de trabajador se encargan de gestionar el procesamiento de paquetes de trabajo (mensajes) de una clave. El número de hilos disponibles para procesar las claves del trabajo es num_of_workers * threads_per_worker. El número de subprocesos por trabajador se determina en función del SDK (Java, Python o Go) y del tipo de tarea (por lotes o en streaming).

Si la canalización no tiene suficientes claves para una fase determinada, limita el procesamiento en paralelo. Esa fase podría convertirse en un cuello de botella.

Si la canalización usa un número muy elevado de claves en una fase determinada, puede limitar el rendimiento de la fase y acumular trabajo pendiente en las fases anteriores, ya que hay una sobrecarga por clave. Los gastos generales pueden incluir la comunicación del backend con los trabajadores, las llamadas a procedimientos remotos externos a un receptor, como BigQuery, y otros procesos. Por ejemplo, si se tarda 100 ms en procesar una clave con un mensaje, también se tardarán unos 100 ms en procesar 1000 mensajes en ese paquete de claves.

Identificar fases con un paralelismo bajo

Para identificar si la lentitud de la canalización se debe a un paralelismo bajo, consulta las métricas de uso de CPU. Si el uso de la CPU es bajo, pero está distribuido de forma uniforme entre los trabajadores, es posible que tu tarea no tenga suficiente paralelismo. Si tu trabajo usa Streaming Engine, para ver si una fase tiene un paralelismo bajo, ve a la pestaña Métricas de trabajo y consulta las métricas de paralelismo. Para mitigar este problema, sigue estos pasos:

Identificar fases con un alto paralelismo

Una combinación de baja latencia del sistema, actualización de datos creciente y aumento de la acumulación y de las CPUs de los trabajadores infrautilizadas sugiere que la canalización se está limitando debido a un gran número de claves. Consulta el gráfico de procesamiento paralelo para identificar las fases con un gran número de claves.

Las transformaciones como Reshuffle pueden generar millones de claves si no especificas explícitamente withNumBuckets. Un gran número de claves puede dar lugar a la creación de numerosos paquetes de trabajo más pequeños, cada uno de los cuales requiere un subproceso de trabajador específico para procesarse. Como los hilos de trabajadores disponibles son limitados, puede producirse una acumulación significativa de claves de procesamiento, lo que provoca retrasos mientras esperan los recursos. Por lo tanto, los hilos de trabajo no se usan de forma eficiente.

Te recomendamos que limites el número de claves configurando la opción withNumBuckets en la transformación Reshuffle. El valor no debe superar el número total de hilos de todos los trabajadores. Segmentar por (threads_per_worker * max_workers) claves en la canalización puede no ser óptimo. A veces, se pueden usar menos claves y paquetes más grandes, que Dataflow procesa de forma más eficiente porque utiliza menos trabajadores. Si se usa un número menor de claves, se crearán paquetes de trabajo más grandes, lo que permite usar los subprocesos de los trabajadores de forma eficiente y aumentar el rendimiento de la fase.

Si hay varios pasos Reshuffle en la canalización, divide el número total de subprocesos entre el número de pasos Reshuffle para calcular withNumBuckets.

Comprobar si hay teclas de acceso rápido

Si las tareas no se distribuyen de forma uniforme entre los trabajadores y la utilización de los trabajadores es muy desigual, es posible que tu canalización tenga una clave activa. Una tecla de acceso rápido es una tecla que tiene muchos más elementos que procesar en comparación con otras teclas.

Busca las teclas de acceso rápido con el siguiente filtro de registro:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Sustituye JOB_ID por el ID de tu trabajo.

Para solucionar este problema, siga uno o varios de estos pasos:

  • Vuelve a cifrar tus datos. Para generar nuevos pares clave-valor, aplica una transformación ParDo. Para obtener más información, consulta la página de transformación Java ParDo o la página de transformación Python ParDo en la documentación de Apache Beam.
  • Usa .withFanout en tus transformaciones combinadas. Para obtener más información, consulta la clase Combine.PerKey en el SDK de Java o la operación with_hot_key_fanout en el SDK de Python.
  • Si tienes una canalización de Java que procesa PCollectionssin límites de gran volumen, te recomendamos que hagas lo siguiente:
    • Usa Combine.Globally.withFanout en lugar de Combine.Globally.
    • Usa Combine.PerKey.withHotKeyFanout en lugar de Count.PerKey.

Comprobar si la cuota es insuficiente

Asegúrate de que tienes suficiente cuota para la fuente y el receptor. Por ejemplo, si tu canalización lee entradas de Pub/Sub o BigQuery, es posible que tu proyecto de Google Cloud Platform no tenga suficiente cuota. Para obtener más información sobre los límites de cuota de estos servicios, consulta Cuota de Pub/Sub o Cuota de BigQuery.

Si tu trabajo genera un número elevado de errores 429 (Rate Limit Exceeded), es posible que no tenga suficiente cuota. Para comprobar si hay errores, sigue estos pasos:

  1. Ve a la Google Cloud consola.
  2. En el panel de navegación, haz clic en APIs y servicios.
  3. En el menú, haz clic en Biblioteca.
  4. Usa el cuadro de búsqueda para buscar Pub/Sub.
  5. Haz clic en API de Cloud Pub/Sub.
  6. Haz clic en Gestionar.
  7. En el gráfico Tráfico por código de respuesta, busca los códigos de error de cliente (4xx).

También puede usar el explorador de métricas para comprobar el uso de la cuota. Si tu canalización usa una fuente o un receptor de BigQuery, para solucionar problemas de cuota, usa las métricas de la API Storage de BigQuery. Por ejemplo, para crear un gráfico que muestre el número de conexiones simultáneas de BigQuery, sigue estos pasos:

  1. En la Google Cloud consola, selecciona Monitoring:

    Ir a Monitoring

  2. En el panel de navegación, selecciona Explorador de métricas.

  3. En el panel Selecciona una métrica, en Métrica, filtra por Proyecto de BigQuery > Escribir > Número de conexiones simultáneas.

Para obtener instrucciones sobre cómo ver las métricas de Pub/Sub, consulta Monitorizar el uso de cuotas en "Monitorizar Pub/Sub en Cloud Monitoring". Para obtener instrucciones sobre cómo ver las métricas de BigQuery, consulta Ver el uso y los límites de las cuotas en "Crear paneles de control, gráficos y alertas".

Herramientas de depuración

Si una canalización es lenta o se bloquea, las siguientes herramientas pueden ayudarte a diagnosticar el problema.

  • Para correlacionar incidentes e identificar cuellos de botella, usa Cloud Monitoring para Dataflow.
  • Para monitorizar el rendimiento de la canalización, usa Cloud Profiler.
  • Algunas transformaciones son más adecuadas para las canalizaciones de gran volumen que otras. Los mensajes de registro pueden identificar una transformación de usuario bloqueada en las canalizaciones por lotes o de streaming.
  • Para obtener más información sobre una tarea bloqueada, consulta las métricas de tareas de Dataflow. En la siguiente lista se incluyen métricas útiles:
    • La métrica Bytes de la lista de pendientes (backlog_bytes) mide la cantidad de entradas sin procesar en bytes por fase. Usa esta métrica para encontrar un paso fusionado que no tenga un rendimiento. Del mismo modo, la métrica de elementos pendientes (backlog_elements) mide el número de elementos de entrada sin procesar de una fase.
    • La métrica Claves de paralelismo de procesamiento (processing_parallelism_keys) mide el número de claves de procesamiento en paralelo de una fase concreta de la canalización durante los últimos cinco minutos. Use esta métrica para investigar de las siguientes formas:
      • Acota el problema a fases específicas y confirma las advertencias de teclas de acceso rápido, como A hot key ... was detected.
      • Detecta cuellos de botella de rendimiento causados por un paralelismo insuficiente. Estos cuellos de botella pueden provocar que las canalizaciones se ralenticen o se bloqueen.
    • La métrica Retraso del sistema (system_lag) y la métrica de retraso del sistema por fase (per_stage_system_lag) miden el tiempo máximo que un elemento de datos ha estado procesándose o esperando a procesarse. Usa estas métricas para identificar las fases ineficientes y los cuellos de botella de las fuentes de datos.

Para ver otras métricas que no se incluyen en la interfaz web de monitorización de Dataflow, consulta la lista completa de métricas de Dataflow en Métricas de Google Cloud Platform.