Kontingente und Limits

In diesem Dokument sind die für Dataflow geltenden Kontingente und Limits aufgeführt. Weitere Informationen zu Kontingenten finden Sie unter Kontingente für Virtual Private Cloud.

Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten. Daher sind Kontingente Teil eines Systems, das Folgendes tut:

  • Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
  • Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
  • Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
  • Möglichkeit, das Kontingent anzufordern oder zu ändern.

Wenn ein Kontingentlimit überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Google Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Google Cloud-Projekt verwenden.

Verwenden Sie zur Erhöhung/Verringerung der meisten Kontingenten die Google Cloud Console. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

Für Dataflow-Ressourcen gelten außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn dies angegeben ist.

Der verwaltete Dataflow-Dienst hat die folgenden Kontingente und Limits:

  • Jedes Google Cloud-Projekt kann bis zu 3.000.000 Anfragen pro Minute senden.
  • Jeder Dataflow-Job kann maximal 2.000 Compute Engine-Instanzen verwenden. Ohne Angabe einer Worker-Zone kann jeder Streamingjob, der Streaming Engine verwendet, oder jeder Batchjob, der dienstbasiertes Dataflow Shuffle verwendet, maximal 4.000 Compute Engine-Instanzen verwenden.
  • Jedes Google Cloud-Projekt kann standardmäßig höchstens 25 parallele Dataflow-Jobs ausführen.
  • Jeder Dataflow-Worker hat eine maximale Anzahl von Logs, die in einem Zeitintervall ausgegeben werden können. Das genaue Limit finden Sie in der Logging-Dokumentation.
  • Wenn Sie sich für Kontingente auf Organisationsebene entscheiden, kann jede Organisation mindestens 125 parallele Dataflow-Jobs ausführen.
  • Jeder Nutzer kann bis zu 15.000 Monitoringanfragen pro Minute senden.
  • Jeder Nutzer kann bis zu 60 Anfragen zur Joberstellung pro Minute senden.
  • Jeder Nutzer kann bis zu 60 Jobvorlagenanfragen pro Minute senden.
  • Jeder Nutzer kann bis zu 60 Anfragen zur Jobaktualisierung pro Minute senden.
  • Jedes Google Cloud-Projekt erhält die folgenden Shuffle-Slots in jeder Region:
    • asia-east1: 48 Slots
    • asia-northeast1: 24 Slots
    • asia-northeast3: 32 Slots
    • asia-south1: 64 Slots
    • asia-southeast1: 64 Slots
    • australia-southeast1: 24 Slots
    • europe-west1: 640 Slots
    • europe-west2: 32 Slots
    • europe-west3: 40 Slots
    • europe-west4: 512 Slots
    • northamerica-northeast1: 512 Slots
    • us-central1: 640 Slots
    • us-east1: 640 Slots
    • us-east4: 64 Slots
    • us-west1: 384 Slots
    • us-west2: 24 Slots
    • us-west3: 24 Slots
    • andere Regionen: 16 Slots
    16 Slots sind ausreichend für einen Shuffle von etwa 10 TB Daten zur gleichen Zeit.
  • Dataflow-Batchjobs werden nach 30 Tagen abgebrochen.

Compute Engine-Kontingente

Wenn Sie Ihre Pipeline im Dataflow-Dienst ausführen, erstellt Dataflow zum Ausführen des Pipelinecodes Compute Engine-Instanzen.

Compute Engine-Kontingente sind pro Region festgelegt. Prüfen Sie das Compute Engine-Kontingent Ihres Projekts und senden Sie bei Bedarf eine Anfrage in Bezug auf die folgenden Anpassungen:

  • CPUs: Die Standard-Maschinentypen für Dataflow sind n1-standard-1 für Batch-Jobs, n1-standard-2 für Jobs mit Streaming Engine und n1-standard-4 für Jobs ohne Streaming Engine. FlexRS verwendet standardmäßig n1-standard-2-Maschinen. Im Betarelease verwendet FlexRS zu 90 % VMs auf Abruf und zu 10 % normale VMs. Compute Engine berechnet die Anzahl der CPUs durch Addieren der CPU-Gesamtzahl jeder einzelnen Instanz. Werden beispielsweise 10 Instanzen vom Typ n1-standard-4 ausgeführt, zählen sie als 40 CPUs. Weitere Informationen über die Zuordnung von Maschinentypen zur CPU-Anzahl finden Sie hier.
  • Verwendete IP-Adressen: Die Anzahl der in Ihrem Projekt verwendeten IP-Adressen muss für die gewünschte Anzahl von Instanzen ausreichend sein. Um 10 Compute Engine-Instanzen zu verwenden, benötigen Sie 10 aktive IP-Adressen.
  • Persistent Disk: Dataflow hängt Persistent Disk an jede Instanz an.
    • Die standardmäßige Laufwerkgröße beträgt 250 GB für Batch- und 400 GB für Streamingpipelines. Für 10 Instanzen benötigen Sie standardmäßig 2.500 GB nichtflüchtigen Speicher für einen Batchjob.
    • Die standardmäßige Laufwerkgröße für Dataflow Shuffle-Batchpipelines beträgt 25 GB.
    • Die standardmäßige Laufwerkgröße für Streaming Engine-Streamingpipelines beträgt 30 GB.
    • Der Dataflow-Dienst ist derzeit zum Ausführen eines Streamingjobs pro Worker-Instanz auf 15 nichtflüchtige Speicher beschränkt. Jeder nichtflüchtige Speicher ist lokal einer einzelnen Compute Engine-VM zugeordnet. Ein Verhältnis von 1:1 zwischen Workern und Laufwerken ist die minimale Ressourcenzuweisung.
    • Die Compute Engine-Nutzung richtet sich nach der durchschnittlichen Anzahl von Workern. Die Nutzung nichtflüchtiger Speicher basiert hingegen auf dem exakten Wert von --maxNumWorkers. Nichtflüchtige Speicher werden so neu verteilt, dass jeder Worker mit der gleichen Anzahl von Laufwerken verbunden ist.
  • Regional verwaltete Instanzgruppen:Dataflow stellt Ihre Compute Engine-Instanzen als regionale verwaltete Instanzgruppe bereit. Sie müssen dementsprechend folgende Kontingente haben:
    • Eine Instanzgruppe pro Dataflow-Job
    • Eine Instanzvorlage pro Dataflow-Job
    • Eine regional verwaltete Instanzgruppe pro Dataflow-Job

Zusätzliche Kontingente

Je nachdem, welche Quellen und Senken Sie verwenden, benötigen Sie möglicherweise auch zusätzliche Kontingente.

  1. Pub/Sub: Wenn Sie Pub/Sub verwenden, benötigen Sie gegebenenfalls eine Kontingenterhöhung. Beachten Sie bei der Planung der Kontingente, dass zur Verarbeitung einer Nachricht von Pub/Sub 3 Vorgänge nötig sind. Wenn Sie benutzerdefinierte Zeitstempel verwenden, sollten Sie Ihre erwartete Anzahl von Vorgängen verdoppeln, da Dataflow ein separates Abo erstellt, um benutzerdefinierte Zeitstempel zu verfolgen.
  2. BigQuery: Wenn Sie die Streaming API für BigQuery verwenden, gelten Kontingentlimits und andere Einschränkungen.

Kontingente suchen und erhöhen

Sie können Ihre aktuelle Nutzung des Dataflow-spezifischen Kontingents prüfen:

  1. Gehen Sie in der Google Cloud Console zur Seite APIs & Dienste.
    APIs & Dienste aufrufen
  2. Wenn Sie die aktuelle Kontingentnutzung für Shuffle-Slots prüfen möchten, suchen Sie auf dem Tab Kontingente in der Tabelle die Zeile Shuffle-Slots und klicken Sie im Nutzungsdiagramm auf Nutzungsdiagramm anzeigen.

Wenn Sie Ihr Jobkontingent erhöhen möchten, wenden Sie sich an den Google Cloud-Support. Wir erhöhen das Limit dann auf einen Wert, der Ihren Anforderungen besser entspricht. Das Standardkontingent beträgt 25 gleichzeitige Dataflow-Jobs für Ihr Projekt oder 125 gleichzeitige Dataflow-Jobs für Ihre Organisation.

Sie können außerdem das Shuffle-Slotkontingent für Batchjobs erhöhen. Senden Sie dazu eine Supportanfrage und geben Sie die erwartete maximale Größe des parallelen Shuffle-Datasets für alle Jobs in Ihrem Projekt an. Führen Sie vor dem Anfordern eines zusätzlichen Shuffle-Kontingents Ihre Pipeline mit Dataflow Shuffle aus und prüfen Sie, wie viel Shuffle-Kontingent tatsächlich genutzt wird.

Wenn Sie Ihren Streaming Engine-Durchsatz für Streamingjobs erhöhen möchten, senden Sie eine Supportanfrage an den Google Cloud Platform-Support. Geben Sie in der Anfrage die maximale Datenmenge an, die unter Workern pro Minute für jede Region, in der Ihr Job ausgeführt wird, mit der Shuffle-Funktion umverteilt werden soll.

Der Dataflow-Dienst verwendet verschiedene Komponenten der Google Cloud, z. B. BigQuery, Cloud Storage, Pub/Sub und Compute Engine. Diese (und andere Google Cloud-Dienste) verwenden Kontingente, um die maximale Anzahl von Ressourcen zu begrenzen, die Sie in einem Projekt verwenden können. Wenn Sie Dataflow verwenden, müssen Sie gegebenenfalls Ihre Kontingenteinstellungen für diese Dienste anpassen.

Dataflow Prime

Für Dataflow und Dataflow Prime gelten dieselben Kontingente und Limits. Wenn Sie Kontingente für Dataflow haben, benötigen Sie kein zusätzliches Kontingent, um Ihre Jobs mit Dataflow Prime auszuführen.

Limits

In diesem Abschnitt werden die praktischen Limits für die Produktion in Dataflow beschrieben.

Limit Wert
Maximale Worker-Anzahl pro Pipeline 1.000
Maximale Größe für eine Joberstellungsanfrage. Pipelinebeschreibungen mit zahlreichen Schritten und langen Namen können dieses Limit erreichen. 10 MB
Maximale Größe für eine Vorlagenstartanfrage. 1 MB
Maximale Anzahl von Nebeneingabe-Shards 20.000
Maximale Größe für ein einzelnes Element, außer bei strengeren Bedingungen wie Streaming Engine). 2 GB
Maximale Schlüsselgröße in Batchpipelines. 1,5 MB
Maximale Anzahl von Logeinträgen pro Worker in einem bestimmten Zeitraum 15.000 Nachrichten alle 30 Sekunden
Maximale Anzahl benutzerdefinierter Messwerte pro Projekt 100
Dauer, unter der Empfehlungen gespeichert werden. 30 Tage
Streaming Engine-Limits Wert
Maximale Byte für Pub/Sub-Nachrichten. 7 MB
Maximale Größe für einen einzelnen Elementwert. 80 MB
Maximale Größe eines großen Schlüssels. Schlüssel über 64 KB führen zu einer geringeren Leistung. 2 MB
Maximale Größe für eine Nebeneingabe. 80 MB
Maximale Länge der von TagValue und TagBag verwendeten Zustands-Tags. 64 KB