univac
Desde la aparición de los grandes ordenadores (mainframes) siempre se han dividido las tareas que podían realizar en dos tipos muy bien diferenciados:

  • Online: necesita la participación de un usuario y realiza una transacción contra el sistema.
  • el batch: llamado también desatendido o proceso por lotes, no necesiba la intervención del usuario. Se ejecutaban varios programas en “cadenas” que podían durar horas.

Esto era así por el gran coste que tenía, o tiene, el uso de la CPU. Por eso se dividía el tiempo de la CPU en online y en batch, que tradicionalmente no se podían ejecutar simultáneamente. Es decir, se establecían una “ventana” de tiempo, por ejemplo de 8 de la tarde a 6 de la mañana, en el que online se apagaba y se ejecutaban exclusivamente procesos batch.

La llegada de la web y el 24/7

Sin embargo, con la llegada de las aplicaciones web, y su requisito de disponibilidad de 24/7 la cosa cambió. Ya no era posible, o era muy problemático, contar con estas ventanas exclusivas para el batch. Pensemos por ejemplo en un banco por internet. El usuario puede realizar sus operaciones, como un traspaso entre cuentas, a cualquier hora del día o de la noche (invadiendo la tradicional ventana batch). Por supuesto, hay que tener en cuenta que atender a la demanda online y ejecutar simultáneamente los procesos batch, provoca que ambos “compitan” por los recursos dela máquina, la memoria, la base de datos, etc. Es decir, es posible que el usuario tenga que esperar mucho tiempo o incluso se de un timeout, porque el batch ha cogido todos estos recursos.

Es por lo tanto necesario una profunda reflexión sobre la naturaleza del proceso batch. Hay quien dice directamente que el batch, tal como lo conocíamos, ha muerto. ¿por qué dicen esto? Es necesario antes una explicación.

Batch masivos y batch unitarios

Normalmente entendemos, o entendíamos, un batch como un proceso masivo, caracterizado por un gran acceso a datos. Un ejemplo de esto podría ser la generación de facturas de una operadora telefónica. Imaginemos un batch simple con los siguientes pasos:

  1. Se leen todas los registros de llamadas para un usuario de este mes
  2. Se calcula la suma de los costes de estas llamadas
  3. Se aplican descuentos

Estos tres pasos, si se tienen que ejecutar para 20 millones de clientes, se podrían partir atendiendo al acceso a datos. Es decir, en lugar de repetir estos tres pasos 20 millones de veces, se hace el primer paso los 20 millones de veces, luego el segundo paso otras tantas y así con el tercer paso. Con esto se consigue mejorar el acceso a los datos e incrementar el rendimiento.

El primer tipo se llamaría batch unitario, se ejecutan todos los pasos cada vez, y el segundo batch masivo, se ejecuta un paso todas las veces para luego pasar el siguiente. Este segundo tipo está unido al uso de ventanas de tiempo, ya que es muy intensivo en acceso a datos y CPU, recursos que podría quitar al online si se ejecutan simultáneamente.

Tenemos pues dos opciones para la facturación de esta empresa:

1.- reservamos una ventana batch de unas cuantas horas todos los finales de mes para hacer la facturación

2.- ejecutamos batch unitario, lógicas unitarias, cada cierto tiempo de igual manera que si fuera el online. Es decir, el sistema lanza una ejecución unitaria (los tres pasos) cada cierto intervalo de tiempo. Por ejemplo, si un día tiene 30 días * 24 horas * 60 minutos = 43200 minutos, unos 463 por minuto. Si somos capaces de realizar 463 operaciones de facturación por minuto, y además atender a la carga normal del online, al final de més, tendremos todas las facturas procesadas de la misma que con el batch tradicional, y sin tener que cerrar la aplicación para dar una ventana batch.

El cuello de botella del acceso a datos

Está demostrado, en la práctica, que el talón de aquiles de todo batch masivo es el acceso a datos. Cuando se procesan millones de registros es normal acceder a varias tablas de base de datos o ficheros y mover incluso TB de información. Es necesario por lo tanto optimizar al máximo este acceso.

Si reutilizamos la lógica de negocio online, que está pensada para una sóla transacción (lógica unitaria), una buena práctica sería sustituir el módulo de acceso a datos por otro que optimice estos accesos. Por ejemplo, si estamos haciendo la facturación de un cliente, en lugar de realizar una consulta para ese cliente, podemos acceder a los datos de 5000 clientes y guardarlos en memoria. La lógica unitaria seguirá trabajando con un solo registro, sin embargo, la siguiente ejecución de esta lógica ya no irá a base de datos (tendrá los datos precargados en memoria).

Por supuesto, para realizar esto, hay que tener una clara separación entre la lógica de negocio y la lógica de acceso a datos, siguiendo por ejemplo los patrones de diseño DAO o EAO

El batch en SOA

La ejecución de procesos en batch plantea una reflexión sobre el concepto tradicional de batch. Si se quiere reutilizar la lógica online (los servicios) y no volver a codificar la lógica de negocio otra vez, tendremos que establecer el mecanismo necesario para logar esta reutilización. Si la lógica de negocio está recogida en los servicios no quedará otro remedio que invocar a estos servicios en los procesos batch. Lógicamente, en este escenario, encaja mucho mejor el tipo de batch unitario. Es decir, se dispara un proceso planificado que obtiene los datos necesarios para invocar al servicio (los parámetros de entrada), invocará al servicio (puede ser millones de veces) y escribirá de nuevo los parámetros de salida (puede ser en un fichero o en una base de datos). En esta situación, deberíamos quizás hablar mejor de operaciones asíncronas que de procesos propiamente batch.

¿pero que pasa cuando los procesos batch son necesarios? Si tenemos una restricción temporal muy fuerte, por ejemplo, un proceso de actualización de nuestra cartera de clientes, que tiene que ejecutarse el último día del mes, de 2 a 6 de la mañana, tal vez el batch unitario no tenga el suficiente rendimiento. En este caso, estaremos ante una situación ventana batch en el que el sistema online se cerrará u operará con mucha dificultad. ¿podemos en este caso invocar a los servicios? Seguramente la respuesta será negativa.

Seguramente en este caso deberemos usar la lógica de negocio “desnuda”, sin la “parafernalia” del recubrimiento con web services. Estaremos perdiendo todas las ventajas inherentes a estos, como el desacoplamiento. En su lugar, se tendría que hacer una aplicación que invoque a la lógica de negocio online de manera masiva (con un acceso a datos altamente optimizado).

Comparte esta entrada…

Share