Usar Dataflow Runner v2

Cuando usas Dataflow para ejecutar tu flujo de procesamiento, el runner de Dataflow sube el código y las dependencias de tu flujo de procesamiento a un segmento de Cloud Storage y crea un trabajo de Dataflow. Este trabajo de Dataflow ejecuta tu canalización en recursos gestionados de Google Cloud Platform.

• En el caso de las canalizaciones por lotes que usan las versiones 2.54.0 o posteriores del SDK de Apache Beam para Java, Runner v2 está habilitado de forma predeterminada.
• En el caso de las canalizaciones que usan el SDK de Apache Beam para Java, se requiere Runner v2 al ejecutar canalizaciones multilingüe, usar contenedores personalizados o usar canalizaciones de flujo de cambios de Spanner o Bigtable. En otros casos, usa el runner predeterminado.
• En las canalizaciones que usan las versiones 2.21.0 o posteriores del SDK de Apache Beam para Python, Runner v2 está habilitado de forma predeterminada. En el caso de las canalizaciones que usan las versiones 2.45.0 y posteriores del SDK de Apache Beam para Python, Dataflow Runner v2 es el único ejecutor de Dataflow disponible.
• En el caso del SDK de Apache Beam para Go, Dataflow Runner v2 es el único ejecutor de Dataflow disponible.

Runner v2 usa una arquitectura basada en servicios que beneficia a algunas canalizaciones:

• Dataflow Runner v2 te permite precompilar tu contenedor de Python, lo que puede mejorar los tiempos de inicio de las VMs y el rendimiento del autoescalado horizontal. Para obtener más información, consulta Precompilar dependencias de Python.

• Dataflow Runner v2 admite flujos de procesamiento multilingüe, una función que permite que tu flujo de procesamiento de Apache Beam use transformaciones definidas en otros SDKs de Apache Beam. Dataflow Runner v2 admite transformaciones de Java desde un flujo de procesamiento del SDK de Python y transformaciones de Python desde un flujo de procesamiento del SDK de Java. Cuando ejecutas las canalizaciones de Apache Beam sin Runner v2, el runner de Dataflow usa trabajadores específicos de cada lenguaje.

Limitaciones y restricciones

Dataflow Runner v2 tiene los siguientes requisitos:

• Dataflow Runner v2 requiere Streaming Engine para las tareas de streaming.
• Como Dataflow Runner v2 requiere Streaming Engine para las tareas de streaming, cualquier transformación de Apache Beam que requiera Dataflow Runner v2 también requiere el uso de Streaming Engine para las tareas de streaming. Por ejemplo, el conector de E/S de Pub/Sub Lite para el SDK de Apache Beam para Python es una transformación entre lenguajes que requiere Dataflow Runner v2. Si intentas inhabilitar Streaming Engine en una tarea o una plantilla que utilice esta transformación, la tarea fallará.
• En las canalizaciones de streaming que usan el SDK de Apache Beam para Java, las clases MapState y SetState no se admiten en Runner v2. Para usar las clases MapState y SetState con las canalizaciones de Java, habilita Streaming Engine, inhabilita Runner v2 y usa la versión 2.58.0 o una posterior del SDK de Apache Beam.
• En los flujos de procesamiento por lotes y de streaming que usan el SDK de Apache Beam para Java, no se admite la clase AfterSynchronizedProcessingTime.
• Las plantillas clásicas de Dataflow no se pueden ejecutar con una versión del ejecutor de Dataflow diferente a la que se usó para crearlas. Esto significa que las plantillas clásicas proporcionadas por Google no pueden habilitar Runner v2. Para habilitar Runner v2 en las plantillas personalizadas, define la marca --experiments=use_runner_v2 al crear la plantilla.
• Debido a un problema conocido de autoescalado, Runner v2 está inhabilitado de forma predeterminada en las canalizaciones de Java por lotes que requieren procesamiento con estado. Puedes seguir habilitando Runner v2 para esas canalizaciones (consulta Habilitar Runner v2), pero el rendimiento de la canalización puede verse muy limitado.

Habilitar Runner v2

Para habilitar Dataflow Runner v2, sigue las instrucciones de configuración de tu SDK de Apache Beam.

Inhabilitar Runner v2

Para inhabilitar Dataflow Runner v2, sigue las instrucciones de configuración de tu SDK de Apache Beam.

Supervisar tu tarea

Usa la interfaz de monitorización para ver las métricas de las tareas de Dataflow, como el uso de la memoria y de la CPU, entre otras.

Los registros de las VMs de trabajador están disponibles a través del Explorador de registros y de la interfaz de monitorización de Dataflow. Los registros de las VMs de trabajo incluyen registros del proceso del arnés del ejecutor y registros de los procesos del SDK. Puedes usar los registros de la VM para solucionar problemas con tu trabajo.

Solucionar problemas de Runner v2

Para solucionar problemas con los trabajos que usan Dataflow Runner v2, sigue los pasos estándar para solucionar problemas con las canalizaciones. En la siguiente lista se proporciona información adicional sobre cómo funciona Dataflow Runner v2:

• Las tareas de Dataflow Runner v2 ejecutan dos tipos de procesos en la VM de trabajador: el proceso del SDK y el proceso del arnés del runner. En función de la canalización y del tipo de VM, puede haber uno o varios procesos del SDK, pero solo hay un proceso de contenedor de ejecución por VM.
• Los procesos del SDK ejecutan código de usuario y otras funciones específicas de cada lenguaje. El proceso del contenedor de pruebas se encarga de todo lo demás.
• El proceso de contenedor de ejecución espera a que todos los procesos del SDK se conecten a él antes de empezar a solicitar trabajo a Dataflow.
• Los trabajos pueden retrasarse si la VM de trabajador descarga e instala dependencias durante el inicio del proceso del SDK. Si se producen problemas durante un proceso del SDK, como al iniciar o instalar bibliotecas, el trabajador informa de que su estado es incorrecto. Si los tiempos de inicio aumentan, habilita la API de Cloud Build en tu proyecto y envía tu canal con el siguiente parámetro: --prebuild_sdk_container_engine=cloud_build.
• Como Dataflow Runner v2 usa el almacenamiento de puntos de control, cada trabajador puede esperar hasta cinco segundos mientras almacena en búfer los cambios antes de enviarlos para que se procesen. Por lo tanto, se espera una latencia de aproximadamente seis segundos.

• Para diagnosticar problemas en el código de usuario, examina los registros de los procesos del SDK. Si encuentras algún error en los registros de la herramienta de pruebas, ponte en contacto con el equipo de Asistencia para informar de un error.
• Para depurar errores habituales relacionados con las canalizaciones multilingüe de Dataflow, consulta la guía Consejos para canalizaciones multilingüe.