Los Datos al Servicio de una Gran Cervecera

Cuando las empresas crecen a través de adquisiciones externas, la integración de los sistemas y datos de las empresas adquiridas es siempre un reto. Para AB InBev; empresa cervecera con más de 600 años de vida y marcas tan conocidas como Budweiser, Corona, Stella Artois, Beck’s, Hoegaarden y Leffe, ese desafío incluía un entorno híbrido con sistemas tanto locales como en la nube, como Salesforce, 15 instancias SAP, 27 sistemas ERP, 23 herramientas ETL y una gran cantidad de cerveceros que operaban como entidades independientes con sus propios sistemas internos. Como se puede imaginar, eso hizo extremadamente difícil obtener una visión única y unificada del negocio ya que no existía una única fuente de verdad. Además, la empresa opera en seis continentes y necesitaba cumplir con los requisitos de GDPR, lo que requería una visibilidad global de todos los activos de datos.

 

Debido a que los ejecutivos de la compañía no podían acceder fácilmente a la información de toda la empresa necesaria para tomar decisiones estratégicas se dieron cuenta de que necesitában un repositorio central para sus activos de datos. Sus clientes internos -como científicos de datos, equipos de operaciones y equipos de negocios- estaban luchando para reunir datos de más de 100 sistemas fuente, analizarlos y tomar decisiones oportunas sobre el desarrollo de productos, cadenas de suministro, campañas de marketing y más.

 

Además, al igual que otros productores de bebidas alcohólicas, AB InBev debe cumplir con estrictas regulaciones en cuanto a la recopilación de información para el consumidor. Por lo tanto, recopilaron datos externos, como datos geográficos y tendencias de compra, pero necesitaban estandarizar e integrar esos datos, que era otro aspecto de su desafío de datos.

 

 

Para conseguir todo ello, AB InBev contactó Talend y llevó a cabo una prueba de concepto (POC) de un mes de duración con Talend. La empresa cervecera quería embarcarse en un viaje en la nube y era consciente de que Talend está muy integrada en ese mundo, y permite que sistemas en la nube y en las instalaciones se comuniquen entre sí de forma segura.

 

Durante el POC, desarrollaron un producto adaptado a sus necesidades a un precio muy competitivo. Así, el grupo está utilizando principalmente Talend Data Integration para reunir las distintas fuentes de datos dentro y fuera de la empresa, y Talend Data Preparation para la detección de datos. Todo su trabajo de gestión de datos debe realizarse para varias empresas bajo el paraguas de AB InBev, por lo se ha creado un marco de trabajo reutilizable de manera que cuando extraen los datos de una cervecería, pueden utilizar el código que se ha creado y ahorrar mucho tiempo.

 

En esta arquitectura se extraen los datos de una serie de fuentes (en tiempo real y por lotes, en la nube y en las instalaciones, sistemas ERP, datos de dispositivos de IO) y se almacenan en una zona de aterrizaje, que forma parte de un lago de datos, o centro de datos, que reside en la nube en Microsoft Azure. Estos datos son procesados y archivados antes de pasar a una “Capa de Oro”, desde donde son consumidos por los usuarios internos de AB InBev. Por otro lado, se potencia un “sandbox” (es decir un entorno de pruebas separado del entrono de producción) para los científicos de datos, que la utilizan para probar varios modelos de datos. Además, la arquitectura de AB InBev incluye Hortonworks para Hadoop, y tecnologías relacionadas como Hive, Spark, Hbase y Kafka.

 

Entre los mayores beneficios de la nueva arquitectura de TI se encuentran la simplificación de la infraestructura y la reutilización de los procesos para extraer y proporcionar acceso a los datos rápidamente porque tienen un código reutilizable y lo que antes se hacía en seis meses ahora se hace en seis semanas. Esto se traduce en decisiones más rápidas y en una reducción del tiempo de comercialización de decisiones, campañas, productos y más.

 

Sin duda el ahorro de costes ha sido otro de los grandes beneficios. En lugar de pagar y administrar 23 herramientas ETL diferentes, han avanzado hacia la gestión de una sola herramienta mediante la estandarización de Talend.

 

Con esta nueva arquitectura de TI la compañía cervecera puede tener una variedad de casos de uso al servicio de su objetivo de vender las mejores cervezas y hacer feliz a la gente. Durante el primer año de lanzamiento de la plataforma de datos se han desplegado varios proyectos y hay cientos de nuevos proyectos de datos en preparación.

 

Todo comienza con un mejor desarrollo del producto. Los datos ayudan a AB InBev a entender cómo puede ayudar a los agricultores a cultivar las mejores cosechas que se utilizan para producir las mejores cervezas. Por ejemplo, el agua es un componente crítico. ¿Cuánta agua deben poner los agricultores en el suelo? Si hay un riesgo climático importante en una región, su responsabilidad social dejar de fabricar cerveza y en su lugar entregar agua a la gente.

 

Los datos también ayudan a la compañía a entender mejor los gustos y comportamientos de los bebedores. Por ejemplo, lo utiliza para analizar las nuevas demandas de los consumidores de cervezas bajas en calorías y determinar las preferencias por las cervezas de acuerdo con la estacionalidad. La cervecera recopila y agrega datos de consumo de Nielsen y encuestas de mercado, y datos casi en tiempo real de los medios de comunicación social, para analizar tendencias y ofrecer las cervezas adecuadas y campañas de marketing más específicas, como cupones en tiempo real en el punto de venta adaptados a los consumidores adecuados.

 

Sus clientes son tiendas y bares y los datos ayudan a mejorar su experiencia con sus marcas. Antes no era posible trabajar con cada tienda para obtener datos. Ahora, se pueden pedir cervezas a través de aplicaciones móviles, y pueden ver los datos en tiempo real para optimizar la previsión de la demanda y los suministros. El marketing basado en datos también significa que se puede analizar el comportamiento de los compradores en las tiendas y utilizar las métricas recopiladas para identificar la mejor ubicación en la tienda para vender cervezas, así como la forma de crear eventos en tiempo real para impulsar la conversión.

 

Los datos también son importantes para la optimización de la cadena de suministro. ¿Cómo pueden asegurarse de que las entregas lleguen a tiempo, con la calidad adecuada y al precio adecuado? ¿Cómo se pueden hacer más entregas? Para encontrar esas respuestas, AB InBev toma datos de IO de los dispositivos RFID para rastrear el ciclo de vida completo de los “paquetes conectados” desde la cervecería hasta la entrega, con el fin de encontrar las mejores rutas para los conductores de entregas. La compañía también utiliza la tecnología IoT para controlar la temperatura de millones de enfriadores de cerveza en todo el mundo para garantizar que su producto se almacena y sirve a la temperatura óptima. Y toman decisiones rápidas sobre cuántas paletas de cerveza enviar a un evento deportivo específico basándose en los datos históricos que ahora se almacenan en el centro de datos.

 

Según reconoce la empresa el descubrimiento de los datos ha sido realmente importante, anteriormente, los usuarios internos tenían que dedicar alrededor del 80 por ciento de su tiempo a localizar y consolidar los datos relevantes, lo que dejaba sólo el 20 por ciento para analizarlos y tomar una decisión. Ahora, utilizando Talend Data Preparation, sólo dedican alrededor del 30 por ciento de su tiempo a recopilar datos y pueden dedicar el 70 por ciento a analizarlos y a tomar decisiones mejor informadas.

 

Read More

6 Consejos de que Hacer y que No Hacer en la Gestión de Datos Colaborativa

Los proyectos de calidad de datos ya no son proyectos técnicos. Se están volviendo colaborativos e impulsados por el equipo.

A medida que las organizaciones se esfuerzan por lograr su transformación digital, los profesionales de datos se están dando cuenta de que necesitan trabajar en equipo con los departamentos comerciales, ya que son ellos los que necesitan mejores datos para lograr el éxito en sus operaciones. Al estar a la cabeza, los Chief Data Officers necesitan dominar algunos sencillos pero útiles “Do’s and Don’ts” (Que hacer y que no hacer) sobre la ejecución de sus proyectos de calidad de datos.

Voy a enumerar algunos de ellos.

QUE HACER

Establecer las expectativas desde el principio

¿Por qué se necesitan datos de calidad? ¿Cuál es el objetivo de la empresa? ¿Hasta qué punto impactará en el rendimiento empresarial de la organización? Las respuestas se deben encontrar entre los responsables del negocio. Hay que conocer la meta final para poder establecer metas e hitos intermedios en el calendario de un proyecto.

 

Construir un equipo interdisciplinar

Por supuesto, se trata de contar con el personal técnico adecuado en el proyecto: profesionales que dominan las plataformas de gestión de datos. Pero también se trata de encontrar a las personas adecuadas que en los “líderes locales” en sus respectivos departamentos. Por ejemplo, los expertos en marketing digital a menudo tienen problemas con datos erróneos y a veces tienen bajo rendimiento debido a la falta de una buena información de contacto. Además, nuevas regulaciones como GDPR hicieron que los profesionales del marketing tomaran conciencia de la importancia de los datos personales. Al poner herramientas como la Preparación de Datos en sus manos, usted les dará una manera de actuar sobre sus datos sin perder el control. Ellos serán sus aliados en su viaje de calidad de datos.

 

Entregar logros rápidamente

Si bien es fundamental ampliar las capacidades de las personas y establecer objetivos ambiciosos, también es necesario demostrar que el proyecto de calidad de datos tendrá un valor comercial positivo muy rápidamente. Por ello no hay que dedicar demasiado tiempo a la una planificación excesiva. Hay que probar el impacto en el negocio con resultados inmediatos. Algunos clientes de Talend lograron resultados de negocio muy rápidamente con aplicaciones como Data Prep o Data Stewardship.  Ser capaces de entregar resultados más rápidamente y más fáciles de comprender hace que la credibilidad sea instantánea y la gente apoye y confíe en el proyecto. Después de ganar credibilidad y confianza, es más fácil pedir recursos adicionales al Comité de Dirección. Es un importante recordar que muchos pequeños logros hacen uno grande.

 

QUE NO HACER

No subestimar el poder de una mala comunicación

A menudo pensamos que los proyectos técnicos necesitan respuestas técnicas. Pero la calidad de datos es un tema estratégico. Sería un error tratarlo como un desafío técnico. Para tener éxito, un proyecto debe ser ampliamente conocido dentro de una organización. Hay controlar la comunicación del proyecto para que no se extiendan malentendidos por el resto de departamentos. Para ello, debe dominar la combinación perfecta de conocimientos y habilidades de comunicación para que sus resultados sean conocidos y comunicados adecuadamente dentro de su organización. Marketing frecuentemente recibe datos erróneos que perjudican las operaciones comerciales por la falta de información y percepciones sesgadas. Por este motivo es habitual que se solicite a TI que amplíen sus proyectos y resuelvan los problemas de calidad de datos, lo que siempre es una buena razón para pedir más presupuesto.

 

No pasarse con la tecnología creando proyectos demasiado técnicos y complejos

Talend proporciona una plataforma simple y potente para producir resultados rápidos de modo que se pueda empezar por lo pequeño y después presentar lo grande. Un ejemplo de haber implementado la gestión de datos desde el principio es Carhartt, una importante empresa de ropa de trabajo de EEUU, que logró limpiar 50.000 registros en un día. No es necesario esperar mucho tiempo para ver resultados.

 

No olvidarse del reloj ni al equipo sin instrucciones claras

Es necesario establecer y cumplir los plazos con la mayor frecuencia posible para reforzar la credibilidad. Como el tiempo corre rápido y la organización puede sustituir a los directivos de negocio a corto plazo, hay que tener clara la ruta a seguir y mantenerse enfocado en las metas finales. Entregar los proyectos a tiempo conlleva poder celebrar el éxito. Al terminar un hito del proyecto y que asegúrese de tomar tiempo para celebrarlo con el equipo y, también, dentro de la organización.

Si te interesa este tema puedes pinchar aquí Definitive Guide to Data Quality.

 

Read More

Gestión básica de metadatos: Qué, cómo y por qué

La gestión de metadatos ha ido convirtiéndose en una de las prácticas más importantes de una estrategia satisfactoria de iniciativa digital. Con el auge de las arquitecturas distribuidas, como los big data y cloud, que pueden crear sistemas y datos compartimentalizados, hoy en día la gestión de metadatos es vital para gestionar los activos informativos de una organización. Internet contiene mucha bibliografía sobre este concepto y es fácil que los lectores se confundan con la terminología. En esta entrada he querido ofrecer a los usuarios un breve repaso sobre la gestión de metadatos en un lenguaje llano.

¿En qué consiste la gestión de metadatos?

Empecemos por lo más básico. Si bien circulan muchas definiciones de la gestión de metadatos, su principal funcionalidad consiste en facultar a los usuarios corporativos para que busquen e identifiquen la información en los atributos clave de una interfaz de usuario web.

Un ejemplo de atributo clave susceptible de búsqueda podría ser un ID de cliente o un nombre de socio. Con un buen sistema de gestión de metadatos, los usuarios corporativos podrán entender de dónde salen los datos de aquel atributo o cómo fueron calculados. Podrán visualizar en qué sistemas empresariales de la organización se está utilizando el atributo (linaje) y entenderán cómo afecta cualquier cambio (análisis de impacto) al atributo, como la longitud del atributo a otros sistemas.

Los usuarios técnicos también tienen necesidades de gestión de metadatos. Al combinar metadatos corporativos con metadatos técnicos, el usuario técnico también descubrirá qué tarea de ETL o proceso de bases de datos se utiliza para cargar los datos al atributo. Los metadatos operativos, como las tablas de control de la carga de un almacén de datos, también pueden combinarse con este modelo de metadatos integrados. Esta información puede ser de suma utilidad para el usuario final si la tiene a su alcance. El resultado final de la gestión de metadatos puede tener el formato de otra “base de datos” de los metadatos de atributos clave de la empresa. El término que el sector emplea para referirse a este tipo de bases de datos es un catálogo de datos, glosario o inventario de datos.

¿Cómo funciona la gestión de metadatos?

La gestión de metadatos tan solo es una de las iniciativas de un programa exhaustivo de gobernanza de datos, pero es la única que aborda la cuestión de los metadatos. Otras iniciativas, como la gestión de datos maestros (MDM) o la calidad de datos (CD) tratan sobre los “datos” reales almacenados en distintos sistemas. La gestión de metadatos integra almacenes de metadatos a escala empresarial.

Herramientas como Talend Metadata Manager ofrecen una forma automatizada de analizar y cargar distintos tipos de metadatos. La herramienta también permite crear un modelo empresarial basado en los metadatos generados de sistemas distintos, como su almacén de datos, herramientas de integración de datos, herramientas de modelado de datos, etc.

Los usuarios podrán resolver conflictos basados, por ejemplo, en nombres o tipos de atributos. También podrá crear tipologías de metadatos a medida para “coser” metadatos entre dos sistemas. Un modelo de gestión de metadatos completamente creado debe ofrecer una visión de 360º sobre la interconexión de distintos sistemas de su organización. Este modelo puede ser un punto de partida para cualquier nueva iniciativa de gobernanza de datos. A partir de ese momento los modeladores de datos sabrán dónde buscar un atributo concreto y usarlo en su propio modelo de datos. Este modelo también son los cimientos de la “base de datos” que comentamos en el apartado anterior. Como sucede con cualquier otra iniciativa de gobernanza de datos, a medida que los metadatos de los sistemas particulares cambian, el modelo necesita actualizarse conforme a una metodología SDLC, que incorpora versionado, flujos de trabajo y autorizaciones. El acceso al modelo de metadatos también debería gestionarse con la creación de funciones, privilegios y políticas.

¿Por qué necesitamos gestionar metadatos?

Pongámoslo fácil: por una cuestión de confianza. Si no se gestionan los metadatos durante todo el ciclo de vida del sistema, se crearán compartimentos de metadatos incongruentes en la organización que no satisfarán las necesidades de todos los equipos y que aportarán información contradictoria. Los usuarios desconocerían la necesidad de confiar en sus datos puesto que no habría metadatos que indicaran cómo ni cuándo llegaron los datos al sistema, ni qué reglas corporativas se aplicaron.

También es necesario contemplar los costes. Si no se gestionan con eficacia los metadatos, cada proyecto de desarrollo tendría que someterse a la definición de requisitos de datos, lo que aumentaría los costes y reduciría la eficiencia. A los usuarios les llegan muchas herramientas y tecnologías, lo que genera redundancia y unos costes excesivos, y tampoco proporciona todo el valor de la inversión, ya que los datos que buscan no están disponibles. Las definiciones de datos se duplican en múltiples sistemas y ello supone un coste de almacenamiento elevadísimo.

A medida que las empresas maduran y se les añaden cada vez más sistemas, necesitan plantearse cómo tienen que gobernarse los metadatos (no tan solo los datos). La gestión de metadatos reporta evidentes ventajas a la empresa, a los usuarios técnicos y la organización en general. Espero que esta introducción sobre los conceptos más básicos de la gestión de metadatos les haya resultado de utilidad. ¡Hasta la próxima!

Read More

Cómo pasar a serverless con Talend con CI/CD y los contenedores

¿Por qué deberíamos prestar atención a la CI/CD y a los contenedores?

La integración continua, entrega y el despliegue continuos, conocido como CI/CD, se ha convertido en una etapa tan fundamental de todo proyecto de software de éxito que son innegables las ventajas que puede reportar a su proyecto. Al mismo tiempo, los contenedores son ya prácticamente omnipresentes y gozan de gran aceptación entre los desarrolladores. A la hora de la verdad, la CI/CD permite a los usuarios ganar confianza en las aplicaciones que están creando por cuanto las verifica y valida continuamente. Por otro lado, la contenedorización le aporta la agilidad para distribuir y ejecutar su software construyendo tan solo una vez y pudiendo desplegar “en cualquier lugar” gracias al formato estándar que las empresas pueden adoptar. Estas prácticas habituales de DevOps permiten no caer en el efecto “¡en mi máquina funcionaba!”. Como consecuencia directa, mejoran el tiempo de llegada al mercado y permiten entregas más frecuentes.

¿Qué lugar tienen en el entorno Talend?

En Talend queremos brindarle la posibilidad de formar parte de esta revolución dándole acceso a lo mejor de ambos mundos. Desde el lanzamiento de Talend 7.0 ya puede crear sus tareas de Talend dentro de imágenes de Docker gracias a la compilación Maven de serie. Además, queremos ayudarle a conectar sin fisuras este proceso a su canalización de CI/CD.

¿Y la tecnología serverless?

La parte serverless la encontraremos al final. Se refiere a la forma en la que desplegaremos nuestras tareas de Talend. En realidad, al enviar nuestras tareas en contenedores tenemos libertad para desplegar las tareas de integración donde queramos. Entre estas posibilidades cada vez es más prominente una nueva categoría de servicios que definimos como serverless (sin servidor). La mayoría de los grandes proveedores de cloud empiezan a ofertar servicios serverless para contenedores como AWS Fargate o Azure Container Instances, por poner algunos ejemplos. Le permiten ejecutar contenedores sin tener que gestionar infraestructura (ni servidores ni clústeres). Tan solo se le factura por el uso que dé a sus contenedores.

Estas nuevas prestaciones fueron presentadas en Talend Connect US 2018 durante la ponencia inaugural y han sido ilustradas con una demostración en directo de toda una canalización, desde la compilación hasta la ejecución de la tarea, en AWS Fargate y en Azure ACI. En esta entrada del blog vamos a utilizar Jenkins para crear una canalización de CI/CD. Se trata de crear nuestras tareas dentro de imágenes de Docker, poniéndolas a disposición en un registro de Docker y, en última instancia, invocando AWS Fargate y Azure ACI para que las ejecuten.

Esquema sobre el salto a serverless con Talend a través de CI/CD y contenedores

Veamos cómo podemos reproducir ese proceso. Si desean seguir nuestros pasos, comprueben que cumplen los siguientes requisitos.

Requisitos

  • Talend Studio 7.0 o superior
  • Talend Cloud Spring 18’ o superior
  • Tener un servidor de Jenkins disponible
  • Su servidor de Jenkins debe tener acceso a un daemon de Docker instalado en la misma máquina
  • Talend CommandLine instalado en la máquina de Jenkins
  • Nexus, versión 2 o 3
  • Tenga instalado Talend CI Builder configurado junto con su Talend CommandLine.

* Todos los componentes de Talend mencionados están disponibles en la prueba de 30 días de Talend Cloud

Entorno Talend

Si no tiene experiencia con Talend, he aquí una presentación general de sus distintos componentes. Empiece con Talend Cloud, donde tendrá que crear un proyecto en la Talend Management Console (TMC o Consola de gestión de Talend) y luego deberá configurar su proyecto para utilizar un repositorio Git donde almacenar los artefactos de su tarea. También tendrá que configurar los ajustes de Nexus en la TMC para indicar a su servidor alojado de Nexus que guarde las bibliotecas externas que su tarea necesite. La cuenta de Talend Cloud facilita toda la gestión del proyecto y los artefactos en la TMC.

A continuación deberá instalar Studio y conectarlo a la cuenta de Talend Cloud. Studio es el principal entorno de diseño de Talend y es donde creará sus tareas de integración. Cuando inicie sesión con Studio a la cuenta cloud siguiendo estos pasos, verá los proyectos desde la TMC y utilizará el proyecto que está configurado en el repositorio Git. Siga los pasos que aparecen abajo para añadir los complementos necesarios a Studio.

Los dos últimos componentes que necesita son Ci Builder y Talend CommandLine o cmdline (si usa la prueba de cloud, la herramienta CommandLine está incluida en los archivos de instalación de Studio). Al instalar o utilizar la herramienta CommandLine por primera vez tendrá que asignarle una licencia también, para lo que puede utilizar la misma de Studio. Las herramientas CommandLine y CI Builder son los componentes que le permiten extraer el código de la tarea en Studio (en realidad, en Git) y crear y desplegar procesos totalmente ejecutables por medio de scripts. CI Builder, junto con el perfil de Studio, es lo que determina si se tratará de un entorno de ejecución de Talend Cloud o de un contenedor. ¡Estos son los pasos para empezar!

1) Cree un proyecto en Talend Cloud

En primer lugar, tendrá que crear un proyecto en su cuenta de Talend Cloud y vincularlo a un repositorio GitHub. Consulte la documentación para realizar esta operación.

No se olvide de configurar su Nexus en su cuenta de Talend Cloud. Siga la documentación de configuración de su Nexus con Talend cloud. Como recordatorio, su Nexus debe tener los siguientes repositorios:

  • releases
  • snapshots
  • talend-custom-libs-release
  • talend-custom-libs-snapshot
  • talend-updates
  • thirdparty

2) Añada los perfiles de Maven Docker a Studio

Este paso ya no es necesario en Talend Studio 7.1 y superiores. Sáltese esta parte si dispone de esta versión u otra superior, dado que los perfiles Maven Docker ahora los genera Talend Studio. Talend también presenta compatibilidad con OpenJDK 8 en su versión 7.1, lo que significa que puede utilizar imágenes de base OpenJDK de Docker en el entorno de producción.

Vamos a configurar Studio añadiendo los perfiles de Maven Docker a la configuración de los archivos POM de nuestro proyecto y nuestra tarea. Busque los dos archivos que necesitará aquí: project.xml y standalone-job.xml.

Puede hacerlo en su Studio, en el menú Project Properties -> Build -> Project / Standalone Job (Propiedades del proyecto > Crear > Proyecto/ Tarea independiente).

Tan solo tiene que cambiarlos por los que haya copiado más arriba. No es necesario ningún cambio más.

En realidad, lo que estamos haciendo es añadir un nuevo perfil llamado “docker” por medio del componente fabric8 de Maven. Al crear nuestras tareas con este perfil de Maven, se usará openjdk:8-jre-slim como imagen de base y después se le añadirán los archivos JAR de nuestras tareas junto con un pequeño script que indique cómo ejecutar la tarea. Cabe mencionar que Talend no es compatible con OpenJDK ni con Alpine Linux. A efectos de verificación exclusivamente, puede conservar la imagen openjdk:8-jre-slim, pero de cara a la producción tendrá que crear su propia imagen de base de Java Oracle. Para obtener más información, consulte nuestra documentación sobre plataformas compatibles.

3) Configure Jenkins

Una vez más, si usa Talend Studio 7.1 o superior, utilice este archivo de script para canalizaciones en lugar del que aparece más abajo. Ha sido adaptado con las modificaciones y mejoras que incluye la versión Talend 7.1. Combina la compilación de la imagen de Docker con la publicación en un registro de Docker en un único comando de Maven.

Este tercer paso consiste en configurar nuestro servidor de Jenkins. En esta entrada no abordaremos la configuración inicial de Jenkins. Si no lo ha utilizado jamás, consulte la Guía de inicio de Pipeline de Jenkins. Una vez finalizada la configuración inicial, utilizaremos los complementos de Maven, Git, Docker, Pipeline y Blue Ocean para realizar nuestra canalización de CI/CD.

Vamos a guardar nuestro archivos de ajustes de Maven en Jenkins. En los ajustes de Jenkins (Manage Jenkins), vaya a “Managed files” y cree un archivo con el ID “maven-file”. Copie este archivo en él como indica la captura de pantalla de abajo. Acuérdese de modificar la ruta de CommandLine conforme a sus propios ajustes y consigne sus propias credenciales de Nexus y la URL.

Antes de adentrarnos en los pormenores de la canalización, también tendrá que definir ciertas credenciales. Para ello vaya a “Manage Jenkins” (Gestionar Jenkins) y “Configure credentials” (Configurar credenciales), y luego a la izquierda, a “Credentials” (Credenciales). Fíjese en esta captura de pantalla:

Cree cuatro credenciales para GitHub, Docker Hub, AWS y Azure. Si tiene pensado utilizar AWS, no hace falta que indique sus credenciales para Azure, y al revés. Acuérdese de configurar su ACCESS KEY (Clave de acceso) como nombre de usuario y su SECRET ACCESS KEY (Clave de acceso secreta) como contraseña para las credenciales de AWS.

Por último, antes de pasar a la canalización, tenemos que poner dos imágenes de CLI Docker a disposición de la máquina de Jenkins. Jenkins utilizará imágenes de Docker con AWS y Azure CLI para ejecutar comandos de CLI en los distintos servicios. Es una forma sencilla de utilizar estas CLI sin tener que instalarlas en la máquina. Estas son las imágenes que vamos a utilizar:

  • vfarcic/aws-cli (docker pull vfarcic/aws-cli:latest; docker tag vfarcic/aws-cli:latest aws-cli)
  • microsoft/azure-cli:latest (docker pull microsoft/azure-cli:latest; docker tag microsoft/azure-cli:latest azure-cli)

Por supuesto, puede utilizar otras imágenes si así lo desea.

Estas imágenes de Docker tienen que extraerse en la máquina de Jenkins y así en esta canalización podremos utilizar el complemento de Jenkins Docker para usar la función “withDockerContainer(‘image’)” para ejecutar los comandos de CLI que verá más adelante. Tiene más información acerca de la ejecución de etapas de compilación en un contenedor de Docker en esta documentación de Jenkins.

Una vez satisfechos todos los requisitos previos, vamos a crear un “New item” (Elemento nuevo) en la página principal y elegiremos “Pipeline” (Canalización).

Una vez creado, ya puede configurar su canalización. Aquí es donde definirá su script de canalización (lenguaje Groovy).

Encontrará el script aquí.

Examinemos este archivo e iré destacando las etapas más importantes.

En la parte superior del archivo puede configurar sus propios ajustes a través de variables de entorno. Tiene un ejemplo que puede seguir con un proyecto llamado “TALEND_JOB_PIPELINE” y una tarea “test”. El nombre Git de proyecto debería coincidir con el de su repositorio GitHub. Por ese motivo aparece el nombre en mayúscula. Fíjese que en este script usamos el nombre de tarea como el nombre de imagen de Docker, de modo que no puede utilizar guiones bajos en el nombre de su tarea. Si quiere utilizar un guión bajo, tendrá que definir otro nombre sin guión para su imagen de Docker. Puede invalidar el nombre de imagen de Docker con la opción -Dtalend.docker.name=NAME en su comando de Maven. Deben configurarse las siguientes variables de entorno:

env.PROJECT_GIT_NAME = 'TALEND_JOB_PIPELINE'
env.PROJECT_NAME = env.PROJECT_GIT_NAME.toLowerCase()
env.JOB = 'test'
env.VERSION = '0.1'
env.GIT_URL = 'https://github.com/tgourdel/talend-pipeline-job.git'
env.TYPE = "" // if big data = _mr
env.DOCKERHUB_USER = "talendinc"

En este archivo, todos los pasos vienen definidos por una “stage” (etapa). Las dos primeras etapas sirven para extraer la versión más reciente de la tarea mediante un complemento de Git.

Luego viene la compilación de la tarea en sí. Como ve, estamos utilizando el complemento de Maven. Los ajustes están en el archivo Config de Jenkins. Este es el archivo que añadimos antes a la configuración de Jenkins con el ID maven-file.

En las etapas “Build, Test and Publish to Nexus” (Crear, probar y publicar en Nexus) y “Package Jobs as Container” (Empaquetar tareas como contenedor), la línea que debe modificarse es:

-Dproduct.path=/cmdline -DgenerationType=local -DaltDeploymentRepository=snapshots::default::http://nexus:8081/repository/snapshots/ -Xms1024m -Xmx3096m

Aquí tendrá que indicar su propia ruta al directorio de CommandLine (relativa al servidor de Jenkins) y la URL de su Nexus.

Una vez compilada la tarea en una imagen de Docker, vamos a enviar la imagen al registro de Docker Hub. Para este paso y el siguiente utilizaremos las CLI para emplear los distintos elementos de terceros. Como el daemon de Docker debería estar ejecutándose en la máquina de Jenkins, puede usar directamente la CLI de Docker. Utilizaremos la función withCredentials() para obtener su nombre de usuario y contraseña para Docker Hub:

stage ('Push to a Registry') {
            withCredentials([usernamePassword(credentialsId: 'dockerhub', passwordVariable: 'dockerhubPassword', usernameVariable: 'dockerhubUser')]) {
               sh 'docker tag $PROJECT_NAME/$JOB:$VERSION $DOCKERHUB_USER/$JOB:$VERSION'
               sh "docker login -u ${env.dockerhubUser} -p ${env.dockerhubPassword}"
               sh "docker push $DOCKERHUB_USER/$JOB:$VERSION"
           }
}

La etapa “Deployment environment” (Entorno de desarrollo) no es otra cosa que una interacción con el usuario mientras se ejecuta la canalización. Le pregunta si desea desplegar su contenedor en AWS Fargate o Azure ACI. Puede eliminar este paso si prefiere una compilación continua hasta el despliegue. Incluimos este paso como demostración.

Las próximas dos etapas son el despliegue en AWS Fargate o Azure ACI en sí. En cada una de las dos etapas tendrá que modificar sus propios ajustes. Por ejemplo, en la etapa de despliegue a AWS Fargate tendrá que modificar esta línea:

aws ecs run-task --cluster TalendDeployedPipeline --task-definition TalendContainerizedJob --network-configuration awsvpcConfiguration={subnets=[subnet-6b30d745],securityGroups=[],assignPublicIp=ENABLED} --launch-type FARGATE

Deberá modificar el nombre de su clúster de Fargate y la definición de su tarea. Sepa que tendrá que crearlos en su consola de AWS. Puede consultar la documentación para realizar esta operación. En el momento de redacción de este texto, AWS Fargate tan solo está disponible en la región del Norte de Virginia, pero se incluirán otras regiones en el futuro. El contenedor que tendrá definido en su definición de tarea es el que se creará en su cuenta de Docker Hub con el nombre de su tarea como nombre de imagen. Por ejemplo, con la configuración por defecto del script de canalización sería talendinc/test:0.1.

p>Lo mismo podemos decir de Azure ACI, en el que deberá indicar su propio grupo de recursos e instancia de contenedor.

4) Configure CommandLine

En realidad, Maven utilizará CommandLine para crear su tarea. CommandLine puede emplearse en dos modalidades: script y servidor. Aquí vamos a utilizar CommandLine como servidor. En primer lugar tendrá que indicar el área de trabajo de su CommandLine (que en nuestro caso será el área de trabajo de Jenkins). Modifique el archivo command-line.sh como sigue con su propia ruta al área de trabajo de Jenkins (dependerá del nombre de canalización que haya elegido en el paso anterior):

./Talend-Studio-linux-gtk-x86_64 -nosplash -application org.talend.commandline.CommandLine -consoleLog -data $WORKSPACE startServer -p 8002

Su instancia de Jenkins especificará la variable $WORKSPACE y será sustituida por el área de trabajo de Jenkins de su canalización. Gracias a esta variable de entorno que facilita Jenkins, podrá ejecutar distintas canalizaciones con distintas áreas de trabajo de Jenkins y CommandLine se adaptará a su propia área de trabajo según convenga.

Como verá en las Opciones de Maven del script de Groovy, el parámetro -Dgeneration.type=local está especificado. Esto significa que CommandLine se inicializará para realizar la compilación y luego se desactivará. Con esta opción evitaremos dejar CommandLine ejecutándose indefinidamente y usaremos la variable $WORKSPACE para cambiar el área de trabajo según la canalización que ejecutemos.

Por último debemos modificar el archivo /configuration/maven_user_settings.xml. Para ello copie y pegue este archivo con la URL y la información de acceso de su propio Nexus.

5) Ejecute la canalización

Una vez realizada toda la configuración necesaria, ya puede ejecutar su canalización. Para ello vaya a la vista Open Blue Ocean y haga clic en el botón “run” (Ejecutar). Activará la canalización y debería poder ver el progreso de la misma:

Captura de pantalla de Pipeline de Jenkins para crear tareas de Talend en contenedores de Docker

Pipeline de Jenkins crea tareas de Talend en contenedores de Docker

La canalización, a efectos de este ejercicio, le preguntará dónde quiere desplegar su contenedor. Elija AWS Fargate o Azure ACI. Tomemos el ejemplo de Fargate.

Una vez realizado el despliegue, su clúster de Fargate debería tener una tarea pendiente:

Si entra al detalle de su tarea una vez ejecutada, debería poder acceder a los registros de su tarea:

Ahora puede ejecutar su tarea de integración de Talend empaquetada en un contenedor de Docker en cualquier lugar, como por ejemplo:

  • AWS Fargate
  • Azure ACI
  • Google Container Engine
  • Kubernetes u OpenShift
  • Y muchos más…

Gracias a las capacidades de CI/CD de Talend puede automatizar todo el proceso, desde la compilación a la ejecución de sus tareas.

Si desea ser agnóstico en cuanto a su tecnología cloud y aprovechar la portabilidad de los contenedores, este ejemplo muestra cómo puede utilizar una herramienta de CI/CD (Jenkins, en nuestro caso) para automatizar la compilación y ejecutar en distintos servicios de contenedores cloud. Esto tan solo es un ejemplo entre muchos, pero poder crear sus tareas como contenedores le abre las puertas a todo un nuevo mundo para sus tareas de integración. Según cuál sea su caso práctico, podría pasar que invirtiera mucho menos dinero gracias a estos nuevos servicios serverless (como Fargate o Azure ACI). También podría dedicar menos tiempo a configurar su infraestructura y centrarse en diseñas sus tareas.

Read More

Cómo crear una tarea de tratamiento de datos con Apache Beam – Canalización en streaming

En nuestra última entrada del blog hablamos sobre cómo crear tareas de tratamiento de datos con Apache Beam. En esta ocasión vamos a hablar de una de las cosas más buscadas del mundo moderno de los big data hoy en día: el tratamiento de datos en streaming.

La principal diferencia entre los lotes y el streaming es el tipo de fuente de datos de entrada. Cuando su conjunto de datos es limitado (aunque en términos de tamaño sea enorme) y no se actualiza durante el tratamiento, lo más probable es que utilice una canalización por lotes. En este caso, la fuente de entrada pueden ser desde archivos, tablas de bases de datos, objetos de almacenes de objetos, etc. Me gustaría volver a subrayar que, cuando se trabaja por lotes, damos por hecho que los datos no son mutables durante todo el tiempo de procesamiento y que el número de registros de entrada es constante. ¿Por qué centrarnos en esto? Pues porque incluso con archivos podemos tener un flujo de datos ilimitado cuando se están añadiendo o cambiando archivos constantemente. Es este caso debemos aplicar un enfoque en streaming para operar con los datos. Así pues, si sabemos que nuestros datos son limitados e inmutables, necesitamos crear una canalización por lotes.

La cosa se complica cuando nuestro conjunto de datos es ilimitado (no paran de llegar) o mutable. Algunos de los ejemplos de este tipo de fuente podrían ser: sistemas de mensajería (como Apache Kafka), archivos nuevos de un directorio (registros de un servidor web) o cualquier otro sistema que recabe datos en tiempo real (como los sensores de IoT). El común denominador de todas estas fuentes es que siempre tenemos que esperar a que lleguen los datos nuevos. Claro que podemos dividir nuestros datos en lotes (por tiempo o tamaño de los datos) y tratar cada división por lote, pero costaría mucho aplicar algunas funciones en todos los conjuntos de datos consumidos y crear toda la canalización para ello. Por suerte, existen varios motores de streaming que nos permiten hacer frente a este tipo de tratamiento de datos fácilmente: Apache Spark, Apache Flink, Apache Apex, Google DataFlow. Todos son compatibles con Apache Beam y podemos ejecutar la misma canalización en distintos motores sin tener que modificar el código. Además podemos emplear la misma canalización por lotes o en streaming con unos cambios mínimos (basta con ajustar correctamente la fuente de entrada y listos), que todo funcionará tal y como nos llega. ¡Pura magia! Hace un tiempo me hubiera parecido un sueño, cuando me tocaba reescribir mis tareas por lotes a streaming.

Bueno, suficiente teoría: es momento de centrarnos en un ejemplo y escribir nuestro primer código en streaming. Vamos a leer algunos datos de Kafka (fuente ilimitada), realizar un simple procesamiento de los datos y mandar los resultados escritos de vuelta a Kafka también.

Pongamos que tengo un flujo ilimitado de coordenadas de GPS (X y Y) de algunos objetos en un mapa (para este ejemplo imaginemos que se trata de coches) que llega en tiempo real y queremos seleccionar tan solo los que están ubicados en una zona determinada. Dicho de otra manera, tenemos que consumir datos de texto de un tema de Kafka, analizarlos, filtrarlos según unos límites concretos y volver a escribirlos a otro tema de Kafka. Veamos cómo podemos hacerlo con ayuda de Apache Beam.

Todos los mensajes de Kafka contienen datos de texto en este formato:
id,x,y

en el que:
id: identificador único del objeto,
x, y: coordenadas en el mapa (enteros).

Tendremos que ocuparnos del formato si no es válido y saltar esos registros.

Crear una canalización

Al igual que en la entrada anterior del blog, en la que realizamos un procesamiento por lotes, creamos una canalización de la misma manera:

Pipeline pipeline = Pipeline.create(options);

Podemos ampliar el objeto Options para transferir opciones de línea de comandos a la canalización. Pueden consultar todo el ejemplo en Github si desean obtener más información.

Luego tenemos que leer datos del tema de entrada de Kafka. Como he comentado anteriormente, Apache Beam ya proporciona varios conectores de I/O y KafkaIO es uno de ellos. Por lo tanto, creamos una nueva PTransform ilimitada que consume los mensajes que llegan de un tema de Kafka específico y los propaga hasta el próximo paso:

pipeline.apply(
    KafkaIO.<Long, String>read()
        .withBootstrapServers(options.getBootstrap())
        .withTopic(options.getInputTopic())
        .withKeyDeserializer(LongDeserializer.class)
        .withValueDeserializer(StringDeserializer.class))

Por defecto, KafkaIO encapsula todos los mensajes consumidos en un objeto KafkaRecord. Aun así, la próxima transformación se limita a recuperar una carga útil (cadena de texto) a través del objeto DoFn de reciente creación:

.apply(
    ParDo.of(
        new DoFn<KafkaRecord<Long, String>, String>() {
            @ProcessElement
            public void processElement(ProcessContext processContext) {
                KafkaRecord<Long, String> record = processContext.element();
                processContext.output(record.getKV().getValue());
            }
        }
    )
)

Después de este paso, es hora de filtrar los registros (consulte la tarea inicial mencionada más arriba), pero antes tenemos que analizar nuestra cadena de texto según el formato definido. Esto permite encapsularlos en un objeto funcional que luego será utilizado por la transformación interna de Beam Filter.

.apply(
    "FilterValidCoords",
    Filter.by(new FilterObjectsByCoordinates(
        options.getCoordX(), options.getCoordY()))
)

A continuación tenemos que preparar mensajes filtrados para escribirlos y devolverlos a Kafka creando un nuevo par de clave/valor con la categoría interna de Beam KV, que puede emplearse en distintos conectores de I/O, entre los cuales se cuenta KafkaIO.

.apply(
    "ExtractPayload",
    ParDo.of(
        new DoFn<String, KV<String, String>>() {
           @ProcessElement
           public void processElement(ProcessContext c) throws Exception {
                c.output(KV.of("filtered", c.element()));
           }
        }
    )
)

La última transformación la necesitamos para escribir mensajes en Kafka, así que sencillamente utilizaremos KafkaIO.write() (implementación Sink) con esa finalidad. En cuanto a la lectura, tenemos que configurar esa transformación con algunas opciones necesarias, como los servidores Bootstrap de Kafka, el nombre de tema de salida o los serializadores para clave/valor.

.apply(
    "WriteToKafka",
    KafkaIO.<String, String>write()
        .withBootstrapServers(options.getBootstrap())
        .withTopic(options.getOutputTopic())
        .withKeySerializer(org.apache.kafka.common.serialization.StringSerializer.class)
        .withValueSerializer(org.apache.kafka.common.serialization.StringSerializer.class)
);

Por último, ejecutamos nuestra canalización como siempre:

pipeline.run();

En esta ocasión puede parecer un tanto más complicado que en el artículo anterior, pero como se puede observar fácilmente no hemos tenido que hacer nada muy específico para que nuestra canalización sea compatible con el streaming. Toda la responsabilidad recae en la implementación del modelo de datos de Apache Beam, que facilita considerablemente la alternancia entre el procesamiento por lotes y en streaming para los usuarios de Beam.

Crear y ejecutar una canalización

Añadamos las dependencias necesarias para que sea posible usar Beam KafkaIO:

<dependency>
  <groupId>org.apache.beam</groupId>
  <artifactId>beam-sdks-java-io-kafka</artifactId>
  <version>2.4.0</version>
</dependency>

<dependency>
  <groupId>org.apache.kafka</groupId>
  <artifactId>kafka-clients</artifactId>
  <version>1.1.0</version>
</dependency>

Después basta con crear un .JAR y ejecutarlo con DirectRunner para comprobar cómo funciona:

# mvn clean package
# mvn exec:java -Dexec.mainClass=org.apache.beam.tutorial.analytic.FilterObjects -Pdirect-runner -Dexec.args=”–runner=DirectRunner”

Si hace falta, podemos añadir otros argumentos utilizados en la canalización con ayuda de la opción «exec.args». Además, asegúrese de que sus servidores de Kafka estén disponibles y correctamente especificados antes de ejecutar la canalización de Beam. Por último, el comando Maven inicializará una canalización y la ejecutará eternamente hasta que se la detenga manualmente (opcionalmente, se puede indicar un tiempo de ejecución máximo). Esto significa que los datos se tratarán de forma continua, en streaming.

Como siempre, todo el código de este ejemplo está publicado en este repositorio de GitHub.

¡Feliz streaming!

Read More

Cómo contenedorizar sus tareas de Talend con un solo clic

Este texto forma parte de una serie sobre arquitectura y contenedores serverless. La primera entrega de la serie analizaba el impacto de los contenedores sobre el DevOps.

Talend Data Integration es una plataforma de integración de datos para empresas que ofrece un diseño visual, generando un Java sencillo. Este enfoque de diseño modular ligero es la opción perfecta para los contenedores. En esta entrada le enseñaremos cómo contenedorizar su tarea de Talend con un solo clic. Todos los ejemplos de código de este texto los encontrará en nuestro repositorio de Git Talend Job2Docker. Este archivo léame de Git también incluye instrucciones pormenorizadas.

Cómo crear Job2Docker

Job2Docker tienes dos partes. La primera es un script de Bash muy sencillo que empaqueta su archivo ZIP de la tarea de Talend como una imagen de Docker. Durante esta etapa de empaquetado, el script modifica el comando de lanzamiento de su tarea de Talend para que se ejecute como PID 1. La tarea en sí no se modifica de ninguna otra manera. Con ese cambio, su tarea de Talend será el único proceso del contenedor. Este enfoque encaja con la filosofía y las mejores prácticas de Docker. Cuando cree una instancia de contenedor, su tarea de Talend se ejecutará automáticamente. Una vez terminada la tarea, el contenedor se desactivará. La lógica de su aplicación queda perfectamente disociada de la infraestructura computacional de alojamiento. Puede hacer uso de herramientas de orquestación de contenedores como Kubernetes, OpenShift, Docker Swarm, EC2 Container Services o Azure Container Instances para gestionar eficientemente sus contenedores de tareas. Tanto si trabaja en cloud como localmente, puede aprovechar la mejora en la elasticidad para rebajar los costes totales de la propiedad.

Cómo se ejecuta Job2Docker

La segunda parte de Job2Docker es una sencilla Tarea de suministro escrita en el mismo Talend. Hace el seguimiento de un directorio compartido. En el momento en que cree una Tarea desde Studio para este directorio, el oyente de Job2Docker invocará el script de empaquetado de tareas para crear la imagen en Docker.

Lo único que necesita para ejecutar los ejemplos son una instancia de Talend Studio 7.0.1 (que puede descargarse gratis aquí) y un servidor con Docker.

  • Si ejecuta Studio en Linux, puede simplemente instalar Docker y seleccionar un directorio para compartir sus tareas de Talend con Docker.
  • Si ejecuta Studio en Windows, puede probar Docker para Windows o instalar Linux en una máquina virtual.

Los ejemplos que incluimos han sido ejecutados en una MV de Linux mientras Talend Studio se ejecutó en Windows en el sistema operativo anfitrión. Para que Studio y Docker se comuniquen tendrá que compartir una carpeta con la herramienta de la MV que usted elija.

Una vez instalados estos scripts y el oyente de Job2Docker, el flujo de trabajo resultará transparente para el usuario de Studio.

1. Inicie la tarea Job2Docker_listener que controla el directorio compartido.

2. Haga clic en “Build” en Talend Studio para crear un archivo ZIP de la tarea de Talend en el directorio compartido. Y ya está.

3. El Job2Docker_listener de Talend activa el script Job2Docker para que convierta el archivo ZIP de Talend a un archivo .tgz apto para Docker.

4. El Job2Docker_listener de Talend activa el script Job2Docker_build, que genera una imagen para Docker.

5. Cree un contenedor con el comando Run (Ejecutar) de Docker. Su tarea se ejecutará automáticamente.

El repositorio Job2Docker incluye algunos ejemplos básicos tipo “Hola, mundo” y le indica cómo enviar parámetros fácilmente a su Tarea. El proceso detallado se explica en un breve vídeo disponible en YouTube.

Una vez tenga su imagen de Docker, ya puede publicarla en el registro de Docker que desee y coordinar su aplicación contenedorizada como parte de su flujo de trabajo de integración continua.

Se trata de un proceso engañosamente sencillo, pero tiene implicaciones de calado en la forma de gestionar sus flujos de trabajo a escala. En nuestra próxima entrada le enseñaremos cómo orquestar varias tareas contenedorizadas con herramientas de orquestación de contenedores como Kubernetes, EC2 Container Services, Fargate o Azure Container Instances.



Read More

Por qué a los científicos de datos les encanta Python (y cómo utilizarlo con Talend)

En los últimos años Python se ha convertido en el lenguaje de programación de referencia para los científicos de datos. En cierto modo, sorprende un poco. Python no se creó originalmente para realizar tareas analíticas o ciencia de datos, sino que ha evolucionado hasta convertirse en la navaja suiza de la caja de herramientas de los científicos de datos. El motivo radica en un conjunto amplio de paquetes de terceros que los científicos de datos tienen a su alcance. Por ejemplo, ‘Pandas’ permite la manipulación de datos heterogéneos y etiquetados, ‘SciPy’ sirve para las tareas de computación científica más habituales, ‘Matplotlib’ para visualizaciones, ‘NumPy’ para la manipulación de datos vectorizados, y un largo etcétera.

Por qué los científicos de datos <3 Python

Hoy en día Python se utiliza para casi todo, desde el manejo de datos a la visualización, pasando por el desarrollo web. Se ha convertido en uno de los lenguajes de programación de código abierto en uso más importantes y que gozan de mayor popularidad actualmente. Mucha gente lo considera un nuevo lenguaje, cuando en realidad es anterior a Java y a R. Python fue creado por Guido van Rossum del Instituto de investigación holandés CWI en 1989. Uno de sus puntos más fuertes es su sencilla habilidad de ampliarse, así como su compatibilidad con múltiples plataformas. La capacidad que ofrece Python de comunicarse con distintos formatos de archivo y bibliotecas le aporta una gran utilidad y es el principal motivo por el que hoy en día lo utilizan los científicos de datos.

Para los programadores, Python no es un lenguaje difícil de aprender. En realidad, la mayoría de programadores experimentados lo consideran fácil de aprender. Hay muchos incluso que recomiendan Python como el primer lenguaje que debería aprender todo el mundo, que son palabras mayores. La sintaxis del lenguaje en sí es muy sencilla de incorporar. Escriba un programa «Hola, mundo» en cualquier lenguaje. En Java y C se necesitan como mínimo tres líneas de código, mientras que en Python tan solo una. No todo es pan comido: aprender a usar bibliotecas, por ejemplo, exige su tiempo, pero se trata de un lenguaje sencillo para empezar y programar, cuando menos más que los demás.

Talend y Python

Este año Talend ha presentado un nueva app nativa para cloud llamada Talend Data Streams. Con Data Streams todo se convierte en un «stream», como un flujo. Incluso el procesamiento por lotes es un flujo con límite temporal. Esto significa que tenemos una arquitectura tanto para el procesamiento por lotes como de flujos en tiempo real. Data Streams presenta una previsualización inmediata para que los desarrolladores sepan que su diseño es correcto en cada etapa del proceso. Cuando arrastren el último conector final al lienzo, podrán ver al instante que su diseño está completo. Ahora la calidad de datos cuenta con matemática compleja para resolver el problema de la eliminación de datos duplicados, correspondencias y normalización de los datos. Data Streams está pensado para permitir a cualquier usuario añadir snippets de Python fácilmente mediante un editor de código integrado que proporciona autocompletado de código y resaltado de sintaxis intuitivo. Nuestro objetivo es dar alas al usuario con la potencia de Python.

Hay momentos en los que resulta más fácil programar y olvidarse, y los desarrolladores solemos tirarnos de cabeza, según sea el usuario y la tarea en cuestión. Ahí es cuando entra en escena Python. Talend Data Streams ofrece compatibilidad nativa para Python integrada. En Talend invertimos en Python. Consideramos que ofrece una gran funcionalidad, junto con facilidad de programación. Le invitamos a que pruebe Talend Data Streams y observe cómo puede ampliar fácilmente sus canalizaciones de datos con componentes de programación integrados de Python.

Read More

Construcción de Lagos de Datos para el Cumplimiento del RGPD

Jean-Michel Franco, Director Senior de Marketing de Producto en Talend y Pinakin Patel, Director Senior de Ingeniería de Soluciones EMEA en MapR.

Si hay un fenómeno clave al que los líderes empresariales de todas las industrias se han aferrado en los últimos años, es el valor de los datos. El mercado de inteligencia empresarial y análisis continúa creciendo, a un ritmo masivo a medida que las organizaciones inviertan en las soluciones que esperan les permitan aprovechar el potencial de esos datos y alcanzar un alto nivel de competitividad en su sector.

Pero mientras las empresas continúan acumulando datos e invirtiendo en herramientas de análisis que esperan que los ayuden a determinar y generar valor adicional, el Reglamento General de Protección de Datos (RGPD) está forzando las mejores prácticas en la captura, administración y uso de datos personales.

El RGPD de la Unión Europea estipula reglas estrictas sobre cómo se deben manejar los datos. Al afectar todo el ciclo de vida de los datos, las organizaciones deben tener una comprensión integral de sus datos personales, desde su recopilación y procesamiento hasta su almacenamiento y, finalmente, su destrucción.

A medida que las empresas luchan por cumplir con la fecha límite del 25 de mayo, la gobernanza de datos es un enfoque clave. Pero las organizaciones no pueden pensar en las nuevas regulaciones como una tarea más a tachar de la lista. Se requiere un cumplimiento continuo y la mayoría de las organizaciones tienen que crear nuevas políticas que les ayuden a lograr un modo de privacidad por defecto.

Diversos activos de datos

Uno de los grandes desafíos que plantea la gestión segura de los datos es la adopción rápida en el análisis de datos en todas las empresas, ya que pasa de ser una función del departamento de TI a convertirse en un activo central para las unidades de negocio. Como resultado, los datos a menudo fluyen en muchas direcciones por toda la empresa, por lo que resulta difícil comprender los datos sobre los datos, como el linaje de datos (dónde se creó y cómo llegó allí).

Las organizaciones pueden tener datos personales en muchos formatos y tipos diferentes (tanto estructurados como no estructurados) en diferentes ubicaciones. Bajo el RGPD, será crucial conocer y administrar dónde están los datos personales en sus negocios. Si bien nadie está seguro exactamente de qué forma se aplicará el RGPD, las organizaciones necesitarán poder demostrar que sus procesos de gestión de datos cumplen continuamente con el RGPD en cualquier momento.

Con las diversas fuentes y bancos de datos que tienen muchas organizaciones, la consolidación de estos datos será clave para gestionar eficazmente su cumplimiento con el RGPD. Teniendo en cuenta los numerosos tipos diferentes de datos que se deben custodiar en una organización, los lagos de datos son una solución clara al desafío de almacenar y administrar datos dispares.

Reúna sus datos

Un lago de datos es un método de almacenamiento que contiene datos brutos, incluidos datos estructurados, semiestructurados y no estructurados. La estructura y los requisitos de los datos solo se definen una vez que se necesitan los datos. Cada vez más, vemos que los lagos de datos se utilizan para centralizar la información empresarial, incluidos los datos personales que provienen de una variedad de fuentes, como ventas, atención al cliente, redes sociales, sistemas digitales y más.

Los lagos de datos, que usan herramientas como Hadoop para rastrear datos dentro del entorno, ayudan a las organizaciones a reunir todos los datos en un lago de datos donde todos pueden mantenerse y gobernarse de manera colectiva. La capacidad de almacenar datos estructurados, semiestructurados y no estructurados es crucial para el valor de este enfoque para consolidar los activos de datos, en comparación con los almacenes de datos que principalmente mantienen datos estructurados y procesados. Permitir que las organizaciones descubran, integren, limpien y protejan los datos que luego pueden compartirse de manera segura es esencial para un gobierno de datos efectivo.

Además de la vista en toda la extensión del lago de datos, las organizaciones pueden mirar ’rio arriba’ para identificar las fuentes de datos antes de que fluyeran al lago. De esta forma, las organizaciones pueden rastrear datos específicos a su origen, como atención al cliente o aplicaciones de marketing, brindando visibilidad de extremo a extremo en toda su cadena de suministro de datos para que pueda ser examinada e identificada según sea necesario.

Esta visión ’end-to-end’ de los datos personales es crucial bajo el RGPD, permitiendo a las empresas identificar la calidad y el punto de origen de toda su información. Además de permitir a las organizaciones almacenar, administrar e identificar la fuente de todos sus datos, los lagos de datos proporcionan un medio rentable para que las organizaciones almacenen todos sus datos en un solo lugar. Por otro lado, la gestión de estos grandes volúmenes de datos en un almacén de datos tiene un Coste Total de Propiedad mucho más elevado.

Estableciendo las bases

Mientras que los lagos de datos actualmente presentan el mejor enfoque para la gestión de datos y la gobernanza para el cumplimiento de RGPD, esta no será la última parada en el camino de las organizaciones hacia la gestión de datos innovadores, eficientes y de quejas. Los enfoques de almacenamiento de datos del futuro se construirán teniendo en cuenta el nuevo clima reglamentario, y se crearán para servir y cumplir los desafíos que presentan.

Sin embargo, con la demanda en las organizaciones para crear políticas y prácticas de datos que respalden el cumplimiento de sus esfuerzos futuros de almacenamiento y análisis de datos, está claro que las empresas deben comenzar a refinar los procesos y las políticas que establecerán las bases para una innovación de datos compatible en el futuro. Poder identificar y acceder de manera fácil y rápida a todos los datos, con una clara comprensión de su origen y administración, es ahora el estándar mínimo para la administración de datos personales. El tiempo se está agotando. Muchas organizaciones están agotando el tiempo para el cumplimiento de la RGPD. Sin embargo, las empresas deben tener una visión a largo plazo y construir un modelo de almacenamiento de datos que les permita consolidar, armonizar e identificar la fuente de sus datos de conformidad con el RGPD.

Este reglamento está aportando nuevas dimensiones con respecto a la demanda de los clientes: ahora se valorará la confianza y la transparencia. Seguirán a las empresas que podrán ofrecer interacciones personalizadas, al tiempo que permitirán a sus clientes tomar el control total de sus datos personales. En última instancia, las empresas que establezcan un sistema de confianza en el núcleo de su relación

 

Next Steps: Free GDPR Assessment Tool

On demand Webinar : Using a GDPR Data Hub to Protect Personal Data

Download the solution brief : Get Ahead Of General Data Protection Regulation (GDPR) With MapR And Talend

 

Read More

El Auge de los Integradores Ad Hoc o Ciudadanos

En los últimos años, ha habido un cambio en la industria de datos, lo que ha llevado a la aparición de una nueva categoría de ciudadanos de datos: los integradores ‘ad hoc’ o ‘ciudadanos’.

Con estas nuevas personas que se suman a la (ya larga) lista de trabajadores de datos que tienen acceso a la información corporativa, las empresas necesitan volver a pensar en la forma en que tienen que abordan sus estrategias de seguridad y gobernanza de los datos. A diferencia de los ingenieros de datos, esta nueva clase de “ciudadanos” o personas, no necesariamente utilizan la integración de datos como parte de su trabajo diario, pero si la usan de vez en cuando.

Entonces, ¿quiénes son exactamente estos integradores? Según Gartner, los integradores ad hoc pueden incluir desarrolladores de una línea de negocio, como desarrolladores de aplicaciones, que pueden necesitar integrar datos para una parte de su desarrollo, pero la integración de datos puede no ser necesariamente una tarea diaria constante. Los integradores ciudadanos incluyen científicos de datos, analistas de datos y otros expertos en datos dentro de la empresa que pueden necesitar integrar datos para su trabajo principal: análisis.

La innovación brinda la oportunidad de comprender

Con un número creciente de fuentes de datos, hay un aumento correspondiente en la cantidad de casos de uso que permiten que cada parte del negocio se base en datos. La adopción a gran escala de tecnologías de procesamiento de datos en tiempo real como Kafka ha aumentado la velocidad a la que los datos son absorbidos por las empresas, lo que hace factible el IoT y el análisis de datos de clickstream.

Al mismo tiempo, las tecnologías de Big Data de código abierto como Apache Spark han proporcionado un marco para procesar y analizar volúmenes crecientes de datos. Incluso los proveedores de servicios en la nube como Amazon Web Services y Microsoft Azure han contribuido a fomentar las prácticas basadas en datos de toda la empresa permitiendo a las empresas de todos los tamaños almacenar, procesar y explorar más datos sin la inversión monetaria y de recursos que antes requerían las tecnologías locales.

Todas estas innovaciones han creado un entorno que nutre y alienta a casi todos los segmentos del negocio, desde la cadena de suministro hasta el marketing, a utilizar sus datos para informar de las elecciones que van desde las tareas diarias hasta las principales iniciativas estratégicas. Además, derivar conocimientos precisos y actuar sobre esos conocimientos se ha convertido en una ventaja competitiva en todos los mercados. En otras palabras, tener análisis incorrectos o incluso información demorada puede colocarlo en una posición vulnerable: una posición en la que sus competidores pueden superar su participación de mercado al actuar según las necesidades de la industria y los clientes que aún no haya identificado.

Para seguir siendo competitivos, las empresas han contratado ejércitos de científicos de datos y analistas de datos que tienen la tarea de identificar tendencias y articular conocimientos accionables para cada segmento del negocio.

Está naciendo el nuevo integrador

A menudo, el departamento TI no puede administrar tanto el número creciente de fuentes de datos como el número exponencial de solicitudes de integradores ad hoc y ciudadanos para preparar conjuntos de datos para análisis. Desafortunadamente, generalmente se convierte en un cuello de botella donde los integradores ad hoc y ciudadanos pueden esperar días o incluso semanas para acceder a los datos que necesitan para el análisis, lo cual no es aceptable en un mundo donde el tiempo de visión más rápido separa a los líderes de una industria de sus rezagados.

Como resultado, los desarrolladores de línea de negocio, los científicos de datos y los analistas de datos se quedan para integrar y preparar sus datos si quieren trabajar con sus datos instantáneamente en lugar de esperar unos días o semanas para comenzar su análisis.

El futuro de la integración: habilitar nuevos integradores sin perder supervisión

Ahora que entendemos que los integradores ad hoc y ciudadanos están asumiendo un papel cada vez más importante en el mundo de la integración de datos, ¿qué será lo siguiente?

Dado que los integradores ad hoc y ciudadanos a menudo han sido descuidados o ignorados por los departamentos TI debido a la falta de recursos, muchos han recurrido a encontrar sus propias herramientas para la recopilación, limpieza y preparación de sus datos para el análisis. Y, a menudo, utilizan herramientas que están fuera del ámbito de TI y, por lo tanto, fuera de la supervisión y el gobierno de TI. Si bien esto brinda a los integradores ad hoc y ciudadanos la capacidad de preparar sus datos rápidamente, también abre el riesgo que entraña la información no supervisada y sin control.

En un momento en que la seguridad de los datos y el gobierno de los datos son a menudo tema de las noticias de la página principal, es primordial que cada compañía restrinja quién está accediendo a qué datos, qué hace cada persona con esos datos y cómo están almacenando los datos. Para alcanzar este nivel de gobernanza, las empresas deben centrar su atención en algunas cosas: personas, procesos y productos.

En primer lugar, las personas que trabajan con datos dentro de su organización deben entender que la administración de datos se ha convertido en un deporte de equipo, y al igual que en cualquier equipo, cada persona necesita comprender su rol. Tan importante como entender su propio rol, necesita comprender cómo puede interactuar y contribuir con su equipo para obtener los datos más precisos (y subsecuentemente, una visión analítica) posible. Debido a que la administración de datos a menudo abarca diferentes equipos, es importante que los diferentes equipos acuerden un proceso para algunas de estas interacciones. Por último, es importante encontrar un producto que lo ayude a habilitar a todos los miembros del equipo de datos y operacionalice los procesos establecidos entre los miembros del equipo de datos mientras se rigen por TI. Con la integración de datos cambiantes y los entornos de análisis, las personas que interactúan con los datos, los procesos que utilizan para interactuar entre sí, y los productos que pueden apoyarlos están cambiando. ¿Está su organización preparada para habilitar y capacitar a sus nuevos integradores?

Read More

La automatización sin esfuerzo: crear tareas de Jenkins con Jenkins DSL

Últimamente he visto muchos artículos y conversaciones sobre DevOps. DevOps se refiere a un conjunto de prácticas que automatizan los procesos entre los equipos de desarrollo de software e informática con el fin de recortar los ciclos de desarrollo, aumentar la frecuencia de despliegue y publicar versiones más fiables siempre según las necesidades de la empresa.

Cada vez más las empresas adoptan prácticas de DevOps por medio de metodologías ágiles y herramientas de automatización, como Jenkins, Bamboo, TeamCity etc. Aquellas que han empezado a utilizar Jenkins para configurar una integración, entrega y despliegue continuos suelen crear sus tareas con la IU de Jenkins. Al principio les encanta, porque es un sistema maravilloso para gestionar compilaciones, pero a medida que distintos grupos de la empresa empiezan a adoptar este método, se topan con ciertos problemas, como por ejemplo:

  • El mantenimiento se resiente por la magnitud de todas las tareas en Jenkins
  • Se dan incongruencias entre las tareas por todo el copia y pega y divergencias no deseadas
  • Reusabilidad y complejidad
  • No hay copias de seguridad de las tareas
  • No hay métodos de recuperación en caso de catástrofes

El complemento Jenkins Job DSL intenta resolver estos problemas permitiendo definir las tareas con el mínimo esfuerzo necesario en formato programático. Analizaremos un script de muestra para lograr un despliegue continuo en el Talend Administration Center con ayuda del complemento Jenkins DSL.

Creación de una tarea de entrega continua en Jenkins

El “Job DSL / Plugin” de Jenkins contiene dos partes: El Lenguaje de dominio específico (DSL, en inglés) en sí permite a los usuarios describir tareas con un lenguaje en Groovy y un complemento (plugin) Jenkins, que gestiona las actualizaciones y, en última instancia, las tareas de Jenkins que crea y mantiene.

Fase 1:

Dando por hecho que ha instalado el complemento DSL del apartado “Manage Plugins” (Administrar complementos), el script para una tarea de entrega continua para crear tareas automáticamente y desplegarlas en el Talend Administration Center (TAC) tendrá un aspecto parecido a este:

Según la automatización necesaria, se puede cambiar a cualquier requisito de Ciclo de vida de desarrollo del software (SDLC, en inglés) que cada empresa configure. En el script de arriba, además de ajustar la configuración para GIT, TAC y sus credenciales respectivas, puede enviar el script en Groovy a través de un complemento de archivos gestionados que necesita para:

  • Analizar el archivo de solicitud JSON (task_list.json)
  • Invocar la API MetaServlet para crear tareas en TAC con ayuda del mensaje codificado BASE64
  • Desplegar las tareas en el JobServer y crear los activadores opcionales

Fase 2:

A continuación, cree su tarea de Jenkins usando el estilo de proyecto libre para ejecutar sus scripts del DSL. Esto suele formularse como tarea SEED, que utiliza el script creado anteriormente.

Fase 3:

Ejecute la Tarea SEED de arriba para crear la Tarea de Jenkins que necesita para la entrega continua, como aparece indicado abajo.

Al final de este proceso obtendrá la tarea necesaria para crear tareas de Talend automáticamente en TAC y desplegarlas en JobServers.

Conclusión:

El complemento de DSL de Jenkins ofrece capacidad de mantenimiento para contextos empresariales. Puede reforzar aún más el diseño guardando los scripts SEED en GIT o cualquier herramienta de SCM y ejecutarlos para tener constancia en historial de cualquier cambio realizado a la tarea. De esta forma, si pierde su tarea en Jenkins, podrá recrearla de forma idéntica desde GIT. Por último, el complemento DSL le permite crear plantillas de scripts siguiendo patrones de diseños regulares para asegurar una uniformidad en la forma de crear o desplegar tareas los diferentes equipos. Como siempre, se agradecen comentarios y opiniones. Ya me dirán qué les ha parecido. ¡Hasta la próxima!

Read More