Cocinando con Big Data Javier Sánchez BDM Big Data jsanchez@flytech.es 91.300.51.09 21/11/2013 Javier Sánchez 1
Agenda Qué es Big Data? Receta Punto de Partida Para qué Big Data? Conclusiones 21/11/2013 Javier Sánchez 2
Qué es Big Data? 21/11/2013 Javier Sánchez 3
Ingredientes - Datos Cocina - Cluster, Hadoop Cocinero Receta + + 21/11/2013 Javier Sánchez 4
Resultado 21/11/2013 Javier Sánchez 5
Ingredientes 3 Vs (Velocidad, Volumen y Variedad) Estructurados Semiestructurados Estructurados Hablamos de Big Data a partir de 1 TB de información. Logs, CDRs, Tweets, Operaciones bancarias 21/11/2013 Javier Sánchez 6
Cocina Tradicional Cocina BBDD Relacionales para pocos datos DW MPP para volúmenes grandes de datos Nuevas Técnicas y Tecnologías para inmensas Cantidades de Datos Por Lotes (Hadoop) On-Line (BBDD NoSQL, Storm ) 21/11/2013 Javier Sánchez 7
Cocina Cocina Tradicional La gente ya la conoce y sabe usarla Muchas herramientas de alto nivel que hacen fácil el análisis Online: las queries se resuelven más o menos rápidas (depende del volumen de datos y de los índices) No escala Esquema en escritura por lo que es poco flexible a cambios Se maneja mal con datos no estructurados 21/11/2013 Javier Sánchez 8
Cocina Nueva Cocina Escala Esquema en lectura (Muy flexible) Capaz de trabajar con datos no estructurados Difícil de encontrar capital humano Pocas o casi ninguna herramienta de alto nivel Poca madurez del SW Respuesta de queries en batches. No se soportan índices. Las queries tardan de minutos a horas 21/11/2013 Javier Sánchez 9
Punto de Partida Nueva Cocina Google necesitaba gestionar inmensas cantidades de información (page rank), lo cual era inviable tanto a nivel económico como tecnológico Solución: Crear un framework que resuelva el problema En 2003 publica White Papper sobre GFS. En Diciembre del 2004 Google libera Map and Reduce Doug Cutting en 2006 comienza oficialmente el proyecto Hadoop bajo licencia Apache 21/11/2013 Javier Sánchez 10
Hadoop Es un sistema para el almacenamiento y procesamiento de grandes cantidades de datos Escala Horizontalmente Almacenamiento (HDFS) Procesamiento (Map & Reduce) Plataforma Homogénea Commodity Servers Instalaciones con más de 4.000 maquinas Yahoo, Google, LinkedIn 21/11/2013 Javier Sánchez 11
Hadoop (HDFS) HDFS (Hadoop Distributed File System) Clúster de almacenamiento distribuido Múltiples copias de los datos Gran tamaño de ficheros Rebalanceo Alta Disponibilidad (Quorum Journal Manager o NFS) Poner la computación sobre el dato siempre es más económico que mover el dato (Share Nothing) Máquinas estándar! No RAID 21/11/2013 Javier Sánchez 12
Hadoop (Map & Reduce) Hadoop TRABAJA con procesamiento por lotes Los procesos no son en tiempo real aunque la explotación de los mismo si puede serlo La unidad básica de operación se denomina tarea (job) Un flujo (Flow) es una cadena de tareas Hasta que todas las tareas no han terminado, no se obtiene el resultado Cada tarea reescribe un fichero. El origen es un fichero y el resultado final es otro fichero. Plano: CVS, Texto Formatos Binarios 21/11/2013 Javier Sánchez 13
Hadoop (Map & Reduce) Ejemplo de tareas Fichero de entrada Transferencias bancarias Tweets Contenido de páginas web Fichero de salida Transferencia media cliente Trending topics por semana Índice invertido 21/11/2013 Javier Sánchez 14
Hadoop Particularidades No es tiempo real No es una BBDD Alta Barrera de Entrada (Cambio de Mentalidad) Todos son ficheros Se puede retorcer y desarrollar fácilmente (Ej. Fetcher, Índices Solar para Real Time) Abandonar el concepto de incrementalidad Ejemplo clics en web (BBDD+1 vs log histórico global) Es más eficiente y evita errores en BBDD Rehacerlo todo siempre en cada ejecución Cambio de dirección inmediata Ejemplo transacción media incremental vs todas las transacciones 21/11/2013 Javier Sánchez 15
Hadoop Hardware Comodity No se requiere hardware especial Ni en servidores Ni en almacenamiento Sin soluciones verticales Share Nothing Mueve el proceso a los datos (HPC se mueven los datos) Recuerden, Big Data nació para solucionar un problema que no era posible con soluciones verticales No escalabilidad Rigidez (Incrementalidad, alteración on-line de esquemas ) Alta incidencia de errores de programación (corrupción de estado ) 21/11/2013 Javier Sánchez 16
Hadoop 21/11/2013 Javier Sánchez 17
Ejemplo de solución (I) Empresa de retail Proyecto panel de compras personalizado por cliente Objetivo: Aumentar fidelidad Aumentar facturación con recomendaciones Ejemplo: Recomendar X a otros clientes que ya han comprado Y y Z. 21/11/2013 Javier Sánchez 18
Ejemplo de solución (II) Características Gastos por meses, semanas, Aderezos con gráficos Por familias de artículos u otros Artículos más comprados en oferta, artículos similares, complementarios Recomendaciones personalizadas partiendo no solo de sus compras, sino también del comportamiento de compra de otros compradores Capilarizadas por ejemplo por clima, fechas próximas señaladas, código postal 21/11/2013 Javier Sánchez 19
Ejemplo de solución (III) Solución clásica Realizar un proceso ETL (Extract, Transform and Load) diario desde un DataWarehose a una base de datos específica SQL para este servicio web Solo los datos nuevos Los DW no están preparados para servir online los datos, están preparados para servir query off-line 21/11/2013 Javier Sánchez 20
Ejemplo de solución (IV) Solución clásica Problemas Una base de datos a este nivel sería muy costosa, ya que manejaría grandes volúmenes de datos Posible incapacidad para manejar todos los datos (escalabilidad) Alto coste en hardware y almacenamiento Incrementalidad (no dispone de todos los datos) Alto riesgo de incidencias por fallo del programador Normalmente el proceso de transformación de datos ETL suele ser monopuesto, incidiendo en la capacidad de proceso de esa máquina durante la ejecución del ETL, además de no poder escalar A la BBDD en producción no se pueden inyectar diariamente grandes cantidades de datos, ya que afectaría negativamente el servicio ofrecido por la página web 21/11/2013 Javier Sánchez 21
Ejemplo de solución (V) Solución Hadoop Copia inicial de todos los datos al clúster HDFS Posteriormente copia diaria con los nuevos datos generados Procesamiento de todos los datos almacenados para todas las fechas en cada ejecución No hay incrementalidad, siempre disponemos del todo Hadoop calcularía las agregaciones mensuales, semanales, diarias, por horas, por familias, por producto, recomendaciones, etc. El resultado se volcaría en bases de datos NoSQL o SQL Pueden convivir ambos mundos de base de datos / DataWarehouse 21/11/2013 Javier Sánchez 22
Ventajas Hadoop Ejemplo de solucion (VI) Menores costes y riesgos Escala y se adapta a la escala Es maleable y menos rígido Disponer de todo y con un cambio de programación se obtiene cualquier resultado, mientras que con SQL cambiar la estructura de la base de datos en producción es muy duro y delicado Reduce la incidencia de un posible fallo de la programación Parte de un único fichero todo y el resultado siempre se genera desde cero Flexibilidad gracias al todo Se pueden tener múltiples clúster en paralelo y apuntar la aplicación al clúster concreto En los primeros prototipos no necesitas adquirir el HW, puedes trabajar desde Elastic Map Reduce en Amazon Cloud y, una vez probado, se adquiere el HW. A corto/medio plazo es más económico disponer de clúster propio HW común, no soluciones verticales Base de datos escalables y gratuitas 21/11/2013 Javier Sánchez 23
Conclusión Qué sucede cuando prescindimos del cocinero? 21/11/2013 Javier Sánchez 24
Conclusión Flytech Qué te puede aportar? 21/11/2013 Javier Sánchez 25
Conclusión Flytech Qué te puede aportar? 21/11/2013 Javier Sánchez 26
MUCHAS GRACIAS! Javier Sánchez BDM Big Data jsanchez@flytech.es 91.300.51.09 21/11/2013 Javier Sánchez 27