Rejoignez la communauté SIG TFX-Addons et contribuez à rendre TFX encore meilleur ! Rejoignez SIG TFX-Addons

Apache Beam et TFX

Apache faisceau fournit un cadre pour le lot en cours d' exécution et le streaming traitement des données d' emplois qui fonctionnent sur une variété de moteurs d'exécution. Plusieurs des bibliothèques TFX utilisent Beam pour exécuter des tâches, ce qui permet un degré élevé d'évolutivité entre les clusters de calcul. Beam prend en charge une variété de moteurs d'exécution ou « runners », y compris un programme d'exécution direct qui s'exécute sur un seul nœud de calcul et est très utile pour le développement, les tests ou les petits déploiements. Beam fournit une couche d'abstraction qui permet à TFX de s'exécuter sur n'importe quel coureur pris en charge sans modifications de code. TFX utilise l'API Beam Python, il est donc limité aux coureurs pris en charge par l'API Python.

Déploiement et évolutivité

À mesure que les exigences de charge de travail augmentent, Beam peut évoluer vers de très grands déploiements sur de grands clusters de calcul. Ceci n'est limité que par l'évolutivité du coureur sous-jacent. Les exécutants dans les grands déploiements seront généralement déployés sur un système d'orchestration de conteneurs tel que Kubernetes ou Apache Mesos pour automatiser le déploiement, la mise à l'échelle et la gestion des applications.

Voir le faisceau Apache documentation pour plus d' informations sur Apache Beam.

Pour les utilisateurs de Google CLOUD, Dataflow est le coureur recommandé, qui fournit une plate - forme et Serverless rentable grâce autoscaling des ressources, le rééquilibrage de travail dynamique, l' intégration profonde avec d' autres services Google Cloud, sécurité intégrée et le suivi.

Code Python personnalisé et dépendances

Une complexité notable de l'utilisation de Beam dans un pipeline TFX est la gestion du code personnalisé et/ou des dépendances nécessaires à partir de modules Python supplémentaires. Voici quelques exemples de situations pouvant poser problème :

  • preprocessing_fn doit faire référence au propre module Python de l'utilisateur
  • un extracteur personnalisé pour le composant Evaluator
  • modules personnalisés qui sont sous-classés à partir d'un composant TFX

TFX repose sur le soutien de faisceau pour la gestion Python Pipeline dépendances pour gérer les dépendances Python. Il existe actuellement deux manières de gérer cela :

  1. Fournir du code Python et des dépendances en tant que package source
  2. [Flux de données uniquement] Utilisation d'une image de conteneur en tant que travailleur

Ceux-ci sont discutés ensuite.

Fournir du code Python et des dépendances en tant que package source

Ceci est recommandé pour les utilisateurs qui :

  1. Connaissez-vous l'empaquetage Python et
  2. Utilisez uniquement le code source Python (c'est-à-dire pas de modules C ou de bibliothèques partagées).

S'il vous plaît suivre l' un des chemins dans la gestion Python Pipeline dépendances pour fournir cette aide de l' une des beam_pipeline_args suivantes:

  • --setup_file
  • --extra_paquet
  • --requirements_file

Avis: Dans tous les cas ci - dessus, s'il vous plaît assurez - vous que la même version de tfx est répertorié comme une dépendance.

[Flux de données uniquement] Utilisation d'une image de conteneur pour un nœud de calcul

TFX 0.26.0 et a surtout un support expérimental pour l' utilisation de l' image de conteneur personnalisé pour les travailleurs Dataflow.

Pour l'utiliser, vous devez :

  • Construire une image Docker qui a à la fois tfx et le code personnalisé des utilisateurs et dépendances pré-installés.
    • Pour les utilisateurs qui (1) l' utilisation tfx>=0.26 et (2) utilise Python 3.7 pour développer leurs pipelines, la meilleure façon de le faire est l' extension de la version correspondante du fonctionnaire tensorflow/tfx l' image:
# 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
  • Transférez l'image créée vers un registre d'images de conteneur accessible par le projet utilisé par Dataflow.
    • Google les utilisateurs de Cloud peuvent envisager d' utiliser Construire - Cloud qui automatise bien au- dessus des étapes.
  • Fournir suivantes beam_pipeline_args :
beam_pipeline_args.extend([
    '--runner=DataflowRunner',
    '--project={project-id}',
    '--worker_harness_container_image={image-ref}',
    '--experiments=use_runner_v2',
])

À FAIRE (b/171733562) : supprimez use_runner_v2 une fois qu'il est utilisé par défaut pour Dataflow.

TODO (b / 179738639): Créer de la documentation pour savoir comment tester conteneur personnalisé localement après https://issues.apache.org/jira/browse/BEAM-5440

Arguments du pipeline de faisceau

Plusieurs composants TFX s'appuient sur Beam pour le traitement distribué des données. Ils sont configurés avec beam_pipeline_args , qui est spécifié au cours lors de la création de pipeline:

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

TFX 0,30 et ajoute au- dessus d' une interface, with_beam_pipeline_args , pour étendre le faisceau au niveau du pipeline args par composant:

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