Embed Size (px)
Citation preview
S
wine_analytics
wine_analytics
MEMORIA
Begoña Boloqui
José Miguel Espinosa
Mónica Manrique
Carlos Valencia
S
wine_analytics
S
1
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
S
2
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
S
3
wine_analytics
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.
S
4
wine_analytics
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;
S
5
wine_analytics
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
S
6
wine_analytics
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
S
7
wine_analytics
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
3 Fuente: http://www.ccovi.ca/vine-alert
4 Fuente: http://www.mavrx.co/product/vineyards/
5 Fuente: http://www.fruitionsciences.com/es/login/home
S
8
wine_analytics
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/
7 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/
S
9
wine_analytics
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 Know-
How 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)
S
10
wine_analytics
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.
S
11
wine_analytics
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.
S
12
wine_analytics
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)
S
13
wine_analytics
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
S
14
wine_analytics
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)
S
15
wine_analytics
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).
S
16
wine_analytics
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.
S
17
wine_analytics
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.
S
18
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:
S
19
wine_analytics
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
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
0 5 10 15 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
Semana
S
20
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.
S
21
wine_analytics
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.
S
22
wine_analytics
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.
S
23
wine_analytics
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.
S
24
wine_analytics
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:
S
25
wine_analytics
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.
S
26
wine_analytics
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).
S
27
wine_analytics
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.
S
28
wine_analytics
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
S
29
wine_analytics
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 e-
commerce.
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.
S
30
wine_analytics
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
S
31
wine_analytics
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.
S
32
wine_analytics
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:
S
33
wine_analytics
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.
S
34
wine_analytics
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.
S
35
wine_analytics
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.
S
36
wine_analytics
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.
S
37
wine_analytics
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.
S
38
wine_analytics
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:
S
39
wine_analytics
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
S
40
wine_analytics
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):
S
41
wine_analytics
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.
S
42
wine_analytics
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.
S
43
wine_analytics
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:
S
44
wine_analytics
Cuenta de resultados
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:
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
Coste Operativos -815,7 -927,6 -973,1 -1.000,6 -1.020,3 -1.040,4
Costes Wine_Analytics 0,0 -112,0 -141,1 -152,0 -154,7 -157,5
Resto de Costes -815,7 -815,7 -832,0 -848,6 -865,6 -882,9
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%
Amortización -87,3 -101,2 -102,2 -104,0 -109,2 -111,5
CAPEX del Proyecto -12,5 -12,5 -12,5 -12,5 -12,5
Resto CAPEX -87,3 -88,7 -89,7 -91,6 -96,8 -99,1
EBIT 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
Impuesto de Sociedades -11,1 4,9 -10,3 -27,4 -38,0 -38,8
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%
2014 2015 2016 2017 2018 2019 2020
Costes del Proyecto 111.988 141.135 151.988 154.734 157.536 160.394
Total costes instancias bajo demanda 14.655 14.655 14.655 14.655 14.655 14.655
Mantenimiento equipos 4.000 4.080 4.162 4.245 4.330 4.416
Fotografía satélite 40.000 40.800 41.616 42.448 43.297 44.163
Marketing digital, acciones Redes Sociales 53.333 81.600 91.555 93.386 95.254 97.159
S
45
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:
S
46
wine_analytics
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.
2014 2015 2016 2017 2018 2019 2020
INGRESOS 943.254 1.014.643 1.116.473 1.214.037 1.281.685 1.307.319 1.333.465
Superficie (ha) 75,4 75,4 75,4 75,4 75,4 75,4 75,4
Rendimiento kg uva / ha 4.000 4.000 4.000 4.000 4.000 4.000 4.000
Kg Totales de uva 301.600 301.600 301.600 301.600 301.600 301.600 301.600
Destino de la uva 100% 100% 100% 100% 100% 100% 100% 100%
Vino alta calidad 10% 10% 11% 12% 12% 12% 12% 12%
Reservas 5% 5% 5% 5% 5% 5% 5%
Selección 5% 6% 7% 7% 7% 7% 7%
Vinos otras calidades 77% 77% 77% 77% 77% 77% 77% 77%
Venta de uva 13% 13% 12% 11% 11% 11% 11% 11%
Cantidad de uva por destino
Vino alta calidad 30.160 33.176 36.192 36.192 36.192 36.192 36.192
Reservas 15.080 15.080 15.080 15.080 15.080 15.080 15.080
Selección 15.080 18.096 21.112 21.112 21.112 21.112 21.112
Vinos otras calidades 232.232 232.232 232.232 232.232 232.232 232.232 232.232
Venta de uva 39.208 36.192 33.176 33.176 33.176 33.176 33.176
Cantidad de botellas (1kg uva = 1 botella 0,75 l)
Vino alta calidad 22.620 24.882 27.144 27.144 27.144 27.144 27.144
Reservas 11.310 11.310 11.310 11.310 11.310 11.310 11.310
Selección 11.310 13.572 15.834 15.834 15.834 15.834 15.834
Vinos otras calidades 174.174 174.174 174.174 174.174 174.174 174.174 174.174
Precio Medio Reservas 35,00 35,00 37,80 41,77 43,86 44,73 45,63 46,54
Precio Selección 15,00 15,00 16,20 17,90 18,80 19,17 19,56 19,95
Precio medio vinos otras calidades 2,00 2,00 2,16 2,39 2,51 2,56 2,61 2,66
Precio medio uva 0,75 0,75 0,77 0,78 0,80 0,81 0,83 0,84
Incremento precio botella reservas 0,00% 8,00% 10,50% 5,00% 2,00% 2,00% 2,00%
Incremento precio botella Selección 0,00% 8,00% 10,50% 5,00% 2,00% 2,00% 2,00%
Incremento precio resto vinos 0,00% 8,00% 10,50% 5,00% 2,00% 2,00% 2,00%
Incremento precio de la uva 0,00% 2,00% 2,00% 2,00% 2,00% 2,00% 2,00%
Ingresos esperados reservas 395.850 427.518 472.407 496.028 505.948 516.067 526.389
Ingresos esperados Selección 169.650 183.222 202.460 255.100 303.569 309.640 315.833
Ingresos esperados resto vinos 348.348 376.216 415.719 436.504 445.235 454.139 463.222
Ingresos esperados venta de uva 29.406 27.687 25.887 26.405 26.933 27.472 28.021
S
47
wine_analytics
Balance de situación
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:
0 1 2 3 4 5
BALANCE 2014 2015 2016 2017 2018 2019
Inmovilizado Bruto 2.860,3 2.957,2 2.982,6 3.027,9 3.158,3 3.215,5
Amortización Acumulada -1.337,9 -1.439,1 -1.541,3 -1.645,3 -1.754,6 -1.866,1
Inmovilizado Neto 1.522,4 1.518,1 1.441,3 1.382,5 1.403,7 1.349,4
Existencias 502,0 540,0 594,2 646,1 682,2 695,8
Clientes 235,8 253,7 279,1 303,5 320,4 326,8
Otros
Tesorería 85,5 42,2 75,0 75,0 75,0 125,1
TOTAL ACTIVO 2.345,7 2.354,0 2.389,6 2.407,2 2.481,3 2.497,0
Capital Social 1.800,0 1.800,0 1.800,0 1.800,0 1.800,0 1.800,0
Reservas 355,5 381,4 368,9 393,9 404,0 472,8
Resultado del Ejercicio 25,9 -12,5 30,9 82,1 114,1 116,5
Dividendos del ejercicio 0,0 0,0 -5,8 -72,0 -45,3 -104,9
Total Patrimonio Neto 2.181,4 2.168,9 2.193,9 2.204,0 2.272,8 2.284,4
Deuda Senior 0,0 0,0 0,0 0,0 0,0 0,0
Acreedores 135,9 154,6 162,2 166,8 170,1 173,4
Otros 28,3 30,4 33,5 36,4 38,5 39,2
Total Pasivo 164,2 185,0 195,7 203,2 208,5 212,6
TOTAL PATRIMONIO NETO Y PASIVO 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
S
48
wine_analytics
Rentabilidad
Finalmente, el análisis de rentabilidad del proyecto según se puede apreciar en el cuadro más
abajo.
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%.
0 1 2 3 4 5
CASH FLOW 2014 2015 2016 2017 2018 2019
EBITDA 127,6 87,0 143,4 213,4 261,4 266,9
Impuesto de Sociedades -11,1 4,9 -10,3 -27,4 -38,0 -38,8
Variación de Fondo de Maniobra -88,8 -35,0 -69,0 -68,8 -47,6 -15,9
Fondo de Maniobra 573,6 608,6 677,7 746,5 794,1 810,0
CASH FLOW DE OPERACIONES 27,6 56,8 64,1 117,3 175,7 212,1
CAPEX ya previsto -34,5 -25,4 -45,3 -130,4 -57,2
CAPEX Proyecto -62,4 0,0 0,0 0,0 0,0
CASH FLOW DE INVERSION 0,0 -96,9 -25,4 -45,3 -130,4 -57,2
FREE CASH FLOW 27,6 -40,1 38,7 72,0 45,3 154,9
Capital Social 0,0 0,0 0,0 0,0 0,0 0,0
Disposiciones de Deuda Senior 0,0 0,0 0,0 0,0 0,0 0,0
Cancelaciones de Deuda Senior 0,0 0,0 0,0 0,0 0,0 0,0
Gastos Financieros Netos -3,2 -3,2 0,0 0,0 0,0 0,0
CASH FLOW DE FINANCIACION -3,2 -3,2 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
Dividendos 0,0 -5,8 -72,0 -45,3 -104,9
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
0 1 2 3 4 5
RENTABILIDAD 2014 2015 2016 2017 2018 2019
Variación de Ingresos 0,0 101,8 199,4 267,0 292,7
Opex del proyecto -112,0 -141,1 -152,0 -154,7 -157,5
Capex del proyecto -62,4 0,0 0,0 0,0 0,0
Flujos del proyecto -174,4 -39,3 47,4 112,3 135,1
ROI 10,41%
TIR de proyecto 10,97%
S
49
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.
S
50
wine_analytics
ANEXOS
S
51
wine_analytics
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.
S
52
wine_analytics
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.
S
53
wine_analytics
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.
S
54
wine_analytics
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.
S
55
wine_analytics
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.
S
56
wine_analytics
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.
S
57
wine_analytics
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.
S
58
wine_analytics
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.
S
59
wine_analytics
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:
S
60
wine_analytics
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.
S
61
wine_analytics
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
S
62
wine_analytics
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.
S
63
wine_analytics
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 DB-
Engine (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.
S
64
wine_analytics
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
Nombre Cassandra
DynamoDB
HBase
Redis
MongoDB
Neo4j X
Descripción
Columnar
basada en
conceptos de
BigTable
y DynamoDB
Hosted,
servicio de
base de datos
escalable por
Amazon con
los datos
almacenados
en la nube
Columnar
basada en
conceptos de
BigTable
y Hadoop
BBDD en
memoria con
opciones
configurables
de
rendimiento
vs.
persistencia
Una de las más
populares BBDD
documentales
BD en Grafos
OpenSource
S
65
wine_analytics
DB-Engines Ranking
Rank 8 Score 98.75
Rank 30 Score 13.09
Rank 14 Score 53.59
Rank 10 Score 94.24
Rank 5
Score 250.90
Rank 23
Score 24.42
Website cassandra.apa
che.org
aws.amazon.c
om/dynamodb
hbase.apache.
org
redis.io www.mongodb.org neo4j.com
Documentació
n Técnica
www.datastax
.com/docs
aws.amazon.c
om/-
documentatio
n/dynamodb
hbase.apache.
org
redis.io/-
documentatio
n
docs.mongodb.org/
manual
neo4j.com/docs/-
stable
Desarrollador
Apache
Software
Foundation
Amazon
Apache
Software
Foundation
Salvatore
Sanfilippo MongoDB, Inc Neo Technology
Año de
publicación 2008 2012 2008 2009 2009 2007
Licencia Open Source commercial Open Source Open Source Open Source Open Source
Database as a
Service
(DBaaS)
no Sí no no no no
Lenguaje de
Programación Java Java C C++ Java
Sistemas
Operativos
Compatibles
BSD
Linux
OS X
Windows
hosted
Linux
Unix
Windows
BSD
Linux
OS X
Windows
Linux
OS X
Solaris
Windows
Linux
OS X
Windows
Modelo de
BBDD Columnar Clave-valor Columnar Clave-valor Documental En Grafos DBMS
Esquema de
datos schema-free schema-free schema-free schema-free schema-free schema-free
Typing Sí Sí no no Sí Sí
Índices
Secundarios restricted no no no Sí Sí
S
66
wine_analytics
SQL no no no no no no
APIs y otros
métodos de
acceso
Proprietary
protocol
RESTful HTTP
API
Java API
RESTful HTTP
API
Thrift
proprietary
protocol
proprietary
protocol using JSON
Cypher query
language
Java API
RESTful HTTP API
Lenguajes de
programación
soportados
C#
C++
Clojure
Erlang
Go
Haskell
Java
JavaScript
Perl
PHP
Python
Ruby
Scala
.Net
ColdFusion
Erlang
Groovy
Java
JavaScript
Perl
PHP
Python
Ruby
C
C#
C++
Groovy
Java
PHP
Python
Scala
C
C#
C++
Clojure
Dart
Erlang
Go
Haskell
Java
JavaScript
Lisp
Lua
Objective-C
Perl
PHP
Python
Ruby
Scala
Smalltalk
Tcl
Actionscript
C
C#
C++
Clojure
ColdFusion
D
Dart
Delphi
Erlang
Go
Groovy
Haskell
Java
JavaScript
Lisp
Lua
MatLab
Perl
PHP
PowerShell
Prolog
Python
R
Ruby
Scala
Smalltalk
.Net
Clojure
Go
Groovy
Java
JavaScript
Perl
PHP
Python
Ruby
Scala
Server-side
scripts no no Sí Lua JavaScript Sí
S
67
wine_analytics
Triggers Sí no Sí no no Sí
Métodos de
particionamie
nto
Sharding Sharding Sharding none Sharding none
Métodos de
replicación
selectable
replication
factor
Sí
selectable
replication
factor
Master-slave
replication
Master-slave
replication
Master-slave
replication
MapReduce Sí no Sí no Sí no
Conceptos de
consistencia
Eventual
Consistency
Immediate
Consistency
Eventual
Consistency
Immediate
Consistency
Immediate
Consistency
Eventual
Consistency
Immediate
Consistency
Eventual
Consistency
Foreign keys no no no no no yes
Conceptos de
transacción no no no
optimistic
locking no ACID
Concurrencia Sí Sí Sí Sí Sí Sí
Durabilidad Sí Sí Sí Sí Sí Sí
Conceptos de
acceso
Se pueden
definir
permisos por
usuario y
objeto
Los permisos
de acceso para
usuarios y
roles se
pueden definir
a través de la
AWS Identidad
y
Administració
n de Acceso
(IAM)
Listas de
control de
acceso (ACL)
Muy Simple
Control de
acceso por
credenciales
Derechos de acceso
para usuarios y
roles
no
S
68
wine_analytics
3. Rendimiento
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
Vs
S
69
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
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
Vs
S
70
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
S
71
wine_analytics
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 (!)
S
72
wine_analytics
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.
S
73
wine_analytics
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 diseñar esquemas muy flexibles, muy complejos.
No tiene Supercolumns. Pero se puede diseñar una supercolumn, ya que tanto la estructura como los nombres y valores de columna son binarios.
No tiene ningún método para incrementar el valor de un elemento de una columna.
Ofrece un método el elemento agradable para incrementar los contadores. Muy adecuado para la agregación de datos.
Soporta Map Reduce. Se necesita un cluster Hadoop para ejecutarlo. Los datos serán transferidos desde el clúster de Cassandra al clúster de Hadoop. No es muy adecuado ejecutar Jobs muy pesados sobre datos Map Reduce.
Map Reduce es nativo. HBase está construido sobre Hadoop. Los datos no se transfieren.
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 está escrito en Java, tiene que utilizarse Thrift para comunicarse con el clúster.
Tiene una bonita API de Java nativo. Se siente mucho más el sistema java que el de Cassandra. HBase tiene una interfaz óptima para otros lenguajes también.
S
74
wine_analytics
Cassandra HBase
No hay ningún servidor maestro, por lo tanto, ningún punto único de fallo.
Aunque no existe un concepto de un 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.
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.
Vs
S
75
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.
S
76
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 log-
estructurado - 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).
S
77
wine_analytics
HBase vs. Cassandra vs. Redis
Categoría Database Database
Database
In Memory/ Management
Preferencia 28% votos 34% votos 38% votos
Website hbase.apache.org Cassandra.apache.org redis.io
Licencia Apache License 2
Apache License 2 BSD-License
Diseño
Database model Column-oriented
Key-value
Column-oriented
Key-value
Key-value
Schema-less
Publish/Subscribe
Data storage
ExFat
local
File System
File System
Volatile memory
File System
Exportable No Sí No
Vs Vs
S
78
wine_analytics
Características
Lenguaje de Consulta
API calls
REST
XML
Thrift
API calls
CQL
Thrift
API calls
Lua
Tipo de datos BLOB
All MySQL
JSON
BLOB
user-defined
STATIC COLUMN
Data structures
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í
S
79
wine_analytics
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
Modelo de bloqueo
MVCC MVCC
Lock Free Model
Optimistic Locking
S
80
wine_analytics
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
S
81
wine_analytics
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 *NIX Cross-platform Cross-platform
Controlador nativo Java
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
S
82
wine_analytics
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
Una base de datos distribuida
basada en Hadoop
Base de datos distribuida de segunda
generación
Almacén de estructuras de datos
en memoria
Marca Apache Apache ?
Sistema multiusuario
Sí Sí Sí
Estandarización No ? ?
S
83
wine_analytics
Distribución de software
Tarball
Package management system
Tarball
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í
S
84
wine_analytics
Interfaz Web Sí Sí ?
API Good Good Basic
Copia de seguridad online
No Sí Sí
Índices parciales No ? ?
Log Sí Sí Sí
Descarga www.apache.
org/dyn/closer.cgi/hbase/
Cassandra.apache.org/download/
redis.io/download
Funcionalidad de Backup
Basic Good Good
Query Cache No ? Sí
Facilidad de uso ★★★★☆ ★★★★☆ ★★★★★
Gratis para uso comercial
Sí Sí Sí
S
85
wine_analytics
Ó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
S
86
wine_analytics
Object-Relational Mapping (ORM)
? Sí Sí
Soporte de la plataforma en la nube
? Amazon EC2
Rackspace Cloud Heroku
Cloud Foundry
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
87
wine_analytics
MongoDB vs Neo4j
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:
Vs
S
88
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.
S
89
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.
S
90
wine_analytics
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.
S
91
wine_analytics
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
S
92
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.
S
93
wine_analytics
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:
S
94
wine_analytics
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
S
95
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ón-
suscripció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.
S
96
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
S
97
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
S
98
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 semi-
estructurados 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.
S
99
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.
S
100
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.
S
101
wine_analytics
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.
S
102
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.
S
103
wine_analytics
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 semi-
estructurados 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
S
104
wine_analytics
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
S
105
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
S
106
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.
S
107
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
S
108
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.
S
109
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
S
110
wine_analytics
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
S
111
wine_analytics
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.
S
112
wine_analytics
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.
S
113
wine_analytics
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
(GB 1)
GCEU 2 Local
Disk
(GB)
Lowest
price 3 (USD)
per hour with
full sustained
usage
Typical
price 4(USD)
per hour
Full
price 5 (USD)
per hour
without
sustained
use
Task(n1-standard-1) 1 1 3.75 2.75 0 $0.045 $0.049 $0.063
Core (n1-standard-
2)
2 2 7.50 5.50 0 $0.089 $0.097 $0.126
Master(n1-
highmem-4)
1 4 26 11 0 $0.208 $0226 $0.296
Detalles: https://cloud.google.com/products/calculator/#id=ebfe9f18-1e5b-4e29-9ae6-
dd1faa9e61e8
S
114
wine_analytics
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-que-
mejor-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-nosql-
databases/
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-public-
cloud/
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/
S
115
wine_analytics
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-cuando-
podemos-usarlo-o-no
http://aws.amazon.com/
http://azure.microsoft.com/
https://cloud.google.com/
Proyecto wine_analytics
wine_analytics
RESUMEN EJECUTIVO
Begoña Boloqui
José Miguel Espinosa
Mónica Manrique
Carlos Valencia
Proyecto wine_analytics
1
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;
2
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
3
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.
4
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.
5
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
6
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
7
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.
8
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.
