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.
Consulta la información de referencia de la API sobre RangeTracker para obtener más información.
Go
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.
Si quieres obtener más información, consulta la información de referencia de la API de RTracker.
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.