Integración de datos en línea

Por Juan Vicenteño
Publicado en diciembre 2011

En épocas en la que la información crece de manera exponencial, la Inteligencia de Negocios (BI) se vuelve en un factor importante al buscar integrar altos volúmenes de transaccionalidad de bases de datos heterogéneas. Algunas operaciones de negocios requieren de conocimiento basado en los datos más actuales que permiten a los altos directivos tomar acciones de manera inmediata sobre información veraz y oportuna. Para mejorar la eficiencia operativa, las empresas están tratando de crear una infraestructura de BI robusta que utilice información operativa y oportuna, pero manteniendo el contexto histórico.

Competir eficazmente en medio de crecientes expectativas de los clientes requiere de BI basada en información oportuna y precisa. Sin embargo, el tradicional “extract, transform and load” (ETL), utilizado por la mayoría de las organizaciones, depende de procesos Batch (para extraer los datos de los sistemas productivos) los cuales son ejecutados en “horas no pico” para no tener un impacto sobre los sistemas transaccionales. El crecimiento exponencial del volumen de transacciones de datos y la necesidad de proporcionar acceso continuo a los sistemas de BI, hacen de estos procesos Batch soluciones cada vez menos eficaces en la creación y mantenimiento de un entorno de BI completo y fiable.

A medida que pasa el tiempo, los datos se vuelven menos valiosos. Las empresas están empezando a darse cuenta del valor de saber acerca de los acontecimientos que ocurrieron recientemente, hace unos segundos. Están buscando más información oportuna para mejorar las operaciones y servicio al cliente, a sabiendas de que tales mejoras les genera una ventaja competitiva más fuerte y eventualmente mayores ganancias.

Los sistemas que utilizan procesos Batch suelen examinar tablas de las bases de datos origen y crear un archivo por lotes para cargarlo en la base de datos destino. Este tipo de proceso de extracción crea una sobrecarga en los sistemas origen que eventualmente creará un alto impacto de procesamiento en dichos sistemas. Además, para garantizar la coherencia de lectura durante el proceso de extracción, este enfoque requiere una extensa codificación sobre los sistemas origen lo que significa que la extracción normalmente se debe realizar en horas donde los sistemas transaccionales no se vean afectados (generalmente por la noche).

Durante muchos años, el procesamiento por lotes era suficiente para satisfacer las necesidades de BI. Sin embargo, con el crecimiento de la Internet, los consumidores realizan transacciones comerciales y esperan un acceso a los servicios 24X7. Esto ha eliminado efectivamente el concepto de extracción durante "horas no pico". Como resultado, los procesos Batch tienden a desaparecer pues la cantidad de datos que se deben procesar es cada vez mayor.

Ante este dilema, los departamentos de TI deben emplear operaciones altamente eficaces para tratar de resolver los problemas que implican los procesos Batch (problemas en tiempo y funcionamiento). Existen varias opciones para hacer frente a este desafío, con especial hincapié en aumentar los sistemas de ETL. Aquí se muestran tres posibles soluciones:

1.- Personalizar el sistema de ETL para extraer múltiples lotes a lo largo del día.


Con la opción de personalizar un sistema de ETL para extraer múltiples lotes durante el día, hace que la extracción de los datos sobre los sistemas fuentes se haga varias veces durante el día, por ejemplo cada cuatro o seis horas. Con este escenario se aprovecha la tecnología ETL que ya se tenía pero además permite a las organizaciones tener la información ya no del día anterior sino de hace cuatro horas, lo que les brinda información más oportuna.

Sin embargo, en este escenario, el sistema de ETL debe realizar análisis completos sobre las bases de datos de producción con más frecuencia. Debido a la sobrecarga que puede generar dicho análisis, pueden tener un impacto negativo en sistemas empresariales de misión crítica, especialmente durante las horas pico. Además, la sobrecarga al extraer la información puede requerir costosas actualizaciones de hardware para los sistemas origen. Y qué decir del tiempo, una frecuencia de cada cuatro o seis horas es una mejora respecto a procesos Batch de cada 24 horas, pero al final del día no es información en línea.

2.- Personalizar el sistema de ETL para extraer sólo los datos que han cambiado.


Algunas organizaciones han intentado minimizar la latencia de los datos tratando de dar más inteligencia a los sistemas de ETL. En este enfoque, en lugar de extraer el contenido completo de una base de datos y la entrega a otro, el sistema captura y entrega sólo los datos modificados. Esto se traduce en datos actualizados (en vez de datos suministrados a través del procesamiento por lotes diarios o en horas), y causa menos sobrecarga de la red porque se mueve menos datos a la vez.

Sin embargo, esta opción requiere una considerable modificación de las bases de datos existentes y las tareas del ETL. A menudo, los datos adicionales, tales como “sellos de tiempo”, tendrían que añadir una bandera para determinar si ha habido cambios desde la última consulta. La mayoría de las bases de datos no fueron diseñadas para este tipo de ajustes, y realizar cambios en el esquema de la base de datos puede generar problemas para las aplicaciones. También podría suponer una carga para los sistemas de producción ya que las consultas complejas, que deben ser ejecutados a través de la base de datos, se harán con frecuencia durante todo el día.

Debido al tiempo necesario para ejecutar las consultas de los datos modificados y realizar el resto de la tramitación a través de un sistema que está optimizado para procesar los datos en lotes, este método no es capaz de proporcionar los datos modificados en línea.

3.- Aumentar el sistema ETL con una solución “Change Data Capture” (CDC).


Para las empresas que deciden aprovechar sus inversiones sobre su ETL, aumentar la capacidad de éste a través de una solución CDC puede ser la mejor opción. Una solución CDC puede alimenta el sistema ETL con un flujo continuo de datos en línea que no sólo reduce la latencia de los datos para los sistemas de BI sino que también elimina la dependencia de los procesos Batch permitiendo así una operación continua en los sistemas productivos.

Aunque tecnologías para mover datos en línea pueden resultar en cierto momento costosas, estudios recientes muestran que, en muchos casos, el costo de propiedad (TCO) se ve beneficiado pues no es necesario gastar en implementaciones para mejorar el funcionamiento del ETL, así como los costos de Hardware que pueden presentarse al momento de requerir más poder de cómputo en los sistemas transaccionales por cuestiones de rendimiento1. Por tal motivo, aumentando un sistema de ETL existente con la tecnología de un CDC es una opción viable para la mayoría de las organizaciones que operan sistemas de ETL, que ofrece todas las ventajas descritas en el párrafo anterior sin desventajas.

Al aumentar un sistema de ETL con una solución de CDC, el sistema combinado debe cumplir una lista de requisitos estrictos para proporcionar el máximo rendimiento y beneficio:

Alto rendimiento y captura de datos modificados en línea: el sistema CDC debe ser capaz de proporcionar datos en tiempos de hasta “milisegundos”, incluso con grandes volúmenes de datos, a fin de mantener el movimiento de datos en línea.

Soporte para fuentes de datos heterogéneos: el sistema CDC debe ser capaz de soportar la captura y entrega a través de diferentes bases de datos y plataformas.

Compatible con formatos de datos: el sistema de CDC debe ser capaz de proporcionar los datos en un formato que el sistema de ETL pueda leer fácilmente. Algunos se han optimizado para leer los archivos de proceso por lotes, otros pueden leer los datos binarios, y otros podrían funcionar mejor con tablas de base de datos.

Un control robusto de programación de procesos Batch: el sistema CDC debería permitir a los usuarios controlar el tamaño del lote, que les permita crear lotes tan cortos como ellos decidan (por ejemplo, enviar lotes por cada minuto de tiempo). El sistema debe ser capaz de alertar al ETL cuando un nuevo lote está listo para su procesamiento.

Entrega garantizada: el sistema de CDC debe garantizar la entrega de los datos modificados. Se debe evitar la entrega de datos duplicados y controlar los errores con recuperaciones rápidas y completas. Además, debe haber un mecanismo de control que el sistema de ETL utiliza para verificar que todos los datos entregados por el CDC han sido leídos y consumidos. Con este paso, los usuarios pueden garantizar que todos los datos de los sistemas de fuente son entregados al destino.

La solución


Oracle GoldenGate es una tecnología que soporta los requerimientos necesarios para integración de datos en línea a través de una captura, ruteo, transformación y entrega continua de los datos transaccionales entre sistemas heterogéneos. Las capacidades clave incluyen:

Movimiento de datos en línea: las transacciones se replican constantemente desde el origen al destino con una latencia de hasta milisegundos, eliminando la dependencia de procesos Batch.

La integridad transaccional: Oracle GoldenGate mueve transacciones a través de bases de datos heterogéneas, con la integridad referencial, de manera que la historia verdadera del negocio se mantiene intacta.

De alto rendimiento, arquitectura de bajo impacto: la arquitectura de Oracle GoldenGate sólo mueve datos transaccionales al leer las operaciones “commited” de los logs transaccionales, sin crear tablas adicionales. La tecnología permite un alto rendimiento constante incluso cuando se manejan miles de transacciones por segundo con un impacto insignificante en los sistemas productivos.

Soporte para bases de datos heterogéneas: los datos transaccionales pueden ser integrados y aplicarse a partir de múltiples bases de datos diferentes, incluyendo Oracle, Sybase, Microsoft SQL Server, IBM DB2, entre otras, y a través de todas las principales plataformas y sistemas operativos. Además, Oracle GoldenGate cuenta con adaptadores de aplicaciones que pueden ser utilizados para escribir los datos transaccionales en un Java Message Service (JMS) o directamente sobre archivos planos.

Transformación de datos: Oracle GoldenGate puede aplicar transformaciones a nivel de fila y mapeos ya sea en el módulo de “Capture” o en el “Delivery”. No se requiere un servidor intermedio y soporta filtrados de tablas a través de funciones definidas por el usuario dentro de la interfaz de GoldenGate.

Disponibilidad continua y fiabilidad: las soluciones de Oracle GoldenGate operan sin necesidad de interrumpir los sistemas. Permite alta disponibilidad y asegura que ningún dato se perderá o corromperá al momento del ruteo incluso cuando existe alguna eventualidad dentro de los sistemas.

Aumentar los sistemas de ETL con Oracle GoldenGate


Oracle GoldenGate ofrece una completa selección de soluciones para aumentar los sistemas de ETL en línea. Estas soluciones les permiten a las organizaciones aprovechar los beneficios del BI en línea, al tiempo de aprovechar las inversiones existentes de ETL.

Staging Tables (Tablas Temporales en el sistema Destino)


Un enfoque para mejorar la infraestructura con el ETL en línea es mediante la organización del CDC en tablas temporales. Oracle GoldenGate hace el trabajo de extraer los datos de los sistemas transaccionales y enviarlos a dichas tablas temporales que se ubican en el sistema destino. Usando este enfoque, el sistema ETL nunca tiene contacto directo con los sistemas productivos, lo que elimina cualquier impacto sobre éstos y permite datos en línea sin depender de procesos Batch.

Las tablas temporales pueden crear una copia viva del sistema transaccional para permitir a las aplicaciones de reporteo hacer las búsquedas en estas tablas sin afectar el sistema transaccional. El sistema de ETL puede reunir datos de las tablas temporales de acuerdo a un calendario u otro criterio definido por el usuario haciendo uso de estas tablas temporales para transformar la información y cargarla ahí mismo en el sistema de BI. Dicho esto, la latencia es determinada por la trasformación que llegue hacer el ETL sobre las tablas.

Este método se adapta mejor para las soluciones de ELT que realizan las transformaciones dentro de la base de datos destino, ya que elimina la necesidad de mover los datos, pues esta tarea la hace Oracle GoldenGate.

Directo en Archivos Planos.


Otro método para aumentar los sistemas de ETL en línea es escribir los datos modificados en un archivo de texto plano. El sistema de ETL leerá los datos de esos archivos y así realizará las transformaciones necesarias para posteriormente cargar los datos al almacén de datos. Para muchos sistemas de ETL, la lectura de archivos es más rápido que la exploración de tablas lo que permite disminuir tiempo de latencia. Similar a Stagin Tables, este método evita que el ETL tenga contacto con los sistemas transaccionales y permite la captura continua de cambios de las bases de datos origen, incluso si el proceso ETL se interrumpe. Debido a que este método replica los datos que han cambiado y no utiliza una base de datos provisional, hace que se requiera menos mantenimiento del sistema.

Oracle GoldenGate tiene la capacidad de proporcionar datos en una variedad de formatos, incluidos archivos de texto delimitado y archivos binarios para crear el mecanismo óptimo de alimentación de datos con la tecnología ETL existente. Además de la entrega de datos en archivos planos, Oracle GoldenGate proporciona archivos de control para poder indicar al sistema ETL cuándo éste deberá leer los archivos planos. También, los usuarios pueden configurar el tamaño de los archivos de control, así como la frecuencia de cada periodo de micro Batch. Cada archivo puede configurarse para enviar los datos en cualquier frecuencia de tiempo (segundos, minutos, horas, etc.)

Los sistemas de ETL pueden utilizar los archivos de control de Oracle GoldenGate de dos maneras:

-El sistema de ETL continuamente puede comprobar la presencia del archivo de control en la carpeta asignada y, cuando se encuentra, el sistema sabrá que hay un nuevo conjunto de operaciones a procesar.

-El sistema de ETL puede leer el archivo de control en un horario predeterminado y procesar los datos que se han escrito desde la última ejecución.

Varias empresas han implementado exitosamente Oracle GoldenGate para la integración con sus sistemas ETL a través de archivos planos. Una empresa de servicios financieros eligió esta solución para acelerar sus rutinas de detección de fraude que había estado funcionando cada 24 horas. La compañía aprovechó Oracle GoldenGate para capturar los datos modificados de sus sistemas fuente y escribir las operaciones a los archivos planos en línea. El sistema de ETL que manejaban transfiere los datos a un Data Warehouse y al mismo tiempo los envía hacia un Sistema de Apoyo a Decisiones (DSS) que permite detectar fraudes automáticamente y en cuestión de minutos.

Otro cliente también se basó en los datos de procesamiento por lotes, cada 24 horas. Sin embargo, a efectos de cumplimiento normativo y legal para evitar multas, la empresa tuvo que llevar la información de pedidos de clientes en el Data Warehouse cada hora. Al aprovechar Oracle GoldenGate, la compañía está ahora en condiciones de cumplir con ese requisito, sin impactar los sistemas transaccionales.

Encolamiento de Mensajes (Message Queue Infraestructure)


Muchos de los sistemas ETL ya tienen la capacidad de leer y procesar mensajes XML directamente de JMS y otros encolamientos de mensajes. Para las organizaciones que ha implementado una infraestructura de este tipo, Oracle GoldenGate puede ser implementado en conjunto con algunos adaptadores de GoldenGate para publicar datos en línea de los sistemas fuentes a los destinos a través de JMS. El sistema ETL recibirá los datos modificados en formato XML y en línea. Al utilizar GoldenGate se podrán publicar las operaciones de los sistemas origen a través del Sistema de Mensajes (JMS) para de esta manera reducir costos al querer implementar soluciones hechas en casa para obtener datos específicos.

Hay que tener en cuenta que con este método, el sistema de ETL todavía tendría que estar configurado para procesar los datos XML, ya sea JMS u otro formato basado en XML y encolamiento de mansajes. Aunque esta arquitectura proporciona datos en línea a un sistema de ETL sin procesos Batch, hay una sobrecarga adicional por escrito y de procesamiento XML, así que esta solución no es la más adecuada para los casos que requieren velocidades de transacción extremadamente altos. Sin embargo Oracle GoldenGate puede publicar las transacciones a un bus de mensajes en línea con latencia de hasta milisegundos.

Sistemas ETL con un CDC

Con estos tres métodos que se utilizan para unir los sistemas ETL con un CDC (GoldenGate), las empresas pueden asegurar la información actualizada en el Data Warehouse y además no tendrán impacto sobre los sistemas transacciones, lo cual significa un aprovechamiento de la tecnología actual y un TCO menor en Hardware, Software y consultoría.




Publicado por Juan Vicenteño. Sales Consultant, Oracle Mexico.