«Patrones de diseño de tareas» y mejores prácticas de Talend – 4.ª parte

«Patrones de diseño de tareas» y mejores prácticas de Talend – 4.ª parte

  • Dale Anderson
    Dale Anderson is a Customer Success Architect at Talend. Over a 30 year career, Mr. Anderson has gained extensive experience in a range of disciplines including systems architecture, software development, quality assurance, and product management and honed his skills in database design, modeling, and implementation, as well as data warehousing and business intelligence. A keen advocate for an appropriate temperance of the software workflow process, he has applied his innovations to the often overlooked lifecycle of a database. The Database Development Lifecycle Mr. Anderson has developed incorporates data modeling best practices to address the complexities involved in modeling adaptations, multi-environment fulfilments, fresh installations, schema upgrades, and data migrations for any database implementation.

 

Nuestro viaje por los patrones de diseño de tareas y mejores prácticas de Talend está llegando a una emocionante encrucijada. Mi humilde misión de compartir contenidos prácticos está cobrando vida propia. El éxito continuado de las anteriores entregas de la serie (por favor, consulte la 1.º parte, la 2.ª parte y la 3.ª parte si no lo ha hecho todavía), además de las presentaciones del Bootcamp técnico (gracias a la gente que asistió y pude conocer) y haber facilitado este material directamente a los clientes ha conllevado una demanda de transformación internamente. Gracias a ello hemos puesto en marcha un plan para crear varios webinars sobre esta serie y ponerlos a disposición dentro de poco. Ahora bien, rogamos un poco de paciencia, puesto que tardaremos un poco y tendremos que coordinar recursos, pero espero que el primero de estos webinars esté listo más o menos a principios de 2017. Me hace mucha ilusión y agradezco el constante interés que muestran leyendo estos artículos.

No obstante, como les prometí, ha llegado el momento de profundizar en otro grupo de mejores prácticas en materia de patrones de diseño de tareas en Talend. Para empezar, me gustaría recordarles algo muy sencillo, pero que mucha gente desconoce. Talend es un generador de código Java y, por lo tanto, elaborar unas orientaciones para sus desarrolladores fortalece y racionaliza el código Java que se genera con los patrones de diseño de tareas. Parece evidente, y lo es, pero la mejor forma que yo conozco de lograr grandes resultados es mediante unas tareas bien diseñadas que generen un código Java limpio pintando su lienzo con estos conceptos. Yo lo llamo «proyectos para el éxito».

Proyectos para el éxito de Talend

Crear tareas en Talend puede ser un proceso muy sencillo, pero también puede acabar siendo muy complejo. El secreto de su correcta implantación pasa por adoptar y adaptar los buenos hábitos y la disciplina necesarios.

Desde los «preceptos fundamentales» que analizamos al principio de esta serie hasta ahora, mi objetivo ha venido siendo siempre fomentar un debate sincero sobre estas prácticas recomendables para lograr unos patrones de diseño de tareas en Talend sólidos y útiles. La mayoría de los usos previstos mejorarán con un diseño de tarea atómico y una orquestación padre/hijo y, cuando los proyectos contengan una cantidad considerable de código reutilizable, el éxito general se acelera. Huelga decir que cada cual debe elegir su propio camino, pero cuando menos lo único que pido es esto: ¡sea coherente!

Ciclo de vida de desarrollo de las bases de datos (DDLC)

Pero, ¡un segundo! A lo mejor no todo depende del diseño de una tarea, ¿qué sucede con los datos? Nos dedicamos a procesar datos, ¿o no? En la mayoría de casos, los datos están alojados en una base de datos. Pues yo pregunto: ¿las bases de datos necesitan mejores prácticas? ¿Es una pregunta retórica? Los modelos de datos (esquemas) cambian con el tiempo, de modo que los diseños de bases de datos ¡también tendrán su propio ciclo de vida! Es de cajón.

Las bases de datos evolucionan y los desarrolladores debemos tenerlo en cuenta. Hemos aceptado nuestro proceso de SDLC, así que no debería ser difícil aceptar que necesitamos un Ciclo de vida del desarrollo de bases de datos también. Tal y como yo lo veo, la cosa no tiene secreto. Para cualquier entorno (DEV/TEST/PROD) una base de datos debe ser compatible con:

  • Una INSTALACIÓN desde cero: según la versión actual del esquema
  • Aplicar una VERSIÓN MEJORADA: eliminar/crear/alterar objetos de BD que actualicen una versión a la siguiente
  • MIGRACIÓN de datos: cuando tenga lugar una «actualización» disruptiva (como por ejemplo una división de tablas)

Entender el ciclo de vida de la base de datos y su impacto en el diseño de la tarea cobra una gran importancia. Es fundamental versionar su modelo de base de datos. Siga un proceso de diseño previsto. Utilice diagramas gráficos para ilustrar los diseños. Cree un «diccionario de datos» o un «glosario» y haga un seguimiento del linaje con los cambios históricos. Dentro de poco redactaré otro artículo para el blog más detallado sobre este tema. Esté atento. Mientras tanto, tenga en cuenta el siguiente proceso cuando diseñe modelos de bases de datos. Como disciplina es más exigente, ¡pero da resultados!

ddlc_dbdesignflow

 

Más mejores prácticas para el diseño de tareas

Muy bien. ¡He aquí otros patrones de diseño de tareas y mejores prácticas para su satisfacción y consumo inmediatos! Empiezan a ahondar en funcionalidades de Talend que a lo mejor le resulten conocidas o que quizá utilice muy de vez en cuando. Espero que le resulten de utilidad.

8 mejores prácticas más:

Búsquedas en tMap

Como muchos ya saben, el componente esencial tMap se utiliza extensamente en las tareas de Talend. El motivo son sus potentes capacidades de transformación.


El uso más habitual del componente tMap es el de mapear un esquema de flujo de datos desde la entrada fuente a la salida destino: Sencillo, ¿a que sí? ¡Pues claro! Sabemos que también podemos incorporar varios flujos de datos de esquema de origen y destino, lo que nos ofrece complejas oportunidades de combinar o dividir estos flujos de datos como mejor nos convenga, incorporando posiblemente expresiones de transformación que controlen qué datos de entrada se dispersan aguas abajo y de qué forma. Las expresiones dentro de un componente tMap pueden producirse en los esquemas de fuente o de destino. También pueden aplicarse mediante variables definidas en el componente tMap. Puede consultar la forma de proceder en este sentido en la Guía de referencia sobre componentes Talend. Eso sí, acuérdese: ¡un gran poder conlleva una gran responsabilidad!

tmaplookup1Otro uso muy potente del componente tMap es la incorporación de consultas que se combinan con el flujo de datos original. Si bien no existe un límite físico para el número de consultas que puede aplicar a un componente tMap ni en qué consisten los datos de consulta, hay una serie de cuestiones de orden real y práctico que debe plantearse.

Fíjese en este ejemplo básico: Dos generadores de fila: uno es la fuente, el otro la consulta. Al tiempo de ejecución, la generación de datos de consulta se produce primero y luego se tratan los datos fuente.

Como el ajuste de la combinación en los datos de consulta está configurado a «Load Once» (Cargar una vez), todos sus registros se cargan en memoria y luego se procesan comparándolos con el conjunto del resultado de los datos fuente. Este comportamiento por defecto proporciona combinaciones de alto rendimiento y puede ser muy eficiente.

tmaplookup2

Si no, es fácil imaginar que, al cargar millones de filas de consulta o decenas de columnas, se exigirían unos requisitos de memoria considerables. Sería lo más probable. ¿Y si se requieren múltiples consultas de millones de filas cada una? ¿Cuánta memoria se requeriría? Sopese detenidamente sus consultas cuando tenga muchos registros o centenares de columnas.

tmaplookup3Analicemos una disyuntiva: memoria o rendimiento. Existen tres modelos de consulta aplicables:

  • Load Once (Cargar una vez): lee todos los registros admisibles en memoria
  • Reload at each Row (Volver a cargar en cada fila): lee la fila admisible tan solo de cada registro fuente
  • Reload at each Row (cache) (Volver a cargar en cada fila, en caché): lee la fila admisible de cada registro fuente y la guarda en la memoria caché

Es evidente que los datos de consulta que se han cargado en memoria para combinarse con la fuente pueden ser bastante rápidos. No obstante, cuando las restricciones de memoria imposibilitan grandes cantidades de datos de consulta o cuando sencillamente no quiere cargar TODOS los datos de consulta por que en ese caso concreto no le hacen falta, utilice el modelo de consulta «Reload at each Row» (Volver a cargar en cada fila). Existe un pequeño truco que debe entender para que esto funcione.

Primero, en el componente tMap, cambie el modelo de consulta a «Read at each Row» (Leer en cada fila). Fíjese que la zona de abajo se expande para que pueda introducir la «clave o claves» que necesitará para realizar al consulta. Añada las claves, que en esencia definen las variables globales disponibles fuera del componente tMap.

tmaplookup4

Para el componente de la consulta utilice la función (datatype)globalMap.get(“key”) de la cláusula «WHERE» de su sintaxis SQL para aplicar el valor clave guardado definido en el tMap en el conjunto de datos de consulta. Esto completa la extracción de la consulta de cada registro procesado desde la fuente.

tmaplookup5

Pues ya lo tiene: ¡consultas eficientes con el método que sea!

Variables globales

Existen varios aspectos de la definición y el uso de lo que consideramos «variables globales». Los desarrolladores las creamos y utilizamos en tareas de Talend constantemente y las llamamos «variables de contexto». A veces están «integradas» (locales para una tarea) y otras en el «Repositorio de proyectos» como grupos de contexto, lo que permite reutilizarlas en distintas tareas.

En ambos casos son todas «variables globales» cuyo valor
viene determinado al tiempo de ejecución y puede utilizarse en cualquier punto de la tarea que las define. Sabrá que está utilizando una cuando tenga integrado un context.varname en un componente, expresión o activador (trigger). Recuerde que si guarda las variables de uso más común en un «proyecto de referencia» maximizará su acceso desde distintos proyectos.


Talend también proporciona los componentes tSetGlobalVar y tGlobalVarLoad, que pueden definir, guardar y utilizar «variables globales» en tiempo de ejecución. El componente tSetGlobalVar guarda un par de clave-valor en las tareas, que equivale a utilizar una «variable de contexto», y aporta un mayor control (como en el manejo de errores). Eche un vistazo a mi ejemplo, donde se recupera un único valor MAX(date) y luego se utiliza en una posterior consulta en SQL para filtrar una segunda recuperación de un conjunto de registros.

tsetglobalvar1

Para acceder a la variable global, utilice la función (datatype)globalMap.get(“key”) de la cláusula ‘WHERE’ de SQL. Aprenda a utilizar bien esta función, porque es probable que la emplee a menudo cuando haya descubierto su potencial.tglobalvarload1

El componente tGlobalVarLoad ofrece capacidades parecidas para tareas de big data en las que no está disponible el componente tSetGlobalVar. Observe mi ejemplo, en el que se calcula un valor agregado y luego se utiliza en una posterior lectura para clasificar los registros a devolver.tglobalvarload2

Hay más tela que cortar sobre esta cuestión. Ocultas a plena vista existe un conjunto de «variables globales de sistema» disponibles en una tarea cuyos valores vienen determinados por los mismos componentes. Hablamos de una de esas variables anteriormente, cuando tratamos la práctica recomendada para la resolución de errores, hace tiempo, en la primera parte de esta serie. CHILD_RETURN_CODE y ERROR_MESSAGE. Estas variables globales de sistema suelen estar disponibles para su uso inmediatamente después de la ejecución de un componente para ajustar su valor. En función del componente, habrá distintas variables de sistema disponibles. He aquí una lista parcial:

  • ERROR_MESSAGE / DIE_MESSAGE / WARN_MESSAGE
  • CHILD_RETURN_CODE / DIE_CODE / WARN_CODE / CHILD_EXCEPTION_STACK
  • NB_LINE / NB_LINE_OK / NB_LINE_REJECT
  • NB_LINE_UPDATED / NB_LINE_INSERTED / NB_LINE_DELETED
  • global.projectName / global.jobName (estas son de nivel de sistema; su uso es evidente)

Contextos de carga


Los «grupos de contexto» permiten un diseño de tarea muy reutilizable, pero sigue habiendo ocasiones en las que necesitamos un grado aún mayor de flexibilidad. Por ejemplo, pongamos que queremos conservar los valores por defecto de las variables de contexto externamente. A veces es más lógico tenerlos guardados en un archivo o incluso en una base de datos. Tener la capacidad de conservar estos valores externamente puede acabar siendo muy eficaz e incluso calmar ciertas preocupaciones en materia de seguridad. Aquí es donde entra en juego el componente tContextLoad.

tcontextload1

El ejemplo de arriba muestra una forma sencilla de diseñar su tarea para que inicialice variables de contexto al tiempo de ejecución. El archivo externo utilizado para cargar contiene pares de nombre clave-valor delimitados por comas y cuando se lean anularán los valores actuales por las variables de contexto definidas en la tarea. En este caso se cargan los detalles de la conexión con la base de datos para garantizar la conexión deseada. Fíjese que tiene cierto control sobre un cierto manejo de los errores y, en realidad, esto representa otro punto donde una tarea puede salir inmediatamente de forma programática. «Die on Error» (Interrumpir en caso de error). Se dan muy pocos casos. Ni que decir tiene que el componente tContextLoad puede utilizar una consulta a una base de datos con la misma facilidad y conozco varios clientes que lo hacen así.

Existe un componente tContextDump correspondiente disponible que escribe los valores actuales de la variable de contexto en un archivo o una base de datos. Puede ser una opción útil al idear diseños de tarea muy adaptables.

Uso de esquemas dinámicos

Muchas veces me preguntan cómo crear tareas que respondan a esquemas dinámicos. En realidad, la pregunta tiene trampa, porque los esquemas dinámicos los encontramos en casuísticas muy distintas. La más habitual parece centrarse en los casos en los que tenemos muchas tablas con datos que queremos trasladar a otro conjunto de tablas correspondiente, tal vez a un sistema de bases de datos distinto (por ejemplo, de Oracle a MS SQL Server). Crear una tarea para mover esos datos es fácil, pero casi de inmediato llegamos a la conclusión de que crear una tarea para cada tabla no es práctico. Y si tenemos centenares de tablas, ¿qué hacemos? ¿No podríamos sencillamente crear una única tarea capaz de manejar TODAS las tablas? Por desgracia, esto en Talend sigue siendo una limitación. Pero arriba esos ánimos, porque podemos lograrlo igualmente con DOS tareas: Una para volcar los datos y otra para cargarlos: ¿le parece aceptable?

tsetdynamicschema1

Esta es mi tarea de muestra. Se establecen tres conexiones: las dos primeras para recuperar las listas TABLE y COLUMN y la tercera para recuperar los datos en sí. Sencillamente con la iteración de cada tabla, guardando las columnas, puedo leer y escribir datos en un archivo plano posicional (el proceso DUMP o de volcado) utilizando el componente tSetDynamicSchema. Una tarea parecida haría lo mismo, salvo que la tercera conexión leería el archivo posicional y escribiría en el almacén de datos de destino (el proceso LOAD o de carga).

En este caso, los desarrolladores deben entender un poco los entresijos de su base de datos anfitriona. La mayoría de sistemas, como Oracle, MS SQL Server o MySQL, tienen tablas de sistema, muchas veces llamadas un «esquema de información», que contienen metadatos de objeto sobre una base de datos, incluidas tablas y sus columnas. Aquí tenemos una consulta que extrae una lista completa de tabla/columnas de mi base de datos MySQL de la TAC versión 6.1 (¿le gusta mi formato de sintaxis de SQL preferido?):

screen-shot-2017-01-09-at-11-04-28-am

Asegúrese de que utiliza credenciales de conexión con permisos «SELECT» para esta base de datos, que suele estar protegida.

Observe cómo uso el componente tJavaFlex para iterar por los nombres de tabla encontrados. Guardo todos los «nombres de tabla» y fijo un aviso de «control break», luego itero cada tabla encontrada y extraigo su lista de columnas ordenada. Una vez ajustados posibles valores nulos en la longitud de las columnas, el «esquema dinámico» guardado está terminado. El «IF» condicional comprueba el aviso de «control break» cuando el nombre de la tabla cambia y empieza el proceso de volcado de la tabla actual. ¡Tachán!

Componentes dinámicos de SQL

¡El código dinámico es una maravilla! Talend prevé varias formas de implantarlo. En el diseño de tarea anterior he utilizado un enfoque directo para recuperar las listas de tablas y columnas de una base de datos. En realidad Talend ofrece unos componentes de sistema anfitrión concretos que cumplen la misma función. Estos componentes t{DB}TableList y t{DB}ColumnList (en los que {DB} se sustituye por el nombre del componente anfitrión) proporcionan acceso directo a los metadatos del «esquema de información» sin tener que saber realmente nada al respecto. Emplear estos componentes en lugar del proceso DUMP/LOAD que he descrito antes también podría funcionar, ¿pero qué gracia tendría?

No todas las consultas en SQL necesitan recuperar o almacenar datos. A veces son necesarias otras operaciones con base de datos. Para ello haga uso de los componentes t{DB}Row y t{DB}SP. El primero le permite ejecutar prácticamente cualquier consulta en SQL que no devuelva un conjunto de resultados, como «DROP TABLE» El segundo le permite ejecutar un «procedimiento almacenado».

Por último tenemos el componente t{DB}LastInsertId, que recupera el «ID» insertado más reciente del componente de salida de una base de datos, cosa que a veces resulta muy útil.

CDC

Otra pregunta habitual que me formulan es: ¿Talend admite Captura de datos modificados (CDC, en inglés)? La respuesta es que SÍ, por supuesto: Mediante los mecanismos «Publish/Subscribe» vinculados directamente con el sistema de la base de datos anfitrión en cuestión. Conviene fijarse en que no todos los sistemas de bases de datos permiten CDC. He aquí la lista definitiva «actual» de compatibilidad con CDC en tareas Talend:

screen-shot-2017-01-09-at-11-15-36-am

Existen tres modalidades de CDC disponibles, que son:

  • Trigger (por defecto): utiliza los activadores anfitriones de la BD que hacen seguimiento de inserciones, actualizaciones y supresiones
  • Redo/Archive Log: tan solo se utiliza con Oracle 11g y versiones anteriores
  • XStream: tan solo se utiliza con Oracle 12 y OCI

Como el modo «Trigger» es el más habitual, echemos una ojeada a su arquitectura:

cdcprocessflow

La Guía de uso de Talend, capítulo 11 incluye un análisis exhaustivo del proceso, configuración y uso del CDC en Studio y en coordinación con su sistema de base de datos anfitrión. Si bien desde el punto de vista conceptual la cosa no tiene secreto, sí exige prestar atención a la configuración. Entienda perfectamente sus requisitos, modalidades de CDC y parámetros de diseño de tareas desde buen principio y ¡documéntelos bien en sus Orientaciones para el desarrollo!

Una vez creado, el entorno de CDC proporciona un sólido mecanismo para tener al día los destinos aguas abajo (que suelen ser un almacén de datos). Utilice los componentes t{DB}CDC de sus tareas en Talend para extraer datos que haya cambiado desde su última extracción. Aunque el CDC sea un proceso largo y exige diligencia para configurarlo y volverlo operativo, es una funcionalidad muy útil.

Componentes personalizados

Aunque Talend actualmente ofrece más de 1000 componentes en su paleta, existen muchos motivos para seguir creando componentes propios. Los desarrolladores de Talend suelen encapsular una funcionalidad especializada en un componente personalizado. Algunos han creado y convertido en producto sus componentes, mientras que otros los publican con acceso gratuito en Talend Exchange, que recientemente ha sido modernizado. Cuando un componente no está disponible en la paleta de Talend, búsquelo aquí, porque es posible que encuentre exactamente lo que necesita. Se necesita una cuenta de «Talend Forge», pero seguramente a estas alturas ya tendrá una creada.

customcomponents1Para empezar, asegúrese de que el directorio donde se guardarán los componentes personalizados esté configurado correctamente. Compruébelo en el menú «Preferences» (Preferencias) y elija una ubicación corriente que todos los desarrolladores utilizarían. Haga clic en «Apply» (Aplicar) y luego en «OK».

Encuentre el enlace «Exchange» en la barra de menús, que permite seleccionar e instalar componentes. La primera vez marque «Always run in Background» (Ejecutar siempre en segundo plano) y haga clic en el botón «Run in Background» (Ejecutar en segundo plano), puesto que la carga de la amplia lista de objetos disponibles es un proceso largo. A partir de esta lista, puede «View/Download» (Ver/descargar) los objetos que le interesen. Una vez completada la descarga de un componente, haga clic en «Downloaded Extensions» (Extensiones descargadas) para instalarlas realmente y utilizarlas en su Studio. Al terminar, el componente aparecerá como «Installed» (Instalado) y estará disponible en la paleta.

customcomponents2

Una vez instalados puede resultar difícil encontrar un componente y sus archivos asociados. Busque en dos sitios:

{talend}/studio/plugins/org.talend.designer.components.exchange{v}
{talend}/studio/plugins/org.talend.designer.components.localprovider{v}

Si desea crear un componente personalizado usted mismo, cambie a la perspectiva «Component Designer» (Diseñador de componentes) en Studio. La mayoría de componentes personalizados utiliza «JavaJet», que es la extensión de archivos para encapsular código Java para el «IDE de Eclipse». Para principiantes tienen un tutorial muy decente sobre «Cómo crear un componente personalizado». Si bien tiene ya años un años (aprox. 2013), recoge los conceptos básicos que debe conocer. También puede encontrar tutoriales de otras fuentes (algunos aparecen en el tutorial). Este es bueno: Talend by Example: Componentes personalizados. Pruebe también a buscarlo en Google si necesita aún más información para crear «componentes personalizados».

JobScript API

Normalmente usamos el «Diseñador» para pintar nuestra tarea de Talend, que luego genera el código Java subyacente. ¿Se ha preguntado alguna vez si puede generarse automáticamente una tarea de Talend? ¡Pues sí existe una manera! Abra una de sus tareas. En la parte inferior del lienzo hay tres pestañas: DESIGNER, CODE y JOBSCRIPT. Hmm, qué interesante. Seguramente habrá hecho clic en la pestaña CODE para inspeccionar el código Java generado. ¿Ha probado la pestaña JOBSCRIPT? Si es así, ¿sabe qué es lo que ha visto? Seguro que la mayoría no lo sabe. Esta pestaña muestra el script que representa el diseño de la tarea. La próxima vez, obsérvelo más de cerca. ¿Ve algo que le suene en cuanto al diseño de la tarea? Venga, seguro que sí...

¿Pero qué es?, se preguntará. ¡Pues se lo cuento! Imagine que crea y mantiene unos metadatos en algún lugar sobre su diseño de tarea y los ejecuta a través de un motor de procesamiento (que usted cree), con lo que genera el JobScript correctamente formateado y a lo mejor ajusta unos elementos clave para crear varias permutaciones de la tarea. Ahora la cosa se pone interesante.

jobscript1

Vaya al «Repositorio de proyectos» bajo el apartado CODE>ROUTINES y busque la carpeta «Job Scripts». Cree un nuevo JobScript (yo al mío lo he llamado «test_JobScript»). Abra cualquier tarea y copie los contenidos de la pestaña JobScript, péguelos en el archivo JobScript y guárdelo. Haga clic con el botón derecho en el JobScript y elija «Generate Job» (Generar tarea). Ahora vaya a la carpeta «Job Designs» (Diseños de tarea) y encontrará recién sacada del horno. ¡Imagine todo lo que puede hacer ahora! ¡Fantástico!

Conclusión

¡Uau! Con esto terminamos. Eso no quiere decir que no haya otras prácticas recomendables para la creación y mantenimiento de diseños de tareas en Talend, porque estoy convencido de que habrá muchas más. seo-small-business-competition-300x300Si quiere seguir investigando, hable con toda la comunidad y descúbralas. Quiero pensar que con esta compilación (32 en total) le he dado una visión de conjunto sobre estos proyectos para el éxito que podemos generar gracias a Talend.


En mi próxima entrega de esta serie cambiaremos de tercio y veremos cómo aplicar todas estas mejores prácticas a un caso práctico convencional. ¡Tecnología aplicada, metodologías sólidas y soluciones que logran resultados! Ese es el mejor resumen para saber dónde emplear estas mejores prácticas y patrones de diseños de tareas. ¡Que vaya bien!

Join The Conversation

0 Comments

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *