Ta strona została przetłumaczona przez Cloud Translation API.

Apache Beam i TFX

Apache Beam zapewnia platformę do uruchamiania zadań przetwarzania danych wsadowych i strumieniowych, które działają na różnych silnikach wykonawczych. Kilka bibliotek TFX używa Beam do uruchamiania zadań, co zapewnia wysoki stopień skalowalności w klastrach obliczeniowych. Beam obsługuje różne silniki wykonawcze lub „biegacze”, w tym bezpośredni moduł uruchamiający, który działa na pojedynczym węźle obliczeniowym i jest bardzo przydatny do programowania, testowania lub małych wdrożeń. Beam zapewnia warstwę abstrakcji, która umożliwia działanie TFX na dowolnym obsługiwanym module runner bez modyfikacji kodu. TFX korzysta z API Beam Python, więc jest ograniczony do modułów biegaczy obsługiwanych przez API Pythona.

Wdrożenie i skalowalność

W miarę wzrostu wymagań dotyczących obciążenia Beam można skalować do bardzo dużych wdrożeń w dużych klastrach obliczeniowych. Jest to ograniczone jedynie skalowalnością podstawowego modułu runner. W przypadku dużych wdrożeń moduły uruchamiające będą zazwyczaj wdrażane w systemie orkiestracji kontenerów, takim jak Kubernetes lub Apache Mesos, w celu automatyzacji wdrażania aplikacji, skalowania i zarządzania.

Więcej informacji na temat Apache Beam znajdziesz w dokumentacji Apache Beam .

W przypadku użytkowników Google Cloud zalecanym rozwiązaniem jest Dataflow , który zapewnia bezserwerową i ekonomiczną platformę dzięki automatycznemu skalowaniu zasobów, dynamicznemu równoważeniu pracy, głębokiej integracji z innymi usługami Google Cloud, wbudowanym zabezpieczeniom i monitorowaniu.

Niestandardowy kod Pythona i zależności

Godną uwagi złożonością używania Beam w potoku TFX jest obsługa niestandardowego kodu i/lub zależności wymaganych od dodatkowych modułów Pythona. Oto kilka przykładów sytuacji, w których może to stanowić problem:

preprocessing_fn musi odnosić się do własnego modułu Pythona użytkownika
niestandardowy ekstraktor dla komponentu Evaluator
niestandardowe moduły, które są podklasami komponentu TFX

TFX opiera się na wsparciu Beama w zakresie zarządzania zależnościami potoków Pythona w celu obsługi zależności Pythona. Obecnie można sobie z tym poradzić na dwa sposoby:

Udostępnianie kodu Pythona i zależności jako pakietu źródłowego
[Tylko przepływ danych] Używanie obrazu kontenera jako procesu roboczego

Omówiono je dalej.

Udostępnianie kodu Pythona i zależności jako pakietu źródłowego

Jest to zalecane dla użytkowników, którzy:

Znasz opakowania w języku Python i
Używaj tylko kodu źródłowego Pythona (tzn. żadnych modułów C ani bibliotek współdzielonych).

Aby to zapewnić, skorzystaj z jednej ze ścieżek opisanych w artykule Zarządzanie zależnościami potoków Pythona, korzystając z jednego z następujących argumentów belki_pipeline_args:

--plik_konfiguracyjny
--dodatkowy_pakiet
--plik_wymagań

Uwaga: W każdym z powyższych przypadków upewnij się, że ta sama wersja tfx jest wymieniona jako zależność.

[Tylko przepływ danych] Używanie obrazu kontenera dla pracownika

TFX 0.26.0 i nowsze wersje oferują eksperymentalną obsługę używania niestandardowego obrazu kontenera dla procesów roboczych Dataflow.

Aby z tego skorzystać, musisz:

Zbuduj obraz Dockera, który ma preinstalowany zarówno tfx , jak i niestandardowy kod i zależności użytkowników.
- Dla użytkowników, którzy (1) używają tfx>=0.26 i (2) używają Pythona 3.7 do tworzenia swoich potoków, najłatwiejszym sposobem na zrobienie tego jest rozszerzenie odpowiedniej wersji oficjalnego obrazu 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

Wypchnij utworzony obraz do rejestru obrazów kontenera, do którego dostęp ma projekt używany przez Dataflow.
- Użytkownicy Google Cloud mogą rozważyć użycie Cloud Build , który ładnie automatyzuje powyższe kroki.
Podaj następujące beam_pipeline_args :

beam_pipeline_args.extend([
    '--runner=DataflowRunner',
    '--project={project-id}',
    '--worker_harness_container_image={image-ref}',
    '--experiments=use_runner_v2',
])

DO ZROBIENIA (b/171733562): Usuń use_runner_v2, gdy jest on domyślny dla Dataflow.

DO ZROBIENIA (b/179738639): Utwórz dokumentację dotyczącą lokalnego testowania niestandardowego kontenera po https://issues.apache.org/jira/browse/BEAM-5440

Argumenty dotyczące rurociągu belkowego

Kilka komponentów TFX wykorzystuje Beam do rozproszonego przetwarzania danych. Są one konfigurowane za pomocą beam_pipeline_args , która jest określana podczas tworzenia potoku:

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

TFX 0.30 i nowsze wersje dodają interfejs with_beam_pipeline_args , do rozszerzania argumentów belek na poziomie rurociągu na komponent:

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