[Orador 1]: Hola, ¿se me oye bien? Bueno, buenos días a todos. Gracias lo primero por asistir y también muchas gracias a los organizadores por permitirnos estar en este evento. Vamos a hablar de arquitecturas en tiempo real, en Big Data. No está en el título de la presentación, pero todas las tecnologías que vamos a ver son open source, no vamos a ver ninguna tecnología comercial, para que lo sepáis. El objetivo de la presentación es que conozcáis un poco la problemática de este tipo de escenarios, de soluciones en tiempo real. Primero vamos a ver básicamente a repasar por qué las empresas, por qué las corporaciones cada vez necesitan este tipo de soluciones con una necesidad muy acuciante y también vamos a hacer un repaso de todas las tecnologías que habitualmente suelen estar presentes en una arquitectura de referencia Big Data en tiempo real, con tecnologías de lo más novedoso. Bueno, para los que no me conozcáis, soy David Morales, trabajo en Estratio como arquitecto. Estratio es una compañía americana, aunque fundamentalmente estamos el core del desarrollo del producto, está aquí ubicado en Madrid. He participado en la incepción y el desarrollo de muchos de los módulos de la arquitectura que tenemos en Estratio, del producto, especialmente los que tienen que ver con visualización, tiempo real, streaming y proceso complejo de eventos. Bueno, vamos a la materia. Primero, como os comentaba, lo que quiero es explicaros cuál es la problemática del tiempo real. muchas de las empresas que conocemos en todos los sectores, tanto banca, retail, seguros, etcétera, tienen un funcionamiento basado en procesamiento batch. Casi todos los procesos que os podéis imaginar en una empresa grande, consolidación de movimientos, transferencias, movimiento de datos entre diferentes data warehouse, etcétera, son procesos que están normalmente programados para ejecutarse con una periodicidad, bien sea diaria, semanal, mensual, la que sea. Entonces, en este primer punto lo que quiero es que entendáis por qué es necesario este cambio hacia arquitecturas en tiempo real, por qué es necesario para las empresas, si quieren seguir compitiendo en el mercado, por qué es necesario que empiecen a pensar cada vez más en cómo dar respuestas en tiempo real a este tipo de... de necesidades de la empresa. Entonces, lo primero, doy por hecho que casi todos conocéis, prácticamente todos conoceréis este tipo de infografías, cada año suele salir una con datos cada vez más apabullantes sobre cuál es el movimiento que se genera, en este caso cada minuto, en Internet. Como podéis ver hay más de 600.000 logis en Facebook, 67.000 fotos se suben a Instagram, 433.000 tweets se envían en un minuto en el mundo. Estos son datos de 2014 y como os digo cada año suele sacar una infografía nueva donde estos datos suelen incrementarse en un orden de magnitud al menos. ¿Por qué? ¿Qué tipo de compañías veis aquí reflejadas? Casi todas están relacionadas con el social media. Como veis, Facebook, Instagram, Twitter, Pinterest, todas ellas están relacionadas con social media. Pero si os dais cuenta, casi todas ellas tienen un modelo de negocio detrás. Y las que no lo tienen, seguramente lo empezarán a tener dentro de poco. ¿Vale? Entonces, toda esta cantidad tan importante de información que está circulando en tiempo real no solamente es tráfico de red, no solamente son tweets por minuto, sino que detrás hay negocios que están funcionando con facturaciones, con impresiones, con pagos, etc. que se están ejecutando en tiempo real en estas empresas. Lo bueno que tienen estas empresas es que de vez en cuando publican este tipo de visualizaciones, de infografías, como queramos llamarlo, que nos permiten de alguna manera tangibilizar esa información que ocurre en tiempo real, porque muchas veces es difícil imaginarnos tanta información, no en qué se traduce. Esta infografía que veis aquí, por ejemplo, son los deseos que expresa la gente en Twitter cuando arranca el año. Pues quiero dejar de fumar, quiero ir al gimnasio, en fin. Seguramente el día siguiente haya un hashtag de lo dejo, pero bueno. Esto es una infografía que hizo Twitter sobre qué es lo que habitualmente, qué propósitos hacía la gente al principio de año. Bueno, Estamos acostumbrados a ver este tipo de infografías que normalmente están cocinadas, tienen un proceso en el que los datos se recogen, se filtran, se agregan para tener un dibujo muy específico que normalmente es una imagen, no es interactivo. Entonces, es bastante llamativo, a todo el mundo le gusta ver este tipo de datos, ¿no? Pero lo interesante en este tipo de empresas, como os decía antes, es que detrás de estas visualizaciones, detrás de todas estas infografías y estos datos que son apabullantes, hay negocio. Y todas estas empresas parten con un negocio anclado en el tiempo real. Ninguna de ellas tiene más de 10, de 15 años. Creo que el dominio de YouTube se compró en el 2004 o algo así, no tengo el dato exacto, pero creo que fue así. Entonces, estas empresas no tienen más de 10 años, muchas de ellas. Los modelos de negocio probablemente arrancaron hace 1, 2, 3 años como mucho. Entonces, todo su modelo de negocio está basado en tiempo real. Todos los servicios con los que ellos trabajan, facturan a los que se anuncian en la red social, por ejemplo, todas las promociones que hacen en las redes sociales, todo eso tiene una facturación detrás y todo está montado en tiempo real. En cambio, las compañías más clásicas, como os comentaba, los bancos, los seguros, etc., son compañías que tienen 30, 20, 25 años y todas ellas están construidas sobre una base tecnológica que, como os digo, puede tener fácilmente 25 años. Entonces, aquí nos encontramos con un choque, podríamos decir, generacional entre empresas muy importante, dado que las compañías orientadas al social media, digamos, o compañías digitales, nativas digitales, están ofreciendo a sus clientes servicios en tiempo real, ¿vale? tenemos por el otro lado una gran cantidad de compañías que tienen una media de 20-25 años que no tienen este tipo de soluciones en tiempo real. Entonces, cada vez hay un choque más fuerte porque estas compañías digitales van canibalizando más sectores o más parcelas de las compañías que no son digitales. Por ejemplo, Google... Tiene servicios de pago, Amazon ofrece cada vez más compra, por ejemplo, de productos frescos incluso, entonces van canibalizando parcelas de sectores de retail, de bancas, de seguros, etc. Entonces, ¿qué tienen que hacer estas compañías que no son digitales, no son nativas digitales, para seguir siendo competitivas? Tienen que cambiar sus paradigmas, tienen que cambiar todos sus sistemas para dejar de ser empresas estáticas que producen resultados al final del día o al final de la semana o al final del mes y tienen que empezar a producirlos en tiempo real. Este es el cambio y este es el gran, podríamos decir, drama incluso, porque realmente lo es, al que se enfrentan las compañías que tienen, como os digo, una media de 20 años. y habitualmente en una compañía de este tipo podemos empezar a dar soluciones en tiempo real de dos maneras o bien coger procesos existentes y llevarlos a una solución en tiempo real, romper los esquemas, patch de procesos diarios, nocturnos, etc., y llevarlos a una arquitectura en tiempo real, o bien coger información que ahora mismo la compañía no esté tratando. Coger esas parcelas de información que no están cubiertas en la compañía y meterlas ya en arquitecturas en tiempo real. Esas son las dos estrategias. con las que habitualmente empiezan este tipo de compañías a trabajar en tiempo real. Entonces, es lo que nosotros, por contraponerlo con el Business Intelligence, que es una disciplina que todos conocéis y que posiblemente tiene 20-25 años desde que más o menos establecieron las bases del Business Intelligence, que siguen teniendo vigencia, nosotros llamamos a esta necesidad del tiempo real y a cómo se desarrollan los procesos en el tiempo real, lo llamamos Operational Intelligence, por contraponerlo con... con las áreas de Business Intelligence que son departamentos súper necesarios en todas las empresas y que están presentes en todas ellas. ¿Qué podemos empezar a escuchar? ¿En dónde podemos poner la oreja, por así decirlo, dentro de los procesos y los canales que tiene una empresa offline? ¿Qué información podemos recoger para empezar a trabajar en tiempo real? Pues aquí tenéis un ejemplo. Podemos escuchar desde lo que ocurre en los TPVs, podemos escuchar lo que ocurre en las redes sociales también, podemos escuchar transacciones en tiempo real, por ejemplo, los logs de aplicación que hay en cualquier banco, por ejemplo, que tiene muchos sistemas, podemos ir recogiendo todos los logs e ir montando poco a poco... una arquitectura de tiempo real que permita pivotar a la empresa desde, como os digo, soluciones más ancladas en el batch a soluciones en tiempo real. Por tanto, ¿la conclusión cuál es? el real time, el procesamiento en tiempo real parece que es como muy novedoso, llama la atención, todas las empresas parece que quieren empezar a hacer cosas con tiempo real, todos estamos acostumbrados a visualizaciones, infografías, sistemas de monitorización así con gráficas, con muchas pantallas, todo eso es muy bonito, pero la realidad es que estas empresas dependen de este cambio para seguir siendo competitivas. Esto es muy importante. Probablemente dentro de cinco años, si estas empresas no cambian su forma de operar en sus procesos core, es muy probable que terminen en el olvido, porque las empresas digitales irán, como os digo, canibalizando cada vez más parcelas de las que tienen las empresas tradicionales. Por lo tanto, hay dos conclusiones. Necesitamos en este tipo de empresas repensar los procesos que tiene la compañía para hacer una entrega al cliente mucho más rápida y mucho mejor. Y por entrega no significa llevarte a tu casa un paquete de Amazon, sino entregar cualquier tipo de servicio, desde información que tienes en el banco hasta contrataciones, pasando por información que actualmente, como os digo, no se está teniendo en cuenta la compañía, pero que le puede dar un valor añadido a la empresa. Y por otro lado, crear nuevas oportunidades, como os comentaba antes, hacer uso de piezas que todavía la compañía no tiene contempladas para ganar ventajas competitivas. De alguna manera posicionarse o diferenciarse en un mercado que cada vez está más reñido. Bueno, y hasta aquí la problemática, como os digo... Yo creo que es interesante que entendáis por qué es necesario el tiempo real más allá de todo lo bonito que es ver gráficas en movimiento, infografías y visualizaciones. Esto realmente es un problema para las empresas. Vamos a ver ahora una arquitectura de referencia en tiempo real. Podemos añadir más piezas, podemos quitarlas, pero más o menos una arquitectura de referencia es lo que tiene, que más o menos intenta contemplar el caso estándar. Como veis aquí no hay tecnologías, no estamos poniendo apenas ninguna tecnología, son todo necesidades, luego vamos a ver cómo encajan las tecnologías en esta foto, pero es importante que entendáis cuál es el end to end de una solución en tiempo real. Una solución en tiempo real, por lo menos tal y como la entendemos nosotros en Estratio, empieza siempre en las fuentes de información y termina en la visualización. Es muy importante, especialmente en Big Data, que todos los resultados de todo lo que hagáis, pruebas de concepto, proyectos, etc., siempre tengan un resultado tangible. Porque muchas veces... los objetivos de un proyecto Big Data no son tangibles hasta que no los visualizas. Siempre contemplamos un end-to-end, como veis, desde las fuentes, pasando por la ingesta, almacenamiento, consulta y visualización. Así pensamos nosotros que se deberían afrontar los proyectos en tiempo real. Como veis hay necesidades más o menos claras, reflejadas, tenemos una primera pieza de data stream, ahora veremos qué tecnologías encajan y cuál es la necesidad que tiene, hay una pieza de transporte que nos permite conectar la parte del stream de datos con diferentes tipos de procesamiento, desde el almacenamiento RAW, que ahora os explico la importancia que tiene, también agregación y correlación. Podemos añadir más, podemos añadir más piezas, pero bueno, fundamentalmente en una arquitectura de tiempo real se requieren estas cuatro grandes cajas, data stream, almacenamiento en row, agregación y correlación. Respecto al almacenamiento de Big Data, estoy convencido de que todos vosotros conocéis las bases de datos relacionales, también conocéis las bases de datos NoSQL, seguramente conoceréis algún almacenamiento distribuido tipo HDFS o similar. Aquí no hay ninguna pegatina, como veis, es simplemente almacenamiento Big Data. Una cuestión interesante, que si me gustaría, luego lo vamos a ver, pero si me gustaría dejarlo claro ya, es que nosotros el almacenamiento Big Data en Stratio al menos lo consideramos que es híbrido totalmente. Es decir, no hay una solución que te permita resolver todas las problemáticas que tienes en el almacenamiento de Big Data. Como sabéis las bases de datos relacionales son de propósito general, te permiten a través de las formas normales y el modelado te permiten diseñar un caso de uso específico y luego el nuevo GSQL te da el resto. Te costará más o menos hacer una SQL pero prácticamente tienes asegurado que puedes extraer los datos de cualquier manera si el modelo está bien pensado. Las bases de datos no SQL son un poco diferentes porque son de propósito específico, no pretenden resolver cualquier caso de uso, sino que están pensadas para resolver bien uno, dos o tres casos de uso, muy específicos. Entonces es muy raro que consigas resolver una problemática de tiempo real con suficiente entidad solo con una base de datos, no SQL. Es raro, a lo mejor lo podéis hacer, pero habitualmente necesitas combinar al menos dos tipos de almacenamiento. Luego tenemos una capa de consulta que también veremos por qué es importante hablar de ella y también la parte de visualización. Si ponemos pegatinas encima de esta foto, hablando de tecnologías, podemos también cambiar las tecnologías y poner cualquier otra, pero aquí vamos a hablar de estas. En el caso del Data Stream podemos hablar de Flume, todos los proyectos que estáis viendo aquí son Apache, Apache Flume, Apache Kafka para la parte de transporte, almacenamiento en tiempo real que es simplemente una capa intermedia, Spark como pieza fundamental en la parte de procesamiento en tiempo real, tanto para agregación como para correlación y también para la parte de consulta, todo esto lo vamos a ver ahora con un poco más de detalle. El almacenamiento de Big Data, como veis, aquí hay cuatro pegatinas puestas, cuatro tecnologías, HDFS, Cassandra, Mongo y Elastic, para el estatio. Digamos que esto sería como la santísima trinidad del almacenamiento de Big Data. Podemos ir a cualquier caso de uso con estas cuatro piezas que prácticamente lo vamos a resolver sin ningún problema. Podemos añadir todas las que queráis porque ha habido una explosión de bases de datos no secure tremendas y que aquí podemos añadir todo lo que queráis. Pero bueno, estas cuatro más o menos reflejan los cuatro tipos de almacenamiento que podéis usar en Big Data. Vale, creo que nada más. Vamos a ir viendo ahora punto por punto, como veis hay una pequeña miga de pan arriba a la derecha donde vamos a ir evaluando desde las fuentes hasta el almacenamiento al menos, cuáles son las tecnologías y la problemática técnica a la que nos enfrentamos en una arquitectura de este tipo. Bueno, respecto a las fuentes, aquí hay un paradigma que es el de ETL, seguro que lo conocéis, ¿vale? Extraer información, transformarla y cargarla. Este es un paradigma que viene... ya dado desde el Business Intelligence, de la carga de los Data Warehouse, etc. Estos son disciplinas que están súper establecidas, pero en el caso del tiempo real tienen algunas particularidades, porque los datos los estamos cogiendo en tiempo real, no puedo hacer una extracción masiva de las transacciones que ha habido hoy en el día, digerirlas, transformarlas un poquito y guardarlas en un Data Warehouse, no puedo hacer eso. Los datos me están llegando en tiempo real, me están llegando las transacciones según se están produciendo. Entonces esto tiene unas particularidades técnicas, pero la necesidad es la misma. El ETL, como veis, sigue estando presente. Entonces para nosotros es muy importante en esta etapa del procesamiento, que es la etapa más temprana donde te enganchas a la fuente de datos, que se siga respetando las tres necesidades fundamentales de extracción, transformación y carga. Respecto a la parte de extracción, bueno, fuentes, aquí hemos puesto algunas, que son bastante clásicas en un escenario de tiempo real, pero bueno, obviamente hay bastantes más. Respecto a la extracción, podéis imaginaros que los datos no siempre vienen estructurados, es posible que estemos escuchando logs de aplicación, logs de un sistema, transacciones bancarias que vienen sin estructura. Entonces aquí tenemos que soportar los dos tipos de información que nos puede llegar, de datos estructurados y no estructurados. En la parte de transformación es muy relevante porque en lugar de hacer una transformación masiva de los datos necesitas hacer transformaciones al vuelo, que normalmente pasan por hacer un data cleaning, por ejemplo, de los datos, si me viene un log de aplicación, Puedo limpiar la fecha, puedo normalizarla, puedo aplicar un formato estándar. También la parte de enriquecimiento es muy importante. Te llega un log de aplicación, imaginaros, con una IP que ha hecho una petición y a través de una base de datos de GeoIP, por ejemplo, puedo averiguar la geolocalización de esa IP. Lo que estoy haciendo es añadir un campo al dato que me ha llegado originalmente enriqueciéndolo. Este proceso es bastante clásico, ya no solo en logs, sino por ejemplo en transacciones normalmente la transacción que te llega no tiene todos los datos del cliente, te llega un ID. Y a lo mejor para hacer otro tipo de cuestiones necesitas saber la provincia del cliente. Pues vas enriqueciendo el dato según te va llegando y le vas aplicando estas transformaciones orientadas o bien al data clearing o bien al enriquecimiento. Respecto a la carga, aquí tenemos tres tipos fundamentales de almacenamiento. El almacenamiento RAW, es decir, guardar exactamente el dato que me ha llegado de la fuente y ahora vamos a explicar por qué es importante. Guardar información para el procesamiento a largo plazo, ¿vale? orientado al batch processing, tened en cuenta que las fuentes en tiempo real pueden dar soporte a procesos, pero también son una entrada de información, una entrada de información que a lo mejor queremos explotar después en procesamiento batch. Entonces hay que almacenarlo orientado a ese tipo de explotación posterior y luego normalmente suelen utilizarse técnicas de indexación para hacer una analítica en tiempo real, por ejemplo en el caso de los logs, pues es muy habitual utilizar técnicas de indexación para hacer luego búsquedas de texto libre o similares. ¿Qué tecnología se podría usar en cuanto a la pieza de Data Stream? Nosotros habitualmente, en un gran porcentaje de los casos, utilizamos Apache Flume. Aquí hay otras tecnologías. No sé si conocéis Fluenty o Logestash, por ejemplo, Heca creo que también, Scoop, bueno, hay muchas tecnologías que te permiten hacer este tipo, resolver este tipo de problemas, ¿vale? De coger datos de una fuente en tiempo real y hacer un procesamiento con ellos. Flume es una tecnología bastante usada porque es muy estable, tiene ya varios años de desarrollo y es bastante flexible. No requiere codificación, todo va por programación declarativa, simplemente defines en un fichero cuál es tu fuente, qué transformaciones quieres aplicar, cuál es el destino de los datos y no hace falta a priori programar nada. Lo bueno que tiene Flume es que te garantiza la entrega punto a punto, ¿vale? Es decir, en el momento en el que el dato entra en el sistema, digamos, te garantiza que se va a llevar al sync, ¿vale? Esta garantía tiene obviamente letra pequeña, pero es fácil preparar un sistema productivo donde se asegure que no hay pérdida de eventos en ninguno de los puntos de Flume, ¿vale? La estructura de Flum es básicamente como veis la de un ETL, fuentes, transformaciones y los sinks son la parte de carga. Aquí hay un ejemplo de cuál es el catálogo que tiene Flum para cada uno de los casos. Como veis, por ejemplo, en las fuentes podemos cargar datos desde, por ejemplo, un spooling, que es bastante clásico. Spooling es engancharte a un directorio de un sistema operativo y ir recorriendo todos los ficheros que hay en ese directorio procesándolos línea a línea. En fin, podemos también engancharnos a buses tipo JMS, en fin, puedes engancharte a un montón de fuentes. En la parte de transformación, aquí tenéis un catálogo de las posibilidades que tiene Flume respecto a transformar los datos en tiempo real. Como veis, muchos de ellos están orientados a parseo. Me llega un dato bruto y quiero parsearlo, quiero aplicarlo a una estructura. Otros son para enriquecer el evento, por ejemplo, el de GeoIP o el de Add Current Time, por ejemplo. Cualquiera de ellos lo que te permiten es ensanchar el dato para añadir información nueva. Hay por ejemplo una pieza, la de Grok, que es para aplicar expresiones regulares. Normalmente se utiliza también para extraer datos del dato RAW que te ha llegado. Y en cuanto a los destinos, como podéis ver, hay diferentes opciones para grabar los datos. MongoDB, Elastic, HBase, HDFS, Cassandra, en fin, hay bastante variedad. Lo bueno que tiene Flume es que puedes grabar en syncs en paralelo, es decir, puedes grabar a la vez en Cassandra y a la vez en HDFS o puedes grabar todo en HDFS y solo los eventos que tengan una expresión regular concreta se graban en Elasticsearch. Es una pieza bastante potente en ese sentido y como os digo se utiliza muchísimo en cuanto a la captura de datos. Bueno, no me voy a entretener mucho más. En cuanto al transporte de datos, ¿qué necesidades fundamentales tenemos en el transporte? Lo primero es que de alguna manera haya una especie de especificación en lo que está circulando en el bus. Esto no es totalmente obligatorio, pero sí es recomendable. Que soporte esquemas o que soporte alguna forma de definir lo que el consumidor está enviando y lo que el receptor está recibiendo. No obstante, como os digo, no es algo obligatorio. Hay diferentes formas de solucionar este tipo de desacople entre productor y consumidor. Lo que sí es interesante es esto, que tenga muy alto rendimiento y que sea bastante escalable la solución de base. Y esto es importante. Hay algunos buses del mercado que seguro que conocéis, RabbitMQ, ActiveMQ, Hornet, Apollo, cualquiera de ellas. Cualquiera de ellos son tecnologías que ya posiblemente tengan 8 o 10 años y que no nacen con la necesidad de la escalabilidad de base. Entonces lo que han hecho es ir añadiendo diferentes parches para soportar escalabilidad, lo cual no está mal, pero no nacen con esta solución de base. Entonces ahora vamos a ver alguna tecnología que sí que nos permite una escalabilidad y un rendimiento muy alto. Y el último punto quizás es el más importante de todos en una arquitectura de Big Data. poder desacoplar productores y consumidores. Esto es bastante interesante, yo creo que es de las cuestiones más novedosas que se están viendo en el último año, año y medio en las tecnologías de Big Data. Por ejemplo, LinkedIn propone una arquitectura en la que todas sus fuentes de información están totalmente desacopladas de los que los consumen. Ahora vamos a ver cómo esta pieza te ayuda a desacoplar un productor y un consumidor. Los buses tradicionales están pensados para comunicar punto a punto. La calidad del servicio, por ejemplo, depende de que el productor emita un mensaje y el consumidor lo reciba. Si no lo recibe, entran en juego unas políticas de reintentos, etcétera. En este caso, esta comunicación no existe. El productor produce y el consumidor consume. El productor produce y no sabe quién lo va a consumir y el consumidor consume y no sabe quién le ha enviado el dato. Esto es muy interesante para especialmente el rendimiento y también para garantizar que los evolutivos que se vayan haciendo sobre la arquitectura se soporten mejor. La pieza que habitualmente utilizamos en esta fase, en la fase de transporte, es Kafka. Seguro que habéis oído hablar o lo conocéis. Es un bus liberado por LinkedIn, ya forma parte de la Apache Software Foundation. La verdad es que es una maravilla, a mí es una de las piezas que más me gustan de este tipo de arquitecturas. El concepto la verdad es que es muy sencillo, el concepto base de Kafka es muy sencillo. Rompen con el esquema tradicional de un bus y logran escalabilidad en base a un clúster de brokers, replicación y hay una pieza muy interesante en la arquitectura de Kafka que es el offset, el concepto de offset, que eso en los buses tradicionales no existe. El offset es básicamente el mecanismo que tiene el consumidor para saber por dónde está leyendo, ¿vale? El productor está enviando una pila de mensajes, imaginaros 100 mensajes y el consumidor aparece y empieza a leer desde un punto concreto. Puede empezar a leer desde el principio o puede empezar a leer desde el momento en el que se levanta el consumidor, ¿no? A partir de ese momento el consumidor empieza a guardar un registro del punto en el que se encuentra, en qué mensaje se encuentra para que en caso de que pare y vuelva a empezar a leer, por algún motivo, sepa continuar desde donde lo dejó. Este concepto en los buses tradicionales no existe y es una de las piezas clave en la arquitectura de Kafka porque te permite desacoplar, como os digo, la parte de producción de datos de la parte de consumición de datos. Bueno, respecto a la parte de agregación en tiempo real, que esto es una problemática bastante usada, prácticamente todos los datos que consumís en Twitter, por ejemplo, o en Facebook son datos agregados. Nunca hay una consulta a una base de datos para hacer un group buy. Normalmente se hace una consulta donde tú tienes una foto estática de lo que hay en tu muro de Facebook. Son datos que están preagregados. En ningún caso, como os digo, a Facebook por volumen de datos se le ocurre ir a la base de datos cada vez a hacer un group buy. Son datos que están preagregados. Y es una problemática que, como os digo, está presente en muchos sectores. No solo en Facebook, sino que el hacer agregación en tiempo real es un problema bastante clásico. ¿Qué necesidades hay en cuanto a una agregación en tiempo real? Habitualmente tener este tipo de estadísticas y KPIs que están calculados con antelación te permite, por ejemplo, tomar información en tiempo real. No solo es un tema de rendimiento, de no machacar la base de datos para hacer el mismo group by n veces, sino que también es un tema de conseguir KPIs que no tienes actualmente. También la parte de agregación multidimensional es una necesidad, necesitas, por ponerse un ejemplo, los tweets, podemos medir tweets por minuto, los tweets que tiene una persona por minuto, pero también podemos medir los tweets que hay en un hashtag concreto por minuto, por hora y por día, ¿vale? Podemos agregar toda la actividad que se está produciendo en un banco concreto, en un cajero concreto, en una cuenta concreta de un cliente, agregar transacciones por tarjeta de crédito o transferencia habitual. Este tipo de agregaciones multidimensionales son muy clásicas. Como os digo, te permiten tener información actualizada en tiempo real. Que el banco pueda saber en este minuto preciso cuáles son la cantidad de transacciones que han ocurrido por minuto en tal provincia o en tal sucursal o en tal cajero. Y luego respecto a la flexibilidad y recuperación de los datos, la agregación lo que te permite es poder jugar con los datos mucho mejor. En lugar de matarte haciéndote consultas con GroupBytes uniendo 17 tablas para conseguir este KPI concreto, defines los KPIs que necesitas de entrada y el motor de agregación o la solución de agregación te permite tenerlos ya calculados. Con lo cual tienes que hacer únicamente una consulta para decir dame la situación que había en el minuto 33 de la hora 10. Entonces esto te da una flexibilidad y una rapidez en cuanto al consumo de datos que es tremenda. Es un cambio totalmente diferente y os voy a poner un ejemplo. Para que ahora mismo alguien de negocio en un banco solicite un KPI nuevo, quiero saber cuántas transacciones se hacen por minuto por sucursal bancaria, a partir de esa petición tan sencilla arranca un proceso de business intelligence, de carga de datos, etcétera, que puede tardar días y no meses hasta que por fin esta persona tiene ese dato. De esta manera es fácil hacer agregaciones en tiempo real si tienes los datos de las transacciones y conseguir ese KPI mucho más rápido. ¿Qué soluciones solemos utilizar para las agregaciones en tiempo real? A ver cómo voy de tiempo. Bueno, habitualmente solemos utilizar Spark, Apache Spark es un nuevo paradigma de procesamiento que viene a reemplazar MapReduce, Hadoop MapReduce, tiene la ventaja de que es mucho más... más potente, más rico en cuanto a las operaciones que te permite hacer y tiene otra ventaja que es que soporta estas tres vertientes de procesamiento y alguna más. Mínimo es para que se cuele consulta interactiva, procesamiento en tiempo real y machine learning. También tiene otras capacidades, por ejemplo, procesamiento orientado a grafos. Y esto te permite desarrollar proyectos con una única tecnología, pero que te permiten aplicar Machine Learning o procesamiento en tiempo real o consulta interactiva sabiendo solo una tecnología. Voy a ir un poco rápido para intentar cubrir todos los slides. Apache Spark, seguro que lo conocéis. Este es un benchmark bastante clásico de ordenación de registros. Este es el último récord de Hadoop en 2013 y este es el de 2014 de Spark. Veis que la infraestructura que se necesita es bastante menor y el procesamiento es mucho más rápido. Como os digo, Spark tiene una vertical específica para procesamiento en tiempo real con la que podríamos desarrollar una solución de agregación como la que estamos viendo ahora mismo. Bueno, en cuanto a la correlación, esta es una necesidad bastante interesante, especialmente para detectar patrones de eventos. Por ejemplo, imaginad que estoy escuchando las transacciones que ocurren en un cajero automático y quiero detectar fraude. Bueno, pues es muy sencillo, o no tan sencillo. A mí se me ocurre una. Por ejemplo, detectar el uso de la misma tarjeta de crédito en dos cajeros diferentes. Uso un cajero aquí, uso otro cajero en Segovia, en un rango de tiempo de 15 minutos, pues puede haber fraude. Alguien me ha clonado la tarjeta y la está usando en otro sitio, ¿no? Ese tipo de patrones es el que habitualmente se resuelve con ese tipo de procesamiento, con Complex Event Processing. No está presente en Spark como tal, pero sí se puede hacer alguna regla de Complex Event Processing como tal en Spark Streaming. Respecto al almacenamiento RAW, solo deciros que es muy importante en cualquier arquitectura de tiempo real guardar el dato que te ha llegado tal cual, sin transformación. Y es muy importante especialmente por el punto central, el del reprocesamiento. ¿Qué ocurre si el proceso que yo he hecho en tiempo real tiene un bug, por ejemplo? ¿Cómo voy a la fuente otra vez a decirle, oye, dame las transacciones de ayer? No puedo, es una fuente en tiempo real. Entonces, es muy importante guardar el row y prever mecanismos de reprocesamiento para que en caso de que haya un bug o en caso de que te venga el usuario de negocio a pedirte un nuevo KPI, puedas recalcularlo desde hace uno, dos, tres meses o un año. Eso es muy importante. Aquí hay tecnologías, seguro que las conocéis todas ellas, HDFS como almacenamiento a largo plazo, MongoDB, Elasticsearch, Cassandra, todas ellas te pueden servir para este tipo de solución. Respecto a la consulta, aquí solo comentaros una cuestión. Habitualmente, como os digo, un lago Big Data no se conforma solo con una tecnología de almacenamiento. No te vale solo HDFS, solo Cassandra, solo Mongo. Normalmente tendrás dos o más piezas unidas para dar una solución. Entonces, una capa de consulta que te permita atacar a los dos fuentes simultáneamente y que puedas hacer un join, por ejemplo, entre datos que tienes en Mongo y datos que tienes en HDFS es fundamental. Para ello, habitualmente, nos apoyamos en Cassandra, en Mongo, en Elastic, voy a pasarlo un poco rápido, pero la pieza fundamental es Spark SQL. Spark SQL sí que te permite, a través de las abstracciones que tiene DataFrames, te permite hacer este tipo de joins, de agregaciones, etc., entre fuentes diferentes. Bueno, y ahora voy a pasar rápido por la demo que traía, no es una demo real, simplemente es contaros un caso de uso. Row, que es una compañía que me he inventado, Es una compañía de retail, no vamos a ponerle nombre, podéis imaginaros cualquiera, que debido a la aparición de diferentes actores digitales que están, como os decía antes, canibalizándole sus parcelas, necesita mejorar todos sus tiempos de respuesta y procesos para ganar ventaja competitiva. ¿Cuál es la situación actual de ROW? Pues tiene procesamientos nocturnos, tiene inteligencia estática basada en reporting mensual, por ejemplo... Tiene sistemas complejos, es una compañía que suele tener 20 años, como os decía, 15, 20 años, son muchos años de deuda tecnológica. Y habitualmente algunas de ellas han lanzado a un canal online, pero no han hecho bien. Lo han hecho como un silo más. Entonces tienen su canal offline y el canal online normalmente con departamentos totalmente duplicados. ¿Cómo aplicamos una solución de tiempo real en una compañía como esta? Pues fijaros que partiendo desde un... una premisa tan sencilla como dame los tickets digitales simplemente déjame escuchar los tickets de compra en formato digital que eso es algo que ya prácticamente todos tienen podemos empezar a montar una solución en tiempo real para darle muchas ventajas a este tipo de compañía ahí veis un ticket en formato jason con la fecha el cliente que ha comprado qué método de pago ha usado qué centro comercial ha comprado el cajero etcétera etcétera Bueno, si empezamos a utilizar todas las tecnologías que hemos estado viendo hasta ahora, utilizamos Flume para capturar los datos, hacer un enriquecimiento del ticket añadiendo la ciudad, por ejemplo, el canal. cualquier otra información relevante. Podemos pasar a la correlación de datos en la que podemos averiguar, por ejemplo, si hay compras fraudulentas o cuáles son los niveles de stock o cuál es el canal de actividad que está fallando, por ejemplo, si te dejan de llegar peticiones de un canal concreto, pues puedes saber que puede haber un fallo en ese canal concreto. Podemos hacer agregaciones para calcular KPIs, por ejemplo, de la actividad que está ocurriendo diariamente, o a la hora, o al minuto, la actividad de cada cliente, el rendimiento por producto, por centro comercial, por método de pago y el comportamiento del cliente en tiempo real. Todo esto son cosas que habitualmente estas empresas no tienen. Tienen que esperar un día entero o si no un mes para tener un informe que les diga cuáles son las ventas que se han producido, cuáles son los hábitos de sus clientes, ¿no? En cuanto al almacenamiento, como veis podemos usar cualquiera de las tecnologías que hemos hablado, en consulta Spark SQL es la pieza clave para poder unir especialmente el mundo Big Data con las bases de datos existentes en la corporación, Oracle o Postgres o cualquiera de ellas. ¿Y cuál es el resultado? Pues podríamos tener una visualización de este tipo, podríamos tener un rendimiento de lo que está ocurriendo por minuto en mi compañía entera. Quiero saber dentro de ROW, quiero saber qué está ocurriendo, las transacciones que están ocurriendo en este momento. Podría hacer un drill down para llegar a saber por minuto cómo está rindiendo el centro comercial que está situado en Guadalajara. O podría llegar incluso a saber cuál es el rendimiento por método de pago o cualquier otra cosa. Este tipo de información la tienes ya calculada en tiempo real y preagregada, con lo cual este tipo de visualizaciones son súper rápidas. No tienes que ir a la base de datos, hacer agregaciones, pasar por procesos de tele, procesos nocturnos de carga masiva, etc. También podríamos tener paneles de monitorización donde puedas ver en forma de mapa geolocalizado cuál es la actividad que está ocurriendo en tus centros comerciales o en tus canales online. Los centros comerciales quizás serían los puntos más gruesos, pero un canal online te puede llegar una venta desde cualquier punto. Este sería un mapa bastante real de una empresa que tiene esa mezcla entre canal offline y canal online. O cuáles son los hábitos de tu cliente, por ejemplo, si compra más alimentación, o si ha gastado más dinero en electrónica, o si suele pagar con tarjeta de crédito, si el volumen de compras que hace normalmente es bajo, medio o alto, por ejemplo, en qué centros comerciales suele comprar, toda esta información la podéis tener actualizada en tiempo real. Y esta es la gran diferencia que hay respecto a las arquitecturas que hay montadas en cualquier empresa que os encontréis ahora mismo. Bueno, pues nada más. Creo que de tiempo vamos bien. Sí. Bueno, como os digo, nosotros tenemos en Statio algunas soluciones desarrolladas ya sobre Spark. Por ejemplo, tenemos un motor de agregación en tiempo real, totalmente open source. Tenemos una capa también de acceso a datos, tenemos herramientas de visualización. Os animo a que echéis un vistazo a nuestro GitHub. Tenemos repositorios open con licencia Apache 2, donde tenemos nuestros módulos publicados. Podéis echar un vistazo a nuestra página web, a nuestro Twitter. Necesitamos a gente para sacar todo esto adelante, así que os animo también a que echéis un vistazo a las oportunidades que tenemos. Y nada más. Muchas gracias. Si queréis hacer alguna pregunta, disparad ahora. [Orador 3]: Buenas. La pregunta es sobre todo cuando le dais la solución a una empresa, lo primero es, si ellos ya tienen servidores o un sistema propio interno, ¿vosotros lo alojáis siempre dentro de eso o le dais una solución externa? Y lo segundo es, a la gente que está allí que normalmente toda esta tecnología no la conoce, ¿lo formáis vosotros o cómo solucionáis ese tema? [Orador 1]: Vale. Bueno, respecto a tu primera... Muchas gracias. Respecto a tu primera pregunta, gracias a ti. Respecto a tu primera pregunta, la verdad es que es una problemática que va más allá de dónde lo despliego. Va más allá de si tengo máquinas compradas o no las tengo, porque eso normalmente es una cuestión, pues eso, de hacer una orden de compra, ¿vale? La problemática va más allá, es, vale, yo tengo esto en mi casa ahora montado, ¿quién lo mantiene? ¿Quién se encarga de cuando Kafka tenga un problema? ¿Quién mira, no? Porque habitualmente los departamentos de sistemas de las empresas... Tienes especialistas en sistemas, especialistas en bases de datos, especialistas en aplicaciones web, pero no tienes especialistas en Big Data. Entonces, cuando vas a una empresa a contar una solución de este tipo, suele haber preguntas de, oye, vale, me encanta, lo necesito, sé que lo necesito, pero quiero saber al día siguiente de que me lo pongas en producción, ¿quién mantiene esto? Bueno, pues para eso, obviamente hay empresas que te dan soporte, ¿no? Nosotros somos una de ellas, también tienes Cloudera, Hortonworks, cualquier proveedor de Big Data, no solo te provee la tecnología, sino que también te ayuda a mantenerla en producción, ¿vale? Obviamente, igual que pasa con Oracle, por ejemplo, tienes que pagar una licencia. Oracle no se mantiene solo. Tienes que pagar una licencia anual para tener soporte, para poder hacer uso de esa tecnología en un entorno productivo. Lo primero, que sepas que hay empresas que te pueden ayudar a montar esto en producción. Respecto a la infraestructura, la verdad es que normalmente se utiliza infraestructura dedicada. No se suele reutilizar infraestructura que ya tenga la compañía. Especialmente porque las necesidades de Big Data son muy particulares. Igual que un Teradata, por ejemplo, o un Exadata o un Oracle, igual tienen infraestructura dedicada. Normalmente un banco no tiene un Oracle instalado en una máquina cualquiera. Tiene una Playams, una máquina que va enracada y que tiene un hardware específico para que esa base de datos corra como un demonio. Entonces, habitualmente tiene sentido que si vas a invertir en una solución de Big Data, inviertas a su vez en un hardware específico que te permita también sacar el máximo provecho a la tecnología. Y la segunda pregunta que me has hecho, no me acuerdo, así que no me la voy a inventar, si me la puedes hacer otra vez... [Orador 3]: Era sobre todo lo de la formación, pero ya me lo has dicho luego al principio. [Orador 1]: Sí, la formación va acompañada, es decir, cuando una empresa se aventura a arrancar procesos de Big Data, normalmente hay una formación, efectivamente. Nosotros damos formación, por ejemplo, en Stratio a nuestros partners y también a compañías finales en las que conocen estas tecnologías, aprenden a hacer uso de ellas, no tanto en desarrollo, que también lo que busca una compañía como Stratio, como Cloudera, como Horton, es que esa empresa sea autónoma para poder desarrollar sus soluciones pero también se les forma en la explotación tengo mi sistema montado si se cae a las 5 de la mañana no quiero llamarte a ti quiero tener a mi equipo de explotación que igual que me mantiene un Oracle o la aplicación web quiero que mantenga mi sistema de Big Data así que sí, el proceso va acompañado de normalmente infraestructura dedicada y en todo caso de formación específica ¿Alguna más? [Orador 2]: Bueno, mi pregunta va más al tiempo real, la latencia, porque siempre todos los sistemas de tiempo real tienen una latencia. ¿Qué soluciones o dentro de la arquitectura cuál está más enfocada a minimizar el tiempo de latencia? [Orador 1]: Bueno, todas ellas, todas las soluciones que os he comentado, desde Flum hasta la capa de consulta, te garantiza que la latencia es mínima, de entrada. Es cierto que, te voy a hablar por mi experiencia, en mi experiencia la latencia normalmente viene más por la fuente que por el procesamiento. estamos en ese punto donde las fuentes todavía no son lo suficientemente rápidas hablo de entornos corporativos clásicos y la solución de Big Data está todavía muy por delante quizás en el futuro cuando tengamos unas fuentes mucho más rápidas es posible que empecemos a encontrar aquí ciertos cuellos de botella pero a día de hoy lo normal es que la latencia esté más en la fuente que en la capa que tú montas en cualquier caso hay mecanismos para reducir la latencia pasando obviamente por el propio despliegue que hagas, garantizar que la localidad del dato, por ejemplo, esté garantizada y también por cómo configuras los diferentes elementos que forman parte de la ecuación completa. Puedes mejorar la comunicación entre Flum y Kafka, por ejemplo, o entre Spark y Kafka. Spark Streaming, supongo que si lo conocéis lo sabéis seguro, el procesamiento en tiempo real está basado en ventanas. Tú especificas cuál es el tamaño de la ventana. Una ventana es una fracción de tiempo en la que tú te quedas escuchando la fuente para recopilar todos los eventos que se han producido en esa ventana de tiempo y pasarlos al procesamiento. Si esa ventana obviamente la pones en 5 minutos y tú esperas tener los datos actualizados cada minuto, pues va a ser complicado. Siempre tienes que adaptar la ventana un poco a las necesidades que también tengan las personas que están consumiendo esos datos. También influye la verbosidad que tenga la fuente. Si tienes una fuente muy verbosa, a lo mejor es preferible hacer una ventana más pequeña para no saturar todo el pipeline que tienes montado. Es un tema delicado. Hay una receta mágica. En muchos casos tienes que adaptar algunas piezas para asegurar que la latencia sea pequeña. [Orador 2]: ¿Alguna más? [Orador 1]: ¿Alguna más? Bueno, pues muchas gracias a todos.