Treten Sie der SIG TFX-Addons-Community bei und helfen Sie, TFX noch besser zu machen!

Apache Beam und TFX

Apache Beam bietet ein Framework zum Ausführen von Batch- und Streaming-Datenverarbeitungsjobs, die auf einer Vielzahl von Ausführungsmodulen ausgeführt werden. Einige der TFX-Bibliotheken verwenden Beam zum Ausführen von Aufgaben, was ein hohes Maß an Skalierbarkeit über Rechencluster hinweg ermöglicht. Beam bietet Unterstützung für eine Vielzahl von Ausführungsmodulen oder "Läufern", einschließlich eines direkten Läufers, der auf einem einzelnen Rechenknoten ausgeführt wird und für die Entwicklung, das Testen oder kleine Bereitstellungen sehr nützlich ist. Beam bietet eine Abstraktionsschicht, mit der TFX auf jedem unterstützten Läufer ohne Codeänderungen ausgeführt werden kann. TFX verwendet die Beam Python-API, daher ist sie auf die Läufer beschränkt, die von der Python-API unterstützt werden.

Bereitstellung und Skalierbarkeit

Wenn die Anforderungen an die Arbeitslast steigen, kann Beam auf sehr große Bereitstellungen in großen Computerclustern skaliert werden. Dies ist nur durch die Skalierbarkeit des zugrunde liegenden Läufers begrenzt. Läufer in großen Bereitstellungen werden normalerweise auf einem Container-Orchestrierungssystem wie Kubernetes oder Apache Mesos bereitgestellt, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu automatisieren.

Weitere Informationen zu Apache Beam finden Sie in der Apache Beam- Dokumentation.

Für Google Cloud-Nutzer ist Dataflow der empfohlene Runner, der eine serverlose und kostengünstige Plattform durch automatische Skalierung von Ressourcen, dynamische Neuverteilung der Arbeit, tiefe Integration in andere Google Cloud-Dienste, integrierte Sicherheit und Überwachung bietet.

Benutzerdefinierter Python-Code und Abhängigkeiten

Eine bemerkenswerte Komplexität bei der Verwendung von Beam in einer TFX-Pipeline besteht darin, benutzerdefinierten Code und / oder die Abhängigkeiten zu verarbeiten, die von zusätzlichen Python-Modulen benötigt werden. Hier einige Beispiele, wann dies ein Problem sein könnte:

  • preprocessing_fn muss auf das benutzereigene Python-Modul verweisen
  • Ein benutzerdefinierter Extraktor für die Evaluator-Komponente
  • Benutzerdefinierte Module, die von einer TFX-Komponente untergeordnet werden

TFX stützt sich auf die Unterstützung von Beam für die Verwaltung von Python-Pipeline-Abhängigkeiten , um Python-Abhängigkeiten zu verarbeiten. Derzeit gibt es zwei Möglichkeiten, dies zu verwalten:

  1. Bereitstellen von Python-Code und Abhängigkeiten als Quellpaket
  2. [Nur Datenfluss] Verwenden eines Container-Images als Worker

Diese werden als nächstes besprochen.

Bereitstellen von Python-Code und Abhängigkeiten als Quellpaket

Dies wird Benutzern empfohlen, die:

  1. Sind mit Python-Verpackungen vertraut und
  2. Verwenden Sie nur Python-Quellcode (dh keine C-Module oder gemeinsam genutzten Bibliotheken).

Folgen Sie einem der Pfade unter Verwalten von Python-Pipeline-Abhängigkeiten , um dies mithilfe eines der folgenden Beam_pipeline_args bereitzustellen:

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

Hinweis: tfx Sie in jedem der oben genannten Fälle sicher, dass dieselbe Version von tfx als Abhängigkeit aufgeführt ist.

[Nur Datenfluss] Verwenden eines Container-Images für einen Worker

TFX 0.26.0 und höher bietet experimentelle Unterstützung für die Verwendung eines benutzerdefinierten Container-Images für Dataflow-Mitarbeiter.

Um dies nutzen zu können, müssen Sie:

  • Erstellen Sie ein Docker-Image, auf dem sowohl tfx als auch der benutzerdefinierte Code und die Abhängigkeiten der Benutzer vorinstalliert sind.
    • Für Benutzer, die (1) tfx>=0.26 und (2) Python 3.7 zum Entwickeln ihrer Pipelines verwenden, ist der einfachste Weg, dies zu tun, die entsprechende Version des offiziellen tensorflow/tfx Bildes zu erweitern:
# 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
  • Verschieben Sie das erstellte Image in eine Container-Image-Registrierung, auf die das von Dataflow verwendete Projekt zugreifen kann.
    • Google Cloud-Nutzer können die Verwendung von Cloud Build in Betracht ziehen, mit dem die oben genannten Schritte gut automatisiert werden.
  • Geben Sie folgende 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): Entfernen Sie use_runner_v2, sobald es für Dataflow Standard ist.

TODO (b / 179738639): Erstellen Sie eine Dokumentation zum lokalen Testen von benutzerdefinierten Containern nach https://issues.apache.org/jira/browse/BEAM-5440

Beam-Pipeline-Argumente

Mehrere TFX-Komponenten verlassen sich bei der verteilten Datenverarbeitung auf Beam. Sie werden beam_pipeline_args konfiguriert, das während der Pipelineerstellung angegeben wird:

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

TFX 0.30 und höher fügt eine Schnittstelle with_beam_pipeline_args , um die with_beam_pipeline_args auf Pipeline-Ebene pro Komponente zu erweitern:

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