domingo, 20 de marzo de 2016

Partición real-time en un Datawarehouse

Es cada vez más habitual la necesidad de tener los datos en nuestros sistemas de Business Intelligence lo más actualizados posibles y eso implica el tener un datawarehouse lo más próximo al real-time que podamos.




Vamos a ver una forma de implementarlo:

En un DW nos puede interesar combinar la actualización de datos en batch con una actualización real-time. El objetivo podría ser obtener informes de los datos procedentes de un proceso batch diario nocturno que nos muestran el estado de los eventos de negocio a cierre del día anterior y por otro lado poder obtener informes sobre los eventos de negocio que ocurren durante el mismo día de la solicitud del informe.

- ¿Cómo debo almacenar la información para guardar los datos procedentes del batch diario nocturno y los datos real-time?- ¿Cómo debo implementar los procesos ETL para realizar esta doble actualización?

En nuestro DW tendremos una tabla de hechos que guarde los datos cargados en el proceso batch diario que llamaremos partición estática y que será una foto a d -1. Añadimos a esta partición una nueva partición que llamaremos partición real-time que guardará los eventos generados durante el día y que será otra tabla física a parte idéntica en estructura a la tabla de hechos ya existente



Fuente: www.rittmanmead.com


La ventaja de tener dos tablas físicas es que la tabla de hechos de la partición estática que será consultada desde la capa de explotación no se verá afectada por las actualizaciones de la partición real-time. 

Para actualizar la partición real-time será necesario implementar mecanismos CDC que detecten los cambios y los actualicen N veces al día, en micro-lotes muy frecuentes.  La partición real-time afecta a los hechos, pero no a las dimensiones, lo que puede dar lugar a falta de sincronización entre hechos y dimensiones, con situación del tipo early-arriving facts que será necesario gestionar. Por ejemplo, los datos de hechos real-time traen un valor en un campo no encontrado en su tabla de dimensión, no rechazamos el registro, lo integramos pero con valor ‘unknown’ o un código que establezcamos para el valor indeterminado de esa dimensión (ejemplo: 9999). Este valor indeterminado si existe en la tabla de dimensión. El dato se ve en los informes, pero clasificado en un valor ‘saco’, hasta que la tabla dimensión se actualice y la tabla de hechos se reprocese


El proceso ETL será idéntico para la actualización batch y la real-time con la diferencia de las fuentes origen (extracción en batch y CDC en real-time) y las tablas destino que será las tabla de la partición estática o la tabla de la partición real-time.





Fuente: www.rittmanmead.com

Los datos actualizados a final del día en la partición real-time podrán ser movidos a la partición estática. Esta operación puede hacerse realizando una actualización de la metadata (alter table … exchange partition…) que no suponga un movimiento de datos, aprovechando que ambas tablas son idénticas. 

El hecho de tener 2 particiones facilita el trabajo del analista de negocio que sabe que en una partición tiene la foto a d-1 y que en la partición real-time le pueden cambiar los datos si obtiene el mismo informe varias veces en un día. Será posible obtener informes que unan datos de ambas particiones de forma sencilla. Obteniendo SQL’s que unan los datos de ambas particiones de una forma sencilla ya que tienen la misma estructura.




Esta aproximación permite la convivencia de dos particiones que dan dos visiones del dato y nos acercan a el análisis real-time, sin perder la visión clásica de la foto de la situación del negocio a una fecha.