Sintonizar con las primeras mujeres en ML Simposio este martes, 19 de octubre a 09 a.m. PST Registrar ahora

Apache Beam y TFX

Apache Beam proporciona un marco para el funcionamiento de lote y la transmisión de los datos de proceso que se ejecutan en una variedad de motores de ejecución. Varias de las bibliotecas TFX usan Beam para ejecutar tareas, lo que permite un alto grado de escalabilidad entre clústeres de cómputo. Beam incluye soporte para una variedad de motores de ejecución o "ejecutores", incluido un ejecutor directo que se ejecuta en un solo nodo de cómputo 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 corredor compatible sin modificaciones de código. TFX usa la API Beam Python, por lo que está limitado a los corredores que son compatibles con 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 de cómputo. Esto está limitado solo por la escalabilidad del corredor subyacente. Los corredores 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.

Ver el Apache haz documentación para obtener más información sobre Apache Beam.

Para los usuarios de Google Cloud, flujo de datos es el corredor recomendada, que proporciona una plataforma sin servidor y rentable a través de escala automática de los recursos, el reequilibrio de trabajo dinámico, una profunda integración con otros servicios de Google Cloud, una función de seguridad y monitoreo.

Dependencias y código Python personalizado

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 Python adicionales. A continuación, se muestran algunos ejemplos de situaciones en las que esto podría suponer un problema:

  • preprocessing_fn necesita hacer referencia al módulo Python del usuario
  • un extractor personalizado para el componente Evaluador
  • módulos personalizados que se subclasifican de un componente TFX

TFX basa en el apoyo de la viga para la Gestión de Python Pipeline Dependencias para manejar dependencias Python. Actualmente hay dos formas de gestionar esto:

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

Estos se discuten 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 código fuente de Python (es decir, sin módulos C ni bibliotecas compartidas).

Por favor, siga uno de los caminos en la gestión de Python Pipeline dependencias para proporcionar esta usando uno de los siguientes beam_pipeline_args:

  • --setup_file
  • --extra_package
  • --requirements_file

Aviso: En cualquiera de los casos anteriores, por favor asegúrese de que la misma versión de tfx aparece como una dependencia.

[Solo Dataflow] Uso de una imagen de contenedor para un trabajador

TFX 0.26.0 y por encima tiene soporte experimental para el uso de la imagen contenedor personalizado para los trabajadores de flujo de datos.

Para usar esto, debe:

  • Construir una imagen del estibador que tiene tanto tfx y código y dependencias de encargo de los usuarios pre-instalados.
    • Para los usuarios que (1) el uso tfx>=0.26 y (2) usa Python 3.7 para desarrollar sus tuberías, la forma más fácil de hacerlo es extender la correspondiente versión del funcionario tensorflow/tfx imagen:
# 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
  • Envíe la imagen creada a un registro de imágenes de contenedor al que puede acceder el proyecto que usa Dataflow.
    • Los usuarios de Google Cloud pueden considerar el uso de la nube de construcción , que muy bien automatiza los pasos anteriores.
  • Proporcionar 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 esté predeterminado para Dataflow.

TODO (b / 179738639): Crear documentación sobre la prueba de contenedor personalizado a nivel local después de https://issues.apache.org/jira/browse/BEAM-5440

Argumentos de la tubería de vigas

Varios componentes TFX dependen de Beam para el procesamiento de datos distribuidos. Ellos están configurados con beam_pipeline_args , que se especifica durante la durante la creación de la tubería:

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

TFX 0,30 y por encima añade una interfaz, with_beam_pipeline_args , para extender los args haz nivel tubería por componente:

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