Particularidades de los ciclos de proceso
Por
razones históricas, desde el inicio de la era de los mainframes los ciclos
online y batch quedaron muy separados. Las condiciones que determinaron esta
separación fueron:
- El
cumplir con el modelo básico de proceso (entrada de datos, proceso de
datos, salida de datos)
- El
hecho de que toda la información a procesos entraba por terminales u otros
dispositivos en el estricto horario de atención a clientes en las oficinas
- La
no existencia de procesos online fuera del horario de oficina, tales como
la banca por Internet o los cajeros automáticos
- La
potencia limitada de los sistemas de bases de datos de aquella época menos
orientados a la concurrencia que los actuales
- El
bajo nivel de automatización de procesos de la época (aún existiendo
ordenadores, las empresas hacían muchos procesos manuales y solo dejaban
al mainframe los mayores volúmenes de datos)
- El
coste de procesamiento de datos era muy elevado entonces (se encarecía por
la instalación, el consumo de electricidad, el coste del almacenamiento,
la programación prácticamente realizada por expertos, etc.)
¿Cómo
ha cambiado este escenario en la actualidad?
- El
crecimiento a 24x7 de la ventana online. La información a procesos entra
de manera multicanal (oficinas, Internet, Mobile) a cualquier hora del día
y en cualquier fecha
- Los
sistemas de base de datos son muy potentes y soportan una gran
concurrencia de usuarios
- El
alto nivel de automatización de los procesos de banca
- Costes
mas asequibles para el procesamiento de datos (aunque mantener un
mainframe sigue siendo caro, hoy hablamos de MIPS, gigabytes y fibra
óptica cuando hace años hablábamos en megabytes y cable de cobre)
Las
dos únicas particularidades que continúan a pesar de estos cambios son:
- El
procesamiento online se aplica por lo general a un único cliente aunque
concurran muchos clientes a lo largo de la ventana online o fuera de ella
para realizar operaciones. El tiempo de proceso es corto y la respuesta al
usuario casi inmediata independientemente del canal que se utilice
- El
procesamiento batch de aplica por lo general a muchos los clientes de
manera masiva resultando en un uso intenso y continuado de recursos
(memoria, disco, procesador) que puede demorar horas en ocasiones.
Los
sistemas frontales, combinados con los sistemas transaccionales permiten
mantener unos tiempos de respuesta adecuados para los clientes.
El
único ciclo que por sus características puede influenciar de manera
significativa en la ventana online, alterando estos tiempos de respuesta, es el
ciclo o ventana batch.
Al
alterar los tiempos de respuesta de la ventana online, provocando en ocasiones
bloqueos de tablas, caídas de transacciones y respuesta errónea a las acciones
del usuario, podemos considerar que esta influencia es negativa.
Influencia negativa de la ventana batch sobre la
online
¿Cuál
es la principal influencia negativa del ciclo batch sobre el ciclo online?
La
principal influencia negativa del ciclo batch sobre el online está en los
recursos compartidos, especialmente en las bases de datos.
Vamos
a explicar esta influencia negativa en las bases de datos con ejemplos.
Ejecución de transacciones en ventana online
De
manera muy simple cada una de las transacciones que se ejecutan en la venta
online demora un tiempo t1. Durante ese tiempo t1, imaginemos que determinadas
tablas quedan bloqueadas un tiempo b1.
Una
vez que la transacción termina, tanto exitosamente con un COMMIT que grabe la
información de manera permanente en la base de datos, como con un ROLLBACK con
lo cuál la información es descartada, se produce un tiempo T durante el cuál el
sistema de gestión de base de datos queda libre para aceptar nuevas peticiones
transaccionales.
Si
hay muchas transacciones durante por ejemplo, un horario pico de trabajo o un
fin de mes, la gráfica quedaría como sigue:
Si
hay pocas transacciones, por ejemplo en horas de la madrugada o un domingo al
mediodía, la gráfica quedaría como sigue:
Mientras
mayor sea el tiempo T entre una transacción y otra, mayor posibilidad hay de
atender más operaciones en el sistema transaccional y menos probabilidades
existen de bloqueo de las tablas y de errores de timeout o caídas del sistema.
Ejecución transaccional en procesos batch
A
pesar de que asociamos el término transacciones con la ventana online, en batch
desde el punto de vista de bases de datos se ejecutan también procesos
transaccionales.
Recordamos
que una transacción, en el sentido amplio de la palabra, es un proceso que se
ejecuta en términos de todo o nada, o sea solo prospera si prosperan cada uno
de sus procesos componentes de manera estricta. Si falla uno de ellos, falla
todo el proceso.
Como
grabar o persistir la información en las
bases de datos es un proceso costoso en tiempo y procesador, se suele realizar
por lotes o grupos (de ahí la palabra batch o lote).
Para
ello se guarda toda la información a persistir en un área de memoria y cuando
se ejecuta la sentencia COMMIT esta área es persistida permanentemente en el
almacenamiento del gestor de bases de datos.
Si
se ejecuta una sentencia ROLLBACK, simplemente se libera la memoria que ocupa
esta área perdiéndose los datos.
Si
por alguna casualidad se interrumpe la unidad de ejecución, tanto en online como
en batch, de manera automática se ejecuta un ROLLBACK.
Como
en batch las transacciones se ejecutan por lotes y en un bucle de proceso (no
vienen espaciadas en tiempo ni de forma aleatoria o esporádica como las
transacciones online que dependen incluso de la hora del día), las
transacciones se ejecutan muy rápidamente con un tiempo T entre transacciones
prácticamente despreciable:
La
consecuencia de disminuir el tiempo T altera la respuesta de sistema provocando
que disminuyan drásticamente las probabilidades de que entre una transacción y
otra, el gestor pueda atender otras peticiones que le llegan de manera
asincrónica. Esto se traduce en un bloqueo prácticamente permanente en la tabla
que estamos actualizando.
Para
intentar, al menos que esta posibilidad “exista”, cuando hay muy pocos
registros a procesar en batch se realiza un COMMIT por cada uno de ellos. Esto
permite que aunque el proceso de persistencia de datos sea más costoso, la
afectación será mínima dado el número limitado de registros.
Para
reducir el coste del proceso de persistencia, lo práctico es ejecutar un COMMIT
cada cierto número de sentencias que modifican la información en la base de
datos:
En
esta gráfica vemos como se ejecutan cinco operaciones durante las cuáles la
tabla está bloqueada, luego un COMMIT y luego existe un tiempo T en el cuál el
gestor de base de datos podría aceptar otra operación. Las últimas dos
operaciones se persisten con un COMMIT final puesto que el total no es múltiplo
de cinco.
Este
es el enfoque habitual a utilizar en grandes volúmenes de datos. Mientras mayor
sea el total de registros a procesar, mayor suele ser el número de operaciones
para agrupar en un COMMIT con tal de reducir el coste de la operación y mayor
el tiempo b1 durante el cuál la tabla permanece bloqueada.
¿Qué
ocurre cuando tenemos que realizar operaciones batch en ventana online?
Ante
todo dejamos claro que en las actuales condiciones, siempre tendremos procesos
online en la ventana batch debido al carácter 24x7 de muchos procesos.
De
lo que se trata es de minimizar el impacto del procesamiento masivo sobre los
procesos online.
El
hecho de que estos procesos se ejecuten por la madrugada obedece no solo a que
no hay horario de oficinas, sino también a que el grueso de las operaciones
24x7 que se ejecutan por los canales Internet y Mobile disminuyen a cierta por
la simple lógica que los usuarios tienen que dormir.
La
siguiente gráfica muestra la distribución de la carga en 24 horas, destacando
la parte online (violeta) y la batch (rojo).
El
cuadro azul está surcando las barras moradas que representan la mayor carga de
CPU producida por el CICS entre las 7:30 y las 18:30 horas.
Sin
embargo esta carga disminuye notablemente a partir de las 20:30 y llega a
niveles muy bajos de madrugada, entre las 0:00 y las 06:30 horas.
Los
cuadros rojos enmarcan las barras rojas, mostrando como la capacidad de proceso
a esas horas es sustituida por el batch.
Vemos
la influencia que pueden tener los procesos batch (sobre todo los que utilizan
bases de datos) sobre la ventana online:
En
esta gráfica superponiendo las ejecuciones batch y las online vemos que durante
el tiempo b1 que duran los bloqueos batch las operaciones online están
condenadas a esperar. Si este tiempo b1 supera el tiempo de respuesta t1 de una
transacción online se producirá un error de timeout llegándole a los usuarios
un error que enmascara que el sistema no puede procesar los datos de su
transacción.
De
ahí la tremenda importancia de intentar por todos los medios minimizar el
impacto de la ventana batch sobre las operaciones online.
Si
ejecutamos las mismas operaciones batch en el momento del día que hay menos
probabilidades de operaciones online la gráfica anterior pudiera ser muy
diferente:
En
el peor de los casos si existe algún error grave de bloqueo de tablas, se
perdería una mínima cantidad de las operaciones online siempre invitando al
usuario a intentarlo de nuevo.
Características de las operaciones online
Las
operaciones online, tienen determinadas características:
- El
usuario de una operación online espera una respuesta en un breve espacio
de tiempo
- Una
operación online por lo general trata datos relacionados con un único
usuario (o pocos usuarios intervinientes). En cualquier caso el volumen de
datos a tratar es muy poco y los bloqueos de tabla ocurren en un tiempo
ínfimo
- Una
operación online puede ser multicanal, o sea, se puede ejecutar a través
de diferentes canales como el teleproceso de oficinas, Internet o Mobile.
Aunque el la capa de datos y la capa de proceso de datos son las mismas la capa de presentación cambia
según el canal por el que estamos accediendo
- Las
operaciones online que introducen o modifican datos lo hacen en el momento
(los datos son persistidos en el gestor de base de datos si la transacción
prospera)
- Las
operaciones online que consultan datos están limitadas a un volumen
limitado de información o a utilizar recursos de software como la
paginación (cargar páginas o subconjuntos de datos en los que se puede
navegar)
- Los
errores de datos pueden verse y tratarse en el momento en que se realiza
la operación
Características de las operaciones batch
Las
operaciones batch se caracterizan por:
- El
usuario de una operación batch espera una respuesta diferida. Esta
respuesta puede llegar en el orden de horas, al día siguiente e incluso en
fechas marcadas como por ejemplo un informe mensual no lo podemos ver
hasta que la información no haya sido consolidada mensualmente
- Una
operación batch por lo general trata datos de cientos o miles de usuarios.
En la gran mayoría de los casos el volumen de datos es grande e incluso
muy grande si se tratan datos históricos
- Las
operaciones batch se ejecutan por lo general de dos formas diferentes: de
manera esporádica o a petición o en fechas/horas concretas lanzadas por el
planificador CTRL-M
- Las
operaciones batch solo tienen capa de datos y capa de proceso. No poseen
capa de presentación que interacciona con los usuarios, por lo que la
definición de canales que está asociada con esta última no tiene sentido
- En
una operación batch típica, miles de datos de entrada son transformados en
miles de datos de salida y en un conjunto de datos rechazados por error
- Los
errores de datos no pueden ser tratados en tiempo de proceso. Los datos
erróneos solo pueden rechazarse.
Diseño de un proceso online ideal
El
siguiente esquema muestra el diseño de un proceso online ideal:
En
este esquema separamos claramente dos entornos: los canales del mainframe.
Dentro del mainframe está el sistema transaccional de IBM denominado CICS
destinado a ejecutar procesos invocados desde los diferentes canales.
Estos
procesos consumen y modifican información de negocio almacenada en base de datos
y a su vez persisten posibles errores.
Los
usuarios de cualquiera de los canales introducen información de sus
operaciones y reciben una respuesta que
puede ser el resultado esperado o un error.
Los
errores son persistidos en una base de datos donde luego puedan ser
consultados.
Diseño de un proceso batch ideal
El
siguiente esquema muestra el diseño de un proceso batch ideal:
El
proceso batch durante su ejecución recupera y actualiza datos de negocio en
bases de datos. Opcionalmente puede consumir también información de negocio de
ficheros de entrada y escribir la
información procesada en ficheros de salida. Los registros o filas que no
pudieron ser procesados por problemas de validación se rechazan en un fichero
diferente.
Por
último, cualquier proceso batch debería de dejar información en la clase de
salida de mensajes que permita dos cosas:
- Verificar
que realmente ha sido procesada la información de entrada (contadores de
registros de entrada, registros de salida y registros rechazados)
- Información
que permita clarificar un error catastrófico que ha provocado la
interrupción del proceso
Ambas
informaciones son útiles tanto para los operadores de procesos del mainframe,
como para los analistas y desarrolladores.
0 comentarios:
Publicar un comentario