 Bueno, voy a hablar un poco de un caso de uso de Big Data y especialmente de Hadoop en la estación de valor de tarjetas, de transacciones con tarjetas de crédito para el banco BBVA. Lo primero, bueno, me gustaría presentarnos. Nosotros básicamente lo que dedicamos es a maestrar al elefante, el elefante de Hadoop y bueno, básicamente tenemos mucha experiencia en proyectos, en el desarrollo de proyectos con Hadoop desde muy pronto ya que leímos el paper de Google MapReduce, vimos que eso era cañero y nos decidimos a empezar a aprender y a usarlo. Al final de estar en varias startups decidimos montar nuestra propia empresa y hemos estado ofreciendo servicios de consultoría y formación. Actualmente seguimos ofreciéndolos pero nos estamos moviendo más a productos, estamos desarrollando nuestro propio producto Big Data sobre el que os contaré un poco algo al final de la presentación porque hoy os puedo comentar que en primicia lo liberamos Open Source y bueno, también os encanta el mundo Open Source y hemos liberado algún proyecto como Pangool que os voy a hablar de esta presentación porque lo hemos usado. Lo primero me gustaría comentar mi visión sobre el Big Data. Para mí el Big Data es como esta hamburguesa. Es apetitosa, se ve muy apetitosa, pero no fácil de comer. No es nada fácil de comer y un poco la cuestión es esto es lo mismo. Nosotros nos encontramos con problemas de Big Data que suena muy bonito todo el tema pero como te comes la hamburguesa. Y un poco lo que quiero presentar en esta presentación es cómo nos hemos comido la hamburguesa con el BBBA con el tema de los datos. Bueno, primero presentar un poco quién es el BBBA. Supongo que como estas charlas en castellano todos los que estáis aquí es el BBBA pero bueno, 104.000 empleados, 47 millones de clientes. Así que os podéis imaginar que es bastante grande. Bueno y cuando nos viene el BBBA qué nos propuso, cuál era el problema que ellos querían resolver. Ellos lo que querían era extraer valor de datos anónimos de transacciones con tarjeta de crédito. Ellos tienen muchos datos con tarjeta de crédito y ahora que estamos en la época del Big Data pues les empezó a sonar el oído, pero tantos datos que tenéis pues no se puede extraer algún valor que salga de los propios datos. Un valor que sea anónimo, que sea impersonal, que esté disociado y que sea irreversible. Es decir, naturalmente los datos que estamos usando son datos de tarjeta de crédito así que no pueden usarse los propios datos por temas de privacidad. Entonces simplemente se trata de buscar qué datos agregados aparecen e emergen digamos de agregar esa información y luego tratar de que esa información pues sea útil para la sociedad. Eso es un poco subjetivo. La idea es ayudar por ejemplo a los consumidores a tomar decisiones informadas por ejemplo recomendándoles tiendas o comercios según donde ellos estén en un momento dado. Entonces dado lo que ha hecho la gente comprando los comercios que la persona ha comprado en este comercio, siempre compra en otro comercio, puedes recomendar a gente qué comercio debería de ir. También puedes informarle de cuál es por ejemplo el gasto medio por persona en el comercio o puedes decirle a qué hora hay más gente dentro del comercio, etcétera. Entonces digamos que la gente podría un poco tomar decisiones más informadas si coincides esta información. Naturalmente otra opción es ofrecer esos datos a las propias tiendas. Las propias tiendas pueden aprender de los patrones del cliente. Pueden aprender primero qué fidelidad tiene sus clientes. Vuelven mucho los clientes, vuelven a comprar esa tienda o son clientes de paso. ¿Cuál es el sexo, la edad y la localización de estos clientes? Por ejemplo, a qué horas es mejor tener abierto? Viene mucho la gente al final y me convendría abrir una hora más y podría cerrar igual abrir un poco más tarde. Bueno, básicamente esto aterrizándolo un poco. La idea es generar este tipo de estadísticas por ejemplo para la tienda. Vamos a ver algunas de ellas. Por ejemplo, lo primero es varios rangos. Queremos calcular estos datos para rangos de tiempo variables. Es decir, bien todo el período temporal es posible, anuales por seis meses, cada cuarto, cada mes o cada semana y cada día. ¿Qué tipo de datos queremos calcular? Por ejemplo, el histograma de pagos. Bueno, estos datos son falsos, por eso el histograma es tan plano. Pero en realidad el histograma nuevamente se tendría que parecer más a una distribución normal. Pero bueno, en un histograma de pagos tú puedes ver en cada tienda cuál ha sido el gasto que ha realizado cada persona y cuánto número de personas ha realizado qué gasto. Es bastante útil, te puede ser útil, por ejemplo, para conocer cuál es el comportamiento de compra de tus clientes en la tienda y para la gente para saber cuánto la gente se está gastando en esa tienda. También podemos ofrecer un histórico. Un histórico de cuál ha sido el gasto medio en la tienda durante el tiempo. Podemos ver si sube, si baja. Y podemos ver aquí lo que se ven son los clientes que han vuelto a la tienda y todos los clientes que has tenido únicos. Puedes ver para cada mes. Oye, pues sí que hemos tenido estos clientes este mes y además de ellos han vuelto tantos clientes. Puedes tener la distribución por sexo, la distribución por edad, la distribución por visitas recurrentes. Es decir, por ejemplo, el 83% de las personas que han ido a esta tienda la han visitado entre 10 y 19 veces. Naturalmente esto es un caso ficticio, un poco extraño. Y arriba tenemos recomendaciones de tiendas. O sea, si la gente que ha comprado en esta tienda también ha comprado muy habitualmente en estas otras tiendas. Esto puede ser útil para el cliente. Entonces, la aplicación. ¿Cómo quiere el banco explotar esta información? Bueno, esto todavía está un poco en discusión dentro del banco. Actualmente lo usan para uso interno, un poco para explorar las posibilidades que pueden tener para el desarrollo de aplicaciones con esos datos. Una posibilidad clara es presentarle un panel al vendedor para que el vendedor pueda aprender, pueda saber cómo se compra en su tienda. Algo que ahora mismo no tiene. Y directamente sería más o menos un servicio gratuito. O sea, alguien va a una página web. Un gratuito me refiero, que es bastante de coste bajo. Porque una tienda pequeña no tiene posibilidades para desarrollarse una aplicación como esta. Sin embargo, si directamente, porque ellos tienen una TPU, tú les puedes dar estos datos seguramente de alguna manera les ha introducido la analítica dentro de una tienda. También se quieren hacer aplicaciones para los propios clientes. Aplicaciones que pueden ser webs o aplicaciones móviles. Un poco para lo que he dicho. Un poco para los datos de comercios, en lugares en los que estás, para conocer los patrones en la tienda, los horarios, si va a haber mucha gente o no va a haber mucha gente, etcétera. En cualquier caso, todo esto es un trabajo que está en progreso. Como es un departamento de innovación del banco, con lo que estamos trabajando, están innovando en la parte de generación de datos y ellos también están innovando en la parte de negocios con estos datos. Los retos a los que nos enfrentamos con esta aplicación, pues varios. Lo primero son los silos en las compañías. Las compañías como los bancos, al final tienen muchos departamentos que son muy estancos y es muy difícil al final coordinar varios departamentos para hacer una aplicación de este tipo. Si tuviésemos que haber ido al departamento de Data Warehouse del banco para decirle oye, quiero que no sé qué o te voy a lanzar una SQL. Probablemente hubiese sido una especie de reto o conseguir que ellos nos dicen acceso. Entonces tuvimos que hacer algún truco, digamos, una especie de bypass para tener el mínimo impacto en el resto de departamentos del banco. Los costes. Para una aplicación de innovación, los costes son importantes. Esta aplicación extrae valor de los datos pero todavía no sabemos cuánto valor. Así que no puede tener un alto coste. No es lo que estamos realizando, no es una aplicación core del banco. La operativa la tiene cubierta con sus sistemas. Estos son aplicaciones nuevas con los datos. La cantidad de datos. Por dar un dato en Estados Unidos en el año 2009 se revisaron 50.000 millones de transacciones con tarjeta de crédito. En todo Estados Unidos. Eso os da una idea de qué número de transacciones se mueven en el mundo. En el banco son menos pero siguen siendo altísimos. La seguridad en todo banco pues la seguridad es algo importantísimo. La flexibilidad y la agilidad en el desarrollo esto es clave porque estamos en una aplicación de innovación. No sabemos a priori todos los requisitos de la aplicación. Sabemos que hay un valor ahí y que va a haber que extraerlo. No sabemos si hay que agregar por año, si hay que agregar por mes. Necesitamos mucha flexibilidad y necesitamos flexibilidad no solamente no hablo de parametrización del sistema. Hablo de flexibilidad, hablo de poder cambiar igual desarrollar una cosa nueva, etcétera y que eso no sea algo doloroso. Y finalmente que se oporte los errores humanos. Esto es algo para mí bastante importante. Porque al final si hablamos de sistemas habituales con bases de datos relacionales imaginamos que alguien comete un error en el código y de repente se pone a sumar en una tabla y en lugar de sumar uno sumaba 200. Y tú no sabes exactamente en dónde lo has sumado. El volver a recuperar la consistencia dentro de las bases de datos se convierte en una tarea titánica complicada y al final muchas veces lo que acaba ocurriendo con este tipo de sistemas es que la mayoría del tiempo la tienes resolviendo bugs que has tenido en el código. Entonces nosotros queremos hacer un sistema que soporte los errores humanos que si el código ha fallado sea tan fácil como cambiar el código volver a ejecutar y que todo se solucione. Entonces ahí tenemos estos retos que teníamos para el desarrollo del producto y de ahí decidimos qué plataforma usar. Podemos usar una plataforma sin house o usar la nube podemos usar Amazon Web Services para esta aplicación y principalmente nuestra aplicación tiene tres capas. La primera capa es la capa de almacenamiento para ella usamos S3 que es un servicio de almacenamiento en Amazon que proporciona almacenamiento masivo de datos con alta durabilidad y bajo coste. Otra de las capas es la capa de procesamiento de datos. Esta capa la cubrimos con ElasticMapReduce que no es más que Hadoop bajo demanda en Amazon y esto nos da una funcionalidad que es que podemos arrancar un cluster ejecutar lo que queramos y luego tirarle y esa es una reducción de costes que tenemos. Y finalmente tenemos la capa de servicio y la capa de servicio la hemos realizado arrancando instancias en C2 que es la nube de Amazon donde puedes arrancar las temperas. La arquitectura, hablemos de la arquitectura ¿Cómo os ha planteado este sistema? Bueno, lo primero es hablar de donde guardamos los datos. S3, que está aquí abajo, la capa de almacenamiento tenemos un servicio que es el DailyUploader. Este DailyUploader lo que hace es cargar los datos de las transacciones bancarias que se produjeron ayer. Esto es nuestra única comunicación con el resto de departamentos que hemos tenido que luchar con el silo, con el otro departamento que es el de DataWareHouse para que nos rodeese. Pero una vez conseguido esto, nosotros almacenamos en S3 absolutamente todo el histórico de transacciones financieras, reacciones con tarjeta de crédito. Naturalmente anonimizadas. La nube de tarjeta de crédito está jaseado etcétera, no tenemos nombre de persona esos datos no son peligrosos. Tenemos el DataWareHouse propio. Hemos hecho un bypass del DataWareHouse del banco y lo tenemos aquí en S3. Esa es la primera clave del servicio, el almacenamiento. ¿Cómo funciona esto? Voy a seguir un poco por la capa de servicio y luego cuento la capa de actualización. La capa de servicio es esta que tenemos aquí arriba que está en S2. Esta capa de servicio si veis ahí pone Voldemort. Voldemort es una base de datos KeyValue que fue desarrollada por LinkedIn. Luego cuento un poco más. Un WServe que es un servicio desarrollado por nosotros que lo nuevo que hace es una especie de pantalla entre Voldemort y la aplicación que es simplemente convierte la interfaz HTTP y hace un poco de load balancer. Lo conectamos a un load balancer y ahí tenemos las aplicaciones tirando contra esta base de datos KeyValue. En esa base de datos KeyValue es donde almacenamos todas las estadísticas precomputadas de tal manera que todo lo que queremos servir en una web etcétera está precomputado anteriormente. Pero si os dais cuenta aquí no aparece por ningún lado la actualización. Cómo se actualizan los datos de este Voldemort y dónde se calculan. Aquí es donde entra el clúster Hadoop en el Astigmab Reduce y el controller. El controller es la aplicación que está encargada de actualizar el Voldemort a partir de los datos que tenemos en S3. El controller lo primero que hace es arrancar un clúster con el número de nodes que queramos. Una vez que haga un clúster lo que hace es lanzar este flow esto es un flow en Hadoop y este flow lo que hace es preprocesar y filtrar unas registros y luego lanza el cálculo de estadísticas el cálculo de tarjetas estadísticas de tarjeta y el cálculo de recomendaciones. Y finalmente todos estos precálculos de estadísticas ya están precomputados a la salida de cada uno de esos procesos se indexan con el Voldemort Indexer. El Voldemort Indexer lo veremos un poco después pero lo que hace es precomputar las estructuras que Voldemort necesita en producción. Esas estructuras se almacenan de nuevo en S3 en este punto el controller tira el clúster de Hadoop ya no lo necesitamos, lo apagamos y le mandamos una orden a los Voldemort para que se descarguen todos los datos nuevos que tienen que servirse y Voldemort automáticamente se los descarga los datos nuevos con los viejos sin que haya ningún tipo de pérdida de servicio en la parte de servicio de la aplicación. Vale, esto es un poco la arquitectura principal ahora voy a entrar un poquito en detalle en algunas tecnologías que hemos usado y en algunas detalles de implementación de algunas cosas que hemos tenido que implementar. Bueno, lo primero, Hadoop os voy a comentar un poco en una introducción breve a Hadoop aunque ya se ha hablado todo el día de Hadoop supongo que os habréis informado un poco de qué va esta introducción somera Hadoop, una de las claves que tiene un sistema de ficheros distribuido en el que puedes introducir ficheros tan grandes como quieras escala horizontalmente al poner más máquinas más ficheros puedes meter y más datos puedes hacer y esto se puede hacer en caliente y soporta failovers y tiras una de las máquinas o tiras según como tienes pues digamos que tus datos sobreviven, no mueren esta es una de las partes de la clave de Hadoop pero claro, almacenar no es idea de nada si no puedes computar sobre ellos y esto es un poco la clave de Hadoop y la magia es que mezcla tanto la capa de almacenamiento como la capa de computación. La capa de computación lo que hace es basarse en MapReduce que ya habéis hablado de que es una invención de Google, que luego se implementó en Hadoop y que es un paradigma de computación paralela y algo importantísimo a tener en mente es que es BatchOriented, es decir lo que hace MapReduce es simplemente tener un fichero que está en el sistema de ficheros distribuidos lo procesa de algún modo haciendo una agrupación y aplicando un par de funciones y finalmente el resultado es otro fichero dentro del sistema de ficheros distribuido entonces cualquier aplicación que montes encima de Hadoop lo que tienes que hacer es enlazar este tipo de jobs que se llaman, enlazas un job o otro job y al final tienes un flow, un flujo cuyo resultado final son otras series de ficheros así que al final, tú empiezas con una serie de ficheros de entrada y una serie de ficheros de salida y esto es Hadoop y esto es una de las dificultades también porque es difícil pensar en una aplicación que tenga utilidad que partas de un fichero de inicio y acabas en un fichero al final, y es porque realmente luego se flexibiliza esto un poco en esta presentación veremos un ejemplo de esto y aquí es donde metemos Pangool, ¿qué es Pangool? bueno nosotros hemos estado desarrollando con Hadoop mucho tiempo y es muy difícil programar en Hadoop, por dos razones primero porque la API es bastante complicada y segundo porque el propio MapReduce no cubre los casos de uso comunes que te encuentras al desarrollar cualquier flow por muy simple que sea como por ejemplo, ordenación secundaria registros con varios campos o incluso o joins entonces al final para hacer estas cosas tan simples tenías que implementar algo muy complicado y de bajo nivel, así que nosotros bastante tiempo usando la API viendo que no había alternativas que nos gustasen, desarrollamos Pangool Pangool es un proyecto Pensors que es una apijada de Hadoop más sencilla pero que mantiene una eficiencia similar a la de Hadoop todos los patrones comunes están la mayoría de patrones comunes están cubiertos como os he dicho como registros con varios valores ordenación secundaria y joins y bueno, tiene otras mejoras que también hemos detectado como por ejemplo la configuración por distancia o multiple inputs y multiple outputs por efecto sin que tengas que hacer algún truco pero bueno, al final, para explicar un poco mejor Pangool la clave es que Pangool es una implementación de Tappelmap Reduce para Hadoop y que es Tappelmap Reduce pues Tappelmap Reduce es nuestra evolución al algoritmo original de Google y es que bueno, nos hemos atrevido un poco supongo que con un par de narices a proponer una alternativa mejor al sistema que propuso Google al principio bueno, esto lo hemos escrito en un paper y este paper nos lo han aceptado en la conferencia internacional de Datamining que se va a hacer ver en Bruselas en diciembre y lo estaremos presentando allí y bueno, me gustaría un poco explicar en qué consiste Tappelmap Reduce en realidad en Tappelmap Reduce lo que hacemos es que en MapReduce si lo conocéis un poco, está basado en Key and Values nosotros reemplazamos el Key and Values por una tupla porque es más conveniente pero veamos un ejemplo es un fichero que está en el sistema de fichos distribuidos y tenemos aquí cada tupla pues es una tupla de tres campos en este caso son las oficinas en cada lugar y cuánto han vendido, digamos, en un período de tiempo imaginaos que queremos contestar aquella pregunta de arriba cuál es la diferencia entre la oficina que más ha vendido y la segunda que más ha vendido por cada lugar pues cómo funcionaría esto con Tappelmap Reduce bueno, lo primero es que esto lo que tiene es probar el programador el programador de Hadoop tiene que probar algo parecido pero esto es empangul lo que tiene que probar es lo primero es un group buy porque quiere agrupar los datos en este caso quiere agruparlos por localización porque queremos saber para cada localización cuáles son los que más han vendido lo segundo es que va a indicar una función que se va a aplicar a cada grupo esta función lo que recibe es la lista de tuplas que se han agrupado por el campo que tú has indicado y finalmente tienes que indicar por qué quieres ordenar por qué quieres ordenar en el sentido que cómo quieres que las tuplas te lleguen ordenadas a la función entonces, en este caso, si lo fijáis agrupamos por localización pero ordenamos por localización y en sentido y además por sentido descendente del precio de las ventas si miráis las dos funciones que se van a ejecutar es la primera función se va a aplicar a todos los datos de Londres por la localización y los datos que estamos ordenados por las ventas así que el primero que más ha vendido es el primero y el segundo que más ha vendido es el segundo y lo mismo para Madrid sólo que tiene dos únicas tuplas y entonces qué se hace si aplica la función que ha pasado desarrollado que en este caso la función es súper sencilla simplemente crea otra tupla que va a ser la tupla de final de salida que va a ser la tupla del primer campo es el nombre de la localización de la oficina en la primera y la segunda tupla y finalmente la diferencia entre las ventas que es la diferencia entre el primero y el segundo así que al final tenemos aquel resultado que es un fichero en Hadoop que tiene tuplas y la clave de todo esto la cosa bonita de Hadoop es que esto se ejecutan distribuidos estas funciones que aquí vemos que se ejecutan sobre esos grupos solo hay una restricción que se debe cumplir no se puede agrupar y ordenar por cualquier cosa la cláusula por la que agrupas la restricción por la que agrupas ha de ser un subconjunto de la restricción por la que ordenas en realidad está sencillo si ponemos así la tupla simplemente es que el grupo ahí tiene que ser más pequeño que el sorbol hemos demostrado que si esto se cumple entonces TapperMapReduce se puede implementar en cualquier implementación de MapReduce existente sin cambiar su arquitectura es decir, en realidad TapperMapReduce no es más que una manera más conveniente de implementar el MapReduce existente y eso es lo que hemos hecho hemos implementado TapperMapReduce para Hadoop y esto es Pangool la clave de mostrar que la eficiencia es la misma de nada sirve que hayamos hecho un mejorado el MapReduce original si es más lento bueno, aquí un poco demostramos los números que a pesar de estar encima de la API de Hadoop porque nos olvidéis que estamos convertimos las tuplas aquí value por debajo en realidad la eficiencia es muy similar perdemos muy poquito y probablemente si se pudiese implementar sin hacerlo encima de Hadoop sino con un poco de más bajo nivel probablemente no se perdería nada bueno, hasta aquí Pangool, Pangool lo hemos usado en todo el proceso que habéis visto que se ejecutan Hadoop cada uno de esos bloques azules como varios jobs MapReduce implementados en un pipeline y todos en Pangool Voldemort, hablemos un poco de Voldemort de la parte de servicio porque al final nosotros los datos los cogemos en Hadoop pero lo que queremos es tener una base de datos para poder servirlo en una aplicación web y para eso usamos Voldemort Voldemort es una base de datos key value fue inventada por LinkedIn bueno, fue desarrollada por LinkedIn pero está usando, digamos, conceptos para crear Amazon expuso con su base de datos Dynamo vamos a explicar primero la capa de servicio la capa de servicio en realidad, tú tienes varias instancias de Voldemort corriendo en diferentes máquinas y tú tienes diferentes chunks de información estos chunks son en realidad bloques de datos con key value donde todas las keys, digamos, están en rango es como si fuera un diccionario tú tienes tu en ciclopedia pues cada volumen de ciclopedia sería uno de estos chunks delante de Voldemort tienes LubeSharp que es una cosa que hemos implementado a nosotros pero no es algo excesivamente complicado simplemente es, usando el cliente de Voldemort convertimos sus peticiones TCP porque Voldemort que tiene este TCP la convertimos en una interfaz HTTP más conveniente para nosotros y aparte enruta las queries, digamos a los nodos aunque bueno, esto del enrutamiento puedes enrutarlo pero luego que estén mal enrutado entonces Voldemort lo reenruta, etcétera bueno, esto es lo de menos el caso es que el servicio es capaz de tirar contra Voldemort y responder a queries que hagas sobre una key de volumen del value una cosa importante, los datos, los chunks están replicados, ¿de acuerdo? hay unas siete replicaciones y si se te cae algún nodo todo esto sobrevive, o sea que tiene failover y además puedes aumentar el throughput porque si ponéis más máquinas pues más throughput tienes puedes aumentar todo throughput como la cantidad de datos a servir los datos pues ponéis más máquinas vale, pero cómo actualizamos este Voldemort porque este Voldemort está ahí sirviendo datos pero no si os dais cuenta no hay ninguna petición de actualización por ese servicio ese servicio es sólo lectura la actualización se realiza desde el cluster de Hadoop en el cluster de Hadoop nosotros tenemos el fichero de entrada en el que tenemos, digamos, después de nuestro proceso de Hadoop que ha realizado todas las agregaciones y el procesado que queramos pues este fichero de equivaleos lo damos al Voldemort Indexer esto viene con Voldemort y Voldemort Indexer lo que hace es dedicarse a crear esos chunks esos volúmenes de enciclopedia, digamos y esos volúmenes de enciclopedia al final no son más que la estructura que Voldemort va a utilizar para servir en producción que en realidad es un B3 es un árbol B de toda la vida de los que tienen la base de datos por debajo para generar índices y para generar tablas específicamente es la base de datos BerkeleyDB y lo que se hace con estos chunks una vez que se ha acabado es que se lanza un deployment se le dice a Voldemort oye, Voldemort, bájate a los nuevos chunks y reemplázame por los viejos y esto digamos que es atómico y tiene muy poco impacto en el servicio porque, claro, los datos ya están pre-generados en Hadoop hemos desacoplado la actualización del servicio de otra manera que no tenemos impacto al actualizar el Voldemort pero hay más ventajas y vamos a ver las ventajas que tiene ahí hay algo clave y es que estamos actualizando todo siempre no hay actualizaciones incrementales sino que cogemos todo el histórico de datos esto no lo he hecho en capí antes y lo voy a hacer ahora cada vez que lanzamos el proceso cogemos todo el histórico de todos los datos bancarios no cogemos y cogemos los últimos del último día cogemos siempre todo y esto que aparentemente es una locura es la mejor decisión de diseño que puedes tener para desarrollar este tipo de aplicaciones que tiene algunas ventajas bueno, las ventajas por ejemplo es que bueno, las ventajas de usar Hadoop y Voldemort en esta manera es que tienes una escalabilidad y soporte errores porque si necesitas más capacidad de procesamiento aumentas tu tamaño de tu cluster si necesitas más capacidad de Voldemort aumentas el número de máquinas así que se puede decir que se escala segundo al desacoplar la creación y la actualización de la base de datos no afectas a la base de datos para nada su servicio así que siempre está ofreciendo un servicio constante no tienes peligro de que en ciertos momentos tu servicio de actualización esté tirando demasiado contra tu base de datos y aquí la que más me gusta a mí todos los datos se reemplazan en cada ejecución todo la base de datos Voldemort entera tiras la antigua y pones la nueva y esto te da muchísimas ventajas lo primero es que nos ofrece una flexibilidad y una agilidad en el desarrollo increíble y cambiar absolutamente todo el pipeline de un día para otro, ejecutarlo y tener unas bases de datos completamente diferentes con un esquema completamente diferente por ejemplo hacer que se lancen a otro cluster de Voldemort y tenemos dos clusters de Voldemort y luego actualizamos la aplicación web decimos oye ya no tienes contra este actualizate y contra estas nuevas de datos tiramos el Voldemort antiguo y hemos cambiado absolutamente la aplicación de arriba abajo hemos actualizado todos los datos que teníamos del histórico y ha sido bastante poco costoso esto con una base de datos relacional es una locura, ponte a cambiar un esquema o bueno, se convierte en bastante complicado el esquema está en producción no puedes cambiarlo o se aledas a cambiar y puede ser dolorosísimo aparte que tampoco escala así que bueno, esta es una de las mejores decisiones también esto te permite sobrevivir a errores humanos porque si nos equivocamos en el desarrollo y sumamos mal por ejemplo a las estadísticas la hacemos fatal pues simplemente cogemos y cambiamos el código, volvemos a ejecutar a poner bien porque partimos del histórico partimos de los datos en bruto siempre podemos cambiar todo absolutamente y bueno, podemos fácilmente crear clases de diferente topología esto ya lo he explicado un poco antes que podemos coger y arrancar un cluster teníamos un Voldemort de 4 máquinas pues ahora queremos uno de 20 máquinas entonces cambiamos el... ahora no me actualices aquí, actualicenme acá y cuando queramos cambiamos la aplicación web que tire contra la base de datos nueva y listo osea, hemos cambiado el tamaño de nuestro cluster de modo muy sencillo bueno, hasta ahora ha hablado un poco de las dos tecnologías clave que hemos usado en el pipeline aparte de la plataforma en Amazon hemos hablado de Pangool para desarrollar los para programar en Hadoop y hemos hablado de Voldemort para servir los datos vamos a hablar un poco ahora de la aplicación que hemos realizado bueno estadísticas básicas las estadísticas básicas son fáciles de implementar con un job de Hadoop como os habéis imaginado en el caso que os he puesto la dimensión que aplicas es fácil coger y realizar cosas como por ejemplo contar, calcular la media el mínimo, el máximo y la dirección típica eso en un único job de Hadoop agrupas por la dimensión que quieras contar por ejemplo por la oficina y luego por lo único que haces es te vienen los datos, sumas o sumas al cuadrado lo que quieres hacer también podemos utilizar un único job para computar varios periodos en el mismo job porque al final hemos dicho que queríamos periodos no solamente semanales, mensuales, anuales esto lo podemos hacer en un mismo job simplemente utilizando el mapper y replicando cada línea de transacción mandándolo digamos a una agregación de periodo diferente esto simplemente en la tupla introduces un identificador de periodo y duplicas ese dato para todos los periodos que tengas bueno, aquí está explicado bueno, el distant count ya no es tan sencillo pero también se puede hacer un único job la clave un poco es que tienes que ordenar por la dimensión por la que quieras contar únicamente por ejemplo en este caso visitantes únicos a una tienda una vez que lo tienes ordenado y lo recibes ordenados en el reducer entonces sí que puedes contar los usuarios únicos cuando encuentras la diferencia entre un grupo y otro veamos un ejemplo aquí tiene la tienda y la tarjeta de crédito entonces ¿cómo contamos aquí los usuarios únicos que han entrado en la tienda? pues primero cuando cambia aquí encontramos pues evidentemente sumamos uno y siempre hay que sumar uno al final para que esto ajuste y tenemos dos así que al final en el mismo job que habíamos contado estadísticas básicas también contamos usuarios únicos y lo más regular son histogramas y normalmente los histogramas se deben de calcular en dos pasos normalmente el primer paso supone encontrar el mínimo y el máximo para luego dividir en las columnas que tú quieras tener y finalmente haces una segunda pasada para rellenar las columnas con los datos que te vas encontrando y finalmente ya tienes el histograma pero claro ejecutar dos jobs para calcular histogramas es bastante costoso así que nosotros hemos usado un histograma adaptativo un histograma adaptativo funciona de la siguiente manera partes de tu tienes un número de buckets un número de columnas digamos fijo imaginamos este caso, en este caso tenemos la primera columna de tres observaciones en la segunda dos, en la tercera una en la cuarta dos y llega a una nueva observación que queda fuera del rango del histograma ¿qué hacemos? comprimimos el histograma estas dos buckets van al primero esas dos buckets van al segundo bucket y la otra va a ver el dato en la tercera bucket de tal manera que el histograma se va adaptando según van llegando en los datos y al final tienes un histograma que se ha adaptado de tal manera que podemos hacerlo en una única pasada y las columnas se adaptan vale, entonces ya tenemos el histograma hemos calculado un histograma de igual por ejemplo de 500 barras y esto lo hemos hecho en un único job de Hadoop para todos los comercios, para todos los periodos toda la vez queremos calcular el histograma óptimo porque en realidad lo que queremos calcular es aquel histograma que encaja mejor con el histograma original usando barras de tamaño variable un número de barras fijo esto tiene dos razones para hacerlo la primera es de almacenamiento es decir, si tu almacenas 500 columnas es bastante más que si almacenas 100 o 50 pero sin embargo puedes alcanzar casi una resolución similar almacenando 50 si son de longitud variable y la segunda es de visualización un histograma con columnas variables se ve bastante mejor vamos a ver aquí algún ejemplo imaginamos el histograma original que hemos calculado el verde de fondo y este sería el histograma digamos que si queremos hacer un histograma que representa el mismo histograma pero con solamente tres columnas nos encontramos con aquella representación la superficie azul sería el error el error de representación que estamos teniendo con respecto al original sin embargo si pudiéramos hacer la columna de tamaño variable nos encontraríamos con que el histograma adapta bastante mejor este histograma de 8 barras 3 y 10 adapta bastante mejor tiene muchísimo menos superficie azul al final resulta que nos encontremos con que hay un histograma de los dos que representa el histograma de mejor manera aquí se puede ver un poco la imagen eso evidentemente representa mejor este histograma ¿cómo calcular este histograma? bueno pues hay un paper de esta gente y en este paper expone un algoritmo exacto para calcular el histograma óptimo pero bueno nos dimos cuenta de que es bastante lento así que lo que hicimos fue utilizar un algoritmo aproximado que es básicamente un random restart hill-climbing es un algoritmo de optimización que lo único que hace realidad os lo voy a explicar aquí es tu partes de una solución ya dada y ahora tienes varias posibilidades de movimiento desde esa solución a una próxima que es mover esta barra hacia la derecha, moverla hacia la izquierda mover esta barra hacia la derecha o hacia la izquierda tienes cuatro posibilidades entonces lo que haces es decidir la mejor aquella que al moverte de esa dirección reduce la superficie azul el error y al final lo que te vas a acabar es en un máximo problema, que ese máximo puede ser un máximo local, es decir que no hayas encontrado la mejor solución porque partiendo de esa solución no es la buena, pero esta solución es bastante fácil con hacer un random restart que simplemente es una vez que he encontrado una solución busco otra empezando de otra solución inicial y al final me quedo con la mejor de todas este es el algoritmo ya lo explicado y lo bueno pues es que resulta que la velocidad es muchísimo mayor o sea hasta un orden de magnitud y la precisión es del 99% o sea que es bastante sorprendente al final usamos este algoritmo entonces conclusión, al final todas las estadísticas el distant count, el histograma varios periodos para la tienda y para cliente, al final todos nos cabe en un Nikoyop, así que lo ponemos todo junto en un Nikoyop y en un Nikoyop calculamos muchísimas estadísticas para el comercio recomendaciones bueno las recomendaciones nos pasamos en las ocurrencias, es decir si yo compro en esta tienda y también he comprado en esta otra tienda, evidentemente hay una conexión entre ambas tiendas, lo que hacemos luego es preguntar todas estas conexiones y nos quedamos con aquella tienda que tiene más conexiones con la otra cojamos el top y ese es el top recomendaciones para las tiendas, tampoco es algo excesivamente complicado, esto se llama coocurencias, es decir, la tarjeta la compra un cliente coocurre en dos tiendas esto lo podemos calcular en Hadoop con varios jobs y bueno, naturalmente esto hay que hacer cuantas mejoras, por ejemplo mejoras las tiendas más populares hay que eliminarlas en el mundo con plancarefour o mucha gente así que no es una recomendación que tenga mucho sentido hay que eliminar comercios que vendan demasiado también hay que hacer filtrado por categoría o por localización es decir, quiero ver tiendas o quiero ver comercios cercas de aquí y bueno, puedes calcular usar diferentes periodos, es decir usamos las coocurencias del último mes o del último año esto naturalmente lo hemos implementado en Hadoop hemos usado varios jobs para computarlo y bueno, el mayor reto que tenemos con este calculo de coocurencias es que si el número de tiendas en las que ha comprado una persona es muy grande el número de coocurencias a generar es cuadrático de tal manera que puedes plotar entonces te puedes encontrar con que tu proceso no pueda ir esto lo aliviamos limitando poniendo un máximo para esta gente que compra demasiado o que es excesiva o ponemos un límite y cogemos solamente los comercios o los que más ha comprado y bueno en el futuro queremos tratar de mirar coocurencias en espacios temporales limitados, es decir, si yo he comprado aquí y he comprado en otro sitio, en una hora justo después pues eso considero como coocurencia y no considero otras coocurencias y así probablemente salgan recomendaciones un poco más interesantes bueno, algunos números de esta solución hemos estimado más o menos esto es una estimación lo que necesitaremos para tener para manejar un año de datos de transacciones de tarjeta de crédito del BBVA y necesitaremos servir 270 GB con Voldemort esto se calcularía en el cluster de Hadoop con 24 instancias de tipo large en Amazon en unas 11 horas y el coste sería unos 3.500 euros al mes que me parece ya bastante razonable pero no estamos teniendo en cuenta que se pueden optimizar bastantes cosas que no estamos hablando de estas instancias reservadas y que probablemente fuera más barato si usas un cluster in-house y bueno, las conclusiones nos ha sido posible desarrollar una aplicación bitdeta para un banco con un número limitado de recursos no hemos necesitado muchísimos desarrolladores bastante rápido y gracias al uso de tecnologías digamos de nuevo cuño como puede ser el cloud de Amazon Hadoop y base de datos no de SQL y la solución que hemos llevado a cabo digamos que es escalable que permite agilidad a la hora de desarrollar y que está preparada para soportar errores humanos y el coste es bastante razonable y como digo quiero volver a poner en fases en que la mayor ventaja es que reacemos absolutamente todo siempre y esto es algo que también ha dicho el ponente dos anteriores que ha hablado de los datos de los morinos eólicos que una de las mejores y mayor ventaja que ellos sabían de la decisión que habían tomado es almacenar a todo Hadoop y tenerlo ahí para usarlo en el futuro y esto es un poco lo que hacemos nosotros nosotros tenemos todo Hadoop esto es la solución que hemos hecho ahora pero tenemos infinitas posibilidades para explotar esos datos en muchas maneras diferentes y no es doloroso hacerlo y el futuro bueno, el futuro como vemos esto Voldemort está bien pero es limitado no podemos realizar agregaciones en tiempo real tenemos que tenerlo todo precomputado y no se puede tener siempre todo precomputado porque por ejemplo los periodos que estamos ofreciendo son periodos fijos no podemos variar el periodo de hacerle más largo o más corto según no lo pida el usuario porque es que el espacio de datos a precomputar es tan grande que no sería posible así que nosotros hemos estado esto nos ha ocurrido con bastante más clientes y hemos desarrollado Splout Splout es lo mismo que Voldemort pero en SQL sigue la misma idea de Voldemort de generar los datos en Hadoop y luego servirlos en un cluster pero lo que hacemos es que tenemos bases de datos SQL en cada uno de los nodos así que es una base de datos SQL partitionada y de solo lectura con esto podríamos tener queries muchísimas más ricas en el frontend muchísimos más ricas por ejemplo podríamos realizar agregaciones en tiempo real podríamos tener todos los datos diarios, semanales y mensuales agregados pero podemos decirle al usuario como un calendario de que día a que día quieres la agregación y nosotros ahí podríamos agregando diferentes tablas podríamos realizando en tiempo real básicamente podríamos implementar un tipo de Google Analytics pero para el banco un tipo de aplicación así en el que quien entra en la aplicación puede seleccionar se le mueven, se le mueven gráficos etc y bueno la primicia es que lo hemos liberado y lo hemos liberado de hecho hoy como primicia para la conferencia así que si alguien quiere echarle un vistazo la cultura semanal lo vamos a evolucionar bastante más sobre todo con respecto al tema documentación etc pero bueno, queríamos liberarlo ya para que estuviese ahí presente para que si alguien quiere echarle un vistazo que lo echase y bueno, ya está es el tiempo un poco de preguntas espero que nadie se sienta como este hombre con el elefante Buenas, tenía dos preguntas primero, quería preguntarnos si en este proyecto en otros habéis trabajado ¿jojáis siempre con ficheros planos simplemente csv o habéis usado algún framework de serialización estilo afro y segunda pregunta la se podrías comentar las diferencias entre el pangool y algo como pig no se realmente hay cosas que hacéis con pangool que no se pueden hacer en pig vale la primera pregunta es la serialización las propias tuplas de pangool son serializables así que se pueden escribir y leer en discos y que todo el pipeline digamos que está usando estos ficheros entre medias pero es cierto que el primer fichero es un fichero con un formato bancario todo lo que tenemos ahí es un parser especial que es capaz de convertir ese fichero en tuplas así que la serialización digamos que la cubre pangool segunda, la diferencia entre pangool y pig pig es una librería de alto nivel entonces no solamente te permite realizar agregaciones etc. sino que digamos que tú escribes en un script todo tu flow de algún modo con un script se calcula los más radios exactos en los que se tiene que convertir ese trabajo sin embargo con pangool lo que haces es manejar desde bajo nivel es una librería tan bajo nivel como la de hadub digamos que en pangool por encima se podría implementar pig esto, la que flexibilidad nos ha dado meterlo todo en un job probablemente con pig no hubiera sido posible inventar tantas cosas solamente dentro de un único job a final digamos que nosotros vamos a hacer bajo nivel recomiendo pangool para quien quiera introducirse en la API de hadub por efecto que empiece con pangool porque es más complicado aprender más radios que pangool y luego si quieres usar algo de más alto nivel pues que lo use Hola, quería preguntar si no es muy largo de explicar el histograma adaptativo cómo se traduce a un job de MapReduce entendido que lo estabais haciendo así como un job de MapReduce es bastante más sencillo el job de hadub no calcula el histograma adaptativo calcula simplemente el histograma y el histograma puede ser por ejemplo 500 barras tu pones lo fijas a priori yo quiero un histograma que lo calcules de 500 barras eso si que lo va calculando el job de hadub bueno exactamente no, perdona el adaptativo es lo que calcula hadub entonces lo único que tu tienes en memoria 500 barras y según te va llegando un dato vas actualizando las barras y cuando comprimes el histograma adaptativo lo vuelcas los datos hacia la derecha o hacia la izquierda según quieras y al final lo que tienes el uso de memoria es constante y lo único que vas haciendo es recibir datos y actualizar el histograma cuando has recibido el último dato tienes el histograma calculado pero el volcado de un vaqueta a otro no implicaría actualizar claves que ya has emitido de la reducción si lo estoy interpretando totalmente mal es que el histograma se calcula para cada grupo hay múltiples histogramas calculadas en total no calculas un histograma total sino calculas pues para cada tienda un histograma y todo los registros de una tienda en el Rediose alguna última pregunta parece que no hay más pues muchas gracias Iván