Usa el ejecutor portátil de Dataflow

Cuando usas Dataflow para ejecutar la canalización, su ejecutor sube el código y las dependencias de la canalización a un bucket de Cloud Storage y crea un trabajo de Dataflow. Este trabajo de Dataflow ejecuta la canalización en recursos administrados enGoogle Cloud.

  • Para las canalizaciones por lotes que usan las versiones 2.54.0 o posteriores del SDK de Apache Beam para Java, el Runner portátil está habilitado de forma predeterminada.
  • Para las canalizaciones que usan el SDK de Java de Apache Beam, se requiere el Runner portátil cuando se ejecutan canalizaciones de varios lenguajes, cuando se usan contenedores personalizados o cuando se usan canalizaciones de flujo de cambios de Spanner o Bigtable. Para las canalizaciones de transmisión de Java a gran escala, usa el ejecutor de Java de transmisión (predeterminado).
  • Para las canalizaciones que usan las versiones 2.21.0 o posteriores del SDK de Apache Beam para Python, el Runner portátil está habilitado de forma predeterminada. Para las canalizaciones que usan las versiones 2.45.0 y posteriores del SDK de Apache Beam para Python, el ejecutor portátil de Dataflow es el único ejecutor de Dataflow disponible.
  • En el SDK de Apache Beam para Go, el ejecutor portátil es el único ejecutor de Dataflow disponible.

El Runner portátil usa una arquitectura basada en servicios que beneficia a muchas canalizaciones:

Limitaciones y restricciones

El Dataflow Portable Runner tiene los siguientes requisitos y limitaciones:

  • Funciones solo para el ejecutor portátil: Las siguientes funciones solo son compatibles con el ejecutor portátil:
    • Transformaciones administradas y RunInference en Java.
    • Contenedores personalizados
    • VMs de trabajador basadas en ARM.
    • Splittable DoFns. Se está explorando la compatibilidad con el ejecutor Non-Portable.
  • El Dataflow Portable Runner requiere Streaming Engine para los trabajos de transmisión.
  • Debido a que Dataflow Portable Runner requiere Streaming Engine para los trabajos de transmisión, cualquier transformación de Apache Beam que requiera Dataflow Portable Runner también requiere el uso de Streaming Engine para los trabajos de transmisión. Por ejemplo, el conector de E/S de Pub/Sub Lite para el SDK de Apache Beam para Python es una transformación de varios lenguajes que requiere el ejecutor portátil de Dataflow. Si intentas inhabilitar Streaming Engine para un trabajo o una plantilla que usa esta transformación, el trabajo fallará.
  • En las canalizaciones de transmisión que usan el SDK de Java de Apache Beam, no se admiten las clases MapState y SetState con el Runner portátil. Para usar las clases MapState y SetState con canalizaciones de Java, habilita Streaming Engine, inhabilita Portable Runner y usa la versión 2.58.0 o posterior del SDK de Apache Beam.
  • En las canalizaciones por lotes y de transmisión que usan el SDK de Java de Apache Beam, no se admite la clase AfterSynchronizedProcessingTime.
  • Si bien el ejecutor portátil se adapta mejor que el ejecutor no portátil en muchos casos, el uso de memoria podría ser mayor para el sharding fijo.
  • Las plantillas clásicas de Dataflow no se pueden ejecutar con una versión del ejecutor de Dataflow diferente de la que se usó para compilarlas. Esto significa que las plantillas clásicas proporcionadas por Google no pueden habilitar el ejecutor portátil. Para habilitar el ejecutor portátil para plantillas personalizadas, configura la marca adecuada cuando compiles la plantilla. Esta marca depende de la versión del SDK que uses:
    • Versiones 2.74 y posteriores del SDK de Beam: --experiments=enable_portable_runner.
    • Versiones 2.73 y anteriores del SDK de Beam: --experiments=use_runner_v2.

  • Debido a un problema conocido de ajuste de escala automático, el ejecutor portátil está inhabilitado de forma predeterminada para las canalizaciones de Java por lotes que requieren un procesamiento con estado. Aun así, puedes habilitar el ejecutor portátil para esas canalizaciones (consulta Habilita el ejecutor portátil), pero es posible que el rendimiento de la canalización se vea gravemente afectado.

  • En algunas canalizaciones, el ejecutor portátil puede aumentar la frecuencia de las fallas de coherencia. Es posible que veas el siguiente error en los archivos de registro: "Internal consistency check failed, the output is likely incorrect. Vuelve a intentarlo". Una posible mitigación es agregar una transformación Reshuffle después del paso Join/GrouByKey. Si la tasa de fallas no es tolerable y la mitigación no resuelve el problema, intenta inhabilitar el ejecutor portátil.

Habilita el ejecutor portátil

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

Java

Dataflow Portable Runner requiere las versiones 2.30.0 o posteriores del SDK de Apache Beam para Java, aunque se recomienda usar la versión 2.44.0 o una posterior.

Para las canalizaciones por lotes que usan las versiones 2.54.0 o posteriores del SDK de Apache Beam para Java, el Runner portátil está habilitado de forma predeterminada.

Para habilitar el ejecutor portátil, ejecuta tu trabajo con el valor del experimento que corresponde a la versión del SDK de Beam y al tipo de canalización:

  • Versiones 2.74 y posteriores del SDK de Beam: enable_portable_runner (por lotes) o enable_streaming_java_runner (transmisión).
  • Versiones 2.73 y anteriores del SDK de Beam: use_runner_v2.

Para obtener más información, consulta Configura las opciones de canalización experimental.

Python

Para las canalizaciones que usan las versiones 2.21.0 o posteriores del SDK de Apache Beam para Python, el Runner portátil está habilitado de forma predeterminada.

El ejecutor portátil de Dataflow no es compatible con las versiones 2.20.0 y anteriores del SDK de Apache Beam para Python.

En algunos casos, tu canalización podría no usar el Runner portátil, incluso si la canalización se ejecuta en una versión del SDK compatible. Para ejecutar el trabajo con el Portable Runner, establece el valor del experimento que corresponde a tu versión del SDK de Beam:

  • Versiones 2.74 y posteriores del SDK de Beam: enable_portable_runner.
  • Versiones 2.73 y anteriores del SDK de Beam: use_runner_v2.

Para obtener más información, consulta Configura las opciones de canalización experimental.

Go

Dataflow Portable Runner es el único ejecutor de Dataflow disponible para el SDK de Apache Beam en Go. Portable Runner está habilitado de forma predeterminada.

Inhabilita el dispositivo Portable Runner

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

Java

Para inhabilitar Portable Runner, establece el valor del experimento que corresponde a tu versión del SDK de Beam:

  • Versiones 2.74 y posteriores del SDK de Beam: disable_portable_runner.
  • Versiones 2.73 y anteriores del SDK de Beam: disable_runner_v2.

De forma predeterminada, el trabajo se ejecutará con el ejecutor no portátil (ejecutor de Java de transmisión para la transmisión). Para obtener más información, consulta Configura las opciones de canalización experimental.

Python

Inhabilitar el ejecutor portátil no es compatible con las versiones 2.45.0 y posteriores del SDK de Apache Beam para Python.

Para versiones anteriores del SDK de Python, si se identifica que tu trabajo usa el experimento auto_runner_v2, puedes inhabilitar el Runner portátil configurando el experimento disable_runner_v2. Para obtener más información, consulta Configura las opciones de canalización experimental.

Go

El ejecutor portátil de Dataflow no se puede inhabilitar en Go. El ejecutor portátil es el único ejecutor de Dataflow disponible para el SDK de Apache Beam en Go.

Supervisa tu trabajo

Usa la interfaz de supervisión para ver las métricas de los trabajos de Dataflow, como el uso de memoria, el uso de CPU y mucho más.

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

Soluciona problemas del Portable Runner

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

  • Los trabajos que usan el ejecutor portátil de Dataflow ejecutan dos tipos de procesos en la VM de trabajador: el proceso del SDK y el proceso de aprovechamiento del ejecutor. Puede haber uno o más procesos del SDK, según la canalización y el tipo de VM, pero solo hay un proceso de aprovechamiento del ejecutor por VM.
  • Los procesos del SDK ejecutan el código de usuario y otras funciones específicas del lenguaje, mientras que el proceso de aprovechamiento del ejecutor administra todo lo demás.
  • El proceso de aprovechamiento del ejecutor espera a que todos los procesos del SDK se conecten a él antes de comenzar a solicitar trabajo de Dataflow.
  • Es posible que los trabajos se retrasen si la VM de trabajador instala y descarga dependencias durante el inicio del proceso del SDK. Si se producen problemas durante un proceso del SDK, como cuando se inician o instalan bibliotecas, el trabajador informa que está en mal estado. Si aumentan los tiempos de inicio, habilita la API de Cloud Build en tu proyecto y envía tu canalización con el siguiente parámetro: --prebuild_sdk_container_engine=cloud_build.
  • Debido a que Dataflow Portable Runner usa puntos de control, cada trabajador puede esperar hasta cinco segundos mientras almacena los cambios en búfer antes de enviar los cambios para su procesamiento posterior. Como resultado, se espera una latencia de aproximadamente seis segundos.