• 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

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. 

Spring Batch proporciona funciones reutilizables que son esenciales en el procesamiento de grandes volúmenes de registros, incluidos el registro / rastreo, la gestión de transacciones, las estadísticas de procesamiento de trabajos, el reinicio de trabajos, la omisión y la gestión de recursos. También proporciona servicios y características técnicas más avanzadas que permiten trabajos por lotes de alto volumen y alto rendimiento a través de técnicas de optimización y partición. Spring Batch se puede usar tanto en casos de uso simples (como leer un archivo en una base de datos o ejecutar un procedimiento almacenado) como en casos de uso complejos y de alto volumen (como mover grandes volúmenes de datos entre bases de datos, transformarlo, etc.) en). Los trabajos por lotes de alto volumen pueden aprovechar el marco de una manera altamente escalable para procesar grandes volúmenes de información. 

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: 

• Aplicaciones de conversión: para cada tipo de archivo suministrado o generado a un sistema externo, se debe crear una aplicación de conversión para convertir los registros de transacciones suministrados en un formato estándar requerido para el procesamiento. Este tipo de aplicación por lotes puede consistir parcial o totalmente en módulos de utilidad de traducción (consulte Servicios de lotes básicos). 

• Aplicaciones de validación: Las aplicaciones de validación aseguran que todos los registros de entrada / salida sean correctos y consistentes. La validación generalmente se basa en encabezados y trailers de archivos, sumas de verificación y algoritmos de validación, y verificaciones cruzadas de nivel de registro. 

• Extraer aplicaciones: una aplicación que lee un conjunto de registros de una base de datos o archivo de entrada, selecciona registros basados en reglas predefinidas y escribe los registros en un archivo de salida. 

• Extraer / actualizar aplicaciones: una aplicación que lee registros de una base de datos o un archivo de entrada y realiza cambios en una base de datos o un archivo de salida impulsado por los datos encontrados en cada registro de entrada. 

• Procesamiento y actualización de aplicaciones: una aplicación que realiza el procesamiento de transacciones de entrada desde un extracto o una aplicación de validación. El procesamiento generalmente implica leer una base de datos para obtener los datos necesarios para el procesamiento, potencialmente actualizar la base de datos y crear registros para el procesamiento de salida. 

• Aplicaciones de salida / formato: aplicaciones que leen un archivo de entrada, reestructuran los datos de este registro de acuerdo con un formato estándar y producen un archivo de salida para imprimir o transmitir a otro programa o sistema. 

Además, se debe proporcionar un shell de aplicación básica para la lógica empresarial que no se puede construir utilizando los bloques de construcción mencionados anteriormente.  Cada aplicación puede usar uno o más de los pasos de utilidad estándar, como: 

• Ordenar: Un programa que lee un archivo de entrada y produce un archivo de salida donde los registros se han vuelto a secuenciar de acuerdo con un campo de clave de clasificación en los registros. Las clasificaciones generalmente las realizan las utilidades del sistema estándar. 

• Split: un programa que lee un solo archivo de entrada y escribe cada registro en uno de varios archivos de salida en función de un valor de campo. Las divisiones se pueden adaptar o realizar mediante utilidades de sistema estándar controladas por parámetros. 

• Fusionar: Un programa que lee registros de múltiples archivos de entrada y produce un archivo de salida con datos combinados de los archivos de entrada. Las fusiones se pueden adaptar o realizar mediante utilidades de sistema estándar controladas por parámetros. 

Las aplicaciones por lotes también se pueden clasificar por su fuente de entrada: 

• Las aplicaciones controladas por la base de datos están controladas por filas o valores recuperados de la base de datos. 

• Las aplicaciones controladas por archivos están controladas por registros o valores recuperados de un archivo. 

• Las aplicaciones controladas por mensajes son controladas por mensajes recuperados de una cola de mensajes. 

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): 

1. Procesamiento normal fuera de línea. 

2. Lote concurrente o procesamiento en línea.

3. Procesamiento en paralelo. 

4. Particionamiento. 

5. 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. 

• El bloqueo optimista supone una baja probabilidad de contención de registros. Por lo general, significa insertar una columna de marca de tiempo en cada tabla de base de datos utilizada simultáneamente por el procesamiento por lotes y en línea. Cuando una aplicación obtiene una fila para su procesamiento, también obtiene la marca de tiempo. A medida que la aplicación intenta actualizar la fila procesada, la actualización utiliza la marca de tiempo original en la cláusula WHERE. Si la marca de tiempo coincide, los datos y la marca de tiempo se actualizan. Si la marca de tiempo no coincide, esto indica que otra aplicación ha actualizado la misma fila entre la búsqueda y el intento de actualización. Por lo tanto, la actualización no se puede realizar. 

• El bloqueo pesimista es cualquier estrategia de bloqueo que asume que existe una alta probabilidad de contención de registros y, por lo tanto, es necesario obtener un bloqueo físico o lógico en el momento de la recuperación. Un tipo de bloqueo lógico pesimista utiliza una columna de bloqueo dedicada en la tabla de la base de datos. Cuando una aplicación recupera la fila para la actualización, establece una marca en la columna de bloqueo. Con la bandera en su lugar, otras aplicaciones que intentan recuperar la misma fila fallan lógicamente. Cuando la aplicación que establece el indicador actualiza la fila, también borra el indicador, permitiendo que otras aplicaciones puedan recuperar la fila. Tenga en cuenta que la integridad de los datos debe mantenerse también entre la búsqueda inicial y la configuración del indicador, por ejemplo, mediante el uso de bloqueos db.  Tenga en cuenta también que este método tiene el mismo inconveniente que el bloqueo físico, excepto que es algo más fácil de administrar creando un mecanismo de tiempo de espera que libera el bloqueo si el usuario va a almorzar mientras el registro está bloqueado. 

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. 

Si el acceso a los datos no es un problema, el procesamiento en paralelo se puede implementar mediante el uso de subprocesos adicionales para procesar en paralelo. En el entorno de mainframe, tradicionalmente se han utilizado clases de trabajo paralelas, para garantizar un tiempo de CPU adecuado para todos los procesos. En cualquier caso, la solución debe ser lo suficientemente robusta como para garantizar segmentos de tiempo para todos los procesos en ejecución. 

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 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.