Cloud Composer 1 befindet sich im Modus nach der Wartung. Google veröffentlicht keine weiteren Updates für Cloud Composer 1, einschließlich neuer Versionen von Airflow, Fehlerkorrekturen und Sicherheitsupdates. Wir empfehlen die Migration zu Cloud Composer 2.

Diese Seite wurde von der Cloud Translation API übersetzt.

Airflow-DAGs schreiben

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

In dieser Anleitung erfahren Sie, wie Sie einen gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) in Apache Airflow für die Ausführung in einer Cloud Composer-Umgebung schreiben.

Da Apache Airflow keine strikte DAG- und Aufgabenisolierung bietet, empfehlen wir, separate Produktions- und Testumgebungen zu verwenden, um DAG-Interferenzen zu vermeiden. Weitere Informationen finden Sie unter DAGs testen.

Airflow-DAG strukturieren

Ein Airflow-DAG wird in einer Python-Datei definiert und besteht aus den folgenden Komponenten:

DAG-Definition
Airflow-Operatoren
Beziehungen zu Betreibern

Die folgenden Code-Snippets zeigen Beispiele für die einzelnen Komponenten ohne Kontext.

Eine DAG-Definition

Das folgende Beispiel zeigt eine Airflow-DAG-Definition:

import datetime

from airflow import models

default_dag_args = {
    # The start_date describes when a DAG is valid / can be run. Set this to a
    # fixed point in time rather than dynamically, since it is evaluated every
    # time a DAG is parsed. See:
    # https://airflow.apache.org/faq.html#what-s-the-deal-with-start-date
    "start_date": datetime.datetime(2018, 1, 1),
}

# Define a DAG (directed acyclic graph) of tasks.
# Any task you create within the context manager is automatically added to the
# DAG object.
with models.DAG(
    "composer_sample_simple_greeting",
    schedule_interval=datetime.timedelta(days=1),
    default_args=default_dag_args,
) as dag:

Operatoren und Aufgaben

Airflow-Operatoren beschreiben die auszuführende Arbeit. Eine Aufgabe ist eine bestimmte Instanz eines Operators.

from airflow.operators.bash import BashOperator
from airflow.operators.python import PythonOperator

    def greeting():
        import logging

        logging.info("Hello World!")

    # An instance of an operator is called a task. In this case, the
    # hello_python task calls the "greeting" Python function.
    hello_python = PythonOperator(task_id="hello", python_callable=greeting)

    # Likewise, the goodbye_bash task calls a Bash script.
    goodbye_bash = BashOperator(task_id="bye", bash_command="echo Goodbye.")

Aufgabenbeziehungen

Aufgabenbeziehungen beschreiben die Reihenfolge, in der die Arbeit ausgeführt werden muss.

# Define the order in which the tasks complete by using the >> and <<
# operators. In this example, hello_python executes before goodbye_bash.
hello_python >> goodbye_bash

Vollständiger DAG-Workflow in Python

Der folgende Workflow ist eine vollständige DAG-Vorlage, die aus zwei Aufgaben besteht: einer hello_python- und einer goodbye_bash-Aufgabe:


import datetime

from airflow import models

from airflow.operators.bash import BashOperator
from airflow.operators.python import PythonOperator



default_dag_args = {
    # The start_date describes when a DAG is valid / can be run. Set this to a
    # fixed point in time rather than dynamically, since it is evaluated every
    # time a DAG is parsed. See:
    # https://airflow.apache.org/faq.html#what-s-the-deal-with-start-date
    "start_date": datetime.datetime(2018, 1, 1),
}

# Define a DAG (directed acyclic graph) of tasks.
# Any task you create within the context manager is automatically added to the
# DAG object.
with models.DAG(
    "composer_sample_simple_greeting",
    schedule_interval=datetime.timedelta(days=1),
    default_args=default_dag_args,
) as dag:
    def greeting():
        import logging

        logging.info("Hello World!")

    # An instance of an operator is called a task. In this case, the
    # hello_python task calls the "greeting" Python function.
    hello_python = PythonOperator(task_id="hello", python_callable=greeting)

    # Likewise, the goodbye_bash task calls a Bash script.
    goodbye_bash = BashOperator(task_id="bye", bash_command="echo Goodbye.")

    # Define the order in which the tasks complete by using the >> and <<
    # operators. In this example, hello_python executes before goodbye_bash.
    hello_python >> goodbye_bash

Weitere Informationen zum Definieren von Airflow-DAGs finden Sie in der Airflow-Anleitung und in den Airflow-Konzepten.

Airflow-Operatoren

Die folgenden Beispiele enthalten einige beliebte Airflow-Operatoren. Eine verbindliche Referenz zu den Airflow-Operatoren finden Sie in der Referenz zu Operatoren und Hooks und im Index der Anbieter.

BashOperator

Mit dem BashOperator können Sie Befehlszeilenprogramme ausführen.

from airflow.operators import bash

    # Create BigQuery output dataset.
    make_bq_dataset = bash.BashOperator(
        task_id="make_bq_dataset",
        # Executing 'bq' command requires Google Cloud SDK which comes
        # preinstalled in Cloud Composer.
        bash_command=f"bq ls {bq_dataset_name} || bq mk {bq_dataset_name}",
    )

Cloud Composer führt die bereitgestellten Befehle in einem Bash-Script auf einem Airflow-Worker aus. Der Worker ist ein Docker-Container auf Basis von Debian und enthält mehrere Pakete.

gcloud-Befehl, einschließlich des gcloud storage-Unterbefehls für die Arbeit mit Cloud Storage-Buckets
bq-Befehlszeilentool
kubectl-Befehlszeilentool

PythonOperator

Verwenden Sie den PythonOperator, um beliebigen Python-Code auszuführen.

Cloud Composer führt den Python-Code in einem Container aus, der Pakete für die in Ihrer Umgebung verwendete Cloud Composer-Image-Version enthält.

Informationen zum Installieren weiterer Python-Pakete finden Sie unter Python-Abhängigkeiten installieren.

Google Cloud Betreiber

Verwenden Sie dieGoogle Cloud Airflow-Operatoren, um Aufgaben auszuführen, die Google Cloud -Produkte verwenden. Beispielsweise fragen und verarbeiten BigQuery-Operatoren Daten in BigQuery.

Es gibt viele weitere Airflow-Operatoren für Google Cloud und einzelne Dienste von Google Cloud. Eine vollständige Liste finden Sie unter Google Cloud Operatoren.

from airflow.providers.google.cloud.operators import bigquery
from airflow.providers.google.cloud.transfers import bigquery_to_gcs

    bq_recent_questions_query = bigquery.BigQueryInsertJobOperator(
        task_id="bq_recent_questions_query",
        configuration={
            "query": {
                "query": RECENT_QUESTIONS_QUERY,
                "useLegacySql": False,
                "destinationTable": {
                    "projectId": project_id,
                    "datasetId": bq_dataset_name,
                    "tableId": bq_recent_questions_table_id,
                },
            }
        },
        location=location,
    )

EmailOperator

Verwenden Sie den EmailOperator, um E-Mails von einem DAG zu senden. Wenn Sie E-Mails aus einer Cloud Composer-Umgebung senden möchten, müssen Sie Ihre Umgebung für die Verwendung von SendGrid konfigurieren.

from airflow.operators import email

    # Send email confirmation (you will need to set up the email operator
    # See https://cloud.google.com/composer/docs/how-to/managing/creating#notification
    # for more info on configuring the email operator in Cloud Composer)
    email_summary = email.EmailOperator(
        task_id="email_summary",
        to="{{var.value.email}}",
        subject="Sample BigQuery notify data ready",
        html_content="""
        Analyzed Stack Overflow posts data from {min_date} 12AM to {max_date}
        12AM. The most popular question was '{question_title}' with
        {view_count} views. Top 100 questions asked are now available at:
        {export_location}.
        """.format(
            min_date=min_query_date,
            max_date=max_query_date,
            question_title=(
                "{{ ti.xcom_pull(task_ids='bq_read_most_popular', "
                "key='return_value')[0][0] }}"
            ),
            view_count=(
                "{{ ti.xcom_pull(task_ids='bq_read_most_popular', "
                "key='return_value')[0][1] }}"
            ),
            export_location=output_file,
        ),
    )

Benachrichtigungen bei Fehlern des Mobilfunkanbieters

Zum Senden einer E-Mail-Benachrichtigung, wenn ein Operator im DAG fehlerhaft ist, legen Sie für email_on_failure den Wert True fest. Zum Senden von E-Mails aus einer Cloud Composer-Umgebung müssen Sie Ihre Umgebung für die Verwendung von SendGrid konfigurieren.

from airflow import models

default_dag_args = {
    "start_date": yesterday,
    # Email whenever an Operator in the DAG fails.
    "email": "{{var.value.email}}",
    "email_on_failure": True,
    "email_on_retry": False,
    "retries": 1,
    "retry_delay": datetime.timedelta(minutes=5),
    "project_id": project_id,
}

with models.DAG(
    "composer_sample_bq_notify",
    schedule_interval=datetime.timedelta(weeks=4),
    default_args=default_dag_args,
) as dag:

Richtlinien für DAG-Workflows

Platzieren Sie benutzerdefinierte Python-Bibliotheken im ZIP-Archiv eines DAG in einem verschachtelten Verzeichnis. Platzieren Sie Bibliotheken nicht auf der obersten Ebene des DAG-Verzeichnisses.

Airflow prüft den Ordner dags/ nur auf DAGs in Python-Modulen, die sich auf der obersten Ebene des Ordners „DAGs“ und auf der obersten Ebene eines ZIP-Archivs befinden, das ebenfalls im Ordner dags/ auf oberster Ebene enthalten ist. Wenn Airflow in einem ZIP-Archiv ein Python-Modul ermittelt, das weder airflow- noch DAG-Teilstrings enthält, beendet Airflow die Verarbeitung des ZIP-Archivs. Airflow gibt dann nur diejenigen DAGs zurück, die bis zu diesem Zeitpunkt gefunden wurden.
Achten Sie aus Gründen der Fehlertoleranz darauf, nicht mehrere DAG-Objekte im gleichen Python-Modul zu definieren.
Verwenden Sie keine untergeordneten DAGs. Gruppieren Sie stattdessen Aufgaben in DAGs.
Platzieren Sie Dateien, die zum Zeitpunkt des DAG-Parsens erforderlich sind, im Ordner dags/ und nicht im Ordner data/.
Implementieren Sie Einheitentests für Ihre DAGs.
Testen Sie entwickelte oder geänderte DAGs wie in der Anleitung zum Testen von DAGs empfohlen.
Prüfen Sie, ob die entwickelten DAGs die DAG-Parsing-Zeiten nicht zu stark erhöhen.
Airflow-Aufgaben können aus verschiedenen Gründen fehlschlagen. Um Ausfälle bei der Ausführung ganzer DAGs zu vermeiden, empfehlen wir, Wiederholungsversuche für Aufgaben zu aktivieren. Wenn Sie die maximale Anzahl von Wiederholungen auf 0 festlegen, werden keine Wiederholungen ausgeführt.

Wir empfehlen, die Option default_task_retries mit einem anderen Wert für die Wiederholungen von Aufgaben als 0 zu überschreiben. Außerdem können Sie den Parameter retries auf Aufgabenebene festlegen.
Wenn Sie GPUs in Ihren Airflow-Aufgaben verwenden möchten, erstellen Sie einen separaten GKE-Cluster, der auf Knoten mit Maschinen mit GPUs basiert. Verwenden Sie GKEStartPodOperator, um Ihre Aufgaben auszuführen.
Führen Sie keine CPU- und speicherintensiven Aufgaben im Knotenpool des Clusters aus, in dem andere Airflow-Komponenten (Planer, Worker, Webserver) ausgeführt werden. Verwenden Sie stattdessen KubernetesPodOperator oder GKEStartPodOperator.
Wenn Sie DAGs in einer Umgebung bereitstellen, laden Sie nur die Dateien in den Ordner /dags hoch, die für die Interpretation und Ausführung von DAGs unbedingt erforderlich sind.
Begrenzen Sie die Anzahl der DAG-Dateien im Ordner /dags.

Airflow parst kontinuierlich DAGs im Ordner /dags. Beim Parsen wird der DAGs-Ordner durchlaufen. Die Anzahl der Dateien, die geladen werden müssen (mit ihren Abhängigkeiten), wirkt sich auf die Leistung des DAG-Parsings und der Aufgabenplanung aus. Es ist viel effizienter, 100 Dateien mit jeweils 100 DAGs zu verwenden als 10.000 Dateien mit jeweils 1 DAG. Daher wird eine solche Optimierung empfohlen. Bei dieser Optimierung wird ein Gleichgewicht zwischen Parsingzeit und Effizienz der DAG-Erstellung und -Verwaltung hergestellt.

Wenn Sie beispielsweise 10.000 DAG-Dateien bereitstellen möchten, können Sie 100 ZIP-Dateien mit jeweils 100 DAG-Dateien erstellen.

Zusätzlich zu den oben genannten Hinweisen kann es bei mehr als 10.000 DAG-Dateien sinnvoll sein, DAGs programmatisch zu generieren. Sie können beispielsweise eine einzelne Python-DAG-Datei implementieren, die eine bestimmte Anzahl von DAG-Objekten generiert (z. B. 20 oder 100 DAG-Objekte).
Verwenden Sie keine eingestellten Airflow-Operatoren. Verwenden Sie stattdessen die aktuellen Alternativen.

FAQs zum Schreiben von DAGs

Wie minimiere ich Codewiederholungen, wenn ich die gleichen oder ähnliche Aufgaben in mehreren DAGs ausführen möchte?

Wir empfehlen das Definieren von Bibliotheken und Wrappern, um Codewiederholungen zu reduzieren.

Wie kann ich Code in mehreren DAG-Dateien wiederverwenden?

Binden Sie Hilfsfunktionen in eine lokale Python-Bibliothek ein und importieren Sie die Funktionen. Sie können in allen DAGs, die sich im dags/-Ordner Ihres Buckets befinden, auf die Funktionen verweisen.

Wie minimiere ich das Risiko unterschiedlicher Definitionen?

Angenommen, es gibt zwei Teams, die Rohdaten zu Umsatzkennzahlen zusammenfassen möchten. Die Teams schreiben zwei geringfügig unterschiedliche Aufgaben für den gleichen Sachverhalt. Definieren Sie Bibliotheken für die Arbeit mit den Umsatzdaten, sodass diejenigen, die DAGs implementieren, die Definition des zusammengefassten Umsatzes eindeutig festlegen müssen.

Wie lege ich Abhängigkeiten zwischen DAGs fest?

Das hängt davon ab, wie Sie die Abhängigkeit definieren möchten.

Wenn Sie zwei DAGs haben (DAG A und DAG B) und DAG B nach DAG A ausgelöst werden soll, können Sie einen TriggerDagRunOperator am Ende von DAG A platzieren.

Wenn DAG B nur von einem von DAG A generierten Artefakt abhängt (z. B. eine Pub/Sub-Meldung), ist ein Sensor möglicherweise besser geeignet.

Wenn DAG B eng mit DAG A integriert ist, können Sie die beiden DAGs möglicherweise in einen DAG zusammenführen.

Wie übergebe ich eindeutige Ausführungs-IDs an einen DAG und die zugehörigen Aufgaben?

Angenommen, es sollen Dataproc-Clusternamen und -Dateipfade übergeben werden.

In diesem Fall können Sie eine zufällige eindeutige ID generieren und dafür str(uuid.uuid4()) in einem PythonOperator zurückgeben. Dadurch wird die ID in XComs abgelegt, sodass Sie in anderen Operatoren über Vorlagenfelder darauf verweisen können.

Prüfen Sie vor dem Generieren einer uuid, ob eine DagRun-spezifische ID sinnvoller wäre. Sie können auf diese IDs in Jinja-Substitutionen auch mit Makros verweisen.

Wie trenne ich Aufgaben in einem DAG?

Eine Aufgabe sollte eine idempotente Arbeitseinheit sein. Vermeiden Sie es deshalb, einen aus mehreren Schritten bestehenden Workflow in eine einzelne Aufgabe aufzunehmen, z. B. in ein komplexes Programm, das in einem PythonOperator ausgeführt wird.

Soll ich mehrere Aufgaben in einem einzelnen DAG definieren, um Daten aus mehreren Quellen zusammenzufassen?

Angenommen, ich habe mehrere Tabellen mit Rohdaten und möchte tägliche Zusammenfassungen für jede einzelne Tabelle erstellen. Die Aufgaben sind nicht voneinander abhängig. Soll ich eine Aufgabe und einen DAG für jede Tabelle oder einen allgemeinen DAG erstellen?

Wenn es für Sie kein Problem ist, dass jede Aufgabe die gleichen Attribute auf DAG-Ebene verwendet (z. B. schedule_interval), ist es sinnvoll, mehrere Aufgaben in einem einzigen DAG zu definieren. Andernfalls können zur Minimierung der Codewiederholung mehrere DAGs aus einem einzigen Python-Modul generiert werden. Dazu platzieren Sie diese in den globalen globals() des Moduls.

Wie beschränke ich die Anzahl gleichzeitiger Aufgaben, die in einem DAG ausgeführt werden?

Ich möchte z. B. vermeiden, dass API-Nutzungslimits und -kontingente überschritten oder zu viele Prozesse gleichzeitig ausgeführt werden.

Sie können dazu Airflow-Pools in der Airflow-Weboberfläche definieren und in Ihren DAGs Aufgaben mit vorhandenen Pools verknüpfen.

FAQs zur Verwendung von Operatoren

Soll ich den `DockerOperator` verwenden?

Wir raten von der Verwendung des DockerOperator ab, es sei denn, er wird zum Starten von Containern in einer Remote-Docker-Installation verwendet (nicht im Cluster einer Umgebung). In einer Cloud Composer-Umgebung hat der Operator keinen Zugriff auf Docker-Daemons.

Verwenden Sie stattdessen KubernetesPodOperator oder GKEStartPodOperator. Diese Operatoren starten Kubernetes-Pods in Kubernetes- bzw. GKE-Clustern. Es ist nicht empfehlenswert, Pods im Cluster einer Umgebung zu starten, da dies zu Konkurrenz um Ressourcen führen kann.

Soll ich den `SubDagOperator` verwenden?

Die Verwendung von SubDagOperator wird nicht empfohlen.

Verwenden Sie die Alternativen, die unter Aufgaben gruppieren vorgeschlagen werden.

Soll ich Python-Code nur in `PythonOperators` ausführen, um Python-Operatoren vollständig zu trennen?

Abhängig von Ihrem Ziel haben Sie mehrere Optionen.

Falls Ihr einziges Ziel ist, separate Python-Abhängigkeiten beizubehalten, können Sie PythonVirtualenvOperator verwenden.

Verwenden Sie den KubernetesPodOperator. Mit diesem Operator können Sie Kubernetes-Pods definieren und die Pods in anderen Clustern ausführen.

Wie füge ich benutzerdefinierte binäre oder Nicht-PyPI-Pakete hinzu?

Sie können dazu Pakete installieren, die in privaten Paket-Repositories gehostet werden,

Wie übergebe ich Argumente einheitlich an einen DAG und die zugehörigen Aufgaben?

Sie können die integrierte Airflow-Unterstützung für Jinja-Vorlagen nutzen, um Argumente zu übergeben, die in Vorlagenfeldern verwendet werden können.

Wann findet die Vorlagenersetzung statt?

Die Vorlagen werden auf den Airflow-Workern unmittelbar vor dem Aufruf der pre_execute-Funktion eines Operators ersetzt. In der Praxis bedeutet dies, dass Vorlagen erst unmittelbar vor der Ausführung einer Aufgabe ersetzt werden.

Wie kann ich erkennen, welche Operatorargumente die Vorlagenersetzung unterstützen?

Operatorargumente, die die Jinja2-Vorlagenersetzung unterstützen, sind explizit entsprechend gekennzeichnet.

Suchen Sie in der Operatordefinition nach dem Feld template_fields. Es enthält eine Liste der Argumentnamen, für die die Vorlagenersetzung verwendet wird.

Dazu gehört beispielsweise der BashOperator, mit dem Vorlagen für die Argumente bash_command und env unterstützt werden.

Eingestellte und entfernte Airflow-Operatoren

Die in der folgenden Tabelle aufgeführten Airflow-Operatoren werden eingestellt:

Verwenden Sie diese Operatoren nicht in Ihren DAGs. Verwenden Sie stattdessen die bereitgestellten aktuellen Ersatzoperatoren.
Wenn ein Operator als entfernt aufgeführt ist, war er bereits in einem der veröffentlichten Airflow-Builds in Cloud Composer 3 nicht mehr verfügbar.
Wenn ein Operator als zum Entfernen geplant aufgeführt ist, wird er eingestellt und in einem zukünftigen Airflow-Build entfernt.
Wenn ein Betreiber als bereits in den neuesten Google-Anbietern entfernt aufgeführt ist, wird er in der neuesten Version des apache-airflow-providers-google-Pakets entfernt. Gleichzeitig verwendet Cloud Composer weiterhin die Version dieses Pakets, aus der der Operator noch nicht entfernt wurde.

Veralteter Operator	Status	Ersatzoperator	Ersatzgerät verfügbar ab
CreateAutoMLTextTrainingJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	SupervisedFineTuningTrainOperator	composer-3-airflow-2.9.3-build.1 composer-3-airflow-2.9.1-build.8
GKEDeploymentHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GKEKubernetesHook	Alle Versionen
GKECustomResourceHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GKEKubernetesHook	Alle Versionen
GKEPodHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GKEKubernetesHook	Alle Versionen
GKEJobHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GKEKubernetesHook	Alle Versionen
GKEPodAsyncHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GKEKubernetesAsyncHook	Alle Versionen
SecretsManagerHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleCloudSecretManagerHook	composer-3-airflow-2.7.3-build.6
BigQueryExecuteQueryOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	BigQueryInsertJobOperator	Alle Versionen
BigQueryPatchDatasetOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	BigQueryUpdateDatasetOperator	Alle Versionen
DataflowCreateJavaJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	beam.BeamRunJavaPipelineOperator	Alle Versionen
DataflowCreatePythonJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	beam.BeamRunPythonPipelineOperator	Alle Versionen
DataprocSubmitPigJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataprocSubmitJobOperator	Alle Versionen
DataprocSubmitHiveJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataprocSubmitJobOperator	Alle Versionen
DataprocSubmitSparkSqlJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataprocSubmitJobOperator	Alle Versionen
DataprocSubmitSparkJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataprocSubmitJobOperator	Alle Versionen
DataprocSubmitHadoopJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataprocSubmitJobOperator	Alle Versionen
DataprocSubmitPySparkJobOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataprocSubmitJobOperator	Alle Versionen
BigQueryTableExistenceAsyncSensor	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	BigQueryTableExistenceSensor	Alle Versionen
BigQueryTableExistencePartitionAsyncSensor	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	BigQueryTablePartitionExistenceSensor	Alle Versionen
CloudComposerEnvironmentSensor	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	CloudComposerCreateEnvironmentOperator, CloudComposerDeleteEnvironmentOperator, CloudComposerUpdateEnvironmentOperator	Alle Versionen
GCSObjectExistenceAsyncSensor	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GCSObjectExistenceSensor	Alle Versionen
GoogleAnalyticsHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleAnalyticsAdminHook	Alle Versionen
GoogleAnalyticsListAccountsOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleAnalyticsAdminListAccountsOperator	Alle Versionen
GoogleAnalyticsGetAdsLinkOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleAnalyticsAdminGetGoogleAdsLinkOperator	Alle Versionen
GoogleAnalyticsRetrieveAdsLinksListOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleAnalyticsAdminListGoogleAdsLinksOperator	Alle Versionen
GoogleAnalyticsDataImportUploadOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleAnalyticsAdminCreateDataStreamOperator	Alle Versionen
GoogleAnalyticsDeletePreviousDataUploadsOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	GoogleAnalyticsAdminDeleteDataStreamOperator	Alle Versionen
DataPipelineHook	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataflowHook	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
CreateDataPipelineOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataflowCreatePipelineOperator	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
RunDataPipelineOperator	Eingestellt, Entfernung geplant, Bereits in den neuesten Google-Anbietern entfernt	DataflowRunPipelineOperator	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
AutoMLDatasetLink	Eingestellt, Entfernung geplant	TranslationLegacyDatasetLink	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
AutoMLDatasetListLink	Eingestellt, Entfernung geplant	TranslationDatasetListLink	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
AutoMLModelLink	Eingestellt, Entfernung geplant	TranslationLegacyModelLink	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
AutoMLModelTrainLink	Eingestellt, Entfernung geplant	TranslationLegacyModelTrainLink	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
AutoMLModelPredictLink	Eingestellt, Entfernung geplant	TranslationLegacyModelPredictLink	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
AutoMLBatchPredictOperator	Eingestellt, Entfernung geplant	vertex_ai.batch_prediction_job	composer-3-airflow-2.9.3-build.4
AutoMLPredictOperator	Eingestellt, Entfernung geplant	vertex_aigenerative_model. TextGenerationModelPredictOperator, translate.TranslateTextOperator	composer-3-airflow-2.7.3-build.6
PromptLanguageModelOperator	Eingestellt, Entfernung geplant	TextGenerationModelPredictOperator	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
GenerateTextEmbeddingsOperator	Eingestellt, Entfernung geplant	TextEmbeddingModelGetEmbeddingsOperator	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
PromptMultimodalModelOperator	Eingestellt, Entfernung geplant	GenerativeModelGenerateContentOperator	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
PromptMultimodalModelWithMediaOperator	Eingestellt, Entfernung geplant	GenerativeModelGenerateContentOperator	composer-3-airflow-2.9.1-build.0 composer-3-airflow-2.7.3-build.9
DataflowStartSqlJobOperator	Eingestellt, Entfernung geplant	DataflowStartYamlJobOperator	composer-3-airflow-2.9.3-build.1 composer-3-airflow-2.9.1-build.8
LifeSciencesHook	Eingestellt, Entfernung geplant	Google Cloud-Batch-Operator-Hook	Wird noch bekannt gegeben
DataprocScaleClusterOperator	Eingestellt, Entfernung geplant	DataprocUpdateClusterOperator	Wird noch bekannt gegeben
MLEngineStartBatchPredictionJobOperator	Eingestellt, Entfernung geplant	CreateBatchPredictionJobOperator	Wird noch bekannt gegeben
MLEngineManageModelOperator	Eingestellt, Entfernung geplant	MLEngineCreateModelOperator, MLEngineGetModelOperator	Wird noch bekannt gegeben
MLEngineGetModelOperator	Eingestellt, Entfernung geplant	GetModelOperator	Wird noch bekannt gegeben
MLEngineDeleteModelOperator	Eingestellt, Entfernung geplant	DeleteModelOperator	Wird noch bekannt gegeben
MLEngineManageVersionOperator	Eingestellt, Entfernung geplant	MLEngineCreateVersion, MLEngineSetDefaultVersion, MLEngineListVersions, MLEngineDeleteVersion	Wird noch bekannt gegeben
MLEngineCreateVersionOperator	Eingestellt, Entfernung geplant	Parameter „parent_model“ für Vertex AI-Operatoren	Wird noch bekannt gegeben
MLEngineSetDefaultVersionOperator	Eingestellt, Entfernung geplant	SetDefaultVersionOnModelOperator	Wird noch bekannt gegeben
MLEngineListVersionsOperator	Eingestellt, Entfernung geplant	ListModelVersionsOperator	Wird noch bekannt gegeben
MLEngineDeleteVersionOperator	Eingestellt, Entfernung geplant	DeleteModelVersionOperator	Wird noch bekannt gegeben
MLEngineStartTrainingJobOperator	Eingestellt, Entfernung geplant	CreateCustomPythonPackageTrainingJobOperator	Wird noch bekannt gegeben
MLEngineTrainingCancelJobOperator	Eingestellt, Entfernung geplant	CancelCustomTrainingJobOperator	Wird noch bekannt gegeben
LifeSciencesRunPipelineOperator	Eingestellt, Entfernung geplant	Google Cloud-Batch-Operatoren	Wird noch bekannt gegeben
MLEngineCreateModelOperator	Eingestellt, Entfernung geplant	entsprechender Vertex AI-Operator	Wird noch bekannt gegeben