El Rincon del BI

Descubriendo el Business Intelligence…

Archive for the ‘Talend’ Category

Webminar sobre Talend Open Profiler (Data Profiling)

Posted by Roberto Espinosa en 29 octubre 2010


Ayer asistí al Webminar que Talend presento sobre su producto de Data Profiling y Calidad de Datos, llamado Talend Open Profiler. Conocía un poco el producto de una rapida review que realice en mi blog hace unos meses, hablando sobre el tema de la identificación de los origenes de datos para la construcción de un DW y los tipos de herramientas necesarios para esa tarea (incluida la revisión de la calidad de los datos, tan necesaria para el éxito de un proyecto de BI).

Configuracion de conexiones a BD y navegación por el catálogo

En la presentación se explicaron los diferentes productos que tiene Talend (Talend Open Studio/Integration Suite para Integración de Datos, Talend Open Profiler/Talend Data Quality para calidad de datos y Talend MDM para gestión de datos maestros). Además, se realizo una demo sencilla para ver las posibilidades de Talend Open Profiler revisando datos maestros de clientes de un portal de ventas Web (en concreto, los datos de direcciones de Email).

La herramienta nos permite navegar por nuestros esquemas de tablas en la base de datos y ademas realizar una serie de análisis como:

  • Overview Analysis: analiza los esquemas de base de datos, devolviendonos información sobre tablas, filas, número de registros, indices, etc.
  • Table Analysis: análisis sobre la definición de una tabla, verificaciones de dependencias, etc.
  • Column Analysis: analisis especifico sobre el contenido de un campo. Para cada campo, se pueden seleccionar los indicadores de análisis (tales como valores estadísticos, número de registros, valores nulos, longitud mínima, longitud máxima, valores duplicados, etc.). Además, podremos indicar patrones de validación sobre los campos, para verificar que están correctamente definidos (tanto con expresiones regulares como con patrones sql).

En el análisis de campos, además de la utilización de estadísticas sobre los valores de los campos o el análisis de patrones predefinidos, podemos configurar nuestros propios patrones utilizando expresiones  regulares o  SQL, lo que nos da una gran potencia de personalización de las verificaciones que podemos realizar sobre los valores de los campos. También podremos construir nuestro propios indicadores personalizados para obtener información especifica sobre los campos o realizar análisis de frecuencia de patrones en el contenido de estos.

Al analizar la información de los análisis realizados, la herramienta nos permite, a partir de los gráficos de resultados, acceder a los registros específicos asociados. Por ejemplo, si hay campos que no cumplen un determinado patrón, podremos entrar a visualizarlos para establecer las correspondientes medidas de corrección sobre ellos o tenerlo en cuenta en la definición de nuestros procesos ETL.

Ejemplo de análisis de un campo

Si estaís interesados en conocer mas sobre estas herramientas, podeís visualizar los diferentes Webminar que la gente de Talend prepara regularmente para hablar de sus productos (tanto de iniciación como de casos prácticos concretos).

Anuncios

Posted in Data Profiling, Talend | Leave a Comment »

16.4. Comparativa ETL Talend vs Pentaho Data Integration (Kettle).

Posted by Roberto Espinosa en 1 junio 2010


(Read in English language here)

Vamos a intentar en esta ultima entrada de la serie de procesos ETL realizar una comparativa lo mas completa posible de las herramientas Talend Open Studio y Pentaho Data Integration (Kettle), que hemos estado utilizando en los últimos meses. Para que este estudio sea lo mas completo y riguroso posible, vamos a dividir esta tarea en 5 secciones:

 

Ejemplo de proceso ETL utilizando Talend

  • Tabla de características.
  • Ejemplos de Uso.
  • Cuadro de puntos fuertes/puntos debiles.
  • Links de recursos (comparativas e informacion adicional).
  • Conclusiones.

Tabla de Características.

Producto TALEND OPEN STUDIO ver.4.0 PENTAHO DATA INTEGRACION CE (KETTLE) ver 3.2
Fabricante Talend – Francia Pentaho – Estados Unidos
Web www.talend.com www.pentaho.com
Licencia GNU Lesser General Public License Version 2.1 (LGPLv2.1) GNU Lesser General Public License Version 2.1 (LGPLv2.1)
Lenguaje de desarrollo Java Java
Año de lanzamiento 2006 2000
Entorno gráfico Herramienta gráfica basada en Eclipse Herramienta de diseño (Spoon) basada en SWT
Entorno de ejecución Desde la herramienta de diseño, o a nivel de línea de comandos con Java o Perl (independiente de la herramienta) Desde la herramienta de diseño, o desde línea de comandos con las utilidades Pan y Kitchen.
Características Con la herramienta de diseño construimos los Jobs, utilizando el set de componentes disponibles.Trabaja además con el concepto de proyecto, que es un contenedor de los diferentes Jobs que lo forman y sus metadatos y contextos.Talend es un generador de código, de forma que los Jobs definidos son traducidos al correspondiente lenguaje (podemos elegir Java o Perl al crear un proyecto), compilados y ejecutados.Los componentes se enlazan entre si con diferentes tipos de conexiones. Una son de paso de información (que pueden ser del tipo Row o Iterate, segun la forma de pasar los datos). Ademas, se pueden conectar unos con otros con conexiones disparadoras (Run If, If Component Ok, If Component Error), que nos permiten articular la secuencia de ejecución y su control.Una vez se termina el diseño de los trabajos, se exportan a nivel de SO, y se pueden ejecutar independientemente de la herramienta de diseño en cualquier plataforma que permita la ejecución del lenguaje seleccionado. Además, todo el código generado es visible y modificable (aunque lo modifica la herramienta al realizar cualquier cambio en los Jobs). Con la herramienta de diseño Spoon construimos las transformaciones (mínimo nivel de diseño) utilizando los pasos o steps. En un nivel superior tenemos los Jobs, que permiten ejecutar las transformaciones y otros componentes, y orquestar los procesos.PDI no es un generador de código, es un motor de transformación, donde los datos y sus transformaciones están separadas.Las Transformaciones y Jobs son almacenadas en formato XML, donde se especifican las acciones a realizar en los datos.Para construir las transformaciones, se utilizan los pasos o componentes, que se enlazan entre si mediante saltos o steps, que determinan el flujo de datos entre los diferentes componentes.Para los jobs, tenemos otro set de pasos, en los que podemos realizar diferentes acciones (o ejecutar transformaciones). Los steps o saltos en este caso determinan el orden de ejecución o la ejecución condicional.
Componentes Talend tiene una gran cantidad de componentes. El enfoque es tener un componente distinto según la acción a realizar, y para el acceso a   base de datos u otro sistemas, hay componentes diferentes según el motor de base de datos al que vayamos a atacar. Por ejemplo, tenemos un table input para cada fabricante (Oracle, MySQL, Informix, Ingres) o uno para la gestión de SCD para cada SGBDR. Podeis ver la lista de componentes disponibles aquí. Set mas reducido de componentes, pero muy orientados a integración de datos. Para acciones similares (por ejemplo, lectura de tablas de BD), un único paso (no uno por cada fabricante), y el comportamiento según la base de datos lo define la conexión. Los elementos disponibles son: para las transformaciones ver aquí y para los jobs aquí.
Plataforma Windows, Unix y Linux. Windows, Unix y Linux.
Repositorio Trabaja con el concepto de workspace, a nivel de sistema de ficheros. En ese lugar se almacenan todos los componentes de un proyecto (todos los Jobs, su definición de metadatos, código personalizado y contextos). El repositorio se actualiza con las dependencias de objetos al ser modificados (se expanden a todo el proyecto los cambios). Si modificamos el repositorio de una tabla, por ejemplo,  se actualiza en todos los Jobs donde se utiliza. Los Jobs y transformaciones son almacenados en formato xml. Podemos elegir almacenar a nivel de sistema de fichero o en el repositorio de base de datos (para trabajo en equipo). No se actualizan las dependencias si modificamos una transformación llamada desde otra, por ejemplo. Si a nivel de componentes dentro de una misma transformación o job.
Metadatos Completo metadata que incluye las conexiones a base de datos y los objetos de esta (tablas, vistas, querys). Al traer el metadata de los objetos de BD deseados, no se vuelve a acceder al sistema origen o destino, lo que agiliza los procesos. Además, podemos definir metadatos de estructuras de ficheros (delimitados, posicionales, Excel, xml, etc), que luego pueden ser reutilizados en cualquier componente. Se almacenan de forma centralizada en el repositorio (workspace) EL metadata se limita a las conexiónes de base de datos, que si pueden ser compartidas por diferentes transformaciones y jobs.La información de metadata de base de datos (catalogo de tablas/campos) o de ficheros esta en los pasos y no se puede reutilizar. Además se lee en el momento de diseño.
Contextos Set de Variables que se configuran en el proyecto y que se pueden utilizar luego en los Jobs para personalizar su comportamiento (por ejemplo para definir entorno de desarrollo y productivo). Uso de variables en fichero de parámetros de la herramienta (fichero kettle. Properties). Paso de parámetros y argumentos a los procesos (similar a los contextos).
Versiones Nos permite realizar una completa gestión del versionado de objetos (pudiendo recuperar versiones anteriores) Funcionalidad prevista en la versión 4.0.
Lenguajes para definir componentes propios (scripting) Talend nos permite introducir nuestro código personalizado utilizando Java y Groovy.Además podemos realizar scripting en SQL y Shell. PDI utiliza JavaScript para los cálculos y formulas.Ademas podemos realizar scripting con SQL, Java, Shell y formulas Open Office.
Herramientas complementarias Talend dispone de herramientas complementarias para Data Profiling y Gestión de Datos Maestros (MDM). En Open Studio tenemos una herramienta de modelado sencilla para dibujar procesos y modelos lógicos. PDI ofrece en la versión 4.0 la funcionalidad Agile para modelado dimensional y su publicación en Pentaho BI.
Plugins Descarga de nuevos componentes a través de Talend Exchange. Incorporación de plugins adicionales en la web.
Soporte Un completa comunidad online con Talend’s wiki, Talend Forum y bugtracker, para la gestión de incidencias y Bugs. Incluye el Pentaho forum, Issue Tracking y la Pentaho Community.
Documentación Completa documentación en pdf que incluye: Manual de Instalación, Manual de Usuario y Documentación de componentes. Documentación Online en la web. Libros: Data Integration-Pentaho 3.2 Beginner’s Guide(M.C.Roldan), Pentaho Kettle Solutions (M.Casters, R.Bouman, J.van Dongen).

Ejemplos de Uso.

EJEMPLO TALEND OPEN STUDIO PENTAHO DATA INTEGRATION (KETTLE)
Carga de dimensión tiempo de un DW Proceso ETL para la carga de la Dimensión Tiempo. Ejemplo de uso de la ETL Talend. ETL Dimensión Tiempo con PDI.
Ejecución de sentencias sql dinámicas Mas ejemplos de Talend. Ejecución de sentencias SQL construidas en tiempo ejecución. Paso de parametros y operaciones dinamicas en una transformación de PDI.
Carga de dimensión producto de un DW ETL para carga Dimension Producto. Mas ejemplos de Talend. Uso de logs, metricas y estadisticas. ETL Dimensión Producto con PDI (I). Extraccion a Stage Area.ETL Dimensión Producto con PDI (II). Carga al DW.
Carga de dimensión cliente de un DW ETL Talend Dimension Cliente.Tipos de Mapeo para lookup. ETL Dimensión Cliente con PDI.
Tratamiento de dimensiones lentamente cambiantes Gestión de SCD (Dimensiones lentamente cambiantes). Tratamiento de Dimensiones Lentamente Cambiantes (SCD) con PDI.
Conexión al ERP Sap Ejemplo Talend para conectarnos a Sap Ejemplo Kettle para conectarnos a Sap (con el plugin ProERPConn)
Carga de tablas de hechos de ventas en un DW Tabla Hechos Venta. Ajuste diseño fisico y procesos carga ETL. Contextos en Talend. ETL Carga de hechos de ventas con PDI.ETL Carga de hechos de presupuestos con PDI.
Exportación de Jobs y planificación procesos Exportación jobs en Talend.Planificacion procesos ETL.
Tratamiento de datos públicos Modelo de Datos y Procesos de Carga del DW de datos públicos de Londres.
Explicación de la interfaz de usuario Construccion procesos ETL utilizando Kettle (Pentaho Data Integration)
Proyecto de Grado (comparativa Pentaho/JasperETL). Realizado por Rodrigo Almeida y Mariano Heredia Proyecto fin de carrera donde se detalla un proyecto de Business Intelligence, utilizando las herramientas de Pentaho y Jasper. En la parte de ETL´s, se compara Kettle con JasperETL (basado en Talend). Descarga del libro en la web: http://sites.google.com/site/magm33332/bifloss. Incluye un magnifico detalle de las características de cada herramienta.

Como ejemplos adicionales, podeis consultar igualmente:

  • Tutorial de Talend Open Studio 4 realizado por Victor Javier Madrid en la web adictosaltrabajo.com. Incluye otro ejemplo para procesar un fichero EDI con Talend.
  • Libro blanco de las heramientas ETL Open Source, realizado en frances por Atol. Incluye una serie de ejemplos prácticos muy completos.

 

Ejemplo de proceso ETL utilizando Pentaho Data Integration

Cuadro de puntos fuertes/puntos debiles.

Desde mi punto de vista, con la experiencia de utilización de las dos herramientas y la información recopilada sobre las herramientas y la experiencia de usuarios, puedo destacar los siguientes aspectos:

TALEND OPEN STUDIO PENTAHO DATA INTEGRATION (KETTLE)
Es un generador de código, y este aspecto hace que tenga una gran dependencia del lenguaje elegido en los proyectos (Java en mi caso). Al elegir Java, tenemos todas las ventajas e inconvenientes de este lenguaje. Se necesita tener un nivel alto de este lenguaje para sacarle el máximo partido a la aplicación. Es un motor de transformación, y desde el principio se observa que ha sido diseñado por gente que necesitaba cubrir sus necesidades en la integración de datos, con gran experiencia en ese ámbito. Igualmente, es mas fácil gestionar los tipos de datos con PDI, pues no es tan riguroso como Java.
Herramienta poco intuitiva y difícil de entender, pero una vez superada esta dificultad inicial se observan las grandísimas posibilidades y la potencia de la aplicación. La herramienta es muy intuitiva, y con unos conceptos básicos te puedes poner a hacer cosas. Conceptualmente muy sencilla y potente.
Interfaz de usuario unificada en todos los componentes. Basada en Eclipse, el conocimiento de la herramienta nos facilita el uso de la interfaz. El diseño de la interfaz puede resultar un poco pobre, y no hay una interfaz unificada en todos los componentes, siendo en ocasiones la interfaz de los componentes confusa.
La empresa Talend esta invirtiendo gran cantidad de recursos en su desarrollo (gracias a aportaciones de capital de varios fondos de inversión), lo que esta produciendo una evolución muy rápida de la herramienta. Se observa un gran potencial de futuro. El producto además se esta complementando con otras herramientas para Data Profiling y MDM. Evolución mucho más lenta de la herramienta e incierta, pues Pentaho tiende a abandonar la parte Open.
Gran disponibilidad de componentes para conectarnos a múltiples sistemas y orígenes de datos, y en continua evolución. Disponibilidad de componentes más limitada, aunque más que suficiente para la mayoría de procesos ETL o de integración de datos.
Aunque no disponemos de un repositorio en base de datos para trabajo en equipo (si en las versiones de pago), el trabajo con el Workspace nos da muchas posibilidades, al trabajar con el concepto de proyecto. Muy útil el análisis y actualización de dependencias cuando se modifican elementos (que son distribuidos a todos los Jobs de un proyecto). El repositorio en base de datos nos da muchas posibilidades para el trabajo en equipo. En este repositorio se almacenan los xml que contienen las acciones que realizan sobre los datos las transformaciones y los Jobs.
Enfoque un componente por cada fabricante en los elementos para trabajar con bases de datos. Enfoque un único componente por tipo de acción sobre la base de datos (y las características de la conexión utilizada son las que determinan su comportamiento).
Ayuda contextual en la aplicación. Completa ayuda online de los componentes. Cuando diseñamos nuestros propios controles en Java, tenemos la ayuda contextual del lenguaje proporcionada por Eclipse. Ayuda muy pobre, casi inexistente en la aplicación. La ayuda online en la web de Pentaho no es especialmente completa, y en algunos componentes es muy reducida, de forma que la única forma de averiguar el funcionamiento del componente es probándolo.
Logs: podemos configurarlos a nivel de proyecto o en cada uno de los Jobs. Indicando si queremos sobrescribir la configuración del proyecto en ese aspecto. El log se puede enviar a base de datos, a consola o a ficheros. La funcionalidad esta muy desarrollada, distinguiendo logs de estadísticas, de métricas de procesos y de los logs propiamente dichos (para gestionar los errores). Logs: diferentes niveles de logs (desde el más básico, hasta el nivel de cada registro). Suficiente para analizar las ejecuciones de las transformaciones y jobs. Posiblidad de registrar log en base de datos, aunque muy limitado. Los logs se configuran a nivel de transformaciones y Jobs.
Debug: con la perspectiva Debug de Eclipse, podemos seguir la traza de la ejecución (viendo el código fuente) tal y como si estuviéramos programando en Eclipse. También se puede incluir visualización de estadísticas y datos de traza o tiempos de respuesta en la ejecución de la herramienta gráfica. Debug: contiene una sencilla herramienta de debug, muy básica.
Versionado de objetos: en el Workspace tenemos una completa gestión de versionado de Jobs (con minus y major number). Nos permite recuperar las versiones anteriores en caso de problemas. Dispone de una herramienta para modificación masiva de versiones de objetos (puede ser muy util para realizar el versionado de distribuciones). El versionado de objetos esta previsto que se incluya en la versión 4.0.
Paralelismo: muy reducido en las versiones Open. Funcionalidad avanzada en las versiones de pago (Integration Suite). Paralelismo: es muy sencillo realizar paralelismo de procesos con la opcion Distribute Data en la configuración del paso de información entre pasos, aunque habrá que llevar cuidado con las incosistentencias según el tipo de proceso.
Generación de documentación automática en HTML de los Jobs. Incluye visualización gráfica de los diseños, tablas de propiedades, documentación adicional o textos explicativos que hayamos introducido en los componentes, etc. Podéis ver un ejemplo aquí. No se puede generar documentación de las transformaciones y Jobs. A nivel gráfico, podemos incluir notas con comentarios en el dibujo de los procesos. Con el proyecto kettle-cookbook se puede generar documentacion en html.
Herramienta sencilla para modelado gráfico. En ella podemos dibujar de forma conceptual los diseños de nuestras Jobs y procesos.
Generación continúa de nuevas versiones, que incorporan mejoras y arreglo de Bugs. La generación de nuevas versiones no es muy frecuente, y tenemos que generarnos nosotros mismos las versiones actualizadas con los últimos fuentes disponibles: Ver entrada del Blog de Fabian Schladitz.
Talend Exchange: lugar donde la comunidad elaborar sus propios componentes y los comparte con el resto de usuarios. Pentaho también dispone de colaboradores que desarrollan y liberan plugins en su web, aunque con menos actividad que Talend.
Como punto negativo, en ocasiones se nota en demasía la lentitud ocasionada por el uso de Java. Como punto negativo, algunos componentes no se han comportando de la forma esperada, al realizar transformaciones muy complejas o al enlazar llamadas entre diferentes transformaciones a Jobs. Los problemas se pudieron superar cambiando el diseño de las transformaciones.
Es una ventaja tener un repositorio en local, donde nos guardamos en local la parte que nos interesa de la información de bases de datos, tablas, vistas, estructuras de ficheros (texto, Excel, xml). Al estar en el repositorio, se pueden reutilizar en los componentes asociados y no se tiene que volver a leer de los orígenes de datos su metadata cada vez que se usa (para el caso de las bases de datos, por ejemplo). Dispone de un asistente de construcción de querys (SQL Builder) muy potente y con muchas funcionalidades. Cuando trabajamos con bases de datos con catálogos muy grandes, es incomodo tener que recuperarlo entero para poder construir, por ejemplo, una sentencia sql para leer de una tabla (cuando utilizamos la opción de navegación por el catalogo).
Reutilización de código: podemos incluir nuestras propias librerías, que son visibles en todos los Jobs de un proyecto. Esto nos permite de alguna manera diseñar nuestros propios componentes. El código escrito en JavaScript dentro de los componentes no se puede reutilizar en otros componentes. Bastante limitado para añadir nuevas funcionalidades o modificar las existentes.
Control del flujo en los procesos: tenemos por un lado flujo  de datos (row, iterate o row lookup) y por otro lado disparadores para control de ejecución y orquestación de procesos. La combinación row e iterate es muy útil para orquestar procesos del tipo bucle, con el objetivo de repetir tareas. Hay un inconveniente importante que nos puede complicar el diseño de los jobs, y es que no se pueden juntar varios flujos de datos que provengan del mismo origen (han de tener un diferente punto de partida), nunca se han de cruzar en un elemento padre común. Control del flujo en los procesos: se pasa la información entre componentes (pasos) con los saltos, de una forma única, y el flujo resultante varía según el tipo de control. Esta forma de interactuar tiene limitaciones para el control de procesos iterativos. Como característica interesante, la encapsulación de transformaciones a traves de los mappings, que nos permite definir transformaciones para procesos repetitivos (similar a una funcion).
Gestión de errores: cuando se producen errores, podemos gestionar el log, pero perdemos el control. Gestión de errores: con la gestión de errores en los pasos que lo permiten, podemos interactuar con esos errores y solucionarlos sin terminar el proceso (no es siempre posible).
Ejecución: bien desde la herramienta (que a veces es muy lenta, sobre todo si incluimos estadísticas y trazas de ejecución). Para ejecutar a nivel de línea de comandos, se exportan los Jobs. La exportación genera todos los objetos (librerias jar) necesarias para poder ejecutar el trabajo, incluyendo un .bat o .sh para ejecutarlo. Esta forma de exportar los Jobs nos permite llevarlos a cualquier plataforma donde se pueda ejecutar el lenguaje java o perl, sin necesidad de tener instalado Talend. Ejecución: bien desde la herramienta (tiempos de respuesta bastante buenos) o bien a nivel de comandos con Pan (para las transformacionse) y Kitchen( para los jobs). Son dos utilidades muy sencillas y funcionales que nos permiten ejecutar los xmls de los diseños (bien desde fichero o desde el repositorio). Siempre es necesario tener instalado PDI para poder ejecutar las herramientas. También disponemos de la herramienta Carte, que es un sencillo servidor web que permite la ejecución remota de jobs y transformaciones.

Comparativas e Información adicional.

Benchmark entre Pentaho Data Integration y Talend realizado por Matt Caster. http://www.ibridge.be/?p=150. Opiniones sobre la prueba en el blog de Gobán Saor y Nicholas Goodman
Comparativa entre Kettle y Talend, realizada por Vicent McBurnety (año 2007) http://it.toolbox.com/blogs/infosphere/wiki-wednesday-comparing-talend-and-pentaho-kettle-open-source-etl-tools-16294
Comparativa entre Kettle, Talend y CloverETL. http://www.cloveretl.org/_upload/clover-etl/Comparison%20CloverETL%20vs%20Talend%20and%20Pentaho.pdf
Benchmark entre PDI, Talend, Datastage e Informatica http://it.toolbox.com/blogs/infosphere/etl-benchmark-favours-datastage-and-talend-28695
Comparativa de funcionalidades y benchmark entre Talend y PDI http://www.atolcd.com/fileadmin/Publications/Atol_CD_Livre_Blanc_ETL_Open_Source.pdf
Comparativa entre PDI e Informatica http://www.jonathanlevin.co.uk/2008/03/pentaho-kettle-vs-informatica.html
Tabla comparada de características en la web Openmethodology.org Talend vs PDI (Kettle).
Ejemplo sencillo comparado Kettle y Talend http://forums.pentaho.org/showthread.php?t=57305
Comparativa de herramientas ETL realizada por la empresa Adeptia. http://www.adeptia.com/products/etl_vendor_comparison.html
Pentaho Kettle Open Source Review http://www.datawg.com/pentaho-kettle-open-source-etl-tool-review.html
Benchmark entre Pentaho Data Integration y Talend realizado por Marc Russel. http://marcrussel.files.wordpress.com/2007/08/benchmark-tos-vs-kettle.pdf
Comparativa entre Datastage, Talend, Informatica y PDI (Manapps). http://marcrussel.files.wordpress.com/2009/02/etlbenchmarks_manapps_090127.pdf
Presentación PowerPoint comparativa Kettle vs Talend http://svn2.assembla.com/svn/bbdd_dd/Presentaciones/Kettle%20Vs%20Talend.pptx
EOS: Open Source Directory. http://www.eosdirectory.com/project/397/Talend+Open+Studio.html vs http://www.eosdirectory.com/project/202/KETTLE++pentaho+data+integration+.html

Conclusiones.

Desde mi punta de vista, creo que ambas herramientas son complementarias. Cada una con un enfoque, pero permiten realizar las mismas tareas de transformación e integración de datos. El producto Talend tiene para mi mas recorrido, pues se estan poniendo muchos recursos en su desarrollo, y se esta complementando con otras herramientas para crear una verdadera suite de integración de datos. También se utiliza en el proyecto de Jaspersoft. Igualmente, el hecho de ser mas abierto y poder ser complementado con el uso del lenguaje Java también le da ciertas ventajas con respecto a Pentaho.

Por otro lado, Pentaho Data Integration es una herramienta muy intuitiva y facil de utilizar. Se nota desde el principio cuando se empieza a usar, como ya mencione, que esta desarrollada bajo el prisma de las problematicas de procesos ETL y transformación de datos. En algunas aspectos se le ve más rápida y ágil que Talend, al no tener que estar moviendo generación de código Java en todo momento. Aunque si se echa de menos la gestión de un repositorio de proyectos verdaderamente integrado, como en Talend, y con un metadatos independiente de los origenes/destinos de datos.

A nivel de rendimiento, y revisando las diferentes comparativas, tampoco se ve un claro ganador. Una herramienta es mas rapida en algunas cosas (Talend en calculo de agregaciones o Lookups), mientras Pentaho es mas rápido, por ejemplo en el tratamiento de SCD o con los procesos de paralelización. En mis procesos ETL tampoco ha habido unas grandes diferencias de rendimiento, aunque si me ha parecido ligeramente más ágil Pentaho a la hora de realizar los procesos masivos.

Teniendo en cuenta todo lo visto (y todo lo detallado en los puntos anteriores), yo me decanto ligeramente a favor de Talend, aunque antes de elegir una herramienta para un proyecto, yo realizaría un estudio profundo del tipo de trabajos y casuisticas a las que nos vamos a enfrentar en el diseño de nuestros procesos antes de decantarme por una u otra herramienta. Seguramente habrá factores especificos que pueden recomendar el uso de una u otra (como la necesidad de conectarnos a determinada aplicación o las plataformas donde ejecutar los procesos). Y lo que esta claro en ambos casos, es que cualquiera de las dos nos podría valer para los procesos de construcción de un DW en un entorno real (como he demostrado en este blog con toda la serie de ejemplos publicados).

Si habeis trabajado con alguna de las herramientas, o ambas, quizas tengais algo que añadir a esta comparativa. Espero vuestras opiniones.

Actualización 18.06.10

Os dejo el link al ultimo estudio de Gartner sobre Integración de Datos, publicado en noviembre de 2009:

Magic Quadrant for Data Integration Tools.

En el ultimo estudio se ha incluido a Talend como un proveedor emergente de herramientas de Integración de Datos. Si estáis pensando en trabajar con Talend, se dicen cosas interesantes (tanto Pro´s como contras) sobre la evolución del producto y su futuro:

Puntos Fuertes:

  • Dos niveles: nivel de entrada con herramienta Open Source gratuita (Talend Open Studio) y nivel superior con herramienta de pago con mas funcionalidades y soporte (Talend Integration Suite).
  • Talend esta consiguiendo casi por unanimidad resultados positivos en las empresas. Aunque el factor determinante inicial puede ser su precio, sus características y funcionalidades son el segundo factor determinante de su exito.
  • Buena conectividad en general. Complementada con las herramientas de Data Profiling y Data Quality. El paso de las versiones Open a las de pago no requiere curva de aprendizaje adicional.

Precauciones:

  • Hay escasez de expertos en la herramienta, aunque se esta desarrollando una red de alianzas con otras empresas y desarrollando su red comercial (aunque no estan en todas las regiones).
  • Existen algunos problemas en las herramientas de pago con el repositorio central (que no esta en la versión  Open), cuando se trabaja para coordinar trabajos de desarrollo. Parece que lo estan intentando solucionar en las nuevas versiones.
  • Algunos clientes han reportado que la documentación es errónea y algún problema en la gestión de los metadatos. Igualmente, es necesario disponer de un experto en Java o Perl para sacarle todo el partido a la herramienta (como indicamos en la comparativo con Pentaho).

Os recomiendo la lectura del informe, se dicen cosas muy interesantes en general sobre las herramientas de integración de datos y en particular si estais buscando información de alguna en concreto (como es Talend, el objeto de esta comparativa de productos).

Posted in ETL, Kettle, Pentaho, Talend | 11 Comments »

ETL´s: Talend Open Studio vs Pentaho Data Integration (Kettle). Comparative.

Posted by Roberto Espinosa en 1 junio 2010


(Read in Spanish language here)

Let’s try in this latest entry of the ETL processes series to make a comparison as complete as possible of Tools Talend Open Studio and Pentaho Data Integration (Kettle), which we have been using in last months. For this study to be as comprehensive and rigorous as possible, we will divide the task in 5 sections:

 

Using Talend Open Studio in ETL Process Design

  • Property table.
  • Examples of Use
  • Strengths / weaknesses table.
  • Resource Links (comparative and additional information.)
  • Final opinion.

Property table.

Product TALEND OPEN STUDIO ver.4.0 PENTAHO DATA INTEGRACION CE (KETTLE) ver 3.2
Manufacturer Talend – France Pentaho – United States
Web www.talend.com www.pentaho.com
License GNU Lesser General Public License Version 2.1 (LGPLv2.1) GNU Lesser General Public License Version 2.1 (LGPLv2.1
Development Language Java Java
Release Year 2006 2000
GUI Graphical tool based on Eclipse Design Tool (Spoon) based on SWT
Runtime Environment From design tool, or command line with Java or Perl language (independent of the tool) From design tool, or command line with utilities  Pan and Kitchen .
Features With the design tool build the Jobs, using the set of components available.Work with project concept, which is a container of different Jobs with metadata and contexts. Talend is a code generator, so Jobs are translated into corresponding defined language (Java or Perl can choose when create a new project), compiled and executed .Components bind to each other with different types of connections.  One is to pass information (which may be of Row or Iterate, as how to move the data).  Also, you can connect with each other triggering connections (Run If, If Component Ok, If Component Error) that allow us to articulate the sequence of execution and ending time control.Jobs are exported at SO, and can run independently of the design tool on any platform that allows the execution of the selected language.  In addition, all generated code is visible and modifiable (although you modify the tool to make any changes to the Jobs). With the design tool built Spoon transformations (minimum design level) using the steps. At a higher level we have the Jobs that let you run the transformations and other components, and orchestrate process. PDI is not a code generator, is a transformation engine, where data and its transformations are separated.The transformations and Jobs are stored in XML format, which specifies the actions to take in data processing. In transformations use steps, which are linked to each other by jumps, which determine the flow of data between different components. For the jobs, we have another set of steps, which can perform different actions (or run transformations). The jumps in this case determine the execution order or conditional execution.
Components Talend has a large number of components. The approach is to have a separate component as the action to take, and access to databases or other systems, there are different components according to the database engine that we will attack. For example, we have an input table component for each manufacturer (Oracle, MySQL, Informix, Ingres), or one for the SCD management  for each RDBMS. You can see available components list here. Smallest components set, but very much oriented towards data integration. For similar actions (eg reading database tables), a single step (no one from each manufacturer), and behavior according to the database defined by the connection. You can see available elements for transformations here and for jobs here.
Platform Windows, Unix and Linux. Windows, Unix and Linux.
Repository Works with the workspace concept, at filesystem level.  In this place you store all the components of a project (all Jobs, metadata definitions, custom code and contexts). The repository is updated with the dependencies of changend objects (expand to all project changes.) If we change the table definition in repository, for example, is updated in all the Jobs where it is used. The Jobs and transformations are stored in XML format. We can choose to store at  file system level or in the database repository (for teamwork). Dependencies are not updated if you change a transformation who is called from another. If the level of components within a single transformation or job.
Metadata Full metadata that includes links to databases and the objects (tables, views, querys).  Metadata info is centrally stored in workspace and its not necesary to read again from source or destination system, which streamlines the process. In addition, we can define metadata file structures (delimited, positional, Excel, xml, etc), which can then be reused in any component. The metadata is limited to database connections, which metadata can be shared by different transformations and  jobs.Database information (catalog tables / fields) or files specifications (structure) is stored in steps and can not be reused. This info is read in design time.
Contexts Set of variables that are configured in the project and that can be used later in the Jobs for your behavior (for example to define productive and development environment). Using Variables in tool parameters file (file kettle.properties). Passing parameters and arguments to the process (similar to the contexts), both in jobs and transformations.
Versions It allows us to perform a complete management of objects versions (can recover previous versions) Functionality provided in version 4.0.
Languages to define their own components (scripting) Talend allows us to introduce our custom code using Java and Groovy.Additional custom SQL and Shell. JavaScript used for the calculations and formulas.Aditional custom SQL, Java, Shell and open office formulas.
Additional tools Talend offers additional tools for Data Profiling and Master Data Management (MDM). Open Studio have too a simple modeling tool to draw logical processes and models. PDI 4.0 offers Agile functionality  for dimensional modeling and models publication in Pentaho BI.
Plugins Download new components through Talend Exchange . Incorporation of additional plugins in the web .
Support An complete online community with Talend’s wiki , Talend Forum and bugtracker for the management of incidents and Bugs. Includes forum Pentaho , Issue Tracking and Pentaho Community .
Documentation Complete documentation in pdf format that includes: Installation, User Manual and Documentation of components. Online Documentation  on the web. Books: Data Integration-Pentaho 3.2 Beginner’s Guide(M.C.Roldan), Pentaho Kettle Solutions (M.Casters, R.Bouman, J.van Dongen).

Examples of Use (in Spanish)

EXAMPLE TALEND OPEN STUDIO PENTAHO DATA INTEGRATION (KETTLE)
Charging time dimension of a DW ETL process to load the time dimension. Example use of the ETL Talend. Time Dimension ETL with PDI.
Implementation of dynamic sql statements More examples of Talend. Execution of SQL statements constructed in execution time. Passing parameters and dynamic operations in a transformation of PDI.
Loading a product dimension DW Product Dimension ETL load. More examples of Talend. Using logs, metrics and statistics. Product Dimension ETL with PDI (I).Extraccion to Stage Area. ETL Product Dimension with PDI (II). Loading to DW.
Charging a customer dimension DW Talend ETL Mapping Types. Customer Dimension ETL. Customer Dimension ETL with PDI.
Treatment of slowly changing dimensions Management of SCD (slowly changing dimensions.) Treatment Slowly Changing Dimensions (SCD) with PDI.
Connecting to ERP Sap Connecting to Sap with Talend Connecting to Sap with Kettle (plugin ProERPConn)
Charging sales fact tables in a DW Sales Facts table. Talend contexts. Loading ETL sales made with PDI. ETL load PDI budgeting facts.
Exporting Jobs and planning processes Export Talend.Planification jobs in ETL processes.
Treatment of public data Data Model and Process Load DW London’s public data.
Understanding the user interface Building ETL processes using Kettle (Pentaho Data Integration)
Graduation Project (comparative Pentaho / JasperETL). Developed by Rodrigo Almeida, Mariano Heredia. Thesis which details a Business Intelligence project using the tools of Pentaho and Jasper.  In the ETL’s, compared Kettle with JasperETL  (based on Talend). Download the book on the web: http://sites.google.com/site/magm33332/bifloss. It includes a magnificent detail of the features of each tool.

As further examples, you can also consult:

  • Tutorial Talend Open Studio 4 by Victor Javier Madrid on the web adictosaltrabajo.com. Includes another example to process an EDI file with Talend.
  • White Paper on Open Source ETL tools conducted in French by Atol. It includes a series of practical examples very complete.

 

Using Pentaho Data Integration (Kettle) in ETL Process Design

Table of strengths / weaknesses.

From my point of view, with the user experience of the two tools and the information collected about tools and others user experience, I can highlight the following aspects:

TALEND OPEN STUDIO PENTAHO DATA INTEGRATION (KETTLE)
It is a code generator and this issue implies a heavy dependence of the project chosen language (Java in my case). By choosing java, we have all the advantages and disadvantages of this language. You need a high level of this language to get the most out of the application. It is a transformation engine, and notes from the outset has been designed by people who needed to meet their needs in data integration, with great experience in this field. It is also easier to manage the datatypes with PDI, it is not as rigorous as Java.
Tool unintuitive and difficult to understand, but once you overcome this initial difficulty, we observe the very great potential and power of the application. Very intuitive tool,  with some basic concepts can make it works. Conceptually very simple and powerful.
Unified user interface across all components. Based on Eclipse, the knowledge of the tool enables us to use the interface. The design of the interface can be a bit poor and there is no unified interface for all components, being sometimes confusing.
Talend is investing significant resources in its development (through capital injections from various funds), which is producing a very rapid development of the tool. With a great potential, the product also is being supplemented with other tools for MDM and Data Profiling. Much slower tool evolution and uncertain because Pentaho tends to leave the OpenSource focus.
Greater availability of components to connect to multiple systems and data sources, and constantly evolving. Limited availability of components, but more than enough for most ETL or data integration process.
There is not a database repository (only in paid versions),but work with Workspace and the project concept gives us many opportunities. Very useful dependency analysis and update when elements are modified (which is distributed to all the Jobs of a project). Database repository gives us many opportunities for teamwork. In this repository is stored xml, containing the actions that Transformations and Jobs take on the data.
A separated component by each database vendor. A single component by database action type (and the characteristics of the connection used are those that determine their behavior).
Help shortcut in the application. Comprehensive online help components. When we designed our own code in Java, we have the context assistance of language  provided by Eclipse. Help poor, almost nonexistent in the application.  The online help in the Pentaho website is not particularly full, and in some parts is very small, so that the only way to determine the functioning of the component is test it.
Logs: We can configure at project level or in each Job, indicating if we want to overwrite the configuration of the project in this regard.  Log can be sent to database,  console or file.  The functionality is very developed, distinguishing logs of statistics, metrics and process logs (to handle errors). Logs: different logs levels (from the most basic to the row detail in data flow). Sufficient to analyze the execution of the transformations and jobs. Possibility of record logs in database, but very limited. Log configuration is set at the level of transformations and Jobs.
Debug: Debug perspective in Eclipse, we can keep track of implementation (see the source code) as if we were programming in Eclipse.  You can also include statistics and data display trace or response times in the execution of jobs using the graphical tool. Debug: Contains a simple debug tool, very basic.
Versioning of objects: in the Workspace we can manage a complete versioning of the Jobs (with minus and major number). It enables us to recover earlier versions if problems occur.  It has a massive tool to change versions of lots of objects (can be very useful for versioning of distributions). Object versioning is scheduled to be included in version 4.0.
Parallelism: very small in Open version. Advanced functionality in paid versions (Integration Suite). Parallelism: parallelism is very easy to make,using the Distribute Data option in the configuration of the information exchange between steps, but will have to take care with not consistent, depending type of process.
Automatic generation of HTML jobs documentation. Includes graphical display of the designs, tables of properties, additional documentation or explanatory texts that we have introduced in the components, etc.  You can see an example here . Unable to generate documentation of changes and Jobs. Using the graphics tool, we can include notes with comments on the drawing process. With project kettle-cookbook you can generate html documentation.
Simple tool for modeling chart. With it  we can conceptually draw our Jobs designs and processes.
Continuous generation of new versions, incorporating improvements and bug fixes. The generation of new versions is not very common and we need to generate versions ourseles updated with the latest available sources: see blog entry of Fabin Schladitz .
Talend Exchange : place where the community develop their own components and share them with other users. Pentaho also offers fans who develop and release plugins on their website , with less activity than Talend.
As a negative point, sometimes excessively slow caused by the use of Java language. As a downside, some components are not behaving as expected, to perform complex transformations or by linking calls between different transformations in Jobs. The problems could be overcome by changing the design of transformations.
It is an advantage to have a local repository where we store locally  information about database, tables, views, structures, files (text, Excel, xml). Being in the repository can be reused and associated components not need to re-read of the  data source metadata every time (for the case of databases, for example).  It has a query assistant (SQL Builder) with many powerful features. When working with databases with very large catalogs, it is inconvenient to have to recover the entire building, for example, a sql statement to read from a table (when we use the option of browsing the catalog).
Code reuse: we can include our own libraries, which are visible in all Jobs in a project.  This allows us a way to design our own components. JavaScript code written in the step components can not be reused in other components. Fairly limited to adding new functionality or modify existing ones.
Control of flow processes: on the one hand we have the data flow (row, iterate or lookup) and on the other triggers for control execution and orchestration of processes. The row and iterate combination is useful to orchestrate the  loop process, with the aim of repetitive process.  There is a major inconvenience we may complicate the process: you can not collect several data streams coming from the same origin (must have a different point of departure). Flow control processes: passing information between components (steps) with jumps, in a unique manner, and the resulting flow varies with the type of control used.  This approach has limitations with the control of iterative processes.  As an interesting feature, encapsulation of transformations through the mappings, which allows us to define transformations for repetitive processes (similar to a function in a programming language).
Handling errors: when errors occur, we can manage the log, but we lose control. We cant reprocess rows. Error management: errors management in the steps allow us to interact with those mistakes and fix them without completing the process (not always possible, only in some steps).
Execution: either from the tool (which is sometimes very slow, especially if you include statistics and execution traces). To run at command line level, is necesary to export Jobs. The export generates all objects (jar libraries) necessary to perform the job, including a .bat or .sh file to execute it. This way allow us to execute the job in any platform where you can run java or perl language, without needing to install Talend. Execution: either from the tool (pretty good response times) or at command level with Pan (for transformations) and Kitchen(for jobs) . They are two very simple and functional utilities that allow us to execute XMLs  specifications of jobs or transformations (either from file or from the repository). It is always necessary to run the process have installed the PDI tool. We have also Carte tool, a simple web server that allows you to execute transformations and jobs remotely.

Comparatives and additional information.

Benchmark between Talend and Pentaho Data Integration by Matt Caster. http://www.ibridge.be/?p=150. Reviews about in Goban Saor and Nicholas Goodman blogs.
Comparison between Kettle and Talend, by Vicent McBurnety (2007) http://it.toolbox.com/blogs/infosphere/wiki-wednesday-comparing-talend-and-pentaho-kettle-open-source-etl-tools-16294
Comparison between Kettle, Talend and CloverETL. http://www.cloveretl.org/_upload/clover-etl/Comparison% 20CloverETL 20vs%%%% 20and 20Talend 20Pentaho.pdf
Benchmark between PDI, Talend, Datastage e Informatica http://it.toolbox.com/blogs/infosphere/etl-benchmark-favours-datastage-and-talend-28695
Compare features and benchmark between Talend and PDI http://www.atolcd.com/fileadmin/Publications/Atol_CD_Livre_Blanc_ETL_Open_Source.pdf
Comparison between PDI and Informatica http://www.jonathanlevin.co.uk/2008/03/pentaho-kettle-vs-informatica.html
Comparative table of features on the web Openmethodology.org Talend vs PDI (Kettle).
Simple example comparing Kettle and Talend http://forums.pentaho.org/showthread.php?t=57305
Comparison of ETL tools Adepti made by Adeptia company. http://www.adeptia.com/products/etl_vendor_comparison.html
Pentaho Kettle Open Source Review http://www.datawg.com/pentaho-kettle-open-source-etl-tool-review.html
Benchmark between Talend and Pentaho Data Integration by Marc Russel. http://marcrussel.files.wordpress.com/2007/08/benchmark-tos-vs-kettle.pdf
Comparison between Datastage, Talend, Informatica and PDI (Manapps). http://marcrussel.files.wordpress.com/2009/02/etlbenchmarks_manapps_090127.pdf
PowerPoint Presentation comparative Talend vs. Kettle http://svn2.assembla.com/svn/bbdd_dd/Presentaciones/Kettle%
EOS: Open Source Directory. EOS: Open Source Directory. http://www.eosdirectory.com/project/397/Talend+Open+Studio.html vs http://www.eosdirectory.com/project/202/KETTLE++pentaho+data+integration+.html

Summary (final opinion).

From my point of view, I think both tools are complementary. Each one with a focus, but allow the same tasks of transformation and data integration. The product Talend has more future, since they are putting many resources in its development, and is being supplemented with other tools to create a true data integration suite. Also used in the  Jaspersoft project, the fact of being more open and can be complemented with the use of Java gives certain advantages over Pentaho.

By the other hand, Pentaho Data Integration is a very intuitive and easy to use. You can see from the beginning when you start to use, as I mentioned, which is developed through the prism of the problems of ETL processes and data transformation. In some aspects it is faster and more agile than Talend, not having to be moving Java code generation all the time. We misses the management of a truly integrated project repository, such as Talend, and an independent metadata of source/target systems.

A level of performance, and reviewing the different comparations and benchmarks, not see a clear winner. A tool is faster in some things (Talend in calculating  additions or Lookups), while Pentaho is faster, for example in the treatment of SCD or the parallelization process. In my ETL processes there have been no large differences in performance, although I found slightly more agile Pentaho when performing mass processes.

Taking into account all seen (and everything detailed in the above), I opted for Talend slightly, but before choosing a tool for a project, I conduct a thorough study of the type of work and casuistic to which we will face in the design of our processes before opting for one or other tool. You may have specific factors that may recommend the use of one or another (such as the need to connect to a particular application or platform in which to run the process). What is clear in both cases, is that either we could hold for the processes of construction of a DW in a real environment (as I have shown in this blog with the whole series of published examples.)

If you have worked with some of the tools, or both, maybe have to add something to this comparison. I hope your opinions.

Updated 18/06/10

I leave the link to the last Gartner study about Data Integration Tools, published in November 2009:

Magic Quadrant for Data Integration Tools.

In the latter study was included Talend  as a emerging provider of data integration tools. If you are considering working with Talend, they say interesting things (both Strengths and Cautions) on the evolution of the product and its future:

Strong Points:

  • Two levels: entry-level Open Source tool free (Talend Open Studio) and higher with a payment tool with more features and support (Talend Integration Suite).
  • Talend is getting almost unanimously positive results in business. Although the initial factor may be its price, its features and functionality are the second factor in its success.
  • Good connectivity in general. Complemented with the tools of Data Profiling and Data Quality. The passage of the versions to pay Open requires no extra learning curve.

Precautions:

  • There is a shortage of experts in the tool, although it is developing a network of alliances with other companies and develop its commercial network (although they are not in all regions).
  • There are some problems with the central repository (which is not in the Open version), when working to coordinate development works. Looks like they are trying to solve in the new versions.
  • Some customers have reported that the documentation is wrong and some problems in  metadata management. It is also necessary to have an expert in Java or Perl to take full advantage of the tool (such as indicated in comparison with Pentaho).

I recommend reading the report, there is a lot of information about data integration tools and particularly if you are looking for information on any individual (such as Talend, the purpose of this comparative product).

Posted in ETL, Kettle, Pentaho, Talend | 33 Comments »

13.5. Exportación jobs en Talend.Planificacion procesos ETL.

Posted by Roberto Espinosa en 18 enero 2010


Una vez concluido el desarrollo de los procesos para la carga del DW, la siguiente tarea sera la planificación de estos para su ejecución regular, de forma que vayan reflejando en el DW todos los cambios que se vayan produciendo en el sistema operacional ( modificaciones en los datos maestros y nuevos hechos relacionados con los procesos de negocio de ventas).

Los jobs que hemos definido usando Talend se podrían ejecutar a petición desde la herramienta, o bien a nivel de sistema operativo, utilizando la correspondiente herramienta (CRON en Unix/Linux, AT en Windows). Para ello es necesario generar los ficheros de scripts a nivel de sistema operativo.

Para hacer esto, hemos de exportar el Job, pulsando con el botón derecho sobre el. Nos aparecera el correspondiente menú contextual, donde podremos seleccionar la opción “Export Job Scripts“. Como ya comentamos, Talend puede trabajar a nivel de generación de código con los lenguajes Java y Perl. Cuando creamos un proyecto, seleccionamos con que lenguaje vamos a trabajar(en nuestro caso hemos seleccionado Java), lo que determina que internamente se trabaje a todos los niveles con Java, al igual que a la hora de definir expresiones en los diferentes procesos y transformacion. De la misma manera, cuando exportemos los correspondientes scripts de un Job, estos se generarán utilizando dicho lenguaje.

Al exportar el Job, nos aparece un cuadro de diálogo, como el que veis a la derecha, donde se nos pide un directorio para realizar la generación de todos los elementos necesarios, ademas de indicar una serie de opciones:

Tipo de exportación: trabajo autonomo, Axis web service, JBoss ESB.

Versión del job: podemos realizar una gestión de versiones de las modificaciones que vamos realizando sobre este y luego descargar una versión en concreto.

Sistema operativo para generar el shell: indicamos para que tipo de sistema va a preparar los scripts para la posterior ejecución de los procesos.

Incluir objetos dependientes: podemos hacer que en el directorio de exportación se incluyan todos los elementos necesarios para la ejecución independiente del trabajo (módulos talend, librerias java, rutinas del sistema).  Esto nos permitirá llevarnos el job y ejecutarlo en cualquier sitio sin necesitar nada mas (solo la correspondiente maquina virtual java).

Source files: podemos generar también el código fuente de nuestros jobs (para analizarlo o modificarlo directamente). Recordemos que Talend realmente es un generador de código, que utiliza la plataforma Eclipse.

Contexto a utilizar: de todos los contextos que tenga definido el job, podemos indicar con cual se van a generar los scripts de ejecución (aunque luego podremos modificar el script para ejecutar con otro contexto,  no es mas que un parametro de ejecución).

Una vez exportados los jobs, vemos que en la carpeta donde se ha exportado, aparecen los siguientes elementos:

  • Directorio “NombreJob”: aparecen los scripts para ejecutar el job ( NombreJob_run.bat y NombreJob_run.sh), y la libreria NombreJob_version.jar, que es la que se llama desde el script para arrancar la ejecución del proceso. Es la libreria Java que se ha construido con todos los elementos y componentes que hemos utilizado para la definición de nuestro Job. Dento de estar carpeta cuelga otra donde se guardan los ficheros con los valores de las variables de contexto (en ficheros del tipo properties).

Script de ejecución de un job para Windows

En el script, observamos como se le pasa como parametro el contexto con el que queremos que se ejecute el Script. Es sencillo cambiarlo y teniendo preparados los juegos de variables correspondientes en diferentes ficheros de contexto, podremos trabajar con los mismos jobs trabajando sobre diferentes entornos o ejecutar los jobs con valores personalizados.

  • Directorio “Lib”: aparecen todas las librerias java necesarias para la ejecución independiente del job. En nuestro caso, por ejemplo, que hemos utilizado controles para envio de mail (aparece la libreria mail.jar), conexión a mysql (aparece la libreria mysql-connector-java*.jar), conexión a oracle (libreria ojdbc14-9i.jar), rutinas de usuario (userRoutines.jar), etc.

Para realizar la planificación de los jobs, podriamos utilizar el CRON del sistema operativo Unix/Linux (preparando su correspondiente fichero crontab ), o bien a nivel de Windows utilizando AT o alguna herramienta similar como WinAT. Talend proporciona una herramienta para preparar los ficheros crontab. La herramienta es el OpenScheduler (tal y como vemos en la imagen).

Talend Open Scheduler

De una forma visual, podemos elegir los diferentes parametros de ejecución del job  (dia del mes, dia de la semana, mes, hora, minutos). A partir de las entradas grabadas en el OpenScheduler, podemos generar un fichero con los parametros necesarios para incorporar la programación de los jobs a las tablas crontab de nuestro sistema y asi planificar la ejecución de los procesos en los momento indicados.

Planificación de Jobs para el proyecto Enobi

Utilizando los scripts generados, planificaremos en nuestro sistema un lote de trabajos que ejecutará, en primer lugar, la carga de las dimensiones. Una vez concluida esta, se lanzara la carga de la tabla de hechos de venta (pues llevan incluidos datos que dependen de los existentes en las dimensiones).

La siguiente fase de nuestro proyecto será la explotación del DW utilizando la herramienta de Microstrategy 9. En primer lugar, teniendo en cuenta el diseño definitivo, configuraremos el modelo de datos dentro de el, para posteriormente abordar la explotación del sistema. Esta incluirá todos los ambitos del Business Intelligence. Veremos ejemplos de informes, cubos olap y navegación dimensional, cuadros de mando e indicadores kpi´s y también funciones de Data Mining.

Posted in Business Intelligence, ETL, OpenSource, Talend | 1 Comment »

13.4.2. Tabla Hechos Venta. Ajuste diseño fisico y procesos carga ETL. Contextos en Talend.

Posted by Roberto Espinosa en 18 enero 2010


Vamos a desarrollar los procesos de carga de la tabla de hechos de ventas de nuestro proyecto utilizando Talend. Antes de esto, vamos a hacer algunas consideraciones sobre la frecuencia  de los procesos de carga que nos van a permitir introducir el uso de un nuevo elemento de Talend, los contextos.

En principio, vamos a tener varios tipos de carga de datos:

Carga inicial: será la primera que se realice para la puesta en marcha del proyecto, e incluira el volcado de los datos de venta desde una fecha inicial (a seleccionar en el proceso) hasta una fecha final.

Cargas semanales: es el tipo de carga mas inmediato. Se realiza para cada semana pasada (por ejemplo, el martes de cada semana se realiza la carga de la semana anterior), para tener un primer avance de información de la semana anterior (que posteriormente se refrescara para consolidar los datos finales de ese periodo). La carga de una semana en concreto también se podrá realizar a petición (fuera de los procesos batch automáticos).

Recargas mensuales: una vez se cierra un periodo mensual (lo que implica que ya no puede haber modificaciones sobre ese periodo), se refresca por completo el mes en el DW para consolidar la información y darle el status de definitiva para ese periodo. La ejecución es a petición y se indicara el periodo de tiempo que se quiere procesar.

Teniendo en cuenta esto, definiremos un unico proceso de traspaso al cual se pasaran los parametros que indicaran el tipo de carga a realizar. Para ello utilizaremos los contextos de Talend. Cada tipo de carga tendra un contexto personalizado que definira como se va a comportar el proceso.

Contextos en Talend

Los contextos de Talend son grupos de variables contextuales que luego podemos reutilizar en los diferentes jobs de nuestras transformaciones. Nos pueden ser utiles para muchas cosas, como para tener definidas variables con los valores de paths de ficheros, valores para conexión a bases de datos (servidor, usuario, contraseña, puerto, base de datos por defecto, etc), valores a pasar a los procesos (constantes o definidos por el usuario en tiempo de ejecución). Los valores de los contextos se inicializan con un valor que puede ser cambiado por el usuario mediante un prompt (petición de valor). Un mismo contexto puede tener diferentes “grupos de valores”. Es decir, en el contexto “conexion a base de datos”, podemos tener un grupo de valores llamado “test”, que incluira los valores para conectarnos al sistema de pruebas y un grupo llamado “productivo”, que incluira los valores para la conexión a la base de datos real (tal y como vemos en el ejemplo).

Definición de Contextos en Talend

Dentro del contexto, definiremos que grupo de valores es el que se utilizara por defecto. Esto nos va a permitir trabajar con los jobs y sus componentes olvidandonos de contra que sistema estamos trabajando. Tendremos, por ejemplo, el contexto de test activo, y es el que utilizaremos para las pruebas. Y podremos cambiar en cualquier momento, al ejecutar un job, para decirle que utilice el contexto “productivo”. Igualmente, podremos preparar un fichero o una tabla de base de datos con los valores de las variables de contexto, que serán pasadas al job para su utilización en la ejecución de un proceso (utilizando el componente tContextLoad).

Definición del proceso de carga

El diseño físico definitivo de la tabla de hechos será el siguiente:

Una vez hechas todas las consideraciones, veamos el esquema de como quedaria nuestro proceso de transformación.

Job completo en Talend para la carga de la tabla de Hechos

Vamos a ver en detalle cada uno de los pasos que hemos definido para realizar la lectura de datos del sistema origen y su transformación y traspaso al sistema destino (y teniendo en cuenta varios procesos auxiliares y la carga del contexto de ejecución).

1) Ejecución de un prejob que  lanzará un generara en el log un mensaje de inicio del proceso y un logCatcher (para recoger las excepciones Java o errores en el proceso).  Este generará el envio de un email de aviso en el caso de que se produzca algún problema en cualquier paso del job (al igual que hemos incluido en todos los jobs de carga del DW vistos hasta ahora).

  • Lanzador Prejob (componente tPrejob): sirve para realizar el lanzamiento de un pretrabajo, anterior al proceso principal.
  • Mensaje Log Inicio (componente tWarn): genera un mensaje de log indicando que se comienza la ejecución del job.
  • Control Errores (componente tLogCatcher): activamos el componente que “escuchara” durante toda la ejecución del job, esperando que se produzca algún tipo de error. En ese momento se activara para recuperar el error y pasarlo al componente siguiente para el envio de un email de notificación.
  • tFlowtoIterate: convertimos el flujo de registros de log a una iteración para poder realizar el envio del correo electrónico.
  • Envio Email Notif (componente tSendMail): generamos el envio de un email de notificación de errores, incluyendo el paso donde se paro el proceso, y el mesaje de error generado. Es una forma de avisar que ha fallado algo en el proceso.

2) Carga del contexto de ejecución: para que el proceso sepa que tipo de carga ha de  realizar y para que periodo de fechas, es necesario proporcionarle la información. Esto lo haremos utilizando los contextos. En este caso, tal y como vemos en la imagen, el contexto tendrá 3 variables, donde indicaremos el tipo de carga y la fecha inicio y fin del periodo a procesar.

Contexto para la ejecución del Job

Los valores para llenar el contexto los recuperaremos de un fichero de texto (también lo podiamos haber recuperado de los valores existentes en una tabla de la base de datos). El fichero contendrá lineas con la estructura “clave=valor”, donde clave sera el nombre de la variable y valor su contenido.

Para abrir el fichero, utilizaremos el paso LEE_FICHERO_PARAMETROS (componente tFileInputProperties), que nos permite leer ficheros de parametros. A continuación cargaremos los valores recuperados en el contexto utilizando el paso CARGA_CONTEXTO, del tipo tContextLoad. A partir de este momento ya tenemos cargado en memoria el contexto con los valores que nos interesan y podemos continuar con el resto de pasos.

Podriamos haber dejado preparados los valores de contexto en una tabla de base de datos y utilizar un procedimiento parecido para recuperarlos y con el componente tContextLoad  cargarlos en el job. Tened en cuenta que los ficheros que va a leer el job habrán sido previamente preparados utilizando alguna herramienta, donde se definira el tipo de carga a realizar y el periodo (y dichos valores se registraran en el fichero para su procesamiento).

3) Borrado previo a la recarga de los datos del periodo en la tabla de hechos (para hacer un traspaso desde cero): antes de cargar, vamos a hacer una limpieza en la tabla DWH_VENTAS para el periodo a tratar. De estar forma, evitamos inconsistencia en los datos, que podrían haber sido cargados con anterioridad y puede haber cambios para ellos. Con el borrado, nos aseguramos que se va a quedar la última foto completa de los datos. Para hacer esto, utilizamos el paso BORRAR_DATOS_PERIODO (del tipo tMySqlRow).

Observad como en el paso hemos incluido la ejecución de una sentencia sql de borrado (DELETE), y le hemos pasado como valores en las condiciones del where las fechas del periodo, utilizando las variables de contexto.

4) Lectura de datos desde los pedidos de venta (cabecera) y a partir de cada pedido, de las lineas (desde el ERP).

A continuación, procederemos a recuperar todos los pedidos de venta del periodo para obtener los datos con los que llenar la tabla de Hechos. Para ello, utilizamos el paso LEER_CABECERA_PEDIDO (del tipo tOracleInput), con el que accedemos a oracle y obtenemos la lista de pedidos que cumplen las condiciones (observar como también en la sentencia SQL ejecutada por este componente hemos utilizado las variables de contexto).

A continuación, para cada pedido, recuperamos todas las lineas que lo componen con el paso LEER_LINEAS_PEDIDO (también del tipo tOracleInput) y pasamos todos los datos al componente tMap para realizar las transformaciones, normalización y operaciones, antes de cargar en la base de datos.

5) Transformación de los campos, normalización, operaciones.

Los valores de los datos de cabeceras y lineas de pedido recuperados desde Sap los transformamos a continuación conforme a la especificaciones que hicimos en el correspondiente análisis (ver entrada blog). En este proceso realizamos conversión de tipos, llenado de campos vacios, cálculos, operaciones. Todo con el objetivo de dejar los datos preparados para la carga en la tabla de Hechos de la base de datos.

Transformaciones de los datos de pedidos antes de grabar en tabla Hechos

En este ejemplo,  hemos utilizado un elemento nuevo del control tMap, que son las variables (ver la parte central superior). Las variables nos permiten trabajar de forma mas agil con los procesos de transformación, filtrado, conversión y luego se pueden utilizar para asignar a los valores de salida (o ser utilizadas en expresiones que las contengan).

Por ejemplo, observar que hemos creado la variable UNIDADES, y en ella hemos hecho un calculo utilizando elementos del lenguaje Java:

row6.shkzg.equals("X")?-1 * Float.valueOf(row6.kwmeng):Float.valueOf(row6.kwmeng)

El campo SHKZG de los pedidos nos indica si un pedido es venta o abono. Por eso, si dicho campo tiene el valor X, hemos de convertir los importe a negativo. Observad también como luego utilizamos las variables definidas en la sección VAR en el mapeo de campos de salida.

Para los campos que son clave foranea de las correspondientes tablas de dimensiones (código de cliente, material, etc), hemos realizado las mismas transformaciones que realizamos cuando cargamos dichas tablas, para que todo quede de forma coherente y normalizada.

6) Inserción en la tabla de hechos y conclusión del proceso.

Como paso final, vamos realizando el insertado de los registros en la tabla DWH_VENTAS utilizando el componente tMysqlOutput (tal y como vemos en la imagen).

Una vez realizada toda la lectura de datos e inserción, concluiremos el proceso generando un mensaje de conclusión correcta del Job en la tabla de Logs con el paso MENSAJE_LOG_FIN (componente tipo tWarn).

Observad como hemos incluido, intercalados en los diferentes pasos del job, unos llamados VER_REGISTROS (del tipo tLogRow). Es un paso añadido para depuración y comprobación de los procesos (aparece en consola los valores de los registros que se van procesando). En el diseño definitivo del job estos pasos se podrían eliminar.

Para ver en detalle como hemos definido cada componente, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Conclusiones

Hemos terminado el desarrollo de todos los procesos de carga para llenar nuestro DW. Para cada una de las dimensiones y para la tabla de hechos, hemos construido un proceso con Talend para llenarlos. Como ultima actividad, nos quedaría combinar todos esos procesos para su ejecución conjunta y planificarlos para que la actualización del DW se produzca de forma regular y automatica.

Igualmente, veremos la forma de exportar los procesos en Talend para poder ejecutarlos independientemente de la herramienta gráfica (nos permitira llevar a cualquier sitio los procesos y ejecutarlos, pues al fin y al cabo es código java).

Todo esto lo veremos en la siguiente entrada del blog.

Posted in Business Intelligence, ETL, OpenSource, Talend | 2 Comments »

Ejemplo Talend para conectarnos a Sap

Posted by Roberto Espinosa en 13 enero 2010


(Read in English Language here)

Antes de continuar con el proceso ETL para la carga de la tabla de Hechos de ventas, vamos a hacer una pausa para ver como utilizar Talend para conectarnos a Sap utilizando los componentes tSapConnection, tSapInput y tSapOutput. En nuestro proyecto, podriamos haber utilizado estos componentes para hacer la lectura de datos desde el ERP (pero hemos utilizado el componente tOracleInput para leer directamente de la base de datos).

Aunque el componente Sap de Talend es libre, para poder utilizarlo hace falta una librería Java proporcionada por Sap (sapjco.jar), que tendremos que tener instalada en nuestro sistema. Esta libreria solo se puede descargar de Sap si somos usuarios registrados (http://service.sap.com/connectors). La versión del sapjco que hemos instalado es la 2.1.8 (hay una posterior, la 3.0.4, pero con esa no funciona Talend).

La forma de instalar la libreria sapjco.jar es la siguiente:

  • Una vez descargado el correspondiente fichero (según la versión de sistema operativo que estemos utilizando), lo descomprimimos en un directorio de nuestra elección. La prueba, en nuestro caso, la hemos realizado utilizando Windows Vista.
  • Si tenemos una versión mas antigua de la dll librfc32.dll en el directorio de windows system32, la sustituimos con la que viene de Sap.
  • Incluimos el directorio de instalación en la variable de entorno PATH (en nuestro caso c:\sapjco ).
  • Finalmente, añadimos a la variable de entorno CLASSPATH el fichero sapjco.jar con su ruta completa (por ejemplo, CLASSPATH=c:\sapjco\sapjco.jar ).

A continuación, instalamos la libreria en el directorio de clases de Talend y comprobamos que este correctamente instalada. Para ello, dejamos caer el fichero sapjco.jar en el directorio <directorio_instalacion_talend>\lib\java. A continuación abrimos Talend, y en la pestaña Modules, comprobamos que aparezca el modulo sapjco.jar correctamente instalado (tal y como vemos en la imagen).

Finalmente, vamos a ver un ejemplos práctico de conexión a Sap para recuperar información, utilizando modulos de función (RFC) implementados en Sap y a las que podremos acceder desde Talend (esto es realmente lo que nos permite hacer el componente, acceder a Sap a traves de sus RFC´s y BAPIS).

Las RFC´s (Remote Function Call) son la base para la comunicación entre Sap y cualquier sistema externo. Son componentes de programación (un programa Abap, por ejemplo), encapsulado en una función, con su correspondiente interfaz de entrada y salida de datos, que ademas puede ser llamado desde dentro del propio Sap, o de forma remota si esta habilitada la opción “Modulo Acceso Remoto” (tal y como vemos en la imagen inferior). En este caso, es cuando podremos llamarlas, por ejemplo, desde Talend.

Definicion de la RFC "RFC_READ_TABLE" en Sap

Sap tiene programadas multitud de RFC´s de forma estandar, y ademas nosotros podremos construir las nuestras con codigo que realize las tareas que deseemos. Ademas, existe otro tipo de RFC´s dentro de sap, las llamadas BAPIS, que incluyen reglas adicionales integradas con el funcionamiento de la aplicación Sap (por ejemplo, la BAPI BAPI_SALESORDER_CREATEFROMDAT2 nos permite la creación de un pedido de ventas a partir de los datos que pasamos a la función en la interfaz).

Ejemplo: Lectura del contenido de una tabla utilizando la RFC “RFC_READ_TABLE”.

Vamos a realizar un Job en Talend para leer el contenido de una tabla de Sap, en concreto, vamos a recuperar todos los materiales que son de un determinado tipo. El Job completo tendrá la siguiente estructura:

En Talend utilizaremos el componente tSapInput para hacer la llamada a la RFC de Sap. Para poder hacer esto, tendremos que conocer cual es la interfaz que tiene definida esta en Sap para saber que parametros le podemos pasar y que resultados y en que tipos de estructuras de datos podemos recibir. En la transacción SE37 de Sap podemos ver como estan definidos los modulos de función, y ver como se va a realizar la comunicación con dicho componente.

Por ejemplo, en modulo de función RFC_READ_TABLE (como vemos en la imagen inferior), tiene 5 parametros de entrada, definidos en la pestaña IMPORT. Los que vamos a utilizar en nuestro ejemplo serán: QUERY_TABLE (la tabla de la que queremos obtener información), DELIMITER (delimitador para los datos obtenidos).

Definicion RFC en Sap - Import (parametros Entrada)

Existe tambien la pestaña EXPORT, en la que podriamos ver que parametros de salida tenemos (para el caso de variables o estructuras simples). En el caso de trabajar con tablas, estas aparecerán en la pestaña TABLAS. Las tablas son estructuras complejas de Sap (como una matriz de datos). Las tablas se pueden utilizar tanto para recibir datos de la RFC como para pasarselos. En nuestro ejemplo, utilizaremos la tabla DATA para recibir los registros recuperados de la base de datos.

Definicion RFC en Sap - Tables (parametros Entrada/Salida)

A continuación, volveremos a Talend y completaremos los diferentes campos del componente:

  • Cliente: mandante de Sap del cual recuperaremos los datos.
  • Userid: usuario para la conexión. Habrá de tener permisos para ejecutar la RFC y para acceder a los datos deseados.
  • Password: contraseña.
  • Language: lenguaje de conexión.
  • Host Name: Host donde esta ubicado el servidor Sap.
  • System Number: numero de instancia Sap del servidor (normalmente la 00 donde solo hay un servidor).
  • Function name: Nombre de la RFC a la cual vamos a invocar.

Ejemplo de Uso de componente tSapInput

  • Initialize input: inicializacion de los parametros de entrada. Son los valores que vamos a pasar al módulo de función. En nuestro caso, observar que hemos pasado valores simples (variables) y también hemos pasado valores a algunas de las tablas.
    • Input single: los parametros “QUERY_TABLE” y “DELIMITER” son del tipo input_single (entrada sencilla) y los inicializamos pasandoles un valor, en concreto el nombre de la tabla que queremos leer y el delimitador a utilizar.
    • Table input: introducimos valores en dos tablas. En la tabla OPTIONS, en el campo TEXT, indicamos una condición para restringir la lectura de datos (como si fuera una condición del where). En la tabla FIELDS, en el campo FIELDNAME, le indicamos a Sap que campos de la tabla son los que queremos recuperar (en este caso el código del material, su tipo y su linea de producto). De esta forma, limitamos tanto el número de registros devueltos, como los campos obtenidos (no queremos ver todos los campos de cada registro de esta tabla). Observar como para indicar varios valores para el campo FIELDNAME de la tabla FIELDS, hemos puesto varias entradas separadas por coma.
  • Outputs: definición de las estructuras donde vamos a gestionar los datos devueltos por Sap. Aquí indicaremos el tipo de valor recuperado (table_output para cuando el resultado sea una tabla), el nombre de la tabla en Sap (en el campo TableName (Structure Name) y el nombre del Schema (será un nombre para el flujo de datos, podemos ponerle cualquiera).  En nuestro ejemplo, estamos leyendo de la tabla de Sap DATA, que es una tabla de registros, y cada registro tiene un unico campo que se llama WA. Los pasos a seguir en esta sección para una correcta definición de intercambio de datos son los siguientes:
  • Creamos en primer lugar el flujo de salida pulsado el boton del signo “+”. Pulsado en Schema le daremos un nombre a este flujo (registros_devueltos en nuestro ejemplo) e indicaremos los campos que componen la estructura de salida del componente tSapInput. En este caso, solo tendremos un campo, llamado WA (tal y como vemos en la imagen), que corresponde con el campo de la tabla DATA de Sap.

Definicion de la estructura de salida "registros_devueltos"

  • A continuación, habrá que asociar esta columna a la componente de Sap donde se recuperan los datos. Para ello pulsaremos en el campo Mapping,y se nos abrira una nueva ventana. Aquí nos aparecera el flujo de datos definido en el paso anterior mas  el campo Schema XPatchQuerys, que es el que nos permite Mapear el campo de Talend con el campo del diccionario de datos de Sap, y así poder recibir los datos de Sap correctamente (los valores introducidos en XPatchQuerys deberán ir entre comillas dobles, utilizando el simbolo “).
Mapeo entre la estructura de salida en Talend y la de Sap

Con este ejemplo, hemos podido de una forma relativamente sencilla recuperar datos de Sap en un único control. Conociendo los diferentes RFC´s existentes en Sap y las Bapis, seguramente podremos realizar tareas mucho mas complejas y aprovechar funcionalidades que ya estan definidas en Sap. Incluso puede ser una forma de realizar interfases con Sap utilizando estos componentes ya definidos y paquetizados.

Para ver en detalle como hemos definido cada componente, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Posted in ETL, OpenSource, Sap, Talend | 1 Comment »

13.3. ETL Talend Dimension Cliente.Tipos de Mapeo para lookup. Gestión de SCD (Dimensiones lentamente cambiantes).

Posted by Roberto Espinosa en 12 enero 2010


El proyecto ENOBI sigue avanzando en la parte mas compleja y que seguramente mas recursos consumira, los procesos ETL. Como ya indicamos, en algunos proyectos puede suponer hasta el 80% del tiempo de implantación. Y no solo eso, el que los procesos esten desarrollados con la suficiente consistencia, rigor, calidad, etc. va a determinar el exito posterior del proyecto y que la explotación del sistema de Business Intelligence sea una realidad. Seguramente si los procesos de extraccion, transformación y carga no esta bien desarrollados, eso pueda acabar afectando al uso correcto del sistema

Para concluir los procesos ETL de las Dimensiones del proyecto, vamos a abordar la carga de la Dimensión Cliente, que incluye todos los atributos por los que analizaremos a nuestros clientes. Vamos a obviar la publicación de los proceso de carga de la Dimensión Logistica y Promoción, pues son muy sencillos y no aportan nada nuevo.

Al detallar los procesos de la carga de la Dimension Cliente, entraremos en detalle en las diferente formas que tiene Talend de realizar los mapeos de tablas de lookup. Es decir, cuando tenemos un valor para el que tenemos que recuperar un valor adicional en otra tabla de la base de datos (por ejemplo, para un código de cliente recuperar su nombre; para la familia de producto, introducida en el maestro de materiales, recuperar de la tabla de parametrización su descripción, etc ), ver de que maneras Talend nos permite realizar dicha consulta.

Igualmente, veremos mas ejemplos de utilización de Java dentro de los componentes, y la potencia que ello nos proporciona (aunque nos obliga a tener conocimientos amplios de este lenguaje).

Para completar el ejemplo, aunque en realidad en nuestra dimensión no vamos a gestionar las dimensiones lentamente cambiantes (SCD Slowly Change Dimension), vamos a incluir un ejemplo de tratamiento de este tipo de dimensiones, utilizando el componente que tiene Talend para ese cometido, que implementa el algoritmo correspondiente para su procesamiento (elemento tMySQLSCD).

Proceso ETL en Talend completo para la dimensión Cliente

Tal y como vemos en la imagen anterior, los pasos del proceso ETL para llenar la Dimensión Cliente serán los siguientes:

1) Ejecución de un prejob que  lanzará un generara en el log un mensaje de inicio del proceso y un logCatcher (para recoger las excepciones Java o errores en el proceso).  Este generará el envio de un email de aviso en el caso de que se produzca algún problema en cualquier paso del job.

  • Lanzador Prejob (componente tPrejob): sirve para realizar el lanzamiento de un pretrabajo, anterior al proceso principal.
  • Mensaje Log Inicio (componente tWarn): genera un mensaje de log indicando que se comienza la ejecución del job.
  • Control Errores (componente tLogCatcher): activamos el componente que “escuchara” durante toda la ejecución del job, esperando que se produzca algún tipo de error. En ese momento se activara para recuperar el error y pasarlo al componente siguiente para el envio de un email de notificación.
  • tFlowtoIterate: convertimos el flujo de registros de log a una iteración para poder realizar el envio del correo electrónico.
  • Envio Email Notif (componente tSendMail): generamos el envio de un email de notificación de errores, incluyendo el paso donde se paro el proceso, y el mesaje de error generado. Es una forma de avisar que ha fallado algo en el proceso. En la siguiente imagen tenéis un ejemplo de un email de notificación de error enviado a una cuenta de gmail.

Ejemplo envio Email de notificacion de error

2) Recuperamos del maestro de cliente en el ERP, todos los clientes existentes en el fichero maestro (con el componente tOracleInput).

Job DimCliente - Lectura Maestro Clientes Sap

3) Realizamos una sustitución de valores erroneos o en blanco en los registros seleccionados según los criterios establecidos (con el componente tReplace), como ya vimos en los procesos ETL de la Dimensión Producto.

4) Completamos el mapeo de dimensión Cliente, llenando el resto de campos que provienen de otras tablas en la base de datos (los campos de lookup),  con sus correspondientes consultas SQL (utilizando el componente tMap).

Job DimCliente - Mapeo Cliente

Podeis observar como al realizar el mapeo del maestro de clientes con las correspondientes tablas de lookup (donde estan el resto de campos y descripciones), hemos estado utilizado sintaxis del lenguaje Java. Esto nos da mayor potencia a las transformaciones y nos permitirán hacer casi de todo, aunque tendremos que conocer bien Java, sus tipos de datos, la forma de convertirlos. Algunos ejemplos son:

  • Relational.ISNULL(row2.psofg)?”SIN ASIGNAR”:row2.psofg : el operador Java que nos permite asignar un valor u otro a un resultado segun si se cumple una condición o no. En este caso, si row2.psofg es nulo, al resultado se le dara el valor “SIN ASIGNAR”. En caso contrario, se le dara el valor del campo row.psofg.
  • StringHandling.UPCASE(row2.ort01 ) : es un metodo de la clase StringHandling, que nos permite pasar una cadena a mayúsculas.
  • Long.valueOf(StringHandling.RIGHT(row2.konzs,10)) : utilizamos el metodo RIGHT de la clase StringHandling para obtener una subcadena, y el resultado lo convertimos al tipo de datos numérico Long con el metodo de este valueOf.

Tipos de Mapeo en el componente tMap

Cuando utilizamos el componente tMap para completar los datos de nuestro flujo con valores proveniente de otras tablas (u otros ficheros u origenes de datos), vemos que siempre tenemos un flujo Main (en nuestro caso con los datos que llegan del fichero maestro de Sap) y uno o varios flujos lookup (lo podeis observar en la imagen anterior). Estos flujos de lookup nos permiten “rellenar” valores que residen en otro lugar, buscandolos por una clave determinada. La clave puede venir del propio flujo Main o de otros flujos de lookup (de forma anidada). Pensar por elemplo el caso de recuperar, a partir del código de cliente, un dato asociado (como el comercial asignado). Posteriormente, para el código de comercial, busco en otro lookup, utilizando ese código, el nombre de dicho comercial.

Los flujos de lookup  pueden ser de tres tipos, como vemos en la imagen. Veamos en que consiste cada uno de ellos:

  • Load Once: la rama de lookup del componente tMap se ejecuta una unica vez y siempre antes de la ejecución del componente tMap. En este caso, la ejecución unica de la rama de lookup ha de generar todos los registros para poder buscar valores en ellos (será una carga de todo un fichero maestro, por ejemplo). Si los datos para el lookup tuvieran muchos registros, podría ser un cuello de botella para el proceso, e igual convendría utilizar el tipo Reload at each row.
  • Reload at each row: la rama del lookup se ejecuta para cada registro que llegan del flujo Main. Este tipo de mapeo nos permite ejecutar la consulta de lookup para un valor concreto (podremos pasar un valor unico que sera el que realmente busquemos. Ver ejemplo posterior de este tipo de lookup). Puede tener sentido utilizarlo con tablas de lookup muy grandes que no tiene sentido gestionar en una consulta de atributos (pensar en una tabla maestro de clientes de millones de registros).
  • Reload at each row (cache): idem al anterior, pero los registros que se van recuperando se guardan en la cache. En las siguientes consultas, se mira primero en la cache, y si ya existe, no se lanza el proceso. En el caso de que no exista, entonces si se relanza la ejecución para buscar los valores que faltan.

En este caso, en todos los flujos de lookup hemos utilizado el tipo Load Once (mas adelante veremos un ejemplo de uso Reload at each row).

5) Verificamos que realmente haya modificaciones con los datos existentes en la base de datos del DW (también con el componente tMap), y para los registros que si tienen modificaciones (o son nuevos registros), realizamos la actualización. En principio, no vamos a realizar gestión de Dimensiones Lentamente Cambiantes, sino que siempre tendremos la foto de los datos tal y como están los ficheros maestros en el momento actual.

Job DimCliente - Verificacion Modificaciones

Para discriminar el paso de registros al paso siguiente de actualización en la base de datos del DW, se ejecuta la siguiente expresión condicional (vemos que es 100% lenguaje Java). La expresión va comparando campo por campo entre los valores recuperados de nuestro ERP y los existentes en la tabla de la dimensión cliente DWD_CLIENTE.

!row8.cliente_desc.equals(row10.cliente_desc) ||
row8.agrupador_id!=row10.agrupador_id||
!row8.agrupador_desc.equals(row10.agrupador_desc)||
!row8.comercial_id.equals(row10.comercial_id)||
row8.canal_id!=row10.canal_id||
!row8.canal_desc.equals(row10.canal_desc)||
row8.tipocl_id!=row10.tipocl_id||
!row8.tipocl_desc.equals(row10.tipocl_desc)||
!row8.pais_id.equals(row10.pais_id)||
!row8.region_id.equals(row10.region_id)||
!row8.provincia_id.equals(row10.provincia_id)||
!row8.cpostal_id.equals(row10.cpostal_id)||
!row8.poblacion_id.equals(row10.poblacion_id)||
!row8.nielsen_id.equals(row10.nielsen_id)||
row8.clubvinos_id!=row10.clubvinos_id

Cuando el lookup lo ejecutamos para cada registro que llega al control tMap (en este caso utilizamos el tipo Reload at each row), la sentencia SQL que se ejecuta en el flujo de lookup es la siguiente (observa que en la condición del where utilizamos una variable que hemos generado en el control tMap, y será la que contiene el código de cada cliente que queremos verificar). En este caso, el paso asociado al flujo lookup se ejecuta una vez para cada registro que llegue al componente tMap y siempre posteriormente:

"SELECT dwd_cliente.cliente_id,
 dwd_cliente.cliente_desc,
 dwd_cliente.agrupador_id,
 dwd_cliente.agrupador_desc,
 dwd_cliente.comercial_id,
 dwd_cliente.canal_id,
 dwd_cliente.canal_desc,
 dwd_cliente.tipocl_id,
 dwd_cliente.tipocl_desc,
 dwd_cliente.pais_id,
 dwd_cliente.region_id,
 dwd_cliente.provincia_id,
 dwd_cliente.cpostal_id,
 dwd_cliente.poblacion_id,
 dwd_cliente.nielsen_id,
 dwd_cliente.clubvinos_id
FROM    dwd_cliente
WHERE cliente_id = " + (globalMap.get("var.cliente_id"))

En este caso, la sentecia SQL (y el correspondiente componente que la contiene), se ejecutara una vez por cada registro que llega por el flujo Main al componente tMap. Y la sentencia SQL solo recuperara un registro de la base de datos, aunque se estará ejecutando continuamente (le hemos pasado con la variable var.cliente_id el valor a buscar).

6) Concluimos el proceso guardándonos en el log el correspondiente mensaje de finalización correcta del proceso, con el componente MENSAJE_LOG_FIN del tipo tWarn.

TRATAMIENTO DE LAS DIMENSIONES LENTAMENTE CAMBIANTES

Como ejemplo y para estudiar su funcionamiento, incluimos un paso para la gestión de las dimensiones lentamente cambiantes (que se grabaran en una tabla paralela a la de la dimensión cliente). El tipo de componente en Talend para realizar esto será el tMySqlSCD.

Para entender que son exactamente las dimensiones lentamente cambiantes, os recomiendo un poco de literatura. En el blog Business Intelligence Facil, se explican de una forma muy clara que son y como gestionarlas ( ver aquí ), así como de las claves subrogadas. Tambien Jopep Curto nos da muy buenas definiciones en su blog.

Una vez tengamos clara la teoria, vamos a ver como aplicarlo a la practica utilizando los componentes de Talend.

Componente para gestion dimensión lentamente cambiante

El algoritmo de la dimensión SCD se gestiona con el correspondiente editor, tal y como vemos en la imagen siguiente:

Editor Componente SCD

Para utilizar el editor, se indica un nombre de tabla existente en la base de datos, que sera la tabla para la cual vamos a gestionar la SCD (ha de incluir los campos necesarios para la gestión de versiones según lo indicado en el editor SCD). El control recibirá un flujo con los registros a procesar contra la tabla indicada. En el editor SCD indicamos como se va a comportar la actualización contra la tabla según los diferentes tipos de atributos.

Los controles que forman el editor de dimensiones SCD son los siguientes:

  • Unused: aquí apareceran todos los campos disponibles para utilizar en el editor SCD. Desde este sitio iremos arastrando los campos al resto de sitios.
  • Source keys: son las claves principales de los datos (la clave en el sistema original). Para un maestro de clientes, aquí indicaremos la clave que identifica a este en el sistema origen.
  • Surrogate keys: es el nombre que le damos a la clave subrogada. Es decir, aquella clave inventada que nos va a permitir gestionar versiones de nuestros datos en el DW.
  • Type 0 fields: aqui indicaremos los campos que son irrelevantes para los cambios. Si aqui metemos, por ejemplo, el campo nombre, cualquier cambio en el sistema origen con respecto a los datos existentes en el DW no se va a tener en cuenta (se ignorará).
  • Type 1 fields: aquí indicaremos los campos para los que, cuando haya un cambio, se machacará el valor existente con el valor recibido, pero sin gestionar versionado.
  • Type 2 fields: aquí indicaremos los campos para los que queremos que, cuando haya un cambio, se produzca un nuevo registro en la tabla (con una nueva subrogated key). Es decir, aquí pondremos los campos que son dimensiones lentamente cambiantes y para los que queremos gestionar un versionado completo.
  • Versioning: aqui indicamos los valores para el versionado (fecha de inicio y fecha de fin), y si queremos llevar un control de numero de versión o flags de registro activo (requeriran campos adicionales en la tabla para este cometido).
  • Type 3 fields: aquí indicaremos los campos para los que queremos guardarnos una versión anterior del valor (es decir, cuando haya un cambio, siempre tendremos dos versiones, la ultima y la anterior).

Para concluir la explicación de las dimensiones SCD, observar las diferencias de catalogo entre el flujo de entrada y el flujo de salida (en el de salida se han incluido atributos propios para la gestión de la dimension lentamente cambiante, gestión de versiones, fechas de validez, etc):

Esquema de traspaso de Datos en Dimensiones SCD

Para entender mejor el ejemplo, observar las entradas en MySql de la tabla DWD_CLIENTE_SCD. Observar como el cliente tuvo un cambio en su nombre y se generó un  nuevo registro en la tabla con una nueva clave subrogada. Todo se ha realizado de una forma automatica por el componente de Talend, sin tener que gestionar nosotros nada.

Registros para el mismo cliente en MySql con Subrogated key

Finalmente, observar que hemos utilizado un componente nuevo para duplicar un flujo de datos (el componente tReplicate). Este componente nos permite a partir de un unico flujo, generar tantos flujos como sea necesarios (todos serán iguales y procesarán los mismos registros).

Duplicacion de flujos de datos con el componente tReplicate

Para ver en detalle como hemos definido cada componente del Job, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Posted in Business Intelligence, ETL, OpenSource, Talend | 1 Comment »

Comparativa ETL´s OpenSource vs ETL´s Propietarias

Posted by Roberto Espinosa en 10 enero 2010


La elección de una herramienta ETL puede ser una tarea compleja que va a tener mucha repercusión en el desarrollo posterior de un proyecto. Podeis ver la comparativa de ETL´s OpenSource vs ETL´s Propietarias a continuación ( gracias a http://www.jonathanlevin.co.uk/). Aqui se habla de que las herramientas OpenSource ya estan empezando a ser una alternativa real a los productos existentes y se estan desarrollando con rapidez.

En la web EtlTools.net también se hace una comparación de las herramientas ETL propietarias y las Open mas conocidas. De la misma manera, se analizan los productos Open de una forma muy rigurosa en el portal openmethodology.org.

Igualmente, os dejo el link a un documento donde se habla de todo lo que tendremos que tener en cuenta a la hora de realizar la selección de una herramienta ETL (características que habrán de tener, criterios para la evaluación, etc). Acceder al documento aquí.

Comparativa Talend / Pentaho

Si finalmente os decidis por utilizar herramientas ETL Open, la empresa francesa ATOL ha realizado una comparativa entre Pentaho y Talend con varios casos de ejemplo, comparativa de características, etc. (acceder al informe aquí , esta escrita en Frances pero es bastante completa).

Tambien os puede resultar interesante para comparar ambos productos la entrada del blog Wiki Wednesday, donde Vincent McBurney nos habla de los pros y contras de cada una de las herramientas, de una forma bastante completa (ademas hace referencia a varios sitios donde se estan analizando ambos productos).

Posted in ETL, Kettle, OpenSource, Pentaho, Talend | 5 Comments »

13.2. ETL para carga Dimension Producto. Mas ejemplos de Talend. Uso de logs, metricas y estadisticas.

Posted by Roberto Espinosa en 9 enero 2010


El siguiente proceso ETL que vamos a abordar es el de la carga de la Dimensión Producto. En esta dimensión se ubicarán, como ya vimos, los diferentes atributos relacionados con el producto que utilizaremos en nuestro sistema BI. Después de la revisión de la estructura física, teniendo en cuenta los origenes de datos, la estructura física de la tabla es la siguiente:

Diseño Fisico Tabla Dimensión Producto en MySql

Los procesos que tendremos que implementar utilizando Talend serán los siguientes (tal y como vimos en una entrada anterior del Blog):

Transformaciones para la creación de la Dimensión Producto

Para el desarrollo del proceso con Talend, vamos a ir un paso mas alla, definiendo información de logs, registro de estadísticas y métricas. Esto nos permitira conocer otra funcionalidad de Talend, y orquestar la ejecución de los jobs (para permitir, por ejemplo, la recuperación de la fecha de ultima ejecución del job para poder buscar los cambios en el maestro de materiales desde la ultima ejecución del proceso de traspaso), controlar los errores de ejecución y notificar por email en el caso de que se produzca algún problema.

El esquema completo del job con todos los pasos sería el siguiente (a continuación veremos de forma detallada cada uno de los pasos incluidos):

Proceso ETL en Talend completo para la dimensión Producto

Los pasos del proceso ETL para llenar la Dimensión Producto serán los siguientes:

1) Ejecución de un prejob que recuperará la fecha de ultima ejecución del proceso y registrara en el log el inicio de la ejecución del job. Además, se lanzará un logCatcher (para recoger las excepciones Java o errores en el proceso), que generará el envio de un email de aviso en el caso de que se produzca algún problema en cualquier paso del job.

2) A partir de la fecha de ultima ejecución, recuperamos del maestro de materiales en el ERP, todas las modificaciones o altas de productos realizadas en la tabla desde dicha fecha.

3) Realizamos una sustitución de valores erroneos o en blanco en los registros seleccionados según los criterios establecidos.

4) Completamos el mapeo de dimensión Producto, llenando el resto de campos que provienen de otras tablas en la base de datos (los campos de lookup),  con sus correspondientes consultas SQL.

5) En el mapeo se podrán generar materiales erróneos que habrá que verificar y corregir en el sistema origen (por tener valores incorrectos). La lista de materiales se introduciran en un fichero excel. Igualmente, contaremos el número de registros leidos desde el sistema origen correctos para guardarlos en las tablas de metricas.

6) Verificamos que realmente haya modificaciones con los datos existentes en la base de datos del DW, y para los registros que si tienen modificaciones (o si son nuevos registros), realizamos la actualización. En principio, no vamos a realizar gestión de Dimensiones Lentamente Cambiantes, sino que siempre tendremos la foto de los datos tal y como están los ficheros maestros en el momento actual (mas adelante si gestionaremos una dimensión con esta casuistica para conocer los componentes de los que dispone Talend para este cometido).

7) Concluimos el proceso guardandonos en el log el correspondiente mensaje de finalización correcta del proceso.

Antes de profundizar y ver en detalle cada unos de los pasos, vamos a ver la forma de activar en Talend la gestión de logs, estadisticas y metricas. El significado de cada uno de estos elementos es el siguiente:

  • Logs: sería el registro de los mensajes de error generados por los procesos, las excepciones Java al ejecutar o los mensajes generados por nosotros utilizando los componentes tDie o tWarn (para generar diferentes tipos de mensajes).
  • Stats (estadísticas): es el registro de la información estadística de los diferentes pasos y componentes que forman un job. Para cada paso, se puede activar el registro de estadísticas seleccionando la opción tStatCatcher Statistics. Se guarda información de cada paso, cuando empieza, cuando termina, su status de ejecución, duración, etc.
  • Meter, volumetrics  (métricas): es el registro de metricas (numero de registros de un flujo) que podemos intercalar en los procesos utilizando el control tFlowMeter.

Talend nos permite trabajar de dos maneras con todos estos registros (se pueden combinar): una sería gestionando nosotros mismos los logs, stats y meters que se generan (recolectandolas en tiempo de ejecución con los componentes tLogCatcher, tStatcatcher o tFlowMeterCatcher en cada job y dandoles el tratamiento oportuno) o bien activar la gestión automática a nivel de cada proyecto o job, seleccionando en que lugar queremos guardar los registros generados(con tres opciones: visualización en consola, registro en ficheros de texto planos o registro en base de datos). Con esta ultima opción, toda la información que se genere quedara registrada en tablas y será mas fácil explotarla para revisión de procesos realizados, orquestación de procesos, verificación de cuellos de botella, corrección de errores, etc.

Para activar la gestión a nivel de proyecto seleccionaremos la opción de menú Archivo –> Edit Project Properties, opción Job Settings, Stats & Logs (tal y como vemos en la imagen):

Opciones de estadísticas y logs a nivel de Proyecto

Estas propiedades quedan habilitadas para todos los jobs del proyecto, aunque luego se pueden ajustar en cada job según nos interese (puede haber jobs para los que no queremos guardar nada de información). Esto lo modificaremos en las propiedades de cada job, en la pestaña Stats & Logs. En principio, mandan las propiedades establecidas en el proyecto, pero se pueden generar excepciones (llevar los logs a un sitio diferente o no generar) para un job en concreto:

Opciones de estadísticas y logs a nivel de Job

Una vez realizada esta aclaración, veamos en detalle cada uno de los pasos del ETL:

1) Ejecución de un prejob que recuperará la fecha de ultima ejecución del proceso y registrara en el log el inicio de la ejecución del job. Además, se lanzará un logCatcher (para recoger las excepciones Java o errores en el proceso), que generará el envio de un email de aviso en el caso de que se produzca algún problema en cualquier paso del job. Los componentes utilizados en este paso inicial son los siguientes:

  • Lanzador Prejob (componente tPrejob): sirve para realizar el lanzamiento de un pretrabajo, anterior al proceso principal.
  • Ultima Fecha Ejecución (componente tMySqlInput): recuperamos de la tabla de registro de logs, la ultima fecha de ejecución correcta del job. Esta fecha nos servira de fecha de referencia para buscar las altas/modificaciones de productos en el ERP desde la ultima ejecución. Sino hay una ejecución anterior del job, construimos una fecha de referencia para lo que sería la carga inicial de la dimensión producto.
  • Mensaje Log Inicio (componente tWarn): genera un mensaje de log indicando que se comienza la ejecución del job.
  • Set Variable Fecha (componente tSetGlobalVar): la fecha de ultima ejecución recuperada en el paso anterior se registra en una variable global que se podrá utilizar posteriormente en cualquier paso del job.
  • Control Errores (componente tLogCatcher): activamos el componente que “escuchara” durante toda la ejecución del job, esperando que se produzca algún tipo de error. En ese momento se activara para recuperar el error y pasarlo al componente siguiente para el envio de un email de notificación.
  • tFlowtoIterate: convertimos el flujo de registros de log a una iteración para poder realizar el envio del correo electrónico.
  • Envio Email Notif (componente tSendMail): generamos el envio de un email de notificación de errores, incluyendo el paso donde se paro el proceso, y el mesaje de error generado. Es una forma de avisar que ha fallado algo en el proceso.

Para ver en detalle como hemos definido cada componente, podeis pulsar en el link de cada componente o para ver la documentación HTML completa generada por Talend pulsando aquí.

2) A partir de la fecha de ultima ejecución, recuperamos del maestro de materiales en el ERP, todas las modificaciones o altas de productos realizadas en la tabla desde dicha fecha.

Job DimProducto - Lectura Maestro Productos Sap

Para ello, utilizamos el componente LECT_MAESTRO_PRODUC TO del tipo tOracleInput (ver detalle aqui ), que nos permite acceder a la base de datos de Sap, que en este caso es Oracle. También podiamos haber realizado la lectura de Sap utilizando los componentes tSAPConnectiony tSAPInput). Observar la sentencia SQL ejecutada en el componente, y ver como combinamos el texto escrito con el uso de una variable global y el uso de funciones de Taled (que también podrían ser Java).

3) Realizamos una sustitución de valores erroneos o en blanco en los registros seleccionados según los criterios establecidos. Utilizando el componente AJUSTE_CAMPOS, del tipo tReplace (ver detalle aqui), con el que podemos buscar valores existentes en los registros recuperados (utilizando cadena regulares) e indicar una cadena de sustitución. Puede ser util para cualquier transformación que haya que realizar para determinados valores, para normalizar, para corregir registros erróneos, etc. En nuestro caso, la vamos a utilizar para sustituir registros sin valor (se podría haber optado también por rechazar dichos registros).

Job DimProducto - Ajuste Campos

4) Completamos el mapeo de dimensión Producto, llenando el resto de campos que provienen de otras tablas en la base de datos (los campos de lookup),  con sus correspondientes consultas SQL. Para ello utilizamos el componente MAPEO_PRODUCTO del tipo tMap (ver detalle aqui ).

Job DimProducto - Mapeo Producto

Con este componente, juntamos en un paso los registros leidos del maestro de materiales, y los valores adicionales que estan en otras tablas del ERP que nos permiten completar cada registro (como son los valores de descripciones, unidades de medida, calculo de equivalencia de unidades de medida, etc).

En este mapeo, utilizamos una funcionalidad de Talend que no habiamos visto, que es realizar un filtrado selectivo de los registros. Esto nos permite generar en el paso dos flujos de datos, uno con los registros correctos, y otro con los registros que no cumplan unas determinadas condiciones. En nuestro caso, los registros que tengan un valor NULL en el campo umren, serán rechazados y pasados a un paso posterior donde serán grabados en un fichero excel para su revisión.

5) En el mapeo se podrán generar materiales erróneos que habrá que verificar por parte de algún usuario y corregir en el sistema origen (por tener valores incorrectos). La lista de materiales se introducira en un fichero excel a través del control  REGISTROS_ERRONEOS del tipo tFileOutputExcel (ver aqui) . Igualmente, utilizando el componente CUENTA_LEIDOS_SAP del tipo tFlowMeter (ver aqui ),contaremos el número de registros correctos leidos desde el sistema origen para guardarlos en las tablas de metricas (para luego poder otener información estadística de los procesos realizados).

6) Verificamos que realmente haya modificaciones con los datos existentes en la base de datos del DW , y para los registros que si tienen modificaciones (o si son nuevos registros), realizamos la actualización. Para ello, utilizamos el componente VERIF_MODIFICACIONES del tipo tMap (ver aqui ) que recibira como flujo principal los registros que hemos leido desde Sap totalmente completados. Por otro lado, recibira como flujo de lookup (ver aqui) los registros que ya tenemos cargados en Myql en la tabla DWD_PRODUCTO (la tabla de la dimensión Producto). Con esta información, podremos realizar la comparación en el mapeo,  realizarando un filtrado selectivo de los registros, pasando al siguiente componente solo aquellos que tienen modificaciones (hay alguna diferencia en alguno de los campos).

Job DimProducto - Verificacion Modificaciones

El código utilizado en el expression filter, que es la condición de filtrado, es el siguiente:

!row11.material_desc.equals(row15.material_desc) ||
row11.familia_id!=row15.familia_id||
!row11.familia_desc.equals(row15.familia_desc)||
!row11.denom_id.equals(row15.denom_id)||
!row11.variet_id.equals(row15.variet_id)||
!row11.formato_id.equals(row15.formato_id)||
!row11.um_id.equals(row15.um_id)||
row11.litros_id!=row15.litros_id||
row11.linprod_id!=row15.linprod_id||
!row11.linprod_desc.equals(row15.linprod_desc)||
!row11.target_id.equals(row15.target_id)

Observar como vamos realizando la comparación campo a campo de los dos flujos, para determinar si hay algún cambio entre los datos ya cargados y los provenientes del ERP.

En principio, no vamos a realizar gestión de Dimensiones Lentamente Cambiantes, sino que siempre tendremos la foto de los datos tal y como están los ficheros maestros en el momento actual (mas adelante si gestionaremos una dimensión con esta casuistica para conocer los componentes de los que dispone Talend para este cometido). Los registros que superan el mapeo, son registrados en la base de datos Mysql utilizando el control ACTUALIZA_DWD_PRODUCTO, del tipo tMySqlOutput (ver detalle aqui ), grabandose como ya hemos dicho en la tabla DWD_PRODUCTO.

Con el componente tFlowMeter, en el paso CUENTA_MODIFICADOS (ver detalle aquí ), registramos en las tablas de metricas el número de registros que van a generar actualización.

7) Concluimos el proceso guardándonos en el log el correspondiente mensaje de finalización correcta del proceso, con el componente MENSAJE_LOG_FIN del tipo tWarn (ver detalle aqui).

Para ver en detalle como hemos definido cada componente, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Conclusiones

Hemos realizado nuestro primer trabajo ETL complejo utilizando Talend. Ha sido un poco complicado entender como funciona la herramienta, como se vinculan y encadenan los diferentes componentes, la forma de pasar la información y los registros entre ellos, como se gestionan los errores, etc. Pero una vez comprendidos los conceptos básicos, se observa el gran potencial que tiene Talend (que ademas puede ser completado con el uso del lenguaje Java por todas partes).  Os recomiendo si quereis ampliar el conocimiento de la herramienta, la lectura del Manual de Usuario de la herramienta y la Guia de Referencia de Componentes (ambos en inglés) en este link y visitar la web del proyecto Open TalendForge, donde podeis encontrar Tutoriales, Foros, gestión de bugs, etc.

También he visto lo importante que es el proceso de análisis de los origenes de información y el detallado de todas las transformaciones que hay que realizar, las excepciones, que criterio se sigue para ellas, que sustituciones realizamos, etc. Quizas deberiamos de haber realizado ese paso mas en profundidad, pues luego al realizar los procesos ETL han aparecido situaciones que no habiamos previsto. Lo tenemos en cuenta para nuestro próximo proyecto.

Igualmente hemos visto que es importante establecer un mecanismo para la gestión de todos los logs de la ejecución de procesos, estadísticas y metricas, pues luego nos serán de utilidad para montar los procesos de automatización, seguimiento y depuración de errores necesarios para la puesta en productivo del proyecto y para su mantenimiento a lo largo del tiempo.

Y como no, la documentación. El hecho de ir documentando y explicando cada componente que utilizamos en Talend (nombrado de los pasos, texto explicativo en cada componente, comentarios en los metadatos, etc), ha permitido que utilizando una funcionalidad estandar de Talend, la generación de documentación HTML, disponer de un repositorio donde poder consultar como estan construidos los procesos, de una forma muy completa y detallada, de cara a la comprensión de como están montados los procesos por parte de terceras personas, para su posterior modificación o mantenimiento en el futuro.

En la siguiente entrada del Blog, detallaremos los procesos ETL para la carga del resto de dimensiones de nuestro proyecto. Posteriormente, abordaremos el proceso ETL para la carga de la tabla de Hechos, que será la mas compleja y para la que habrá que establecer un mecanismo de orquestación para su automatización. En dicha entrada incluiremos igualmente el estudio del particionado de tablas utilizando Mysql, que veremos en profundidad.

Posted in Business Intelligence, ETL, OpenSource, Talend | 9 Comments »

13.1. Mas ejemplos de Talend. Ejecución de sentencias SQL construidas en tiempo ejecución.

Posted by Roberto Espinosa en 5 enero 2010


Después de llenar la dimensión Tiempo con los procesos ETL utilizando Talend, al revisar los registros de la tabla DWD_TIEMPO, comprobamos que para algunos años, la ultima semana del año se ha llenado con el valor 1. La explicación es que Java utiliza la normalización ISO para el número de semana, y esta nunca puede ser superior a 52. Por tanto, para algunos años, la ultima semana del año ha quedado registrada con el valor 1.

Este problema nos sirve de base para desarrollar nuestro seguiente proceso ETL, que ira encandenado a la generación de los registros de la dimensión tiempo, y que tendrá el objetivo de arreglar los registros que han quedado erróneos en la base de datos.

El proceso tendría los siguientes pasos:

1) Recuperación para cada año, del mayor número de semana registrado en la tabla: para ello, ejecutamos una sentencia SQL , utilizando el componente TMySqlInput del grupo Databases, Mysql).

La sentencia ejecutada es la siguiente:

"SELECT dwd_tiempo.ano_id,max(dwd_tiempo.sem_id) as semana
FROM    dwd_tiempo group by dwd_tiempo.ano_id
order by dwd_tiempo.ano_id"

Este control nos genera un flujo con todos los registros devueltos por la sentencia SQL y para cada registro realizaremos las acciones siguientes:

2) Para cada año, ejecutamos una sentencia SQL construida en tiempo de ejecución con los datos pasados por el control anterior,para arreglar el número de semana erronea (utilizando el mayor número de semana + 1). Para ello, utilizamos el control  tMySqlRow. Este control nos permite ejecutar una sentencia SQL para cada registro del flujo y transmitir dicho flujo al paso siguiente del job.

La sentencia ejecutada es la siguiente (observad como vamos construyendo la sentencia SQL concatenando trozos de texto fijo con los valores de la variable row, que seran pasados por el componente anterior de la secuencia):

"update    dwd_tiempo set sem_id =" +  row2.semana  +
" + 1 where ano_id = " +
 row2.ano_id  + " and sem_id = 1 and mes_id = 12"

3) Terminamos el proceso de arreglo corrigiendo el campo compuesto semano_id, que también quedo erróneo y que corresponde a la Semana del año en la notacion AAAA-SS, donde AAAA es el año y SS es la semana. Para ello, utilizamos también el control  tMySqlRow.

La sentencia ejecutada es la siguiente (construida igualmente concatenando trozos de texto fijo con los valores de la variable row, que seran pasados por el componente anterior de la secuencia). En este caso, también estamos utilizando funciones de Mysql (CONCAT y CAST), para hacernos una idea de la potencia del lenguaje SQL en combinación con la utilización de variables de Talend:

"update enobi.dwd_tiempo " +
"set semano_id = CONCAT(CAST(ano_id AS CHAR),'-',CAST(sem_id AS CHAR))"
+ " where ano_id = " +  row2.ano_id  + " and mes_id = 12"

Los pasos 2 y 3 los podríamos haber realizado en una única sentencia SQL, pero los hemos separado para mayor claridad.

El proceso completo sería el siguiente:

Esquema Completo del Job en Talend para el arreglo de las semanas

Seguimos avanzando en nuestro proyecto y una de las cosas que va quedando clara es que los conocimientos del consultor de BI han de cubrir muchas areas: bases de datos, sql, algo de lenguajes de programación (Java en el caso de Talend), herramientas de modelado, herramientas ETL, teoria de modelado de datos multidimensional con sus variantes, algo de estadística para el datamining, nociones de erp´s,crm´s, etc. Eso sin contar los conocimientos de las empresas, indicadores de negocio y la visión diferente que habrá que aportar a la empresa donde se realize el proyecto. Volvemos a acordarnos de lo que decía Jorge Fernández en su blog ( “El consultor de BI, ese bicho raro“).

A continuación, vamos a realizar el proceso ETL para la dimensión Producto.

Posted in Business Intelligence, ETL, OpenSource, Talend | 2 Comments »

 
A %d blogueros les gusta esto: