La información se provee al data warehouse desde distintos tipos de interfaces como conexión a base datos en producción, conexión a réplica, archivos planos, servicios web, servicios de mensajería, entre otros. Cuando la interfaz provee la información en batch, utilizamos la estrategia de staging para obtener ciertas garantías de desempeño sobre los sistemas de información y en la carga hacía el data warehouse.
El objetivo principal es extraer lo más rápido posible los datos desde la fuente hacía el data warehouse, reduciendo la ventana de tiempo requerida. Para optimizar la propagación de la información hacía otras capas, también es posible realizar una selección incremental de la información (solamente la información nueva o con algún cambio).
Es una área temporal no-persistente que mantiene la información hasta el momento en que el data warehouse ha sido cargado y cuando mucho solamente se almacenan algunos pocos batch anteriores en caso sucedan errores en los procesos de carga.
El stage tiene características deseables para preparar la información para su posterior carga hacía el data warehouse:
- Ejecución de hard rules
- Correcta definición de load datetime
- Selección incremental (Opcional)
La información es extraída en paralelo, por tanto, no es factible ni deseable agregar llaves foráneas a estas tablas. Además puede llevar a no cargar un registro y siempre debemos cargar el 100% de los datos. Es recomendado deshabilitar los índices para agilizar la carga de los datos y solamente habilitarla de nuevo hasta que ya haya finalizado completamente la carga de esa tabla.
Ejecución de hard rules
En el post de hard rules expongo que varias de estas reglas se ejecutan durante el movimiento de datos desde la fuente hacía el staging. Entre los casos particulares de estas reglas están las de business keys y hash differences.
En caso que estas reglas se implementen en el staging, significa que agregaremos estos atributos directamente en las tablas de staging, evitando el re-cálculo de los hash en cada carga de los objetos del data warehouse. Entre las otras formas de implementar estas reglas sería la creación de vistas para su uso en los procesos de carga o colocar directamente esa lógica en los propios procesos de carga. Cada opción tiene sus ventajas y desventajas.
- Hash Rules en Staging: La ventaja es el desempeño, al tener calculados los hash evitando su constante cálculo en los distintos procesos de carga. Además la regla está implementada en un sólo lugar, por tanto, el impacto en correcciones o cambios en reglas de negocio es mínimo. La desventaja es el impacto que produce un cambio en data vault sobre las tablas staging. Si se decide agregar un nuevo hub, se agrega un nuevo atributo es las tablas stage, modificando el proceso de carga. También si se cambia una definición de business key, modificarás de nuevo el proceso de carga. Estas modificaciones conllevan un riesgo inherente al realizar cambios a procesos que han sido validados y ejecutan correctamente.
- Hash Rules en Vistas: La ventaja, al igual que en el punto anterior, la regla existe sólo en un lugar. En este caso los cambios en reglas no impactan el staging. La desventaja es que se calculará la información en cada proceso que ingresa información al data warehouse.
- Hash Rules en Procesos: Me refiero a que las reglas existen en los procesos de carga del data warehouse. Creo que es la peor opción pues la creación de reglas será redundante y en caso de correcciones requieres buena documentación para no pasar por alto ningún proceso. Requieres más controles.
- Tambíen es posible considerar distintas aproximaciones para distintas tablas. No todas debes responder al mismo patrón, aunque será más difícil la adminsitración.
La selección de tu estrategía estará en función de la saturación de información y disponibilidad de recursos de infraestructura. Si te falta recursos, es recomendado "Hash Rules en Staging", mientras si los recursos no son un problema gestionas mejor utilizando vistas.
Otras reglas que implementas aquí son las relaciones de llaves foráneas entre las tablas de los sistemas de información fuente. Considerando que no es deseable la existencia de llaves foráneas, una forma de implementar estas reglas también es utilizando vistas. De no utilizar esta opción será necesario que los joins existan en de forma explícita en los procesos de carga del data warehouse.
Muchos consideran relevante establecer un conjunto limitado de tipos de datos a utilizar en el staging con categorías definidas para simplificar la administración. Esto significa hacer un mapeo de todos los tipos del sistema fuente hacía las siguientes categorías propuestas:
- CHAR o VARCHAR con longitudes 10, 50, 100, 500, 1000, 4000
- Las variantes SMALLINT, TINYINT, etc hacía INT
- Las variantes de valores flotantes hacía DECIMAL(38,20)
- Las fechas a la máxima precisión disponible
Cuando se cargan archivos sugiero que todos los campos sean cargados a atributos de tipo varchar con el fin de no perder ningún registro por formato de fecha incorrecto o similares. Esto a menos que puedas asegurar que todos los posibles errores se manejan correctamente en los procesos de carga.
Para las demás reglas creo que no tengo consideraciones adicionales que comentar, pero te sugiero que pienses con detenimiento la forma correcta de definir e implementar las reglas. Entre las opciones está colocar las expresiones en los procesos de carga, en vistas o en funciones definidas por el usuario de base de datos.
Correcta definición de load datetime
El load datetime debe reflejar el momento en que la información llega hacía la plataforma de inteligencia de negocios sea el staging o data warehouse. Se espera que la llegada de los datos corresponda al orden en que realmente sucedieron los eventos. Además esta fecha será llave primaria en unos objetos que introduciré posteriormente llamados Satellites. Por lo que seguramente necesitarás una buena precisión en estas fechas para absorber múltiples cambios por batch.
Hay muchas razones por las que no es recomendable utilizar fechas administradas por el sistema de información fuente, entre las cuales se incluyen que las fechas de esos sistemas dependen de zonas horarias, no se tiene control sobre esas fechas y pueden ser actualizadas, muchas veces estas fechas no están disponibles, entre otros problemas.
La consideración especial está en la primera carga histórica, y sobre todo en las propias bitácoras que llevan los sistemas de información. Esos datos suelen existir también en otros catálogos y ante cambios pasar a esas bitácoras de cambios. Para esa carga considera establecer un criterio que ordene los registros a como ocurrieron los eventos en el negocio. Puede ser una fecha de cambio calculando la diferencia con una fecha base (la mínima fecha del conjunto de datos por ejemplo) para generar un valor entero o utiliza un propio secuencial del sistema de información. Establece una load date fijo y agrega en mili o micro segundos el valor entero calculado.
Hay muchas razones por las que no es recomendable utilizar fechas administradas por el sistema de información fuente, entre las cuales se incluyen que las fechas de esos sistemas dependen de zonas horarias, no se tiene control sobre esas fechas y pueden ser actualizadas, muchas veces estas fechas no están disponibles, entre otros problemas.
La consideración especial está en la primera carga histórica, y sobre todo en las propias bitácoras que llevan los sistemas de información. Esos datos suelen existir también en otros catálogos y ante cambios pasar a esas bitácoras de cambios. Para esa carga considera establecer un criterio que ordene los registros a como ocurrieron los eventos en el negocio. Puede ser una fecha de cambio calculando la diferencia con una fecha base (la mínima fecha del conjunto de datos por ejemplo) para generar un valor entero o utiliza un propio secuencial del sistema de información. Establece una load date fijo y agrega en mili o micro segundos el valor entero calculado.
Selección incremental
Se refiere a la identificación de cambios verdaderos entre distintas cargas. El mecanismo para implementarlo está en función de la interfaz que provee los datos. Por ejemplo, la mejor interfaz es una change data capture (mecanismo de restreo de cambios propia de un dbms). Este tipo de interfaz provee una fecha en la cuál ocurrió un cambio de insert, update o delete y por tanto, es muy sencillo obtener la máxima fecha de última carga para determinar los nuevos registros a ser cargados.
Otras características
Definir un record source apropiado para el restreo de la fuente de los datos. Recomiendo identificar y nombrar las distintas interfaces que proveen datos. En caso de las interfaces de tipo archivo generar un nombre que identifique a todo el conjunto de archivos. Por ejemplo: para los archivos: sys1_tabla1_20180901, sys1_tabla1_20180902, sys1_tabla1_20180903 utilizaría el nombre sys1_tabla1 sin incluir la fecha de extración, pero agregaría entre los atributos las fechas de extracción presentes en los archivos.
Además podrías pre-procesar los archivos para incluir en el nombre el checksum del contenido. De esta forma, la existencia de múltiples versiones de un archivo en el mismo día puede ser manejado.