MOTIVOS Y UTILIDADES DE LA BASE DE DATOS DE STAGING
Las varias excusas para no usar staging
Las seis razones por las que usar staging pueden ayudarnos a rebatir con facilidad y contundencia las varias excusas que jefes o clientes pueden alegar para prescindir de un activo importante en su data warehouse.
Cuando diseñamos nuestra solución de data warehouse puede resultarnos obvio que la fuente desde donde se nutrirá nuestro modelo dimensional son las bases de datos que van registrando la actividad diaria de nuestra organización.
La idea de volcarlos a una base de datos intermedia puede parecer absurda. Ocupa espacio en disco, requiere una carga, ha de diseñarse y ha de mantenerse. Todo ello se traduce en dinero.
Es cierto, se traduce en dinero, pero no es dinero gastado, sino invertido.
Las seis razones por las que usar staging
Vamos a ver a continuación las seis razones por las que usar staging. No son las únicas pero sí las que considero principales.
Linaje de datos. Principal de las seis razones por las que usar staging
Conocer el origen de todos los datos que contiene nuestro data warehouse es fundamental para poder evaluar su fiabilidad así como para poder diagnosticar problemas.
En rarísimas ocasiones podremos modificar las bases de datos de producción para incluir metadatos que guarden esa información. Otras veces, los datos vendrán en formatos no estructurados. Una base de datos de staging nos permite añadir columnas a las tablas de datos que pueden ir desde una simple fecha hasta una clave externa a otra tabla que contenga metadatos más detallados.
Estos metadatos no sólo pueden informar de cuándo los datos se incorporaron a nuestro data warehouse sino de posteriores modificaciones.
Aislamiento de entornos.
Producción es producción y BI es BI. Sus necesidades y maneras de tratar los datos son diferentes porque sus objetivos son diferentes. Mientras que el objetivo de producción es meter datos, el de BI es extraer información.
Estas diferencias hacen que no se a deseable que ambos departamentos naden manipulando los datos y las estructuras que los albergan simultáneamente y con objetivos distintos. Es una receta segura para los problemas.
Por lo dicho, conviene que BI se limite a realizar conexiones a producción sólo cuando haya de cargar datos y que esas conexiones sean lo más breves posibles. Para ello recurriremos a técnicas de carga incremental siempre que sea posible.
Concentración de datos de orígenes diversos
Aunque nuestro data warehouse pueda nutrirse a partir de múltiples fuentes de datos, las complejas tareas de modelado dimensional serán más sencillas si todos los datos se hallan en un repositorio único.
Una sola conexión, un solo conjunto de tipos de datos, unas únicas credenciales y un sólo punto donde aplicar seguridad son algunas de las ventajas de volcar los datos en tablas de nuestra base de datos de staging.
Control de calidad de los datos
De igual manera que no podemos modificar las bases de datos de producción para incluir metadatos que guarden el linaje de los datos, tampoco podemos hacerlo para guardar su nivel de calidad.
Como dijo alguien, no hay datos limpios, hay datos más o menos sucios, Esa suciedad adopta múltiples formas: fechas en formatos diversos, columnas incompletas o vacías, valores incongruentes, nulos, blancos, etc. Dependiendo de nuestras reglas de negocio un registro puede llegar a ser, no ya inútil, sino contraproducente si se incorpora a nuestro data warehouse. Uno solo puede abortar un proceso, pero sin llegar a eso una acumulación de registros sucios puede desvirtuar gravemente los resultados ofrecidos por el data warehouse.
En una base de datos de Staging somos libres de marcar los regitros desde una simple catalogación dual: procesable, no procesable hasta clasificaciones más detalladas donde marquemos cada registro indicando qué tipo de defecto contiene.
Protección ante cambios del esquema de las bases de datos de producción
Como ya hemos dicho antes, producción y BI son dos mundos aparte y, muchas veces, mal comunicados. Es frecuente que las estructuras y esquemas de las BBDD de producción sean modificadas sin que BI sea notificado de ello. Esto suele acarrear fallos en los procesos de ETL que provocan retrasos en la disposición de la información por los usuarios finales así como tiempo y recursos malgastados.
El hecho de tener las estructuras de datos replicadas en nuestra base de datos de staging nos permite comparar su esquema con el de producción detectando los cambios y parando la carga ordenadamente antes de que se produzca un fallo de consecuencias peores. Además, habiendo registrado los cambios producidos, podremos actualizar nuestros esquemas en consecuencia con mayor agilidad que si tuviésemos que indagar en producción.
Tablas auxiliares, procedimientos de extracción e índices
Hay dos tareas en toda creación de un data warehouse que suelen requerir de la creación de objetos completos en una base de datos: el modelado dimensional y la extracción de datos para una carga.
Con frecuencia, la extracción de datos requerirá un consulta que nos devuelva los datos requeridos y dicha consulta se materializará en una vista. Igualmente, estas vistas suelen ser usadas por procedimientos almacenados que cargan los registros que devuelven en las tablas de destino.
Por otra parte, no es raro que el remodelado necesario para llenar una tabla de nuestro data warehouse sea tan complejo que necesitemos crear una tabla auxiliar a partir de las que cargamos desde las bases de datos de producción.
Finalmente, las consultas que extraen los datos desde las tablas de origen para ser cargadas en nuestro data warehouse necesitarán de índices específicos para funcionar a pleno rendimiento.
Nada de eso podemos crearlo en las bases de datos de producción sin afectar su rendimiento pero nada impide que lo hagamos en nuestra base de datos de staging.
Y estas son seis razones por las que usar staging
Podéis encontrar información más detallada en los siguientes enlaces:
O si lo preferís consultad nuestra oferta de cursos sobre data warehouse en la página de SQL Server y BI de Certia
Hasta la próxima.