Starting Area (Funcionalidades: Segunda Parte)

En el anterior Post introduje como nació la Starting Area (STA de ahora en adelante).

Esta idea ha ido evolucionado y la STA cumple actualmente 4 funcionalidades y posee 2 características (que ya avancé en el anterior post)

1) Relanzar los procesos de ETL cuando los necesites.

La primera de ellas la pudimos ver en el anterior post. Se trata de tener siempre "llenos" los primeros pasos de los procesos ETL, y no borrar esa información. Para ello cogemos el último nivel de agregación desde el que construimos el DWH. Obviamente como vamos a dejar la información de forma permanente la STA debe estar obligatoriamente en una base de datos relacional diferente a la Staging Area (STG) para poder optimizarla y realizar tunning de forma separada en el caso de que el volumen de datos así lo hiciera recomendable.

2) Ser el embrión del MasterData

Obviamente todos estos procesos necesitan de una unificación del modelo cuando las fuentes de datos son heterogeneas. Por ejemplo si estamos unificando el concepto "Cliente" podemos tener un modelo E-R de Cliente en el ERP que nada tenga que ver con el "Cliente" del CRM y que en la aplicación de gestión comercial tenga otro significado muy distinto. Obviamente desde el punto de vista decisional nosotros tenemos un único "Cliente" así pues en la STA, cuando las fuentes de datos son heterogeneas ,nos quedamos con el último nivel de detalle pera una vez unificado el modelo. Así esta tabla puede ser unificada no solo en la parte decisional sino que cualquier otra aplicación que quiera hacer uso de "Clientes" puede intorducirla como su fuente de datos operacional, de esta manera tenemos el embrión de un MasterData de la organización que mas adelante pueda servirnos tanto para la parte de sistemas de información transaccionales, como para los sistemas de información decisionales. Es una buena manera de empezar a difundir el concepto de MasterData en aquella empresas que no están maduras.

3) Proveer de Reporting para la trazabilidad decisional a nivel de detalle.

Muchas veces desde el DWH necesitamos vincular con información de detalle cuyo detalle tenemos que ir a buscarlo al operacional, por eso nos puede llegar a interesar tener algún repositorio con esa información ya almacenada (siempre que no estemos tratando de información a tiempo real). Por ejemplo, si queremos saber el número de incidencias de producción la semana pasada lo tenemos fácil, pero si queremos buscar una descripción de los incidentes de gravedad 1 de esa misma semana para ponerlo en el Informe, entonces deberíamos ir al operacional. Para facilitar esto lo que podemos hacer es traernos un nivel de detalle mas bajo que el que estamos utilizando en el DWH y vincularlo con la base de la estrella al mas puro estilo Inmon, como Reporting. Alguien podría decir que esto no es mas que un ODS (Operational Data Storage) y le daría la razón pero con un matiz, y es que los ODS carga información operacional agregada y yo cargo información de detalle muy bajo, ya que la información típicamente agregada del ODS para mí es parte del modelo del DWH al combinar Inmon y Kimball en la base de la estrella.

Este nivel de detalle bajo nos puede ayudar también a crear el MasterData y nos da esa capacidad de reporting complementaria al DWH sin que tengamos que molestar a los operacionales.

4) Realizar mejora de la calidad de forma "continua"

La STA como he dicho tiene un repositorio diferente de la STG y obviamente del DWH, así que podemos lanzar los procesos de carga de la STA con una periodicidad mucho mas pequeña que no la del DWH limpiando y puliendo los datos antes de hacer la carga definitiva del DWH. Esto nos da la posibilidad de detectar los errores antes de lanzar los procesos definitivos y mas costosos, mejorando la calidad del dato y los tiempos de los procesos de carga.
De esta manera podemos construir escenarios en los que la STA se cargue diariamente y el DWH mensualmente. La mayoría de los posibles problemas de calidad del dato tienen 30 oportunidades de ser detectados antes de cargar el DWH.

Estas son las funcionalidades de la Starting Area, en el próximo (el último de esta trilogía) comentaré como construirla y sus dos características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

2) Diluirse a medida que la estructura decisional madura.

Starting Area (Orígenes: Primera Parte)

Bueno, me lanzo al final. Llevo varios dias intentando ver como explico lo de la starting area, lo he explicado muchas veces y lo he puesto en marcha varias mas, y funciona, pero no se porque, escribirlo, me da un poco de respeto y lo he estado evitando. Pero en fin allá voy.

La Starting Área (STA) tiene dos carácterísticas principales, la primera es que está ligada intrínsecamente al concepto de metodologías ágiles y la segunda es que tiene fecha de caducidad.


El concepto es el siguiente: La idea de la Starting Area la empecé a madurar al encontrarme "malas" implementaciones de la Staging Area. La Staging Area (STG) por definición es el área donde se ejecutan los procesos ETL y que tiene un caracter volatil, es decir al finalizar el proceso, la Staging debe de quedar vacia, sin contenido. Sin embargo, me encontraba que muchas implementaciones, tanto propias, como de otros arquitectos de DWH, acababan dejando información en la STG. En mi época más purista blasfemaba cada vez que me encontraba una STG con datos, pero a medida que trabajaba con estas arquitecturas me daba cuenta que si bien en algunos casos era pura negligencia, en otros casos incluso yo mismo estaba dejando esos datos "permanentes" de forma deliberada. Esto siempre ocurría en implantaciones con mucha limpieza de ETL, al final decidia no borrar la STG para poder ir haciendo pruebas en desarrollo y no tener que esperar a cargar de nuevo los origenes. Al final, tenía un proceso ETL en el que en lugar de finalizar con el borrado de la tabla, dejaba los datos hasta la siguiente ejecución , con lo que cada proceso se iniciaba borrando los datos que habían sido utilizados en la anterior ejecución.

Obviamente esto solo lo hacía durante el desarrollo del DWH y una vez lo ponía en marcha cambiaba el modelo a la ejecución normal dejando la STG totalmente vacia. Y así lo estube haciendo hasta que cierto día en uno de mis clientes, alguien cambió un elemento de una jerarquía en el operacional por error, una operación que el ERP validó pero que no tenia sentido lógico, error que se propagó a la información que daba el DWH, y que nadie comprobó hasta al cabo de varios dias. Con lo que teníamos que rehacer el DWH y con urgencia, porque al dia siguiente había la reunión del comité de dirección. Me avisaron a las 9:00 de la mañana, tardé en borrar la información erronea unos 20 minutos y tube que esperarme hasta las 20:00 horas que cerraban el turno para poder conectarme al operacional y lanzar la carga del DWH. A las 21:00 ya estaba cargado y solventado, y a las 21:30 cogia el tren hacia mi casa pensando "esto no tiene sentido, tiene que haber una manera mejor de hacer las cosas". Y ahí fué cuando empecé a crear mi idea de la Starting Area.

Su primera versión consistió en no borrar el primer estadio de todos los procesos ETL del DWH, dejarlo como en el modo de desarrollo, es decir borrando al iniciar, pero solo en el primer paso de cada proceso ETL, con el que "todo empieza", de ahí su nombre "Starting Área". Eso me daba la ventaja de poder ejecutar el proceso anterior de nuevo sin necesidad de esperar a la ventana de tiempo del proceso de carga, sin embargo no me solucionaba nada cuando tenía que rehacer varias ejecuciones anteriores del proceso ETL, o si tenia que recargar TODO el DWH.

Así que di paso a mi segunda versión que solamente utilizaba en desarrollo y que consistía en hacerme una copia exacta de las fuentes de datos en un repositorio diferente. Y cuando estaba haciendo esto me di cuenta que estaba volviendo a los origenes del DWH, en los que haciendo una copia "exacta" del operacional se construían los sistemas decisionales. Y entonces me dí cuenta que algo se me estaba escapando y que así no iba bien, que tendría que volver a los origenes y ver que estaba pasando. Fué así como empecé a descubrir a Inmon y como me replanteé las funciones que debería tener la Starting Area.

Obviamente la Starting Area (STA) no se ha quedado en simplemente eso, ha evolucionado mucho mas, dando soporte a otras necesidades que me he encontrado, como la hetorogeneidad de fuentes que comentaba en el post anterior, el reporting operacional (funcionalidades de ODS) y mejoras en los procesos de calidad del dato, siempre desde la perspectiva de las metodologías ágiles, en el que el tiempo de desarrollo y de entrega ha de ser de ciclo corto.

Pero ya se me ha hecho muy tarde y eso lo dejaré para el próximo post.