Entonacion de procesos ETL en Data Stage Server

Muchas veces nos conseguimos con procesos que tardan mucho mas tiempo de lo debido. Para evaluar estos procesos debemos revisar como tenemos configurados los archivos Hash, realizando lo siguiente:


1- Evaluar si el tipo de hash fue creado tomando en cuenta la naturaleza de los datos que componen su clave: Numericos; alfanumericos; con mas variacion a la derecha; a la izquierda o el centro, Tamaño de la clave;.....etc, etc. De no estar creado tomando estos parametros en cuenta, el hash puede tener un performance de I/O bastante bajo y, por ende, los tiempos de ejecucion se pueden ir a niveles no esperados por las areas de negocio que esperan resultados lo mas pronto posible. (Ver opciones de creacion en el stage del hash).


2- Revisar si la memoria cache del servidor se esta utilizando de manera adecuada.


Muchas veces intentamos cargar en memoria todos los datos para conseguir tiempos de respuesta mas optimos, pero en ocasiones esto se vuelve en contra del mismo performance de toda la cadena ETL. Tratar en lo posible de subir a memoria solo lo que realmente sea necesario. Revisar en la opcion Pre-load file to Memory las alternativas de Enabled y Disabled.



3- Si se trabaja con Stage de DB2.

Si el stage de db2 es de salida.

Evaluar el Array size y el Transaction size. Estos dos parametros nos dan el tamaño de las paginas de datos a escribir y el commit, respectivamente. Se recomienda dejar los valores por Default (50 y 100), pero si se busca entonar el job podemos cambiarlos hasta lograr los tiempos de ejecucion deseados. Estos ajustes son de cambiar y probar. No conozco una formula que indique los valores a colocar segun el tamaño de archivo. Lo cierto es que para un archivo muy grande, no se le debe asignar un Transaction size muy grande, porque los commits serian igualmente muy grandes y como consecuencia, el proceso seria muy lento.



Si el stage de db2 es de entrada.

En este caso se puede ajustar el Prefetch row para determinar la cantidad de filas que el db2 devolvera cada vez que Data Stage demande informacion de la fuente de datos.



4- Revisar los Stages Transformer.

Chequera el uso de rutinas externas. Su uso excesivo degrada significativamente el performance de los jobs. En el caso de que se detecte que el uso de estas es el responsable de la lentitud, buscar las formas de aplicar el codigo dentro del mismo Transformer y de esta forma el calculo de la regla de negocios quedaria ejecutandose de manera local.