 Thank you so much for the presentation. I will change to Spanish, but if I want to send a question in English after the talk, we can talk. Bueno, muchas gracias y bienvenidos hasta charla donde vamos a intentar comentar un poco nuestra experiencia desarrollando un sistema en streaming. Me presento muy verdaderamente, soy Rubén Casados, soy ingeniero y doctora en informática y desde 2016 soy responsable del equipo Big Data en Accenture Digital. Bien, antes de entrar en la parte técnica quiero que es lo que más nos interesa a todos sobre lo que hemos desarrollado, dejarme daros un mínimo contexto sobre el proyecto donde lo hemos desarrollado. Este proyecto lo hemos desarrollado para un cliente en el sector de las telecomunicaciones y específicamente dentro del sector, dentro del área del departamento de UVR. UVR es la tecnología que permite mejorar y semiautomatizar los call center. Cuando nosotros llamamos por teléfono atención al cliente para contratar un nuevo producto para información sobre nuestra facturación, pues ese sistema con el que interaccionamos vale que nos dice si quiere información sobre la factura pulse 1, si quiere información sobre el producto pulse 2, esa información que vamos interactuando nos va enrutando dependiendo de las respuestas y dependiendo de nuestra información, pues hacia otro sistema o finalmente hacia una persona que nos pueda atender. Para que un sistema de UVR funcione bien, funciona de forma adecuada tenemos que tener en cuenta dos aspectos fundamentales. Uno es la información, es necesario que el sistema de UVR pueda acceder a la información de la persona lo más rápido y lo más eficiente posible, porque para tener una visión completa de lo que el usuario puede necesitar y anticiparnos o personalizar la respuesta, de nada me vale ofrecer un producto que ya tiene contratado. Y otra segunda parte muy importante son los tiempos de respuesta. Daros cuenta que nosotros estamos al teléfono en ese momento, la experiencia de usuarios es muy importante, no podemos permitir que el sistema tarde mucho en procesarlo. Entonces necesita que los tiempos de respuesta de UVR sean menores de un segundo. Bien, cuando llegamos a este cliente ya tenía un sistema de UVR funcionando por supuesto, entonces esos dos problemas más o menos los tenía resuelto. ¿Qué es lo que pasaba? Que para conseguir que UVR contestase esa información de una manera más o menos eficiente, lo que se hacía es generar toda la información del cliente que como os podéis imaginar viene de múltiples fuentes que es muy diversa, pues en procesos batch que se tiraban horas, es decir actualizaban esa información de forma diaria, por lo cual guardaba esa información al final pues llegamos en una base de datos que UVR podía consultarla de forma rápida. El tiempo de respuesta era adecuado, pero ¿cuál es la problemática aquí? Que la información que tiene UVR está desactualizada como mínimo con un día, por lo cual si tú has comprado un producto en las últimas seis horas o has consumido tus datos en la última hora esa información no la va a tener en cuenta. Bueno, cuando llegamos allí ¿cuál fue la solución que les propusimos? Bien, esto está claro. Lo que vosotros necesitáis es tener la visión 360 del cliente más o menos como la tenéis pero actualizada en tiempo real, no con 24 horas, es decir el mundo sucede de la vida, sucede en tiempo real, no sucede en batch de 24 horas, por lo cual olvidemos ese mito de los batch diarios. Simplemente hagamos las cosas de una forma más natural, según se van generando los eventos pasemos y actualicemos esa visión 360 del cliente y eso es lo que hemos decidido hacer. ¿Qué significa la visión 360 actualizada en tiempo real? Pues obviamente significa tener un profile del cliente con su información personal, customer ID, nombre, apellidos, sus datos personales pero además una información que es lo que se llaman las business tag o etiquetas de negocio. ¿Qué significa en esas etiquetas de negocio? Son clasificaciones o scoring que el negocio define, por ejemplo ser un usuario digital, un cliente digital. Un cliente digital es aquel que ha accedido al área privada de la web pues en los últimos 180 días o un parámetro configurable o un cliente es un consumidor activo de internet si ha gastado más del 20% de sus datos en el último día. Son dos ejemplos de esas etiquetas. Esas etiquetas anteriormente se generaban en batch, lo que hacíamos es pues ese cliente tenía esa etiqueta o no la tenía. Esto también era un problema porque esas definiciones de etiquetas funcionales, aunque están más o menos concretas, esos parámetros sí que podían variar y negocio se quejaba de que tenían muy poca mano. Cuando querían cambiar que en vez de consumir el 20% tuviera que hacer el 30% se lo tenía que pasar al equipo de negocio, el equipo de negocio lo metían en su código y en el mejor de los casos el día siguiente con el nuevo batch lo tenía. Eso en un hipotético caso. Aquí habrá muchos desarrolladores, pero sabéis que hacer un cambio en el código que esté en producción el día siguiente no es tan rápido, ¿verdad? Bueno, pues nosotros lo que propusimos es no solo vamos a tener la visión 360 actualizada del cliente, sino que esos cambios de configuración también los vas a poder hacer en tiempo real. Por lo cual en la visión 360 del cliente vamos a guardar no solo la información del cliente, sino la información base para que cuando se consulte ese último cocinado de la información se haga también en tiempo real. El cliente nos compró esta solución, pero esto es algo grande, era tirar todo lo que tenían hasta ahora de la gestión del OUBR y crear algo desde cero. Cuando hablamos de una plataforma como ésta todos pensamos en lo que nosotros llamamos arquitectura de ejecución, ¿no? Oye, ¿qué piezas necesito para coger el tacto en tiempo real? Procesarlo, guardarlo en una caché de acceso, ¿no? Empezamos a hablar que es el Kafka, que es el Pulsar, el Parkstream y el Flink, bien eso es la arquitectura de ejecución que es muy importante, es lo más importante, pero tenemos dos arquitecturas paralelas, es decir, esto va a estar en producción 24x7 dando servicio en tiempo real, eso lo tenemos que tener super controlado, administrado, operado, con una monitorizado, con unas alertas que nos digan si eso funciona o no funciona, eso es lo que llamamos la arquitectura de operación, también la hemos tenido que desarrollar. Y de nuevo vamos a montar un sistema nuevo para las funcionalidades, va a haber un equipo que va a tener que desarrollar sobre él, va a necesitar unos entornos de desarrollo, unos lenguajes, ver cómo se compila, cómo se prueba, cómo se despliega sobre esa nueva arquitectura, ¿vale? Eso es lo que llamamos la arquitectura de desarrollo, que tenemos que o crearla o por lo menos adaptarla existente a la nueva plataforma. Bien, pues lo que os vamos a contar ahora un poquito son estas tres arquitecturas, los detalles de estas tres arquitecturas, vale, vamos a empezar por la ejecución que sin duda es la más interesante, digamos que esto es todo el resumen del proyecto, si lo hicieramos así en una slide, este es el resumen del proyecto, esto es lo que a todos nos encanta como técnicos, ver ahí todas las piezas puestas con flechitas de ver cómo encaja, pues es real y funciona, bien, si empezamos por la izquierda y tenemos los orígenes de los orígenes de datos, tenemos diferentes orígenes, desde microservicios que realmente nos generan los eventos en tiempo real, ficheros de otros departamentos que nos lo generan no en tiempo real, sino cada x horas y mucha información que aunque se generan en tiempo real, realmente los aplicativos no están preparados para generar eventos y lo que nos queda es irnos a las bases de datos operacionales y coger esos cambios en tiempo real mediante herramientas de chain data capture, en este caso que hemos utilizado como herramienta de chain data capture stream, todos los eventos como vemos por aquí nos lo llevaríamos a Kafka, ¿vale? Kafka es nuestro buffer de eventos, lo utilizamos como cola que nos va a permitir asegurar la consistencia de los datos, la replicación en el momento, el reprocesado, digamos que es nuestra base de datos temporal donde voy a asegurar pues el exactly one semantic y toda la consistencia de un procesamiento de streaming, hecho ese eventos lo va a coger fling, fling, motor de procesamiento de eventos en tiempo real, distribuido, gestión de estados, tecnología más avanzada que nos va a permitir cumplir requisitos funcionales que tenemos y esos eventos actualizados, creando ese profile, esa visión 360 del cliente, la vamos a mantener actualizada en redis, una caché de acceso muy rápido. El acceso a esos datos no se hace directamente a redis sino que se apifica mediante un microservicios que es lo que me permite esto lo que os decía antes, ese último cocinado de la información es lo de si el parámetro es un 20% o un 40% lo va a aplicar el microservicio dinámicamente, ¿cómo conseguimos eso? con reglas drills, el microservicio lo que tiene incrustado son unas reglas drills, si vemos por aquí este otro flujo lo que hemos puesto es que el usuario de negocio mediante un excel puede subir las reglas drills a un aplicativo que valida que están correctamente, esto también se mueve por Kafka y el microservicio es notificado que hay una nueva versión de esas reglas y en tiempo real las empiezan a aplicar. Esto es un poco toda la arquitectura que tenemos montada, veis por abajo que tenemos lo que llamamos un réplica data, simplemente toda la información que cogemos en los orígenes de forma temporal lo guardamos en una base de datos por simplemente por mejorar la tolerancia de fallos, es decir si alguna de las marcas funcionales se nos cae y necesitamos reprocesar en vez de volver a los orígenes que tiene un impacto en los operacionales lo cogemos desde aquí, es un mecanismo de seguridad. Todo esto lo tenemos desplegado en Amazon Web Service, la parte de origen obviamente son premis pero la parte del procesamiento está en premis. Hemos utilizado pues tanto servicios gestionados como como infraestructura, por ejemplo productos como stream lo tenemos instalados sobre EC2 mientras que otros productos como fling sí que lo hemos ejecutado dentro de algunos servicios gestionados que tiene Amazon como MR. Kafka tuvimos la duda, Kafka lo podemos usar mediante EC2 o con uno de los servicios gestionados de Amazon. Cuando nosotros empezamos este proyecto, el servicio auto gestionado de Kafka para Amazon estaba en versión beta, no cumplía ciertos requisitos de seguridad y por eso lo descartamos. Lo mismo con fling, podríamos utilizar kinesis analytics, fling con Kubernetes, nos decantamos con MR porque es la solución más madura y que a nosotros nos daba más confianza. Y por último redis que no es que la tengamos instalada nosotros como en EC2 sino que usamos el servicio elasticache de Amazon. De esta manera pues no tenemos un vendor locking como estáis viendo nos podríamos ir a otro sitio pero sí que utilizamos en medida los servicios auto gestionados de Amazon. Es un acuerdo entre uso del servicio gestionado y evitar el vendor locking. Si hacemos un zoom en la parte del procesamiento lo que sería Kafka y fling, que es lo que vemos, encontramos esto. Todos los orígenes de datos, ficheros, tablas de una base de datos, lo convertimos o lo mapeamos a un topic Kafka. Un topic Kafka que el ponemos el nombre de Rao, el prefijo de Rao para saber que esa información, ese dato es en bruto. Después por cada una de esas marcas funcionales lo que hacemos es desarrollar un job fling, un job fling que le da de los topics Kafka que necesite. Ese job fling aplica la lógica y guarda la información resultante. Esa información que deberíamos actualizar en el customer profile en reddit lo guarda en otro topic Kafka que lleva el prefijo de proc, de información ya procesada. Y por último tenemos un job genérico uno único que es fling que lee de todos los topics de tipo procesados y va actualizando en tiempo real la cache. La cache como veis es un formato clave de valor donde la clave es el customer ID, tenemos ciertos datos y luego al final tenemos todas esas etiquetas funcionales con la información que necesita. El nombre de la etiqueta y la información base que necesita para que el microservicio aplicando reglas drulz pueda generar dinámicamente esa etiqueta. Podríamos ver aquí por qué los jobs fling no almacenan o no actualizan directamente la cache. ¿Por qué pasan por un topic intermedio que al final mete la atención? Bueno, es por problemas de consistencia de datos. Si tuviésemos diferentes jobs fling actualizando la cache, daros cuenta que podríamos estar actualizando el mismo customer ID simultáneamente. Actualizar qué significa? Coger la nueva versión, añadir los datos y volver a guardar. Si lo estamos haciendo en paralelo eso podría darnos problemas de consistencia de datos. De esta manera al almacenarlos en un unicotopic fling se encarga de hacer un kby customer ID. O sea, me asegura que ordenamos todas las cambios que hay que hacer sobre un customer ID y los ejecuta de uno nudo de forma secuencial. Esto no significa que esto todo sea secuencial. Como obtenemos paralelismo en el global sync, lo que hacemos es que muchos usuarios están actualizando en tiempo real, pero cada uno de forma ordenada. Bien, ¿cómo desarrollamos todas estas marcas? Obviamente esto no es un proyecto de una única marca y no tenemos un montón de marcas, por lo cual no era parecía poco lógico empezar a desarrollar cada job fling, cada marca funcional siempre desde cero, cuando hay mucha de la funcionalidad que es equivalente. Bueno, pues para esto lo que hicimos fue desarrollarnos lo que llamamos una librería base donde está implementada un montón de funcionalidad común que luego vamos a necesitar para hacer los job. Y tenemos un arquitectipo Mavin que al final cada vez que necesitamos una lista, pues generamos ese arquitectipo que ya viene con la independencia de la librería base y digamos que ya tenemos un esqueleto con bastante funcionalidad donde ya tenemos que ir simplemente a personalizar lo que necesitamos. ¿Qué tenemos en esta librería base? En esta librería base tenemos toda la parte de parseo de la configuración y la configuración en sí del job fling, pues la autenticación, la autorización y demás. Tenemos el código común siempre de fling, pues crear un entorno, hacer el checkpoint, definir el paralelismo, todo esto para que sea muy sencillo y que cuando cualquiera de los equipos de desarrollo tenga que hacer una lista simplemente tenga que tocar unos parámetros y ya esté. Incluso metemos un main genérico en el que digamos que es la plantilla de Leo de un tópico Kafka, aplica una lógica y escribo en el tópico de destino con el formato que el GlobalSync espera para que los desarrolladores digamos solo tengan que ir a coger esa parte del medio y meter la lógica concreta y además muy importante incluimos ciertas abstracciones, ciertos objetos como el event o el join DTO que nosotros necesitamos para que la librería base funcione con muchas de las funcionalidades que hemos implementado los joins, inner join, left join, outer join que luego comentaremos y por supuesto la transformación del evento al formato genérico que es lo que espera GlobalSync para que independientemente de la lista que haya generado o la marca funcional que haya generado esa actualización el GlobalSync sea capaz de forma automática de actualizarlo. ¿Qué hace el GlobalSync? El GlobalSync como os comentaba solo hay un GlobalSync que tiene un paralelismo bastante grande por supuesto y lo que haces dinámicamente utilizando expresiones regulares detecta los nuevos topic Kafka de información procesada. Como tenemos acordado un esquema de datos entre las jobflinks que generan los datos y los y el GlobalSync dinámicamente lee esos datos y va actualizando en tiempo real la cache por lo cual tenemos uno corriendo 24% y nos olvidamos ya de la actualización de la de la cache una vez hecho este GlobalSync para nosotros el desarrollo de nuevas marcas funcionales es crear ese evento con un formato JSON, guardarlo en un topic de tipo procesado y automáticamente se actualiza en la en la cache. Bien hasta aquí hemos visto la parte de ejecución seguramente seguramente en la primera que todos pensamos pero como comentábamos al principio también hay que operar esto va a estar en producción 24x7 pues ahí entra la parte del arquitectura de operación lo primero es la infraestructura vale cómo tenemos desplegado esto muy rápidamente como os comentaba antes esto está en Amazon lo tenemos en una única región pero en tres zonas de disponibilidad las piezas core de esta arquitectura string Kafka con su toquíper y mr lo que tenemos es configurado en forma de cluster asegurando la tolerancia fallos vale la alta disponibilidad es decir si alguno de los nodos se cae pues tenemos en otra zona de disponibilidad ese mismo servicio funcionando por lo cual no perdemos no perdemos el servicio después bueno veis por ahí algunos otros nodos que necesitamos para hacer correlación de datos un bastión para acceder a los servicios en resúmenes esto tenemos desplegado todo en Amazon una única región tres zonas de disponibilidad diferentes todo configurado modo cluster para asegurar la tolerancia a fallos cómo desplegamos todo esto bueno nosotros seguimos la filosofía de estructura como código es decir necesitamos que los entornos sean siempre iguales consistentes y que tengamos el dinamismo de poder crear dinámicamente esos entornos es decir no tenemos un Kafka o un único fling mr depende la necesidad vamos a tener que crear otro mr o por criterios de segmentación poder crear otro Kafka necesitamos que todo eso esté automatizado con con plantillas con infraestructura como código básicamente utilizamos tele tecnologías vale utilizamos packer para definir las imágenes básicas sistema operativo file system los agentes que conjen los logs utilizamos terraform para definir la infraestructura que hay por debajo vale el hardware la topología de red los load balancer y por último utilizamos ansibol pues para la instalación de los productos y o la configuraciones concretas de esos productos por ejemplo para que estén modo cluster durante a fallos y demás como la infraestructura es código estas plantillas siguen el mismo ciclo de vida que cualquiera de nuestros desarrollos vale alguien los desarrolla con su entorno se guarda en un repositor y en un jetlab se hacen pruebas estáticas de calidad de código se hacen desplieges automáticos para comprobar que los entornos han quedado bien y una vez que esos entornos han quedado bien digamos que pasan a máster y están disponibles para que la nueva necesidad o despliegue de una infraestructura pues bueno necesitamos otro entorno de integración para pruebas de cuá pues ya podamos utilizar la nueva plantilla una vez que tenemos desplegadas infraestructura es muy importante monitorizarla vale asegurarnos que está funcionando correctamente vale tenemos un montón de piezas en muchas cosas donde donde mirar nosotros identificamos tres familias de parámetros no parámetros de sistema de servicio de aplicación de sistema típicos cpu run espacio disco de servicio específicos de nuestros de los aplicativos que tenemos ahí encima cuántos job fling hay corriendo cuántos topic Kafka hay cuántos megas por segundos están tratando en redis y los específicos casi funcionales nosotros nos importan mucho las latencias cuánto tarda un evento desde que se genera en el origen hasta que está actualizado en redis y si digamos que es la latencia más importante pero para detectar cuyos de botellas también hay que ir viendo lo que hay por debajo oye qué pasa desde que sale el origen del evento hasta que los coge stream como veíamos en arquitectura hay bases de datos muy antiguas que necesitamos un paso intermedio que es que es el gol de engate el cuello de botella que pasa con fling cuando pasa de un topic al procesado es el global sin el cuello de botella necesitamos ir sabiendo muy bien cuáles son las latencias para poder escalar más un job a escalar las más las particiones de Kafka meter más máquinas crear otro cluster es muy importante y eso sería los aplicativos obviamente todas estas aplicaciones de los cuentas tenemos redis tenemos Kafka zuki per lo específico de amazon hay un montón de hay un montón de métricas que se podrían generar es importante identificar cuáles son las más importantes vale si intentamos coger el 100% de las métricas de todos productos tumbaríamos cualquier sistema de monitorización vale es importante que detectemos cuáles son las claves para saber que tu sistema tiene tiene tiene salud y a partir de ahí pues definir cuáles son los valores umbrales adecuados o no y generar alertas esta es nuestra arquitectura de monitorización básicamente tenemos dos orígenes de dos orígenes de monitor de logs a monitorizar lo que ya me da close watch de forma nativa de amazon y los que nosotros generamos los que nosotros generamos de nuestros aplicativos lo que hemos acordado es que en todas las instancias los disponibilizamos en una obra específica en barra métrices tenemos unos agentes de prometeos que tanto de close watch como en ese barra métrices de nuestras máquinas los van consultando se los llevan a influx de vea y nuestra base de datos de logs y a partir de influx de vea por un lado hacemos unos dashboards en grafana y por otro lado lo lo conectamos con el sistema alertas que en este en este caso utilizamos capacitor que genera alertas a tiboli o más concreto y es un poquito casi más informal manda a slack avisos a la equipo operación para que esté para que esté atento nosotros como desarrolladores y arquitectos lo que más nos gusta es esto entramos en dashboards de grafana y vemos hoy si los topic Kafka están entrando eventos o no están eventos cuántos megas están actualizándose en reddit cuál es la latencia de esos diferentes pasos que juntaba y con esto pues podemos ir ir jugando vale cómo desarrollamos el código en esto bueno aquí tampoco hemos reinventado la rueda nos hemos intentado lo que hemos hecho intentar adaptarlo que ya más o menos hemos hecho todos o teníamos en la casa pues a este producto al final cada vez que generamos una marca funcional nueva creamos dos repositorios uno para código fling y otro para el código stream al final es un tipo de tql de secuel que se mate que me permite extraer los datos lo metemos en gitlab una vez que ese código está robusto que se hace comité master lo que haces Jenkins pues ejecuta pruebas estáticas de calidad de código dinámica si todo va ok pues se genera el artefacto que guardamos en artefacto y a partir de ahí se podría desplegar todo está automatizado la segunda parte en la que estamos trabajando que no está todavía del todo automatizada es una vez que están artefacto lo que necesitamos es desplegarlo vale lo que debería de hacer Jenkins es detectar si tenemos espacio en el mr disponible si tenemos espacio por paralelismo es lo disponible ejecutarlo y si no dinámicamente lanzar otro cluster mr y ahí meter el código vale eso es lo que todavía estamos un poquito intentando automatizarlo bien os voy a intentar contar ahora a modo de ejemplo cómo se desarrolla desde que nos dicen es de negocio oye esta es la nueva lista funcional hasta que ese código fling está disponible y lo actualiza en redes vale a nosotros casi siempre nos viene el requisito funcional por una secuel como os comentaba al principio el cliente ya tiene este sistema ya tiene un sistema de ubr donde guarda la información y lo hacen procesos batch tirando de los orígenes como lo hacen a origen pues con una mega sql normalmente o pl sql que une mil formatos por lo cual nuestro equipo de negocio habla con su equipo de negocio detectan esas secueles ya que convertirla en algo y bueno y nos la pasan por lo cual vamos a asumir que tenemos una secuela de ese tipo en el select vamos a ver cuáles son los campos que nosotros necesitamos los que tienen que estar después en redes en front me dice las tablas de origen que para mi job fling van a ser los tópicos afga los que tengo que leer y el huerr me va a especificar los filtros que tengo que hacer y además lo más importante los join entre los diferentes orígenes para generarlo bueno pues lo primero que tengo que hacer es conseguir los datos de origen vale pues con fling me conecto a los tópicos específicos creo un datastream con esa información que me viene en formato string y lo que hago es parsearlo para crear un objeto de tipo event vale event es un concepto nuestro genérico que hemos definido para que las operaciones genéricas que nosotros tenemos en librería base siempre pueda funcionar lo que hacemos siempre es heredar de la clase de la clase event para crear una clase pojo específica para este caso no pues información de consumo pues es el consumo event si es de contratación pues contratación event vale entonces lo que hago es me conecto a Kafka a Kafka creo un datastream de un datastream de strings hago el parseo y ya tengo un datastream de los pojos concretos con los que voy a trabajar si tengo los orígenes pues tengo dos datastream que están representados como dos pojos después la siguiente parte es el filtrado vale lo que tengo que hacer es filtrar toda la información que no necesito imaginaros que si estoy leyendo tablas que tienen 40 campos y al final solo necesito 2 pues todas esas campos me sobran entonces el filtrado cuanto antes lo haga mejor una vez que tengo los datastream ya con los con los pojos hago una función filter metropológica dentro y el filtrado es automático y luego sin duda la parte más interesante son los joins vale el join entre diferentes fuentes de datos el join en el mundo stream no es igual que el del mundo batch vale intentaremos verlo luego en la siguiente slide con un ejemplo pero bueno digamos que esta es la parte más mágica cómo conseguimos que estos tengan unos tiempos de respuesta buenos daros cuenta que nosotros tardamos en total desde que el evento entre en casca hasta que está en redis 200 milis segundos más o menos como conseguimos esto gracias a la gestión de estados que hace fling fling lo que permite es tener estados que es como si fueran bases de datos específicas y locales a cada nodo por lo cual no hay que ir a consultar un estado externo y lo que nosotros mantenemos en los estados es una vista materializada de la información que nos viene de origen obviamente con los campos que necesitamos es decir la última versión por cada clave primaria de ese evento nosotros esto lo tenemos digamos generalizado con la librería base básicamente con objetos como joins DTO lo que hacemos es convertir el datastream de eventos en un datastream de joins DTO y lo podemos conectar como conectamos esto pues básicamente al tener objetos joins DTO hacemos un connec en fling mediante de hacer un con un connec en fling esos dos datastreams van a poder utilizar y compartir los estados de ambos es decir es de uno puedo ver el de otro y al final lo que hago es cuando me venga un evento por el join de la izquierda reviso el estado de la derecha para ver cuál es la última versión con cuál la puedo hacer el join y genera un evento nuevo si me viene un evento por el join de la izquierda lo mismo hago el equivalente independientemente del orden donde vengan los eventos gracias a la compartición de estados pues yo puedo generar el resultado final alguien se puede preguntar si al final la lógica o se especifican en fling en SQL y fling tiene la manera de programar en SQL porque no habéis desarrollado los códigos en SQL que es pegar la SQL y ya está no y os ahorraréis tiempo lo planteamos no lo pensáis que no lo pensamos y lo intentamos hacer de hecho hacerlo desde el punto de vista de código sería bastante sencillo no hay un poco un ejemplo básicamente un datastream que es leer de Kafka el objeto datastream lo parseo para que tenga un formato lo registro como tabla registraría todas las tablas que necesito y a partir del SQL environment podría tirar la SQL y me generaría un resultado podría hacerlo qué es lo que pasa vamos a intentar ver aquí que el SQL en streaming no es exactamente igual que en batch no estaría para otra charla y cómo lo tiene implementado fling no es lo que a día de hoy nosotros necesitamos vale fling está lo tienen room a implementarlo de otra manera pero como lo tiene ahora no es lo que nos vale vamos a intentar ver con un ejemplo imaginados que tenemos que hacer joins de la tabla 1 con la tabla 2 vale vamos a ir viendo los resultados que genera el el si lo hicimos con SQL o si lo usamos con nuestra librería que hemos tenido que desarrollar para hacer inner join left según la lógica que nosotros necesitábamos imaginaos que nos llega un evento de la tabla 1 no tiene nada la tabla 2 por lo cual no hay que hacer ningún join me llega el evento de la tabla 2 ya tengo para hacer un join por lo cual por género el evento no evento x tanto fling como nuestra librería lo haría exactamente igual me lleva un evento la tabla a lo mismo ya tengo el evento de la tabla de la tabla 1 tiene información para hacer el join y lo generaría me llega una versión actualizada vale no es un evento nuevo es una versión actualizada de o sea es decir tiene la misma clave primaria de la tabla 2 que es lo que tengo que hacer pues hacer join de esa nueva versión con todo lo que tenemos en la tabla 1 vale hasta aquí perfecto todo exactamente igual el problema viene aquí me llega un nuevo evento de la tabla 1 como funciona fling es que hace un join con todas las versiones del evento de la tabla 2 vale por lo cual estaría generando un montón de información que realmente está desactualizada lo que nosotros necesitamos es que haga el join exactamente con la última versión vale esto que parece simple pues bueno no está no está implementado todavía de hecho si habéis estado un poco leyendo las noticias ayer por la tarde Kafka ha anunciado ksqldb donde una de las grandes incorporaciones es justamente esto que os estamos comentando esta librería que nosotros hemos tenido que hacer pues pues básicamente esa misma funcionalidad bueno pues con estas librería de nuestros joys de lectura y escritura pues crear crear estas listas pues nos es más o menos rápido esta es la manera en que desarrollamos por ir terminando bueno pues comentaros que este proyecto esta arquitectura está en producción ya ya llevamos meses en producción no están todavía todas las marcas funcionales creadas estamos en ello en ese proceso de desarrollo tenemos que generar unas 60 marcas funcionales de las cuales más o menos por lo que tenemos pensado 30 serán job fling y luego esas otras 30 las podremos casi derivar mediante mediante esa lógica que metemos en en rules cosas importantes que hemos aprendido ha sido fundamental separar los dos equipos vale ya sé que la filosofía de bops no están así pero para nosotros ha sido fundamental que haya un equipo específico de infraestructura definido centrado en crear la arquitectura tolerante a fallos que esté automatizada a monitorizarla tunearla performance y otro muy específico en el desarrollo funcional del código que se centren a hacer componentes reutilizables de calidad y demás cada uno con su mundo que obviamente tenemos puntos en común pero que trabajen de forma de forma independiente y centrados cada uno en lo suyo después también muy importante es la necesidad de tener gente de negocio que conozca identifique y entienda qué significa esas marcas funcionales vale porque nosotros como desarrolladores nos podemos entrar en hacer pruebas unitarias de rendimiento de integración y todo está genial pero luego el resultado no puede no tener tanto tanto sentido por lo cual en el momento en que metimos a gente de negocio sentado con nosotros a desarrollar el código decir oye mira lo que vamos a hacer es antes de ponernos a programar vamos a definir los casos de prueba el data set de entrada el data set de prueba de salida y para que todos entendamos en ese momento pues nuestros procesos de correlación que también es muy importante tener procesos de correlación de datos automáticamente de origen a destino pues empezaron a mejorar y a por último simplemente comentar que bueno este proyecto que empezó dentro del área de ubr como ha conseguido tiempos de respuesta muy buenos ha mejorado notablemente lo que existía pues otros departamentos están empezando a interesarse por él y ya tenemos los proyectos que no tiene nada que ver con ubr para entrar encima de esta arquitectura por lo cual como esto está creciendo pues tenemos en roadmap ciertas ciertas trabajitos por ejemplo uno es montar el gobierno del dato va a decir quién como y cuándo se puede crear un tópica gestión de los estados gestión de los esquemas que están trabajando todo es de una manera pues organizada con algún interfaz gráfico una política de revac lo que es un gobierno del dato otra es facilitar a la gente de negocio el trabajo a trabajar con esta arquitectura vale desde hacer pequeñas transformaciones porque hay situaciones en las que necesitan pequeñas transformaciones donde estamos viendo pues herramientas como como apache nifi hasta temas más complicados que es donde ellos quieren realmente vamos a deciros y programar vale quieren definir la lógica para eventos en streaming ahora todo el mundo ha visto que esto el tiempo real está muy chulo y lo quiere llevarse a sus a sus lugares no pero pueden no tener en sus equipos las skills técnicas ahí estamos empezando a desarrollar un interfaz gráfico vale que permita definir ciertas condiciones esas condiciones se transforman no en código fring sino en ese qlc vale y es ese qlc es el que automáticamente se convierte en código fling vale hacemos ese paso intermedio pero bueno esos son trabajos que todavía estamos en ello y nada más esto era todo lo que os quería contar si tenéis alguna pregunta encantado de responder muchas gracias si charla muy interesante lo única duda que me que se me plantea si habéis contemplado en cams en el caso de que cambia el esquema de los dos orígenes porque ahora mismo sin el skin registry se quedaría un poco acoplar al código no muy buena muy buena pregunta bueno tenemos como te comentaba tenemos tenemos objetos que extraen vale el esquema pero al final el micro servicio trabaja con unos campos específicos es decir como y aplica las reglas rule sobre unos campos específicos como en origen los cambios de esos campos específicos el micro servicio no va a poder aplicarlos vale más allá del evento por el camino que estos que lo tenemos gestionado con con objeto astra que ven y demás donde generalizamos los campos no no hay tanto problema pero desde el punto de vista funcional tendríamos sí que tendríamos ese problema valoramos es que en registry pero a día de hoy como estamos tan ligado a la última parte no nos aportaría no nos aportaría más valor pero en la parte en esta parte de gobierno que estamos pensando sí que de hecho si ves a la ui que puse ahí que tenemos ahora en prueba es justamente para gestionar los esquemas en es que en registry no tenemos en cuenta tengo una pregunta es una duda cómo hablabas de que los equipos han estado separados a mí de alguna manera puedo estar de acuerdo pero cómo tiene que haber un punto donde los ha juntado en algún momento cómo has como lo he hecho avisado auto servicio vale cuando yo que están separados están sentados en la misma mesa están sentados en las mismas bueno tenemos dos localizaciones o tres madrid barcelona exijo pero vamos parte de infraestructura de desarrollo están sentados en la misma mesa lo que digo es que no intentamos hacer como me ha pasado en otros proyectos que los desarrolladores también se encargan de la infraestructura y demás y no hemos separado teníamos un equipo de tres personas que es infraestructura no saben digamos de código java nada pero saben de paquete de ansibol hasta la muerte y saben de configurar ya para que los contenedores tengan la memoria adecuada perfectamente ellos han centrado solo en esa parte no querían saber nada si hemos desarrollado una lista o un componente y al revés ellos nosotros desarrollamos el código y me da igual donde lo desplea obviamente hay muchos puntos en común para cuando hacemos las pruebas en integración un proceso en el que los equipos estaban definiendo los entornos haciendo mucha prueba y error porque al final aquí esto va de prueba y error no nos engañemos no hay recetas mágicas de cuántos números de slots o de contenedores tenemos que poner la memoria en jar para que esto esté fino vale entonces en ese caso sí que colaboran están sentados en la misma en la misma mesa lo que parece es que tienen responsabilidades diferentes la parte de calidad de código soy mucho de tener tan por ejemplo sonar para ansibol etcétera eso lo dice hecho si tenemos sonar cube de hecho lo tenemos automatizado si no pasa que recordar el 50 por ciento de cobertura rechaza el rechaza el comit pero lo que sí que tuvimos un problema fue en ciertas ciertas pruebas unitarias de june que teníamos en el código no las detectaba vale no detectaba podemos tener que hacer muchos mocs porque obviamente probar en código flin que es distribuido y demás no se puede hacer en el un servidor local entonces hemos tenido que hacer ciertos mocs y esos mocs no los detectaba como calidad vale problemas con joco y demás y ahí nos hemos tenido que pegar para ver cómo generar dinámicamente esos result de los j unit para que son arquivos detectara y en quiso detectara ya ya podríamos pasar porque si no lo podíamos desplegar no se ha llevado nos ha llevado bastante trabajo hay alguna hay alguna librería hay una que se llama flin que permite automatizar ciertas pruebas pero no las cogen luego no cogen los los esquemas de neclema ni en ni en yankis por lo cual nos tocó picarnos a mano ciertas integraciones más bien para que las herramientas las vienes pero sí es fundamental a la calidad del código utilizamos ya por la pregunta que las pruebas nos interesa mucho utilizamos clases de equivalencia para definir los casos de prueba y mcdc para cobertura hola me ha parecido muy interesante mi duda es todas esas piezas open que utilizáis quién le da soporte a nivel aplicación nosotros nos encargamos pero bueno darte cuenta que es la tecnología son open source para evitar el vendor locking pero tras de redis está el servicio elastic cache por lo cual si se cae red es a la actualización de una nueva versión de redis eso es responsabilidad de amazon no responsabilidad nuestra si queremos actualizar una nueva versión de flin para en vez de la 1.8 que tenemos que irnos a la una nueva eso es responsabilidad de amazon porque ponemos la nueva versión de mr y ya lo tiene y para cazca cazca si que es 100% cosa nuestra vale si que es 100% utilizamos la de confluente la versión la versión open source en este caso y si esto crece mucho habrá que valorar tendremos que revolver a valorar luego utilizar el que ha gestionado de amazon o el cloud no nos gustaría irnos al clau de confluente porque tenemos más latencia luego por los datos pero nos tendremos que volver a evaluar esa esa decisión