tag lib form spring parallel-processing spring-batch scalability

lib - La mejor estrategia de escalado de lotes Spring



tag lib jstl (1)

Tenemos procesos por lotes simples que funcionan bien. Recientemente, tenemos un nuevo requisito para implementar un nuevo proceso por lotes para generar informes. Tenemos diferentes fuentes de datos para leer para preparar estos informes. Específicamente, podríamos tener una vista para cada informe.

Ahora queremos escalar este proceso de tal manera que se pueda escalar y completar lo antes posible.

Estoy familiarizado con el paso de varios subprocesos pero no estoy seguro acerca de otra estrategia (fragmentación remota y paso de partición) y cuál usar cuando.

En nuestro caso, procesar + escribir en un archivo es más incentivo de recursos que lectura.

En tales casos, qué enfoque es el más adecuado.

O si descubrimos que leer datos de db es el mismo incentivo de recursos que escribir + procesar para archivar, entonces ¿cuál es la mejor opción para mejorar / escalar este proceso?


TLDR;

Según su descripción, creo que podría probar el paso de subprocesos múltiples con el lector sincronizado, ya que menciona que el procesamiento y la escritura son la parte más costosa de su paso.

Sin embargo, dado que su lector es una base de datos, creo que obtener un paso particionado configurado y funcionando sería muy beneficioso. Se necesita un poco más de trabajo para prepararse, pero se escalará mejor a largo plazo.

Paso de múltiples hilos

Usar para:

  • Acelerando un paso individual
  • Cuando el equilibrio de carga puede ser manejado por el lector (es decir, JMS o AMQP)
  • Al usar un lector personalizado que particione manualmente los datos que se leen

No usar para:

  • Lectores de artículos con estado

Los pasos con múltiples subprocesos utilizan el procesamiento orientado a fragmentos empleado por Spring Batch. Cuando multiplique un paso por un paso, permite que el lote de primavera ejecute un fragmento completo en su propio hilo. Tenga en cuenta que esto significa que todo el ciclo de lectura-proceso-escritura para sus fragmentos de datos ocurrirá en paralelo. Esto significa que no hay un orden garantizado para procesar sus datos. También tenga en cuenta que esto no funcionará con los lectores de artículos con estado ( JdbcCursorItemReader y JdbcPagingItemReader son ambos con estado).

Paso de múltiples subprocesos con lector sincronizado

Usar para:

  • Acelerar el procesamiento y la escritura para un paso individual
  • Cuando se lee con estado

No usar para:

  • Acelerando la lectura

Existe una forma de evitar la limitación de no poder usar pasos de subprocesos múltiples con lectores de elementos con estado. Puede synchronize su método de read() . Esto esencialmente hará que las lecturas sucedan en serie (sin embargo, todavía no hay garantía de pedido) pero aún permite que el procesamiento y la escritura se realicen en paralelo. Esta puede ser una buena opción cuando leer no es el cuello de botella, sino el procesamiento o la escritura.

Particionamiento

Usar para:

  • Acelerando un paso individual
  • Cuando se lee con estado
  • Cuando los datos de entrada pueden ser particionados

No usar para:

  • Cuando los datos de entrada no pueden ser particionados

La partición de un paso se comporta ligeramente diferente de un paso de múltiples subprocesos. Con un paso particionado, en realidad tiene StepExecutions completamente distintos. Cada StepExecution funciona en su propia partición de datos. De esta forma, el lector no tiene problemas para leer los mismos datos porque cada lector solo está mirando un segmento específico de los datos. Este método es extremadamente potente, pero también es más complicado de configurar que un paso de múltiples subprocesos.

Chunking Remoto

Usar para:

  • Acelerar el procesamiento y la escritura para un paso individual
  • Lectores con buen estado

No usar para:

  • Acelerando la lectura

La fragmentación remota es un uso muy avanzado del lote de primavera. Requiere tener algún tipo de middleware duradero para enviar y recibir mensajes (es decir, JMS o AMQP). Con la fragmentación remota, la lectura sigue siendo de un solo subproceso, pero a medida que se lee cada fragmento se envía a otra JVM para su procesamiento. En la práctica, esto es muy similar a cómo funciona un paso de subprocesos múltiples, sin embargo, la fragmentación remota puede utilizar más de un proceso en lugar de más de un subproceso . Esto significa que la fragmentación remota le permite escalar horizontalmente su aplicación en lugar de escalar verticalmente . (TBH, creo que si está pensando en implementar fragmentación remota, debería considerar echar un vistazo a algo como Hadoop).

Paso paralelo

Usar para:

  • Acelerando la ejecución general del trabajo
  • Cuando hay pasos independientes que no dependen el uno del otro

No usar para:

  • Acelerando la ejecución del paso
  • Pasos dependientes

Los pasos paralelos son útiles cuando tiene uno o más pasos que se pueden ejecutar de forma independiente. Spring Batch puede permitir fácilmente que los pasos se ejecuten en paralelo en hilos separados.