S wine_analytics wine_analytics MEMORIA Begoña Boloqui José Miguel Espinosa Mónica Manrique Carlos Valencia S wine_analytics S wine_analytics Introducción ............................................................................................................................... 3 Motivación.................................................................................................................................. 3 El Problema y la Oportunidad de Negocio ................................................................................. 4 Contexto ................................................................................................................................. 4 Definición del problema ......................................................................................................... 4 Oportunidad de Negocio ........................................................................................................ 5 Situación actual .......................................................................................................................... 6 Big Data y Analytics en el sector agroalimentario .................................................................. 6 Análisis de la competencia ..................................................................................................... 6 Nuestra propuesta...................................................................................................................... 9 Modelo de Negocio ................................................................................................................ 9 Propuesta de valor................................................................................................................ 11 Mapa Estratégico .................................................................................................................. 12 Balanced Scorecard .............................................................................................................. 13 Prueba de concepto ................................................................................................................. 14 Resultados ............................................................................................................................ 15 Marco Temporal ....................................................................................................................... 17 Solución Tecnológica ................................................................................................................ 19 Objetivo ................................................................................................................................ 19 Estrategia tecnológica .......................................................................................................... 21 Propuesta técnica a alto nivel .............................................................................................. 25 Fase 1- Adquisición de datos ............................................................................................ 26 Fase 2 - Procesado de datos ............................................................................................. 32 Fase 3 - Explotación y exportación de los datos .............................................................. 35 Patrón de arquitectura para la solución ............................................................................... 36 Soluciones para la Analítica .................................................................................................. 42 Herramienta de visualización ............................................................................................... 43 Análisis financiero..................................................................................................................... 43 Cuenta de resultados ............................................................................................................ 44 1 S wine_analytics Balance de situación ............................................................................................................. 47 Cash Flow .............................................................................................................................. 47 Rentabilidad .......................................................................................................................... 48 ANEXOS .................................................................................................................................... 50 Marco temporal – ciclo vegetativo de la vid ............................................................................ 51 Datos enológicos técnicos ........................................................................................................ 54 Comparativa de Bases de datos NoSQL ................................................................................... 57 Comparativa de Soluciones Big Data en Cloud ........................................................................ 96 Referencias (de los anexos tecnológicos)............................................................................... 114 2 wine_analytics S Introducción Wine_analytics es un proyecto innovador, que nace como proyecto final del Programa Ejecutivo en Big Data y Business Analytics 2014-2015. Esta memoria es el documento que explica detalladamente el proyecto wine_analytics y complementa el Resumen Ejecutivo del mismo. A través de este proyecto queremos aplicar los conocimientos adquiridos durante el programa, así como afianzar nuestras habilidades de comunicación y el trabajo en equipo. Además de los conocimientos mencionados, los principales componentes de este trabajo han sido la pasión y motivación que nos ha llevado en un principio a participar en este programa, así como la buena amistad desarrollada por este equipo a lo largo del curso. Motivación La industria de bebidas y alimentación es, junto al turismo, el primer sector industrial en España, y se erige uno de los principales motores económicos del país. En este contexto, la industria vinícola representa el 14% de toda la industria alimentaria española y supone el 1% del PIB. El vino español representa un factor importante en la imagen de nuestro país en el exterior y es una de las claves del éxito de España como destino del turismo gastronómico. Por todo ello es un sector de extraordinaria relevancia. Wine_analytics pretende aprovechar la analítica de inteligencia de negocio así como hacer uso de las tecnologías Big Data con dos objetivos principales: aumentar la eficiencia de los procesos, reducir la incertidumbre asociada a la toma de decisiones en una industria con fuerte dependencia de factores de difícil o limitado control, como es el caso del sector agroalimentario. Inicialmente se trata de un proyecto piloto interno de un grupo agroalimentario, centrado concretamente en la rama de la viticultura. Confiando en el éxito nuestro proyecto, el objetivo a medio y largo plazo es ampliarlo para que pueda utilizarse en otras áreas de negocio del grupo, tales como aceites, zumos o cafés y, en un futuro más lejano, ofrecerlo a terceras empresas del sector. 3 wine_analytics S El Problema y la Oportunidad de Negocio Contexto El grupo agroalimentario Pérez Cristóbal fue creado a finales del siglo XIX y se ha dedicado desde sus inicios a la manipulación y elaboración de productos agrícolas derivados. Está estructurado en varias divisiones: zumos, aceites, vinos, cafés y bebidas vegetales. El Grupo tiene su origen en el mundo del vino y es ahí donde es una referencia a escala mundial. A lo largo de su historia el Grupo se ha convertido en líder absoluto en los mercados de vinos y zumos en España. Es uno de los grupos de referencia de Europa y en este contexto es la segunda marca de zumos del continente. Su actividad comercial se extiende a más de 100 países de los 5 continentes, posicionándose en el quinto lugar a nivel mundial. Definición del problema Dentro de la división de vinos existen varias bodegas que producen vinos en distintas denominaciones de origen españolas. Entre ellas se encuentra Abadía de Haza, que está ubicada en el corazón de la Ribera del Duero y se basa en la variedad de uva autóctona Tempranillo para la elaboración de sus vinos. Esta bodega es la tercera del grupo por volumen de fabricación e ingresos y cuenta con varios tintos de diverso envejecimiento (roble, crianza, reserva y selección), posicionados en los tres canales de venta de la bodega: alimentación moderna horeca (hoteles, restaurantes y cafeterías) exportación El excedente de uva que no alcanza la calidad exigida por la dirección técnica de la bodega se vende a terceros, lo que supone un máximo del 10% del total de la producción de tempranillo. A pesar de la calidad extraordinaria de los vinos de esta bodega, Abadía de Haza se enfrenta a varios problemas: mejorar la uva de máxima calidad. Actualmente, ésta se sitúa en un 10% de la producción. Esta uva tan demandada es la que le confiere a los vinos de Abadía de Haza una marca distintiva que le ha hecho históricamente destacar y ser líder en el mercado; la consolidación de sus vinos Premium en restaurantes; 4 wine_analytics S la penetración en mercados americanos (Estados Unidos, México y Brasil principalmente), para cualquiera de sus vertientes, especialmente los de mayor envejecimiento (crianza, reserva y selección). La dirección del grupo es exigente con todas las divisiones y en especial con el sector del vino, que como ya hemos mencionado, fue el origen de este grupo empresarial. Por este motivo necesita posicionar adecuadamente sus vinos de alta gama (reserva y selección). Su ficha de cata destaca que son caldos complejos, con aromas intensos donde la fruta roja madura toma protagonismo, junto con notas de crianza muy expresivas, con clavo y cacao. Teniendo en cuenta los problemas arriba mencionados, el grupo pretende abrir una nueva etapa apostando por estos vinos de máxima calidad, a la vez que mantiene los vinos ya existentes. Oportunidad de Negocio Probando una serie de técnicas y tecnologías, se ha considerado que la producción de vino se puede mejorar notablemente en calidad y en su inclusión en los mercados donde no tiene la presencia y visibilidad requeridas. En una segunda fase se podrá utilizar y capitalizar ese conocimiento para otras divisiones del grupo e incluso venderlo como servicio a terceros. En este momento el grupo está abordando una serie de proyectos considerados “transversales” y que combinan recursos y personas de las distintas divisiones con el fin de encontrar sinergias significativas y que apuesten por la mejora continua de procesos y productos en los distintos frentes. Con la ayuda de unos asesores externos al comité de dirección, se decide establecer un equipo de trabajo entre distintos especialistas del grupo para aprovechar las capacidades innovadoras de Big Data y la analítica avanzada. Para el proyecto wine_analytics, que lidera personalmente el Director Financiero de la Compañía, este equipo está compuesto por: Carlos Valencia: Director Financiero del Grupo ya citado anteriormente José Miguel Espinosa: Corporate IT Manager del Grupo y especialista en BI Begoña Boloqui: Analista Senior de Datos y especialista en modelización del área de vinos Mónica Manrique: Analista Senior de Datos y de Investigación de Mercados de la división de Zumos 5 wine_analytics S Situación actual Big Data y Analytics en el sector agroalimentario El uso de tecnologías de la información es crucial para mejorar la competitividad y productividad, así como para ayudar en la toma de decisiones. Siendo esto muy común en sectores como el financiero o el marketing, en muchos otros ámbitos queda todavía un largo camino por recorrer. Uno de ellos es el sector agroalimentario, cuyos procesos son muy mejorables si se aplican las TIC. En la actualidad comienza a visualizarse la revolución que puede significar el Big Data para el sector de la agricultura. Las tecnologías actuales ya permiten recoger, gestionar y extraer información en tiempo real de las observaciones de la tierra y de sus sistemas naturales. El coste de recoger la información ha descendido drásticamente, y de la misma manera ha aumentado nuestra capacidad para procesar dicha información. Las empresas y los gobiernos empiezan a abordar algunos de los mayores retos explotando esta información, que hasta ahora no era accesible. Análisis de la competencia En el marco del sector agroalimentario están surgiendo en todo el mundo soluciones de monitorización del estado del cultivo (con redes de sensores), herramientas con análisis de imágenes (GIS) para estudiar el estado del cultivo y herramientas de ayuda en la toma de decisiones. Algunos ejemplos son: Bynse: es una solución Big Data para la agricultura y ha sido desarrollada por la empresa española Cubenube, especialista en el desarrollo de sistemas de datos e información en Cloud. La familia de productos Bynse permite controlar, desde cualquier dispositivo con conexión a Internet, el estado actual y las necesidades futuras de sus cultivos, desde el punto de vista suelo-planta-clima1. Siega: es un sistema basado en una red de sensores que, conjuntamente con una aplicación informática, permite monitorizar en tiempo real una serie de variables para realizar agricultura de precisión. La gestión de cultivos basada en la agricultura de precisión engloba actividades de monitorización, sistemas de soporte para la toma de decisiones o un medio 1 Fuente: www.bynse.com 6 wine_analytics S para la realización de determinadas acciones que controlen automáticamente sistemas de riego, fertilización o uso de pesticidas2. VineAlert: Proyecto del Cool Climate Oenology and Viticulture Institute (CCOVI), Universidad de Brock (Canadá). Es una base de datos online interactiva que provee información de niveles comparativos de resistencia de los brotes en diferentes lugares a lo largo del periodo inactivo o de dormición. Ayuda a los viticultores a gestionar el daño del invierno sobre el cultivo, a través de la monitorización del nivel de resistencia al frío de los brotes. El muestreo y análisis ocurre durante todo el período de dormición y los datos obtenidos ayudan a determinar cuándo es necesario tomar medidas para evitar la congelación y prevenir el daño de la uva. Los productores pueden personalizar los datos que quieren recibir del sistema y se les notifica cuando hay nuevos datos disponibles o reciben alertas cuando es probable que se vayan a alcanzar temperaturas críticas. Más de 250 productores están suscritos y la web tiene usuarios en Canadá, USA y en todo el mundo3. Mavrx: La empresa Mavrx se dedica a recopilar y organizar la información física de nuestro planeta. Provee herramientas y plataformas para conectar las infraestructuras ya existentes con la información del planeta desde el suelo hasta el espacio. Mavrx construye y utiliza sensores, Big Data y sistemas informáticos para ayudar al mundo a gestionar la tierra más eficientemente. Actualmente ofrece servicios de captación de imágenes y mapeo de viñedos en California y Sudáfrica4. Fuition Sciences: ha desarrollado una tecnología que "escucha" las necesidades de agua de la vid. Esto se hace mediante la evaluación de la cantidad de agua que la vid está transpirando (pérdida de agua) a través de sus hojas y por medio del monitoreo de flujo de savia. Esta tecnología ayuda a decidir cuándo y cuánto regar con precisión midiendo el consumo de agua de las viñas5. VinTank: es una plataforma de escucha de redes sociales centrada específicamente en gente interesada en el vino, que es una de las ocho categorías de las que más se habla online (junto a gastronomía, viajes, música, cine, restaurantes y software). Ayuda a los viticultores a entender el comportamiento online de los clientes para hacerse una idea de quién es quién en cuanto a sus preferencias de vinos. El software monitoriza cualquier conversación sobre 2 Fuente: www.siegasystem.com Fuente: http://www.ccovi.ca/vine-alert 4 Fuente: http://www.mavrx.co/product/vineyards/ 5 Fuente: http://www.fruitionsciences.com/es/login/home 3 7 wine_analytics S vinos en más de 4500 marcas de vino en todo el mundo, ayudando así a las bodegas a gestionar las escucha en redes sociales. A través de un dashboard se añade una capa de gestión de Social Media que permite conectar las transacciones directas del cliente con las cuentas de la compañía6. GMV: Proporciona servicios de consultoría e ingeniería, así como de desarrollo de software y hardware, integración de sistemas llave en mano y soporte a las operaciones. Entre las soluciones, dentro del contexto agroalimentario cabe destacar Wineo (Weather INformation and Earth Observation), un sistema de observación de la Tierra por el que, mediante imágenes captadas por satélite, se procesa la información obtenida generando un sistema de ayuda inteligente para la agricultura de precisión7. También existe un número limitado de empresas que proporcionan servicio de analítica técnica a nivel de laboratorio o consultoría de servicios para sectores agrícolas. Estas empresas tienen su foco no solamente en el sector agroalimentario, sino agrícola en general, así como aguas y medio ambiente. Algunos ejemplos son: Gemasbe Analítica8: consultoría y asesoramiento técnico en el sector agroalimentario. Presta asistencia en las fases de diseño, implantación y dirección técnica en las empresas del sector agroalimentario; también desarrolla actividad como Laboratorio Químico Agroalimentario. Su campo de trabajo se basa tanto en las actividades de Analíticas y Consultorías, y quedan recogidos por los sectores Agrícola, Enológico, Alimentario, Aguas y Medio Ambiente. Biotechveg9: ofrece al sector agroalimentario servicios analíticos, asesoramiento técnico e investigación y desarrollo. Ofrece a sus clientes datos e información técnica sobre sus productos agroalimentarios de sus clientes, de los que se requieren controles analíticos cada vez más exhaustivos. Provee servicios de microbiología de alimentos (incluyendo microbiología predictiva), análisis de alimentos, análisis de aguas, control de plagas, análisis, análisis fitopatológicos y microbiología ambiental. LAB (Laboratorio Analítico Bioclínico)10: su objetivo principal es proporcionar una respuesta integral a las necesidades analíticas requeridas por los sectores agroalimentario, ambiental, 6 Fuente: www.vintank.com/wineries/ Fuente: http://www.gmv.com/en/ 8 Fuente: http://www.gemasbe.es/ 9 Fuente: http://www.biotechveg.com/es/biotechveg/ 10 Fuente: http://www.lab-sl.com/index.php/es/ 7 8 wine_analytics S industrial y bioclínico. Los servicios analíticos se centran en el sector agrario, alimentario, medio ambiente, industria y otras instalaciones de riesgo biológico. Nuestra propuesta proporciona una solución completa para el cliente, mientras que las soluciones y compañías mencionadas anteriormente se enfocan en propuestas de valor específicas, especialmente de tipo Locking y Product Leadership11. Wine_analytics aúna varios servicios a lo largo de toda la cadena de producción, desde el mismo campo hasta el análisis de resultados de campañas de marketing, incluyendo datos de Redes Sociales. Esta propuesta de valor queda enmarcada dentro de la tipología Solutions, frente a sus competidores potenciales más directos. En un contexto internacional, la estadounidense Gallo ha sido pionera en este campo, destacando durante la InformationWeek en 2004, con el lanzamiento de APEX. Se apoya en el uso de tecnologías de la información junto con la viticultura, así como la analítica para tomar decisiones basadas en datos. Gallo cuenta con más de 500 TB de datos, que incluyen información sobre las cosechas y variedades de la uva que utiliza, las marcas que produce, los detalles sobre los hábitos de compra de sus distribuidores, entre otros. También incluyen información del punto de venta al por menor y datos de terceros, como el IRI y Nielsen, lo cual le permite también conocer comprándolos hábitos de consumo y las tendencias locales y regionales. Nuestra propuesta Modelo de Negocio Wine_analytics es una iniciativa del Grupo Pérez Cristóbal para mejorar la comercialización de varios vinos de la bodega Abadía de Haza, tanto en canales Horeca como en mercados exteriores, optimizando costes y mejorando la producción de uva y su calidad. Este modelo de negocio parte como un proyecto dentro del Grupo, que se escindiría del mismo una vez logrado el éxito en sus objetivos, exportando la analítica equivalente a otros sectores del grupo (como zumos y cafés), así como intentar crecer con otros clientes y rentabilizar el KnowHow adquirido. El objetivo del sistema contemplado es en primer lugar una mejora de la producción del vino Abadía de Haza Selección. Esto es posible aumentando la producción de uva de máxima calidad 11 Artículo: Strategy Maps, Converting Intangible Assets into Tangible Outcomes (Robert S. Kaplan and David P. Norton) 9 wine_analytics S del 10% al 12%, lo que implicaría un 20% de la producción de vino. En segundo lugar se busca el posicionamiento en restaurantes de dicho vino y su entrada en los mercados estadounidense, mexicano y brasileño. Tras múltiples estudios y análisis, se ha concluido que las principales variables que inciden en la calidad de la uva son las climatológicas, además de la propia calidad y antigüedad de la cepa, que serían parámetros dados. El impacto de la climatología en la producción se convierte en el principal factor a controlar, y para ello el enfoque sigue la siguiente secuencia: Predicción de eventos y condiciones climatológicas y biológicas: se implantarán estaciones meteorológicas y otros sensores contemplándose asimismo la incorporación de datos procedentes de imágenes de satélite y de otras fuentes, que permitan anticipar las condiciones y tomar las medidas oportunas, además de hacer un mejor seguimiento del riesgo de plagas. Medición y análisis del impacto de dichas condiciones en los parámetros de calidad y producción de la uva de máxima calidad: se pretende modelar el output de esta uva en función de las condiciones climatológicas. Esto se hace con el fin de lograr anticipación, planificar mejor la producción y gestión, y facilitar la comercialización del vino, gracias a una mayor garantía de calidad y homogeneidad del mismo. Aplicación de medidas correctivas: se aplicarán una serie de medidas con el objetivo de regular estos impactos climatológicos. En este sentido, se contemplan soluciones mitigantes tales como aerogeneradores o cobertura de viñas, en el caso de heladas; optimización del uso de químicos, en relación con el riesgo de plagas; optimización de fechas de recogida y vendimia, etc. El foco principal del modelo son las uvas de máxima calidad, que son las que harán destacar Abadía de Haza Selección sobre el resto de sus competidores. Respecto a la uva de calidad estándar, estas mismas acciones también son factibles y se llevarán a cabo. Como ya hemos comentado, la analítica y la anticipación resultarán actividades clave en la solución propuesta, pues serán los instrumentos principales de control de la producción y de la calidad. 10 wine_analytics S Propuesta de valor La propuesta de valor consiste en el desarrollo de una solución adicional al Business Intelligence ya existente en Pérez Cristóbal, y en la implantación de un nuevo sistema analítico que complemente a la anterior solución, proporcionando información clave para la gestión y control tanto de los procesos como de la logística y del producto final. Los valores de esta propuesta son múltiples, ya que permite optimizar la calidad tanto de la producción como del producto final. Ello se logra minimizando mermas mediante actividades como la monitorización varios de los procesos de la cadena de valor, el seguimiento de las condiciones medioambientales y de las vides; pero también se busca una mejora efectiva en la distribución de los distintos vinos, gracias al nuevo sistema analítico, que se convierte en un activo en sí mismo para la bodega. La nueva información que se pretende recoger con el desarrollo del Business Intelligence entra dentro de la clasificación Big Data al considerar algunas de las características básicas sobre la naturaleza de los datos: Su variedad: se trata de datos estructurados, semi-estructurados y no-estructurados; Su velocidad: necesaria para un tratamiento en tiempo real de determinadas mediciones críticas, desde la fase de maduración de la uva hasta la elaboración de los caldos; Su volumen: aunque ya con un menor impacto. Los nuevos datos capturados pueden definirse como estructurados, semi-estructurados y no estructurados, y provienen de la instalación de múltiples sensores capaces de recoger información en tiempo real y accesible vía web sobre múltiples parámetros críticos del terreno, de la vid y/o ambientales. Estos aspectos se explicarán con más detalle en el apartado Solución Tecnológica. En fases posteriores de la cadena de producción se contempla implantar dispositivos en la bodega para medir elementos críticos que afectan directamente a la calidad del vino durante su proceso de elaboración. Finalmente la integración de datos de geolocalización en la distribución, junto con los datos del ya mencionado BI, permitirá identificar los puntos críticos para optimizar la logística de distribución del producto a los clientes finales. 11 wine_analytics S El modelo de negocio se traduciría en los siguientes aspectos clave identificados en el siguiente Canvas. Mapa Estratégico Tomando como referencia la definición de Mapa Estratégico planteada por Kaplan y Norton12, construimos el mapa de nuestro proyecto teniendo en cuenta sus cuatro perspectivas. Los distintos valores de la propuesta se plantean en una hoja de ruta que permite definir las acciones necesarias para el cumplimiento de los objetivos planteados dentro de la estrategia para esta iniciativa 1. Perspectiva de Conocimiento: contemplamos el Business Analytics como el foco de nuestro modelo de negocio. Este permite aportar mucho más valor añadido que un simple Business Intelligence. Dada la vocación de crecimiento, este modelo de negocio que se plantea desarrollar precisará de una clara orientación internacional para lograr su expansión. 2. Perspectiva interna: la eficiencia y el respeto medioambiental serán esenciales para lograr desarrollar el proyecto en los términos planteados. La calidad y la orientación al cliente también formarán parte de las cuestiones estratégicas a garantizar en todo 12 Artículo: Strategy Maps, Converting Intangible Assets into Tangible Outcomes (Robert S. Kaplan and David P. Norton) 12 wine_analytics S momento. Como dimensión interna fundamental, es necesaria la capacidad de penetrar en otros sectores agroalimentarios para replicar el modelo desarrollado en vinos. De esta forma se podrá extrapolar a otras áreas en las que se puedan aprovechar equivalencias y sinergias que permitan desarrollar este modelo analítico. En este sentido, sectores como el aceite de oliva, los zumos o cafés son los planteamientos iniciales de expansión. 3. Perspectiva del cliente: Abadía de Haza es el piloto, y en este marco se busca mejorar la reputación y el posicionamiento como bodega mediante los vinos reserva y selección, así como aumentar el valor añadido en la cadena. 4. Perspectiva de finanzas: el objetivo es posicionarnos como líderes en Analytics para el sector agroalimentario, y apostar por la expansión internacional para lograr el ritmo de crecimiento deseado. Cabe también destacar la disminución significativa de los costes de producción basado el conocimiento de cada punto de la cadena de suministro. Balanced Scorecard Permite medir cuantitativamente el cumplimiento de los objetivos planteados en el mapa estratégico, de modo que si alguna de las mediciones no refleja los resultados esperados, podrán 13 wine_analytics S o bien tomarse acciones correctivas al respecto o flexibilizar la estrategia planteada a través del mapa estratégico, para hacerla sostenible en el tiempo. Los principales Key Performance Indicators (KPI’s) a los que hacer seguimiento se podrían clasificar en los siguientes grupos: KPI’s relativos a eficiencia en costes: consumo de agua, cantidad de uva producida para el nivel de calidad requerido, mermas en la elaboración de vino; KPI’s relativos a calidad de la uva: grado de maduración, niveles de fructosa y agua, momento óptimo de cosecha; KPI’s relativos a las características del vino: grado alcohólico, intensidad del sabor a madera, fruta, etc.; KPI’s relativos a la logística: geolocalización de ventas, análisis de riesgo de roturas de stock. KPI’s relativos al sentimiento del mercado respecto al producto: valoración en redes sociales y blogs especializados; percepción de calidad en los diferentes mercados. Prueba de concepto Con el fin de comprobar que nuestra solución es viable se llevó a cabo una prueba de concepto con fecha 20 de diciembre de 2014 en las bodegas y viñedos de Abadía de Acón. La prueba de concepto incluyó una reunión in-situ con los directores técnico y comercial para conocer en detalle el proceso de elaboración de sus vinos. En esta prueba se determinaron los parámetros que definen una uva como de máxima calidad y se identificaron una serie de factores que potencialmente podrían explicar las variaciones de dichos parámetros. Los técnicos de la bodega señalaron al clima como principal aspecto a analizar. De esta manera, se cruzaron mediciones de los parámetros de calidad de uva para una muestra periódica representativa del viñedo con diferentes variables climáticas, con el fin de evaluar el impacto de las mismas. De acuerdo con los primeros resultados obtenidos se concluyó que nuestro proyecto podía ser implantado para cumplir los siguientes objetivos: determinación precisa de la fecha óptima para vendimiar (en cada parcela) 14 wine_analytics S mejor planificación de la producción, anticipando necesidades fitosanitarias e hídricas en los viñedos en función de la variabilidad climática y optimizando fechas para su aplicación Después de conocer cómo este tipo de proyectos puede contribuir significativamente a resolver sus problemas y posicionar mejor sus vinos, el equipo de Abadía de Acón se mostró muy interesado en implantar la solución wine_analytics en su bodega. Durante los últimos meses hemos mantenido el contacto con ellos y nos han provisto de información muy valiosa para el proyecto, tanto técnica enológica como financiera. De la misma forma, a nivel tecnológico se ha desplegado un laboratorio en donde hemos podido probar el stack tecnológico que soporta toda la solución propuesta. Así, se han descartado alternativas que fueron apareciendo en nuestro horizonte mientras se diseñaba la solución, de modo que el resultado obtenido es el más apropiado para este caso de uso. Resultados Los resultados de esta primera prueba fueron positivos a pesar de que la base de datos construida para este objetivo era limitada en cuanto a registros históricos. Es por ello que lo que se buscaba era la confirmación de la relevancia de determinadas variables climáticas, más que la precisión de un modelo analítico Se concluyó un relevante poder explicativo de variables como las temperaturas mínimas absolutas durante los últimos tres meses antes de la vendimia (variable x2), de las precipitaciones durante el primer trimestre del año (variable x4), y del número de días de tormenta dos meses antes de la vendimia (variable x7). 15 wine_analytics S La metodología de modelización utilizada en esta prueba de concepto fue una regresión lineal multivariante. Si bien estas variables poseen correlaciones individuales significativas, no se puede considerar que, a pesar de ello, las correlaciones fueran altas. El modelo elaborado arroja valores razonables en cuanto a probabilidad, cercanos a la significancia (0,10), aunque un poco más alejado para el caso del intercepto. El p-valor de 0,2157 no es garantía de precisión, pero sí de que las variables consideradas de algún modo tienen relevancia destacable en la producción de vino que cumpla los criterios de calidad objetivo, como ocurre también con el estadístico t. El dato que a priori más podría generar optimismo es el dato que razonablemente sería el más engañoso: la bondad del ajuste, que es de 0,971. Este grado de bondad no puede considerarse real, pero verdaderamente, con los objetivos iniciales planteados de búsqueda de indicios, sí podría confirmar que de algún modo estas variables tienen poder explicativo. De acuerdo con estos primeros resultados, y en base a la experiencia del equipo técnico, se considera que con adecuada y puntual información sobre dichas variables, pueden ser posibles diferentes objetivos: determinación más exacta de la fecha más adecuada de vendimia, anticipándose a heladas, granizos o tormentas que pudieran afectar negativamente a la producción. 16 wine_analytics S mejor planificación de la producción, anticipando necesidades de los viñedos (agua, abonos, químicos, etc.) en función de la variabilidad climática y optimizando fechas para su aplicación. Abadía de Haza se enfrenta inicialmente a un problema de eficiencia en la producción de vino en base a uvas de máxima calidad: apenas el 10% de la producción de uva alcanza los parámetros de calidad requeridos para estas uvas de máximo prestigio, que confieren a los vinos de Abadía de Haza una distinción sobre el resto de sus competidores. Por lo tanto, el hecho de aumentar la producción de éste tipo de uva representa uno de los factores clave a optimizar para la mejora de los ingresos. Cabe destacar que el 90% de la producción de uva también es utilizada en la producción, pero su precio es tres veces inferior al de esa uva de máxima calidad. Se estima que el logro de los objetivos mencionados anteriormente podría permitir mejoras en la cantidad de producción de uva de máxima calidad superiores al 30%. En este sentido, y siendo más conservadores en virtud de las limitaciones de la prueba de concepto, se plantea como objetivo aumentar al 12% el total de uva de alta calidad, lo que permitiría un aumento de la producción de vino con mayor margen del 20% (vinos reserva y crianza). Con los datos actuales de uva de máxima calidad, en torno a una producción actual del 10%, el objetivo del 12% se considera como factible y realista, si bien sujeto a un análisis coste / beneficio para evaluar si las tecnologías aplicables al proyecto permiten una mejora de rentabilidad real del mismo. Marco Temporal Para el marco temporal del proyecto lo más importante a tener en cuenta es el ciclo de la vid, ya que ello va a determinar el momento en el que es crucial y pertinente tanto empezar a recolectar datos como a mostrar resultados. No es posible empezar el proyecto en cualquier época del año, ya que la vid pasa por un ciclo vegetativo anual con unos periodos muy definidos y reconocibles. Wine_analytics es por lo tanto un servicio estacional. 17 S wine_analytics El ciclo biológico anual de la vid comienza al principio de la primavera cuando, pasadas las bajas temperaturas del invierno que provocan la parada invernal, la savia empieza a sangrar por los cortes de la poda. Cuando las temperaturas medias llegan a los 10º C, entre marzo y abril, se produce el desborre o brotación de los pámpanos (nacimiento anual), que siguen creciendo hasta el mes de agosto. La principal preocupación de viticultor una vez producida la brotación es que no hiele. Si hiela se mueren los brotes, lo que puede reducir mucho la cosecha hasta casi desaparecer. Con la aparición de los brotes comienza la etapa de crecimiento anual de la planta, que dura hasta el envero (final de julio). El detalle del ciclo vegetativo de la vid está detallado como Apéndice. Como acabamos de detallar, es necesario enmarcar el comienzo del proyecto como mínimo 8 meses antes de la época de vendimia, es decir, en torno al mes de enero. Esto se debe a que la instalación de los sensores debe realizarse antes de que se produzca el desborre, es decir aproximadamente en el mes de marzo. En este punto del proyecto deben estar definidos tanto los requisitos del agricultor (cliente) los objetivos del proyecto. También debe estar montada la plataforma tecnológica, de modo que los sensores puedan empezar a recoger datos en cuanto se detecte la brotación, La fase de escucha y análisis de datos de Redes Sociales se puede llevar a cabo en paralelo desde el mismo momento en el que la plataforma funciona y permite la recolección de datos. De igual modo no es necesario esperar a la brotación para empezar a trabajar con los datos climatológicos. Se pueden ir analizando y creando modelos utilizando los históricos de años anteriores. Las fases del proyecto serán las siguientes: 18 wine_analytics S Definición de los requisitos de la división (bodega) 1 mes Definición de los objetivos del proyecto 2 semanas Implantación de la solución tecnológica (incluye integrar solución con BI corporativo) 2 meses Instalación de sensores y dispositivos en campo (viñedo), línea de producción (bodega) y línea de embotellado 2 semanas Puesta en marcha de campañas de marketing digital 1 mes Creación y entrenamiento del modelo predictivo en base a los datos existentes 1 mes Fase de prueba del modelo 2 semanas Correcciones del modelo (si son necesarias) 2 semanas Prueba de la solución integral 2 semanas Despliegue de la solución y puesta en producción 3 semanas Fase de control y soporte desde puesta en producción hasta fin de proyecto Fin de proyecto 0 5 10 15 Semana 20 25 30 35 1.Definición de los requisitos de la división (bodega) 2.Definición de los objetivos del proyecto 3.Implantación de la solución tecnológica (incluye integrar solución con BI corporativo) 4.Instalación de sensores y dispositivos en campo (viñedo) 5.Puesta en marcha de campañas de marketing digital 6.Creación y entrenamiento del modelo predictivo en base a los datos existentes 7.Prueba del modelo 8.Correcciones del modelo (opcional) 9.Prueba de la solución integral 10.Despliegue de la solución y puesta en producción 11.Fase de control y soporte Solución Tecnológica Objetivo Se pretende realizar un sistema de soporte a las decisiones para la optimización de los trabajos en el viñedo así como en la producción de uva para la mejora general de los vinos producidos y en particular para resolver los problemas que se han identificado en esta bodega y que dan lugar a un importante proyecto transversal dentro del grupo Pérez-Cristóbal. En bodega o nave, los sistemas tradicionales soportan bastante bien la recogida de información y la automatización de sistemas electromecánicos a través de dispositivos y técnicas ampliamente y, desde hace tiempo, usadas en la industria como autómatas programables, electroválvulas y 19 S wine_analytics controladores lógico programables (PLC’s) u otros dispositivos para la gestión de alarmas normalmente vinculados a la ingeniería eléctrica y/o mecánica. Para el caso de los trabajos en el campo y con el actual desarrollo y expansión de los sistemas de gestión de información heterogénea y masiva de datos aparecen interesantes alternativas vinculadas a la ingeniería informática que permiten la recogida y el tratamiento de esta información en tiempo y forma para la toma de decisiones. El propósito de la solución wine_analytics se centra, por un lado, en hacer agricultura de precisión que permita a los gestores una mejor toma de decisiones y anticiparse a determinados eventos fundamentalmente climáticos y fitosanitarios a través de la monitorización de los cultivos, predicción de las cosechas y estimación del uso de productos fertilizantes y necesidades de riego. La agricultura de precisión se ha convertido en una nueva forma de gestionar la información sobre cultivos y cosechas, frente a métodos tradicionales de agricultura. Se ha impulsado su crecimiento a partir de los avances en tecnología mediante sensores remotos, sistemas GIS, etc., conceptos hasta ahora aplicados a otros campos industriales y ahora inmersos en sistemas agrícolas avanzados. Dada la extensión agrícola de todos los campos con los que trabaja el grupo Pérez Cristóbal la toma de imágenes por satélite es un servicio con el que ya cuenta el grupo empresarial, tanto para los campos en arriendo como en propiedad. El beneficio de este servicio se torna rentable a partir de grandes extensiones, en torno a las diez mil hectáreas. En este contexto wine_analytics contará con esta fuente de información, que será volcada junto con las fuentes que se explicarán más adelante. Asimismo utiliza también datos meteorológicos que mejoran la toma de decisiones en aspectos tan relevantes para la agricultura como son la necesidad de regadío o momento de recolecta, reduciendo el consumo de agua, pesticidas y fertilizantes, minimizando tanto la huella de carbono, como el impacto de pesticidas en los productos agrícolas. Por otro lado, wine_analytics tiene el propósito de obtener información a través de las Redes Sociales de las campañas de marketing digital que el departamento de Marketing de la bodega y del grupo van a poner en marcha como parte de la estrategia corporativa así como de los resultados de comercio electrónico. 20 wine_analytics S La idea fundamental descansa en la utilización de datos de diferentes fuentes, siendo las más determinantes las mediciones microclimáticas que realizará el sistema de sensorización. Estas mediciones se procesan junto con predicciones y mediciones meteorológicas, registros de labores, enfermedades, consumos y otros tipos de datos con una solución tecnológica, que permite analizar a gran velocidad esa cantidad de información tan heterogénea, y obtener información, conocimiento y conclusiones valiosas que lleven a mejorar la toma de decisiones y la productividad de nuestros cultivos. Estrategia tecnológica En uno de los comités de operaciones del grupo se aprobó abordar el proyecto como un transversal a la organización en forma de piloto para comprobar su viabilidad y posibilidades de aplicación a otras empresas y negocios del grupo (fincas de olivares, naranjos, etc.). Por lo tanto la estrategia del grupo consiste en probar a través de este piloto las bondades de las soluciones propuestas por el equipo de trabajo y extrapolarlas a otros negocios del grupo para capitalizar las inversiones tanto económicas como de capital humano. Por otro lado, la estrategia del equipo de trabajo elegido para generar información que permita a la bodega ahorrar costes, mejorar su producción y elaborar unos mejores caldos se fundamenta en los siguientes pasos: Sensorizar los microclimas de las fincas y parcelas. Procesar los datos de los sensores con los de los servicios de predicción meteorológica y con los registros introducidos por los técnicos de la bodega y del consejo regulador, para obtener las necesidades actuales y futuras de los cultivos. Informar mediante la puesta a disposición para los gestores de la bodega y, de cualquier persona relacionada con los cultivos, a través de un servicio de información en la nube, que les permita gestionar la información generada en cualquier PC, tablet o smartphone a través de una conexión a Internet, con informes, gráficos, mapas, alarmas, etc. que permita gestionar ágilmente cualquier necesidad de los cultivos. En concreto la solución tecnológica estará focalizada en ayudar en dos frentes: Reducir las pérdidas de producción por eventos climáticos dañinos, permitiendo adelantarse a heladas, granizos, altas temperaturas, etc. 21 wine_analytics S Reducir los fitosanitarios aportados a los cultivos, empleando algoritmos y modelos de predicción de plagas y enfermedades para, en función del riesgo futuro, realizar los tratamientos pertinentes. Adicionalmente la solución tecnológica podrá también ayudar en: Reducir los costes de producción con información sobre el crecimiento, la gestión y la planificación de labores y los recursos asociados, etc. Reducir el uso de agua para el caso de las espalderas, ya que será capaz de cuantificar por microclimas las necesidades hídricas actuales y futuras, porque tiene en cuenta tanto los datos a nivel de planta (temperatura, humedad ambiente, estrés hídrico) como los datos a nivel de suelo (capacidad de campo y contenido volumétrico de agua). A continuación se van a detallar los pasos anteriormente mencionados que determinan la estrategia de generación de información sobre la que descansa la arquitectura del sistema informacional propuesto y su posterior integración con los sistemas de información del grupo. 1 Sensorizar La idea se basa en medir y cuantificar las diferencias micro climáticas existentes en fincas y parcelas. Éstas presentan, obviamente, frecuentes irregularidades en el terreno dentro del mismo viñedo así como desniveles orográficos que se revelan determinantes ante algunos fenómenos climáticos como las heladas. Para cuantificar estos microclimas, los sensores obtienen ciertas mediciones pero no las procesan para ello se requiere un micro controlador por medio del cual se definen parámetros, como por ejemplo la frecuencia de envío. Por otra parte, se necesita un elemento para transmitir los datos, el módulo de comunicaciones, que podría utilizar conexiones GPRS, 3G/4G, M2M, Wifi, Ethernet… El tamaño de información que se enviará dependerá de: Cantidad de sensores en un punto de medición. Cantidad de puntos de mediciones, en cuántos puntos queremos medir. Periodicidad de información, cada cuánto queremos tomar una medida. 22 wine_analytics S Previo a la instalación de los sensores en campo, se realizará un análisis sobre las fincas y parcelas, para delimitar las zonas con diferentes microclimas a las cuales se las denomina celdas. En función de la orografía, el tipo de suelo, el tipo de vid, etc. las celdas pueden abarcar una superficie diferente. En cada celda se instalan los sensores y las configuraciones adecuadas para la necesidad que se desea cubrir. Vamos a usar dos configuraciones en función de las diferentes necesidades: Configuración climática: desarrollada para predecir los riesgos meteorológicos como heladas, granizo, altas temperaturas, etc. Configuración enológica: diseñada para cuantificar las necesidades hídricas y optimizar las políticas fitosanitarias, basándonos en la evapotranspiración (ETP), el déficit de presión de vapor (DPV) y las propiedades físico-químicas del terreno. Los sensores actuales para este tipo de trabajo presentan compatibilidad y gran adaptabilidad a las necesidades particulares con múltiples puertos, robustez gracias al encapsulado IP-67, sencilla instalación en campo gracias a sus diferentes opciones de anclaje, fácil conexión y recambio de sensores mediante conectores universales. Tras analizar las diferentes opciones del mercado, se decide desplegar 33 estaciones meteorológicas de PCE Instruments cuyo modelo Watch Dog 2900 cumple con todo lo arriba descrito. Cada estación viene acompañada por 6 sensores externos con lo que contamos con 198 sensores para desplegar por el terreno junto con las 33 estaciones propiamente dichas. 23 wine_analytics S En la negociación, se acuerda que el soporte y mantenimiento de las estaciones, de los sensores y de la conexión móvil queda cubierto con el 10% del coste total de la operación y que será el proveedor quien lo lleve a cabo. 2 Procesar Wine_analytics tiene la capacidad de generar información valiosa sobre el estado y las necesidades actuales y futuras de los cultivos, debido al uso de tecnologías de procesamiento de grandes volúmenes de datos diferentes que permiten integrar y relacionar todos estos datos tan diferentes con las necesidades específicas del viñedo y predecirlas. Para realizar las predicciones se utilizan modelos y algoritmos basados en condiciones genéricas, pero a los que wine_analytics aporta inteligencia sobre las condiciones particulares personalizándolos a las condiciones específicas de cada finca y/o parcela y calculando las desviaciones con respecto a lo inicialmente esperado. Para poder generar esta información y dotar de inteligencia a los modelos, es necesario cuantificar los elementos que influyen en los cultivos: el clima, la vid, el suelo y las acciones sobre ellos. Para obtener estos datos heterogéneos, wine_analytics tiene varios métodos: Para obtener información sobre el clima, wine_analytics integra los datos sobre las mediciones y predicciones meteorológicas de los servicios meteorológicos más importantes. Los datos a nivel de microclimas tanto agronómicos como meteorológicos los aportan los sensores instalados estratégicamente en los viñedos. Los registros e información sobre las acciones y labores que se realizan en el campo y le afectan se adquieren desde las herramientas de registro de la bodega. Los históricos y los registros sobre la incidencia de enfermedades y plagas se obtienen directamente del consejo regulador y de las organizaciones que realizan la vigilancia fitosanitaria. 3 Informar En definitiva lo que la solución wine_analytics ofrece es un servicio de Analytics as a Service de forma transparente para los usuarios y que permite tomar decisiones accionables de forma ágil. A wine_analytics se accede con credenciales desde cualquier dispositivo que posea conexión a internet (PC, tablet o smartphone) para: 24 wine_analytics S Visualizar los datos enviados por los sensores. Administrar la Información generada sobre las necesidades actuales y futuras de sus cultivos (riego, enfermedades y plagas, crecimiento y clima). Gestionar las labores y acciones realizadas por los técnicos sobre los cultivos. Programar alarmas configurables según diferentes parámetros (Altas temperaturas, riesgos de enfermedades o plagas, etc.). Configurar el modo de funcionamiento de los sensores (energía, tiempos de medición, tiempos de envío, etc.). Una de las ventajas del servicio en la nube es que no necesita instalarse (acceso a través de un navegador de Internet), está siempre disponible y siempre actualizado. Para adecuarse a las diferentes necesidades de información, wine_analytics dispone de las siguientes ventajas: Pantallas configurables y dinámicas según las necesidades de cada usuario (dashboard). Alarmas a través de SMS, email y Twitter. Gráficas y tablas configurables de alto rendimiento. Funciones de gestión de usuarios, permisos, etc. Informes automatizados e integrados en el BI corporativo. Wine_analytics aúna las últimas tecnologías y avances en sensorización con los desarrollos más avanzados de las tecnologías de la información para conocer mejor el viñedo, medir y cuantificar los factores que le afectan, las relaciones entre ellos y mejorar la gestión de los cultivos, convirtiendo los datos en información accionable. Propuesta técnica a alto nivel La arquitectura está dividida en tres capas, cada una encargada de las fases de la cadena de valor de la información. Adquisición de los datos. Procesado de los datos. Explotación y exportación de los valores. Se propone una solución de este tipo por: Escalabilidad: Por volumen, velocidad, variedad, variabilidad y complejidad de la información. Permite escalar eficientemente por volumen de datos. 25 wine_analytics S Bajo Coste: Se ejecuta en hardware de bajo coste, sin coste de licencias al ser Open Source. Alta Capacidad: Por el almacenamiento desestructurado y el análisis de grandes conjuntos de datos. Rendimiento: Permite monitorizar los datos en tiempo real. Flexibilidad: Permite proporcionar informes y análisis adhoc. Proporciona la capacidad de crear rápidamente paneles de instrumentos (dashboards) y visualizaciones personalizadas. La dirección técnica del proyecto propone inicialmente dos posibles caminos para abordar la solución desde una perspectiva de persistencia de los datos: Usando Spark (junto con una BB.DD de alta latencia y escalabilidad) Usando Hadoop (HDFS) Ventajas de ambas propuestas: Rápido retorno de la inversion Menor coste de desarrollo. El tiempo de desarrollo se puede reducir hasta en dos veces. Plazos de entrega menores. Hosting económico. Se ejecuta en plataformas de bajo coste. Sin coste de licencias. Open Source totalmente gratuito. Solución de futuro. Durante los próximos años crecerá el volumen de información y de procesamiento de datos exponencialmente debido a las redes sociales. La tendencia es procesar más KPIs con una frecuencia de muestreo menor. Fiabilidad, Escalabilidad Y Bajo Coste. Grandes empresas han adoptado estas soluciones: Microsoft (Azure HDInsight), IBM (InfoSphere BigInsights), Facebook, Twitter o Yahoo. Fase 1- Adquisición de datos El primer paso es la obtención de los datos que queremos analizar, para ello enumeraremos las fuentes susceptibles de esta recogida: Sensores (temperatura, velocidad del viento, radiación solar, humedad, etc.). Bases de datos meteorológicas (estaciones e institutos de meteorología). Redes Sociales. Tweets, Likes de Facebook… Campañas de marketing on-line. Logs. Datos propios del BI corporativo. Datos de ventas internas y externas. Sistemas de información geográfica (GIS). 26 wine_analytics S Imágenes satelitales. Como se puede ver en el listado precedente, el origen de los datos es muy diverso y las fuentes bastante desestructuradas por lo que será importante la fase de fusión de datos. Antes de detallar esa fase, vamos a tratar de poner en valor cada una de las fuentes y analizar el tipo de datos y volumen de cada una de ellas. Sensores Ya lo hemos anticipado en secciones precedentes. Devuelven información en “tiempo real” y los que más nos interesan son aquellos asociados al riego y al clima. Humedad relativa. Devuelve la tensión proporcional al nivel de humedad medido. Temperatura del aire. Temperatura del punto de condensación. Precipitación. Velocidad del viento. Radiación solar. Evapotraspiración. Balance hídrico Los datos recogidos por estos sensores son usados para la toma de decisiones basada en información meteorológica, para generar series temporales de estadísticas agroclimáticas y para extraer conclusiones microclimáticas que nos permitan tomar decisiones casi en tiempo real. Otras medidas que pueden resultar interesantes en la medición de un viñedo son la presión atmosférica, el oxígeno y CO2 pero no son tan determinantes en nuestro caso como los anteriores. Estaciones meteorológicas y bases de datos meteorológicas De manera conjunta se pueden tomar mediciones como la presión barométrica, temperatura, humedad, sensor de luz, viento, lluvia… Estos sensores ya vienen integrados en la propia estación meteorológica, recogen la información y se apoyan en un módulo de comunicaciones para transmitir dicha información. Desde la Agencia Estatal de Meteorología (AEMET) se pueden descargar ficheros XML con la predicción meteorológica de hasta 6 días y CSV o Excel con la observación por franjas horarias. 27 wine_analytics S Los tamaños de los archivos por región son 11kB para el XML, 18kB para el Excel y 3kB para el CSV y la periodicidad sería diaria. Redes sociales La información obtenida por redes sociales es muy desestructurada, por ejemplo, para Twitter tenemos una cadena de 140 caracteres, Facebook no tiene límite de caracteres y además permite subir imágenes, vídeos… Hay que tener en cuenta que las redes sociales no codifican con ANSI, sino con Unicode, con el fin de incluir caracteres especiales y de otros idiomas. Estos caracteres ocupan de forma individual (en char) entre 2 y 4 bytes. Según cada red social se puede recoger unas métricas u otras, algunas de las métricas que resulta interesante recoger son las siguientes: Publicaciones/Tweets y analizar su contenido para buscar coincidencias o llamadas a otros usuarios. Likes Retweets Comentarios a publicaciones En el área de las Redes Sociales hay varias iniciativas a tener en cuenta: Por un lado el departamento corporativo de Marketing del grupo Pérez Cristóbal lanzará una serie de acciones digitales en Redes Sociales para realizar el seguimiento de acciones de marketing físicas que se hayan lanzado en supermercados, Horeca, etc. En este sentido se realizará un rastreo on-line de éstas para medir el impacto directo que puedan tener sobre un aumento de los ingresos. Se prevé la contratación de un Community Manager por el grupo cuyo objetivo será crear valor de marca a través de los medios digitales. Con la creación de esta área de marketing digital, se lanzarán otra serie de acciones digitales por marcas, con mayor continuidad en el tiempo, incluyendo acciones concretas para nuestra bodega Abadía de Haza de las que se hará un seguimiento exhaustivo para evaluar el retorno del marketing comercial. Lanzamiento de campañas de marketing directo a través de las redes sociales: cada hashtag que el departamento digital ponga de cualquiera de los vinos de la bodega, y en especial de Abadía de Haza Selección, se realizará un rastreo de los datos (envío de los datos en tiempo real, y explotación de los datos para convertirlos en información). Se crearán un conjunto de 28 wine_analytics S tags corporativos por país, categoría, marca y canal basados en Google Analytics. Esta iniciativa está vinculada con el plan estratégico de ingresos, que lanza campañas de e-mkt e impulsa la venta internacional de vinos vía un distribuidor local (único en cada país) y vía ecommerce. Se trabajará con una agencia de marketing digital externa con distintos objetivos: Realizar acciones encaminadas a aumentar la exportación, especialmente en EEUU, Brasil y México Posicionar la tienda corporativa on-line del grupo, también a nivel de marcas Evaluar la reputación on-line de los productos del grupo, en especial los de nuestra bodega Abadía de Haza. Pasaremos de los datos a la información vía contratación de servicios a esta agencia de e-mkt, que medirán la efectividad de nuestras acciones utilizando herramientas como Google Analytics para estadísticas de abandono, tiempo medio y usuarios activos Mejorar el SEO y SEM de los sitios web relacionados con Abadía de Haza y de otros negocios del grupo. Finalmente se lanzarán acciones digitales, puntuales en el tiempo o sostenidas. La primera de ellas, “Apadrina una cepa” pretende fidelizar al cliente directamente con nuestra bodega. En definitiva, se abordará una primera fase para tagear toda la actividad digital de modo que pueda ser seguida tal y como hemos descrito con el objetivo de obtener insights en términos de reputación, impacto, retorno promocional y comportamiento del usuario dentro de las webs relacionadas con Abadía de Haza. Campañas de marketing Como ya hemos anticipado en párrafo precedente, cuando se lanza una campaña publicitaria es importante saber el impacto que se ha tenido en el consumidor. Los datos que se recogen para medir este impacto no son solo las ventas de un producto antes, durante y después, o las descargas para el caso de la aplicación móvil, hay también métricas que cuantifican a cuántos usuarios se ha llegado o cuántas veces han visto la campaña. El tamaño de este archivo dependerá de la cantidad de información, detalle y formato que se quiera exportar, siendo muy pesado para un Excel y bastante más ligero para un JSON, XML, CSV, etc. 29 wine_analytics S Para este input de datos la periodicidad dependerá principalmente de si está habiendo algún tipo de campaña publicitaria, si no hay campaña los datos pueden tener poca periodicidad o nula y el tiempo que dura la campaña pueden ser reportes diarios. Estudio general de medios El Estudio General de Medios proporciona información de la población en España y de la audiencia a los medios (televisión, radio, prensa, revistas…) y periódicamente generan informes. También tienen reportes con el uso de internet o el marco general de medios donde muestran el consumo que se hace de los medios. Estos datos se pueden descargar en formato pdf por lo que no permiten una carga directa en el sistema. Análisis de audiencias Se cargará un fichero Excel con una periodicidad que dependerá de la información que se requiera, por la naturaleza de la información podría interesar que fuera de manera quincenal o mensual. El tamaño del fichero dependerá de la cantidad de información, pero suponiendo que será con periodicidad mensual este fichero ocuparía alrededor de 50kB. Logs El tamaño de estos mensajes dependería de la longitud, cada char ocupa 1 byte. En nuestro caso sería útil recoger mensajes de respuesta del servidor: Si algún sensor no está recogiendo información Se ha perdido comunicación con alguna estación meteorológica/sensor Algún dato recibido no se ha podido procesar El envío de información por parte de los sensores es correcto, aunque este mensaje podría ser muy redundante y proporcionar ruido y carga extra al sistema Inconsistencia de la información recibida a la hora de fusionar datos Escritura en base de datos correcta o incorrecta Exportaciones desde base de datos correctas o incorrectas 30 wine_analytics S Esta información de errores se querrá enviar como datos de entrada por lo que sería interesante codificarla. De tal forma que la información que enviamos sea un código que corresponda con un mensaje conocido por nosotros y ocupe menos que un mensaje completo. Datos propios de BI. Ventas internas y externas El volumen de estos datos dependerá de la extracción que se haga del data warehouse. Normalmente, tratándose del volumen de ventas interno, estaríamos hablando de unos 2MB diarios. En este punto conviene mencionar el grupo tiene el siguiente stack tecnológico en BI: Capa de almacenamiento: MS SQL Server Capa de integración: PowerCenter (informatica) Capa de visualización: Microstrategy GIS e imágenes tomadas desde satélite El tamaño de las imágenes dependerá de la resolución y de las dimensiones que tenga. Una imagen estándar en formato jpg ocupa alrededor de 3MB. Si suponemos que un satélite envía estas imágenes una vez tomadas estaríamos en una situación asíncrona, en la que recibiríamos la imagen una vez tomada, pero no tendría por qué ser un flujo continuo. La situación ideal es aprovechar el servicio que el grupo tiene externalizado a través de un proveedor en el que éste nos envía los datos ya extraídos de las imágenes de satélite a través de un proceso batch. Desde el punto de vista tecnológico, se propone utilizar Kafka para la recogida de datos de las diferentes fuentes Kafka es un servicio de repositorio de logs que permite ser distribuido, replicado y particionado. Es escalable, de baja latencia y alto rendimiento para agregación de logs y flujos de actividad. Las principales características de Kafka son: Gran throughput. Absorbe grandes cantidades de tráfico. Capacidad de replicación. Gestiona la tolerancia a fallos. Persistente en disco por lo que no se pierde la información. Su objetivo es garantizar el thoughput necesario a medio plazo, absorber los picos de tráfico que se produzcan y estar prevenido ante posibles caídas del servicio. El cluster de Kafka recoge los mensajes enviados y los distribuye a los destinatarios. 31 wine_analytics S Típicamente la terminología que utiliza Kafka es la siguiente: Kafka mantiene los hilos de los mensajes en categorías llamadas topics. Los procesos que publican mensajes son los producers. Los procesos que se suscriben a los topics y que procesan los mensajes son los consumers. Kafka corre en un cluster que constará de uno o más servidores, cada uno de ellos se llama broker. Los usos más comunes de Kafka son: Mensajería. Es útil porque permite separar procesos de cada producer y almacena mensajes no procesados. Comparado con otros servicios de mensajería tiene mejor rendimiento, particionado, reproducción y tolerancia a fallos. Trackeo de actividad web. Reproducir la actividad de los usuarios en una web. Métrica. Monitorización de datos. Agregación de logs. Procesamiento de datos. Se convierten los datos originales en datos con el formato de Kafka para más adelante ser utilizados. Repositorio para sistemas distribuidos. Permite recuperar estados anteriores. Kafka puede trabajar para realizar cargas offline de datos, esto ofrece la posibilidad de consumir paquetes de datos de forma periódica de sistemas offline como Hadoop o bases de datos relacionales. En el caso de Hadoop se pueden paralelizar las cargas de datos. Fase 2 - Procesado de datos La dirección técnica del proyecto propone inicialmente dos posibles caminos para abordar la solución desde una perspectiva de procesamiento de los datos: 32 wine_analytics S Hadoop es una librería que proporciona un framework para procesado distribuido de grandes conjuntos de datos. Spark es un motor que consta de varias librerías también para el procesado de grandes sets de datos. Hadoop es un almacén con los datos semi-estructurados en HDFS y que tiene la flexibilidad de MapReduce para hacer queries con los datos. Spark, por medio de Scala, permite realizar ejecuciones de programas de manera más sencilla que simplemente Hadoop y especialmente útil para usuarios sin mucho background de bases de datos. Para usuarios con conocimientos de bases de datos, dentro de Scala MLlib hay una herramienta llamada Shark para hacer consultas tipo SQL. Spark tiene las siguientes ventajas sobre Hadoop-MapReduce: Spark utiliza RDD (Resilient Distributed Datasets) por lo que los datos se almacenan en memoria. De esta forma ejecuta programas 100 veces más rápido que Hadoop en memoria o 10 veces en disco. Permite procesado en tiempo real para alertas y análisis. Recoge y fusiona los datos de diferentes fuentes. Por otro lado, los inconvenientes son: Hay más experiencia en el campo de MapReduce. Para el procesado y carga de datos paralelos, MapReduce es ligeramente más ligero que el equivalente de Spark. Spark no está todavía muy integrado con YARN. Acompañando a Kafka, se propone utilizar Spark Streaming para fusión de datos. Spark Streaming procesa un flujo continuo de datos de la misma forma que Spark procesa los paquetes. Spark permite leer datos de diferentes fuentes, como HDFS, Flume, Kafka, Twitter, ZeroMQ… y puede procesar algoritmos de alto nivel, como MapReduce. 33 wine_analytics S Las características de Spark Streaming son: Basado en Spark. Usa la misma filosofía de Spark basada en RDD (Resilient Distributed Datasets). Modelo de programación sencillo. Unificación de procesos batch y real time. Un stack para todos los procesos. Es un sistema escalable y robusto. Alta tolerancia a fallos. Latencias por debajo del segundo. Debido a su rendimiento y tolerancia a fallos puede utilizarse como herramienta de procesado de datos en tiempo real. En el proceso de fusión de datos, Spark Streaming lee la información a través de las colas de Kafka. Tiene tres funciones: Agregar estos datos. Realizar cálculos al vuelo de la información. Insertar la información en la capa de análisis. 34 wine_analytics S Fase 3 - Explotación y exportación de los datos Se propone utilizar Apache Cassandra como motor de almacenamiento de datos. Se trata de una base de datos NoSQL de alto rendimiento, que permite escalabilidad, alta disponibilidad y es tolerante a fallos. Está diseñada para manejar grandes cantidades de datos. ¿Consistencia de datos o latencia? Es una de las preguntas que debemos hacernos al definir una arquitectura de datos. Con Cassandra esto no va a ser problema, ya que nos permite ajustar el tiempo de respuesta (latencia), y la consistencia de los datos a nuestro antojo y según nuestras necesidades. La característica más importante de Cassandra es su alta escalabilidad y la gestión de los datos entre una serie de servidores o nodos de un clúster. Estos nodos se añaden al clúster de forma horizontal de modo que nuestra información es procesada automáticamente por el sistema, quien se encarga de hacer el balanceado y mantener la consistencia en los nodos ya existentes y en el nodo recién añadido. Esta característica es la que hace especial a Cassandra, ya que al igual que el balanceado de datos y el manejo de la consistencia se hace de forma automática al añadir un nodo, también se encarga de realizar la misma operación si algún nodo se pierde, y con esto aunque el servidor esté caído, no veremos afectados nuestros datos por esta eventualidad. Presenta dos características adicionales que la hacen particularmente interesante para nuestro caso de uso como veremos en la siguiente sección. Tiene integración con Hadoop y MapReduce. 35 wine_analytics S Utiliza un lenguaje propio basado en SQL llamado CQL (Cassandra Query Language), similar a SQL tradicional. Patrón de arquitectura para la solución En este apartado vamos a describir cómo se llega a diseñar una solución flexible y elegante que soporte las fases descritas anteriormente desde el punto de vista de arquitectura de software. Un aspecto importante en una arquitectura de datos moderna es la capacidad de utilizar múltiples frameworks de ejecución sobre los mismos datos. Esto permite obtener la flexibilidad necesaria para adoptar las tecnologías que van surgiendo y tener siempre disponible el stack tecnológico ideal para un caso de uso concreto. En el caso que nos ocupa, la solución tecnológica descansa sobre el principio anterior y por ello, se propone usar dos motores de almacenamiento separados, HDFS y Cassandra, junto con múltiples marcos de ejecución, incluyendo Spark, Spark Streaming, Spark SQL, Impala, y CQL. Kafka se utilizará para ingestión escalable de datos y tolerante a fallos. Un escenario ideal de datos sería tener una única copia de éstos que sirviera para todas nuestras necesidades de informacionales, pero esto es muy difícil de lograr porque las arquitecturas de datos subyacentes que sirven gran volumen, necesidades OLTP de baja latencia son fundamentalmente diferentes de las necesarias para servir los grandes escaneos de tablas necesarias en casos de uso típicos de analytics. Por ejemplo, con Cassandra es difícil escanear grandes volúmenes de datos, pero permite el acceso ultra rápido, por debajo de un milisegundo, de millones de registros por segundo. Por otro lado, el patrón de almacenamiento simple en los sistemas de archivos distribuidos como HDFS no indexa datos para permitir el acceso por debajo del milisegundo, pero usa grandes tamaños de bloques que permiten el acceso secuencial de forma muy rápida a los datos para escanear miles de millones de registros por segundo. Motores de streaming como Spark Streaming ayudan a mitigar el problema permitiendo análisis “al vuelo” a la vez que los datos se ingieren en el sistema. Sin embargo, nunca o casi nunca se han podido predecir todas las métricas que necesitaban ser calculadas. Por ello han surgido arquitecturas como la arquitectura lambda que permite añadir métricas on the road que permiten recalcular la historia. La arquitectura Lambda se basa en tres principios fundamentales de diseño: Tolerancia a fallos - el sistema es tolerante a la pérdida de datos o la corrupción de estos. 36 wine_analytics S Inmutabilidad de datos - almacena datos de forma cruda de forma inmutable y a perpetuidad. Re-cálculo - con los dos principios anteriores, es siempre posible re-computar ejecutando una función sobre los datos brutos. Esquema típico de arquitectura Lambda La descripción de cada una de las capas se detalla a continuación. Batch layer La capa batch contiene lo inmutable, los datos que están en constante crecimiento almacenados en un sistema de archivos distribuido como HDFS. Con el procesamiento por lotes (MapReduce) los llamados puntos de vista (por lotes) se calculan a partir de este conjunto de datos en bruto. Así Hadoop se ajusta perfectamente al concepto de la capa de batch. Serving layer El trabajo de la serving layer es cargar y exponer los puntos de vista por lotes en un almacén de datos para que puedan ser consultados. Este almacén de datos no requiere escrituras aleatorias pero debe ser compatible con las actualizaciones por lotes y lee aleatoriamente - y por lo tanto puede ser extraordinariamente simple. 37 wine_analytics S Speed layer Esta capa se ocupa sólo de los nuevos datos y compensa las actualizaciones de alta latencia de la serving layer. Aprovecha los sistemas de procesamiento de streams como Storm, S4 o Spark y motores de almacenamiento de datos de lectura / escritura aleatoria como HBase o Cassandra para calcular las vistas en tiempo real. Estas vistas siguen siendo válidas hasta que los datos se han abierto camino a través de la capa batch y la de serving. Una característica importante de una buena arquitectura lambda es que el sistema puede volver a calcular la historia y para ello debe ser capaz de operar rápidamente con un gran conjunto de datos sin interrumpir el rendimiento o el tráfico de baja latencia. Por lo tanto, nuestra propuesta tecnológica se basa en la combinación de dos motores de almacenamiento: HDFS en formato parquet para almacenar la copia de nuestros datos, el 100% de estos (el raw data), mientras que para el tráfico de baja latencia y los datos muy frecuentes (25% de los datos) proponemos usar Cassandra. Se sugiere el siguiente Set de software que soporta la arquitectura para el piloto: Cassandra 2.0.7.31 CDH5.1 HDFS + Impala 2.0.0 Kafka 0.8.1.1 built for Scala 2.10 Spark 1.1 built for Hadoop 2.3 Flujo que modela un escenario típico de datos para esta arquitectura en este proyecto: 38 wine_analytics S Breve descripción del flujo 1. El escenario se inicia leyendo los datos con un script en Python. 2. El script en Python publica los datos a Kafka. 3. Se correrá un job de Spark Streaming que leerá los datos de Kafka y escribirá en Cassandra y en formato parquet en HDFS. 4. Podemos entonces leer los datos con Spark SQL e Impala del HDSF y de Cassandra vía Spark SQL y CQL. Arquitectura para procesamiento de datos en AWS El siguiente gráfico corresponde a una arquitectura para procesamiento de datos en Amazon Web Services con Kafka y Spark, y almacenamiento con Cassandra que podría reflejar perfectamente nuestro escenario de ingeniería de datos para el caso de uso de sensórica. El ítem de APPLICATION correspondería al software localizado en los sensores, por lo que el punto de entrada a la arquitectura en AWS sería directamente al Kafka. La Alta Disponibilidad de estos servicios se la ofrece a modo de clusters (por lo que no requieren un Load Balancer). La idea 39 wine_analytics S es definir en este análisis clusters de servicios integrados ara una arquitectura mínima (en coste/actividad) viable. En la etapa de desarrollo siempre se podría empezar con instancias más pequeñas, ya que la combinación Spark-Kafka-Cassandra está diseñada para ser escalable, todos los clusters van a ser dinámicos dependiendo del tráfico/carga de trabajo/peticiones. Proponemos la siguiente arquitectura mínima en AWS: CAPA KAFKA (cluster) IP elástico externo (punto de entrada) 1 instancia de Zookeeper (se encarga de arbitrar los brokers y se puede reutilizar para el Spark) m3.large 2 instancias brokers m3.large CAPA SPARK (cluster) 1 instancia master m3.xlarge 2 instancias slave m3.large CAPA CASSANDRA (cluster) 3 instancias/nodos m3.large CAPA HADOOP (cluster minimo) 1 instancia master m3.xlarge 2 instancias slave m3.large COSTES BAJO DEMANDA Con 100% de uso (Hosting en Irlanda): 40 wine_analytics S 9 instancias m3.large 2 instancias m3.xlarge Coste/mensual: 1465.49$ Coste/anual: 17585.88$ COSTES DE ALMACENAMIENTO Según los requisitos de la arquitectura del sistema los datos podrían almacenarse en discos SSD o en S3. En este caso hay que contemplar estos costes: S3: $0.03 por GB (después de almacenar 1 TB los costes bajan más). SSD: $0.11 por GB-mes de almacenamiento aprovisionado. Nota: Es importante señalar que se puede ahorrar de un 30% a un 40% en instancias reservadas, o ahorrar si se calendariza el despliegue de las instancias. Arquitectura mínima viable en AWS (Capas Opcionales): CAPA COLLECTOR (OPCIONAL): Si se necesita algún tipo de parsing/procesamiento de mensajes desde la aplicación de los sensores, se necesitaría una capa COLLECTOR con nodos que estén tras un balancer. En este caso el punto de entrada a la arquitectura serían los balancers. CAPA DE BÚSQUEDAS INDEXADAS (OPCIONAL): Para búsquedas indexadas/rápidas varias fuentes se podrían proponer implementar un Elasticsearch. Seguridad en AWS: Para la implementación de la seguridad desplegaremos sobre AWS un setting típico y fácil de gestionar usando varios recursos: Security Groups (firewalls a nivel de instancias), VPCs y subredes privadas (aislamiento lógico de la infraestructura), ACLs (listas de control a de acceso), Route Tables (control de rutas a nivel de instancia), IAM (servicio de Amazon para el control de identidades), y pares de llaves (para el acceso a las instancias). La seguridad se podría complementar con sistemas de software como WAFs, IDS, gestión de logs, firewalls de sistemas operativos, etc. Adicionalmente, mencionar que como AWS cumple con varias certificaciones de seguridad que las arquitecturas implementadas heredan automáticamente como: PCI-DSS, SOC, ISO 27001, etc., podremos contar con esas garantías en wine_analytics. 41 wine_analytics S Observaciones adicionales Amazon Kinesis es el equivalente de Kafka en la nube. En el caso de montar una arquitectura de este tipo en AWS, se podría investigar esta tecnología, ya que inicialmente este tipo de servicios bajo demanda son más baratos, y a mediano plazo son escalables. Amazon ya soporta lanzar Spark/Hadoop a través de su servicio EMR (Elastic Map Reduce). La ventaja además de la gestión a alto nivel del servicio, es que las instancias de EMR son más baratas. Sería interesante evaluar su utilización dentro de la arquitectura de AWS. Soluciones para la Analítica Una vez recogidos los datos, almacenados y procesados a través de la arquitectura propuesta en el apartado anterior, tenemos que pasar a la fase de Analytics. Presentamos tres alternativas dependiendo de la necesidad analítica concreta ofreciendo así un completo conjunto de posibilidades analíticas para nuestros científicos de datos. Para la parte de analítica predictiva utilizaremos una solución de código abierto llamada H2O (Hortonworks). Se trata de una solución en memoria para análisis predictivo en grandes volúmenes de datos. Tiene un motor de machine learning que permite el trabajo distribuido y en paralelo de potentes algoritmos que ayudan a hacer predicciones y a hacer modelos precisos de forma rápida. Lo conectaremos directamente con nuestro Hadoop. Tiene APIs para R y JSON, así como el método de almacenamiento de HDFS, H2O tiene la capacidad de hacer análisis avanzados para un grupo más amplio de usuarios con una curva de aprendizaje casi inexistente para los usuarios actuales de Hadoop. Un análisis que los científicos de datos correrán haciendo uso de H2O sería por ejemplo encontrar y clasificar patrones de desviación durante un periodo de tiempo en la radiación solar o evapotranspiración de una zona determinada de los viñedos. Para realizar análisis en los datos almacenados en Hadoop a través de herramientas de SQL vamos a usar Impala que es un motor de consulta que corre en Hadoop. Impala lleva la tecnología de base de datos escalable en paralelo a Hadoop, permitiendo a los usuarios realizar consultas SQL de baja latencia a los datos almacenados en HDFS sin necesidad de movimiento o transformación de datos. 42 wine_analytics S El resultado es que el procesamiento de datos a gran escala (a través de MapReduce) y las consultas interactivas se pueden hacer en el mismo sistema utilizando los mismos datos y metadatos - eliminando la necesidad de migrar los conjuntos de datos a sistemas especializados y/o formatos propietarios solo para realizar el análisis. Un análisis que los científicos de datos correrán haciendo uso de Impala sería por ejemplo encontrar datos históricos concretos con respecto a las series de temperaturas. Finalmente, usaremos R para el análisis estadístico avanzado como regresiones lineales multivariantes. Lo conectaremos directamente desde Cassandra vía Spark SQL. Un análisis que los científicos de datos correrán haciendo uso de R sería por ejemplo identificar un determinado evento climático de manera anticipada estudiando los días de tormenta en un periodo de determinado de tiempo y las temperaturas mínimas absolutas en ese mismo periodo. Herramienta de visualización Para la visualización de los datos haremos una integración con el Microstrategy corporativo del grupo. Sin entrar en mucho detalle, sólo indicamos que con Impala lo haremos a través del conector ODBC de este. Para el caso H20 haremos la integración a través de una de las librerías graficas de H2O, en concreto con GBW (Graphic Business Wire). Para el caso de R, usaremos el conector específico que Microstrategy tiene para éste. Análisis financiero El equipo de Abadía de Haza es optimista con relación al impacto en cuenta de resultados de este proyecto, dada la baja inversión inicial y OPEX, y teniendo en cuenta la significativa mejora que se podría lograr en cuenta de resultados, cuantificada en un 20%. La mejora en producción es requisito necesario para mejorar la cuenta de resultados, ya que de otro modo sería imposible abordar los mercados objetivo por falta de producto. Las proyecciones de estados financieros realizadas serían las siguientes: 43 wine_analytics S Cuenta de resultados 0 1 2 3 4 5 CUENTA DE RESULTADOS 2014 2015 2016 2017 2018 2019 Ventas 943,3 1.014,6 1.116,5 1.214,0 1.281,7 1.307,3 -815,7 0,0 -815,7 -927,6 -112,0 -815,7 -973,1 -141,1 -832,0 -1.000,6 -152,0 -848,6 -1.020,3 -154,7 -865,6 -1.040,4 -157,5 -882,9 Coste Operativos Costes Wine_Analytics Resto de Costes EBITDA 127,6 87,0 143,4 213,4 261,4 266,9 13,53% 8,57% 12,84% 17,58% 20,39% 20,41% -87,3 -101,2 -12,5 -88,7 -102,2 -12,5 -89,7 -104,0 -12,5 -91,6 -109,2 -12,5 -96,8 -111,5 -12,5 -99,1 Amortización CAPEX del Proyecto Resto CAPEX EBIT -87,3 40,3 -14,2 41,1 109,4 152,1 155,4 4,27% -1,40% 3,69% 9,01% 11,87% 11,88% Gastos Financieros -3,2 -3,2 0,0 0,0 0,0 0,0 EBT 37,1 -17,4 41,1 109,4 152,1 155,4 -11,1 4,9 -10,3 -27,4 -38,0 -38,8 Impuesto de Sociedades Beneficio Neto 25,9 -12,5 30,9 82,1 114,1 116,5 2,75% -1,24% 2,76% 6,76% 8,90% 8,91% Como vemos, la situación de partida para 2014 es la de una compañía con márgenes reducidos, y nuestro objetivo es la mejora de los mismos mejorando la eficiencia del proceso productivo (mayor cantidad de uva de calidad), y aumentando precios gracias a un plan estratégico de posicionamiento comercial, que incluiría adicionalmente acciones de marketing digital y en redes sociales, con lo que buscaría mejorar la calidad percibida y poner en valor el producto en mercados con mayores márgenes. El impacto de los costes incrementales por la implantación del nuevo sistema tecnológico sería nulo, considerando que se utilizaría Open Source y SaaS para minimizar costes asociados. Las estimaciones de costes anuales serían: 2014 Costes del Proyecto Total costes instancias bajo demanda Mantenimiento equipos Fotografía satélite Marketing digital, acciones Redes Sociales 44 2015 2016 2017 2018 2019 2020 111.988 14.655 4.000 40.000 53.333 141.135 14.655 4.080 40.800 81.600 151.988 14.655 4.162 41.616 91.555 154.734 14.655 4.245 42.448 93.386 157.536 14.655 4.330 43.297 95.254 160.394 14.655 4.416 44.163 97.159 S wine_analytics Este bajo impacto de costes tecnológicos, permite una sustancial mejora de márgenes EBIT en 2015 dada la baja inversión requerida también, que apenas impactaría en amortizaciones. El plan estratégico de la bodega buscaría lograr esta mejora de márgenes desde 2015 vía precios, sin embargo, debido a que el ciclo de explotación sería superior al año natural debido a las necesidades de maduración de los vinos selección y reservas, las mejoras en producción tardarían al menos dos años en manifestarse en cuenta de resultados, de manera que iniciando acciones en 2015 no se podrían ver los resultados objetivo hasta 2018. El impacto de esta subida de precio unido a la mayor producción permitiría doblar EBITDA en el período considerado, pasando de unos márgenes del 13,5% sobre ventas a cifras del 20,4%. A nivel de beneficio neto, estaríamos mejorando unos niveles del 2,75% hasta un 8,91%, lo que implicaría multiplicar por más de cuatro el beneficio neto de 2014, desde 25,9 miles euros hasta 116,5 miles de euros. La mejora continuada de la calidad del vino, así como el trabajo más activo en redes sociales y en marketing, serían las claves de este reto que permitiría mejorar márgenes tanto en términos absolutos como relativos, hasta los niveles marcados como target de la compañía. El detalle de este plan estratégico puede apreciarse a continuación: 45 S wine_analytics INGRESOS 2014 943.254 2015 1.014.643 2016 1.116.473 2017 1.214.037 2018 1.281.685 2019 1.307.319 2020 1.333.465 Superficie (ha) Rendimiento kg uva / ha Kg Totales de uva 75,4 4.000 301.600 75,4 4.000 301.600 75,4 4.000 301.600 75,4 4.000 301.600 75,4 4.000 301.600 75,4 4.000 301.600 75,4 4.000 301.600 100% 10% 5% 5% 77% 13% 100% 11% 5% 6% 77% 12% 100% 12% 5% 7% 77% 11% 100% 12% 5% 7% 77% 11% 100% 12% 5% 7% 77% 11% 100% 12% 5% 7% 77% 11% 100% 12% 5% 7% 77% 11% Cantidad de uva por destino Vino alta calidad Reservas Selección Vinos otras calidades Venta de uva 30.160 15.080 15.080 232.232 39.208 33.176 15.080 18.096 232.232 36.192 36.192 15.080 21.112 232.232 33.176 36.192 15.080 21.112 232.232 33.176 36.192 15.080 21.112 232.232 33.176 36.192 15.080 21.112 232.232 33.176 36.192 15.080 21.112 232.232 33.176 Cantidad de botellas (1kg uva = 1 botella 0,75 l) Vino alta calidad Reservas Selección Vinos otras calidades 22.620 11.310 11.310 174.174 24.882 11.310 13.572 174.174 27.144 11.310 15.834 174.174 27.144 11.310 15.834 174.174 27.144 11.310 15.834 174.174 27.144 11.310 15.834 174.174 27.144 11.310 15.834 174.174 35,00 15,00 2,00 0,75 37,80 16,20 2,16 0,77 41,77 17,90 2,39 0,78 43,86 18,80 2,51 0,80 44,73 19,17 2,56 0,81 45,63 19,56 2,61 0,83 46,54 19,95 2,66 0,84 0,00% 0,00% 0,00% 0,00% 8,00% 8,00% 8,00% 2,00% 10,50% 10,50% 10,50% 2,00% 5,00% 5,00% 5,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00% 395.850 169.650 348.348 29.406 427.518 183.222 376.216 27.687 472.407 202.460 415.719 25.887 496.028 255.100 436.504 26.405 505.948 303.569 445.235 26.933 516.067 309.640 454.139 27.472 526.389 315.833 463.222 28.021 Destino de la uva Vino alta calidad Reservas Selección Vinos otras calidades Venta de uva Precio Medio Reservas Precio Selección Precio medio vinos otras calidades Precio medio uva Incremento precio botella reservas Incremento precio botella Selección Incremento precio resto vinos Incremento precio de la uva Ingresos esperados reservas Ingresos esperados Selección Ingresos esperados resto vinos Ingresos esperados venta de uva 100% 10% 77% 13% 35,00 15,00 2,00 0,75 Los costes de explotación de 2014, en consonancia con la media comparable del sector, serían de un 86,5% aproximadamente sobre cifra de ventas. 46 wine_analytics S Balance de situación BALANCE Inmovilizado Bruto Amortización Acumulada Inmovilizado Neto 0 1 2 3 4 5 2014 2015 2016 2017 2018 2019 2.860,3 -1.337,9 1.522,4 2.957,2 -1.439,1 1.518,1 2.982,6 -1.541,3 1.441,3 3.027,9 -1.645,3 1.382,5 3.158,3 -1.754,6 1.403,7 3.215,5 -1.866,1 1.349,4 Existencias Clientes Otros Tesorería TOTAL ACTIVO 502,0 235,8 540,0 253,7 594,2 279,1 646,1 303,5 682,2 320,4 695,8 326,8 85,5 2.345,7 42,2 2.354,0 75,0 2.389,6 75,0 2.407,2 75,0 2.481,3 125,1 2.497,0 Capital Social Reservas Resultado del Ejercicio Dividendos del ejercicio Total Patrimonio Neto 1.800,0 355,5 25,9 0,0 2.181,4 1.800,0 381,4 -12,5 0,0 2.168,9 1.800,0 368,9 30,9 -5,8 2.193,9 1.800,0 393,9 82,1 -72,0 2.204,0 1.800,0 404,0 114,1 -45,3 2.272,8 1.800,0 472,8 116,5 -104,9 2.284,4 0,0 135,9 28,3 164,2 0,0 154,6 30,4 185,0 0,0 162,2 33,5 195,7 0,0 166,8 36,4 203,2 0,0 170,1 38,5 208,5 0,0 173,4 39,2 212,6 2.345,7 2.354,0 2.389,6 2.407,2 2.481,3 2.497,0 0,0 0,0 0,0 0,0 0,0 0,0 Deuda Senior Acreedores Otros Total Pasivo TOTAL PATRIMONIO NETO Y PASIVO Desde el punto de vista patrimonial, la bodega no precisaría de afrontar fuertes inversiones tecnológicas, que se estimarían por importe de 62,4 miles de euros. Dicha inversión se dedicaría fundamentalmente a la adquisición de estaciones meteorológicas con sensores, un servidor y licencias diversas. El balance proyectado a partir de las cuentas reales de cierre de 2014 presenta una continuidad tanto de políticas contables como de criterios de gestión y financieros, como serían los relativos a la financiación permanente, política de inversión, periodo medio de pago a proveedores o la política de dividendos. Cash Flow En el cash flow resumen de este plan estratégico puede apreciarse mejor la contribución a la generación de caja de la mejora de la cuenta de resultados frente a la inversión realizada y opex incrementales asumidos: 47 wine_analytics S 0 1 2 3 4 5 CASH FLOW 2014 2015 2016 2017 2018 2019 EBITDA Impuesto de Sociedades Variación de Fondo de Maniobra Fondo de Maniobra CASH FLOW DE OPERACIONES 127,6 -11,1 -88,8 573,6 27,6 87,0 4,9 -35,0 608,6 56,8 143,4 -10,3 -69,0 677,7 64,1 213,4 -27,4 -68,8 746,5 117,3 261,4 -38,0 -47,6 794,1 175,7 266,9 -38,8 -15,9 810,0 212,1 0,0 -34,5 -62,4 -96,9 -25,4 0,0 -25,4 -45,3 0,0 -45,3 -130,4 0,0 -130,4 -57,2 0,0 -57,2 FREE CASH FLOW 27,6 -40,1 38,7 72,0 45,3 154,9 Capital Social Disposiciones de Deuda Senior Cancelaciones de Deuda Senior Gastos Financieros Netos CASH FLOW DE FINANCIACION 0,0 0,0 0,0 -3,2 -3,2 0,0 0,0 0,0 -3,2 -3,2 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 FREE CASH FLOW TO EQUITY 24,4 -43,3 38,7 72,0 45,3 154,9 0,0 -5,8 -72,0 -45,3 -104,9 CAPEX ya previsto CAPEX Proyecto CASH FLOW DE INVERSION Dividendos VARIACION ANUAL DE TESORERÍA 24,4 -43,3 32,8 0,0 0,0 50,1 Saldo Inicial de Tesorería 61,0 85,5 42,2 75,0 75,0 75,0 SALDO FINAL DE TESORERÍA 85,5 42,2 75,0 75,0 75,0 125,1 0,0 0,0 0,0 0,0 0,0 0,0 Rentabilidad Finalmente, el análisis de rentabilidad del proyecto según se puede apreciar en el cuadro más abajo. RENTABILIDAD 0 1 2 3 4 5 2014 2015 2016 2017 2018 2019 0,0 -112,0 -62,4 -174,4 101,8 -141,1 0,0 -39,3 199,4 -152,0 0,0 47,4 267,0 -154,7 0,0 112,3 292,7 -157,5 0,0 135,1 Variación de Ingresos Opex del proyecto Capex del proyecto Flujos del proyecto ROI 10,41% TIR de proyecto 10,97% En términos de TIR de proyecto, por tanto, estaríamos en la situación de TIR de proyecto del 11%, que sería infinita a nivel de accionista, debido a que no se precisaría financiación de accionistas para el proyecto. Con relación al ROI, estaríamos en un 10,4%. 48 S wine_analytics La interpretación de estas magnitudes permite confirmar sin lugar a dudas, y a pesar del largo ciclo de explotación (más de dos años de maduración para vino selección y reservas), la evidente conveniencia financiera de la inversión, lo que la convierte en clave para la estrategia de la bodega. 49 S wine_analytics ANEXOS 50 wine_analytics S Marco temporal – ciclo vegetativo de la vid El ciclo biológico anual de la vid comienza al principio de la primavera, cuando pasadas las bajas temperaturas del invierno, que provocan la parada invernal, la savia empieza a sangrar por los cortes de la poda. Cuando las temperaturas medias llegan a los 10º C, entre marzo y abril, se produce el desborre o brotación de los pámpanos (nacimiento anual), que siguen creciendo hasta el mes de agosto. La principal preocupación de viticultor una vez producida la brotación es que no hiele. Si hiela se mueren los brotes, lo que puede reducir mucho la cosecha, hasta casi desaparecer. Con la aparición de los brotes comienza la etapa de crecimiento anual de la planta, que dura hasta el envero (final de julio). A continuación se describen con más profundidad las etapas del ciclo de la vid: Lloro: Es la primera muestra de la movilización de las reservas y el comienzo de este periodo depende la de la temperatura y de la variedad de uva empleada. Por los cortes de poda, la vid “llora” savia. Algunas pierden litros diariamente. Suele producirse en el mes de marzo y es un fenómeno muy curioso de observar tanto por profesionales como por aficionados a la Viticultura. Brote: Las yemas comienzan a hincharse y aparece una borra blanca por lo que a este periodo se le conoce también como “desborre”. Después, las primeras partes verdes llamadas mariposas sustituyen la borra. El brote también depende de la temperatura y la variedad de uva así como de la climatología del invierno. Suele aparecer entre marzo y abril. Crecimiento: El brote da lugar a unos órganos en miniatura (inflorescencias) donde podemos ver claramente el futuro racimo que seguirá creciendo salvo que circunstancias climatológicas negativas interfieran. Se divide, a su vez, en cuatro periodos: 1. Periodo herbáceo o del agraz: Dura unos 50 días y empieza a partir de la fecundación de la flor que puede producirse de dos formas. Si los óvulos de la flor son fecundados por un grano de polen se consigue la uva pirena (con semillas) y si se fecunda solo con el estímulo parcial del grano de polen se obtiene uva apirena (sin semillas) que es muy apreciada para la elaboración de pasas. Cuando este periodo acaba, el racimo es muy pobre en azúcares pero no en acidez. 51 wine_analytics S 2. Periodo del envero: Tiene una duración de un solo día para cada grano de uva y como característica principal observamos un cambio de color en la baya y un cese momentáneo del crecimiento. En este momento, las pepitas alcanzan su madurez fisiológica, es decir, serían capaces de germinar. Un viñedo medio tardaría en enverar totalmente unos 15 días. 3. Periodo de maduración: La uva madura en unos 40 o 50 días aproximadamente. El grano sigue aumentando de tamaño así como en la concentración de azúcares pero la acidez disminuye. Este periodo acaba en el momento estimado para la vendimia. Cómo determinar que la uva está madura, es decir lista para ser vendimiada, es uno de los aspectos más subjetivos en Viticultura pues depende, en gran medida, del interés del técnico además de factores como el color o el peso del grano de uva. Por tener un índice objetivo al margen de las necesidades o el gusto del viticultor, decimos que se basa en dos parámetros: contenido en azúcares y acidez. Comparándolos y valorando las necesidades de la bodega, se obtienen los datos necesarios para decidir la fecha de la vendimia. Es aquí donde wine_analytics tiene una de sus principales aplicaciones. Los factores que influyen en la maduración son de diversa naturaleza: Permanentes: como la variedad cultivada, el clima o el suelo. Variables: dependen de cada año como la humedad, pluviometría, temperatura u horas de luz. Modificables: poda y abonos entre otras labores de cultivo. Accidentales: enfermedades, plagas, heladas, etc. De estos factores y otros de índole enológica depende, en parte, la calificación de las añadas de los vinos. 52 wine_analytics S 4. Periodo de sobremaduración: La cepa deja de aportar a la uva los componentes esenciales y comienza a perder agua por evaporación y, consecuentemente, peso. Los azúcares sin embargo aumentan. Normalmente, la finalidad de la sobremaduración es la obtención de uvas pasas. Caída de la hoja: Cuando la temperatura disminuye, se produce la caída de la hoja pero antes la planta se prepara para el invierno acumulando reservas. Por debajo de 0 ºC, la vid entra en parada vegetativa y permanece en reposo hasta el lloro del nuevo año. 53 wine_analytics S Datos enológicos técnicos Cabe destacar que desde la recogida de la vendimia y las etapas iniciales en la elaboración de los caldos existen varios puntos críticos que afectan muy significativamente a la calidad de toda una cosecha, y estos procesos se producen de forma muy seguida. La sensorización y monitorización continua de estos parámetros minimiza muy significativamente el riesgo durante este período crítico de elaboración. Los parámetros técnicos vitivinícolas considerados clave en la toma de decisiones en el proceso de elaboración se detallan a continuación. Es importante destacar que durante un período muy corto de tiempo han de medirse muchos parámetros, que resultan críticos en la calidad del vino que se quiere producir. La sensorización y automatización de estas medidas optimizan La automatización y sensorización de la toma de temperaturas, de forma que al superar el máximo nivel se automatiza el proceso de remontado13 de homogeneización. Si tras este proceso la temperatura sigue elevada, se pone se en marcha el proceso de refrigeración. Frente a la toma manual o semi-automatizada de temperatura en una bodega tradicional, cada 3-4 horas, la sensorización de la toma de temperatura permite un seguimiento mucho más exhaustivo, evitando la puesta en marcha de la bomba de remontado si no existe una clara tendencia de la temperatura a seguir subiendo (basado en un sencillo modelo analítico). De forma paralela a la temperatura se toman también datos de densidad. El índice de color es un parámetro fundamental y va claramente ligado al índice de polifenoles totales, ligados al vino que se quiere obtener: IPT=47 en el caso del joven roble de Abadía de Haza IPT=70 en el caso del reserva de Abadía de Haza La medida del índice de color se toma al final del proceso de maceración y es uno de los aspectos clave que tomarán como referencia wine_analytics en su modelo. La automatización de la 13 El proceso de remontado consiste en recircular el contenido del líquido (total o parcialmente) de la cuba hasta la parte superior de la misma. 54 wine_analytics S medición mediante espectrofotometría evitará el análisis en el laboratorio de un muestreo aleatorio. Al final del proceso de fermentación se mide también la acidez volátil, cuando ésta tiende a descender. Mediante la monitorización continua de la acidez volátil, cuando ésta no descienda puede predecirse un ataque bacteriano que ponga en riesgo la producción. El control de temperatura permite controlar la parada de la fermentación: T=23-25ºC, en el caso del joven roble de Abadía de Haza T=29-30ºC, en el caso del reserva de Abadía de Haza (se busca una gran extracción del hollejo) La maceración busca una extracción selectiva (taninos, antocianos y aromas fundamentalmente), evitando la extracción de otros compuestos (que transfieren sabores amargos o astringentes). Consta de dos etapas, disolución y difusión, en las que es fundamental una medición exhaustiva. La duración de la maceración afecta de forma distinta a los polifenoles y antocianos, y está íntimamente relacionada con el IPT: Para el joven roble de Abadía de Haza: IPT=47 y una elevada intensidad colorante, contenido polifenólico bajo y maceración corta. Para el reserva de Abadía de Haza: IPT=70 y menor colorante, contenido polifenólico alto y maceración larga. En esta extracción selectiva que es la maceración inicialmente se extraen los antocianos, para ello no hace falta alcohol. Posteriormente se empiezan a extraer los taninos de los hollejos, y finalmente de las pepitas (para no generar sabores amargos). La temperatura favorece la maceración, por lo que es (de nuevo) uno de los aspectos claves a tener en cuenta, así como el grado alcohólico que se medirá a lo largo de todo el proceso. Una vez que el vino ha macerado en las cubas el tiempo necesario, se procede al descube. La definición de tiempo necesario, más allá de las mediciones sensóricas se complementará con los análisis clásicos. Este procedimiento dual permitirá el análisis para definir correlaciones y extrapolarlo a futuras cosechas. 55 wine_analytics S En el momento del descube se generan dos fracciones, vino-yema y orujos, y se producirá en dos momentos distintos en función de la crianza que ha de desarrollar: Coincidiendo con el final de la fermentación alcohólica, para el joven roble de Abadía de Haza Después de la fermentación alcohólica (incluso 2-3 semanas), para el reserva de Abadía de Haza La medición continua del grado de alcohol / temperatura y azúcares para evaluar el final de la fermentación alcohólica es otro de los parámetros clave que entran en el modelo de wine_analytics. 56 wine_analytics S Comparativa de Bases de datos NoSQL El objetivo de este anexo es presentar una comparativa entre las algunas de las más populares BB.DD NoSQL y determinar la mejor elección para determinados casos de uso. En concreto, nos interesa encontrar la más idónea para analizar y almacenar datos desestructurados de múltiples fuentes de forma que puedan ser útiles, entre otras cosas, para obtener predicciones. Introducción Cuando pensamos en bases de datos relacionales a nuestra mente suelen acudir los mismos nombres. En la parte comercial tenemos Oracle y Microsoft SQL Server. Del lado del software libre, tenemos opciones como PostgresSQL o MySQL. Aunque cada una tiene sus peculiaridades, para un desarrollador no es difícil elegir entre un sistema y otro. Al final todo son tablas, columnas, claves primarias, y sobre todo, consultas SQL. La decisión de cuál elegir, se basará en sus características y precio. Si hablamos de bases de datos NoSQL, la cosa se complica. A día de hoy existen unos 150 sistemas de bases de datos NoSQL. Elegir uno de ellos puede ser muy difícil, ya que ninguno ha obtenido todavía la fama que sí han conseguido las bases de datos relacionales. Pero el problema principal que encontramos, es que aunque todas se denominan NoSQL, en realidad hay diferentes tipos. Dependiendo de lo que necesitemos, deberemos decantarnos por una u otra. Diferencias con las BBDD SQL Algunas de las diferencias más destacables que nos podemos encontrar entre los sistemas NoSQL y los sistemas SQL son: No utilizan SQL como lenguaje de consultas. La mayoría de las bases de datos NoSQL evitan utilizar este tipo de lenguaje o lo utilizan como un lenguaje de apoyo. Por poner algunos ejemplos, Cassandra utiliza el lenguaje CQL, MongoDB utiliza JSON o BigTable hace uso de GQL. No utilizan estructuras fijas como tablas para el almacenamiento de los datos. Permiten hacer uso de otros tipos de modelos de almacenamiento de información como sistemas de clave–valor, objetos o grafos. 57 wine_analytics S No suelen permitir operaciones JOIN. Al disponer de un volumen de datos tan extremadamente grande suele resultar deseable evitar los JOIN. Esto se debe a que, cuando la operación no es la búsqueda de una clave, la sobrecarga puede llegar a ser muy costosa. Las soluciones más directas consisten en desnormalizar los datos, o bien realizar el JOIN mediante software, en la capa de aplicación. Arquitectura distribuida. Las bases de datos relacionales suelen estar centralizadas en una única máquina o bien en una estructura máster–esclavo, sin embargo en los casos NoSQL la información puede estar compartida en varias máquinas mediante mecanismos de tablas Hash distribuidas. SQL o NoSQL Algunas de las razones que nos pueden llevar a decantarnos por el uso de las bases de datos NoSQL en lugar de las clásicas SQL son: Cuando el volumen de los datos crece muy rápidamente en momentos puntuales, pudiendo llegar a superar el Terabyte de información. Cuando la escalabilidad de la solución relacional no es viable tanto a nivel de costes como a nivel técnico. Cuando tenemos elevados picos de uso del sistema por parte de los usuarios en múltiples ocasiones. Cuando el esquema de la base de datos no es homogéneo, es decir, cuando en cada inserción de datos la información que se almacena puede tener campos distintos. Tipos de BBDD NoSQL Aunque hay varias aproximaciones diferentes para clasificar las bases de datos NoSQL (Teorema CAP, basándonos en el modelo de datos etc.), en general se considera que existen cuatro tipos diferentes: orientadas a documentos, orientadas a columnas, de clave-valor y en grafo. Así que veamos en qué consisten estos sistemas, para que podamos elegir la opción que mejor se adapte a nuestras necesidades. 58 wine_analytics S Orientadas a Documentos Son aquellas que gestionan datos semi-estructurados. Es decir documentos. Estos datos son almacenados en algún formato estándar como puede ser XML, JSON o BSON. Para hacernos una idea un documento suele ser algo parecido a: Son las bases de datos NoSQL más versátiles. Se pueden utilizar en gran cantidad de proyectos, incluyendo muchos que tradicionalmente funcionarían sobre bases de datos relacionales. En esta categoría encontramos: MongoDB: probablemente la base de datos NoSQL más famosa del momento. En octubre del año pasado, MongoDB conseguía 150 millones de dólares en financiación, convirtiéndose en una da las startups más prometedoras. Algunas compañías que actualmente utilizan MongoDB son Foursquare o eBay. CouchDB: es la base de datos orientada a documentos de Apache. Una de sus interesantes características es que los datos son accesibles a través de una API Rest. Este sistema es utilizado por compañías como Credit Suisse y la BBC. Orientadas a Columnas Son aquellas que gestionan datos semi estructurados. Es decir documentos. Estos datos son almacenados en algún formato estándar como puede ser XML, JSON o BSON. Para hacernos una idea un documento suele ser algo parecido a: 59 wine_analytics S Este tipo de bases de datos están pensadas para realizar consultas y agregaciones sobre grandes cantidades de datos. Funcionan de forma parecida a las bases de datos relacionales, pero almacenando columnas de datos en lugar de registros. En esta categoría encontramos: Cassandra: incluida en esta sección, aunque en realidad sigue un modelo híbrido entre orientada a columnas y clave-valor. Es utilizada por Facebook y Twitter (aunque dejaron de usarla para almacenar tweets). HBase: Escrita en Java y mantenida por el Proyecto Hadoop de Apache, se utiliza para procesar grandes cantidades de datos. La utilizan Facebook, Twitter o Yahoo. De Clave Valor Estas son las más sencillas de entender. Simplemente guardan tuplas que contienen una clave y su valor. Cuando se quiere recuperar un dato, simplemente se busca por su clave y se recupera el valor. 60 wine_analytics S En esta categoría encontramos: DynamoDB: desarrollada por Amazon, es una opción de almacenaje que podemos usar desde los Amazon Web Services. La utilizan el Washington Post y Scopely. Redis: desarrollada en C y de código abierto, es utilizada por Craiglist y Stack Overflow (a modo de caché). En Grafo BBDD que utilizan la topología de la teoría de grafos con nodos y aristas para representar los datos almacenados (Graph DataBase). Son muy útiles para guardar información en modelos con muchas relaciones, como redes y conexiones sociales. En esta categoría encontramos: Infinite Graph: escrita en Java y C++ por la compañía Objectivity. Tiene dos modelos de licenciamiento: uno gratuito y otro de pago. Neo4j: base de datos de código abierto, escrita en Java por la compañía Neo Technology. Utilizada por compañías como HP, Infojobs o Cisco. Benchmark de BBDD NoSQL Analizando los tipos de BBDD NoSQL, encontramos que las que más se adaptan a nuestros posibles casos de uso son las siguientes: Columnar: Cassandra y HBase 61 wine_analytics S Clave valor: Redis y DynamoDB Documental: MongoDB En Grafo: Neo4j 1. Características Generales Para las comparativas utilizaremos dos categorías como son la popularidad y el rendimiento. 62 wine_analytics S 2. Popularidad Método de cálculo de las puntuaciones de los DB-Motores Clasificación La clasificación DB-Engines es una lista de los sistemas de gestión de bases de datos clasificados según su popularidad actual. Medimos la popularidad de un sistema mediante el uso de los siguientes parámetros: Número de menciones del sistema en los sitios web, medida como el número de resultados de motores de búsqueda consultas. Por el momento, utilizamos Google y Bing para esta medición. Con el fin de contar con resultados sólo pertinentes, estamos en busca de "<nombre del sistema> base de datos", por ejemplo, "Base de datos de Oracle". El interés general en el sistema. Para esta medición, se utiliza la frecuencia de búsquedas en Google Trends. Frecuencia de las discusiones técnicas sobre el sistema. Utilizamos el número de preguntas relacionadas y el número de usuarios interesados en la conocida TI relacionada Q & A sitesStack Desbordamiento y DBA Stack Exchange. El número de ofertas de trabajo, en los que se menciona el sistema. Utilizamos el número de ofertas en los principales motores de búsqueda de trabajo hecho y Simply Hired. El número de perfiles en redes profesionales en el que el sistema es mencionado utiliza la red profesional internacional más popular: LinkedIn. Relevancia en las redes sociales. Contamos el número de tweets de Twitter, en la que se menciona el sistema. Calculamos el valor popularidad de un sistema mediante la estandarización y un promedio de los parámetros individuales. Estas transformaciones matemáticas se hacen en una forma de manera que se conserva la distancia de los sistemas individuales. Eso significa que, cuando el sistema A tiene el doble de un valor en el DB-Engine que en el sistema B, entonces es dos veces más popular cuando se promedian sobre los criterios de evaluación individuales. La clasificación DB-Engine no mide el número de instalaciones de los sistemas, o su uso dentro de los sistemas de TI. Es de esperar, que un aumento de la popularidad de un sistema de medida DBEngine (por ejemplo, en las discusiones o las ofertas de empleo), preceda a una amplia gama de usos correspondiente del sistema por un determinado factor tiempo. Debido a esto, la clasificación DB-Engine puede actuar como un indicador temprano. 63 wine_analytics S DB-Engines Ranking Tendencia de Cassandra vs. DynamoDB vs. HBase vs. Redis vs. MongoDB vs. Neo4j La clasificación DB-Engines clasifica los sistemas de gestión de base de datos en función de su popularidad. Este es un diagrama de tendencia parcial de la clasificación completa mostrando sólo Cassandra vs. DynamoDB vs. HBase vs. Redis vs. MongoDB vs. Neo4j Detalles Cassandra DynamoDB HBase Redis MongoDB Neo4j X Nombre Hosted, BBDD en servicio de Columnar memoria con Columnar base de datos basada en opciones basada en escalable por Descripción conceptos de Una de las más configurables conceptos de Amazon con BigTable de BigTable los datos y DynamoDB BD en Grafos populares BBDD rendimiento y Hadoop almacenados vs. en la nube persistencia 64 OpenSource documentales wine_analytics S DB-Engines Ranking Rank Score 8 98.75 Rank Score 30 13.09 Rank Score 14 53.59 cassandra.apa aws.amazon.c hbase.apache. che.org om/dynamodb org Website Rank Score 10 94.24 redis.io Rank 5 Score 250.90 www.mongodb.org Rank 23 Score 24.42 neo4j.com aws.amazon.c redis.io/Documentació www.datastax om/- hbase.apache. docs.mongodb.org/ neo4j.com/docs/documentatio n Técnica .com/docs documentatio org manual stable MongoDB, Inc Neo Technology n n/dynamodb Apache Apache Salvatore Desarrollador Software Amazon Software Sanfilippo Foundation Foundation Año de 2008 2012 2008 2009 2009 2007 Open Source commercial Open Source Open Source Open Source Open Source no Sí no no no no Java C C++ Java BSD Linux Linux OS X OS X Solaris Windows Windows publicación Licencia Database as a Service (DBaaS) Lenguaje de Java Programación BSD Sistemas Linux Linux Operativos hosted Unix OS X Compatibles Linux OS X Windows Windows Windows Modelo de Columnar Clave-valor Columnar Clave-valor Documental En Grafos DBMS schema-free schema-free schema-free schema-free schema-free schema-free Sí Sí no no Sí Sí restricted no no no Sí Sí BBDD Esquema de datos Typing Índices Secundarios 65 wine_analytics S SQL no no no no no Java API no Cypher query APIs y otros Proprietary RESTful HTTP RESTful HTTP proprietary proprietary language protocol API API protocol protocol using JSON Java API métodos de acceso Thrift RESTful HTTP API Actionscript C C# C++ C Clojure C# ColdFusion C++ D Clojure C# Dart Dart C++ .Net Clojure ColdFusion C Go Erlang C# Haskell Groovy C++ Java Java Groovy JavaScript JavaScript Java Lisp Perl PHP Lua PHP Python Objective-C Python Scala Perl Erlang Go Lenguajes de programación soportados Delphi .Net Erlang Clojure Go Go Groovy Groovy Haskell Java Java JavaScript JavaScript Perl Lisp PHP Lua Python MatLab Ruby Perl Scala Erlang Haskell Java JavaScript Perl PHP Python Ruby PHP Ruby Python Scala PHP Ruby PowerShell Scala Prolog Smalltalk Python Tcl R Ruby Scala Smalltalk Server-side no no Sí scripts 66 Lua JavaScript Sí wine_analytics S Triggers Sí no Sí no no Sí Sharding Sharding Sharding none Sharding none Master-slave Master-slave Master-slave replication replication replication no Sí no Métodos de particionamie nto selectable selectable Métodos de replication Sí replication replicación factor MapReduce factor Sí no Eventual Eventual Conceptos de Consistency Consistency Immediate Consistency Eventual consistencia Immediate Immediate Consistency Immediate Consistency Consistency Consistency no no no no no no Foreign keys Sí Eventual Consistency Conceptos de no no yes no ACID optimistic transacción locking Concurrencia Sí Sí Sí Sí Sí Sí Durabilidad Sí Sí Sí Sí Sí Sí Los permisos de acceso para usuarios y Se pueden roles se definir pueden definir Muy Simple Listas de Conceptos de Derechos de acceso Control de permisos por a través de la control de acceso para usuarios y acceso por usuario y AWS Identidad acceso (ACL) roles credenciales objeto y Administració n de Acceso (IAM) 67 no wine_analytics S 3. Rendimiento Vs Redis vs DynamoDB Cuando hay tantas empresas, organizaciones y usuarios que utilizan estas dos data-stores de clave-valor, es probablemente porque cada una tiene algo que ofrecer - y algo diferente en cada caso. La elección entre ellos dependerá de los requisitos o limitaciones individuales. Los puntos de partida son los siguientes: Redis es en memoria y disyuntiva configurable entre la persistencia y el rendimiento DynamoDB es un servicio de data warehouse de clave-valor de Amazon. Antes de entrar en detalle comparativo, vale la pena enumerar las cosas que son comunes a todos ellos: Apoya a la manipulación simultánea de datos (concurrencia) Son sin esquema Sin embargo, no son compatibles con SQL Y no ofrecen claves externas (es decir, la integridad referencial o evitar la introducción de datos inconsistentes). Éstas difieren en varios otros aspectos: Licencias (DynamoDB está comercialmente licencia, Redis son Open Source) Los índices secundarios (DynamoDB) Los scripts de servidor (Redis) Tipos de APIs que ofrecen y lenguajes de programación soportados Coherencia (DynamoDB para su eventual e inmediata) Funcionalidad de MapReduce (una opción para DynamoDB) Idoneidad para el procesamiento de transacciones (Redis ofrece bloqueo optimista) Durabilidad o persistencia de los datos Razones para elegir Redis Como solución in-memory, Redis ofrece una buena solución para el almacenamiento de datos transitorios, como fichas y datos handshake, además posee un buen organismo de control para 68 S wine_analytics limitar el uso de la API del sistema. La lectura/escritura de los datos es muy rápida, pero se produce con gran volumen y frecuencia. La latencia puede mantenerse baja y el riesgo de pérdida de datos es aceptable. Redis también ofrece mecanismos configurables para persistencia. Sin embargo, el aumento de la persistencia tenderá a aumentar la latencia y la disminución de rendimiento. Redis soporta cinco estructuras de datos diferentes que le permiten manejar entidades tales como conjuntos ordenados y datos de series de tiempo. Otro punto fuerte es la variedad de lenguajes de programación con la que es compatible. Razones para elegir DynamoDB La diferencia inmediata de DynamoDB es que es un servicio alojado en la nube. Además de eliminar la necesidad de los clientes para crear sus propios servidores, su PaaS (Plataforma como Servicio) hace que sea inmediatamente escalable. El rendimiento concurrente es alto y la disponibilidad está asegurada a través de los múltiples centros de datos de AWS (Amazon Web Services). Una vez que has entendido las reglas con las que DynamoDB, el rendimiento es predecible. Amazon cuenta con medios de comunicación móviles, publicidad en línea y juegos de azar entre sus aplicaciones de los clientes estrella, con millones de usuarios atendidos. Otras posibles aplicaciones incluyen registradores de clics corrientes en general (no sólo de publicidad), almacenamiento de sesión de usuario de aplicación, y la duplicación de datos intermedios. Cassandra vs HBase Vs Después de mirar tanto Cassandra y HBase, hay una tendencia natural a preguntarse cuál es mejor. Esta no es una decisión fácil de tomar. Si tiene experiencia en bases de datos y en administración del servidor de base de datos sus prioridades y preferencias podrían ser muy diferentes de alguien que aborda su primera configuración NoSQL a gran escala; en lugar de comparar aspectos muy técnicos que pueden no ser útiles, vamos a comparar las dos BBDD de un modo más general: Instalación Soluciones a nivel empresarial como Cassandra y HBase van claramente a ser un poco más difícil de instalar y configurar que los productos más pequeños como RavenDB. Instalación HBase se complica al tener que instalar todos sus componentes clave por separado. Y debido a que por lo general se ejecuta en el sistema de archivos distribuidos Hadoop (HDFS), esto añade una capa 69 S wine_analytics adicional de complejidad si usted no está utilizando el software. Cassandra instala todos sus componentes clave en una, proceso relativamente simple, la instalación. Sin embargo, vale la pena señalar que se puede ejecutar sin HBase HDFS (aunque todavía se requiere para sistemas totalmente distribuidos), y se puede ejecutar Cassandra con él. Así que, como se dice, su experiencia puede variar. Documentación Documentación de usuario final de HBase no es muy numerosa, e incluso puede ser desagradable para algunos usuarios nuevos. Esta es un área donde DataStax (distribuidores de sus propias ediciones de Cassandra) se han dedicado mucho esfuerzo. La documentación para DataStax Cassandra es mucho más legible y accesible, y sus programas de capacitación gratuita, en línea son una ventaja. Estos materiales son útiles incluso si no se está utilizando una versión DataStax de la base de datos. Herramientas de administración Ambas bases de datos tienen más o menos las mismas herramientas - interfaces de línea de comandos, herramientas de gestión basadas en la web, y soluciones de monitoreo. En términos de funcionalidad, no hay suficiente diferenciación real entre estas herramientas para decir objetivamente que un conjunto es sustancialmente mejor que el otro. Programación Ambas bases de datos están escritas en Java y tienen bibliotecas de cliente para la mayoría de los mismos lenguajes de programación. En la versión 3.0, Cassandra apoyará las funciones definidas por el usuario y ha apoyado disparadores desde la versión 2.0. Si no puede esperar a la versión 3.0 y no necesita un lenguaje de consulta similar a SQL, entonces HBase es actualmente un poco más capaz. Rendimiento En pruebas más independientes, Cassandra es un claro ganador en términos de su rendimiento general. Pero eso no quiere decir HBase es lento, ni mucho menos. Mientras Cassandra está optimizado para la escritura de datos, HBase está optimizado para la lectura de datos y, a veces 70 wine_analytics S se ha demostrado que es un poco más rápido en las aplicaciones read-hard. Aunque en general, Cassandra es el producto de mejor rendimiento. Escalabilidad Ambas soluciones están concebidas como sistemas altamente disponibles y escalables, a nivel de empresa, y por lo que es bastante difícil de juzgar entre ellos en esta área. HBase escalas muy bien horizontal (aunque no sin esfuerzo por parte del administrador del sistema), mientras que el límite de filas de tamaño de Cassandra podría ser un problema en algunos casos raros. Sin embargo, la diferencia clave entre los dos viene cuando necesita datos consistentes garantizados a través de todos los nodos del clúster. Modelo de consistencia de Cassandra "eventual" hace de este un poco más difícil de conseguir, a pesar de la administración de nodo que es sustancialmente más fácil que con HBase. Más Detalles Redis (v2.8) Escrito en: C Dato: Blazing rápido Licencia: BSD Protocolo: tipo telnet, segura con material binario Disco con respaldo de base de datos en memoria, El tamaño del conjunto de datos limitado a la RAM del ordenador (pero puede abarcar RAM múltiples máquinas con clustering) Replicación maestro-esclavo, failover automático Los valores simples o estructuras de datos de claves pero las operaciones complejas como ZREVRANGEBYSCORE. INCR & co (bueno para la limitación de velocidad o estadísticas) Operaciones de bits (por ejemplo, para implementar filtros floración) Tiene conjuntos (al mismo tiempo unión / diferencias / inter) Tiene listas (también una cola; bloqueo de ventanas emergentes) Tiene hashes (objetos de campos múltiples) Conjuntos Ordenado (tabla de puntuación, bueno para consultas de rango) Capacidades de scripting Lua (!) 71 wine_analytics S Tiene transacciones (!) Los valores se pueden configurar para expirar (como en una memoria caché) Resto bar / Sub permite un implemento de mensajería Mejor uso: Para cambiar rápidamente los datos con un tamaño de base de datos previsible (debe encajar en su mayoría en la memoria). Ejemplo: Para almacenar las cotizaciones en tiempo real. Análisis en tiempo real. Tablas de clasificación. La comunicación en tiempo real. Y donde quiera que utilizó memcached antes. Cassandra (2.0) Escrito en: Java Dato: Tienda enormes conjuntos de datos en "casi" SQL Licencia: Apache Protocolo: CQL3 y Ahorro CQL3 es SQL muy similares, pero con algunas limitaciones que provienen de la escalabilidad (en particular: No JOIN, no hay funciones de agregación) CQL3 es ahora la interfaz oficial. No mirar Thrift, a menos que se esté trabajando en una aplicación de legado. De esta manera, se puede vivir sin entender ColumnFamilies, SuperColumns, etc. Consulta con la tecla, o rango de teclas (índices secundarios también están disponibles) sintonizables compensaciones para la distribución y reproducción (N, R, W) Los datos pueden tener caducidad (juego en INSERT). La escritura puede ser mucho más rápida que la lectura (cuando las lecturas se han unido en el disco) Map / reduce posible con Hadoop Todos los nodos son similares, a diferencia de Hadoop / HBase Muy buena y fiable replicación cruzada centro de datos Distribuido contador tipo de datos. Puede escribir disparadores en Java. Mejor usado: Cuando se necesita almacenar una gran cantidad de datos y quiere conservarse una interfaz amigable. Por ejemplo: La analítica web, para contar los accesos por hora, por el navegador, a través de IP, etc. El registro de transacciones. La recolección de datos a partir de grandes conjuntos de sensores. 72 wine_analytics S Cassandra HBase Carece de concepto de una tabla. Toda la documentación le dirá que no es común tener múltiples keyspaces. Eso significa que usted tiene que compartir un espacio clave en un clúster. Además de añadir un espacio de claves requiere un reinicio del clúster! El concepto de la Tabla existe. Cada tabla tiene su propio espacio de claves. Se puede agregar y quitar tablas con la misma facilidad que un RDBMS. Utiliza claves de cadena. Muy común el uso de UUID como las keys. Puede utilizar TimeUUID si desea que sus datos estén ordenados por tiempo. Utiliza claves binarias. Es común combinar tres elementos diferentes entre sí para formar una clave. Esto significa que usted puede buscar por más de una clave en una give-table. Incluso si utiliza TimeUUID, como Cassandra balancea las solicitudes de los clientes, no se producen problemas de hot spotting. (Todas las solicitudes de los clientes que van a un servidor en un clúster se conoce como un problema de hot spot). Si el primer componente de su clave es el tiempo o un número secuencial, entonces se producirá un problema de hot spotting. Todas las nuevas claves se insertarán en una región hasta que ésta se llena (de ahí el hot spotting). Ofrece clasificación de columnas No ofrece clasificación de columnas El concepto de Supercolumn le permite No tiene Supercolumns. Pero se puede diseñar esquemas muy flexibles, muy diseñar una supercolumn, ya que tanto complejos. la estructura como los nombres y valores de columna son binarios. No tiene ningún método para incrementar Ofrece un método el elemento el valor de un elemento de una columna. agradable para incrementar los contadores. Muy adecuado para la agregación de datos. Soporta Map Reduce. Se necesita un Map Reduce es nativo. HBase está cluster Hadoop para ejecutarlo. Los datos construido sobre Hadoop. Los datos no serán transferidos desde el clúster de se transfieren. Cassandra al clúster de Hadoop. No es muy adecuado ejecutar Jobs muy pesados sobre datos Map Reduce. Fácil de mantener si no tiene Hadoop. Complicado de mantener ya que tiene muchas piezas en movimiento, como Zookeeper, Hadoop y la propia HBase. No tiene una API de Java nativa. Aunque Tiene una bonita API de Java nativo. Se está escrito en Java, tiene que utilizarse siente mucho más el sistema java que Thrift para comunicarse con el clúster. el de Cassandra. HBase tiene una interfaz óptima para otros lenguajes también. 73 wine_analytics S Cassandra HBase No hay ningún servidor maestro, por lo Aunque no existe un concepto de un tanto, ningún punto único de fallo. servidor maestro, HBase no es muy pesado. Un clúster de HBase puede seguir sirviendo datos incluso si el maestro se cae. Hadoop NameNode es un único punto de fallo. Conclusiones Al igual que con cualquier comparación entre dos grandes sistemas, experiencia previa y preferencia personal pueden ser claves para decidir qué producto utilizar. Ambos tienen una gran cantidad de usuarios leales. Los requisitos de su aplicación específica son un factor más importante que los comentarios generales en las seis áreas anteriores. Sin embargo, la facilidad de Cassandra de instalación y significativamente mejores recursos de documentación y formación lo distinguen de HBase. Para los nuevos usuarios, la documentación es muy importante y HBase se encuentra ahí ausente. Que el aumento de la "amigabilidad" de Cassandra también viene con ganancias generales de rendimiento da Cassandra la "victoria" en este punto. Vs Cassandra vs DynamoDB Tal vez son unas palabras demasiado atrevidas, pero sin duda una gran comparación de Cassandra y Amazon DynamoDB es la de Jonathan Ellis (presidente de Cassandra y fundador de DataStax): “Como ingeniero, es agradable ver tantas decisiones de diseño de Cassandra imitadas por la próxima generación de productos NoSQL de Amazon. Me siento como un tío orgulloso, pero en muchos aspectos importantes, Cassandra conserva una ventaja firme en el poder y la flexibilidad.” Amazon DynamoDB, es una base de datos alojada en Amazon Web Services. Con DynamoDB, Amazon y Cassandra llegan al punto de partida: al igual que Cassandra se inspiró en 2007 en el papel de Dynamo de Amazon, DynamoDB ha adoptado muchas de las mejoras que Cassandra ha hecho desde entonces. 74 S wine_analytics Comparativa de Cassandra vs DynamoDB Tanto Cassandra y DynamoDB logran un alto grado de escalabilidad utilizando muchas de las mismas técnicas. Cassandra se ha demostrado que escala a millones de ops / s, y Amazon anunció que su cliente hace más de 250.000 op / s en DynamoDB. La historia de la disponibilidad de múltiples centros de datos es un poco más compleja. DynamoDB replica los datos "a través de múltiples zonas de disponibilidad en una región", pero la región cruz no es compatible. Desde zonas de disponibilidad no se dispersan geográficamente, necesita replicación cruzada región si usted está preocupado acerca de las interrupciones que afectan a regiones enteras o si desea proporcionar latencias de datos locales a todos sus clientes en cualquier región. Esto requiere el tipo de control preciso sobre la consistencia de datos se ve en Cassandra. El modelo de datos es un área donde DynamoDB es mucho más cercano a Cassandra que al Dynamo originales. El diseño original Dynamo tenía un modelo primitivo de clave / valor de los datos, que tiene graves consecuencias: para actualizar un solo campo, todo el valor se debe leer, actualizado y re-escrita. (Otras bases de datos NoSQL han injertado una API de documento en un motor clave / valor, lo que es una de las razones de su rendimiento se resiente en comparación con Cassandra.) Otra consecuencia directa está requiriendo relojes vectoriales complejos para manejar conflictos de actualizaciones simultáneas a campos separados. Cassandra fue una de las primeras bases de datos NoSQL para ofrecer un modelo más potente de datos ColumnFamily, que DynamoDB de asemeja fuertemente. Sin embargo, los índices secundarios fueron una de las características mejor recibidas, cuando Cassandra les presentó hace un año. Como Cassandra, DynamoDB ofrece integración Hadoop para consultas analíticas. No está claro si DynamoDB también es capaz de particionar las cargas de trabajo de análisis a un grupo separado de las máquinas de la misma manera que con Cassandra y DataStax Enterprise. En tiempo real y las cargas de trabajo analíticas tienen muy diferentes características de rendimiento, por lo que la partición de ellos para evitar conflictos de recursos, es necesario en los volúmenes de solicitud de alta. 75 S wine_analytics Hadoop está convirtiendo rápidamente en el estándar de la industria para análisis de datos grandes, así que tiene sentido para ofrecer apoyo Hadoop en lugar de una API personalizada incompatibles. Vale la pena señalar que Cassandra apoya cerdo, así como de la colmena en la parte superior de Hadoop. Mucha gente piensa cerdo es una mejor opción para el mapa subyacente / reducir motor. Cassandra ha estado en producción en muchos entornos exigentes desde hace años, así que no es sorpresa que Cassandra tiene una ventaja sustancial en la prestación del mundo real características como copia de seguridad. Motor de almacenamiento de Cassandra logestructurado - que es también la razón por la que Cassandra corre tan bien sin SSDs - permite que ambas copias de seguridad completas e incrementales sin impacto en el rendimiento. (A continuación, puede cargar sus archivos de copia de seguridad con una herramienta como tablesnap). 76 wine_analytics S HBase vs. Cassandra vs. Redis Vs Vs Database Categoría Database Database In Memory/ Management Preferencia Website Licencia 28% votos 34% votos 38% votos hbase.apache.org Cassandra.apache.org redis.io Apache License 2 Apache License 2 BSD-License Diseño Key-value Column-oriented Column-oriented Key-value Key-value Database model Schema-less Publish/Subscribe ExFat Volatile memory Data storage local File System File System File System Exportable No Sí 77 No wine_analytics S Características API calls API calls Lenguaje de Consulta REST API calls CQL XML Lua Thrift Thrift All MySQL JSON Tipo de datos BLOB BLOB Data structures user-defined STATIC COLUMN Actualizaciones entrada condicional Sí Sí Sí Map / Reduce Sí Sí No Unicode Sí Sí Sí TTL para entradas Sí Sí Sí Compresión Sí Sí Sí 78 wine_analytics S Integridad Modelo de Integridad Log Replication BASE ? Atomicidad Sí Sí Sí Consistencia Sí Sí Sí Aislamiento Sí Sí Sí Durabilidad (almacenamiento de datos) Sí Sí Sí Transacciones No No Sí Integridad Referencial No No No Control de revisión Sí Sí No MVCC MVCC Modelo de bloqueo Lock Free Model Optimistic Locking 79 wine_analytics S Indexación Índices secundarios Sí Sí No Claves compuestas Sí Sí No Búsqueda de texto completo No No No Índices Geoespaciales No No No Soporte Gráfico No No No Distribución Horizontal Escalable Sí Sí Sí Replicación Sí Sí Sí Modo de replicación Master-Slave Replication Master-Master Replication Master-Slave Replication 80 wine_analytics S Sharding Sí Sí Sí Shared nothing architecture Sí Sí Sí Restricciones Tamaño de valor máximo 2 TB 2 GB 512 MB Requerimientos del sistema Sistema operativo Controlador nativo *NIX Java Cross-platform Cross-platform Java (any JVM scripting language) JavaScript/Node.js Python go Ruby Perl PHP Erlang Lua Scala C++ Clojure C# .NET Framework C# Actionscript 3.0 C# C++ Clojure Common Lisp D Lang Dart Erlang Fancy go Haskell Haxe io Java JavaScript Lua Objective-C Perl PHP 81 wine_analytics S Pure Data Python Ruby Scala Scheme Smalltalk Tcl Memoria mínima ? 4 GB 3 MB Arquitectura Sistema de programación Java (any JVM scripting language) Java C# Más Descripción Marca Una base de datos distribuida basada en Hadoop Apache Base de datos distribuida de segunda generación Apache Almacén de estructuras de datos en memoria ? Sistema multiusuario Sí Sí Sí Estandarización No ? ? 82 wine_analytics S Tarball Distribución de software Tarball Package management system Package management system Fecha De Lanzamiento 2ⁿᵈ February 2008 2008 ? Nivel de documentación disponible ★★★★☆ ★★★★☆ ★★★★★ RESTful Sí No Sí Contador Distribuido Sí Sí Sí Gratis Sí Sí Sí Activo Sí Sí Sí Pooling de conexiones Sí Sí Sí Analítica en tiempo real Conditional Sí Sí 83 wine_analytics S Interfaz Web Sí Sí ? Good Good Basic Copia de seguridad online No Sí Sí Índices parciales No ? ? Log Sí Sí Sí www.apache. org/dyn/closer. cgi/hbase/ Cassandra.apache.org/ download/ redis.io/download Basic Good Good No ? Sí Facilidad de uso ★★★★☆ ★★★★☆ ★★★★★ Gratis para uso comercial Sí Sí Sí API Descarga Funcionalidad de Backup Query Cache 84 wine_analytics S Órdenes No Sí Sí Colectores No No Sí Configuración de rutinas de escritura Sí Sí Sí Preferencias de lectura Sí Sí No Open Source Sí Sí Sí Rendimiento ★★★★☆ ★★★★☆ ★★★★★ Pipeline Aggregation Sí ? Sí Soporte de Spring Sí Sí Sí Procedimientos almacenados No No No Auto-Sharding Sí Sí No 85 wine_analytics S Object-Relational Mapping (ORM) ? Soporte de la plataforma en la nube ? In-Place Update ? Sí ? Caché de ensamblados global ? Sí ? Triggers ? Sí No Server Side Java Script ? No Sí Flexible Table(Schema) ? Sí Sí Re-Reduce ? Sí No Extension/Plug-in ? ? Sí HBase Cassandra Redis Sí Amazon EC2 Rackspace Cloud 86 Sí Heroku Cloud Foundry wine_analytics S MongoDB vs Neo4j Vs MongoDB es una base de datos orientada a documentos. Esto quiere decir que en lugar de guardar los datos en registros, guarda los datos en documentos. Estos documentos son almacenados en BSON, que es una representación binaria de JSON. Una de las diferencias más importantes con respecto a las bases de datos relacionales, es que no es necesario seguir un esquema. Los documentos de una misma colección – concepto similar a una tabla de una base de datos relacional -, pueden tener esquemas diferentes. Imaginemos que tenemos una colección a la que llamamos Personas. Un documento podría almacenarse de la siguiente manera: { Nombre: "Pedro", Apellidos: "Martínez Campo", Edad: 22, Aficiones: ["fútbol","tenis","ciclismo"], Amigos: [ { Nombre:"María", Edad:22 }, { Nombre:"Luis", Edad:28 } ] } El documento anterior es un clásico documento JSON. Tiene strings, arrays, subdocumentos y números. En la misma colección podríamos guardar un documento como este: 87 S wine_analytics { Nombre: "Luis", Estudios: "Administración y Dirección de Empresas", Amigos:12 } Este documento no sigue el mismo esquema que el primero. Tiene menos campos, algún campo nuevo que no existe en el documento anterior e incluso un campo de distinto tipo. Esto que es algo impensable en una base de datos relacional, es algo totalmente válido en MongoDB. ¿Cómo funciona MongoDB? MongoDB está escrito en C++, aunque las consultas se hacen pasando objetos JSON como parámetro. Es algo bastante lógico, dado que los propios documentos se almacenan en BSON. Por ejemplo: db.Clientes.find({Nombre:"Pedro"}); La consulta anterior buscará todos los clientes cuyo nombre sea Pedro. MongoDB viene de serie con una consola desde la que podemos ejecutar los distintos comandos. Esta consola está construida sobre JavaScript, por lo que las consultas se realizan utilizando ese lenguaje. Además de las funciones de MongoDB, podemos utilizar muchas de las funciones propias de JavaScript. En la consola también podemos definir variables, funciones o utilizar bucles. Si queremos usar nuestro lenguaje de programación favorito, existen drivers para un gran número de ellos. Hay drivers oficiales para C#, Java, Node.js, PHP, Python, Ruby, C, C++, Perl o Scala. Aunque estos drivers están soportados por MongoDB, no todos están en el mismo estado de madurez. Por ejemplo el de C es una versión alpha. Si queremos utilizar un lenguaje concreto, es mejor revisar los drivers disponibles para comprobar si son adecuados para un entorno de producción. 88 S wine_analytics ¿Dónde se puede utilizar MongoDB? Aunque se suele decir que las bases de datos NoSQL tienen un ámbito de aplicación reducido, MongoDB se puede utilizar en muchos de los proyectos que desarrollamos en la actualidad. Cualquier aplicación que necesite almacenar datos semi estructurados puede usar MongoDB. Es el caso de las típicas aplicaciones CRUD o de muchos de los desarrollos web actuales. Eso sí, aunque las colecciones de MongoDB no necesitan definir un esquema, es importante que diseñemos nuestra aplicación para seguir uno. Tendremos que pensar si necesitamos normalizar los datos, desnormalizarlos o utilizar una aproximación híbrida. Estas decisiones pueden afectar al rendimiento de nuestra aplicación. En definitiva el esquema lo definen las consultas que vayamos a realizar con más frecuencia. MongoDB es especialmente útil en entornos que requieran escalabilidad. Con sus opciones de replicación y sharding, que son muy sencillas de configurar, podemos conseguir un sistema que escale horizontalmente sin demasiados problemas. ¿Dónde no se debe usar MongoDB? En esta base de datos no existen las transacciones. Aunque nuestra aplicación puede utilizar alguna técnica para simular las transacciones, MongoDB no tiene esta capacidad. Solo garantiza operaciones atómicas a nivel de documento. Si las transacciones son algo indispensable en nuestro desarrollo, deberemos pensar en otro sistema. Tampoco existen los JOINS. Para consultar datos relacionados en dos o más colecciones, tenemos que hacer más de una consulta. En general, si nuestros datos pueden ser estructurados en tablas, y necesitamos las relaciones, es mejor que optemos por un RDBMS clásico. Y para finalizar, están las consultas de agregación. MongoDB tiene un framework para realizar consultas de este tipo llamado Aggregation Framework. También puede usar Map Reduce. Aún así, estos métodos no llegan a la potencia de un sistema relacional. Si vamos a necesitar explotar informes complejos, deberemos pensar en utilizar otro sistema. Eso sí, esta es una brecha que MongoDB va recortando con cada versión. En poco tiempo esto podría dejar de ser un problema. 89 wine_analytics S Neo4J Neo4J es un líder en la Base de datos en Grafo. Se compone de modelado de datos enteros en forma de nodos y vértices, donde los nodos representan las entidades y relaciones entre ellos. Para el almacenamiento de datos utiliza la base de datos gráfica. Esto es una ventaja cuando tenemos un caso de uso en el que las entidades están altamente conectadas y tenemos que determinar varias dependencias y relaciones. Características No hay esquema. Transacciones ACID(Atomicity, Consistency, Isolation, Durability). Puede contener billones de nodos y relaciones. Rápido recorriendo relaciones, este tipo de queries se conoce como transversals. Lenguaje de query propio, Cypher. Alta disponibilidad, instalación en diferentes maquinas con balanceador de carga. Multilenguaje, proporciona una Api Rest pudiendo utilizarse desde cualquier lenguaje. Lenguaje drivers disponibles. Ventajas Tiene gran soporte y comunidad: hay muchas aplicaciones y plugins en github, podemos utilizar Neo4j con cualquier lenguaje. Además, añaden mejoras a la herramienta en función de los problemas que surgen en la comunidad de usuarios. Muy rápida para consultas de pocos grados de profundidad y miles de nodos. Fácil importación de formatos propios .csv (con plugin batch-import). Muy práctica para manejar grafos Aportan en la interfaz web una forma de visualización de las respuestas de las consultas (en forma de grafo) aunque no está enfocada a datos masivos. Hay otras herramientas para datos masivos como GraphChi, Linkurius o GraphAlchemist. Permiten usar Neo4j de forma embedded a través de la API de Java para crear endpoints específicos. Desventajas Neo4j Community no es escalable para cantidades de datos muy grandes, hay que cambiar la configuración de la memoria en Neo4j acorde con las necesidades del grafo. 90 wine_analytics S Lo que más ocupa en memoria es el almacenamiento de los nodos, se hacen ineficientes las consultas si no se ha modelado el problema bien y si se almacena demasiada información en los nodos. Neo4j quiere que tengas todo el grafo en memoria, si puedes (igual que MongoDB, etc.), pero al final habrá cosas del grafo que nunca tocas y es ineficiente tenerlo cacheado. Lo más recomendable es tener un conjunto de datos mínimo en memoria (por ejemplo, lo que más vas a consultar). Neo4j no tiene gestión de usuarios, nada de autenticación: hay una extensión para autenticar, o como alternativa, se puede poner un proxy delante de la BD para autenticar. Conclusiones MongoDB es almacén de documentos en el que podemos almacenar documentos JSON y BSON que requieren escrituras rápidas. Pero la recuperación de datos desde MongoDB requiere consultas complejas, con lo que es un trabajo realmente difícil y es necesario mucho esfuerzo en términos de marco de agregación y Map Reduce. MongoDB es altamente disponible y consistente, pero no es capaz de utilizar relaciones, ya que no mantiene la integridad referencial entre DBRefs. La principal ventaja de Neo4j es su capacidad rápida de hacer consultas muy complejas con profundidad ilimitada y conexiones ponderadas. Neo4j almacena los gráficos como "Usuarios" y las relaciones como "amistad" o "suscriptor". Es capaz de devolver relaciones entre datos de una manera sencilla. MongoDB funciona mucho mejor cuando todos los datos de una partición caben en memoria. Lo que hace que sea escalable es que muchas de las colecciones de datos se pueden almacenar y repartir fácilmente. Esto le permite distribuir los datos a través de una serie de nodos permitiéndole que se adapte conjuntos de datos que son mayores que la capacidad de memoria de un solo servidor. Es particularmente difícil encontrar formas de mantener grandes gráficos en memoria cuando superas los recursos de hardware. Es de señalar que para más del 90 por ciento de los casos de uso de aplicaciones, será más que suficiente el uso de una base de datos o la otra. El uso de dos bases de datos diferentes, incluso puede tener un impacto negativo en el rendimiento, especialmente en el sharding instancias de 91 S wine_analytics base de datos a través de múltiples máquinas. También hay que señalar es que Neo4j todavía no soporta auto-sharding. En resumen, veo que comparar Neo4j con MongoDB es como comparar peras con manzanas. Se debe utilizar Neo4j cuando los datos están altamente interconectados y es necesaria una navegación entre ellos, mientras que si los datos son estructuras no normalizadas, se debe de utilizar MongoDB. Conclusiones Cuando usar Redis Redis ofrece una buena solución para el almacenamiento de datos transitorios, además posee un buen organismo de control para limitar el uso de la API del sistema. La lectura/escritura de los datos es muy rápida. La latencia puede mantenerse baja y el riesgo de pérdida de datos es aceptable. Redis también ofrece mecanismos configurables para persistencia. Redis soporta cinco estructuras de datos diferentes que le permiten manejar entidades tales como conjuntos ordenados y datos de series de tiempo. Otro punto fuerte es la variedad de lenguajes de programación con la que es compatible. Cuando usar DynamoDB Si se desea eliminar la dependencia del entorno, es decir, su PaaS (Plataforma como Servicio) hace que sea inmediatamente escalable. El rendimiento concurrente es alto y la disponibilidad está asegurada a través de los múltiples centros de datos de AWS (Amazon Web Services). El rendimiento es predecible. Amazon cuenta con medios de comunicación móviles, publicidad en línea y juegos de azar entre sus aplicaciones de los clientes estrella, con millones de usuarios atendidos. Otras posibles aplicaciones incluyen registradores de clics corrientes en general (no sólo de publicidad), almacenamiento de sesión de usuario de aplicación, y la duplicación de datos intermedios. 92 wine_analytics S Cuando usar HBase HBase es básicamente utilizado para procesar los datos con fines de análisis en lugar de procesamiento en tiempo real. HBase viene a la mente cuando hay gran cantidad de datos se tratara, cientos de gigabytes o incluso cientos de petabytes de datos está involucrado. Básicamente HBase se utiliza para publicar el análisis de datos de procesamiento, a menudo el tratamiento de la información se mide en minutos y horas, a veces incluso días. Cuando se tratan grandes cantidades de datos Con fines de análisis El tiempo de procesamiento se mide en minutos y horas Para el procesamiento sin conexión Por ejemplo: previsión del tiempo Cuando usar MongoDB MongoDB en el otro lado está diseñado para el procesamiento en tiempo real. A pesar de que MongoDB puede almacenar gran cantidad de datos, procesamiento de datos a la vez se realiza en un pequeño subconjunto de datos. Se utiliza cuando el conjunto de datos es pequeño El tiempo de procesamiento mide en milisegundos Para el procesamiento en tiempo real Para almacenamiento de documentos (PDF, imágenes, XML, etc.) Por ejemplo: datos de búsqueda en tiempo real Cuando usar Cassandra Básicamente se puede utilizar Cassandra cuando nuestro problema requiera utilizar una base de datos escalable, con un grado de escalabilidad lineal. Escalabilidad lineal quiere decir que si añadimos un nuevo nodo al anillo, este verá incrementado su músculo de procesamiento en un nodo más literalmente. Además, Cassandra es ideal cuando se necesita almacenar una gran cantidad de datos y aun así quiere conservarse una interfaz amigable. También tenemos que tener en cuenta que Cassandra posee las siguientes características: 93 wine_analytics S Los datos son fácilmente replicables/distribuibles La consistencia de datos es personalizable Diseño del esquema es flexible Admite comprensión de datos El Lenguaje es tipo SQL, (aunque no os voy a mentir, es bastante simple y limitado). Esquema Flexible: admite diseño de esquema dinámico y permite tratar con datos estructurados, semi-estructurados y no estructurados Por ejemplo: La analítica web, para contar los accesos por hora, por el navegador, a través de IP, el registro de transacciones o la recolección de datos a partir de grandes conjuntos de sensores Cuando usar Neo4j Neo4j almacena la información como grafos dónde las relaciones entre los nodos son lo más importante. Es muy útil para representar/almacenar información de redes sociales. Es muy rápida para consultas de pocos grados de profundidad y miles de nodos. Fácil importación de formatos propios .csv (con plugin batch-import). Muy práctica para manejar grafos. Se debe utilizar cuando los datos están altamente interconectados y es necesaria una navegación entre ellos. Apéndice Una pregunta podemos hacernos cuando hablamos de arquitecturas modernas de datos es: "¿Debemos utilizar Kafka o Flume para cargar datos en los clusters de Hadoop?" Esta pregunta implica que Kafka y Flume son componentes intercambiables. Esto tiene tanto sentido como plantearse si "¿debemos utilizar coches o paraguas?" Puedes protegerte de la lluvia en tu coche y utilizar el paraguas cuando te desplazas de un lugar a otro pero, en general, se trata de diferentes herramientas destinadas a diferentes casos de uso. El caso de uso principal de Flume es ingerir datos en Hadoop. Está estrechamente integrado con el sistema de monitorización de Hadoop, el sistema de archivos, los formatos de archivo, y las utilidades tales como Morphlines. Una gran parte del esfuerzo en el desarrollo de Flume está en mantener la compatibilidad con Hadoop. El diseño de las fuentes de Flume, dispersores y canales 94 S wine_analytics se pueden utilizar para mover datos a otros sistemas con flexibilidad, pero la característica más importante es su integración Hadoop. El caso de uso principal de Kafka es un sistema de mensajería distribuido de publicaciónsuscripción. Una gran parte del esfuerzo en el desarrollo de Kafka está dirigida a permitir que los suscriptores lean exactamente los mensajes que les interesan, y en asegurarse de que el sistema distribuido sea escalable y fiable en multitud de condiciones diferentes. No fue concebido para transmitir datos específicamente para Hadoop, con lo que usarlo para leer y escribir datos en Hadoop es mucho más difícil de lo que es en Flume. Kafka es: Rápido Con una única ejecución, Kafka puede manejar cientos de megabytes de lecturas y escrituras por segundo desde miles de clientes. Escalable Kafka está diseñado para permitir que un solo grupo para servir como la columna vertebral de datos central para una gran organización. Puede ser elástica y se su ampliación es transparente independientemente de que el sistema esté activo o no. Los data streams se dividen y se extienden sobre un grupo de máquinas para que se tenga más capacidad que cualquier máquina individual y permitir clústeres coordinados de consumidores. Duradero: Los mensajes se conservan en el disco y se replican dentro del clúster para evitar la pérdida de datos. Cada broker puede manejar terabytes de mensajes sin impacto en el rendimiento. Distribuido: Kafka tiene un diseño cluster-centric moderno que ofrece una sólida durabilidad y garantías de tolerancia a fallos. En resumen: utiliza Flume si tienes fuentes de datos no relacionales, tales como archivos de registro, y deseas almacenarlos en Hadoop. Utiliza Kafka si necesitas un sistema de mensajería de la empresa altamente confiable y escalable para conectar muchos sistemas múltiples, uno de los cuales es Hadoop. 95 S wine_analytics Comparativa de Soluciones Big Data en Cloud El objetivo del documento es realizar una comparativa entre las soluciones Big Data que aportan tanto Amazon, Microsoft como Google BigData en Azure (HDInsight) Una de las razones del éxito de Hadoop es una simple cuestión económica. El procesamiento de conjuntos de datos de gran tamaño solía requerir equipos de alto rendimiento y hardware adicional especializado de precio elevado. Con Hadoop es posible realizar tareas de procesamiento confiable, escalable y distribuido en servidores estándar del sector, con capacidad para abordar petabytes de datos y sin que los presupuestos más reducidos supongan un problema. Hadoop también está diseñado para escalar de un único servidor a miles de máquinas, así como para detectar y controlar errores en la capa de aplicación para mayor confiabilidad. Información de todos los tipos de datos Según ciertas estimaciones, hasta un 80 % de los datos con los que las organizaciones trabajan hoy en día no vienen perfectamente clasificados en columnas y filas. Más bien se trata de una avalancha desordenada de correos electrónicos, fuentes de medios sociales, imágenes de satélites, señales de GPS, registros de servidor y otros archivos no relacionales sin estructurar. Hadoop puede administrar prácticamente cualquier archivo o formato (su otra gran ventaja), de manera que las organizaciones puedan plantear cuestiones que nunca creyeron posible. ¿Por qué usar Hadoop en la nube? Puede implementar Hadoop en un centro de datos tradicional en la oficina. Algunas empresas (incluida Microsoft) también ofrecen Hadoop como servicio en la nube. Una pregunta evidente 96 S wine_analytics sería: ¿por qué usar Hadoop en la nube? A continuación veremos por qué cada vez más organizaciones eligen esta opción. La nube ahorra tiempo y dinero El código abierto no significa que todo sea gratis. La implementación de Hadoop localmente requiere el uso de servidores, así como de expertos en Hadoop, para configurarlos, adaptarlos y mantenerlos. Un servicio en la nube permite poner en marcha un clúster de Hadoop en cuestión de minutos sin costo inicial alguno. La nube es flexible y escala con rapidez En la nube de Microsoft Azure solamente se paga por el almacenamiento y los procesos que se utilicen, cuando se utilicen. Puede arrancar un clúster de Hadoop, analizar los datos y cerrarlo una vez terminado para detener el contador. Velocidad gracias a la nube Cree un clúster de Hadoop en cuestión de minutos y agregue nodos a petición. La nube ofrece a las organizaciones un tiempo de amortización inmediato. HDInsight: Hadoop en la nube de Azure HDInsight de Microsoft Azure es un servicio basado 100 % en Apache Hadoop en la nube de Azure. Ofrece todas las ventajas de Hadoop, junto con la capacidad de integración con Excel, los clústeres de Hadoop locales y el ecosistema de software y servicios empresariales de Microsoft. Clientes que integran Hadoop en Azure Escalar con total flexibilidad a petición HDInsight es una distribución de Hadoop diseñada por la nube. Esto significa que HDInsight se ha diseñado para poder hacer frente a cualquier cantidad de datos, con la capacidad de escalar de 97 S wine_analytics terabytes a petabytes a petición. Puede arrancar un número de nodos cualquiera en cualquier momento. Solamente se cobra por los recursos de proceso y almacenamiento que realmente usa. Todos los datos: estructurados, semi-estructurados, no estructurados Dado que es 100% Apache Hadoop, HDInsight puede procesar datos no estructurados o semiestructurados desde secuencias de clics web, medios sociales, registros de servidor, dispositivos, sensores, etc. Esto permite analizar nuevos conjuntos de datos que descubren nuevas posibilidades de negocio para impulsar a su organización. Desarrollo en cualquier lenguaje HDInsight tiene extensiones de programación eficaces para lenguajes como C#, Java, .NET y más. Así, en Hadoop, podrá usar el lenguaje de programación de su elección para crear, configurar, enviar y supervisar trabajos de Hadoop. 98 S wine_analytics Sin hardware que comprar o mantener Con HDInsight, puede implementar Hadoop en la nube sin comprar nuevo hardware ni incurrir en otros costos iniciales. Además, la instalación y configuración se realizan de forma rápida. Azure se encarga de todo. Puede iniciar su primer clúster en minutos. Excel para visualizar los datos de Hadoop Dado que se integra con Excel, HDInsight le permite visualizar y analizar los datos de Hadoop de nuevas y convincentes formas en una herramienta conocida para sus usuarios finales. Desde Excel, los usuarios pueden seleccionar Azure HDInsight como origen de datos. Los clústeres de Hadoop locales conectados con la nube HDInsight también se integra con Hortonworks Data Platform, por lo que puede mover datos de Hadoop de un centro de datos de la oficina a la nube de Azure para escenarios de copia de seguridad, desarrollo y prueba y ampliación a la nube. Con Microsoft Analytics Platform System, puede incluso realizar consultas a sus clústeres de Hadoop locales y en la nube simultáneamente. 99 S wine_analytics Clústeres personalizados para ejecutar otros proyectos de Hadoop Este ecosistema de Hadoop es una cartera de proyectos de código abierto que evolucionan rápidamente y constantemente. Para proporcionar flexibilidad a los clientes, HDInsight tiene la opción de implementar proyectos de Hadoop arbitrarios a través de scripts personalizados. Esto incluye proyectos populares como Spark, R, Giraph y Solr. Incluye capacidades transaccionales distintas de SQL HDInsight también incluirá Apache HBase, una base de datos NoSQL columnar que se ejecuta sobre el Sistema de archivos distribuido de Hadoop (HDFS). Esto le permitirá llevar a cabo procesos transaccionales grandes (OLTP) de datos no relacionales que permiten el uso de casos como tener sitios web interactivos o escritura de datos de sensor en el almacenamiento de blobs de Azure. 100 wine_analytics S Procesado de transmisiones en tiempo real HDInsight incluye Apache Storm, una plataforma de análisis de transmisiones de código abierto que puede procesar eventos en tiempo real a gran escala. Esto le permite realizar el procesamiento de millones de eventos a medida que se generan permitiendo el uso de casos como Internet de las cosas (IoT) y obteniendo perspectivas a partir de sus dispositivos conectados o eventos desencadenados por web. Precios HDInsight arquitectura básica 8hxdía. Coste: 229$ al mes HDInsight arquitectura básica, 24hx7días, Coste: 709€ al mes. http://azure.microsoft.com/es-es/pricing/calculator/ BigData en Amazon AWS (EMR) Amazon Elastic MapReduce (Amazon EMR) es un servicio web que facilita el procesamiento rápido y rentable de grandes cantidades de datos. Amazon EMR utiliza Hadoop, un marco de código abierto, para distribuir los datos y el procesamiento en un clúster de tamaño variable de instancias de Amazon EC2. Amazon EMR se utiliza en diversas aplicaciones, como el análisis de registros, la indización web, el almacenamiento de datos, el aprendizaje de máquinas, el análisis financiero, la simulación científica y la bioinformática. Los clientes inician millones de clústeres de Amazon EMR cada año. Ventajas Facilidad de uso Puede lanzar un clúster de Amazon EMR en cuestión de minutos. No tiene que preocuparse por la provisión de nodos, la configuración del clúster, la configuración de Hadoop o el ajuste del clúster. Amazon EMR se encarga de estas tareas para que usted pueda centrarse en los análisis. 101 S wine_analytics Elasticidad Gracias a Amazon EMR, puede aprovisionar una instancia informática o cientos o miles de ellas para procesar datos en cualquier escala. Puede aumentar o reducir con facilidad el número de instancias y solo tendrá que pagar por lo que utilice. Bajo coste Puede lanzar un clúster de Hadoop de 10 nodos por tan solo 0,15 USD la hora. Como Amazon EMR ofrece soporte nativo para las instancias puntuales y reservadas de Amazon EC2, puede ahorrar entre el 50% y el 80% del coste de las instancias subyacentes. Fiabilidad Puede dedicar menos tiempo a ajustar y supervisar el clúster. Amazon EMR ha mejorado Hadoop para la nube, también supervisa el clúster, reintenta las tareas fallidas y sustituye automáticamente las instancias que tengan un rendimiento deficiente. Seguridad Amazon EMR configura automáticamente el firewall de Amazon EC2 que controla el acceso de red a las instancias. Podrá iniciar clústeres en Amazon Virtual Private Cloud (VPC), una red lógicamente aislada que define el usuario. Flexibilidad El usuario tiene el pleno control del clúster. Además, tendrá acceso raíz a todas las instancias, para que pueda instalar aplicaciones adicionales con facilidad y personalizar cada clúster. Amazon EMR también admite varias distribuciones y aplicaciones de Hadoop. Casos de uso Análisis clickstream Amazon EMR se puede utilizar para analizar datos clickstream para segmentar los usuarios y conocer sus preferencias. Los anunciantes también pueden analizar clickstreams y registros de impresión de publicidad para ofrecer anuncios más efectivos. 102 wine_analytics S Genómica Amazon EMR se puede utilizar para procesar grandes cantidades de datos genómicos y otros conjuntos de datos científicos de gran tamaño de forma rápida y eficiente. Los investigadores pueden acceder a los datos genómicos alojados de forma gratuita en AWS. Procesamiento de registros Amazon EMR se puede utilizar para procesar registros generados por aplicaciones web y móviles. Amazon EMR ayuda a los clientes a transformar petabytes de datos desestructurados o semiestructurados en perspectivas útiles sobre las aplicaciones o usuarios. Cómo utilizar Amazon EMR Para utilizar Amazon EMR, solo hay que hacer lo siguiente: Desarrolle su aplicación de procesamiento de datos. Puede utilizar Java, Hive (un idioma parecido a SQL), Pig (un lenguaje de procesado de datos), Cascading, Ruby, Perl, Python, R, PHP, C++ o Node.js. Amazon EMR ofrece códigos de muestra y tutoriales para que empiece a utilizarlo rápidamente. Cargue su aplicación y sus datos en Amazon S3. Si dispone de una gran cantidad de datos para la carga, puede que quiera utilizarAWS Import/Export (para cargar datos con dispositivos de almacenamiento físicos) o AWS Direct Connect (para establecer una conexión de red dedicada del centro de datos a AWS). Si lo prefiere, también puede escribir sus datos directamente en un clúster en ejecución. Configurar e inicializar el clúster. Con AWS Management Console, la interfaz de línea de comandos de EMR, los SDK o las API, especifique el número de instancias de EC2 que desea aprovisionar en su clúster, los tipos de instancias que desea utilizar (estándar, alta memoria, CPU alta, E/S alta, etc.), las aplicaciones que desea instalar (Hive, Pig, HBase, etc.) y la ubicación de las aplicaciones y los datos. Puede utilizar aplicaciones de arranque para instalar software adicional o cambiar la configuración predeterminada. (Opcional) Supervisar el clúster. Puede supervisar el estado y el progreso del clúster con Management Console, la interfaz de línea de comandos, SDK o API. EMR se integra con Amazon CloudWatch para supervisar/alarmar y es compatible con herramientas de supervisión conocidas como Ganglia. Puede agregar/eliminar capacidad del clúster en 103 wine_analytics S cualquier momento para gestionar más o menos datos. Para solucionar problemas, puede utilizar la interfaz gráfica de usuario de depuración de la consola. Recupere el resultado. Recupere el resultado de Amazon S3 o HDFS en el clúster. Visualice los datos con herramientas como Tableau y MicroStrategy. Amazon EMR finalizará automáticamente el clúster cuando se complete el procesado. De forma alternativa, puede mantener la ejecución del clúster e incluir más trabajo. Detalles del producto Amazon EMR Características Elasticidad Amazon EMR le permite aprovisionar de forma rápida y sencilla toda la capacidad que necesite, así como añadir o eliminar capacidad en cualquier momento. Es muy útil si cuenta con requisitos de procesado impredecibles o variables. Por ejemplo, si el grueso del procesado se produce por la noche, puede que necesite 100 instancias durante el día y 500 por la noche. De forma alternativa, puede que necesite una gran capacidad durante un breve período de tiempo. Con Amazon EMR, puede aprovisionar rápidamente cientos o miles de instancias y apagarlas cuando se complete el trabajo (para evitar pagar por una capacidad inactiva). Existen dos opciones principales para agregar o eliminar capacidad: Implementar varios clústeres: si necesita más capacidad, puede iniciar fácilmente un nuevo clúster y finalizarlo cuando deje de necesitarlo. No existe ningún límite en el número de clústeres que puede tener. Puede que quiera utilizar varios clústeres si tiene varios usuarios o aplicaciones. Por ejemplo, puede almacenar los datos de entrada en Amazon S3 e iniciar un clúster por cada aplicación que necesite procesar los datos. Se puede optimizar un clúster para la CPU, otro para el almacenamiento, etc. Cambiar el tamaño de un clúster en ejecución: con Amazon EMR es fácil cambiar el tamaño de un clúster en ejecución. Puede que quiera cambiar el tamaño de un clúster si está almacenando los 104 S wine_analytics datos en HDFS y desea agregar más potencia de procesado de forma temporal. Por ejemplo, algunos clientes agregan cientos de instancias a sus clústeres cuando se produce el procesado por lotes, y eliminan las instancias adicionales cuando se completa el procesado. Bajo coste Amazon EMR está diseñado para reducir el coste del procesado de grandes cantidades de datos. Algunas de las características que hacen que tenga un coste bajo son los precios bajos por horas, la integración puntual de Amazon EC2, la integración de instancias reservadas de Amazon EC2, la elasticidad y la integración de Amazon S3. Almacenes de datos flexibles Con Amazon EMR puede aprovechar varios almacenes de datos, incluidos Amazon S3, el Sistema de archivos distribuido Hadoop (HDFS) y Amazon DynamoDB. Amazon S3: Amazon S3 es el servicio de almacenamiento de gran duración, escalable, seguro, rápido y barato de Amazon. Amazon EMR ha realizado numerosas mejoras en Hadoop para que pueda procesar grandes cantidades de datos almacenados en Amazon S3 sin problemas. Al iniciar el clúster, Amazon EMR transfiere los datos de Amazon S3 a cada instancia del clúster y empieza a procesarlos inmediatamente. Una ventaja del almacenamiento de los datos en Amazon S3 y su procesado con Amazon EMR es que puede utilizar varios clústeres para procesar los mismos datos. Por ejemplo, puede tener un clúster de desarrollo de Hive optimizado para la memoria y la CPU y un clúster de producción de HBase optimizado para la E/S. Sistema de archivos distribuido Hadoop (HDFS): HDFS es el sistema de archivos de Hadoop. En Amazon EMR, HDFS utiliza el almacenamiento local efímero. En función del tipo de instancia, pueden ser discos giratorios o unidades de estado sólido. Cada instancia del clúster cuenta con un almacenamiento local efímero, pero usted decide qué instancias ejecutan HDFS. Amazon EMR 105 S wine_analytics denomina a las instancias que ejecutan HDFS "nodos centrales", mientras que las instancias que no ejecutan HDFS son "nodos de tarea". Amazon DynamoDB: Amazon DynamoDB es un servicio de base de datos NoSQL rápido y completamente gestionado. Amazon EMR cuenta con una integración directa con Amazon DynamoDB para que pueda procesar datos almacenados en Amazon DynamoDB de forma rápida y eficiente y transferir datos entre Amazon DynamoDB, Amazon S3 y HDFS en Amazon EMR. Otros almacenes de datos de AWS: los clientes de Amazon EMR también utilizan Amazon Relational Database Service (un servicio web que facilita el establecimiento, el funcionamiento y el escalado de bases de datos relacionales en la nube), Amazon Glacier (un servicio de almacenamiento con un coste extremadamente bajo que ofrece un almacenamiento seguro y duradero para las copias de seguridad y el archivado de los datos) y Amazon Redshift (un servicio de almacén de datos con escalado de petabyte, rápido y completamente gestionado). AWS Data Pipeline es un servicio web que ayuda a los clientes a procesar datos y a transferirlos de manera fiable entre diferentes servicios de almacenamiento e informática de AWS (como Amazon EMR), así como entre fuentes de datos locales en intervalos especificados. Herramientas de Hadoop EMR es compatible con herramientas de Hadoop potentes y probadas, como Hive, Pig, HBase e Impala. Hive es un almacén de datos y paquete de análisis de código abierto que se ejecuta por encima de Hadoop. Hive funciona gracias a Hive QL, un lenguaje basado en SQL que permite que los usuarios estructuren, resuman y consulten datos. Hive QL es más que el SQL estándar, ya que incluye una compatibilidad excelente con funciones map/reduce y tipos de datos complejos y ampliables definidos por el usuario, como JSON y Thrift. Esta capacidad permite procesar fuentes de datos complejas y desestructuradas, como documentos de texto y archivos de registro. Hive permite las extensiones de usuario a través de funciones definidas por el usuario escritas en Java. 106 S wine_analytics Amazon EMR ha efectuado numerosas mejoras en Hive, incluida la integración directa con Amazon DynamoDB y Amazon S3. Por ejemplo, con Amazon EMR puede cargar particiones de tabla automáticamente desde Amazon S3, puede escribir datos en tablas de Amazon S3 sin usar archivos temporales y puede acceder a recursos de Amazon S3, como scripts para operaciones map/reduce personalizadas y bibliotecas adicionales. Pig es un paquete de análisis de código abierto que se ejecuta por encima de Hadoop. Pig funciona gracias a Pig Latin, un lenguaje parecido a SQL que permite que los usuarios estructuren, resuman y consulten datos. Como sucede con las operaciones de estilo SQL, Pig Latin también incluye una compatibilidad excepcional para las funciones map/reduce y los tipos de datos complejos y ampliables definidos por el usuario. Esta capacidad permite procesar fuentes de datos complejas y desestructuradas, como documentos de texto y archivos de registro. Pig permite las extensiones de usuario a través de funciones definidas por el usuario escritas en Java. Amazon EMR ha efectuado numerosas mejoras en Pig, incluida la capacidad de utilizar varios sistemas de archivos (normalmente, Pig solo puede acceder a un solo sistema de archivos remoto), la capacidad de cargar scripts y JAR de clientes desde Amazon S3 (por ejemplo, “REGISTER s3:///my-bucket/piggybank.jar”) y funcionalidades adicionales para el procesado de cadenas y DateTime. HBase es una base de datos distribuida, no relacional y de código abierto modelada después de BigTable, de Google. Se desarrolló como parte del proyecto Hadoop de la Apache Software Foundation y se ejecuta sobre el sistema de archivos distribuido Hadoop (HDFS) para ofrecer capacidades estilo BigTable para Hadoop. HBase ofrece una forma eficiente y a prueba de fallos para almacenar grandes cantidades de datos dispersos con almacenamiento y compresión basada en columnas. Además, HBase ofrece una búsqueda rápida de datos, porque los datos se almacenan en la memoria, en lugar de en el disco. HBase se ha optimizado para las operaciones de escritura secuencial y es muy eficiente para las eliminaciones, actualizaciones e inserciones por lotes. HBase trabaja sin problemas con Hadoop al compartir su sistema de archivos y servir como entrada y salida directa para los trabajos de Hadoop. HBase también se integra con Apache Hive, lo que permite las consultas tipo SQL en tablas de HBase, las uniones con tablas basadas en Hive y la compatibilidad con Java Database Connectivity (JDBC). Con Amazon EMR puede hacer 107 S wine_analytics copias de seguridad de HBase en Amazon S3 (completas o incrementales, manuales o automáticas) y realizar restauraciones a partir de copias de seguridad creadas anteriormente. Impala es una herramienta de código abierto del ecosistema Hadoop para la generación de consultas interactivas y ad hoc mediante una sintaxis SQL. En lugar de utilizar MapReduce, aprovecha un motor de procesamiento masivo en paralelo (MPP) similar al que se encuentra en los sistemas de gestión de bases de datos relacionados (RDBMS) tradicionales. Con esta arquitectura puede consultar sus datos en tablas HDFS o HBase con gran rapidez y aprovechar la capacidad de Hadoop de procesar distintos tipos de datos y proporcionar esquemas durante la ejecución. Esto conduce a Impala a análisis interactivos y de latencia baja. También, esta aplicación admite funciones definidas por el usuario en Java y C++, y puede conectar herramientas de inteligencia empresarial mediante controladores ODBC y JDBC. Impala utiliza el metaalmacén de Hive para almacenar información sobre los datos de entrada, incluyendo los nombres de particiones y tipos de datos. Otros: Amazon EMR también es compatible con una gran variedad de aplicaciones y herramientas conocidas, como R, Mahout (machine learning), Ganglia (supervisión), Spark (MapReduce en memoria), Shark (almacenamiento de datos en Spark), Accumulo (base de datos NoSQL segura), Sqoop (conector de bases de datos relacionales), HCatalog (gestión de almacenamiento y tablas) y más. Características adicionales Uso de la distribución de MapR: MapR satisface las necesidades de Hadoop con una plataforma empresarial probada que admite un amplio abanico de usos productivos de vital importancia y en tiempo real. MapR ofrece una fiabilidad sin precedentes, facilidad de uso y una velocidad récord en todo el mundo para Hadoop, NoSQL, bases de datos y aplicaciones de transmisión en una plataforma unificada de grandes datos. Ajuste del clúster: puede elegir qué tipos de instancias EC2 desea aprovisionar en su clúster (estándar, alta memoria, CPU alta, E/S alta, etc.) en función de los requisitos de su aplicación. Dispone de acceso raíz a todas las instancias y puede personalizar por completo el clúster para que se adapte a sus requisitos. 108 S wine_analytics Depuración de aplicaciones: cuando habilita la depuración en un clúster, Amazon EMR archiva los archivos de registro en Amazon S3 y luego los indexa. Luego puede utilizar una interfaz gráfica para navegar por los registros de forma intuitiva. Supervisión del clúster: puede usar Amazon CloudWatch para supervisar 23 métricas personalizadas de Amazon EMR, como el número medio de tareas map/reduce en ejecución. También puede establecer alarmas para esas métricas. Programación de flujos de trabajo recurrentes: puede utilizar AWS Data Pipeline para programar flujos de trabajo recurrentes que involucren a Amazon EMR. AWS Data Pipeline es un servicio web pensado para ayudarle a procesar datos y a transferirlos, de manera fiable y a intervalos definidos, entre diferentes servicios de almacenamiento e informática de AWS, así como entre fuentes de datos locales. Cascading: Cascading es una biblioteca de Java de código abierto que ofrece una API de consulta, un planificador de consultas y un programador de trabajos para crear y ejecutar aplicaciones de Hadoop MapReduce. Las aplicaciones desarrolladas con Cascading se compilan y empaquetan en archivos JAR estándar compatibles con Hadoop, de forma parecida a otras aplicaciones nativas de Hadoop. Control del acceso de red al clúster: se puede iniciar el clúster en Amazon Virtual Private Cloud (VPC) que es una sección lógicamente aislada de la nube de AWS. Puede controlar todos los aspectos del entorno de red virtual, incluida la selección de su propio rango de direcciones IP, la creación de subredes y la configuración de tablas de enrutamiento y puertas de enlace de red. Gestión de usuarios y permisos: puede utilizar las herramientas de AWS Identity & Access Management (IAM), como las funciones y los usuarios de IAM, para controlar el acceso y los permisos. Por ejemplo, puede otorgar permisos de lectura a unos usuarios, pero no de escritura, para sus clústeres. Instalación de software adicional: se pueden utilizar acciones de arranque para instalar software adicional y para cambiar la configuración de las aplicaciones del clúster. Las acciones de arranque son scripts que se ejecutan en los nodos del clúster cuando Amazon EMR inicia el clúster. Se ejecutan antes de que se inicie Hadoop y antes de que el nodo empiece a procesar datos. Puede 109 wine_analytics S escribir acciones de arranque personalizadas o utilizar las acciones de arranque predefinidas que ofrece Amazon EMR. . Copiado eficiente de datos: se pueden mover rápidamente grandes cantidades de datos desde Amazon S3 a HDFS, desde HDFS a Amazon S3 y entre contenedores de Amazon S3 con S3DistCp de Amazon EMR, una extensión de la herramienta de código abierto Distcp que utiliza MapReduce para mover grandes cantidades de datos de forma eficiente. Hadoop Streaming: Hadoop Streaming es una utilizad de Hadoop que permite desarrollar ejecutables de MapReduce en lenguajes diferentes a Java. Streaming se implementa en forma de un archivo JAR. JAR personalizado: permite escribir un programa de Java, compilarlo para la versión de Hadoop que se quiera utilizar y cargarlo en Amazon S3. Luego se podrán enviar trabajos de Hadoop al clúster con la interfaz de Hadoop JobClient. Herramientas de terceros Se puede utilizar EMR con una gran variedad de herramientas de software de terceros, como Tableau, Microstrategy, SAP, Informatica entre otros. Precios de Amazon EMR Los precios de Amazon EMR son simples y predecibles; se paga una tarifa por horas por cada hora de instancia que se utilice (por ejemplo, un clúster de 10 nodos en ejecución durante 10 horas cuesta lo mismo que un clúster de 100 nodos que se ejecute durante 1 hora). La tarifa por horas depende del tipo de instancia que se utilice (por ejemplo, estándar, CPU alta, memoria alta, almacenamiento alto, etcétera). Las tarifas por horas oscilan entre 0,011 USD/hora y 0,27 USD/hora (de 94 USD/año a 2367 USD/año). El precio de Amazon EMR se añade al precio de Amazon EC2 (el precio de los servidores subyacentes). Existen diferentes opciones de precios de Amazon EC2 para elegir: bajo demanda (se ilustra a continuación), instancias reservadas durante 1 o 3 años, e instancias puntuales. EMR arquitectura básica, mínimo con uso 8hxdía. Coste: 341$ al mes http://calculator.s3.amazonaws.com/index.html#r=DUB&s=EC2&key= calc-44D76183-1A83-4C5C-A29E-FE9699530C2A EMR arquitectura básica, con las mismas instancias que el anterior pero 24hx7días. Coste: 753$ al mes 110 wine_analytics S http://calculator.s3.amazonaws.com/index.html#r=DUB&s=EC2&key= calc-98378EEE-86FC-41E5-A5CD-0565E62793F3 BigData en Google (Google Cloud Storage) Con el conector de Google Cloud Storage para Hadoop, puede realizar trabajos de MapReduce directamente sobre los datos en Google Cloud Storage, sin copiar al disco ejecutando HDFS. El conector simplifica el despliegue de Hadoop, reduce costes y ofrece un rendimiento comparable al HDFS, a la vez que aumenta la fiabilidad al eliminar el punto único de fallo del nodo nombre. Fundamentos de Hadoop Jobs Un Job en Hadoop es un proceso por lotes que se ejecuta en un clúster Hadoop. Un trabajo podría transformar los datos, ejecutar MapReduce, o realizar cálculos paralelos. MapReduce MapReduce es un paradigma de computación distribuida. El procesamiento consta de una etapa de Map, realizado subconjuntos de los datos de entrada; y Reduce, que combina la salida fusionada de los datos. MapReduce se puede ejecutar en datos estructurados o no estructurados, y se ha convertido en una de las maneras más populares para analizar conjuntos de datos masivos en paralelo. 111 wine_analytics S Herramientas Hadoop Conector de Google Cloud Conector Storage para Hadoop Información general El conector de Google Cloud Storage para Hadoop permite ejecutar trabajos de MapReduce directamente en los datos de Google Cloud Storage, y ofrece una serie de ventajas con respecto a la elección de Hadoop Distributed File System (HDFS) como sistema de archivos por defecto. Ventajas de usar el conector La primera vez que se crea un cluster de Hadoop, se debe elegir entre dos sistemas de archivos por defecto. La elección de Google Cloud Storage junto al conector suministrado tiene varios beneficios. Acceso directo de datos. Almacena los datos en Google Cloud Storage y acceda a ellos directamente, sin necesidad de transferirlo a HDFS primero. Compatibilidad HDFS. Se pueden almacenar datos en HDFS, además de Google Cloud Storage, y acceder a ellos con el conector utilizando una ruta de archivo diferente. Interoperabilidad. Almacenamiento de datos en Google Cloud Storage permite la interoperabilidad sin fisuras entre Hadoop y otros servicios de Google. Acceso a los datos. Al apagar un cluster Hadoop, todavía se tiene acceso a los datos en Google Cloud Storage, a diferencia de HDFS. Alta disponibilidad de datos. Los datos almacenados en Google Cloud Storage son altamente disponibles y globalmente replicables sin un impacto en el rendimiento. No sobrecarga de administración de almacenamiento. A diferencia de HDFS, Google Cloud Storage no requiere mantenimiento de rutinas, tales como la comprobación del sistema de archivos, actualizar o hacer retroceder a una versión anterior del sistema de archivos, etc. Encendido rápido. 112 wine_analytics S Con Google Cloud Storage, se comienza a trabajar tan pronto como se levantan los nodos de trabajo, dando lugar a importantes ahorros de costes en el tiempo. BigQuery Connector para Hadoop El conector BigQuery para Hadoop es una biblioteca Java que permite procesar en la nube datos de BigQuery, usando las versiones abstractas de las clases Hadoop InputFormat y OutputFormat. Datastore Connector para Hadoop El Datastore Connector de Hadoop es una biblioteca Java que permite procesar en la nube datos de Hadoop, usando las versiones abstractas de las clases Hadoop InputFormat y OutputFormat. Precios Google Cloud Storage (GCS) arquitectura básica, mínimo con uso 8hxdía. Coste: 260€ al mes GCS arquitectura básica, con las mismas instancias que el anterior pero 24hx7días. Coste: 420€ al mes Configuration Instances Virtual Cores Memory GCEU 2 1 (GB ) Local Lowest 3 Typical 4 Full Disk price (USD) price (USD) price 5 (USD) (GB) per hour with per hour per hour full sustained without usage sustained use Task(n1-standard-1) 1 1 3.75 2.75 0 $0.045 $0.049 $0.063 Core (n1-standard- 2 2 7.50 5.50 0 $0.089 $0.097 $0.126 1 4 26 11 0 $0.208 $0226 $0.296 2) Master(n1highmem-4) Detalles: https://cloud.google.com/products/calculator/#id=ebfe9f18-1e5b-4e29-9ae6- dd1faa9e61e8 113 wine_analytics S Referencias (de los anexos tecnológicos) http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis/ http://www.datastax.com/dev/blog/8761 http://km.nivaria.com/blog/interesante-comparativa-de-dbms-nosql http://www.webmining.cl/2012/06/como-elegir-una-base-de-datos-para-su-empresa/ http://rafinguer.blogspot.com.es/2010/11/comparativa-mongodb-con-otras-bases-de.html http://todobi.blogspot.com.es/2010/12/comparativa-de-nosql-databases.html http://www.genbetadev.com/bases-de-datos/bases-de-datos-nosql-elige-la-opcion-quemejor-se-adapte-a-tus-necesidades https://www.tumblr.com/search/NoSQL+comparison http://www.datastax.com/dev/blog/amazon-dynamodb http://109.239.60.130/compare/hbase/vs/apache-cassandra https://news.ycombinator.com/item?id=2052852 http://www.academia.edu/5352898/NoSQL_Database_New_Era_of_Databases_for_Big_Dat a_Analytics_-_Classification_Characteristics_and_Comparison http://www.bigdata-madesimple.com/a-deep-dive-into-nosql-a-complete-list-of-nosqldatabases/ http://www.indeed.com/jobanalytics/jobtrends?q=MongoDB%2C+Redis%2C+Cassandra%2C +Riak%2C+CouchDB&l= http://clean-clouds.com/2012/01/amazon-dynamodb-1st-steps-of-nosql-in-amazon-publiccloud/ http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedBefor eYouBegin.html http://eng.orcadigital.com/tag/redis/ http://whynosql.com/cassandra-vs-hbase/ http://www.bigdata-careers.com/?page_id=99 http://www.cs.rit.edu/~rsn5770/Narde_Project_Report.pdf https://2015.foss4g-na.org/session/geo-nosql-databases http://neo4j.com/ http://es.slideshare.net/EdurekaIN/no-sql-databases-35591065 http://classpattern.com/mongodb-hadoop.html#.VLT5qCuG_y4 http://hbase.apache.org/ 114 wine_analytics S https://prezi.com/xaitejgkpqsv/introduccion-a-nosql-graph-database-neo4j/ http://freepdfhosting.com/d2b1f50889.pdf http://www.genbetadev.com/bases-de-datos/mongodb-que-es-como-funciona-y-cuandopodemos-usarlo-o-no http://aws.amazon.com/ http://azure.microsoft.com/ https://cloud.google.com/ 115 Proyecto wine_analytics wine_analytics RESUMEN EJECUTIVO Begoña Boloqui José Miguel Espinosa Mónica Manrique Carlos Valencia Proyecto wine_analytics Proyecto wine_analytics Motivación La industria de bebidas y alimentación es, junto al turismo, el primer sector industrial en España. La industria vinícola representa el 14% de toda la industria alimentaria y supone el 1% del PIB del país. El vino es uno de los productos con más éxito en el exterior y un referente como destino del turismo gastronómico, lo que le convierte un sector de extraordinaria relevancia. Wine_analytics pretende aprovechar las capacidades analíticas actuales basadas en tecnología Big Data para impulsar el crecimiento de esta línea de negocio. El objetivo del proyecto es comprobar si la utilización estas herramientas permitirá mejorar la eficiencia de los procesos, así como reducir la incertidumbre asociada a la toma de decisiones en una industria con fuerte dependencia de factores de difícil o limitado control. El problema y la oportunidad En la actualidad nuestro grupo es líder absoluto en los mercados de vinos y zumos en España, y una referencia a escala mundial en el mundo del vino. Hemos seleccionado dentro de la división de vinos a la bodega Abadía de Haza, de la Ribera del Duero, que utiliza uva autóctona de la variedad Tempranillo. Esta bodega es la tercera del grupo por volumen de producción e ingresos. Cuenta con varios tintos de diverso envejecimiento (roble, crianza, reserva y selección), posicionados en los tres canales de venta de la bodega: alimentación moderna, horeca (hoteles, restaurantes y cafeterías), exportación. Siendo la calidad de los vinos de las mejores desde un punto de vista técnico, Abadía de Haza se enfrenta a los siguientes problemas de negocio a los que pretendemos dar solución: incrementar la producción de la uva de máxima calidad, la cual se sitúa actualmente en un 10%. Esta uva es la que le confiere a los vinos de Abadía de Haza una marca distintiva, y sin embargo esta calidad de sus caldos no se ha traducido en una posición de liderazgo en el mercado. El objetivo de este proyecto es alcanzar una producción del 12% de este tipo de uva; la consolidación de sus vinos Premium en restaurantes; 1 Proyecto wine_analytics la mayor penetración de su gama de vinos en mercados americanos (Estados Unidos, México y Brasil), especialmente los de mayor envejecimiento (crianza, reserva y selección). Con el objetivo de dar solución a estos problemas, la dirección del grupo exige controlar mejor la producción y mejorar algunos procesos. Así, se contempla la posibilidad de abordar su primer proyecto de Big Data basado en una interfaz que envía los datos desde su origen a un entorno analítico que posibilite la explotación de esta información. El equipo El equipo seleccionado por el comité de dirección para gestionar este proyecto piloto está liderado por Carlos Valencia, Director Financiero del Grupo apoyándose en los conocimientos técnicos de: José Miguel Espinosa: Corporate IT Manager del Grupo y especialista en Inteligencia de Negocio Begoña Boloqui: Analista Senior de Datos y especialista en modelización del área de vinos Mónica Manrique: Analista Senior de Datos y de Investigación de Mercados de la división de Zumos Receptores de la solución En una primera fase del proyecto piloto nuestro cliente interno va a ser Abadía de Haza. En una segunda fase pretendemos dirigirnos al resto de bodegas de la división de vinos y a otras divisiones del grupo, tales como aceites, zumos, bebidas vegetales, etc. En función de los resultados, el objetivo en un futuro sería ofrecerlo a empresas o grupos externos del sector agroalimentario. Situación actual y competencia La empresa tiene todavía un largo camino por recorrer en el uso de estas soluciones. Un uso adecuado de las tecnologías de la información puede contribuir a mejorar considerablemente tanto productos como procesos y optimizar la toma de decisiones. El coste de recoger, almacenar, procesar y explotar grandes cantidades de datos, incluso en tiempo real, ha bajado drásticamente. En este sentido el Big Data significa una gran revolución. En todo el mundo están surgiendo soluciones de monitorización del estado del cultivo con redes de sensores, herramientas de análisis de imágenes para estudiar el estado de los cultivos, herramientas 2 Proyecto wine_analytics de soporte a la toma de decisiones, plataformas de escucha de redes sociales centradas específicamente en el sector agroalimentario, entre otras. Igualmente existe un número limitado de empresas que proporcionan servicio de analítica técnica a nivel de laboratorio o consultoría de servicios para sectores agrícolas. Mientras que estas soluciones se enfocan en propuestas de valor muy específicas, especialmente de tipo System Lock-in y Product Leadership1, la propuesta de valor de wine_analytics queda enmarcada dentro de la tipología Complete Customer Solutions frente a sus competidores potenciales más directos. Esta propuesta aúna varios servicios a lo largo de toda la cadena de producción, desde el mismo campo hasta el análisis de resultados de campañas de marketing, incluyendo datos de redes sociales. Nuestra propuesta Proponemos una solución complementaria al Business Intelligence ya existente en Pérez Cristóbal, y la implantación de un nuevo sistema analítico de precisión que proporciona información clave para la gestión y control tanto de los procesos en el campo como del resultado final. Los valores de esta propuesta son múltiples, ya que permite optimizar la producción de la uva de máxima calidad mediante actividades como la monitorización y el seguimiento de las vides y de las condiciones medioambientales. El nuevo sistema analítico se convertiría en un activo en sí mismo para la bodega. La tipología de los datos que wine_analytics recogerá, cumple con dos de las características habitualmente asociadas a proyectos Big Data: variedad: se trata de datos estructurados, semi-estructurados y no-estructurados; velocidad: necesaria para un tratamiento en tiempo real de determinadas mediciones críticas, desde la fase de maduración de la uva hasta la elaboración de los caldos. En cuanto al volumen, éste no es muy relevante en esta primera fase. Sin embargo con posterioridad sí se convertiría en una variable a tener en cuenta. 1 Las propuestas de valor planteadas por Robert S. Kaplan and David P. Norton son: 1. Low total cost, 2. Product leadership, 3. Complete customer solution, 4. System lock-in. 3 Proyecto wine_analytics Descripción de la solución Para el caso de los trabajos en el campo han aparecido en los últimos años tecnologías vinculadas a la ingeniería de datos. Estas permiten mayor eficiencia que los métodos tradicionales en la recogida y el tratamiento de esta información en tiempo y forma para la toma de decisiones. El propósito final se basa en hacer agricultura de precisión cuyo crecimiento se ha impulsado a partir de avances tecnológicos tales como sensores remotos, sistemas de información geográfica (GIS), etc. La idea fundamental de la solución descansa en la ingesta de datos de diferentes fuentes, siendo los más determinantes las mediciones agro y micro climáticas que realizará un sistema de sensorización. Se utilizarán también predicciones y mediciones meteorológicas, registros de labores, datos epidemiológicos y consumos. Estos datos mejoran la toma de decisiones en cuanto a la necesidad de regadío o momento de recolecta, reduciendo el consumo de agua, pesticidas y fertilizantes, y minimizando tanto la huella de carbono como el impacto de pesticidas en los productos agrícolas. Wine_analytics también obtiene información a través de las Redes Sociales, de las campañas de marketing digital que se van a poner en marcha como parte de la estrategia del grupo así como de los resultados de comercio electrónico y del Business Intelligence corporativo. Prueba de concepto Con el fin de comprobar que nuestra solución es viable se llevó a cabo una prueba de concepto con fecha 20 de diciembre de 2014 en las bodegas y viñedos de Abadía de Acón. La prueba de concepto incluyó una reunión in-situ con los directores técnico y comercial para conocer en detalle el proceso de elaboración de sus vinos. En esta prueba se determinaron los parámetros que definen la uva de máxima calidad y se identificaron una serie de factores que potencialmente podrían explicar las variaciones de dichos parámetros. Los técnicos de la bodega señalaron al clima como principal aspecto a analizar. De esta manera, se cruzaron mediciones de los parámetros de calidad de uva para una muestra periódica representativa del viñedo con diferentes variables climáticas, con el fin de evaluar el impacto de las mismas. 4 Proyecto wine_analytics De acuerdo con los primeros resultados obtenidos se concluyó que nuestro proyecto podía ser implantado para cumplir los siguientes objetivos: determinación precisa de la fecha óptima para vendimiar (en cada parcela); mejor planificación de la producción, anticipando necesidades fitosanitarias e hídricas en los viñedos en función de la variabilidad climática y optimizando fechas para su aplicación. Después de conocer cómo este tipo de proyectos puede contribuir significativamente a resolver sus problemas y posicionar mejor sus vinos, el equipo de Abadía de Acón se mostró muy interesado en implantar la solución wine_analytics en su bodega. Durante los últimos meses hemos mantenido el contacto con ellos y nos han provisto de información muy valiosa para el proyecto, tanto técnica enológica como financiera. De la misma forma, a nivel tecnológico se ha desplegado un laboratorio en donde hemos podido probar el stack de tecnologías que soporta toda la solución propuesta. Así, se han descartado alternativas que fueron apareciendo en nuestro horizonte mientras se diseñaba la solución, de modo que el resultado obtenido es el más apropiado para este caso de uso. Viabilidad La prueba en Abadía de Acón fue un primer paso para analizar la viabilidad de nuestro proyecto. Algunas de las conclusiones extraídas de este análisis: el modelo tecnológico es escalable; existen fuertes economías de escala, de modo que conforme mayor es la cifra de ventas, mayor será el retorno de wine_analytics; una aplicación exitosa de nuestro proyecto precisa de una masa crítica de ventas, valorada en aproximadamente unos 600,000€; existe mucha demanda para este tipo de soluciones y muy poca oferta. Hemos enmarcado este proyecto en un escenario a cinco años a partir de la vendimia 2015. Este plazo se ha establecido en base al largo ciclo de operaciones. En el caso de Abadía de Haza Reserva y Selección el tiempo mínimo de envejecimiento en barrica y reducción en botella son 12 meses para cada fase, por lo que son necesarios un mínimo de 24 meses solamente de elaboración técnica. Durante ese período se trabajará con los datos disponibles en cada momento para ir afinando los modelos analíticos, y éstos se aplicarán para mejorar la calidad de los vinos más jóvenes. Estos 5 Proyecto wine_analytics últimos con un ciclo menor, son los que contribuirán a que equilibrar la cuenta de resultados de nuestra bodega. Es importante destacar que debido al largo tiempo de maduración que requiere el producto final, la obtención de resultados no se produce de forma inmediata. Se precisa un período mínimo de dos años (período de maduración del vino más joven) para comenzar a obtener los frutos de esta inversión. La analítica y la anticipación son actividades clave en la solución propuesta, ya que son los instrumentos principales de control de la producción y de la calidad. En 2019 también contaremos con datos históricos adicionales de la sensórica en viñedos, necesarios para elaborar modelos predictivos mucho más precisos que permitirán mejorar la calidad de toda la gama de vinos de Abadía de Haza. La situación de partida para 2015 sería la de una bodega con márgenes reducidos y baja eficiencia. El plan estratégico de la bodega busca lograr una mejora en la producción de uva de máxima calidad, pasando de un 10% sobre el total de uva producida, hasta un conservador 12%. Este escenario se plantea como alcanzable con los medios actuales y la implantación de wine_analytics. Superar esta cifra y alcanzar un 14% de uva de máxima calidad, e incluso hasta un 15%, se considera factible, dado que se trata de un objetivo muy conservador. Considerando el largo ciclo de explotación, el impacto en la cuenta de resultados será negativo el primer año (2015) igualando la situación de partida el ejercicio siguiente (2016), e iniciando una fase de “despegue” a partir del año siguiente (2017), una vez que empiezan a venderse los productos Reserva y Selección. Por tanto no es sino hasta el tercer año cuando empiezan a percibirse los resultados del proyecto y la consecución de sus objetivos en términos de beneficio. De esta manera, mientras que en 2014 el beneficio ha sido de 26,000€ (2.75% sobre la cifra de ventas), en el 2019 pasaremos a tener un incremento en este beneficio de aproximadamente 350%, hasta llegar a los 116,500€ que supone un 8.91% sobre las ventas. En términos económicos la inversión de wine_analytics ronda los 62,000€, con unos costes operativos asociados del proyecto de aproximadamente 140,000€ anuales. El impacto de los costes por la implantación del nuevo sistema tecnológico no sería fuerte en comparación con la mejora en ventas, dado que se utilizará software Open Source y SaaS (Software as a Service) para minimizar 6 Proyecto wine_analytics estos costes operacionales. Este bajo impacto de costes tecnológicos permite una sustancial mejora de márgenes EBIT en 2017 dada la baja inversión requerida. Con estas cifras y la mejora de ingresos explicada anteriormente, se logrará un ROI de 10.41% y una TIR de proyecto de 10.97%. La TIR de accionista será infinita considerando que no existe financiación adicional de accionista asociada al proyecto. Mejoras Como primera mejora y considerando la escalabilidad de la solución, ésta se puede aplicar a otras áreas de negocio del grupo, con un coste marginal cercano a cero. Esto supone que otras divisiones dentro del Pérez Cristóbal, como bebidas vegetales, frutas o café, se verán beneficiadas de esta solución en un plazo inmediato (ya que en estos casos el ciclo de explotación es muy corto) con una mínima inversión. Como mejoras subsiguientes se contemplan dos escenarios y no excluyentes: a nivel de bodega: una mayor implantación de sensórica, pasando del mero control electromecánico a la gestión automática de los datos (ingeniería de datos). Esta permitirá tener un control real y exhaustivo de la cadena de producción basada en datos reales, medibles y medidos, aplicando la analítica avanzada; a nivel logístico: se buscará la integración de datos de geolocalización en la distribución, junto con los datos del BI corporativo. Esto permitirá identificar los puntos críticos para optimizar la logística de distribución del producto a los clientes finales; a nivel de solución wine_analytics: puede venderse como un activo en sí mismo a otras bodegas dentro o fuera del grupo Pérez Cristóbal. Conclusiones Wine_analytics se presenta como una oportunidad para un proyecto redondo. El incremento del beneficio triplica el valor porcentual y cuadruplica la cifra sobre los números netos en el tercer año, a pesar del retraso en obtención de resultados debido al largo ciclo de operaciones propio del negocio. La solución tecnológica propuesta es rentable, elegante, escalable y robusta. 7 Proyecto wine_analytics Finalmente es fundamental destacar las fases de mejora y expansión de esta solución, tanto dentro como fuera del grupo, que permitirían extrapolar las ventajas del proyecto con costes operativos incrementales casi nulos. Nuestra recomendación como equipo de proyecto después de realizar la prueba de concepto, tanto a nivel de campo como tecnológica y financieramente, es por tanto: Go. 8
© Copyright 2024