Orientación sobre errores comunes

En esta página, se describen algunos errores comunes que pueden surgir cuando ejecutas tu trabajo de Dataflow y se sugieren algunas medidas para solucionarlos.

Errores de agotamiento de recursos:

Mensajes de trabajo:

Errores de envío de trabajos:

Registros de trabajador:

Errores de entrada y salida:

Errores de inicio de trabajador:

Registros:

Recomendaciones:

Errores de agotamiento de recursos

Resuelve errores de un grupo de recursos agotado

En ocasiones, cuando creas un recurso de Google Cloud, es posible que veas un error de un grupo de recursos agotado. Este error indica una condición de agotamiento temporal para un recurso específico en una zona específica. El siguiente es el formato del mensaje:

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

Para resolver el problema, puedes esperar un período o crear el mismo recurso en otra zona. Como práctica recomendada, te recomendamos que distribuyas tus recursos en varias zonas y regiones para tolerar interrupciones.

Mensajes de trabajo

The job failed because a work item failed 4 times.

Si una sola operación hace que el código del trabajador falle cuatro veces, y el código arroja una excepción o falla, Dataflow reprueba el trabajo y se muestra el mensaje a work item failed 4 times. No puedes configurar este límite de error. Para obtener más detalles, consulta control de excepciones y errores de canalización.

Busca las cuatro fallas individuales en los registros de trabajo de Cloud Monitoring. 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 Dataflow dependen de componentes comunes 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 con Staged package...is inaccessible

  • Verifica que el bucket 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.
  • Verifica que la cuenta de servicio del controlador del proyecto de Dataflow tenga permiso para acceder al bucket de Cloud Storage que se usó en la etapa de pruebas. Las brechas en los permisos pueden deberse a cualquiera de los siguientes motivos:

    • El bucket de Cloud Storage que se usa para la etapa de pruebas está presente en un proyecto diferente.
    • El bucket de Cloud Storage que se usó para la etapa de pruebas migró de acceso detallado al acceso uniforme a nivel del depósito. Debido a la inconsistencia entre las políticas de IAM y LCA, migrar el bucket de etapa de pruebas al acceso uniforme a nivel de depósito no permite LCA para recursos de Cloud Storage, lo que incluye los permisos que mantiene la cuenta de servicio del controlador del proyecto de Dataflow a través del depósito de etapa de pruebas.

Para obtener más información, consulta Cómo acceder a buckets de Cloud Storage en todos los proyectos de Google Cloud.

Tiempo de espera del sondeo de plantilla de Flex

El trabajo de plantilla de Flex puede mostrar el siguiente mensaje de error:

Timeout in polling result file: ${file_path}.
Service account: ${service_account_email}
Image URL: ${image_url}
Troubleshooting guide at https://cloud.google.com/dataflow/docs/guides/common-errors#timeout-polling

Esto podría deberse a las siguientes razones:

  1. Se anuló la imagen base de Docker.
  2. La cuenta de servicio que completa ${service_account_email} no tiene los permisos necesarios.
  3. El programa que crea el grafo tarda demasiado en finalizar.
  4. Hay un problema con el archivo requirements.txt (Solo Python).
  5. Se produjo un error transitorio.

Además de verificar los registros de los trabajos y volver a intentarlo en caso de fallas transitorias, estos son algunos pasos adicionales para la solución de problemas.

Verifica el punto de entrada de Docker

Este paso es para aquellos que ejecutan una plantilla a partir de una imagen de Docker personalizada en lugar de usar una de las plantillas proporcionadas.

Verifica el punto de entrada del contenedor con el siguiente comando:

docker inspect $TEMPLATE_IMAGE

Deberías ver lo siguiente:

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

Si obtienes un resultado diferente, entonces se anula el punto de entrada de tu contenedor de Docker. Restablece $TEMPLATE_IMAGE a la configuración predeterminada.

Verifica los permisos de la cuenta de servicio

Verifica que la cuenta de servicio mencionada en el mensaje tenga los siguientes permisos:

  • Debe poder leer y escribir la ruta de acceso de Cloud Storage que completa ${file_path} en el mensaje.
  • Debe poder leer la imagen de Docker que completa ${image_url} en el mensaje.

Comprueba si no se puede salir del programa de lanzamiento

El programa que construye la canalización debe finalizar antes de que se pueda iniciar. El error de sondeo podría indicar que tardó demasiado en hacerlo.

Puedes hacer algunas acciones para ubicar la causa en el código:

  • Verifica los registros del trabajo y verifica si alguna operación tarda mucho tiempo en completarse. Un ejemplo sería una solicitud de un recurso externo.
  • Asegúrate de que ningún subproceso esté bloqueando la salida del programa. Algunos clientes pueden crear sus propios subprocesos y, si estos no se cierran, el programa esperará para que se unan de forma permanente.

Ten en cuenta que las canalizaciones que se iniciaron directamente (sin usar una plantilla) no tienen estas limitaciones, por lo que si la canalización funcionó de forma directa, pero falló como una plantilla, esta podría ser la causa raíz.

Quita Apache Beam del archivo de requisitos (solo Python)

Si tu Dockerfile incluye un requirements.txt con apache-beam[gcp], debes quitarlo del archivo y, luego, instalarlo por separado. Ejemplo:

RUN pip install apache-beam[gcp]
RUN pip install -U -r ./requirements.txt

Se sabe que poner Beam en el archivo de requisitos genera tiempos de inicio largos y, a menudo, provoca un tiempo de espera.

Trabajo de plantilla flexible en Python se pone en cola y agota el tiempo de espera

Si ejecutas un trabajo de Dataflow mediante la plantilla flexible y Python, el trabajo podría quedar en cola durante un período y, luego, no se podría ejecutar. Se muestra un mensaje de error Timeout in polling.

El error se debe al archivo requirements.txt que se usa para instalar las dependencias necesarias. Cuando inicias un trabajo de Dataflow, todas las dependencias se habilitan primero para que las VM de trabajador puedan acceder a estos archivos. El proceso implica la descarga y la recompilación de cada dependencia indirecta y directa en el archivo requirements.txt. Algunas dependencias pueden tardar varios minutos en compilarse, en particular las PyArrow, que son una dependencia indirecta que usan Apache Beam y la mayoría de las bibliotecas cliente de Google Cloud.

Como solución alternativa, realiza los siguientes pasos:

  1. Descarga las dependencias compiladas previamente en el Dockerfile en el directorio de etapa de pruebas de Dataflow.

  2. Establece la variable de entorno PIP_NO_DEPS como True.

    La configuración evita que pip vuelva a descargar y vuelva a compilar todas las dependencias, lo que ayuda a evitar el error de tiempo de espera.

El siguiente es un ejemplo de código que muestra cómo las dependencias se descargan previamente.

# Copyright 2020 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

FROM gcr.io/dataflow-templates-base/python3-template-launcher-base

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/streaming_beam.py"

COPY . /template

# We could get rid of installing libffi-dev and git, or we could leave them.
RUN apt-get update \
    && apt-get install -y libffi-dev git \
    && rm -rf /var/lib/apt/lists/* \
    # Upgrade pip and install the requirements.
    && pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE \
    # Download the requirements to speed up launching the Dataflow job.
    && pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

# Since we already downloaded all the dependencies, there's no need to rebuild everything.
ENV PIP_NO_DEPS=True

Errores de envío de trabajos

413 Request Entity Too Large/The size of serialized JSON representation of the pipeline exceeds the allowable limit

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 la terminal o consola:

  • 413 Request Entity Too Large
  • “El tamaño de la representación serializada de 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 de JSON de la canalización. Una canalización mayor implica una solicitud mayor. Actualmente, Dataflow tiene 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

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< 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.
  • DoFn como una instancia de clase interna anónima que (posiblemente de forma involuntaria) incorpora gran cantidad de datos para serializarse.

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

The job graph is too large. Please try again with a smaller job graph, or split your job into two or more smaller jobs.

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.
  • DoFn como una instancia de clase interna anónima que (posiblemente de forma involuntaria) incorpora gran cantidad de datos para serializarse.

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

Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit o Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit.

Java

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 Rebalanceo dinámico del trabajo para seguir dividiendo entradas a pedido.

“Las opciones de canalización del SDK o la lista de archivos de etapa de pruebas superan el límite de tamaño. Mantén su longitud por debajo de los 256,000 bytes cada uno y de 512,000 bytes en total”.

No se pudo iniciar la canalización debido a que se superan los límites de metadatos de Google Compute Engine. Estos límites no se pueden cambiar. Dataflow usa metadatos de Compute Engine para las opciones de canalización. El límite se documenta en las limitaciones de metadatos personalizados de Compute Engine.

Si hay demasiados archivos jar para habilitar a etapa, la representación JSON puede superar el límite.

¿Cómo encontrar la opción de canalización completa y su longitud? Para estimar el tamaño de la solicitud JSON de tu canalización, ejecuta tu canalización con la siguiente opción:

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

El tamaño del archivo de salida anterior debe ser inferior a 256,000 bytes. 512,000 bytes en el mensaje de error se refiere al tamaño total del archivo de salida anterior y a las opciones de metadatos personalizados para la instancia de VM de Compute Engine. Se puede determinar una estimación aproximada de la opción de metadatos personalizados para la instancia de VM a partir de la ejecución de trabajos de Dataflow en el proyecto. Elige cualquier trabajo de Dataflow en ejecución, toma una instancia de VM y, luego, navega a la página de detalles de la instancia de VM de Compute Engine para esa VM a fin de verificar la sección de metadatos personalizados. La longitud total de los metadatos personalizados y el archivo anterior debe ser inferior a 512,000 bytes. No es posible obtener una estimación precisa para el trabajo con errores, ya que no se iniciaron las VM de este trabajo.

Si tu lista de archivos jar alcanza el límite de 256,000 bytes, revísala y reduce los archivos jar innecesarios. Si aún es demasiado grande, intenta ejecutar el trabajo de Dataflow mediante un uber jar.

La sección de Cloud Functions de la documentación tiene un ejemplo de cómo crear y usar el archivo uber jar.

Startup of the worker pool in zone $ZONE failed to bring up any of the desired $N workers. The project quota may have been exceeded or access control policies may be preventing the operation; review the Cloud Logging 'VM Instance' log for diagnostics.

Este error tiene dos causas posibles:

  • Es posible que hayas excedido una de las cuotas de Compute Engine en las que se basa la creación de trabajadores de Dataflow.
  • Tu organización tiene restricciones que prohíben algún aspecto del proceso de creación de instancias de VM, como la cuenta que se usa o la zona a la que se orienta.

Para solucionar este problema, haz lo siguiente:

Revisa el registro de instancias de VM

  1. Ve al visor de Cloud Logging
  2. En la lista desplegable Recurso auditado, selecciona Instancia de VM.
  3. En la lista desplegable Todos los registros, selecciona compute.googleapis.com/activity_log
  4. Analiza el registro en busca de entradas relacionadas con la falla de creación de la instancia de VM.

Verifica el uso de las cuotas de Compute Engine

  1. En la línea de comandos de tu máquina local o en Cloud Shell, ejecuta el siguiente comando para ver el uso de recursos de Compute Engine en comparación con las cuotas de Dataflow de la zona a la que orientas:

    gcloud compute regions describe [REGION]

  2. Revisa los resultados de los siguientes recursos para ver si alguno supera la cuota:

    • CPU
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • INSTANCE_GROUP_MANAGERS
    • INSTANCES
  3. Si es necesario, solicita un cambio de cuota.

Revisa las restricciones de la política de la organización

  1. Ir a la página Políticas de la organización
  2. Revisa las restricciones de cualquiera que pueda limitar la creación de instancias de VM para la cuenta que usas (esta es la cuenta de servicio de Dataflow de forma predeterminada) o en la zona a la que se orienta.

Registros de trabajador

“El procesamiento se atascó o la operación está en curso en el paso <step_id> durante al menos <time_interval> sin generar o completar el estado finalizado en <stack_trace>”

Si Dataflow dedica más tiempo a ejecutar una DoFn que el tiempo especificado en <time_interval> sin mostrar un resultado, se muestra este mensaje.

Este error tiene dos causas posibles:

  • Tu código DoFn es lento o espera que se complete una operación externa lenta.
  • O bien, es posible que tu código DoFn esté atascado, bloqueado o sea demasiado lento para terminar de procesarse.

Para determinar cuál es el caso, expande la entrada de registro de Cloud Monitoring a fin de ver un seguimiento de pila. Busca mensajes que indiquen que el código DoFn está bloqueado o que tiene problemas. Si no hay ninguno, el problema podría ser la velocidad de ejecución del código DoFn. Considera usar Cloud Profiler o alguna otra herramienta para investigar el rendimiento del código.

Puedes investigar más a fondo la causa de tu código atascado si la canalización está compilada en la VM de Java (mediante Java o Scala); realiza un volcado completo 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 Cloud 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 siguiente comando:

    curl http://localhost:8081/threadz
    

Excepciones del tipo “La clave Shuffle es demasiado grande”

Si encuentras excepciones que indican que la clave shuffle es demasiado grande, significa que la clave serializada emitida a un (Co-)GroupByKey en particular, después de aplicar el codificador correspondiente, es demasiado grande. Dataflow tiene un límite para las claves shuffle serializadas. Considera reducir el tamaño de las claves o usar codificadores que ahorren más espacio.

KeyCommitTooLargeException

En situaciones de transmisión, esto puede deberse a la agrupación de una gran cantidad de datos sin usar una transformación Combine o con la producción de una gran cantidad de datos a partir de un solo elemento de entrada. Las siguientes estrategias pueden reducir la posibilidad de generar esta excepción:

  • Asegúrate de que procesar un solo elemento no pueda dar lugar a que las salidas o las modificaciones de estado superen el límite.
  • Si se agruparon varios elementos por clave, considera aumentar el espacio de claves para reducir los elementos agrupados por clave.
  • Si los elementos de una clave se emiten a una frecuencia alta durante un período corto, es posible que muchos GB de eventos de esa clave se ejecuten en ventanas. Vuelve a escribir la canalización para detectar claves como esta y solo emite un resultado que indique que la clave estaba presente con frecuencia en esa ventana.
  • Asegúrate de usar transformaciones Combine de espacio sublineal para operaciones conmutativas y de asociación. No uses un combinador si no reduce el espacio. Por ejemplo, el combinador para strings que solo agrega strings es peor que no usar el combinador.

Excepciones de tiempo de espera de RPC, excepciones de 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

    • Si el trabajo no usa un objeto Shuffle basado en servicios, cambia para usar Dataflow Shuffle basado en servicios mediante la configuración de --experiments=shuffle_mode=service. Para obtener detalles y disponibilidad, lee Dataflow Shuffle.
    • 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

    • Si el trabajo no usa un objeto Shuffle basado en servicios, cambia para usar Dataflow Shuffle basado en servicios mediante la configuración de --experiments=shuffle_mode=service. Para obtener detalles y disponibilidad, lee Dataflow Shuffle.
    • 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.

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 de Cloud Monitoring y observa el mensaje de error y el traceback. Muestra qué código falló para que puedas corregirlo si es necesario. Si crees que se trata de un error en Apache Beam o Dataflow, infórmalo.

No queda espacio en el dispositivo

Cuando un trabajo se queda sin espacio en el disco, es posible que veas errores No space left on device en los registros del trabajador.

Si un trabajo descarga grandes dependencias durante el tiempo de ejecución, usa grandes contenedores personalizados o escribe muchos datos temporales en el disco local, el almacenamiento persistente del trabajador podría quedarse sin espacio libre.

Cuando se usa Dataflow Shuffle, Dataflow configura el tamaño de disco predeterminado más bajo. Como resultado, los trabajos que se mueven de la redistribución basada en el trabajador también pueden ver este error.

También es posible que el disco de arranque del trabajador se llene si registra más de 50 entradas por segundo.

Para ver los recursos del disco asociados con un solo trabajador, busca los detalles de las VM de trabajador asociados con tu trabajo. El sistema operativo, los objetos binarios, los registros y los contenedores consumirán parte del espacio en el disco.

Para aumentar el espacio del disco persistente o del disco de arranque, ajusta la opción de canalización del tamaño del disco.

Puedes realizar un seguimiento del uso del espacio en disco en las instancias de VM de trabajador mediante Cloud Monitoring. Consulta Recibe métricas de VM de trabajador del agente de Monitoring para obtener instrucciones sobre cómo configurar esto.

También puedes buscar problemas de espacio en el disco de arranque si ves la salida del puerto en serie en las instancias de VM de trabajador y buscas mensajes como “No se pudo abrir el diario del sistema: No queda espacio en el dispositivo”. Si tienes una gran cantidad de instancias de VM de trabajador, recomendamos crear una secuencia de comandos para ejecutar gcloud compute instances get-serial-port-output en todas ellas de una vez y, en su lugar, revisar esa salida.

Para obtener más información, consulta los precios de los discos persistentes.

EOFError: datos marshal demasiado cortos

Este error a veces se produce cuando los trabajadores de la canalización de Python se quedan sin espacio en el disco. Consulta No queda espacio en el dispositivo.

Advertencias Bad request en registros del shuffler

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

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á sincronizada debido a retrasos de procesamiento. A menudo, tu trabajo de Dataflow tendrá éxito a pesar de estas advertencias de “solicitud incorrecta”. Si ese es el caso, ignora las advertencias.

Se detectó una clave de acceso rápido <hot-key-name> en…

Estos errores identifican una clave de acceso rápido en tus datos. 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 Dataflow de procesar elementos en paralelo, lo que aumenta el tiempo de ejecución.

Para registrar la presencia de una clave de acceso rápido, usa la opción de canalización de clave de acceso rápido.

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

La canalización del contenedor personalizado de Python falla con SystemError: código de operación desconocido

Si experimentas un error inesperado en Python SystemError: unknown opcode inmediatamente después del envío de trabajos y el seguimiento de pila incluye apache_beam/internal/pickler.py, verifica que la versión de Python que usas de forma local coincida con la versión de la imagen de contenedor en la versión principal y secundaria. La diferencia en la versión del parche, como 3.6.7 en comparación con 3.6.8, no crea problemas de compatibilidad, pero la diferencia en la versión secundaria, como 3.6.8 y 3.8.2, puede causar fallas en la canalización.

Errores de entrada y salida

Los gráficos de métricas de E/S usan códigos de error canónicos. Si estos códigos de error persisten en las fuentes y receptores, consulta la siguiente lista para conocer las posibles causas y las acciones que puedes realizar.

  • RESOURCE_EXHAUSTED. Es posible que se haya agotado la cuota de recursos del proyecto para el servicio que usa la fuente o el receptor.

    Si el error se produce ocasionalmente o cuando el gráfico de solicitudes por segundo indica que se realiza una gran cantidad de solicitudes, puede indicar que alcanzaste una cuota de límite de frecuencia de API y necesitas para aumentar la cuota.

  • DEADLINE_EXCEEDED. Es posible que la fuente o el receptor haya agotado el tiempo de espera de la lectura o escritura de un gran lote de datos. Verifica el gráfico de latencia y los registros de trabajadores. Si el error persiste, comunícate con el equipo de asistencia.

  • INVALID_ARGUMENT. Los parámetros especificados para la fuente o el receptor pueden tener un formato incorrecto (como un tema de Pub/Sub). Verifica la configuración de la fuente o del receptor y revisa los registros del trabajador.

  • FAILED_PRECONDITION. Verifica la configuración de la fuente o del receptor y revisa los registros del trabajador. Esto también podría indicar un error.

  • OUT_OF_RANGE. Comprueba que el recurso que usa la fuente o el receptor exista (como un tema o una suscripción de Pub/Sub).

  • UNAUTHENTICATED. Verifica que la cuenta de servicio de Dataflow tenga permisos de administración de identidades y accesos para el servicio específico y que las API relevantes estén habilitadas para el proyecto.

  • PERMISSION_DENIED. Verifica que la cuenta de servicio de Dataflow tenga permisos de administración de identidades y accesos para el servicio específico y que las API relevantes estén habilitadas para el proyecto.

  • NOT_FOUND. Verifica que existan las entidades que usan la fuente o el receptor (como un tema o una suscripción de Pub/Sub).

  • ABORTED. Es posible que el servicio no esté manejando de forma adecuada los intentos del receptor y la fuente de leer o escribir datos. Si el error persiste, comunícate con el equipo de asistencia.

  • ALREADY_EXISTS. La E/S podría estar intentando crear una entidad que ya existe (como una suscripción o un tema de Pub/Sub). Si el error persiste, comunícate con el equipo de asistencia.

  • CANCELLED. Esto puede ocurrir cuando un trabajador de Dataflow se cierra, o la lógica de la fuente o del receptor decide cancelar los intentos de leer o escribir datos.

  • DATALOSS. Indica que se produjo una pérdida o daño irrecuperable de datos. Te recomendamos crear un conjunto de datos nuevo para tus fuentes y volver a ejecutar el trabajo de Dataflow.

    También puedes ver si hay instrucciones de copia de seguridad y restablecimiento disponibles para el servicio subyacente de Google Cloud.

  • UNKNOWN. Es posible que el servicio no esté disponible. Consulta las actualizaciones en el Panel de estado de Cloud para obtener más información.

  • INTERNAL. Es posible que el servicio no esté disponible. Consulta las actualizaciones en el Panel de estado de Cloud para obtener más información.

  • UNAVAILABLE. Es posible que el servicio no esté disponible. Consulta las actualizaciones en el Panel de estado de Cloud para obtener más información.

  • UNIMPLEMENTED. La fuente o el receptor intentaron usar el servicio de manera no válida. Es posible que tu canalización esté mal configurada. Si el error persiste, comunícate con el equipo de asistencia.

Errores de inicio de trabajador

Los errores en los tipos de registros dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup y dataflow.googleapis.com/kubelet indican problemas de configuración con un trabajo. También pueden indicar condiciones que evitan que la ruta de registro normal funcione.

Errores NoClassDefFound

Estos errores también pueden tener el formato Unable to initialize main class [...]. Los errores NoClassDefFound indican que los archivos JAR que se suben al servicio de Dataflow no contienen las clases necesarias para ejecutar Dataflow. Esto sucede con mayor frecuencia cuando se anula el --filesToStage PipelineOption y se omiten algunos archivos JAR o de clase obligatorios.

Se produjo un error en la imagen solicitud de extracción

Este error indica que un trabajador no pudo iniciarse porque el trabajador no pudo extraer una imagen de contenedor de Docker. Esto puede suceder si la URL de la imagen del contenedor personalizada del SDK es incorrecta o si el trabajador no tiene credenciales o acceso de red a la imagen remota.

Si usas una imagen de contenedor personalizada con tu trabajo, verifica que la URL de tu imagen sea correcta, tenga una etiqueta o resumen válidos, y que los trabajadores de Dataflow puedan acceder a la imagen.

Verifica que las imágenes públicas se puedan extraer de forma local mediante la ejecución de docker pull $image desde una máquina no autenticada.

Hay consideraciones adicionales para las imágenes privadas o los trabajadores privados.

  • Dataflow solo admite imágenes de contenedor privadas alojadas en Container Registry. Si usas Container Registry para alojar la imagen de contenedor, la cuenta de servicio predeterminada de Google Cloud tiene acceso a las imágenes en el mismo proyecto. Si usas imágenes en un proyecto diferente al que se usó para ejecutar tu trabajo de Google Cloud, asegúrate de configurar el control de acceso para la cuenta de servicio predeterminada de Google Cloud.
  • Si usas una nube privada virtual (VPC) compartida, asegúrate de que los trabajadores puedan acceder al host del repositorio de contenedores personalizado.
  • Usa ssh para conectarte con una VM de trabajador de un trabajo en ejecución y ejecuta docker pull $image a fin de confirmar directamente que el trabajador está configurado de forma correcta.

Si los trabajadores fallan varias veces seguidas debido a este error y no se inició ningún trabajo en un trabajo, puede fallar con un error como Job appears to be stuck. .... Si quitaste el acceso a la imagen mientras se está ejecutando el trabajo, ya sea quitando la imagen en sí o revocando las credenciales de la cuenta de servicio de trabajador de Dataflow o acceso a Internet para acceder a las imágenes, Dataflow solo registrará errores y no realizar acciones para fallar el trabajo. Dataflow también evita las fallas de las canalizaciones de transmisión de larga duración para evitar la pérdida del estado de la canalización.

Pueden surgir otros errores posibles debido a problemas o interrupciones de la cuota del repositorio. Si tienes problemas que superan la cuota de Docker Hub para extraer imágenes públicas o interrupciones generales del repositorio de terceros, considera usar Container Registry como la repositorio de imágenes.

No se pudo sincronizar el pod… no se pudo “StartContainer”.

Este error indica que no se pudo iniciar el contenedor de Docker de trabajador. Esto suele suceder cuando uno de los contenedores falla de forma continua durante el inicio.

Si el contenedor falla, busca un mensaje de error que describa la falla en los registros de trabajador-inicio, aprovechamiento-inicio o Docker. Una falla de inicio común para los trabajos de Python son errores de instalación pip (pip install failed with error...) debido a problemas de dependencia. Esto puede incluir dependencias o problemas de red especificados incompatibles que hacen que no se pueda acceder a los repositorios especificados. El SDK de Apache Beam para Python instalado en el contenedor debe ser el mismo que el SDK que se usa para iniciar el trabajo.

Este error también puede ocurrir si la imagen del contenedor no se puede extraer durante un trabajo de larga duración. Para obtener más detalles, consulta “se produjo un error en la imagen solicitud de extracción”.

“Java Runtime Environment detectó un error irrecuperable”.

Esto indica que la canalización usa la interfaz nativa de Java (JNI) para ejecutar código que no es de Java y que hay un error en ese código o en las vinculaciones de JNI.

Registros

No veo ningún registro

Si no ves ningún registro para tus trabajos, quita los filtros de exclusión que contengan resource.type="dataflow_step" de todos tus receptores del enrutador de registros de Cloud Logging.

Ir a Enrutador de registros

Para obtener más detalles sobre cómo quitar las exclusiones de registros, consulta la guía Quita exclusiones.

Recomendaciones

Uso alto de la cuota de transferencia de Streaming Engine

Los trabajos que usan Streaming Engine tienen un límite regional en cuanto a la cantidad de datos que se pueden transferir desde y hacia Streaming Engine. Es importante mantenerse por debajo del límite, ya que puede afectar el rendimiento del trabajo. Además, reducir la cantidad de bytes transferidos puede reducir el costo facturado.

Para ver el límite de tu proyecto, consulta las instrucciones en Cuotas y límites. Para ver el uso actual de tus trabajos, sigue este vínculo al Explorador de métricas. Si es necesario, selecciona el proyecto en el que se ejecuta tu trabajo. Luego, reemplaza REGION por la región que te interesa y haz clic en “Ejecutar consulta”.

Sugerencias para reducir el uso:

  • Reduce la cantidad de datos procesados mediante transformaciones GroupByKey y Combine. Esto se puede hacer si se reduce la cantidad de elementos que se pasan o se omiten campos innecesarios.
  • Codifica los datos de manera más eficiente para ocupar menos espacio. En algunos casos, esto puede aumentar el uso de CPU en el trabajador.

    • Para los tipos de datos personalizados, el codificador predeterminado puede ser ineficiente (SerializableCoder en Java, PickleCoder en Python). Intenta seleccionar un codificador predeterminado más eficiente para el tipo personalizado o una PCollection con un esquema.

      Para obtener una explicación más detallada sobre los codificadores y cómo especificarlos, consulta el capítulo de la Guía de programación de Beam sobre la codificación de datos. Para obtener más información sobre PCollections con esquemas, consulta el capítulo sobre esquemas.

    • Para elementos grandes, puede ser útil aplicar compresión.

  • Reduce las lecturas de estados grandes. Por ejemplo, una canalización que tenga un BagState lo suficientemente grande deberá transferirlo de Streaming Engine cada vez que se recupere.

    • Intenta reducir el tamaño del estado.
    • Intenta reducir la frecuencia de las recuperaciones de estado.
    • El estado está vinculado a una clave y ventana específicas. Se puede usar un sistema de ventanas no global para limitar el tamaño del estado.

    Para obtener más información sobre el estado, consulta el capítulo de la Guía de programación de Beam sobre el estado y los temporizadores.

Ajuste de escala automático: Se puede aumentar maxNumWorkers

Dataflow detectó que un trabajo usa la cantidad máxima de trabajadores permitidos, maxNumWorkers (o max_num_workers), y que puede usar más trabajadores si se aumentó este máximo. Por ejemplo, esta recomendación se daría para un trabajo que tiene maxNumWorkers configurado en 50 y que usa 50 trabajadores con un uso de CPU de trabajador promedio superior al 80%.

Por lo general, aumentar la maxNumWorkers aumenta la capacidad de procesamiento de la canalización: una canalización por lotes podría completarse en menos tiempo y una canalización de transmisión podría manejar grandes aumentos en los datos y procesar más elementos por segundo. Sin embargo, esto puede tener un costo mayor (consulta Precios de recursos de trabajadores). Consulta la guía de ajuste de escala automático para obtener detalles sobre cómo funciona el algoritmo de ajuste de escala automático y cómo configurarlo.

Sugerencias:

  • Intenta aumentar la opción de canalización maxNumWorkers o quitarla. Sin la opción, Dataflow usará los valores predeterminados que aparecen en la guía de ajuste de escala automático.
  • No hay problema si no se hace nada si el rendimiento de la canalización es adecuado.
    • Para las canalizaciones por lotes, verifica que el tiempo de ejecución total cumpla con tus requisitos.
    • Para las canalizaciones de transmisión, consulta el grafo de actualidad de datos en la pestaña Métricas de trabajos en la página de trabajos. Asegúrate de que no aumente de forma continua y de que los valores estén dentro de los límites aceptables.

Se detectó un fan-out alto

Dataflow detectó que un trabajo tiene una o más transformaciones con una “fan-out alta”. Esto ocurre cuando un ParDo que tiene una alta proporción de recuento de salida y entrada se fusiona con un ParDo posterior. En esta situación, el segundo ParDo se ejecuta de forma secuencial con el primero. Esto fuerza todos los elementos de salida de una entrada determinada al mismo trabajador, lo que reduce el paralelismo y ralentiza el rendimiento.

Sugerencias:

  • Inserta un GroupByKey y desagrupa después de tu primer ParDo. El servicio de Dataflow nunca fusiona las operaciones en una agregación.
  • Pasa la PCollection intermedia como una entrada complementaria a otro ParDo. El servicio de Dataflow siempre materializa las entradas complementarias.
  • Inserta un paso de redistribución. La redistribución evita la fusión, controla los datos y vuelve a configurar la estrategia del sistema de ventanas para que no se descarten los datos. Dataflow admite que se vuelva a reproducir de forma aleatoria, aunque está marcada como obsoleta en la documentación de Apache Beam (ten en cuenta que la reorganización de datos puede aumentar el costo de ejecución de la canalización).