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

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

 

Parece ser que los artículos que he publicado anteriormente sobre este tema han tenido muy buena acogida. Me permitirán que exprese mi continua satisfacción. Muchas gracias, (ávidos, entregados) lectores.

Si ha llegado hasta aquí sin haber leído mis entradas anteriores, mejor que empiece leyendo las primeras («Patrones de diseño de tareas» y mejores prácticas de Talend 1.ª y 2.ª parte) y luego regrese para seguir leyendo, puesto que siguen un orden. La popularidad de esta serie ha exigido que el texto se traduzca, por lo que si lo desea puede leer las versiones recientes en francés (haga clic en la bandera francesa). Muchas gracias a Gaël Peglissco, jefe de proyectos de Makina Corpus, por su persistencia, paciencia y profesionalidad con la ayuda que nos ha brindado en la realización y publicación de estas traducciones.

Antes de ahondar todavía más en los patrones de diseño de tareas y las mejores prácticas, sepa que todos los contenidos anteriores se han compactado en una presentación técnica de 90 minutos. Es una presentación que imparto en los «Bootcamps técnicos de Talend» que se multiplican en mi agenda por todo el mundo. Eche un vistazo a la página web de Talend para saber si se organiza alguno en su zona dentro de poco. ¡Me encantaría que coincidiéramos!

Sigue nuestro viaje, pero recuerde que en cualquier momento puede comentar, preguntar u opinar sobre mis consejos, ya que en realidad aunque no se note mi objetivo real es abrir la conversación a toda la comunidad Talend. «Orientaciones», no «normas», ¿se acuerda? Es lógico por mi parte creer que tendrán cosas que aportar y opiniones formadas, ¿verdad? Eso espero...

Avanzando sobre una misma cuestión

A estas alturas debería ser evidente que considero necesario crear unas «Orientaciones para desarrolladores» si queremos garantizar un buen ciclo de vida a nuestro software, como sucede con los proyectos de Talend, pero hablemos sin rodeos: Fijar unas orientaciones para desarrolladores, consensuarlas entre los miembros del equipo e ir inculcando disciplina gradualmente son la clave para asegurar unos resultados excepcionales con Talend. ¡Je, je! Espero que lo vean como yo. La creación de tareas en Talend puede entrañar más de un giro inesperado (y no me estoy refiriendo a sus líneas curvas), así que si entendemos los cimientos de cada «uso profesional», cada«tecnología» y «metodología», tendremos más números de hacerlo bien desde el principio. Yo creo que merece la pena dedicar tiempo a elaborar unas orientaciones para su equipo. Le aseguro que lo agradecerá.

Muchas casuísticas complicadas para los clientes de Talend suelen implicar algún tipo de proceso de integración de datos, que es la competencia esencial de Talend: trasladar datos de un lugar a otro. Los flujos de datos adoptan formas muy distintas, por lo que no es irrelevante saber qué hacemos con ellos y cómo los manipulamos. Es tan importante que en realidad es la esencia de prácticamente todas nuestras tareas. Así que, si el uso previsto es el traslado de datos corporativos y Talend es una pieza clave del mix tecnológico, ¿cuál es la metodología? Sin duda, se trata de la mejor práctica del SDLC que ya hemos analizado. No obstante, la cosa va más allá. Las metodologías, en contexto con los datos, engloban un modelado de datos. Es un tema que a mí me apasiona. Hace más de 25 años que me dedico a la arquitectura de datos y he diseñado y construido más soluciones de bases de datos de las que soy capaz de contar, por lo que para mí que los sistemas de bases de datos tengan su propio ciclo de vida tiene una relevancia práctica. Da igual si hablamos de archivos planos, EDI, OLTP, OLAP, STAR, Snowflake esquemas de bóveda de datos, porque si ignoramos el proceso de principio a fin de los datos y sus esquemas correspondientes estaremos forjando, en el mejor de los casos, nuestro talón de Aquiles y, en el peor, ¡una catástrofe!

Las metodologías de modelado de datos no son el tema de este artículo, pero es muy importante adoptar el diseño estructural y el uso más adecuados para nuestros datos. Eche un vistazo a mi serie sobre bóvedas de datos y esté atento a próximos artículos sobre modelado de datos. De momento tengan fe en lo que les digo, pero el DDLC, o «Ciclo de Vida de Desarrollo de los Datos» ¡es una de las prácticas más idóneas! Piénselo bien: puede que descubra que llevo algo de razón.

Otras mejores prácticas para el diseño de tareas

Muy bien, ha llegado el momento de presentarle más «mejores prácticas» en materia de diseño de tareas con Talend. De momento llevamos analizadas dieciséis. A continuación hablaré de otras ocho (y estoy convencido que habrá una cuarta entrega de esta serie, ya que me veo incapaz de resumirlo todo sin renunciar a una cierta claridad de exposición). ¡Espero que les gusten!

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

Rutinas de código

Hay veces que los componentes de Talend no satisfacen una necesidad programática concreta. No pasa nada, Talend es un generador de código Java, ¿verdad? Pues claro, e incluso existen componentes de Java que puede insertar en su lienzo para incorporar puro Java en el proceso o en el flujo de datos. Pero, ¿qué sucede si ni siquiera con eso basta? Les presento a mis pequeñas amigas: ¡Las rutinas de código! Auténticos métodos de Java que puede añadir a su repositorio de proyecto. En esencia, se trata de funciones de Java definidas por el usuario que usted codifica y utiliza en distintos puntos de su tarea.

Talend proporciona muchas funciones de Java que seguramente ya habrá utilizado, como por ejemplo:

- getCurrentDate()

- sequence(String seqName, int startValue, int step)

- ISNULL(object variable)

Teniendo en cuenta la imagen de conjunto de su tarea, proyecto o caso práctico, las rutinas de código dan muchas opciones. Aquí mi mantra es código reutilizable y, siempre que sea capaz de idear una rutina de código útil que ayuda a racionalizar una tarea de forma genérica, es que va por el buen camino. Asegúrese de incorporar los comentarios adecuados cuando aparecen al seleccionar la función como texto «de ayuda».

Esquemas de repositorio

El apartado de metadatos del repositorio de proyecto representa una oportunidad fortuita para crear objetos reutilizables. Se trata de una importante orientación para el desarrollo. ¿Se acuerda? Los esquemas de repositorio suponen una potente técnica de creación de objetos reutilizables para sus tareas. Entre ellos:

- Esquemas de archivo: se utilizan para la correspondencia de una diversidad de formatos de archivo plano, como por ejemplo:

  • Delimitados
  • Posicionales
  • Regex
  • XML
  • Excel
  • JSON

- Esquemas genéricos: se utilizan para establecer la correspondencia de una diversidad de estructuras de registro:

- Esquemas de WDSL: se utilizan para establecer la correspondencia de estructuras de métodos de servicios web:

- Esquemas de LDAP: se utilizan para establecer la correspondencia de una estructura de LDAP (LDIF también disponible)

- UN/EDIFACT: se utilizan para establecer la correspondencia de una amplia variedad de estructuras para transacciones EDI

Cuando usted crea un esquema, le asigna un nombre de objeto, una finalidad y una descripción, además de un nombre de objeto de metadatos al que se hace referencia en el código de la tarea. Por defecto a esto se le llama «metadatos». Dedique tiempo a definir una convención de nomenclatura para estos objetos o al final todo parecerá que tenga el mismo nombre en su código. Tal vez «md_{nombredeobjeto}» sea una opción razonable. Veamos un ejemplo.

Los esquemas genéricos revierten una importancia particular, puesto que ahí es donde creamos estructuras de datos centradas en necesidades concretas. Tomemos de ejemplo una conexión a una BD (como hemos visto en el mismo ejemplo) que ha diseñado esquemas de tabla por ingeniería inversa a partir de una conexión a una bases de datos física. La tabla de «cuentas» tiene 12 columnas, aunque el esquema genérico coincidente definido abajo tiene 16 columnas. Las columnas suplementarias representan elementos de valor añadido a la tabla de «cuentas» y se utilizan en un proceso de flujo de datos para tareas con el fin de incorporar más datos. Al revés, puede suceder que una tabla de una base de datos tenga más de 100 columnas y luego para un flujo de datos de tarea particular tan solo hagan falta 10. Puede definirse un esquema genérico para las diez columnas para una consulta respecto de la tabla con las diez columnas coincidentes, que es una capacidad sumamente útil. Mi consejo: utilice esquemas genéricos y MUCHO. Salvo quizás en las estructuras de una sola columna, en cuyo caso creo que es mejor usarlos integrados.

Fíjese que otros tipos de conexión, como SAP, Salesforce, NoSQL o clústeres de Hadoop, tienen todos la capacidad de contener definiciones de esquema también.

Log4J

El Apache Log4J lleva disponible desde Talend versión 6.0.1 y ofrece un sólido framework para registro en Java. Actualmente todos los componentes de Talend son totalmente compatibles con servicios de Log4J, lo que refuerza la metodología de resolución de errores que comentamos en mis entradas anteriores. Estoy seguro de que a estas alturas habrán incorporado ya todos esas mejores prácticas en sus proyectos o, al menos, eso espero. ¡Ahora reforcémoslas con Log4J!

Para usar Log4J tiene que estar habilitado. Lo puede hacer en el apartado de propiedades del proyecto. Allí también podrá adaptar sus orientaciones de registro para el equipo a fin de ofrecer un paradigma de mensajes uniforme para los canales de salida (appenders) de Console (stderr/stdout) y LogStash. Tener esta ubicación única para definir estos canales de salida supone una sencilla vía para incorporar funcionalidad Log4J a las tareas de Talend. Observe que los valores de nivel incorporados a la sintaxis de Log4J coinciden con las ya conocidas prioridades de INFO/WARN/ERROR/FATAL.

En la Talend Administrator Console (TAC o Consola de Administrador Talend), cuando crea una actividad para ejecutar una tarea, puede habilitar el nivel de prioridad que Log4J registrará también. Asegúrese que lo configura correctamente para entornos DEV/TEST y PROD. La mejor práctica consiste en configurar DEV/TEST a nivel INFO, UAT a WARN y PROD a ERROR. Cualquier nivel superior quedará incluido igualmente.

Trabajando con los componentes tWarn y tDie y el nuevo Log Server, Log4J puede reforzar realmente el seguimiento y el control de las ejecuciones de tareas. Utilice esta funcionalidad para crear una orientación de desarrollo para su equipo.

Consola de seguimiento de actividades (AMC, en inglés)

Talend proporciona una herramienta complementaria integrada para reforzar el seguimiento de la ejecución de tareas que consolida la actividad compilada de información de procesamiento detallada en una base de datos. Incluye una interfaz gráfica a la que se accede desde Studio y desde la TAC. Este instrumento ayuda a desarrolladores y administradores a comprender las interacciones entre componentes y tareas, a prevenir fallos inesperados y respaldar importantes decisiones de administración del sistema. Pero tendrá que instalar la base de datos y la aplicación web de AMC, puesto que se trata de una prestación opcional. La Guía de uso de la Consola de seguimiento de actividades de Talend ofrece información completa sobre la instalación del componente AMC, por lo que no le aburriré aquí con estos detalles. Centrémonos en las mejores prácticas para su uso.

La base de datos de AMC contiene tres tablas, que son:

- tLogCatcher: capta los datos enviados desde las excepciones de Java o los componentes tWarn/tDie

- tStatCatcher: capta los datos enviados desde la casilla tStatCatcher Statistics de componentes individuales

- tFlowMeterCatcher: capta los datos enviados desde el componente tFlowMeter

Estas tablas almacenan los datos de la IU de AMC, que ofrece una sólida visualización de la actividad de una tarea a partir de estos datos. Asegúrese de escoger los ajustes correctos de prioridad de registro en la pestaña de preferencias del proyecto y piense largo y tendido en las posibles restricciones de datos impuestas sobre las ejecuciones de tareas para cada entorno: DEV/TEST/PROD. Utilice la vista Main Chart (Gráfico principal) para ayudar a identificar y analizar escollos en el diseño de la tarea antes de publicar una versión en entornos PROD. Repase la vista Error Report (Informe de errores) para analizar la proporción de errores producidos durante un lapso concreto.

Si bien es de gran utilidad, no es este el único uso que podemos dar a estas tablas. Como son tablas de base de datos, pueden escribirse consultas de SQL para extraer información valiosa externamente. Se puede configurar con herramientas de scripting para diseñar consultas y notificaciones automatizadas cuando se produzcan determinadas condiciones y se registren en la base de datos de AMC. Mediante una técnica consolidada de código de retorno que describo en mi primer artículo sobre patrones de diseño de tareas, estas consultas pueden realizar operaciones automatizadas de forma programática que pueden resultar muy útiles.

Puntos de recuperación

¿Así que tiene una tarea de larga ejecución? Puede que englobe diversos pasos críticos y, si alguno de ellos falla, empezar de cero podría ser muy problemático. Sería fantástico minimizar el esfuerzo y el tiempo necesarios para reiniciar la tarea en un punto determinado del flujo justo antes de que sucediera el error. Pues bien, la TAC ofrece una función de restauración de ejecución especializada cuando una tarea experimenta errores. Las tareas diseñadas con estos «puntos de recuperación» situados concienzudamente y de manera estratégica pueden retomar su ejecución sin volver a empezar y seguir procesando.

Cuando se produce un fallo, utilice la pestaña de la TAC «Error Recovery Management» (Gestión de recuperación de errores) para determinar el error y desde allí podrá dar la orden de proseguir el procesamiento de la tarea. Fenomenal, ¿a que sí?

Joblets

Ya hemos visto en qué consisten los joblets: código de tarea reutilizable que puede «incluirse» en una tarea o en muchas, según convenga, pero ¿qué son en realidad? En realidad, los joblets no tienen tantos usos previstos, pero cuando demos con un caso en el que sí se necesiten, utilícelos, porque son una perla. Hay varias formas de construir y de utilizar los joblets. Echemos un vistazo, ¿le parece?

Al crear un nuevo joblet, los componentes de entrada/salida se añaden automáticamente a su lienzo. Este arranque rápido le permite asignar los esquemas que entran y salen del flujo de trabajo de la tarea con el joblet. Este uso típico de los joblets permite el traslado de datos con el joblet y luego ya cada uno les da el uso que quiere. En el siguiente ejemplo, se pasa una fila entrando y se actualiza la tabla de una base de datos, se registra en stdout y luego se pasa la misma fila sin cambios (en este caso) saliendo.

Un uso menos habitual puede ser eliminar la entrada, la salida o ambos componentes para un tratamiento especial del flujo de datos/proceso. En el siguiente ejemplo, no hay ningún paso de entrada ni de salida de este joblet. En su lugar, un componente tLogCatcher busca distintas excepciones escogidas para su procesamiento posterior (ya lo había visto en las mejores prácticas sobre resolución de errores).

Es evidente que el uso de joblets puede reforzar considerablemente la reusabilidad del código, puesto que es su finalidad. Introduzca estas perlas en un Proyecto de referencia para expandir su uso a distintos proyectos. Ahora ya conoce un elemento sumamente útil.

Casos de prueba de componentes

Si todavía utiliza una versión de Talend anterior a la 6.0.1, ya puede saltarse este apartado. Je, je... o, mejor aún, ¡actualícelo! Una de mis funcionalidades nuevas preferidas es la capacidad de crear casos de prueba dentro de una tarea. No se trata exactamente de «pruebas unitarias», pero sí son pruebas de componentes, tareas reales vinculadas a la tarea padre y, concretamente, al componente que está verificándose. No todos los componentes permiten estos casos de prueba, pero siempre que un componente acepte una entrada de flujo de datos y lo expulse, se podrá generar un caso de prueba.

Para crear un caso de prueba de un componente, basta con hacer clic con el botón derecho en el componente seleccionado y encontrar la opción de menú abajo «Create test case» (Crear caso de prueba). Una vez seleccionada esta opción, se genera una nueva tarea y se abre con una plantilla funcional para el caso de prueba. El componente de la prueba aparece ahí junto con los componentes INPUT y OUTPUT integrados envueltos en un flujo de datos que sencillamente lee un «Input File» (Archivo de entrada), procesa los datos a partir de él y pasa los registros al componente de la prueba, que luego cumple su función y escribe el resultado en un nuevo «Result File» (Archivo de resultados). Una vez completado el archivo se compara con un resultado previsto o «Reference File» (Archivo de referencia). O coincide o no coincide: ¡pasa o no pasa! - Muy sencillo, ¿a que sí? Echemos otro vistazo por si acaso.

Aquí tenemos una tarea que hemos visto antes. Tiene un componente tJavaFlex que manipula el flujo de datos y lo pasa aguas abajo para su posterior procesamiento.

Se ha generado una tarea del caso de prueba que tiene este aspecto: No se necesita ninguna modificación (aunque sí he limpiado el lienzo un poco).

Es importante saber que, si bien puede modificar el código de tarea del caso de prueba, los cambios del componente de la prueba tan solo deberían producirse en la tarea padre. Pongamos que el esquema exige un cambio. Cámbielo en la tarea padre (o en el repositorio) y el caso de prueba heredará el cambio. Están indisolublemente ligadas y, por lo tanto, acopladas por medio de su esquema.

Observe que, una vez creada una «instancia» del caso de prueba, pueden generarse múltiples archivos de «entrada» y de «referencia» para ejecutarlos a través de la misma tarea del caso de prueba. Esto permite comprobar datos de prueba buenos, malos, grandes, pequeños y especializados. Aquí la recomendación pasa por evaluar con detenimiento no tan solo qué verificar sino también qué datos de prueba utilizar.

Por último, cuando se utilice el repositorio de artefactos Nexus y las tareas del caso de prueba se guarden ahí junto con su tarea padre, se pueden utilizar herramientas como Jenkins para automatizar la ejecución de estas pruebas y, de esta forma, la determinación de si una tarea está lista para ascender al próximo entorno.

«Iteraciones» del flujo de datos

Seguro que si ha desarrollado código en Talend habrá visto que vincula componentes entre sí con un proceso de «trigger» o activador, o con un conector de flujo de datos «row» o por filas. Este vínculo se establece haciendo clic con el botón derecho sobre el componente inicial y conectando el enlace «line» al próximo componente. Los enlaces de flujo del proceso son o bien «OnSubJobOk/ERROR», «OnComponentOK/ERROR» o «RunIF», que ya analizamos en mi artículo anterior. Los enlaces de flujo de los datos, cuando están conectados se nombran de forma dinámica «row{x}», donde esta «x» que es un número, la asigna dinámicamente Talend para generar un nombre de objeto/fila único. Estos enlaces de flujo de los datos pueden tener nombres personalizados, claro (que es una mejor práctica en materia de convenciones de nomenclatura), pero crear este enlace establece una correspondencia entre el esquema de los datos de un componente y el otro y representa la «canalización» por la que pasan los datos. En el tiempo de ejecución, los datos que hayan pasado por dicho enlace suelen llamarse un conjunto de datos. En función de los componentes posteriores, el conjunto de datos al completo se procesa íntegramente en la subtarea encapsulada.

No todo el procesamiento del conjunto de datos puede efectuarse a la vez y a veces debe controlarse el flujo de datos directamente. Esto se logra mediante el control de un procesamiento «fila por fila» o mediante «iteraciones». Revise este disparate de código:

Fíjese en los componentes tIterateToFlow y tFlowToIterate. Son componentes especializados que le permiten centrar el control en el procesamiento del flujo de datos permitiendo que se iteren los conjuntos de datos fila por fila. Este procesamiento «por listas» puede ser bastante útil cuando se necesita. No obstante, cuidado porque en muchos casos una vez descompuesto el flujo de datos en iteraciones fila por fila puede que tenga que volver a compilarlo en un conjunto de datos completo antes de proseguir con el procesamiento (como muestras el tMap). Esto es debido al requisito de que algunos componentes fuerzan un flujo de conjunto de datos «por filas» y no pueden manejar un flujo de conjunto de datos «iterativo». Observe también que los componentes t{DB}Input ofrecen una opción de flujo de datos «main» (principal) e «iterate» (iterativo) en el menú de filas.

Echemos un vistazo a los contextos de muestra: Transformar un flujo de datos en lista y Transformar una lista de archivos como flujo de datos, que encontrará en el Centro de Asistencia de Talend y en la Guía de referencia de componentes. Incluyen explicaciones útiles sobre cómo utilizar esta función. Utilice esta función como necesite y facilite etiquetas legibles para describir su finalidad.

Conclusión

¡Ahora toca digerirlo todo! Ya casi hemos terminado. La cuarta parte de esta serie del blog nos traerá la última entrega sobre patrones de diseño de tareas y mejores prácticas que asientan los cimientos para la creación correcta de código de Talend. Pero he prometido que hablaría sobre «Muestras de casos prácticos» y pienso cumplirlo. Considero que dominar todas estas prácticas recomendadas será toda una baza cuando empecemos a hablar sobre sus aplicaciones abstractas. Como siempre, envíenme comentarios, preguntas y opiniones de todo tipo. ¡Bonsai!

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 *