Are you satisfied with the way you currently manage the dependencies in your ETL? In the part 1 of this article, I talked about the features I’m expecting from a dependency management system, and what are the main possibilities offered (directly or indirectly) by Data Services. In part 2, I proposed an architecture (structure and expected behavior) for a dependency management system inside Data Services. In part 3, I explained the complete implementation details. In this final part, I'm going to give you a feedback on how it went “in real life” as well as possible improvements. So, the most important question is of course "Does it work?". I'm happy to confirm that yes, it does! And it makes quite a difference in the life of the customer's Data Services administrator. Of course it doesn't change anything if the ETL is running fine, but when there are problems, this dependency management system can be a huge time-saver!
En su entorno, nuestro cliente tenía 64 flujos, con 86 dependencias entre ellos (esto es igual al número de filas de la tabla FLOW_DEPENDENCIES). Tomemos un ejemplo de la vida real: debido a una nueva excepción, se produjo un error en el flujo responsable de la dimensión del cliente. Como consecuencia, no se ejecutaron 5 flujos dependientes (cuáles fueron las tablas de hechos pobladas). ¿Cuál habría sido el siguiente paso para el administrador después de arreglar la excepción? Sin el sistema de gestión de dependencias, tendría que volver a ejecutar todo el ETL (incluidos los 58 flujos que ya se habían ejecutado con éxito), o para crear un nuevo trabajo con sólo 6 los flujos, preste atención a la Variables, etc. Pero ya que ahora tiene el sistema de administración de dependencias, el administrador simplemente vuelve a ejecutar el trabajo dando el ID del último trabajo y todos los flujos que se ejecutaron con éxito simplemente se saltan.
En general, el ahorro de tiempo y la paz de la mente son realmente apreciados por el cliente.
Ahora, ¿podemos mejorar este sistema? ¡Seguro! 2 posibles mejoras:
Enviar un correo electrónico al administrador al final del trabajo con un resumen de lo que sucedió. Esto se puede hacer dentro de un script al final del trabajo. La siguiente imagen muestra un ejemplo. Observará que he incluido ejemplos de consultas SQL para facilitar al administrador el análisis de lo que sucedió.
ETL_Dependencies_12
It's a bit outside the scope of this article, but you could use the FLOW_STATUS table to create a report about the technical status of the business processes. This report would allow end users to easily see if the data they need has been loaded today. You can see below an example of such a business process status report.
ETL_Dependencies_13
Hay una pregunta final de la que no he hablado todavía: ¿cómo organizamos los flujos en el trabajo? Cuando utilicé este sistema de gestión de dependencias por primera vez, empecé por extraer datos de los sistemas de origen, seguidos por todas las tablas de dimensiones y terminé con todas las tablas de hechos. Hoy haría las cosas de otra manera, basado en una presentación hecha por Werner Daehn (un Gerente de Producto de SAP), crearía un flujo de trabajo por proceso de negocio. Por ejemplo, un flujo de trabajo para el proceso de negocio del Libro mayor, con todos los flujos necesarios para la extracción de datos, las dimensiones y las tablas de hechos. El trabajo ejecutaría el flujo de trabajo para el proceso de negocio 1, luego para el proceso de negocio 2, etc. Esta organización permite pruebas independientes fáciles de cada proceso empresarial. Pero aquí usted puede pensar: "Ok, pero ¿qué pasa con las dimensiones / extracciones que se utilizan en múltiples procesos de negocio? ¿Funcionará el trabajo varias veces?" Ese problema se evitará comprobando la opción "Ejecutar sólo una vez" para cada flujo de trabajo en cuestión.
Ahora he alcanzado el paso final en mi ETL sistema de la gerencia de la dependencia. ¿Que piensas de eso? ¿Alguna pregunta? ¿Lo has probado por ti mismo? Hazme saber publicando un comentario a continuación.