sábado, 6 de febrero de 2010
viernes, 17 de julio de 2009
miércoles, 8 de julio de 2009
Habilitador tecnologico para Auditorias de espacio en disco
Cuando hacemos procesos ETL con DataStage, se genera una gran cantidad de archivos temporales, permanentes, de trabajo, etc, etc. El volumen de datos de nuestras fuentes de datos (Source) se ve duplicado, triplicado y muchas veces cuadruplicado. Lo que hace que la administracion del espacio en disco sea vital para la buena salud de nuestros proyectos y de su correcta ejecucion diaria.
Para diseñar y desarrollar este habilitador tambien podemos utilizar DataStage. Tenemos todas las herramientas para hacerlo: Comandos Unix, rutinas DataStage de ejecucion de estos comandos, stages para envio de archivos de datos por email, etc.
Este Auditor diario toma informacion de los tamaños actuales de cada uno de los file systems, archivos planos y archivos hash y los guarda en otro archivo .txt. Luego, al siguiente dia vuelve a tomar esta misma informacion y la guarda en otro archivo plano.
Una vez generados estos archivos planos, efectua una comparacion de los tamaños de los file systems, archivos planos y hash y genera un informe, indicando:
- Variacion en volumen y porcentaje de los file systems.
- Variacion en volumen y porcentaje de los archivos planos y hash.
- Archivos hash que estan llegando a un nivel critico y pudieran corromperse.
- Logs de jobs con grandes volumenes de warnings y que ponen en riesgo la estabilidad del proyecto DataStage en el cual estan alojados.
Estas alertas se envian segun parametrizacion del proceso Auditor. los niveles criticos de crecimiento y porcentajes se le envian por parametros y solo se envian avisos de los componentes que se encuentren por encima de estos niveles.
Con este habilitador los monitoreos ya no seran manuales, porque lo podemos agendar a traves del planificador y dejar que el mismo envie los mensajes de alerta.
Otro espacio de tiempo disponible para el admistrador ETL!!!!!.
Para diseñar y desarrollar este habilitador tambien podemos utilizar DataStage. Tenemos todas las herramientas para hacerlo: Comandos Unix, rutinas DataStage de ejecucion de estos comandos, stages para envio de archivos de datos por email, etc.
Este Auditor diario toma informacion de los tamaños actuales de cada uno de los file systems, archivos planos y archivos hash y los guarda en otro archivo .txt. Luego, al siguiente dia vuelve a tomar esta misma informacion y la guarda en otro archivo plano.
Una vez generados estos archivos planos, efectua una comparacion de los tamaños de los file systems, archivos planos y hash y genera un informe, indicando:
- Variacion en volumen y porcentaje de los file systems.
- Variacion en volumen y porcentaje de los archivos planos y hash.
- Archivos hash que estan llegando a un nivel critico y pudieran corromperse.
- Logs de jobs con grandes volumenes de warnings y que ponen en riesgo la estabilidad del proyecto DataStage en el cual estan alojados.
Estas alertas se envian segun parametrizacion del proceso Auditor. los niveles criticos de crecimiento y porcentajes se le envian por parametros y solo se envian avisos de los componentes que se encuentren por encima de estos niveles.
Con este habilitador los monitoreos ya no seran manuales, porque lo podemos agendar a traves del planificador y dejar que el mismo envie los mensajes de alerta.
Otro espacio de tiempo disponible para el admistrador ETL!!!!!.
Habilitador tecnologico para monitorear procesos en Data Stage
Cuando tenemos grandes cadenas de ejecucion, muchas veces nos preguntamos: ¿Cuantos procesos corren en paralelo?, ¿Hay algun cuello de botella (Bottle Neck)?, ¿Tengo tiempos ociosos que valen oro y no los utilzo?, etc, etc, etc.
Con el Director de DataStage podemos visualizar las estadisticas de ejecucion (Tiempos de corrida, comienzo, fin, logs, warnings, status, etc), pero no ese nivel de detalle que se necesita como para aplicar reingenieria de procesos a mis cadenas de ejecucion, cuando estamos sobrepasando las ventanas de tiempo para la entrega de la informacion a nuestros preciados clientes de las distintas areas de negocio. Puede ser que el tope de mi ventana de tiempo sea las 8am y mis procesos ETL terminan a las 11am. En este caso tenemos 3 horas de retraso en la entrega de mis datos al Data Warehouse, por ejemplo.
Con la herramienta DataStage podemos hacer muchas cosas, tales como tomar las estadisticas de ejecucion y aplicarle procesos de Transformacion y generar informacion relevante para los administradores ETL.
Entre la informacion generada puedo mencionar:
- Paralelismo de procesos.
- Cuellos de botella (Bottle neck).
- Tiempos 'vacios', ociosos o sin uso.
Incluso, esta informacion podemos distribuirla por periodos de tiempo, por ejemplo cada 3 horas, o cada 30 minutos, o cada 15 minutos, intervalos de tiempo tan grandes o pequeños como se deseen.
El resultado seria una matriz indicandonos como se comporto la cadena ETL desde el primer job de Extraccion hasta el ultimo job de Carga de los datos.
Este utilitario ya se ha probado dando excelentes resultados que sirven de insumo para la toma de decisiones.
Mi recomendacion es que usemos la misma herramienta DataStage para generar utilitarios que nos hagan la vida lo mas tranquila y armonica posible, es decir Calidad de Vida en nuestro rol de Administradores y ocuparnos de otros topicos que no se puedan automatizar.
Con el Director de DataStage podemos visualizar las estadisticas de ejecucion (Tiempos de corrida, comienzo, fin, logs, warnings, status, etc), pero no ese nivel de detalle que se necesita como para aplicar reingenieria de procesos a mis cadenas de ejecucion, cuando estamos sobrepasando las ventanas de tiempo para la entrega de la informacion a nuestros preciados clientes de las distintas areas de negocio. Puede ser que el tope de mi ventana de tiempo sea las 8am y mis procesos ETL terminan a las 11am. En este caso tenemos 3 horas de retraso en la entrega de mis datos al Data Warehouse, por ejemplo.
Con la herramienta DataStage podemos hacer muchas cosas, tales como tomar las estadisticas de ejecucion y aplicarle procesos de Transformacion y generar informacion relevante para los administradores ETL.
Entre la informacion generada puedo mencionar:
- Paralelismo de procesos.
- Cuellos de botella (Bottle neck).
- Tiempos 'vacios', ociosos o sin uso.
Incluso, esta informacion podemos distribuirla por periodos de tiempo, por ejemplo cada 3 horas, o cada 30 minutos, o cada 15 minutos, intervalos de tiempo tan grandes o pequeños como se deseen.
El resultado seria una matriz indicandonos como se comporto la cadena ETL desde el primer job de Extraccion hasta el ultimo job de Carga de los datos.
Este utilitario ya se ha probado dando excelentes resultados que sirven de insumo para la toma de decisiones.
Mi recomendacion es que usemos la misma herramienta DataStage para generar utilitarios que nos hagan la vida lo mas tranquila y armonica posible, es decir Calidad de Vida en nuestro rol de Administradores y ocuparnos de otros topicos que no se puedan automatizar.
lunes, 6 de julio de 2009
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.
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.
Suscribirse a:
Entradas (Atom)