...
Nombre
...
Uso de Spring Batch
...
ID
...
A.ARQ.06
...
Versión
...
v 1.0.0
...
Licencia
...
Free
...
Área
...
Arquitectura
...
Fase
...
Lanzamiento
...
Tipo
...
Guía
...
Impacto
...
8 horas
Funcionalidad
...
| Table of Contents |
|---|
Introducción
Objetivos: Guía de uso para del desarrollo de casos de uso de procesamientos por lotes y/o en diferido.
Requisitos
...
: Necesitas Java 8, Maven 3+, Docker
Introducción
Pautas generales
Bloques de construcción y patrones para el procesamiento por lotes
Estrategias de procesamiento por lotes
1. Procesamiento normal en una ventana por lotes.
2. Procesamiento simultáneo por lotes o en línea.
3. Procesamiento en paralelo.
4. Particionamiento.
Proyecto de ejemplo de uso de Spring Batch
Introducción
¿Qué es Spring Batch?
Spring Batch es un marco de trabajo por lotes liviano e integral diseñado para permitir el desarrollo de aplicaciones de lotes robustas vitales para las operaciones diarias de los sistemas empresariales. Spring Batch se basa en las características de Spring Framework que la gente espera (productividad, enfoque de desarrollo basado en POJO y facilidad de uso general), al tiempo que facilita a los desarrolladores acceder y aprovechar servicios empresariales más avanzados cuando sea necesario. Spring Batch no es un marco de programación. Hay muchos buenos planificadores empresariales (como Quartz, Tivoli, Control-M, etc.) disponibles en los espacios comerciales y de código abierto. Su objetivo es trabajar en conjunto con un planificador, no reemplazar un planificador.
...
A continuación se proporciona una aproximación de uso y buenas prácticas a la hora de integrar un procesamiento por lotes en una aplicación Java mediante la utilización de Spring Batch.
Pautas generales
Los siguientes principios clave, pautas y consideraciones generales deben tenerse en cuenta al crear una solución por lotes.
Una arquitectura por lotes generalmente afecta la arquitectura en línea y viceversa. Hay que realizar el diseño teniendo en cuenta arquitecturas y entornos utilizando bloques de construcción comunes cuando sea posible.
Simplificar tanto como sea posible y evitar construir estructuras lógicas complejas en aplicaciones de un solo lote.
Mantener el procesamiento y el almacenamiento de datos físicamente juntos (en otras palabras, mantener sus datos donde se produce el procesamiento).
Minimizar el uso de recursos del sistema, especialmente E/S. Realizar tantas operaciones como sea posible en la memoria interna.
Revise la E/S de la aplicación para asegurarse de que se eviten las E/S físicas innecesarias. En particular, se deben buscar los siguientes cuatro defectos comunes:
Lectura de datos para cada transacción cuando los datos podrían leerse una vez y almacenarse en caché o mantenerse en el almacenamiento de trabajo.
Releer datos para una transacción en la que los datos se leyeron anteriormente en la misma transacción.
Causando escaneos innecesarios de tablas o índices.
No se especifican valores clave en la cláusula WHERE de una instrucción SQL.
Asignar suficiente memoria al comienzo de una aplicación por lotes para evitar la reasignación que consume mucho tiempo durante el proceso.
Asumir lo peor con respecto a la integridad de los datos. Insertar comprobaciones adecuadas y validación de registros para mantener la integridad de los datos.
Implementar sumas de verificación para validación interna cuando sea posible. Por ejemplo, los archivos planos deben tener un registro de avance que indique el total de registros en el archivo y un agregado de los campos clave.
Planificar y ejecutar pruebas de estrés lo antes posible en un entorno de producción con volúmenes de datos realistas.
En sistemas de lotes grandes, las copias de seguridad pueden ser un desafío, especialmente si el sistema se ejecuta simultáneamente con en línea constantemente. Si el sistema depende de archivos planos, los procedimientos de copia de seguridad de archivos no solo deben estar implementados y documentados, sino que también deben probarse regularmente.
Bloques de construcción y patrones para el procesamiento por lotes
Para ayudar a diseñar e implementar sistemas de lotes, se deben proporcionar bloques de construcción y patrones básicos de aplicaciones de lotes a los diseñadores y programadores en forma de gráficos de estructura de muestra y capas de código. Al comenzar a diseñar un trabajo por lotes, la lógica empresarial debe descomponerse en una serie de pasos que pueden implementarse utilizando los siguientes bloques de construcción estándar:
...
Flujo de ejemplo de procesamiento mediante varios steps
Estrategias de procesamiento por lotes
La base de cualquier sistema por lotes es la estrategia de procesamiento. Los factores que afectan la selección de la estrategia incluyen: volumen estimado del sistema de lotes, concurrencia con los sistemas en línea o con otros sistemas de lotes, ventanas de lotes disponibles. Las opciones de procesamiento típicas para el lote son (en orden creciente de complejidad de implementación):
Procesamiento normal fuera de línea.
Lote concurrente o procesamiento en línea.
Procesamiento en paralelo.
Particionamiento.
Una combinación de las opciones anteriores.
1. Procesamiento normal en una ventana por lotes.
Para procesos por lotes simples que se ejecutan en una ventana por lotes diferente donde los usuarios en línea u otros procesos por lotes no requieren los datos que se actualizan, la concurrencia no es un problema y se puede realizar una confirmación única en el Fin de la ejecución por lotes.
En la mayoría de los casos, un enfoque más robusto es más apropiado. Tenga en cuenta que los sistemas por lotes tienden a crecer a medida que pasa el tiempo, tanto en términos de complejidad como de los volúmenes de datos que manejan. Si no existe una estrategia de bloqueo y el sistema aún depende de un único punto de confirmación, modificar los programas por lotes puede ser doloroso. Por lo tanto, incluso con los sistemas por lotes más simples, considere la necesidad de una lógica de confirmación para las opciones de reinicio y recuperación, así como la información sobre los casos más complejos que se describen más adelante en esta sección.
2. Procesamiento simultáneo por lotes o en línea.
Las aplicaciones por lotes que procesan datos que los usuarios en línea pueden actualizar simultáneamente no deben bloquear ningún dato (ya sea en la base de datos o en los archivos) que los usuarios en línea puedan requerir por más de un pocos segundos. Además, las actualizaciones deben confirmarse en la base de datos al final de cada pocas transacciones. Esto minimiza la porción de datos que no está disponible para otros procesos y el tiempo transcurrido que los datos no están disponibles.
...
Estos patrones no son necesariamente adecuados para el procesamiento por lotes, pero podrían usarse para el procesamiento simultáneo por lotes y en línea (como en los casos en que la base de datos no admite el bloqueo a nivel de fila). Como regla general, el bloqueo optimista es más adecuado para aplicaciones en línea, mientras que el bloqueo pesimista es más adecuado para aplicaciones por lotes. Siempre que se use el bloqueo lógico, se debe usar el mismo esquema para todas las aplicaciones que acceden a entidades de datos protegidas por bloqueos lógicos.
3. Procesamiento en paralelo.
El procesamiento en paralelo permite que se ejecuten varios lotes o trabajos en paralelo para minimizar el tiempo total transcurrido de procesamiento por lotes. Esto no es un problema siempre que los trabajos no compartan los mismos archivos, tablas db o espacios de índice. Si lo hacen, este servicio debe implementarse utilizando datos particionados. Otra opción es construir un módulo de arquitectura para mantener las interdependencias mediante el uso de una tabla de control. Una tabla de control debe contener una fila para cada recurso compartido y si una aplicación la está utilizando o no. La arquitectura por lotes o la aplicación en un trabajo paralelo recuperaría información de esa tabla para determinar si puede acceder al recurso que necesita o no.
...
Otros problemas clave en el procesamiento paralelo incluyen el equilibrio de carga y la disponibilidad de recursos generales del sistema, como archivos, grupos de buffers de bases de datos, etc. También tenga en cuenta que la tabla de control en sí misma puede convertirse fácilmente en un recurso crítico.
4. Particionamiento.
El uso de particionamiento permite que varias versiones de aplicaciones de lotes grandes se ejecuten simultáneamente. El propósito de esto es reducir el tiempo transcurrido requerido para procesar trabajos por lotes largos. Los procesos que se pueden particionar con éxito son aquellos en los que el archivo de entrada se puede dividir y / o las tablas de la base de datos principal se pueden dividir para permitir que la aplicación se ejecute en diferentes conjuntos de datos.
Proyecto de ejemplo de uso de Spring Batch
A continuación se proporciona el enlace a otra página de Confluence, donde enlace donde puedes descargar un proyecto de ejemplo de Spring Batch que da el código a modo de ejemplo para la configuración básica de Spring Batch para un caso de uso sencillo, y la explicación del mismo.
...