Apache Beam et TFX

Apache Beam fournit un cadre pour exécuter des tâches de traitement de données par lots et en streaming qui s'exécutent sur divers moteurs d'exécution. Plusieurs bibliothèques TFX utilisent Beam pour exécuter des tâches, ce qui permet un haut degré d'évolutivité entre les clusters de calcul. Beam inclut la prise en charge d'une variété de moteurs d'exécution ou « exécuteurs », y compris un exécuteur 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 exécuteur pris en charge sans modifications de code. TFX utilise l'API Beam Python, elle est donc limitée aux exécuteurs pris en charge par l'API Python.

Déploiement et évolutivité

À mesure que les exigences en matière de charge de travail augmentent, Beam peut s'adapter à 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écuteurs des déploiements à grande échelle 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.

Consultez la documentation Apache Beam pour plus d'informations sur Apache Beam.

Pour les utilisateurs de Google Cloud, Dataflow est le programme d'exécution recommandé, qui fournit une plate-forme sans serveur et rentable grâce à la mise à l'échelle automatique des ressources, un rééquilibrage dynamique du travail, une intégration approfondie avec d'autres services Google Cloud, une sécurité et une surveillance intégrées.

Code Python personnalisé et dépendances

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

  • preprocessing_fn doit faire référence au 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 s'appuie sur la prise en charge de Beam pour la gestion des dépendances du pipeline Python afin de gérer les dépendances Python. Actuellement, il existe deux manières de gérer cela :

  1. Fournir du code Python et des dépendances en tant que package source
  2. [Dataflow 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é aux utilisateurs qui :

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

Veuillez suivre l'un des chemins dans Gestion des dépendances du pipeline Python pour fournir cela en utilisant l'un des Beam_pipeline_args suivants :

  • --setup_file
  • --extra_package
  • --fichier_exigences

Remarque : dans tous les cas ci-dessus, assurez-vous que la même version de tfx est répertoriée comme dépendance.

[Dataflow uniquement] Utilisation d'une image de conteneur pour un travailleur

TFX 0.26.0 et versions ultérieures disposent d'une prise en charge expérimentale de l'utilisation d'images de conteneur personnalisées pour les nœuds de calcul Dataflow.

Pour l'utiliser, vous devez :

  • Créez une image Docker sur laquelle tfx ainsi que le code personnalisé et les dépendances des utilisateurs sont préinstallés.
    • Pour les utilisateurs qui (1) utilisent tfx>=0.26 et (2) utilisent python 3.7 pour développer leurs pipelines, le moyen le plus simple de le faire est d'étendre la version correspondante de l'image officielle 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
  • Transférez l'image créée vers un registre d'images de conteneur accessible par le projet utilisé par Dataflow.
    • Les utilisateurs de Google Cloud peuvent envisager d'utiliser Cloud Build qui automatise joliment les étapes ci-dessus.
  • Fournissez beam_pipeline_args suivants :
beam_pipeline_args.extend([
    '--runner=DataflowRunner',
    '--project={project-id}',
    '--worker_harness_container_image={image-ref}',
    '--experiments=use_runner_v2',
])

TODO(b/171733562) : supprimez use_runner_v2 une fois qu'il est la valeur par défaut pour Dataflow.

À FAIRE (b/179738639) : Créer une documentation expliquant comment tester un conteneur personnalisé localement après https://issues.apache.org/jira/browse/BEAM-5440

Arguments du pipeline de poutre

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é lors de la création du pipeline :

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

TFX 0.30 et supérieur ajoute une interface, with_beam_pipeline_args , pour étendre les arguments de faisceau au niveau du pipeline par composant :

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