Big Data PDF: Conceptos, Arquitectura y Hadoop

Big Data Jordi Sabater Picañol 16/12/2013 Directores: Manuel Pando Mones José Roldán Rosón Empresa: Everis...

Big Data Jordi Sabater Picañol 16/12/2013 Directores: Manuel Pando Mones José Roldán Rosón Empresa: Everis Ponente: Ruth Raventós Pages Grado en ingeniería informática Ingeniería del software Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech ABSTRACT Español El concepto Big Data está cobrando actualmente un gran interés creciente por parte de las empresas, que ven en ello una gran ventaja competitiva. Este proyecto busca justificar este interés creciente partiendo de los conceptos más básicos de Big Data. Para alcanzar este objetivo, se ha dividido el proyecto en varias partes. En primer lugar se introduce al lector en el mundo Big Data, explicando con detalle el significado de este concepto y a qué tipo de problemas está dirigido. A continuación se estudia el estado actual del mercado Big Data, analizando la arquitectura de los sistemas Big Data y comparando las soluciones existentes. El estudio se ha centrado sobre todo en el framework más utilizado actualmente para la el desarrollo de soluciones Big Data: Hadoop. No obstante también se contemplan otro tipo de soluciones también importantes en el mundo Big Data, como las bases de datos NoSQL y las soluciones altamente escalables en Cloud. Las últimas partes del proyecto están enfocadas al ámbito práctico, haciendo uso de la solución Hadoop open source actualmente más extendida: Cloudera CDH. Sobre esta solución se han realizado un conjunto de pruebas, con el objetivo de ganar conocimiento técnico sobre las diferentes herramientas que componen el ecosistema Hadoop. Y se ha implementado un caso de uso real de Big Data. El caso de uso implementado consiste en capturar todas las menciones que se hacen en las redes sociales como Twitter, Facebook o Linkedin, sobre un producto o empresa determinado. Con los datos capturados y mediante las herramientas incluidas en la solución Cloudera CDH, se buscan los patrones más repetidos en los comentarios con la finalidad de conocer las opiniones de la gente acerca del producto o empresa buscados. Català El concepte Big Data està cobrant actualment un gran interès creixent per part de les empreses, que ven en ell un gran avantatge competitiu. Aquest projecte busca justificar aquest interès creixent partint dels conceptes més bàsics de Big Data. Per assolir aquest objectiu, s'ha dividir el projecte en diverses parts. En primer lloc s'introdueix al lector en el món Big Data, explicant amb detall el significar d'aquest concepte i a quin tipus de problemes està dirigit. A continuació s'estudia l'estat actual del mercat Big Data, analitzant la arquitectura dels sistemes Big Data i comparant les solucions existents. L'estudi s'ha centrat sobre tot en el framework més utilitzat actualment per al desenvolupament de soluciones Big Data: Hadoop. No obstant, també es contemplen altres tipus de solucions no menys importants en el món Big Data, com les bases de dades NoSQL i les solucions altament escalables en Cloud. Les últimes parts del projecte estan enfocades al àmbit pràctic, fent ús de la solució Hadoop open source actualment més estesa: Cloudera CDH. Sobre aquesta solució s'han realitzat un conjunt de proves, amb l'objectiu de guanyar coneixement tècnic sobre les diferents eines que composes l'ecosistema Hadoop. I s'ha implementat un cas d'ús real de Big Data. El cas d'ús implementat consisteix en capturar totes les mencions que es fan en las xarxes socials com Twitter, Facebook o Linkedin, sobre un producte o empresa determinat. Amb les dades capturades i mitjançant les eines incloses en la solució Cloudera CDH, es cerquen els patrons més repetits en els comentaris amb la finalitat de conèixer les opinions de la gent sobre el producte o empresa cercats. English The Big Data concept is nowadays gaining a big growing interest by companies which see this as a competitive advantage. This project seeks to justify the growing interest starting from the most basic concepts of Big Data. To achieve this goal, the project has been divided into several parts. In the first place the reader is introduced to the world of Big Data, explaining in detail the meaning of this concept and what kind of problems it is addressed. Then the current state of the Big Data market is studied by analyzing the architecture of Big Data systems and comparing the existing solutions. The study has been focused primarily on most currently used framework for developing Big Data solutions: Hadoop. However other important solutions in the Big Data world are also contemplated, such as NoSQL databases and the highly scalable solutions in Cloud. The last parts of the project are focused on the practical level, making use of the currently most widespread Hadoop open source solution: Cloudera CDH. Over this solution has been made a set of tests in order to gain technical knowledge about the different tools that compose the Hadoop ecosystem. And an actual Big Data use case has been implemented. The implemented use case consists of capturing all the mentions made in social networks like Twitter, Facebook or Linkedin, on a particular product or company. With the captured data and using the tools included in the Cloudera CDH solution, the most repeated patterns in the comments are sought in order to know the views of people about the product or company being searched. Todo el código generado durante el desarrollo de este proyecto está disponible en el repositorio GitHub BecaBigData: https://github.com/LinJuuichi/BecaBigData CONTENIDO Parte I: GESTIÓN DEL PROYECTO............................................................................................. 1 1. Contextualización................................................................................................................... 2 2. Planificación........................................................................................................................... 4 2.1. Planificación inicial........................................................................................................ 4 2.2. Planificación Final.......................................................................................................... 8 3. Presupuesto......................................................................................................................... 12 4. División del trabajo.............................................................................................................. 14 5. Competencias técnicas........................................................................................................ 18 Parte II: BIG DATA.................................................................................................................... 21 1. Introducción......................................................................................................................... 22 2. ¿Qué es Big Data?................................................................................................................ 23 3. Casos de uso......................................................................................................................... 25 4. Arquitectura......................................................................................................................... 29 4.1. Recolección................................................................................................................. 29 4.2. Almacenamiento......................................................................................................... 30 4.2.1 Bases de Datos NoSQL............................................................................................. 30 4.3. Procesamiento y Análisis / Bussiness Intelligence...................................................... 34 4.4. Visualización................................................................................................................ 34 4.5. Administración............................................................................................................ 35 5. Paradigmas........................................................................................................................... 36 5.1. Map-Reduce................................................................................................................ 36 5.2. Bases de datos relacionales MPP................................................................................ 38 Comparación............................................................................................................................ 38 6. Tipos de soluciones.............................................................................................................. 42 6.1. Software...................................................................................................................... 42 6.2. Appliance..................................................................................................................... 43  6.3. Cloud........................................................................................................................... 44 Comparación............................................................................................................................ 44 Parte III: HADOOP.................................................................................................................... 47 1. Hadoop................................................................................................................................. 48 1.1. HDFS............................................................................................................................ 50 1.2. MapReduce................................................................................................................. 59 1.3. YARN............................................................................................................................ 65 2. Herramientas del ecosistema Hadoop................................................................................. 68 2.1. Ambari......................................................................................................................... 68 2.2. Cascading..................................................................................................................... 70 2.3. Flume........................................................................................................................... 71 2.4. HBase........................................................................................................................... 73 2.5. HCatalog...................................................................................................................... 75 2.6. Hive.............................................................................................................................. 75 2.7. Hue.............................................................................................................................. 76 2.8. Mahout........................................................................................................................ 77 2.9. Oozie............................................................................................................................ 78 2.10. Sqoop........................................................................................................................... 79 2.11. Whirr........................................................................................................................... 80 Parte IV: ANÁLISIS DE SOLUCIONES BIG DATA.................................................................... 81 1. Distribuciones Hadoop (Software)....................................................................................... 82 1.1. Cloudera...................................................................................................................... 83 1.2. Hortonworks Data Platform........................................................................................ 88 1.3. IBM InfoSphere BigInsights......................................................................................... 93 1.4. MapR......................................................................................................................... 103 Tabla comparativa................................................................................................................. 108 2. Hadoop as a service (Cloud)............................................................................................... 115  2.1. Amazon EMR (Elastic MapReduce)........................................................................... 115 2.2. Microsoft Windows Azure HDInsight........................................................................ 118 Parte V: ESTUDIO TÉCNICO DE UNA SOLUCIÓN BIG DATA EXISTENTE. CLOUDERA CDH4................................................................................................................................................... 120 1. Cloudera CDH4................................................................................................................... 121 2. Entorno de trabajo............................................................................................................. 123 3. Plan de pruebas................................................................................................................. 126 4. Pruebas.............................................................................................................................. 128 4.1. Administración.......................................................................................................... 128 4.2. Mahout...................................................................................................................... 138 4.3. Bases de Datos.......................................................................................................... 140 4.4. Data Warehouse (Hive)............................................................................................. 141 4.5. MPP (Impala)............................................................................................................. 149 Parte VI: CASO DE USO. ANÁLISIS DE LA IMAGEN DE UN PRODUCTO A TRAVÉS DE LAS REDES SOCIALES...................................................................................................................... 157 1. Introducción....................................................................................................................... 158 2. Análisis de la imagen de un producto a través d e las redes sociales................................ 160 2.1. Pre procesamiento del texto..................................................................................... 163 2.2. Búsqueda de patrones.............................................................................................. 166 2.3. Automatización del workflow................................................................................... 168 3. Resultados obtenidos......................................................................................................... 173 Parte VII: CASO DE USO. ANÁLISIS DE FICHEROS LOG...................................................... 174 1. Introducción....................................................................................................................... 175 2. Análisis de ficheros log....................................................................................................... 176 3. Comparación entre soluciones.......................................................................................... 180 Conclusión................................................................................................................................. 181 Glosario..................................................................................................................................... 185 Bibliografía................................................................................................................................ 189 Anexos....................................................................................................................................... 197 A1. Especificaciones de hardware y software....................................................................... 197 A2. Instalación del clúster...................................................................................................... 199 Parte I: GESTIÓN DEL PROYECTO 1. CONTEXTUALIZACIÓN El proyecto Big Data se ha desarrollado en la empresa Everis y ha sido el resultado de la colaboración con otro estudiante de la Facultad de Informática de Barcelona, Robert Serrat Morros. A pesar de que Big Data es un término que ya se utiliza desde hace tiempo, no ha sido hasta hace poco que ha cobrado un gran interés por parte de las empresas. Debido a este auge actualmente Big Data se ha convertido en un concepto muy extenso, abarcando un gran abanico de conocimientos como bases de datos NoSQL, servicios en cloud, y nuevos modelos de programación. Definir el alcance del proyecto para poder ajustarlo al tiempo disponible, es por lo tanto, muy importante para no quedar a la deriva ante tantos nuevos conceptos y conocimientos. No obstante, antes de poder determinar el alcance del proyecto es necesario especificar unos objetivos. Los objetivos de este proyecto son cuatro: Entender con un gran nivel de detalle el significado del concepto Big Data. Comprender y analizar el estado actual del mercado entorno a Big Data. Realizar un estudio práctico sobre una solución Big Data existente. Implementar un caso de uso Big Data real en la solución escogida en el objetivo anterior. Teniendo en cuenta los objetivos anteriores, el proyecto se ha dividido en tres fases. Cada una desglosada en varios puntos. 1. Estudio teórico de la situación actual de Big Data. Definición del concepto de Big Data y análisis de por qué ha surgido. Identificación de los casos de uso en los que es necesario o aconsejable utilizar una herramienta o solución Big Data. Estudio y comparación de los diferentes paradigmas Big Data. Estudio de la arquitectura Big Data general. Estudio y comparación de las diferentes herramientas y soluciones Big Data. 2. Estudio técnico de una solución Big Data existente. Diseño y planificación de las pruebas a realizar sobre la solución Big Data escogida. Pruebas de rendimiento, tolerancia a errores, usabilidad, etc. Instalación y configuración de un clúster con la solución escogida. Realización de las pruebas diseñadas en el primer apartado de la segunda fase y anotación de resultados. Análisis de los resultados obtenidos y documentación de las conclusiones. 3. Implementación de un caso de uso real con la solución Big Data estudiada en la segunda fase. Diseño del caso de uso y selección de las herramientas a utilizar. Implementación del caso de uso. Gestión del proyecto | Contextualización 2  Despliegue del caso de uso implementado en el clúster instalado y configurado en la segunda fase. Análisis y documentación de las conclusiones obtenidas sobre el funcionamiento del caso de uso implementado. Por parte de Everis, empresa que ha facilitado las infraestructuras necesarias para el correcto desarrollo de este proyecto, los objetivos han sido dos: Generar el máximo conocimiento posible sobre Big Data durante la duración de todo el proyecto. Disponer, al finalizar el proyecto, de una plataforma Big Data correctamente instalada sobre la que poder realizar diferentes pruebas para poder continuar generando valor añadido en la empresa acerca de esta nueva tecnología. A pesar de que el proyecto se ha realizado en colaboración con otro estudiante, existe una división clara de tareas que podéis consultar más adelante en el apartado cuarto "División del trabajo", que ha permitido que cada estudiante pueda realizar algunas tareas de forma exclusiva, facilitando el desarrollo del proyecto y la evaluación del trabajo individual. Gestión del proyecto | Contextualización 3 2. PLANIFICACIÓN En este apartado se presenta la planificación inicial del proyecto, y la planificación final real que se acabó siguiendo. En un principio se respetó en gran medida la planificación inicial, pero aproximadamente a finales del segundo mes del proyecto, debido a unos problemas en la adquisición de las infraestructuras que iban a albergar el sistema Big Data, se tuvo que modificar de forma notable la planificación inicial. Alargándose el proyecto en más de dos meses sobre la previsión inicial. El gran cambio respecto a la planificación inicial es el hecho de que en un primer lugar íbamos a implementar dos pilotos diferentes, cada uno con una solución Big Data diferente, en el que íbamos a desplegar el mismo caso de uso para poder analizar y comparar las diferencias en cuanto a usabilidad, funcionalidades y productividad de cada una de las dos soluciones escogidas. Como explicamos con más detalle en la planificación final, finalmente sólo se pudo implementar un único piloto. Por lo que modificamos la planificación inicial añadiendo un nuevo caso de uso, y una nueva fase de pruebas sobre la solución escogida para poder generar el máximo conocimiento sobre ella, pudiendo realizar una guía de buenas prácticas al utilizar esa solución Big Data. 2.1. PLANIFICACIÓN INICIAL La duración inicial de la beca en la empresa Everis era de 6 meses. Por esto razón la planificación inicial se ajustó a este intervalo de tiempo. Se dividió la planificación en cinco fases diferentes, comenzando la primera el 11 de Febrero de 2013 (fecha de inicio de la beca en la empresa Everis) y terminando el 31 de Julio de 2013 (fecha de fin de la beca). Figura 1: Planificación inicial (visión general). Las cinco fases fueron pensadas para poder alcanzar los cuatro objetivos principales del proyecto. Durante todo el desarrollo de este proyecto han intervenido dos tutores por parte de la empresa Everis (José Roldán Rosón y Manuel Pando Mones) además de los autores del proyecto (Robert Serrat Morros y Jordi Sabater Picañol). A continuación se detallan las cinco fases. Gestión del proyecto | Planificación 4 Fase 1 - Estado del arte El objetivo de la primera fase era: definir y acotar el alcance del proyecto, intentar obtener el máximo conocimiento inicial posible sobre Big Data (dado que no habíamos trabajado antes este concepto), y realizar la elección de soluciones para el desarrollo de la pruebas piloto (la adquisición de servidores y licencias de software por parte de Everis era un proceso que requería tiempo). El objetivo era poder iniciar estas gestiones en las primeras semanas de proyecto. Figura 2: Planificación inicial (fase 1 detallada). Sabíamos que el framework más utilizado para analizar datos no estructurados de forma distribuida era actualmente Hadoop junto al modelo de programación MapReduce, por ello enfocamos el estudio inicial sobre todo a este producto open source, dado que con mucha probabilidad, como mínimo uno de los dos pilotos implementados sería utilizando Hadoop. A raíz del punto "comparativa de soluciones Hadoop", aparecerían las dos propuestas para la implementación de dos pilotos Big Data diferentes. Fase 2 - Especificación pilotos y aprendizaje En esta fase se formalizaba la petición a Everis de las infraestructuras necesarias para el desarrollo del proyecto. Como hemos comentado en el apartado anterior el objetivo era poder iniciar estas gestiones lo más rápido posible para poder disponer de las infraestructuras la mayor parte de la duración del proyecto. Figura 3: Planificación inicial (fase 2 detallada). Gestión del proyecto | Planificación 5 Para ello en un primer punto se estudiaron los casos de uso en los que se utilizaba o era aconsejable utilizar una solución Big Data. Para a continuación poder especificar el caso de uso que implementaríamos en ambos pilotos. En el intervalo de tiempo entre la especificación de los pilotos que se iban a implementar en el proyecto, y la reunión con los tutores para formalizar la petición de las infraestructuras, se aprovechó para documentar toda la información recolectada hasta el momento, y empezar el aprendizaje sobre una de las herramientas que utilizaríamos más adelante en el proyecto, Flume. Fase 3 - Implementación arquitectura pilotos La fase 3 consistía en la obtención de las infraestructuras solicitadas en la fase anterior por parte del gerente de Big Data en Everis (Juanjo López), y la instalación y configuración de dichas infraestructuras con las soluciones Big Data escogidas en la fase 1, de forma que al finalizar esta fase dispusiéramos de dos plataformas Big Data para poder implementar el caso de uso en dos pilotos diferentes, a los que se realizaría una comparación al finalizar. Figura 4: Planificación inicial (fase 3 detallada). En el intervalo de tiempo que transcurriría hasta la obtención de las infraestructuras solicitadas, se realizaría una presentación al gerente (Juanjo López) para justificar la solicitud de infraestructuras, e indicar el progreso del proyecto y en qué estado se encuentra. Además se aprovecharía la no dependencia de la capa de recolección de datos con las soluciones Big Data escogidas para empezar su diseño e implementación en los portátiles como entorno de desarrollo. Una vez se adquiriesen los servidores y licencias software se procedería a la instalación y configuración de ambos entornos de desarrollo, el piloto A y el piloto B. Gestión del proyecto | Planificación 6 Fase 4 - Implementación del caso de uso El objetivo de la cuarta fase era implementar todo el caso de uso, compartiendo en ambos pilotos las partes comunes de la implementación. Y realizar una valoración final de ambas soluciones. Figura 5: Planificación inicial (fase 4 detallada). Fase 5 - Análisis de resultados y conclusiones Finalmente la quinta fase consistía en la recolección de todas las conclusiones obtenidas a lo largo de todo el proyecto, y la presentación de dichas conclusiones a los tutores en la empresa. Figura 6: Planificación inicial (fase 5 detallada). Gestión del proyecto | Planificación 7 2.2. PLANIFICACIÓN FINAL Las dos primeras fases de la planificación se respetaron de forma fiel. Los cambios respecto a la planificación inicial comenzaron a partir de la tercera fase "Implementación arquitectura pilotos", a raíz de un retraso en la obtención de las infraestructuras. En un principio las infraestructuras iban a estar listas para mediados de abril, pero la realidad fue que hasta principios de julio no pudimos disponer de ellas (faltando menos de un mes para la fecha final de la beca en la empresa). Esto supuso un gran impacto en la planificación inicial, teniendo que reestructurar prácticamente toda la planificación a partir de la tercera fase. Los tres cambios más importantes fueron: Everis alargó dos meses el contrato de beca para compensar el retraso en la obtención de las infraestructuras. En un principio la beca terminaba el 31 de Julio. El nuevo contrato añadía las semanas comprendidas entre el 16 de setiembre de 2013, al 31 de octubre de 2013 (en agosto y las dos primeras semanas de setiembre no se tubo acceso a las infraestructuras al no tener contrato vigente). Al estar inicialmente la tercera fase prácticamente dedicada a la instalación y configuración de las infraestructuras, atrasamos esta fase hasta la disposición de los servidores y licencias software, y adelantamos la cuarta fase "Implementación del caso de uso", teniendo que instalar una versión de Hadoop en local en los portátiles para disponer de un entorno de desarrollo. Al proporcionar Everis únicamente la mitad de las infraestructuras solicitadas, no se pudo implementar dos soluciones Big Data diferentes. Para compensar esto, se añadió una nueva fase en la que se diseñaron y realizaron varias pruebas sobre la solución Big Data instalada con la finalidad de exprimir y generar el máximo conocimiento posible sobre la solución. A continuación se detallan las fases de la planificación final, a partir de la tercera fase dado que las dos primeras fases se respetaron y no se han modificado. Fase 3 - Implementación del caso de uso en local Como hemos comentado en el apartado anterior, al terminar la implementación de la capa de recolección de datos del caso de uso, nos dimos cuenta de que las infraestructuras no iban a estar disponibles hasta un estado del proyecto bastante más avanzado. Por eso fue necesario realizar una reestructuración de la planificación. En esta reestructuración se acordó realizar la implementación del caso de uso en local. Las dos soluciones escogidas para la implementación de los pilotos se basaban en Hadoop, por lo que gran parte de la implementación del caso de uso iba a ser igual en ambos casos. Se decidió utilizar la distribución de Hadoop open source Cloudera CDH4 para el entorno de desarrollo en local en los portátiles. Gestión del proyecto | Planificación 8  Figura 7: Planificación final (fase 3 detallada). Durante el proceso de implementación en el entorno de desarrollo local se experimentaron varios obstáculos. Los más notables fueron el alto consumo de recursos que necesita Hadoop para funcionar y que nuestros portátiles no daban abasto. Se experimentaron graves problemas de rendimiento, como congelarse el entorno de desarrollo durante varios minutos o tener que esperar varios segundos al realizar cualquier acción en el sistema operativo. Se desaconseja totalmente utilizar un entorno de desarrollo local para implementar un caso de uso Big Data. A pesar de los obstáculos de rendimiento, al implementar ambos autores del proyecto el mismo caso de uso sobre la misma solución Big Data (Cloudera), se agilizó bastante dicha implementación pudiendo repartir y aislar de forma coherente las diferentes capas del capo de uso. Fase 4 - Diseño y realización de pruebas El objetivo de esta fase era compensar el hecho de trabajar con un solo piloto (inicialmente iban a ser dos), diseñando y ejecutando un seguido de pruebas para intentar generar el máximo conocimiento posible sobre la solución Big Data trabajada (Cloudera), para intentar formalizar mediante las pruebas una guía de buenas prácticas al implementar un caso de uso en Hadoop - Cloudera (Cloudera es una distribución de Hadoop). A mediados de esta fase (concretamente el 1 de Julio de 2013) se adquirieron las infraestructuras para poder instalar y configurar el piloto Big Data. Una vez el clúster estaba correctamente instalado con la solución Big Data escogida se procedió a la ejecución de las pruebas diseñadas al principio de la fase. Estas pruebas tuvieron una pausa de mes y medio (agosto y la primera quincena de setiembre), dado que hasta el 16 de setiembre no entraba en vigor el nuevo contrato de beca. Gestión del proyecto | Planificación 9  Figura 8: Planificación final (fase 4 detallada). Al finalizar la ejecución de las pruebas sobre las diferentes herramientas de Hadoop - Cloudera (HDFS, MapReduce, Mahout, Impala...), se presentó la valoración de los resultados obtenidos a los tutores. Fase 5 - Despliegue del caso de uso En esta fase se realizó el despliegue al entorno Big Data proporcionado por Everis del caso de uso Big Data implementado en la tercera fase. Además a finales de la cuarta fase uno de los tutores nos propuso implementar un pequeño caso de uso extra relacionado con un proyecto en el que se encontraba en ese momento. El caso de uso era interesante y no extremadamente largo, por lo que se procedió a su implementación. Al finalizar la implementación del caso de uso extra, ambos casos de uso (el extra y el principal desarrollado en la tercera fase) se despliegan en el entorno productivo Big Data y se realizan un seguido de pruebas y experimentaciones sobre ellos para facilitar la extracción de resultados y conclusiones. Figura 9: Planificación final (fase 5 detallada). Gestión del proyecto | Planificación 10 Fase 6 - Análisis de resultados y conclusiones Finalmente la sexta fase de la nueva planificación equivale a la quinta fase de la planificación inicial. En esta fase se realizó la recolección de todas las conclusiones obtenidas a lo largo de todo el proyecto, y la presentación de dichas conclusiones a los tutores en la empresa. Figura 10: Planificación final (fase 6 detallada). Gestión del proyecto | Planificación 11 3. PRESUPUESTO En este apartado se estiman los costes asociadas a la realización del proyecto Big Data. Los costes se han dividido en costes materiales y de personal. Los costes materiales son básicamente los gastos del proyecto asociados al hardware, software y recursos de la empresa utilizados. A nivel de hardware, a cada uno Everis nos ha facilitado un portátil con el que poder trabajar. Además de las infraestructuras para poder montar un clúster Big Data (cuatro servidores), en el que ya hemos englobado en el precio de este recurso el coste asociado por el mantenimiento. A nivel de software se tienen en cuenta las licencias de todos los productos utilizados durante el desarrollo del proyecto, principalmente productos que han dado soporte a la documentación de la memoria del proyecto (Microsoft Word, Microsoft Excel...) ya incluidas en el precio del alquiler del portátil, y a la preparación de las infraestructuras mediante máquinas virtuales (VMware vCenter, VMware ESXI...), dado que la solución Big Data implementada (Cloudera) es open source, al igual que otras muchas herramientas utilizadas, y no han supuesto un coste adicional. Finalmente se ha añadido en costes materiales el alquiler del puesto de trabajo en el edificio de Everis (internet, luz, agua, material de oficina, etc.). Los costes materiales son estimaciones aproximadas ya que algunos de ellos son confidenciales de la empresa y no se pueden facilitar. Coste Meses Subtotal (€) Mensual (€) Alquiler del portátil (x2) 7 80 (x2) 1.120 Licencias de software de virtualización (VMware) 4 30 120 Servidores y mantenimiento 4 300 1.200 Recursos de la empresa (internet, luz...) 7 260 1.820 Total Costes Materiales 4.260 Tabla 1: Costes materiales del proyecto. Dentro de los costes de personal, se incluyen las horas propias, juntamente con las horas recibidas de formación, soporte y gestión para llevar a cabo el proyecto, y que han dedicado los tutores asignados por Everis (José Roldán Rosón y Manuel Pando Mones). El soporte al proyecto por parte de ambos tutores se ha materializados en reuniones semanales con una duración aproximada de una hora cada una. En los últimos meses ha colaborado con el proyecto además un administrador de sistemas, que ha participado en la preparación e instalación de los servidores, sobre los que se ha montado el piloto Big Data. Gestión del proyecto | Presupuesto 12  Coste Meses Subtotal (€) Mensual (€) Robert Serrat Morros 7 830 5.810 Jordi Sabater Picañol 7 830 5.810 José Roldán Rosón 7 520 3.640 Manuel Pando Mones 7 520 3.640 Administrador de sistemas 4 150 600 Total Costes de Personal 19.500 Tabla 2: Costes de personal del proyecto. Finalmente, si se tienen en cuenta los costes materiales y de personal anteriormente especificados, el coste total del proyecto asciende a 23.760 €. Subtotal (€) Costes materiales 4.260 Costes de personal 19.500 Total 23.760 Tabla 3: Coste total del proyecto. Gestión del proyecto | Presupuesto 13 4. DIVISIÓN DEL TRABAJO El proyecto Big Data ha sido desarrollado junto a la colaboración de otro estudiante de la Facultad de Informática de Barcelona, Robert Serrat i Morros. En este apartado se busca aclarar la división del trabajo realizado, con la finalidad de aclarar que parte del proyecto ha realizado cada uno, y que partes se han realizado de forma conjunta. La idea inicial del proyecto, como se ha explicado en la planificación inicial, era desarrollar dos pilotos, cada uno utilizando una solución Big Data diferente. Buscando implementar en ambos casos un caso de uso parecido, y de este modo, al finalizar el proyecto, poder analizar la usabilidad, funcionalidad y productividad de cada solución mediante una comparativa exhaustiva. El objetivo era que cada estudiante se centrara en su propio piloto. No obstante, debido a que finalmente no se pudieron proporcionar más que la mitad de las infraestructuras solicitadas, sólo se pudo implementar un piloto Big Data. Por ello se intentaron dividir otros aspectos del proyecto, como el estudio teórico, la realización de pruebas y la implementación del caso de uso. A continuación se detalla la división de trabajo realizada. Herramientas del ecosistema Hadoop La primera división realizada fue en el apartado de herramientas del ecosistema Hadoop, donde se explican las diferentes herramientas que forman parte del ecosistema. El estudio teórico sobre las herramientas que más adelante se iban a utilizar en la implementación del caso de uso (como Flume, Hive o Mahout) se hicieron de forma conjunta, dividiendo únicamente aquellas que no se pudieron trabajar de forma práctica en este proyecto. La lista de herramientas del ecosistema Hadoop que cada uno ha trabajado en su propia memoria de proyecto son las siguientes (en amarillo las que se han trabajado de forma conjunta): Gestión del proyecto | División del trabajo 14  Robert Serrat Morros Jordi Sabater Picañol Flume Hive Mahout Oozie Hue Avro Sqoop Zookeper Ambari Cassandra HBase Solr Whirr Pig HCatalog Chukwa Cascading Tabla 4: División de las herramientas del ecosistema Hadoop. Soluciones Hadoop La segunda división, se realizó a raíz de las diferentes soluciones Big Data existentes que se basaban en Apache Hadoop. Se dividieron las soluciones Hadoop en tres grupos: Distribuciones, Appliance y Cloud. Todas las soluciones en formato distribución se dividieron entre los dos, haciendo de forma conjunta únicamente Cloudera dado que es la solución que más adelante íbamos a implementar en el piloto. En cuanto a los otros dos grupos, Appliance y Cloud, su división fue de forma completamente íntegra. Robert Serrat Morros se centró en la soluciones Hadoop en formato appliance mientras que Jordi Sabater Picañol en las soluciones Hadoop con formato cloud. Robert Serrat Morros Jordi Sabater Picañol Distribuciones Cloudera Pivotal HD IBM InfoSphere BigInsights DataStax MapR Hortonworks Data Platform Appliance Cloud Pivotal DCA Winsows Azure HDInsight Oracle Big Data Appliance Amazon EMR Tabla 5: División de las soluciones Hadoop. Gestión del proyecto | División del trabajo 15 Tests técnicos sobre la solución Cloudera La tercera división ya pertenecía al ámbito práctico. Se dividió el diseño y ejecución de los tests sobre la solución Cloudera. Los tests de usabilidad no se dividieron de forma exclusiva, dado que la experiencia en usabilidad puede resultar algo muy personal y presentar varias opiniones distintas. El resto de tests sí se dividieron de forma exclusiva, intentando dividirlos de forma que el que realizara los tests sobre una herramienta determinada, no fuera también quien implementaba esa herramienta en el piloto. De esta manera ambos pudimos trabajar con todas las herramientas utilizadas en el proyecto. Robert Serrat Morros Jordi Sabater Picañol Cloudera Manager (usabilidad) HDFS (funcionalidad, rendimiento y Mahout (funcionalidad) tolerancia a errores) Flume (funcionalidad, rendimiento y Hive (escalabilidad, rendimiento y tolerancia tolerancia a errores) a errores) MapReduce (rendimiento, escalabilidad y Impala (escalabilidad, rendimiento y tolerancia a errores) tolerancia a errores) YARN (rendimiento, escalabilidad, tolerancia Oozie (usabilidad y funcionalidad) a errores y funcionalidad) Pentaho (usabilidad y funcionalidad) Tabla 6: División del diseño y ejecución de pruebas sobre Cloudera. Implementación del caso de uso principal (redes sociales) La implementación del caso de uso también se dividió por herramientas / capas. En el repositorio GitHub del proyecto podéis encontrar todo el código del proyecto. La división fue la siguiente: Robert Serrat Morros Jordi Sabater Picañol Preprocesamiento de los tweets Recolección de datos (Twitter API y Flume) (MapReduce) Almacenamiento de datos (HDFS y Hive) Búsqueda de patrones (Mahout) Orquestación y diseño del workflow Preprocesamiento de los tweets (Diccionarios) (Oozie) Visualización de datos (Pentaho) Tabla 7: División de la implementación del caso de uso Análisis de la Imagen de un Producto a través de las Redes Sociales. Gestión del proyecto | División del trabajo 16 Implementación del caso de uso extra (análisis de ficheros log) Finalmente, como se ha comentado en la planificación, se realizó un caso de uso extra propuesto por uno de los tutores, que resultó ser muy interesante. En este caso de uso se buscaba comparar una solución secuencial con una solución distribuida (MapReduce) al problema de análisis de ficheros log. Robert Serrat Morros trabajó en la implementación de la solución secuencial, y Jordi Sabater Picañol en la solución distribuida utilizando el modelo de programación MapReduce. Las conclusiones se extrajeron de forma conjunta. Robert Serrat Morros Jordi Sabater Picañol Solución secuencial para el análisis de ficheros Solución distribuida para el análisis de de log ficheros de log Tabla 8: División de la implementación del caso de uso Análisis de Ficheros de Log. Cualquier otra tarea del proyecto que no aparezca en las tablas anteriores, ha sido fruto de una colaboración conjunta. Gestión del proyecto | División del trabajo 17 5. COMPETENCIAS TÉCNICAS Según la normativa vigente del trabajo de final de grado en ingeniería informática de la Facultad de Informática de Barcelona (FIB), el estudiante tiene que justificar las competencias técnicas de especialidad desarrolladas durante el proyecto. El objetivo de este apartado es realizar dicha justificación, explicando de forma detallada como se ha trabajado cada competencia técnica en este proyecto. A continuación se enumera cada competencia técnica de especialidad trabajada en el proyecto, poniendo en primer lugar el código identificativo y la descripción de la competencia técnica, y a continuación la justificación de como se ha trabajado en este proyecto. Código Descripción CES1.1 Desarrollar, mantener y evaluar sistemas y servicios software complejos y/o críticos Esta competencia técnica se ha desarrollado bastante. Big Data requiere grandes infraestructuras, y la forma más económica para ello es construir sistemas distribuidos complejos que faciliten la escalabilidad horizontal. La base de este proyecto ha sido la construcción y mantenimiento de un sistema distribuido de cuatro servidores, que permitiera ejecutar aplicaciones distribuidas. A pesar de que en el piloto se han utilizado únicamente cuatro servidores, se ha preparado el sistema distribuido de tal manera que fácilmente se pueden añadir nuevos nodos al clúster con la finalidad de obtener un mejor rendimiento en la ejecución de las aplicaciones distribuidas. El sistema distribuido implementado permite la ejecución de aplicaciones distribuidas mediante el modelo de programación MapReduce, y consultas interactivas sobre los datos almacenados mediante SQL. Ambos tipos de aplicaciones aprovechan todos los nodos del clúster para aumentar el rendimiento y reducir el tiempo de ejecución. Código Descripción Identificar, evaluar y gestionar los posibles riesgos asociados a la construcción de CES1.3 software que se pudieran presentar. Esta competencia técnica se ha desarrollado un poco. En este proyecto se ha implementado un caso de uso Big Data real entre dos programadores. El código Java de la implementación está disponible en el repositorio GitHub. Al dividir la implementación del caso de uso entre dos programadores, se ha tenido que realizar previamente un diseño de la arquitectura final completa de la aplicación, con la finalidad de que las partes que implementaba cada uno, pudieron encajar a la perfección y no Gestión del proyecto | Competencias técnicas 18 surgieran problemas inesperados provocados por no haber seguido unas mismas prácticas a la hora de implementar el caso de uso en Java. Código Descripción Desarrollar, mantener y evaluar servicios y aplicaciones distribuidas con soporte de CES1.4 red. Esta competencia técnica se ha desarrollado bastante. Las bases de este proyecto eran la construcción de un sistema complejo distribuido (competencia técnica CES1.1), y la implementación de aplicaciones distribuidas que se pudieran ejecutar sobre el sistema. El sistema distribuido implementado permite la ejecución de aplicaciones distribuidas mediante el modelo de programación MapReduce, y consultas interactivas sobre los datos almacenados mediante SQL. Ambos tipos de aplicaciones aprovechan todos los nodos del clúster para aumentar el rendimiento y reducir el tiempo de ejecución. Concretamente, en este proyecto se han implementado varias aplicaciones distribuidas para el análisis de ficheros de log, tratamiento de texto mediante diccionarios, búsqueda de patrones y consultas interactivas SQL. Para ello se ha utilizado como base el framework Hadoop, que aporta varias funcionalidades para facilitar en gran medida la implementación de aplicaciones distribuidas. Código Descripción CES1.5 Especificar, diseñar, implementar y evaluar bases de datos. Esta competencia técnica se ha desarrollado bastante. En la implementación del caso de uso Imagen de un Producto a través de las Redes Sociales ha sido necesario diseñar e implementar varias bases de datos para el almacenamiento de los tweets obtenidos, así como para almacenar también los datos obtenidos en los procesamientos realizados sobre los datos de entrada (como la búsqueda de patrones en los tweets). Las bases de datos estudiadas han sido de tipos muy diversos, desde bases de datos NoSQL hasta bases de datos relacionales y data warehouses. Finalmente se ha descartado la utilización de bases de datos NoSQL en el caso de uso y únicamente se ha implementado un data warehouse mediante la herramienta Hive del ecosistema Hadoop, y varias bases de datos relacionales Impala para poder consultar los datos almacenados de forma interactiva y distribuida. Gestión del proyecto | Competencias técnicas 19 Código Descripción CES3.2 Diseñar y gestionar un almacén de datos (data warehouse). Esta competencia técnica se ha desarrollado bastante. En la implementación del caso de uso Imagen de un Producto a través de las Redes Sociales ha sido necesario diseñar, implementar y mantener un data warehouse mediante la herramienta Hive del ecosistema Hadoop. Entre las tareas de diseño y mantenimiento del data warehouse están el particionamiento de algunas tablas para poder mejorar el rendimiento de las consultas más ejecutadas. En el data warehouse se han almacenado todos los tweets recolectados a lo largo de todo el proyecto así como toda la información asociada a ellos fruto de la ejecución de diversos procesamientos de análisis, como la búsqueda de patrones. El data warehouse ha tenido que soportar varias dimensiones de consulta, como la fecha en la que se escribió el tweet, el número de repeticiones y la etiqueta (hastag) con la que se encontró el tweet. Gestión del proyecto | Competencias técnicas 20 Parte II: BIG DATA 1. INTRODUCCIÓN Cada minuto que transcurre, los servidores de Facebook son capaces de gestionar más de 500.000 nuevos comentarios, más de 290.000 actualizaciones de estado y cerca de 140.000 fotografías subidas. Facebook no es un caso aislado, pues por ejemplo cada minuto se suben más de 72 horas de vídeo a Youtube , y se añaden más de 120.00 tweets en Twitter. Todos estos datos son Big Data. En algunas empresas poder tratar tales cantidades de información en un tiempo razonable ha sido una necesidad. Otras han visto en ello la oportunidad de avanzar a la competencia o simplemente de crecer, a través de la adquisición de nuevas fuentes de información para poder tomar decisiones más acertadas. En cualquier caso, poder tratar Big Data ha cobrado tanta importancia, que actualmente existen más de 2.100.000.000 entradas en Google donde hace poco no existía prácticamente ninguna. Ha llegado incluso a superar a Business Intelligence (BI) como término más buscado. Figura 11: Google Trends. Evolución del número de búsquedas de los términos Business Intelligence (rojo) y Big Data (azul) en Google. Big Data no es un concepto sencillo, debido al auge que ha experimentado en los últimos años se ha convertido en un término muy amplio, abarcando desde la tipología de los datos de entrada a los procesos de análisis, como los sistemas de almacenamiento que se utilizan para almacenar este tipo de datos y los modelos de programación que se utiliza para procesarlos. El concepto Big Data está estrechamente relacionado con los modelos de programación y sistemas distribuidos, pues debido a la naturaleza y complejidad de los datos Big Data (que explicaremos en el siguiente apartado), es necesario poder paralelizar los procesos de análisis con la finalidad de reducir el tiempo de ejecución, y poder obtener los resultados lo más rápido posible. Big Data | Introducción 22 2. ¿QUÉ ES BIG DATA? Big Data son datos que exceden la capacidad de procesamiento de los sistemas de bases de datos convencionales. La razón es que los datos son muy voluminosos, se mueven demasiado rápido o bien no se ajustan a ninguna de las estructuras de la arquitectura de la base de datos. Es por eso que cuando se define Big Data se habla de la definición de las 3Vs: Volumen, Velocidad y Variedad. Que describen las características más importantes de Big Data. Volumen: Big Data son volúmenes de datos muy grandes que fácilmente pueden superar el Petabyte (PB). Poder procesar cantidades masivas de información es el principal atractivo del análisis de Big Data: Tomar una decisión teniendo en cuenta 300 factores diferentes es mejor que si sólo tienes en cuenta 6. Velocidad: Big Data son datos que fluyen con mucha velocidad. Tanto por la rapidez con la que se crea nueva información entrante (por ejemplo los datos generados por los sensores de un avión o los ficheros de registro de un sistema distribuido), como por el tiempo que tardan en procesarse: Cuanto más actualizados se mantienen los factores de decisión o los procesos de análisis, mejor ventaja competitiva se obtiene (por ejemplo mantener actualizada una matriz de recomendaciones de productos en una tienda online puede suponer hacer mejores propuestas, y por lo tanto vender más). En muchos casos, además, la información almacenada es sensible en el tiempo y lo que hoy puede tener mucho valor para una empresa, puede suponer no tener ninguno mañana. Variedad: Big Data son datos completamente heterogéneos que en la mayoría de los casos no encajan en un esquema. Los datos pueden ser estructurados (si siguen un formato determinado, como por ejemplo las tablas relacionales de una base de datos relacional), no estructurados (si no encajan en ningún esquema, como por ejemplo los textos o los ficheros de audio), o semi-estructurados (si tienen una parte estructurada y otra no estructurada, como por ejemplo los ficheros XML en los que un elemento puede tener muchos subelementos mientras que otro puede no tener ningún subelemento). A pesar de que los tres términos anteriores son comunes a todas las definiciones de Big Data, algunas añaden características nuevas: Variabilidad: Hace referencia a las diferentes maneras en las que se puede interpretar los mismos datos: Diferentes preguntas sobre el mismo conjunto de datos tiene diferentes respuestas. También se refiere a la facilidad con la que los orígenes y tipos de datos pueden cambiar en el tiempo y la capacidad que ha de tener un sistema Big Data para adaptarse a estos cambios. Veracidad: Remarca la diferencia entre los sistemas tradicionales de data warehouse, donde siempre se ha considerado la información almacenada como información en la que se puede confiar, mientras que en Big Data se puede tener información de confianza dudosa como los comentarios de la gente en las redes sociales. La veracidad de la información determinará la influencia que tiene el resultado del análisis en la toma de futuras decisiones. Big Data | ¿Qué es Big Data? 23 Valor: Big Data son datos que tras un análisis o procesamiento aportan valor de negocio a la empresa. Sino no tendría sentido almacenar toda esa información. Si bien Big Data hace referencia principalmente a la tipología de los datos que se procesan (tienen un gran volumen y además no tienen una estructura bien definida), el concepto de Big Data incluye además los sistemas de almacenamiento para almacenar dichos datos así como los modelos de programación distribuida para procesarlos. Podemos decir que Big Data es un paradigma: un conjunto de herramientas y conceptos cuyo objetivo común es poder solventar las necesidad de las empresas, cada vez mayores, de poder analizar grandes volúmenes de información estructurada y no estructurada en un tiempo suficientemente pequeño como para que les permita obtener una ventaja. Big Data | ¿Qué es Big Data? 24 3. CASOS DE USO Big Data tiene muchas aplicaciones. Debido a su alta escalabilidad ofrece un abanico de posibilidades muy amplio en las que podemos encontrar algunos puntos en común. Hay que considerar una solución Big Data en los siguientes casos : Si la plataforma o entorno actual no puede procesar la cantidad de datos que necesitas en el tiempo esperado. Si se quiere añadir nuevas fuentes de datos al data warehouse sobre los que hacer consultas y análisis pero no se puede porque no se ajustan a un esquema bien definido, y por lo tanto se tendría que perder la fidelidad y la riqueza de los datos ya almacenados para poder incluir los nuevos. Si se necesita recoger datos de la forma más rápida posible, pero la plataforma sólo permite trabajar con paradigmas schema-on-write. Se debería poder aprovechar los beneficios de utilizar un schema-on-read y dar estructura a los datos sólo cuando se necesite procesarlos, de manera que no se tenga un coste añadido al recolectarlos. Si se tiene un gran volumen de información que no se termine de identificar si puede aportar valor a la empresa y por lo tanto no se quiera añadirl al data warehouse, o bien esta información es no estructurada o muy sensible en el tiempo (en poco tiempo ya no tendrá ningún valor para la empresa). Si se necesita procesar información entrante en streaming pero la plataforma no es capaz de absorber todo el procesamiento en tiempo real. Otra razón por la que puede ser aconsejable utilizar una solución Big Data a pesar de que ninguno de los puntos enumerados anteriormente coincida con las necesidades actuales, es si la previsión de crecimiento en el número de usuarios o volumen de datos de entrada es bastante grande. Adelantarse a las necesidades y preparar un sistema Big Data aunque actualmente no se vaya a aprovechar en su totalidad puede ahorrar bastante dinero en un futuro. Actualmente se ha explotado tanto la escalabilidad vertical, que continuar mejorando el rendimiento de los sistemas de procesamiento a partir de la mejora de los componentes Hardware (por ejemplo cambiando el disco duro por uno más grande o más rápido), puede ser inviable económicamente. La solución es en estos casos es la escalabilidad horizontal: Añadir nuevos ordenadores al sistema, sin necesidad de que sus componentes Hardware sean de gamma alta. A continuación se explican algunos de los usos de Big Data más extendidos : Servicios financieros La industria de los servicios financieros es una de las industrias que mayores cantidades de datos generan. Sólo con el comercio electrónico que tanta importancia ha cobrado en la última década se crean cada día millones de mensajes entre las tiendas y los servicios financieros. Big Data | Casos de uso 25 Además el entorno regulador en el que se encuentran los bancos y las compañías de seguros requiere que estas instituciones almacenen y analicen varios años de transacciones. En la mayoría de los casos las compañías han confiado en las tecnologías relacionales y herramientas de BI para el análisis de estos datos. No obstante, a pesar de que estas opciones seguirán teniendo un papel muy importante en estas entidades, la aparición de Big Data ha permitido agilizar procesos que antes podían tardar días, así como poder trabajar directamente sobre nuevos conjuntos de datos que antes no eran viables. Se estima que entre el 80 y el 90 por ciento de los datos de un servicio financiero son datos no estructurados (en su mayoría documentos de texto). Perfiles de cliente Actualmente el trato entre los clientes y sus bancos se ha vuelto más reservado. Los clientes ya no confían en un solo banco si no que crean varias cuentas en diferentes entidades (una que ofrece abrir una cuenta corriente sin cargos, otra que da los mayores intereses para los depósitos, etc.). Los bancos ya no disponen de tanta información de sus clientes como antes ni monopolizan todas sus transacciones. De este modo se ha hecho más difícil la toma de algunas decisiones; como determinar los clientes que puedan estar más interesados en nuevas promociones, o relacionadas con la autorización de hipotecas y créditos. Este hecho ha provocado que las entidades financieras busquen información de sus clientes en nuevas fuentes de datos que pueden llegar a ser muy dispares entre ellas: llamadas telefónicas grabadas, correos electrónicos, peticiones, sistemas de pago, e incluso aprovechar el auge de las redes sociales para saber más sobre los intereses de sus clientes. Detección de fraude Detectar el fraude a tiempo o poder predecirlo es muy importante ya que siempre hay una víctima involucrada que puede salir muy perjudicada. Actualmente la mayoría de los sistemas de detección de fraude se basan en perfiles, en lugar de investigar el comportamiento individual de cada individuo. Obviamente el segundo enfoque es mucho mejor que el primero, ya que una persona que esté cometiendo fraude puede no dar el perfil determinado. Pero también requiere trabajar con conjuntos de datos mucho más grandes a la vez que se mantiene un tiempo de procesamiento pequeño para poder detectar los casos de fraude lo más rápido posible. Con Big Data se permite construir modelos de predicción más complejos. Una compañía de tarjetas de crédito por ejemplo, puede utilizar tecnología Big Data para identificar un comportamiento transaccional que indique una alta probabilidad de que una tarjeta determinada sea robada. Big Data | Casos de uso 26 Reducción de riesgo Big data se utiliza para analizar en tiempo real las tendencias de mercado potenciales, y entender las posibilidades futuras para reducir el riesgo al tomar una posición financiera o modificar la cartera de inversiones. Análisis de ficheros de registros (logs) Big data permite a las empresas ganar mejores conocimientos de cómo funcionan sus sistemas, por ejemplo, gracias al procesamiento de ficheros de registro se puede determinar de forma rápida cuando y porqué ha fallado un sistema. En el caso concreto de las entidades financieras que suelen tener entornos distribuidos complejos, cuando algo falla en esos entornos es normalmente difícil determinar la causa ya que puede haber más de 20 ordenadores involucrados en una determinada transacción. La tecnología Big Data permite en estos casos poder analizar grandes cantidades de ficheros de registro en un tiempo de respuesta razonablemente bueno (cuantos más nodos tenga el sistema Big Data mejores tiempos de respuesta se obtendrán). Al poder analizar los ficheros de registro se permite descifrar que ha ocurrido exactamente en cada transacción y que componentes del sistema lo han provocado, para poder proceder a arreglar el problema. Streaming de sensores o datos Los sensores están cobrando poco a poco mucha importancia, son el punto de mira de muchos centros de innovación y aseguran que en algunas empresas permitirán aumentar razonablemente su productividad. Los sensores de un avión a reacción Boeing, por ejemplo, pueden llegar a producir hasta 10 TB de información cada 30 minutos de vuelo. Sólo en el acelerador de partículas europeo (CERN) se pueden generar hasta 40 TB por segundo.Es un volumen de información muy grande que un sistema normal no sería capaz de procesar a tiempo real. Actualmente se utilizan sistemas Big Data para poder predecir terremotos u otros desastres naturales a partir del análisis de sensores. Los datos entrantes pueden proceder de otras muchas fuentes aparte de los sensores. Por ejemplo algunas empresas utilizan soluciones Big Data para streaming de ficheros de registro. De esta manera consiguen monitorizar en tiempo real el estado de salud de su sistema, pudiendo ser capaz de recoger las incidencias a tiempo y prevenir un corte del servicio. Big Data | Casos de uso 27 Análisis de sentimiento Utilizando fuentes de datos internas (correos a atención al consumidor, llamadas telefónicas grabadas) o ajenas (por ejemplo redes sociales), es posible saber lo que los clientes piensan de tu producto o del producto de la competencia, como que novedades les gustaría que se añadieran o bien que partes no terminan de gustar. Saber lo que la gente dice de un producto no es tan importante como el saber porque lo han dicho. Así pues una persona puede comentar en su perfil que un determinado producto no le gusta pero no indicar la razón. Por lo tanto, paralelamente habría que hacer algún estudio sobre las promociones realizadas, cambios de precios, marketing… Para poder encontrar las causas que coincidan temporalmente con las tendencias de opinión. Otro aspecto importante de este sector es el poder clasificar el nivel de enfado o agradecimiento de una persona respecto a un servicio o producto. Por ejemplo, frases como “es la tercera vez que llamo” al analizar una llamada telefónica grabada al servicio de atención al cliente, suele indicar disconformidad con la atención recibida. Marketing Poder enfocar una campaña al sector de la población más sensible al producto anunciado puede ahorrar mucho dinero a las compañías de marketing. Las compañías pueden utilizar toda la información de que dispongan para determinar las preferencias de algunos sectores concretos o bien poder enfocar anuncios u ofertas online individualmente a las personas que más puedan gustarle. Con un sistema Big Data estos procesos pueden hacerse en mucho menos tiempo que con los sistemas tradicionales, ya que suelen ser conjuntos de datos muy grandes y no estructurados. Clickstream Un servidor web puede guardar en un fichero de registro todas las interacciones que observa entre un usuario o navegador y la aplicación web. Los datos guardados se pueden analizar para poder comprobar cómo se accede a la página web, si hay partes de la página que se acceden muy poco, si al rellenar un formulario los usuarios suelen dejarse algún campo en concreto, etc. El resultado de un buen análisis de toda la información recogida puede permitir optimizar la página web para facilitar e incrementar su uso. Big Data | Casos de uso 28 4. ARQUITECTURA La arquitectura que tiene un sistema de análisis de Big Data es la misma que tendría cualquier sistema de análisis de información. Es una arquitectura de cinco capas (o etapas), donde en cada una hay un conjunto amplio de herramientas que facilitan los procesos que se llevan a cabo en ella, algunas de las cuales estudiaremos más adelante en el apartado de ecosistema Hadoop. Figura 12: Arquitectura en capas de un sistema de análisis de información. 4.1. RECOLECCIÓN En la capa de recolección de datos es donde se lleva a cabo la obtención de datos legales (cumplen la ley de protección de datos), considerados que tras un procesamiento adecuado pueden aportar información de valor para la empresa. En Big Data los datos recolectados suelen ser muy grandes y de formato no estructurado. Algunos ejemplos de fuentes de procedencia de estos datos pueden ser redes sociales, ficheros de log, sensores (donde los datos además fluyen con mucha velocidad), o simplemente documentos de texto, audio o vídeo que la empresa ha ido guardando durante bastante tiempo e incluso bases de datos relacionales. Con un conjunto de fuentes de información tan diverso es normal también que existan bastantes herramientas, cada una especializada en obtener los datos de una forma concreta. Tenemos herramientas que permiten mover grandes volúmenes de datos almacenados en bases de datos relacionales hacia donde podamos analizarlos adecuadamente, herramientas que permiten recolectar la información en streaming si esta fluye de forma rápida, APIs REST para facilitar la extracción de datos de redes sociales como Twitter, Facebook o Linkedin, etc. La capa de recolección envía los datos a la etapa de almacenamiento, donde se guardarán todos los datos recolectados para su futuro procesamiento. Big Data | Arquitectura 29 4.2. ALMACENAMIENTO En esta capa se encuentran todas las herramientas que permiten almacenar información de gran volumen y de formato variable. El gran tamaño de los conjuntos de datos es la principal razón por la que estas herramientas normalmente son distribuidas y altamente escalables (si estás a punto de quedarte sin espacio disponible, fácilmente puedes añadir un nodo o varios nodos más al clúster para poder hacer crecer el tamaño total). En la mayoría de los casos estas herramientas permitirán además replicar la información almacenada para que tengamos un almacenamiento tolerante a fallos que puedan provocar pérdida de información. En Big Data existe un abanico de sistemas de almacenamiento bastante grande y muy diferentes entres ellos, debido a la variabilidad de los datos recolectados. Tenemos bases de datos NoSQL para datos dispersos o con un esquema semi-estructurado, bases de datos relacionales y sistemas de ficheros distribuidos. Además de varios servicios de almacenamiento en Cloud que permiten tener almacenamiento escalable de forma rápida (sin preocuparte de comprar, instalar y configurar nuevos servidores). En esta capa no sólo se almacenan los datos recolectados en la etapa de recolección, sino que además se suelen almacenar los resultados obtenidos al procesar un conjunto de datos en la etapa de procesamiento. 4.2.1 BASES DE DATOS NOSQL Las bases de datos NoSQL son conocidas como la nueva generación de bases de datos, no obstante no han aparecido para sustituir a las bases de datos relacionales, pues los objetivos de cada una son muy diferentes. El auge de las bases de datos NoSQL empezó en el año 2009 con la idea de poder ser utilizadas como sistema de almacenamiento para sitios web modernos que iban a tener una gran comunidad de usuarios, por lo que su sistema de almacenamiento tenía que ser altamente escalable. Las bases de datos NoSQL están estrechamente relacionadas con los términos: distribuido, escalabilidad horizontal, open source y no relacional. Y las características más comunes son: esquema flexible (a diferencia de las bases de datos relacionales que imponen un esquema fijo), soporte para facilitar la replicación de datos con la finalidad de aumentar la tolerancia a errores y disminuir el número de cuellos de botella (por ejemplo si la mayoría de los usuarios quiere acceder a la misma información), capacidad para almacenar una gran cantidad de datos, y una API bastante fácil de utilizar. Para poder disponer de todas las características enumeradas en el párrafo anterior, las bases de datos NoSQL tienen que sacrificar algunas de las propiedades ACID que están tan estrechamente ligadas a las bases de datos relaciones. Big Data | Arquitectura 30 Recordemos brevemente las propiedades ACID : Atomicidad: Esta propiedad asegura que un determinado conjunto de operaciones (transacción) realizado sobre la base de datos se ha realizado de forma completa o no se ha realizado ninguna de las operaciones de la transacción, pero nunca se quedará completado de forma parcial ante un fallo del sistema. Consistencia: La consistencia asegura que al ejecutar una transacción sobre la base de datos, esta no va a quedar en un estado inválido teniendo en cuenta las reglas definidas (restricciones de tabla, restricciones de columna, disparadores, etc.). Aislamiento (del inglés Isolation): La propiedad de aislamiento asegura que dos o más transacciones puedan ejecutarse de forma concurrente sobre un mismo conjunto de datos. La ejecución de una transacción no puede afectar al resultado obtenido por otra. Durabilidad: Esta propiedad garantiza que una vez se ha ejecutado correctamente una transacción, los cambios realizados en la base de datos provocados por esta transacción van a persistir y no se van a deshacer aunque el sistema falle inmediatamente después de su ejecución (los cambios se almacenan directamente en un dispositivo no volátil). Las propiedades ACID parecen indispensables para cualquier sistema de almacenamiento que tenga una finalidad productiva, y aun así son incompatibles con alta y disponibilidad y alto rendimiento en sistemas muy grandes. Por ejemplo, si imaginemos una tienda de libros online que muestra el número de libros que tiene en stock en aquel preciso instante. Cada vez que un cliente esté en proceso de comprar de algún libro, hay que ir realizando consultas sobre la base de datos hasta que termine el proceso, con la finalidad de mantener actualizado el stock total de ese libro. Esto funciona bien si la tienda de libros online no es muy grande, pero no funciona por ejemplo en Amazon. Amazon puede utilizar datos en caché para comprobar cuál era el estado del stock de sus libros en el último instante en que se realizó la "fotografía" del inventario. Los clientes cuando vean el stock no tiene porqué ser el stock real, sino que puede ser los datos de hace media hora. Pero en ningún caso es viable hacer consultas en tiempo real sobre el stock de todos los productos de la base de datos, pues ralentizaría el rendimiento del sistema en gran medida. Amazon puede también, por ejemplo, sacrificar la "I" de "Isolation" (Aislamiento), permitiendo una probabilidad pequeña de que haya dos transacciones en ejecución que una pueda interferir en la otra. Dos clientes pueden pensar haber comprado un mismo libro, cuando en verdad uno de ellos no lo ha hecho por falta de stock. Amazon puede preferir correr el riesgo de tener que disculparse antes de disminuir el rendimiento de su sitio web y disgustar a muchísimos más usuarios. El teorema CAP (o teorema de Brewer), expone que para sistemas de almacenamiento distribuido (la única solución si hablamos de grandes cantidades de datos), es imposible garantizar simultáneamente las tres propiedades siguientes : Big Data | Arquitectura 31  Consistencia: Todos los nodos del sistema distribuido son conscientes del mismo estado de la información. No puede ocurrir que dos nodos tengan un mismo dato con valores diferentes (inconsistencia). Una misma lectura en cualquiera de los nodos del clúster obtendrá el mismo resultado. Disponibilidad (del inglés Availability): El sistema siempre está disponible. Si un cliente realiza una operación de lectura o escritura sobre él, siempre recibirá una respuesta de confirmación sobre si la operación ha terminado correctamente o no, pero nunca se quedará sin conexión al sistema. Tolerancia a fallos (del inglés Partition Tolerance): El sistema continua funcionando correctamente incluso cuando alguno de los nodos o parte de la red está experimentando fallos o problemas. El término "partición" hace referencia al hecho de que aunque dos nodos del sistema distribuido hayan quedado descomunicados (el sistema ha quedado particionado o dividido), ambos seguirán aceptando lecturas y escrituras aunque eso suponga mantener dos estados diferentes de la base de datos. Según el teorema, un sistema distribuido solo puede garantizar simultáneamente dos de estas propiedades. Figura 13: Teorema CAP, en un sistema de almacenamiento distribuido solo puedes garantizar simultáneamente dos de las tres propiedades. Los sistemas de gestión de bases de datos relaciones (RDBMS) distribuidos se basan en las propiedades Disponibilidad y Consistencia, o Consistencia y Tolerancia a fallos, mientras que los sistemas de almacenamiento NoSQL se basan en Disponibilidad y Tolerancia a fallos, o Consistencia y Tolerancia a fallos. Big Data | Arquitectura 32 Visto que un único sistema de almacenamiento distribuido no puede garantizar todas las propiedades a la vez, y teniendo en cuenta que un sistema distribuido es hoy en día la única solución disponible cuando hay detrás una gran cantidad de datos y usuarios, las bases de datos NoSQL buscan romper con las propiedades ACID de las bases de datos relacionales para poder así mejorar otras características que se consideren más importantes, como la escalabilidad horizontal, la simplificación del modelo de datos (resultando en un menor número de operaciones JOIN y por lo tanto un mejor rendimiento), capacidad de almacenar más datos, esquema de datos flexible, mejorar el tiempo de respuesta (al no tener que bloquear tantas tablas para realizar operaciones de escritura), etc.. El resultado de sacrificar las propiedades ACID: las propiedades BASE (por el símil químico de los ácidos y bases). El acrónimo BASE hace referencia a las siguientes propiedades (compartidas por las bases de datos NoSQL) : Basically Available: Alta Disponibilidad. Mediante mecanismos como la replicación de datos entre diferentes servidores de almacenamiento, se permite tener un sistema distribuido que a pesar de que alguno de los nodos sufra un error o fallo todos los datos siguen siendo accesibles desde el exterior. Soft state: Estado flexible. Se permite a los datos estar en un estado de inconsistencia, y se delega como se tratará esta inconsistencia los desarrollares. Eventually consistent: Eventualmente consistente. A pesar de que se permite a los datos estar en un estado de inconsistencia, eventualmente se garantiza que los datos volverán a un estado de consistencia. Fuera de las propiedades BASE, las bases de datos NoSQL ya no tienen otras propiedades comunes, pues a diferencia de las bases de datos relaciones que todas tienen unos objetivos muy parecidos, el abanico de bases de datos NoSQL es muy grande y cada una desarrollada con una intención muy específica. Podemos encontrar por ejemplo bases de datos orientadas a familias de columnas (cada entrada en la base de datos sigue teniendo una clave primaria, pero además cada columna puede tener más de un valor), bases de datos orientadas a clave-valor (bases de datos de acceso muy rápido mediante tablas de hash), bases de datos orientadas a objetos (se permite almacenar objetos en formatos como JSON), y otros muchos tipos de bases de datos NoSQL con funcionalidades y objetivos muy diferentes. Finalmente, NoSQL no significa que las bases de datos no utilicen para nada el lenguaje SQL. NoSQL significa "Not only SQL", y de hecho muchas de las bases de datos NoSQL permiten acceder a los datos mediante lenguaje SQL o un conjunto de las operaciones estándares del lenguaje SQL. Big Data | Arquitectura 33 4.3. PROCESAMIENTO Y ANÁLISIS / BUSSINESS INTELLIGENCE En la capa de procesamiento es donde se lleva a cabo todos los análisis, y procesamientos previos de los datos para el futuro análisis, de los datos almacenados para extraer la información de valor que contienen. Entre la capa de almacenamiento y la capa de procesamiento los datos fluyen en ambas direcciones ya que o bien se obtiene un conjunto de los datos almacenados para poder procesarlos y analizarlos, o bien se ha hecho ya el procesamiento de los datos y es necesario almacenarlos para poder visualizarlos más adelante o hacer otros procesamientos más complejos que requerían previamente preparar los datos. Para procesar y analizar los datos tenemos librerías con funciones ya implementadas para facilitar el análisis, lenguajes de alto nivel que traducen automáticamente lo que ha expresado el usuario en procesos complejos, paradigmas de procesamiento como MapReduce o MPP (explicados en la siguiente sección), herramientas para diseñar workflows, etc. En esta capa juega un papel muy importante la línea de productos Bussiness Intelligence. Pues para comunicar los datos almacenados con los sistemas de visualización de datos, se pueden construir cubos de OLAP y otras estructuras de procesamiento que permitan agilizar el proceso con el que las herramientas de visualización pueden acceder a los datos solicitados. 4.4. VISUALIZACIÓN La capa de visualización es la etapa en la que se muestran los resultados de los análisis que se han realizado sobre los datos almacenados. La visualización de los resultados es normalmente bastante gráfica, de manera que se permita una adquisición rápida de conclusiones para poder decidir cuanto antes como actuar o que estrategias se van a seguir, con el objetivo de poder ganar la máxima ventaja o evitar un problema mayor (por ejemplo en la detección de fraude: cuanto antes se detecta una tarjeta robada, menos compras se hacen sin el consentimiento del propietario). Para la etapa de visualización se utilizan muchas de las herramientas que ya se habían utilizado hasta el momento en Business Intelligence, como Microstrategy o IBM Cognos. Para lograr esta conectividad la mayoría de las soluciones Big Data proporcionan conectores JDBC, ODBC o similares, que de forma transparente al usuario, permiten obtener los resultados almacenados independientemente de su formato, y agilizan las consultas mediante la construcciones de estructuras como cubos de OLAP en la capa de procesamiento. Big Data | Arquitectura 34 Figura 14: Ejemplo de un Dashboard para mostrar los resultados de los análisis de forma visual. La imagen corresponde a un ejemplo de las ventas y beneficios obtenidos por una franquicia de tiendas realizado con la herramienta de visualización Pentaho. 4.5. ADMINISTRACIÓN La capa de administración está presenta durante todo el proceso de recolección, almacenamiento, procesamiento y visualización. Esto se debe a que en esta capa se encuentran todas las herramientas que permiten administrar y monitorizar el estado de los sistemas que intervienen durante todos los procesos. Algunos ejemplos de funcionalidades en esta capa son: comprobar que todos los nodos de un sistema distribuido están activos, controlar el factor de replicación o modelo de compresión de los datos almacenados, cargar en el sistema y ejecutar nuevas aplicaciones de análisis de datos, etc. Big Data | Arquitectura 35 5. PARADIGMAS Las diferentes maneras de trabajar con Big Data han ido convergiendo en dos modelos o paradigmas diferentes: map-reduce y bases de datos MPP (Massively Parallel Processing). Es importante hacer un recordatorio de las tres características principales de Big Data (volumen, velocidad y variedad), ya que de estos factores depende determinar cuál de los dos paradigmas es más adecuado para cada caso. En ambos caso la filosofía es la misma: para grandes tamaños de datos, es más económico trasladar la lógica de procesamiento a los datos, que no los datos a la lógica de procesamiento. 5.1. MAP-REDUCE El modelo de programación map-reduce (en adelante MR) fue desarrollado inicialmente por Google. Se ha extendido mucho en parte gracias a su simplicidad: un programa MR consiste únicamente en dos funciones, llamadas “map” y “reduce”, pensadas para que ambas sean capaces de trabajar parejas de datos con formato clave/valor. Los datos de entrada se dividen inicialmente en particiones y se distribuyen en un sistema de ficheros distribuido. Cuando se ejecuta un proceso MR, la lógica de procesamiento se inyecta en los nodos que contienen la información a procesar de manera que no hay que trasladar los datos a ningún sitio (que tendría un coste elevado ya que son muchos datos). Inicialmente el conjunto de datos que se quieren procesar son divididos mediante una función split automática. Esta función divide los datos de entrada en trozos que serán enviados a la función map más adecuada dependiendo de su localización (siempre se intenta que la función map procese los datos que se encuentran en el mismo nodo donde se ejecuta). La función map lee los datos recibidos y los procesa/analiza/filtra de la manera que el usuario ha decidido, para terminar obteniendo una salida formada por un conjunto de parejas clave/valor. Imaginamos el siguiente ejemplo: Tenemos un libro muy grande en formato texto almacenado de forma distribuida entre los nodos, y queremos ejecutar un proceso MR que calcule la frecuencia de aparición de todas las palabras que existen en el libro. Con este objetivo en mente, se programaría una función map que reciba fragmentos de texto del libro, y para cada palabra encontrada en los fragmentos recibidos, escriba en un fichero de salida temporal la pareja clave/valor formada por /1. La manera en que se trocean los datos de entrada viene determinada por la función automática split. Una forma común de trocear los ficheros de texto es por líneas: Las funciones map van recibiendo partes del texto línea a línea. Big Data | Paradigmas 36 A medida que las funciones map van finalizando su trabajo, un mecanismo que depende de cada implementación del paradigma MR, envía las parejas clave/valor escritos por el map en el fichero de salida temporal a las funciones reduce, de manera que todas las parejas que tienen la misma clave, van al mismo reducer (normalmente se ejecuta una función reduce por nodo disponible). En este caso no se puede aprovechar la localidad de los datos ya que cada nodo tiene varios ficheros con los resultados intermedios de la función map ejecutada en ese nodo, por lo que los ficheros deben ser enviados a través de la red (normalmente estos ficheros son muy ligeros, pues son el resultado de haber procesado los ficheros de entrada, y no supone un coste grande). Los ficheros que contienen las parejas con las mismas claves serán enviados al mismo nodo para ser tratados por la misma función reduce, es decir, un mismo reducer procesará diferentes claves. Normalmente el número total de claves se distribuye de forma equitativa entre todos los nodos del clúster que van a hacer de reducer (es decir, van a ejecutar una función reduce). La función reduce combina todas las parejas con la misma clave de la forma que el usuario determina, y guarda los resultados en un fichero del sistema de ficheros compartido por todos los nodos. Siguiendo con el ejemplo del contador de palabras de un libro. A una misma función reduce se envían todas las parejas intermedias que contienen la misma clave. Una función reduce concreta puede recibir todas las parejas que contienen la clave “paralelismo”. Así pues la función reduce procesa las parejas con clave “paralelismo”, y combinamos las frecuencias para hacer el cómputo total de apariciones de esa palabra. Dada la siguiente entrada en la función reduce: “paralelismo/1”, “paralelismo/1” y “distribuido/1”; escribiremos en el fichero final el resultado “paralelismo/2” y "distribuido/1". Un nodo máster se encarga de decidir el número de funciones map y reduce que se ejecutaran, cuantos nodos del clúster intervendrán, y en general, todos los aspectos de coordinación necesarios para optimizar la ejecución de un proceso MR. Figura 15: Ejemplo de proceso MR: calculando la frecuencia de aparición de cada palabra en un texto. Big Data | Paradigmas 37 5.2. BASES DE DATOS RELACIONALES MPP Las bases de dato MPP o Parallel DBMSs (Parallel DataBase Management System) son bases de datos capaces de trabajar en un clúster de nodos, que existen desde finales de los años 80. Estos sistemas soportan tablas relacionales y el lenguaje de consulta SQL. Además el hecho de que las tablas están distribuidas en diferentes nodos es completamente transparente al usuario. Gracias a la distribución de las tablas entre los nodos, las bases de datos MPP tienen optimizadores para traducir las consultas SQL en un plan de ejecución dividido entre múltiplos nodos aprovechando la localidad de los datos de cada uno y los índices disponibles. Estos sistemas han tenido mucho éxito ya que no sólo son escalables y rápidos, sino que permiten al usuario expresar lo que quiere en un lenguaje de alto nivel, sin que éste deba preocuparse por las estrategias de operaciones como las JOIN, la programación de las funciones de procesamiento de los datos, etc. El principal problema de este paradigma es el hecho de que los datos deben tener una estructura bastante estricta que no permite trabajar con datos como documentos de texto o imágenes. COMPARACIÓN Ambos enfoques tienen bastantes puntos en común, pero también hay diferencias importantes que provocan que cada uno sea mejor opción que el otro en casos determinados. Existen otros modelos de programación distribuida para el análisis de la información almacenada. No obstante estos dos son actualmente los modelos más utilizados por las compañías, tomando una gran delantera respecto a otros paradigmas. En la siguiente tabla se detallan los aspectos más relevantes de cada paradigma de análisis de datos de forma distribuida. Big Data | Paradigmas 38  Map-Reduce MPP Alto (datos estructurados, semi- Bajo (datos estructurados y en Variedad estructurados y no estructurados) ciertos casos semi-estructurados) Medio (schema-on-write y Recolección de datos Alto (schema-on-read) mantenimiento de índices) Velocidad Medio (análisis recorriendo todo el Alto (análisis aprovechando los Análisis de datos fichero) índices) Alto (varios índices por tabla y sobre Bajo (bastantes limitaciones a la hora Índices la combinación de atributos que de crear índices) mejor aumente el rendimiento) Bajo (hay que programar algoritmos Modelo de programación y en algunos casos combinar varios Alto (consultas en SQL) lenguajes)* Tolerancia a pérdida Alto (datos replicados y distribuidos) Alto (datos replicados y distribuidos) de datos Alto (gracias a que los nodos generan Tolerancia a Tolerancia a fallos ficheros intermedios y los datos están fallos Bajo (si un nodo se cae hay que durante la ejecución distribuidos, si un nodo se cae, de un proceso volver a empezar) automáticamente se levanta otro que lo suplanta) Muy Alto (con facilidad puedes Alto (con facilidad puedes añadir añadir nuevos nodos para aumentar nuevos nodos para aumentar la Almacenamiento la capacidad. El sistema capacidad. El sistema automáticamente distribuirá datos al automáticamente distribuirá datos al nuevo nodo) nuevo nodo)** Escalabilidad Alto (con facilidad puedes añadir nuevos nodos para aumentar la Alto (con facilidad puedes añadir velocidad de procesamiento. El Procesamiento nuevos nodos para aumentar la sistema automáticamente velocidad de procesamiento) particionará tablas y las distribuirá al nuevo nodo)** Medio (aprovechando la Alto (aprovechando la escalabilidad escalabilidad puedes almacenar Volumen de almacenamiento no tiene grandes volúmenes de información, restricciones) pero aumentando el coste de mantenimiento de los índices) Medio (en una misma consulta o Modificación de proceso de análisis pueden intervenir Alto (sólo hay que modificar el SQL) consultas varios lenguajes y herramientas) Variabilidad Modificación de tipos Bajo (al ser schema-on-write, Alto (al ser schema-on-read no das