ETL, de nuevo, back to the basics y hablamos de errores

Hablábamos de errores no hace mucho en proyectos de Business Intelligence (lo siento pero últimamente me niego a traducir el término). Los errores tanto pueden darse en el diseño lógico del data warehouse, el diseño físico del mismo, así como en los procesos ETL.Ya lo sabemos, pero estamos de revival. Así que no está de más repetirse. ETL es una de las tecnologías para la integración de datos (que por haber existen muchas más y seria un buen tema para otro post). Permite extraer datos del entorno origen, transformarlos según nuestras necesidades de negocio para integración de datos y cargar estos datos en los entornos destino. Justo lo que necesitamos para la construcción de un data warehouse. Los entornos origen y destino son usualmente bases de datos y/o ficheros de todo tipo (xml, txt, xls, csv,…), pero en ocasiones también pueden ser incluso colas de mensajes de un determinado middleware o webservices. Las herramientas de ETL en la práctica mueven o transportan datos entre entornos origen y destino, pero también documentan cómo estos datos son transformados (si lo son) entre el origen y el destino almacenando esta información en un catálogo propio de metadatos; intercambian estos metadatos con otras aplicaciones que puedan requerirlos y administran todas las ejecuciones y procesos de la ETL: planificación del transporte de datos, log de errores, log de cambios y estadísticas asociadas a los procesos de movimiento de datos. Este tipo de herramientas suelen tener una interfaz de usuario de tipo GUI y permiten diseñar y administrar y controlar cada uno de los procesos del entorno ETL. Últimamente los fabricantes de herramientas de ETL han ido añadiendo numerosas funcionalidades a sus productos, de tal manera que gran parte de los productos soportan funcionalidad avanzada:

• Orígenes de datos adicionales: Además de los típicos gestores de bases de datos estructurados y los ficheros planos, actualmente se ofrece soporte para origen de datos en bases de datos XML, web services y datos no estructurados de todo tipo.
• Mejoras en transformación de datos, como uso de funciones avanzadas del gestor de base de datos, uso de SQL u otros lenguajes de scripting.
• Integración con productos de gestión de calidad de datos.
• Mejoras en la administración: planificación de tareas, administración de los metadatos, gestión automatizada de los errores.
• Mejoras de rendimiento: aprovechamiento de las capacidades de paralelismo del gestor en origen y destino, soporte de balanceo de cargas, utilización de programas de carga masiva propios del gestor, etc.
• Mejor usabilidad e interfaz de usuario.
• Mejor seguridad: soporte de gestores de seguridad externos.
• En algunos casos, soporte de federación de datos.

Y volviendo a los errores. Puedes tener la mejor herramienta del mundo, el mejor dashboard del mundo, el mejor análisis multidimensional, los mejores informes,… pero si no tienes información buena no sirven para nada. Són sólo dibujos (mejor o peor hechos). Me comentaba de un tiempo para esta parte un amigo al que hacía tiempo no veía que se había procedido a la implantanción en la empresa de una herramienta de Business Intellince. Y claro, un poco con el objetivo de meter el dedo en la llaga, le pregunté si estaba contento. Me dejo que la verdad es que no. Que sólo tenía información nueva una vez al mes. Y que esa información a él sólo le servía un día o como mucho dos. La necesitaba más frecuentemente. Pero mi dijo, sonriendo entre los dientes, que había solucionado el problema. Se fue al de sistemas y le pidió que cada día se pudiera hacer una carga incremental en un fichero excel mediante macros para tener el toda la información del mes presente. La que el necesitaba. Yo le comenté que eso era un fallo de periodicidad en los procesos ETL. Y que debía comentarlo.Esto me lleva a pensar. ¿Alguien se ha dado cuenta lo crítico que en un proyecto Business Intelligence todas las etapas estén bien diseñadas? Que tanto esfuerzo dedicado, tanto tiempo, tantos recursos pueden quedar en nada.Pues a lo que vamos, algunos errores típicos de los procesos ETL:

• La periodicidad de los procesos ETL no están bien definida.
• No se realiza una limpieza de datos.
• No se realiza una ponderación de la calidad de los datos.
• Los procesos ETL no están bien definidos.

¿Qué más añadirías a esta corta lista?