Administración de dependencias ETL con BusinessObjects Data Services (Parte 1)

¿Está satisfecho con la forma en que actualmente gestiona las dependencias en su ETL? Las dependencias entre trabajos (o partes de trabajos) son un aspecto importante de la gestión de ETL. Se refiere a preguntas como: ¿Desea ejecutar el trabajo B si el trabajo A falló? Imagine que tiene un trabajo C con subtarea 1 (tiempo de ejecución habitual: 3 horas) y subproceso 2 (tiempo de ejecución habitual: 2 minutos). Si el subproceso 1 ha sido satisfactorio y ha fallado el subproceso 2, ¿puede reiniciar el trabajo C sin reiniciar el subproceso 1?

Tan pronto como tenga más de 1 trabajo simple, tendrá que administrar sus dependencias. En este artículo (parte 1 de una serie de artículos sobre el manejo de dependencias de ETL) enumeraré primero algunas de las características que busco en un sistema de administración de dependencia ideal. A continuación, echaré un vistazo a algunas de las posibilidades ofrecidas por SAP Data Services 4. En la parte 2 (mi siguiente post), voy a proponer la arquitectura de un posible sistema de gestión de dependencias. En la parte 3, entraré en los detalles de la implementación en Data Services. Terminaré con la parte 4 diciéndole cómo fue la implementación, y si algunas mejoras son posibles.

El sistema de gestión de dependencias ideal

En este post voy a usar la palabra "proceso" para diseñar una serie de ETL operaciones que tienen un significado juntos. Ejemplo: extraer una tabla de origen, crear una dimensión o actualizar una tabla de hechos. El objetivo aquí es administrar las dependencias entre los procesos: la actualización de una tabla de hechos probablemente sólo debería permitirse si la actualización de las dimensiones correspondientes fue exitosa.

Un sistema de gestión de dependencias debería tener al menos las siguientes características:

• Ejecutar un proceso sólo si sus prerrequisitos se han ejecutado correctamente
• Después de un error, ofrezca la opción de volver a ejecutar todos los procesos o sólo los procesos que fallaron
• Trace el resultado de cada proceso (se ejecutó correctamente, falló, no se ejecutó)
• Ejecutar dinámicamente procesos dependientes (en vez de estaticamente, es decir, basados ​​en fecha / hora)

Las posibilidades

Vamos a enumerar algunas de las posibilidades ofrecidas por Data Services, con sus respectivos pros y contras.

1) Un trabajo con todos los procesos dentro. Esto es muy fácil de implementar, dinámico en términos de tiempos de ejecución, pero no permite las ejecuciones simultáneas. Lo que es más importante, significa que los fallos tienen que ser gestionados de manera que el fallo de un proceso no detenga todo el trabajo.

2) Un proceso por trabajo, con trabajos programados en momentos específicos. Esto es muy fácil de implementar, permite ejecuciones simultáneas, pero no es lo suficientemente dinámico. Si las duraciones del proceso aumentan con los meses / años, los trabajos pueden superponerse.

3) Un trabajo principal que llama a otros trabajos (por ejemplo, con comandos de ejecución o Servicios Web ).

4) Un proceso por trabajo, todos los trabajos se están programando en momentos específicos, pero la comprobación en una tabla de control si los pre-requisitos funcionaban bien. De lo contrario sólo dormir por algún tiempo antes de comprobar de nuevo.

5) Utilice el Programador BOE para gestionar trabajos basados ​​en eventos (cómo se describe bien en el SCN ). No lo he probado aún, pero me gusta este enfoque.

De forma predeterminada, las dos primeras posibilidades sólo gestionan el lado de "flujo" de la administración de dependencias (después de A, do B). Pero no manejan el lado condicional de la gestión de dependencias (hacer B sólo si A fue exitoso). En ambos casos, una tabla de control actualizada por secuencias de comandos SQL permitiría al ETL comprobar si los procesos de requisito previo se han ejecutado correctamente.

Lo que realmente no me gusta en las soluciones 2 a 5 es el hecho de que es difcil tener una visión general de lo que está pasando. Realmente no se puede navegar dentro de todo el ETL fácilmente. La solución 1 le da este resumen, pero a costa de tener un trabajo potencialmente enorme (sin la posibilidad de que los procesos se ejecuten simultáneamente).

También tenga en cuenta que las soluciones con varios trabajos necesitarán administrar la inicialización de las variables globales.

Lo que echo de menos en todas estas soluciones es un reinicio óptimo del ETL. Si 10 de mis 50 procesos fallaron, y sólo quiero reiniciar estos 10, ¿debo iniciarlos manualmente?

En mi siguiente post de blog voy a proponer una arquitectura que aborda este reinicio óptimo.

Hasta entonces, por favor, hágamelo saber sus pensamientos sobre cómo manejar sus dependencias de ETL. ¿Alguna de las 5 soluciones antes mencionadas? ¿Una mezcla? ¿Algo más? Y lo bien que funciona para usted.