Orientación sobre errores comunes

En esta página, se describen algunos errores comunes que puedes encontrar cuando ejecutas tu trabajo de Cloud Dataflow, y se sugieren algunas medidas para tratar esos errores.

Mensajes de trabajo:

Errores de envío de trabajos:

Registros de trabajador (Stackdriver):

Mensajes de trabajo

"El trabajo falló porque un elemento de trabajo falló 4 veces".

Si una sola operación hace que el código de trabajador falle cuatro veces, al arrojar una excepción o bloquearse, Cloud Dataflow falla el trabajo y se muestra el mensaje a work item failed 4 times.

Busca en los registros de Stackdriver del trabajo las cuatro fallas individuales. Busca las entradas de registro Nivel de error o Nivel fatal en los registros del trabajador que muestran excepciones o errores. Debes ver al menos cuatro de estas excepciones o errores.

Errores de codificación, IOExceptions o un comportamiento inesperado en el código de usuario.

Los SDK de Apache Beam y los trabajadores de Cloud Dataflow dependen de componentes de terceros. Estos componentes importan dependencias adicionales. La incompatibilidad de las versiones puede provocar un comportamiento inesperado en el servicio. Si usas alguno de estos paquetes en tu código, ten en cuenta que algunas bibliotecas no se pueden desviar. Es posible que necesites fijar las versiones anteriores que estarán dentro del alcance durante la ejecución. SDK y dependencias de trabajadores contiene una lista de dependencias y sus versiones obligatorias.

Trabajos que solían ejecutarse ahora fallan debido a que “No se puede acceder al paquete en etapa de pruebas”

Verifica que el depósito de Cloud Storage utilizado para la etapa de pruebas no tenga una configuración de TTL que haga que los paquetes en etapa de pruebas se borren.

Errores de envío de trabajos

"413 Request Entity Too Large"/"El tamaño de la representación serializada de JSON de la canalización supera el límite permitido"

Si encuentras un error sobre la carga útil de JSON cuando envías tu trabajo, significa que la representación JSON de tu canalización supera el tamaño máximo solicitado de 20 MB. Estos errores pueden aparecer como uno de los siguientes mensajes en la ventana de tu terminal o consola:

  • 413 Request Entity Too Large
  • “El tamaño de la representación serializada JSON de la canalización supera el límite permitido”
  • “No se pudo crear un trabajo de flujo de trabajo: se recibió una carga útil de JSON no válido”
  • “No se pudo crear un trabajo de flujo de trabajo: la carga útil solicitada supera el límite permitido”

El tamaño de tu trabajo se relaciona específicamente con la representación JSON de la canalización. Una canalización mayor implica una solicitud mayor. Cloud Dataflow actualmente dispone de una limitación de 20 MB para las solicitudes.

Para estimar el tamaño de la solicitud JSON de tu canalización, ejecuta tu canalización con la siguiente opción:

Java: SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Java: SDK 1.x

--dataflowJobFile=< path to output file >

Este comando escribe una representación JSON de tu trabajo en un archivo. El tamaño del archivo serializado es una estimación apropiada del tamaño de la solicitud. El tamaño real será un poco mayor debido a que se incluye información adicional en la solicitud.

Algunas condiciones en tu canalización pueden provocar que la representación JSON supere el límite. Entre las condiciones comunes, se incluyen las siguientes:

  • Una transformación Create que incluye una gran cantidad de datos en memoria.
  • Una instancia DoFn de gran tamaño que se serializa para la transmisión a trabajadores remotos.
  • Un DoFn como una instancia de clase interna anónima que (posiblemente de forma involuntaria) incorpora gran cantidad de datos para que sean serializados.

Para evitar estas condiciones, considera reestructurar tu canalización.

"El grafo del trabajo es demasiado grande. Vuelve a intentarlo con un grafo de trabajo más pequeño, o divide tu trabajo en dos o más trabajos más pequeños".

El tamaño del grafo de tu trabajo no debe superar los 10 MB. Algunas condiciones en tu canalización pueden provocar que el grafo del trabajo supere el límite. Entre las condiciones comunes, se incluyen las siguientes:

  • Una transformación Create que incluye una gran cantidad de datos en memoria.
  • Una instancia DoFn de gran tamaño que se serializa para la transmisión a trabajadores remotos.
  • Un DoFn como una instancia de clase interna anónima que (posiblemente de forma involuntaria) incorpora gran cantidad de datos para que sean serializados.

Para evitar estas condiciones, considera reestructurar tu canalización.

“La cantidad total de objetos BoundedSource generados por la operación splitIntoBundles() es mayor que el límite permitido” o “El tamaño total de los objetos BoundedSource generados por la operación splitIntoBundles() es mayor que el límite permitido”.

Java: SDK 2.x

Puedes encontrarte con este error si lees a partir de una gran cantidad de archivos mediante TextIO, AvroIO o alguna otra fuente basada en archivos. El límite específico depende de los detalles de tu fuente (p. ej., un esquema incorporado en AvroIO.Read permitirá una menor cantidad de archivos), pero corresponde a alrededor de decenas de miles de archivos en una canalización.

También puedes encontrarte con este error si creaste una fuente de datos personalizada para tu canalización y el método splitIntoBundles de tu fuente muestra una lista de objetos BoundedSource que necesita más de 20 MB cuando se serializa.

El límite permitido para el tamaño total de los objetos BoundedSource generados por la operación splitIntoBundles() de tu fuente personalizada es de 20 MB. Puedes trabajar con esta limitación si modificas tu subclase BoundedSource personalizada, de manera que el tamaño total de los objetos BoundedSource generados sea menor que el límite de 20 MB. Por ejemplo, en un principio, tu fuente puede generar menos divisiones y usar un Reequilibrio dinámico del trabajo para seguir dividiendo entradas según se requiera.

Java: SDK 1.x

Puedes encontrarte con este error si lees a partir de una gran cantidad de archivos mediante TextIO, AvroIO o alguna otra fuente basada en archivos. El límite específico depende de los detalles de tu fuente (p. ej., un esquema incorporado en AvroIO.Read permitirá una menor cantidad de archivos), pero corresponde a alrededor de decenas de miles de archivos en una canalización.

También puedes encontrarte con este error si creaste una fuente de datos personalizada para tu canalización y el método splitIntoBundles de tu fuente muestra una lista de objetos BoundedSource que necesita más de 20 MB cuando se serializa.

El límite permitido para el tamaño total de los objetos BoundedSource generados por la operación splitIntoBundles() de tu fuente personalizada es de 20 MB. Puedes trabajar con esta limitación si modificas tu subclase BoundedSource personalizada, de manera que el tamaño total de los objetos BoundedSource generados sea menor que el límite de 20 MB. Por ejemplo, en un principio, tu fuente puede generar menos divisiones y usar un Reequilibrio dinámico del trabajo para seguir dividiendo entradas según se requiera.

Registros de trabajador (Stackdriver)

"El procesamiento se atascó en el paso <step_id> durante al menos <time_interval> sin generar o completar el estado finalizado en <stack_trace>"

Si Cloud Dataflow pasa más tiempo ejecutando un DoFn que el tiempo especificado en <time_interval> sin mostrar, se visualiza este mensaje.

Este error tiene dos causas posibles:

  • Tu código DoFn es lento o espera que se complete una operación externa lenta. En este caso, puedes ignorar la advertencia.
  • O bien, es posible que tu código DoFn esté atascado, bloqueado o sea demasiado lento para terminar de procesarse. Si crees que este es tu caso, expande la entrada de registro de Stackdriver para ver un seguimiento de pila del código atascado.

Puedes investigar más a fondo la causa de tu código atascado si tu canalización está compilada en la VM de Java (mediante Java o Scala); realiza una reducción completa de los subprocesos de toda la JVM (no solo del subproceso atascado) mediante estos pasos:

  1. Toma nota del nombre del trabajador de la entrada de registro.
  2. En la sección de Compute Engine de GCP Console, busca la instancia de Compute Engine con el nombre del trabajador que anotaste.
  3. Establece una conexión SSH a la instancia con ese nombre.
  4. Ejecuta el comando siguiente:

    curl http://localhost:8081/threadz
    

Excepciones de tiempo de espera de RPC, excepciones "DEADLINE_EXCEEDED" o errores de "Server Unresponsive"

Si te encuentras con tiempos de espera de RPC, excepciones de DEADLINE_EXCEEDED o errores de Server Unresponsive mientras se ejecuta tu trabajo, comúnmente estos indican que existe uno de estos dos problemas:

  • Es posible que a la red de VPC que se usa para tu trabajo le falte una regla de firewall. La regla de firewall necesita habilitarse en todo el tráfico de TCP en las VM en la red de VPC que especificaste en tus opciones de canalización. Consulta Cómo especificar tu red y subred para obtener más detalles.

  • Tu trabajo se delimita aleatoriamente. Considera una de las siguientes medidas, o una combinación de ellas:

    Java: SDK 2.x

    • Agrega más trabajadores. Prueba configurar --numWorkers con un valor mayor cuando ejecutes tu canalización.
    • Aumenta el tamaño del disco conectado para los trabajadores. Prueba configurar --diskSizeGb con un valor mayor cuando ejecutes tu canalización.
    • Usa un disco persistente respaldado por SSD. Prueba configurar --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" cuando ejecutes tu canalización.

    Python

    • Agrega más trabajadores. Prueba configurar --num_workers con un valor mayor cuando ejecutes tu canalización.
    • Aumenta el tamaño del disco conectado para los trabajadores. Prueba configurar --disk_size_gb con un valor mayor cuando ejecutes tu canalización.
    • Usa un disco persistente respaldado por SSD. Prueba configurar --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" cuando ejecutes tu canalización.

    Java: SDK 1.x

    • Agrega más trabajadores. Prueba configurar --numWorkers con un valor mayor cuando ejecutes tu canalización.
    • Aumenta el tamaño del disco conectado para los trabajadores. Prueba configurar --diskSizeGb con un valor mayor cuando ejecutes tu canalización.
    • Usa un disco persistente respaldado por SSD. Prueba configurar --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" cuando ejecutes tu canalización.

Una llamada del agente de trabajo de Java a un DoFn de Python falló con el error <error message>

Si un DoFn implementado en Python falla y arroja una excepción, se muestra un mensaje de error relevante.

Expande la entrada de registro de errores Stackdriver y observa el mensaje de error y el traceback. Te muestra qué código falló para que puedas corregirlo si es necesario. Si crees que se trata de un error en Apache Beam o Cloud Dataflow, informa el error.

No queda espacio en el dispositivo

Si un trabajo almacena aleatoriamente una gran cantidad de datos o escribe datos temporales en los discos locales, es posible que el almacenamiento continuo del trabajador se quede sin espacio libre.

Si ves un mensaje que notifica que no queda espacio en el dispositivo, aumenta el tamaño de los discos persistentes de tus trabajadores mediante la configuración de la opción de canalización relevante. Para trabajos de Java, usa la marca --diskSizeGb. Para trabajos de Python, usa --disk_size_gb.

Errores de espacio en disco como "RESOURCE_EXHAUSTED: error de E/S: No queda espacio en el disco"

Estos errores comúnmente indican que asignaste espacio insuficiente en el disco local para procesar tu trabajo. Si ejecutas tu trabajo con una configuración predeterminada, se ejecutará en 3 trabajadores, cada uno con 25 GB de espacio local en el disco y sin ajuste de escala automático. Considera modificar la configuración predeterminada a fin de aumentar la cantidad de trabajadores disponibles para tu trabajo, aumentar el espacio predeterminado en el disco por trabajador o habilitar el ajuste de escala automático.

Advertencias de "solicitud incorrecta" en los registros del shuffler

Durante la ejecución de un trabajo de Cloud Dataflow, los registros de Stackdriver pueden mostrar una serie de advertencias similares a:

Unable to update setup work item <step_id> error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id <lease_id>
with expiration time: <timestamp>, now: <timestamp>. Full status: generic::invalid_argument: Http(400) Bad Request

Las advertencias de "solicitud incorrecta" aparecen porque la información del estado del trabajador está inactiva o no están sincronizadas debido a retrasos de procesamiento. A menudo, tu trabajo de Cloud Dataflow será exitoso a pesar de estas advertencias de "solicitud incorrecta". Si ese es el caso, ignora las advertencias.

Se detectó una clave de acceso rápido en el paso <step_id> con una edad de <time_interval>

Estos errores indican que tienes una clave de acceso rápido. Una clave de acceso rápido es una clave con suficientes elementos para impactar negativamente en el rendimiento de la canalización. Estas claves limitan la capacidad de Cloud Dataflow para procesar elementos en paralelo, lo que aumenta el tiempo de ejecución.

Comprueba que tus datos estén distribuidos de manera uniforme. Si una clave tiene desproporcionadamente muchos valores, considera las siguientes medidas:

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.