In diesem Dokument sind die für Dataflow geltenden Kontingente und Limits aufgeführt.
Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.
Das Cloud-Kontingentsystem ermöglicht Folgendes:
- Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
- Ihren Verbrauch dieser Ressourcen einschränken
- Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.
Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
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
- Dataflow-Batchjobs werden nach 10 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: In den folgenden Regionen sind die Standardmaschinentypen für Dataflow
n1-standard-1
für Batch-Jobs,n1-standard-2
für Jobs mit Streaming Engine undn1-standard-4
für Streamingjobs ohne Streaming Engine undn1-standard-2
für Jobs, die Flexible Resource Scheduling (FlexRS) verwenden. FlexRS verwendet zu 90% VMs auf Abruf und zu 10% normale VMs.asia-east1
asia-east2
asia-northeast1
asia-northeast2
asia-northeast3
asia-south1
asia-south2
asia-southeast1
asia-southeast2
australia-southeast1
australia-southeast2
europe-central2
europe-north1
europe-west1
europe-west2
europe-west3
europe-west4
europe-west5
europe-west6
northamerica-northeast1
northamerica-northeast2
southamerica-east1
us-central1
us-central2
us-east1
us-east4
us-west1
us-west2
us-west3
us-west4
Für andere Regionen sind die Standardmaschinentypen
e2-standard-2
für Batch-Jobs,e2-standard-2
für Jobs mit Streaming Engine,e2-standard-4
für Streamingjobs ohne Streaming Engine unde2-standard-2
für Jobs, die FlexRS verwenden.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. Eine Zuordnung von Maschinentypen zur CPU-Anzahl finden Sie unter Compute Engine-Maschinentypen. - 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
- Wenn verwaltete Instanzgruppen für einen Streamingjob länger als 7 Tage fehlen, wird der Job abgebrochen.
- Wenn verwaltete Instanzgruppen für einen Batchjob länger als eine Stunde fehlen, wird der Job abgebrochen.
Zusätzliche Kontingente
Je nachdem, welche Quellen und Senken Sie verwenden, benötigen Sie möglicherweise auch zusätzliche Kontingente.
- 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.
- 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:
- Gehen Sie in der Google Cloud Console zur Seite APIs & Dienste.
APIs & Dienste aufrufen - 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 | 2.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 | Betrag |
---|---|
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 |