Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Mit dem dynamischen Arbeitsausgleich kann der Dienst Arbeit basierend auf den Laufzeitbedingungen dynamisch neu partitionieren. Diese Bedingungen können Folgendes umfassen:
Ungleichgewichte bei Work-Zuweisungen
Längere Verarbeitungszeiten der Worker als erwartet
Kürzere Verarbeitungszeiten der Worker als erwartet
Der Dataflow-Dienst erkennt diese Bedingungen automatisch und kann Arbeit nicht verwendeten oder nicht ausgelasteten Workern dynamisch zuweisen. Dadurch verringert sich die gesamte Verarbeitungszeit des Jobs.
Beschränkungen
Der dynamische Work-Ausgleich erfolgt nur, wenn der Cloud Dataflow-Dienst einige Eingabedaten parallel verarbeitet. Dies ist der Fall, wenn Daten aus einer externen Eingabequelle gelesen werden oder eine materialisierte dazwischenliegende PCollection bzw. das Ergebnis einer Aggregation wie GroupByKey verwendet wird. Wenn eine größere Anzahl von Schritten im Job zusammengeführt wird, enthält der Job weniger dazwischenliegende PCollection-Vorgänge und der dynamische Arbeitsausgleich beschränkt sich auf die Anzahl der Elemente in der materialisierten Quellsammlung PCollection. Wenn Sie gewährleisten möchten, dass der dynamische Work-Ausgleich auf eine bestimmte PCollection in der Pipeline angewendet werden kann, damit die dynamische Parallelität gewahrt bleibt, können Sie auf verschiedene Methoden zurückgreifen, um die Zusammenführung zu verhindern.
Der dynamische Arbeitsausgleich kann keine Daten neu parallelisieren, die feiner als ein einzelnes Dataset sind.
Wenn einzelne Datasets in den Daten erhebliche Verzögerungen bei der Verarbeitung verursachen, kann sich die Jobausführung trotzdem verzögern. Der Grund dafür ist, dass Dataflow ein einzelnes aktives Dataset nicht auf mehrere Worker verteilen kann.
Java
Wenn Sie eine feste Anzahl von Fragmentierungen für die endgültige Ausgabe Ihrer Pipeline festlegen (z. B. durch Schreiben von Daten mit TextIO.Write.withNumShards), begrenzt Dataflow die Parallelisierung basierend auf der ausgewählten Anzahl der Fragmentierungen.
Python
Wenn Sie eine feste Anzahl von Fragmentierungen für die endgültige Ausgabe Ihrer Pipeline festlegen (z. B. durch Schreiben von Daten mit beam.io.WriteToText(..., num_shards=...)), begrenzt Dataflow die Parallelisierung basierend auf der ausgewählten Anzahl der Fragmentierungen.
Go
Wenn Sie eine feste Anzahl von Fragmentierungen für die endgültige Ausgabe Ihrer Pipeline festlegen, begrenzt Dataflow die Parallelisierung basierend auf der ausgewählten Anzahl der Fragmentierungen.
Benutzerdefinierte Datenquellen verwenden
Java
Wenn die Pipeline eine von Ihnen bereitgestellte benutzerdefinierte Datenquelle verwendet, müssen Sie die Methode splitAtFraction implementieren, damit die Quelle den dynamischen Arbeitsausgleich unterstützt.
Bei einer fehlerhaften Implementierung von splitAtFraction werden Datasets von der Quelle möglicherweise dupliziert oder verworfen. Hilfe und Tipps zur Implementierung von splitAtFraction finden Sie in der API-Referenz zu "RangeTracker".
Python
Wenn die Pipeline eine von Ihnen bereitgestellte benutzerdefinierte Datenquelle verwendet, müssen Sie für RangeTrackertry_claim, try_split, position_at_fraction und fraction_consumed implementieren, damit die Quelle den dynamischen Arbeitsausgleich unterstützt.
Wenn die Pipeline eine von Ihnen bereitgestellte benutzerdefinierte Datenquelle verwendet, müssen Sie eine gültige Methode RTracker implementieren, damit die Quelle den dynamischen Work-Ausgleich unterstützt.
Der dynamische Arbeitsausgleich verwendet den Rückgabewert der getProgress()-Methode Ihrer benutzerdefinierten Quelle zur Aktivierung. Die Standardimplementierung für getProgress() gibt null zurück. Achten Sie für die Aktivierung der automatischen Skalierung darauf, dass Ihre benutzerdefinierte Quelle getProgress() umgeht, um einen entsprechenden Wert zurückzugeben.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003eThe Dataflow service's Dynamic Work Rebalancing feature automatically redistributes work among workers based on runtime conditions such as work imbalances or varying processing times.\u003c/p\u003e\n"],["\u003cp\u003eDynamic work rebalancing is limited to parallel data processing stages, like reading from external sources or working with materialized \u003ccode\u003ePCollection\u003c/code\u003es, and is restricted by the number of elements or shards in those stages.\u003c/p\u003e\n"],["\u003cp\u003eIf you have custom data sources, dynamic work rebalancing requires implementing specific methods in your data source, such as \u003ccode\u003esplitAtFraction\u003c/code\u003e in Java or \u003ccode\u003etry_split\u003c/code\u003e and \u003ccode\u003eposition_at_fraction\u003c/code\u003e in Python, in order to function correctly.\u003c/p\u003e\n"],["\u003cp\u003eDynamic work rebalancing cannot further divide and redistribute a single record that is processing slower than the rest, potentially causing delays.\u003c/p\u003e\n"],["\u003cp\u003eSetting a fixed number of shards for your pipeline's output limits the parallelization that Dataflow can perform, thereby impacting the effectiveness of dynamic work rebalancing.\u003c/p\u003e\n"]]],[],null,["# Dynamic work rebalancing\n\nThe Dynamic Work Rebalancing feature of the Dataflow service allows the\nservice to dynamically repartition work based on runtime conditions. These\nconditions might include the following:\n\n- Imbalances in work assignments\n- Workers taking longer than expected to finish\n- Workers finishing faster than expected\n\nThe Dataflow service automatically detects these conditions and\ncan dynamically assign work to unused or underused workers to decrease\nthe overall processing time of your job.\n\nLimitations\n-----------\n\nDynamic work rebalancing only happens when the Dataflow service is\nprocessing some input data in parallel: when reading data from an external input\nsource, when working with a materialized intermediate `PCollection`, or when\nworking with the result of an aggregation like `GroupByKey`. If a large number\nof steps in your job are\n[fused](/dataflow/docs/pipeline-lifecycle#fusion_optimization), your job has fewer\nintermediate `PCollection`s, and dynamic work rebalancing is\nlimited to the number of elements in the source materialized `PCollection`. If\nyou want to ensure that dynamic work rebalancing can be applied to a particular\n`PCollection` in your pipeline, you can\n[prevent fusion](/dataflow/docs/pipeline-lifecycle#preventing_fusion) in a few\ndifferent ways to ensure dynamic parallelism.\n\nDynamic work rebalancing cannot reparallelize data finer than a single record.\nIf your data contains individual records that cause large delays in processing\ntime, they might still delay your job. Dataflow can't\nsubdivide and redistribute an individual \"hot\" record to multiple workers. \n\n### Java\n\nIf you set a fixed number of shards for the final output of your pipeline (for\nexample, by writing data using `TextIO.Write.withNumShards`),\nDataflow limits parallelization based on the number of\nshards that you choose.\n\n### Python\n\nIf you set a fixed number of shards for the final output of your pipeline (for\nexample, by writing data using `beam.io.WriteToText(..., num_shards=...)`),\nDataflow limits parallelization based on the number of\nshards that you choose.\n\n### Go\n\nIf you set a fixed number of shards for the final output of your pipeline,\nDataflow limits parallelization based on the number of shards\nthat you choose.\n| **Note:** The fixed-shards limitation can be considered temporary, and might be subject to change in future releases of the Dataflow service.\n\nWorking with Custom Data Sources\n--------------------------------\n\n### Java\n\nIf your pipeline uses a custom data source that you provide, you must\nimplement the method `splitAtFraction` to allow your source to work with the\ndynamic work rebalancing feature.\n| **Caution:** Using dynamic work rebalancing with custom data sources is an advanced use case. If you choose to implement `splitAtFraction`, it's critical that you test your code extensively and with maximum code coverage.\n\nIf you implement `splitAtFraction` incorrectly, records from your source might\nappear to get duplicated or dropped. See the\n[API reference information on RangeTracker](https://beam.apache.org/documentation/sdks/javadoc/current/index.html?org/apache/beam/sdk/io/range/RangeTracker.html) for help and tips on\nimplementing `splitAtFraction`.\n\n### Python\n\nIf your pipeline uses a custom data source that you provide, your\n`RangeTracker` must implement `try_claim`, `try_split`,\n`position_at_fraction`, and `fraction_consumed` to allow your source to work\nwith the dynamic work rebalancing feature.\n\nSee the\n[API reference information on RangeTracker](https://beam.apache.org/documentation/sdks/pydoc/current/apache_beam.io.iobase.html#apache_beam.io.iobase.RangeTracker)\nfor more information.\n\n### Go\n\nIf your pipeline uses a custom data source that you provide, you must\nimplement a valid `RTracker` to allow your source to work with the dynamic\nwork rebalancing feature.\n\nFor more information, see the [RTracker API reference information](https://pkg.go.dev/github.com/apache/beam/sdks/v2/go/pkg/beam/core/sdf#RTracker).\n\nDynamic work rebalancing uses the return value of the `getProgress()`\nmethod of your custom source to activate. The default implementation for `getProgress()` returns\n`null`. To ensure autoscaling activates, make sure your custom source overrides\n`getProgress()` to return an appropriate value."]]
