Dataflow 서비스의 동적 작업 재균등화 기능을 사용하면 서비스에서 런타임 조건에 따라 동적으로 다시 작업 파티션을 나눌 수 있습니다. 이러한 조건에는 다음이 포함될 수 있습니다.
작업 할당의 불균형
작업자의 완료 시간이 예상보다 오래 걸림
작업자가 예상보다 빨리 완료
Dataflow 서비스는 이러한 조건을 자동으로 감지하여 사용되지 않거나 사용량이 적은 작업자에게 작업을 동적으로 할당하여 작업의 전체 처리 시간을 줄일 수 있습니다.
제한사항
동적 작업 재균등화는 Cloud Dataflow 서비스가 입력 데이터 일부를 동시에 처리 중인 경우에만 발생합니다. 즉, 외부 입력 소스에서 데이터를 읽는 경우, 구체화된 중간 PCollection으로 작업하는 경우, GroupByKey와 같은 집계의 결과에 대해 작업하는 경우에만 발생합니다. 작업의 많은 단계가 융합되면 작업의 중간 PCollection이 줄어들고 동적 작업 재균등화는 소스의 구체화된 PCollection의 요소 수로 제한됩니다. 동적 작업 재균등화를 파이프라인의 특정 PCollection에 적용할 수 있도록 하려면 몇 가지 동적 동시 처리 방법으로 융합을 방지하면 됩니다.
동적 작업 재균등화는 데이터를 단일 레코드보다 더 미세하게 다시 동시 처리할 수 없습니다.
데이터에 처리 시간을 크게 지연시키는 개별 레코드가 포함된 경우에도 작업이 지연될 수 있습니다. Dataflow는 개별 '핫' 레코드를 세분화하여 여러 작업자에게 재배포할 수 없습니다.
Java
파이프라인의 최종 출력에 고정된 수의 샤드를 설정하면(예: TextIO.Write.withNumShards를 사용하여 데이터 작성) Dataflow는 선택한 샤드 수에 따라 동시 처리를 제한합니다.
Python
파이프라인의 최종 출력에 고정된 수의 샤드를 설정하면(예: beam.io.WriteToText(..., num_shards=...)를 사용하여 데이터 작성) Dataflow는 선택한 샤드 수에 따라 동시 처리를 제한합니다.
Go
파이프라인의 최종 출력에 고정된 수의 샤드를 설정하면 Dataflow는 선택한 샤드 수에 따라 동시 처리를 제한합니다.
커스텀 데이터 소스 작업
Java
파이프라인에서 사용자가 제공한 커스텀 데이터 소스를 사용하는 경우 소스가 동적 작업 재균등화 기능을 사용하여 작업할 수 있도록 하려면 splitAtFraction 메서드를 구현해야 합니다.
splitAtFraction을 잘못 구현하면 소스의 레코드가 복제되거나 삭제된 것으로 보일 수 있습니다. splitAtFraction 구현에 대한 도움말과 팁은 RangeTracker에 대한 API 참조 정보를 참조하세요.
Python
파이프라인에서 사용자가 제공한 커스텀 데이터 소스를 사용하는 경우 소스가 동적 작업 재균등화 기능을 사용하여 작업할 수 있도록 하려면 RangeTracker에서 try_claim, try_split, position_at_fraction, fraction_consumed 메서드를 구현해야 합니다.
동적 작업 재균등화는 커스텀 소스의 getProgress() 메서드의 반환 값을 사용하여 활성화됩니다. getProgress()의 기본 구현은 null을 반환합니다. 자동 확장을 활성화하려면 커스텀 소스가 getProgress()를 재정의하여 적절한 값을 반환해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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."]]
