Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
La característica de rebalanceo dinámico de trabajos del servicio de Dataflow permite que el servicio vuelva a particionar de forma dinámica los trabajos en función de las condiciones del entorno de ejecución. Estas condiciones podrían incluir las que se mencionan a continuación:
Desbalances en asignaciones de trabajos
Trabajadores que tardan más de lo esperado en terminar
Trabajadores que terminan más rápido de lo esperado
El servicio de Dataflow detecta estas condiciones de forma automática y puede asignar trabajos de forma dinámica a los trabajadores sin usar o con poco uso para disminuir el tiempo de procesamiento general del trabajo.
Limitaciones
El rebalanceo dinámico de trabajos solo ocurre cuando el servicio de Dataflow procesa algunos datos de entrada en paralelo: cuando lee datos de una fuente de entrada externa, cuando trabaja con una PCollection materializada intermedia o cuando trabaja con el resultado de una agregación como GroupByKey. Si se fusionan una gran cantidad de pasos en tu trabajo, tu trabajo tiene menos PCollection intermedios y el rebalanceo dinámico de trabajos se limita a la cantidad de elementos en la fuente materializada PCollection. Si quieres asegurarte de que el rebalanceo dinámico de trabajos se pueda aplicar a una PCollection en particular en tu canalización, puedes evitar la fusión de diferentes maneras para garantizar un paralelismo dinámico.
El rebalanceo dinámico de trabajos no puede volver a paralelizar datos de forma más precisa que un solo registro.
Si tus datos contienen registros individuales que causan grandes demoras en el tiempo de procesamiento, es posible que demoren tu trabajo. Dataflow no puede subdividir y redistribuir un registro individual “activo” a varios trabajadores.
Java
Si configuras un número fijo de fragmentos para el resultado final de tu canalización (por ejemplo, si escribes datos con TextIO.Write.withNumShards), Dataflow limita la paralelización según la cantidad de fragmentos que elijas.
Python
Si configuras un número fijo de fragmentos para el resultado final de tu canalización (por ejemplo, si escribes datos con beam.io.WriteToText(..., num_shards=...)), Dataflow limita la paralelización según el número de fragmentos que elijas.
Go
Si estableces un número fijo de fragmentos para el resultado final de tu canalización, Dataflow limitará la paralelización según la cantidad de fragmentos que elijas.
Trabaja con fuentes de datos personalizadas
Java
Si en tu canalización se usa una fuente de datos personalizada que proporcionaste, debes implementar el método splitAtFraction para permitir que tu fuente funcione con la función de rebalanceo dinámico de trabajos.
Si implementas splitAtFraction de forma incorrecta, los registros de tu fuente pueden parecer duplicados o borrados. Consulta la información de referencia de la API sobre RangeTracker para obtener ayuda y sugerencias sobre la implementación de splitAtFraction.
Python
Si tu canalización usa una fuente de datos personalizada que proporcionaste, tu RangeTracker debe implementar try_claim, try_split, position_at_fraction y fraction_consumed para permitir que la fuente funcione con la función de rebalanceo dinámico de trabajos.
Si en tu canalización se usa una fuente de datos personalizada que proporcionaste, debes implementar un RTracker válido para permitir que la fuente funcione con la función de rebalanceo dinámico de trabajos.
El rebalanceo de trabajo dinámico usa el valor de muestra del método getProgress() de tu fuente personalizada para activarse. La implementación predeterminada para getProgress() muestra null. A fin de garantizar que se active el ajuste de escala automático, asegúrate de que la fuente personalizada anule getProgress() para mostrar un valor apropiado.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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."]]
