La función de restablecimiento dinámico del equilibrio de trabajo del servicio Dataflow permite al servicio volver a particionar el trabajo de forma dinámica en función de las condiciones de tiempo de ejecución. Estas condiciones pueden incluir lo siguiente:
- Desequilibrios en las tareas asignadas
- Los trabajadores tardan más de lo previsto en terminar
- Los trabajadores terminan antes de lo previsto
El servicio Dataflow detecta automáticamente estas condiciones y puede asignar trabajo de forma dinámica a los trabajadores que no se estén usando o que no se estén usando al máximo para reducir el tiempo de procesamiento general de tu tarea.
Limitaciones
El reequilibrio dinámico del trabajo solo se produce cuando el servicio Dataflow procesa algunos datos de entrada en paralelo: cuando lee datos de una fuente de entrada externa, cuando trabaja con un PCollection intermedio materializado o cuando trabaja con el resultado de una agregación como GroupByKey. Si se fusionan un gran número de pasos de tu tarea, esta tendrá menos PCollections intermedios y el reequilibrio dinámico del trabajo se limitará al número de elementos del PCollection materializado de origen. Si quieres asegurarte de que el reequilibrio dinámico del trabajo se pueda aplicar a un PCollection concreto de tu canal, puedes evitar la fusión de varias formas para asegurar el paralelismo dinámico.
El restablecimiento dinámico del equilibrio de trabajos no puede volver a paralelizar los datos con una granularidad inferior a un solo registro. Si sus datos contienen registros individuales que provocan grandes retrasos en el tiempo de procesamiento, es posible que sigan retrasando su tarea. Dataflow no puede subdividir y redistribuir un registro "activo" individual a varios trabajadores.
Java
Si defines un número fijo de particiones para el resultado final de tu canalización (por ejemplo, escribiendo datos con TextIO.Write.withNumShards), Dataflow limita la paralelización en función del número de particiones que elijas.
Python
Si defines un número fijo de particiones para el resultado final de tu canalización (por ejemplo, escribiendo datos con beam.io.WriteToText(..., num_shards=...)), Dataflow limita la paralelización en función del número de particiones que elijas.
Go
Si defines un número fijo de particiones para el resultado final de tu canalización, Dataflow limitará la paralelización en función del número de particiones que elijas.
Trabajar con fuentes de datos personalizadas
Java
Si tu canal usa una fuente de datos personalizada que proporcionas, debes implementar el método splitAtFraction para que tu fuente funcione con la función de reequilibrio dinámico del trabajo.
Si implementa splitAtFraction de forma incorrecta, es posible que los registros de su fuente se dupliquen o se pierdan. Consulta la información de referencia de la API sobre RangeTracker para obtener ayuda y consejos sobre cómo implementar splitAtFraction.
Python
Si tu flujo de trabajo usa una fuente de datos personalizada que proporcionas, tu RangeTracker debe implementar try_claim, try_split, position_at_fraction y fraction_consumed para que tu fuente funcione con la función de reequilibrio dinámico del trabajo.
Consulta más información en la referencia de la API sobre RangeTracker.
Go
Si tu canalización usa una fuente de datos personalizada que proporcionas, debes implementar un RTracker válido para que tu fuente funcione con la función de reequilibrio dinámico del trabajo.
Para obtener más información, consulta la referencia de la API RTracker.
El restablecimiento dinámico del equilibrio de trabajos usa el valor devuelto del método getProgress() de tu fuente personalizada para activarse. La implementación predeterminada de getProgress() devuelve null. Para asegurarte de que la función de escalado automático se activa, comprueba que tus anulaciones de origen personalizadas getProgress() devuelvan un valor adecuado.