¿Desarrollamos paquetes de SSIS o proceso de ETL?

Revisando los proyectos que  hemos implementado desde que salió la primera versión de SSIS con SQL Server 2005 hasta la versión actual de SQL Server 2012, podemos encontrar proyectos de clientes muy diversos pero por otro lado muy parecidos. También hemos visto que los errores y los aciertos son muy parecidos en los distintos casos, pero en todos los casos el éxito o el fracaso viene dado por haber contemplado o tener la carencia de un framework de trabajo que ayude a realizar un desarrollo estable y facil de mantener y operar.

Nuestro compañero Rushabh B. Mehta nos da unas cuantas guías en el artículo ‘Building an SSIS Management Framework’ publicado en Julio 2011:

• Estilos de desarrollo diferentes por cada individuo, lo que implica que cada paquete, aún siendo desarrollado en la misma empresa (o incluso por la misma persona), se diseña teniendo en cuenta una arquitectura de lo más variada.
• La gestión de la configuración entre entornos no existe o se realiza de manera manual y descentralizada con los problemas que ello conlleva.
• No hay una monitorización activa, si no reactiva, no sabemos lo que ocurre hasta que no investigamos el error, y lo peor, no tenemos ninguna pista de por donde empezar a mirar.

¿Y como lo solucionamos? Definiendo o usando una arquitectura orientada a un correcto mantenimiento y desarrollo de los procesos de ETL, es decir, no nos centremos únicamente en el paquete, si no centrarnos en el proceso completo. Como Rushabh apuntaba en su artículo, el simple hecho de definir una estrategia de monitorización, auditoría y gestión de errores ya añade un valor añadido lo suficientemente grande como para pararnos a pensar en esos elementos antes de avanzar con nuestro desarrollo. Si además tenemos en cuenta que el TDWI en su informe de 2003 (aunque parezca antiguo, puedo asegurar que sigue vigente) sobre herramientas de ETL ‘Evaluating ETL and Data Integration Patforms’, identificaba que entre el 60% y el 80% del tiempo de desarrollo de un proyecto de BI se va en el desarrollo de los procesos ETL, eso nos debería llevar a pensarnos bien como ejecutamos otras fases de nuestro proyecto.

• ¿Que ocurre con el diseño? ¿Diseñamos antes de crear los paquetes o los hacemos en base a prueba y error? ¿Documentamos mucho o poco? Yo siempre he sido de la opinión de que documentación poca pero útil, y aquí cada cual que determine su límite, lo que si tengo claro es que para afrontar un buen proceso ETL primero tenemos que tener claro donde vamos a cargar los datos (mi modelo de datos final), donde están los datos que voy a extraer(mis orígenes de datos) y que voy a hacer con ellos en el camino (reglas de negocio y transformaciones). No voy a entrar a determinar cual es el formato o la mejor herramienta para  hacerlo, pero si debemos considerar que sea lo suficientemente flexible y fácil de manejar para que podamos mantenerla y complementarla fácilmente (en mi caso uso Excel porque además veremos que nos va a ayudar para agilizar el desarrollo de fases posteriores)
• ¿Son todos los paquetes iguales? La primera respuesta que se viene a la cabeza es: no, cada uno tiene un origen y un destino distinto y usa transformaciones distintas. Sin embargo, la experiencia no nos aporta una respuesta tan clara. De igual manera que nos apoyamos en teorías de modelado (vease Kimball) y que nos ayudan a definir ciertos patrones (que es una dimensión, que es un hecho, que es una medida, etc.) ¿no deberíamos  hacer lo mismo con el ETL? Desde SolidQ hemos comprobado que en un alto porcentaje de los casos nos encontramos con patrones de carga similares: Bajadas planas de datos, Carga de dimensiones y Carga de hechos. Esto implica que podemos crear plantillas que se tomen como base para la creación correcta de los procesos ETL, o mejor aún, podemos automatizar gran parte del proceso de desarrollo. Y eso es justo lo que hemos hecho. Basándonos en la experiencia de algunos compañeros como Enrique Catalá (que nos explica parte del secreto en el artículo ‘Generating SSIS Packages Programmatically’ publicado en Abril 2011) hemos creado una herramienta que nos permite generar paquetes de manera automática. Paquetes que aprovechan las mejores prácticas y diseños (muy amablemente Salvador Ramos nos cuenta algunas de ellas en ‘Integration Services Key Features in BI Project’ publicado en Septiember 2011).

En resumen, podemos seguir haciendo paquetes a demanda sin control o podemos pararnos a pensar si hay mejores maneras de hacerlo y contar con los mejores recursos para ello.