Apache Beam y TFX

Apache Beam proporciona un marco para ejecutar trabajos de procesamiento de datos por lotes y en streaming que se ejecutan en una variedad de motores de ejecución. Varias de las bibliotecas TFX utilizan Beam para ejecutar tareas, lo que permite un alto grado de escalabilidad entre clústeres informáticos. Beam incluye soporte para una variedad de motores de ejecución o "ejecutores", incluido un ejecutor directo que se ejecuta en un único nodo informático y es muy útil para desarrollo, pruebas o implementaciones pequeñas. Beam proporciona una capa de abstracción que permite que TFX se ejecute en cualquier ejecutor compatible sin modificaciones de código. TFX utiliza la API Beam Python, por lo que está limitado a los ejecutores admitidos por la API Python.

Implementación y escalabilidad

A medida que aumentan los requisitos de carga de trabajo, Beam puede escalar a implementaciones muy grandes en grandes clústeres informáticos. Esto está limitado únicamente por la escalabilidad del corredor subyacente. Los ejecutores en implementaciones grandes generalmente se implementarán en un sistema de orquestación de contenedores como Kubernetes o Apache Mesos para automatizar la implementación, el escalado y la administración de aplicaciones.

Consulte la documentación de Apache Beam para obtener más información sobre Apache Beam.

Para los usuarios de Google Cloud, Dataflow es el ejecutor recomendado, que proporciona una plataforma sin servidor y rentable a través del escalado automático de recursos, reequilibrio dinámico del trabajo, integración profunda con otros servicios de Google Cloud, seguridad integrada y monitoreo.

Código Python personalizado y dependencias

Una complejidad notable del uso de Beam en una canalización TFX es el manejo de código personalizado y/o las dependencias necesarias de módulos adicionales de Python. A continuación se muestran algunos ejemplos de cuándo esto podría ser un problema:

  • preprocessing_fn necesita hacer referencia al módulo Python del propio usuario
  • un extractor personalizado para el componente Evaluador
  • módulos personalizados que están subclasificados a partir de un componente TFX

TFX confía en el soporte de Beam para administrar las dependencias de canalización de Python para manejar las dependencias de Python. Actualmente hay dos formas de gestionar esto:

  1. Proporcionar código Python y dependencias como paquete fuente
  2. [Solo flujo de datos] Uso de una imagen de contenedor como trabajador

Estos se analizan a continuación.

Proporcionar código Python y dependencias como paquete fuente

Esto se recomienda para usuarios que:

  1. Están familiarizados con el empaquetado de Python y
  2. Utilice únicamente el código fuente de Python (es decir, no utilice módulos C ni bibliotecas compartidas).

Siga una de las rutas en Gestión de dependencias de canalización de Python para proporcionar esto utilizando uno de los siguientes beam_pipeline_args:

  • --archivo_setup
  • --paquete_extra
  • --requirements_file

Aviso: en cualquiera de los casos anteriores, asegúrese de que la misma versión de tfx aparezca como dependencia.

[Solo flujo de datos] Uso de una imagen de contenedor para un trabajador

TFX 0.26.0 y versiones posteriores tienen soporte experimental para el uso de imágenes de contenedor personalizadas para trabajadores de Dataflow.

Para poder utilizar esto, tienes que:

  • Cree una imagen de Docker que tenga tfx y el código personalizado y las dependencias de los usuarios preinstalados.
    • Para los usuarios que (1) usan tfx>=0.26 y (2) usan python 3.7 para desarrollar sus canalizaciones, la forma más sencilla de hacerlo es extender la versión correspondiente de la imagen oficial tensorflow/tfx :
# You can use a build-arg to dynamically pass in the
# version of TFX being used to your Dockerfile.

ARG TFX_VERSION
FROM tensorflow/tfx:${TFX_VERSION}
# COPY your code and dependencies in
  • Inserte la imagen creada en un registro de imágenes contenedor al que puede acceder el proyecto utilizado por Dataflow.
    • Los usuarios de Google Cloud pueden considerar el uso de Cloud Build , que automatiza muy bien los pasos anteriores.
  • Proporcione los siguientes beam_pipeline_args :
beam_pipeline_args.extend([
    '--runner=DataflowRunner',
    '--project={project-id}',
    '--worker_harness_container_image={image-ref}',
    '--experiments=use_runner_v2',
])

TODO(b/171733562): elimine use_runner_v2 una vez que sea el predeterminado para Dataflow.

TODO(b/179738639): cree documentación sobre cómo probar un contenedor personalizado localmente después de https://issues.apache.org/jira/browse/BEAM-5440

Argumentos sobre la tubería de haz

Varios componentes de TFX dependen de Beam para el procesamiento de datos distribuidos. Se configuran con beam_pipeline_args , que se especifica durante la creación de la canalización:

my_pipeline = Pipeline(
    ...,
    beam_pipeline_args=[...])

TFX 0.30 y superiores agregan una interfaz, with_beam_pipeline_args , para extender los argumentos de viga a nivel de tubería por componente:

example_gen = CsvExampleGen(input_base=data_root).with_beam_pipeline_args([...])