Patrones de diseño de tareas y mejores prácticas de Talend: 2.ª parte

Patrones de diseño de tareas y mejores prácticas de Talend: 2.ª 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.

 

¡Qué alegría que mi anterior publicación en el blog sobre «Patrones de diseño de tareas» y mejores prácticas de Talend haya tenido tan buena acogida! Gracias a todos los que lo hayan leído. Si aún no lo ha hecho, le invito a leerlo ahora antes de proseguir, porque la segunda parte partirá de donde lo dejó la primera para ahondar un poco más en la materia. Además, creo que es conveniente que abordemos algunos aspectos más avanzados también, con lo que prepárense, que vienen curvas. La cosa se va a poner aún más interesante.

Empezar a trabajar con diseños de tareas

Como desarrollador de Talend avezado, siempre me intereso por cómo crean los demás sus tareas. ¿Utilizan las funciones correctamente? ¿Adoptan un estilo reconocible o uno que yo no haya visto antes? ¿Se les ha ocurrido alguna solución chula y singular? ¿O la naturaleza abstracta de los datos/flujos de trabajo en el lienzo/componente resulta un poco agobiante y parece un pasillo oscuro que no sabes a dónde te lleva? Independientemente de la respuesta a cualquiera de estas preguntas, me parece muy importante utilizar la herramienta tal y como fue diseñada. Para ello he iniciado este viaje para analizar los «patrones de diseño de tareas» y las mejores prácticas que llevan asociadas. Me parece que, incluso habiendo aprendido todas las prestaciones y funcionalidades de Talend, la necesidad fundamental de descubrir la mejor forma de crear tareas sigue ahí.

Por lógica, el factor que es el motor principal de cualquier tarea de Talend es su «uso comercial». En realidad, he visto muchas variaciones sobre el mismo flujo de trabajo y muchas variedades de flujos de trabajo distintos. La mayoría de estos «usos» arranca de la premisa básica de que una tarea de integración de datos, en su forma más sencilla, consiste en extraer datos de una fuente y procesarlos, puede que transformándolos por el camino, para acabar cargándolos en algún destino. Por lo tanto, el código de ETL/ELT es nuestro ingrediente principal. A eso nos dedicamos los desarrolladores de Talend. Así que no voy a aburrirles con lo que ya saben. Mejor ampliemos la perspectiva...

Sin demasiados peros, la última versión de Talend (V. 6.1.1) es la mejor con la que he trabajado jamás. Con todos los nuevos componentes de big data, Spark, machine learning, la IU modernizada e integración/despliegue continuos automatizados (por mencionar tan solo algunas novedades destacadas), considero que estamos hablando de la tecnología de integración de datos más robusta y versátil que podemos encontrar hoy por hoy en el mercado. Vale, estoy barriendo un poco para casa, pero entiendo perfectamente como se siente usted, el cliente, porque yo también lo he pasado, así que espero que me crea, aunque entenderé que quiera juzgarlo por sí mismo.

Tres cimientos de un proyecto de integración de datos satisfactorio

A ver, todos los taburetes tienen tres patas, ¿a que sí? Pues lo mismo pasa con el desarrollo de software. Son tres los elementos esenciales necesarios para crear y entregar un proyecto de integración de datos satisfactorio:

  • Finalidad práctica:un requisito de datos/flujos de trabajo corporativos bien definido
  • Tecnología:las herramientas con las que diseñaremos, desplegaremos y ejecutaremos la solución
  • Metodología: una forma de trabajar consensuada

Teniendo esto en cuenta y disponiendo de un documento bien definido de «Orientaciones para el desarrollo» (¿ha leído mi artículo anterior? ¿ha creado alguno para su proyecto?), trabajemos a partir de estos requisitos.

Ensanchar los fundamentos

Si las «tareas» de Talend comprenden la tecnología de un flujo de trabajo para una «finalidad de uso», entonces los «patrones de diseño de tareas» son la «metodología» para su creación considerada mejor práctica. Si no encuentra nada más en mis entradas del blog que le resulte de valor, ¡al menos sea coherente a la hora de crear sus tareas! Si ha descubierto una forma mejor y le funciona, fantástico: no cambie nada. Pero si tiene dificultades con el rendimiento, la reusabilidad y la facilidad de mantenimiento o si constantemente le toca rehacer el código par adaptarlo a unos requisitos cambiantes, entonces estas mejores prácticas le serán de suma utilidad como desarrollador de Talend.

9 mejores prácticas más que tener en cuenta:

Ciclo de vida de desarrollo del software (SDLC)

«Personas, productos y procesos», según el multimillonario Marcus Lemonis de «The Profit» (CNBC), son las tres claves que determinan el éxito o el fracaso de toda empresa. ¡Y estoy de acuerdo! El proceso de SDLC es el momento de la verdad para cualquier equipo de desarrollo de software. Resulta esencial atinar en esta fase y, si no le damos la importancia que merece, pondremos gravemente en peligro nuestro proyecto y, a menudo, generaremos fracasos estrepitosos. La Guía de mejores prácticas de SDLC de Talend analiza a fondo los conceptos, principios, especificaciones y detalles sobre las funcionalidades de integración y despliegue continuos que los desarrolladores de Talend tenemos a nuestro alcance. Recomiendo encarecidamente a todos los desarrolladores de software que incorporen mejores prácticas de SDLC a su documento «Orientaciones para el desarrollo» que apunté en la publicación anterior de esta serie. ¡Pues a trabajar!

Administrar espacios de trabajo

Cuando instale Talend Studio en su portátil/estación de trabajo (asumiendo que tiene derechos de administrador), lo habitual es que se cree un directorio por defecto llamado «Workspace» (Área de trabajo) en su disco duro local y, como sucede con muchas instalaciones de software, esa ubicación por defecto se encuentra en el directorio donde se sitúan los ejecutables. No me parece que sea una buena práctica, la verdad. ¿Por qué?

Las copias locales de los archivos del proyecto (tareas y metadatos del repositorio) se guardan en ese «Workspace» y, cuando se adjuntan a un sistema de control de código fuente (p. ej.: SVN o GIT) mediante Talend Administration Center (TAC), se sincronizan al abrir un proyecto y al guardar los objetos. Yo creo que esos archivos deberían estar en un lugar donde podamos identificarlos y administrarlos fácilmente. Lo ideal sería en cualquier otro lugar del disco (o tal vez en otro disco local directamente).

Por si no queda claro, un área de trabajo se utiliza cuando uno crea una conexión en Talend Studio. Puede tratarse de una conexión «local» o «remota»; la diferencia es que una conexión «local» no la administra TAC, mientras que una «remota», sí. Para nuestros clientes de suscripción, la conexión «remota» suele ser el único tipo utilizado.

En su documento «Orientaciones para el desarrollo» debería constar con toda claridad cómo organizar la estructura de su directorio y todo el equipo debería adoptarla para lograr una cooperación y una colaboración óptimas. El secreto pasa por consensuar algo que les funcione a todos, inculcar disciplina y ser coherentes.

Proyectos de referencia

¿Utiliza proyectos de referencia? ¿Sabe qué son? He descubierto que muchos de nuestros clientes ni siquiera saben que existe esta función tan sencilla, pero tan productiva. Todos queremos crear código reutilizable, habitual o genérico que pueda compartirse en varios proyectos. Muchas veces me encuentro que los desarrolladores abren un proyecto, copian un fragmento de código y lo pegan en un proyecto o tarea distintos (o incluso los mismos). O, si no, exportan objetos de un proyecto y los importan en otro. ¡Me declaro culpable! Yo he hecho ambas cosas en esta vida. Si bien son opciones que a grandes rasgos funcionan, no nos conviene hacerlo; la cosa puede volverse una pesadilla a efectos de mantenimiento, como sabrán los que se hayan sentido atrapados en este proceso. ¡ASÍ QUE, UN MOMENTO! Hay una forma mejor: Proyectos de referencia! ¡Uf, qué alegría tuve cuando los descubrí!

Si alguna vez han usado TAC para crear proyectos, tal vez haya visto una discreta casilla llamada «Referencia». ¿Se ha preguntado para qué sirve? Pues si crea usted un proyecto y marca esa casilla para convertirlo en «Proyecto de referencia», desde ese momento dispondrá de las opciones «Incluir» y «Vincular» a cualquier otro proyecto. El código creado en este «Proyecto de referencia» estará disponible (tan solo como lectura) en aquellos proyectos vinculados, por lo que será muy reutilizable. Es el lugar adecuado para crear todos sus objetos comunes y código compartido.

 

 
 
 
 
 
 

No obstante, más vale que estos «Proyectos de referencia» sean los mínimos; aconsejamos tener tan solo 1 considerado mejor práctica, aunque en ciertos casos discutibles puede tener más (2 o 3). AVISO: crear demasiados «Proyectos de referencia» puede resultar contraproducente, así que no se pasen. Es muy importante administrarlos escrupulosamente; su uso y sus reglas deberían recogerse con claridad en su documento «Orientaciones para el desarrollo» y que todo el equipo lo adoptara para lograr una cooperación y una colaboración óptimas.

Convenciones de nomenclatura de objetos

«¿Qué tiene un nombre? Lo que llamamos rosa olería tan fragante con cualquier otro nombre.» – ¿Quién lo dijo esto, por cierto?

Da igual, tampoco importa. ¡Pero las «convenciones de nomenclatura» sí importan! Todo equipo de desarrollo digno de su nombre lo sabe y lo establece como una práctica. Independientemente del nombre, el momento o la manera de nombrar los objetos en Talend, en ese aspecto la coherencia vuelve a ser fundamental para que el resultado sea razonablemente satisfactorio. Las convenciones de nomenclatura de los objetos en Talend deberían constar con toda claridad en su documento «Orientaciones para el desarrollo» y todo el equipo debería adoptarlas para lograr una cooperación y una colaboración óptimas (no sé si observa una cierta pauta en común).

Repositorio de proyectos

Cuando abra su proyecto con Talend Studio (el IDE de Eclipse, es decir, el Entorno de Desarrollo Integrado, o sencillamente su editor de tareas), el panel de la izquierda representa el Repositorio de proyectos. Ahí es donde están alojados todos sus objetos de proyectos. Allí encontrará varios apartados importantes. Es evidente que deberían sonarle los apartados de «Job Designs» (Diseños de tareas), que en la versión 6.1.1 traen mejoras para adaptarse a los tres distintos tipos de tareas que puede crear (integración de datos, por lotes y en streaming), pero hay otros apartados que convendría que conociera y supiera utilizar.

  • Context Groups (Grupos de contexto): en lugar de crear variables de contexto integradas por tarea, créelas en un Grupo de contexto del repositorio y reutilícelas en distintas tareas (y proyectos, cuando se incluyan en un proyecto de referencia). Alinee los grupos de la forma más eficaz; la mejor práctica dicta crear grupos para sus distintos entornos: SBX/DEV/TEST/UAT/PROD, en el que DEV es el valor por defecto; elimine el contexto «por defecto» existente;

 

 

Fíjese que he añadido una variable de contexto «SysENVTYPE» que contiene el valor de programabilidad dinámica en un entorno seleccionado. Dicho de otro modo, utilizo esta variable dentro de una tarea para determinar en tiempo de ejecución qué entorno se está ejecutando en este momento para poder alterar mi flujo programáticamente con lógica condicional.

 

  • Metadatos: los metadatos presentan formatos distintos; ¡utilícelos todos! Conexiones a bases de datos y sus esquemas de tabla, diseños de archivos planos de todo tipo (.csv; .xml; .json y muchos más); además del siempre útil Esquema genérico, que puede utilizarse de tantas maneras que ni siquiera soy capaz de enumerarlas aquí, porque este artículo no terminaría nunca
  • Documentación: genere su propia Wiki de proyecto y publíquela para su equipo; esta funcionalidad producirá todo un conjunto de archivos en html sobre su proyecto en los que podrá navegar fácilmente. ¡Una herramienta tan útil y se tarda apenas unos minutos en crearla!

Sí, incluya algunas mejores prácticas parar su equipo en su documento «Orientaciones para el desarrollo» y aplíquelas. Se pueden modificar en cualquier momento, pero es importante que el equipo vaya a una.

Control de versiones (ramificación y etiquetado)

Habrá visto que cada pestaña de propiedades de tarea tienen un lugar donde configurar esquemas de numeración de versión «M»ayores y «m»enores. Además, puede determinar un estado de cosecha propia cuyas posibilidades por defecto incluyan «development» (desarrollo), «test» (prueba) y «production» (producción). ALERTA: están pensadas para el desarrollador que trabaja solo (TOS: Talend Open Studio) que no cuenta con la ventaja del desarrollo cooperativo o el control de código fuente (SCC, en inglés) en repositorios de SVN/GIT. Lo que debe saber es que cada vez que modifica esas propiedades internas de tarea se genera una copia completa de la tarea en su área de trabajo local y se sincroniza con el sistema de SCC. He visto proyectos en los que se hacían copias de tareas después de más de una decena de cambios internos de versión. Se copian TODAS las copias de esa tarea, lo que provoca un efecto multiplicador de los archivos subordinados, que se sincronizan todos con el SCC. Esto puede sobrecargar el proyecto y provocar graves problemas de rendimiento al abrirlo y cerrarlo. Si le pasa esto, tendrá que limpiar su área de trabajo exportando y volviendo a importar tan solo la versión superior de la tarea. Pues sí, una lata, pero necesaria.

La mejor práctica en cuanto a control de versiones de todos los entornos con suscripciones de pago consiste en utilizar mecanismos nativos ramificación y etiquetado de SCC. Siempre es la mejor manera de administrar los lanzamientos de versiones de proyectos, dado que el SCC tan solo mantiene la información delta cada vez que se guarda la tarea. Esto tiene un efecto drástico en la reducción del espacio necesario para el historial de cada tarea. Idee un programa de versionado con números, fechas o lo que le resulte de utilidad, plásmelo en el documento «Orientaciones para el desarrollo» y que todo el equipo adopte el proceso (¡al final le pillaremos el truco!).

Gestión de la memoria

¿Así que desea ejecutar su tarea? ¿Ha tenido en cuenta sus necesidades de memoria? ¿El flujo de datos está procesando millones de filas o tiene muchas columnas, o muchas consultas en el tMap? ¿Se ha planteado que, cuando la tarea se ejecuta en el «Job Server» (Servidor de tareas), podrían estar ejecutándose otras tareas al mismo tiempo? ¿Ha pensado cuántos núcleos/cuánta RAM tiene ese «Servidor de tareas»? ¿Cómo ha configurado los JOINS de tMap; «Load Once» (Cargar una vez) o «Row by row» (Fila por fila)? ¿Su tarea invoca tareas hijo o la invoca una tarea padre, y de cuántos niveles de tareas anidadas estamos hablando? ¿Las tareas hijo se ejecutan en una JVM separada? Si escribe tareas de ESB, ¿sabe cuántas rutas se están generando? ¿Utiliza técnicas de paralelización (ver más abajo)? ¿Y bien? ¿Ha tenido todo esto en cuenta? ¿Cómo dice? Supongo que no...

La función de unos ajustes por defecto es proporcionar unos valores base para unos ajustes configurables. Las tareas tienen varios, como la asignación de memoria. Pero los valores por defecto no siempre son correctos; en realidad, lo más probable es que sean erróneos. Su «Use Case Job Design» (Diseño de tarea según caso práctico), su «Operational Ecosystem» (Ecosistema operativo) y su «Real Time JVM Thread Count» (Recuento de hilos de JVM en tiempo real) determinan la cantidad de memoria utilizada. Esto debe gestionarse.

 

 

Puede especificar los ajustes de la memoria de la JVM a nivel de proyecto o para tareas concretas (como arriba):

Preferences > Talend > Run (Preferencias > Talend > Ejecutar)

¡Vale más acertar con esto o lo sufrirá en sus carnes! La gestión de memoria suele merecer poca atención y, como equipo, desde un punto de vista de desarrollo y operatividad, las directrices deberían documentarse y seguirse correctamente. ~ ¿Ahora sí quiere leer aquel primer artículo ya?

Sintaxis dinámica de SQL

Muchos componentes de entrada de bases de datos necesitan que se incluya una sintaxis de SQL correcta en su pestaña «Basic Settings» (Ajustes básicos). Por supuesto, también se puede introducir la sintaxis directamente en el componente tMyDBInput y no pasa nada. Aun así, piense en el requisito de que, cuando una consulta de SQL compleja debe construirse dinámicamente a tiempo de ejecución a partir de una cierta lógica atenuante controlada por la tarea, o por su tarea padre, la manera de enfocar el problema es bastante sencilla. Cree «variables de contexto» para las nociones básicas de la consulta de SQL, configúrelas en el flujo de la tarea antes de llegar al componente tMyDBInput y luego utilice esa variable de contexto en lugar de una consulta integrada en el código.

Por ejemplo, he desarrollado un «grupo de contexto» en un repositorio de proyectos de «referencia» que he llamado «SystemVARS» y contiene diversas variables útiles y reutilizables. Para el paradigma dinámico de SQL defino las siguientes variables de «cadena» inicializadas a «null»:

 

 

Configuro estas variables en un componente tJava según mis necesidades y luego las coso al campo de consulta tMyDBInput de esta forma:

“SELECT “ + Context.sqlCOLUMNS + Context.sqlFROM + Context.sqlWHERE

Fíjese que siempre incluyo un «espacio» al final del valor de la variable para que la concatenación quede limpia. En los casos en los que sea necesario un mayor control, utilizo una variable «sqlSYNTAX» también y controlo de forma condicional cómo concateno las cláusulas de la sintaxis de SQL y sencillamente pongo el Context.sqlSYNTAX en el campo de consulta de tMyDBInput. ¡Tachán! Vale, desde la perspectiva del host de la base de datos no es SQL dinámico, ¡pero sí es SQL generado dinámicamente para su tarea!

En resumen: documente esta orientación y ¡que todo el equipo trabaje de la misma manera!

Opciones de paralelización

Talend ofrece varios mecanismos que permiten la paralelización del código. Si se usan de forma correcta y eficiente, y reflexionando en serio sobre cómo pueden afectar al núcleo de la CPU y al uso de la RAM, se pueden crear patrones de diseños de tareas con un rendimiento altísimo. Echemos un vistazo a la retahíla de opciones:

  • Plan de ejecución: se pueden configurar varias tareas/actividades para que se ejecuten en paralelo desde la TAC
  • Flujos de tareas múltiples: se pueden activar varios flujos de datos en una misma tarea que compartan un mismo hilo. Cuando no haya dependencias entre ellos, puede ser una técnica para situaciones de uso peculiares. En general, yo lo evito, prefiero crear tareas por separado
  • Tareas padre/hijo: al invocar una tarea hijo con el componente tRunJob puede marcar la casilla «Use an independent process to run subjob» (Utilizar un proceso independiente para ejecutar la subtarea), que creará un montón/hilo de JVM separado para ejecutar en él la tarea hijo. Si bien no es paralelización en sentido estricto, sí la utiliza
  • Componentes: el componente tParallelize enlaza varios flujos de datos para su ejecución; los componentes tPartitioner, tDepartitioner, tCollector y tRecollector proporcionan control directo de los distintos hilos en paralelo de un flujo de datos
  • Componentes de BD: la mayoría de componentes de entrada/salida de BD presentan una configuración avanzada para permitir los recuentos de hilos de paralelización en enunciados concretos de SQL. Pueden resultar muy eficientes, pero si configuramos un número demasiado alto puede generar el efecto contrario. La proporción aconsejables es de 2-5.

Se pueden utilizar todos estos métodos de paralelización combinándolos, como anidados, pero conviene ser cautelosos y saber siempre cuánta memoria estamos usando. Tenga siempre en cuenta el flujo de ejecución del patrón de diseño de tarea. Sepa que las opciones de paralelización tan solo están disponibles en la oferta de Talend Platform como funcionalidad avanzada. Excluya las orientaciones de paralelización de su documento... ¡ES BROMA!

El secreto para crear bien tus tareas con Talend

Espero que, después de conocer estas mejores prácticas sobre los patrones de diseño de tareas, se replanteará cuál es la mejor manera de crear tareas con Talend. A grandes rasgos, para que las tareas estén bien hechas se necesitan orientaciones, disciplina y coherencia. Basta con decidirse y cumplir las premisas. Al pintar el código en el lienzo de datos/flujos de trabajo, recuerde:

«¡La acción es la clave fundamental de todo éxito!»- Pablo Picasso

Por último, le ofrezco una enumeración de consejos que resumen lo que considero los secretos para crear tareas bien hechas con Talend:

  • - Utilice tanto componentes tPreJob como tPostJob
  • - No abarrote el lienzo con componentes atiborrados: dispérselos un poco
  • - Disponga bien su código: de arriba abajo y de izquierda a derecha
  • - No espere hacerlo todo perfecto la primera vez que cree código
  • - Identifique su bucle principal de tareas y controle su salida
  • - No se olvide de las técnicas de resolución de errores
  • - Utilice grupos de contexto de forma amplia (DEV/QA/UAT/PROD) e inteligente
  • - No cree ingentes diseños únicos de tarea
  • - Cree módulos atómicos de tarea
  • - No fuerce la complejidad: simplifique
  • - Utilice esquemas genéricos siempre (la posible excepción sería el esquema de columna única)
  • - No se olvide de nombrar sus objetos
  • - Utilice joblets cuando convenga (tan solo unos cuantos)
  • - No se pase con el uso del componente tJavaFlex; probablemente con un tJava o un tJavaRow baste
  • - Genere/publique la documentación del proyecto cuando termine
  • - No se salte la configuración del montón de la memoria en tiempo de ejecución

Conclusión

¡Uau! ¿... le ha parecido poco? ¿Ha satisfecho su curiosidad? Espero que no del todo, porque estoy pensando en añadir artículos a esta serie: «¡Casos prácticos de muestra!» La publicación de hoy

ha ampliado los fundamentos y ha presentado algunos conceptos avanzados para que se los plantee cuando tenga la ocasión. Espero que les resulten de utilidad. No duden en comentar algunas de las mejores prácticas que aplican ustedes y ayudar a que este aparente soliloquio sea una conversación de verdad. Gracias y hasta la próxima...

Recursos relacionados

Introducción a Talend Open Studio for Data Integration

Productos mencionados

Talend Data Integration

 

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 *