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.
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.
