Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Com o recurso Reequilíbrio dinâmico de trabalho do serviço Dataflow, o serviço reparticiona dinamicamente o trabalho baseado nas condições do ambiente de execução. Essas
condições podem incluir:
Desequilíbrio nas atribuições de trabalho
Workers levam mais tempo do que o estimado para finalizar
Conclusão dos workers antes do tempo estimado
O serviço Dataflow detecta automaticamente essas condições e
atribui dinamicamente o trabalho a workers não utilizados ou subutilizados para diminuir
o tempo de processamento geral do job.
Limitações
O rebalanceamento de trabalho dinâmico acontece apenas quando o serviço Dataflow está
processando dados de entrada em paralelo: ao ler dados de uma fonte de entrada
externa, trabalhar com uma PCollection intermediária materializada ou
trabalhar com o resultado de uma operação de agregação como GroupByKey. Se houver fusão de um grande número de etapas do job, ele terá menos PCollections intermediários, e o rebalanceamento dinâmico do trabalho será limitado aos número de elementos na origem materializada PCollection. Para que o
rebalanceamento de trabalho dinâmico seja aplicado a uma determinada
PCollection no pipeline, há algumas maneiras diferentes de evitar a fusão para
garantir o carregamento em paralelo dinâmico.
O reequilíbrio dinâmico de trabalho não pode atuar em dados mais refinados do que um registro único.
Se os dados contêm registros individuais que causam grandes atrasos no tempo de processamento, eles ainda podem atrasar o job. O Dataflow não pode
subdividir e redistribuir um registro individual "ativo" para vários workers.
Java
Se você definir um número fixo de fragmentos para a saída final do pipeline (por exemplo, gravação de dados usando TextIO.Write.withNumShards), o Dataflow limitará o carregamento em paralelo ao número de fragmentos escolhido.
Python
Se você definir um número fixo de fragmentos para a saída final do pipeline (por exemplo, gravação de dados usando beam.io.WriteToText(..., num_shards=...)), o Dataflow limitará o carregamento em paralelo ao número de fragmentos escolhido. do Google Analytics.
Go
Se você definir um número fixo de fragmentos para a saída final do pipeline, o Dataflow limitará o carregamento em paralelo ao número de fragmentos escolhido.
Como trabalhar com origens de dados personalizadas
Java
Se o pipeline usar uma fonte de dados personalizada fornecida por você,
implemente o método splitAtFraction para que ela funcione com o
recurso de rebalanceamento de trabalho dinâmico.
Se splitAtFraction for implementado incorretamente, os registros da fonte podem
aparecer duplicados ou descartados. Confira as
informações de referência da API sobre o RangeTracker se precisar de ajuda e dicas para
implementar splitAtFraction.
Python
Se o pipeline usar uma fonte de dados personalizada fornecida por você, seu
RangeTracker precisa implementar try_claim, try_split,
position_at_fraction e fraction_consumed para que ela funcione
com o recurso de rebalanceamento de trabalho dinâmico.
Se o pipeline usar uma fonte de dados personalizada fornecida por você,
implemente um RTracker válido para que ela funcione com o recurso de
rebalanceamento de trabalho dinâmico.
O rebalanceamento do trabalho dinâmico usa o valor de retorno do método getProgress() da sua origem personalizada para ser ativado. A implementação padrão para getProgress() retorna null. Para garantir que o escalonamento automático seja ativado, faça com que a fonte personalizada substitua getProgress() para retornar um valor apropriado.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
