parte_35.txt

Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 35 • Variedad : Se refiere a la heterogeneidad de los datos que d eben ser almacenados, procesados y/o analizados. Se puede pensar en varie dad cuando se debe analizar datos no estructurados como textos para obtener por ejemp lo...

Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 35 • Variedad : Se refiere a la heterogeneidad de los datos que d eben ser almacenados, procesados y/o analizados. Se puede pensar en varie dad cuando se debe analizar datos no estructurados como textos para obtener por ejemp lo la demografía de su autor, la existencia de plagio o la utilización del lenguaje figurado (ironía, sarcasmo). • Veracidad : Se refiere al nivel de fiabilidad asociado a los datos con los que trabajar. Por ejemplo, los datos recuperados de redes sociales pu eden no ser fiables (por ejemplo, redes de bots para difamar a un personaje público). • Valor : Se refiere al potencial valor que se puede obtene r de los datos, aunque en ocasiones puede depender más de la adecuación de la s técnicas de minería de datos que se le apliquen. A continuación, se va a realizar una revisión de la s infraestructuras y técnicas de big data más utilizadas desde las perspectivas del almacenamient o y el procesamiento. 5.1. Infraestructura de almacenamiento Tradicionalmente se han utilizado las bases de dato s relacionales para almacenamiento y consulta de la información transaccional de las organizacion es (sistemas OLTP). Sin embargo, con el crecimiento de las necesidades en los entornos big data , las bases de datos presentan ciertas limitaciones que no las hacen apropiadas para deter minadas tareas. Algunas de estas limitaciones tienen que ver con su estructura fija y las restric ciones de integridad. Cuando se ha desarrollado un producto, se ha diseñado su modelo de datos y se ha tratado de acomodar la información a modelar dentro de una estructura fija. Pero en big data ocurre que estos modelos de información evolucionan a lo largo del tiempo, tanto en la nece sidad de incorporar nuevas informaciones a los datos existentes o incluso variar las reglas de val idación de los mismos. Esta heterogeneidad en la información provoca constantes modificaciones en la estructura de la base de datos relacional, algo que por un lado puede afectar a su normalizaci ón, perdiendo así una de sus principales características, y que por otro lado y quizás más i mpactante, a su rendimiento, ya que cuando se intenta añadir, modificar o borrar grandes volúmene s de información, las bases de datos relacionales no son muy efectivas. En relación a esto último, otra de las grandes limi taciones de las bases de datos relacionales es su rendimiento en inserción de datos. Debido precisame nte a las comprobaciones necesarias para asegurar su estructura y sus restricciones, las bas es de datos relacionales no están optimizadas para la inserción masiva de datos (e.g. decenas de miles de inserciones por segundo). Si recordamos las fuentes de información, encontramos que algunas de ellas generan volúmenes de datos asombrosos casi de manera constante en el tie mpo (e.g. señales de sensores, conversaciones en redes sociales…). Esto implica ef ectuar inserciones de grandes volúmenes a gran velocidad, algo que pronto deteriora el rendim iento de estas bases de datos. Otro aspecto importante y que limita la capacidad d e uso de las bases de datos relacionales en entornos big data tiene que ver con una limitación en el significado de su propio nombre. Pese a que las bases de datos relacionales se llaman así p or permitir la relación entre datos, a partir de Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 36 TEMARIO OPOSICIONES COIICV | TEMA 36 las claves primarias y foráneas que permiten relaci onar unas tablas con otras, las bases de datos relacionales permiten trabajar con relaciones exist entes en el mundo real de una manera muy limitada. Esto es así porque las relaciones que se permiten están muy ligadas a su diseño, propiciando que ciertas consultas sean sencillas de hacer, pero otras lleguen a ser muy costosas, a la par que complican el diseño de la base de dato s mezclando tablas que modelan el mundo real (e.g. personas, pedidos, productos), y tablas que m odelan las relaciones n a n (e.g. líneas de pedido relacionando producto con pedido y con perso na). Esta meta-información necesaria para el correcto funcionamiento del modelo añade complejida d computacional al sistema, aún más cuando se producen relaciones nulas entre elementos (e.g. inner/left/right joins, in selects…). Pero el mayor problema aparece cuando se desea tratar con r elaciones más complejas y para las que no se ha modelado explícitamente el sistema, como por ejemplo cuando se desea contestar a preguntas como “¿qué clientes han comprado un produ cto?”, o cuando entramos en dominios altamente conectados. Veamos un simple ejemplo, las relaciones de amistad de Twitter, donde la amistad no es recíproca y considerar a alguien tu a migo no implica que él te considere amigo a ti (redes seguido/seguidor). Debido a estos y otros problemas con las bases de d atos relacionales, se ha evolucionado a sistemas que se conocen como bases de datos NoSQL , no por negar el uso de SQL, sino porque son algo más que SQL ( Not Only SQL ). Estas bases de datos NoSQL tienen por principal misión ser capaces de almacenar grandes volúmenes de datos desestructurados en pequeñas unidades de tiempo. Es decir, priman la inexistencia de regl as y restricciones, permitiendo insertar en cualquier momento cualquier tipo de información, qu izás en una estrategia perezosa que permita adaptarse al dominio a posteriori, agilizando y pri mando la inserción masiva de datos frente a su consulta. Existe gran variedad de bases de datos NoSQL, aunqu e por su mayor penetración en entornos big dat a (e.g. en empresas como Google, Facebook o Twitter ), vamos a considerar los siguientes cuatro tipos: orientadas a documentos, almacenes cl ave/valor u organizadas por filas, organizadas por columnas y basadas en grafos. 5.1.1. Bases de datos orientadas a documentos La unidad básica de almacenamiento en una base de d atos orientada a documentos es el documento. Un documento puede contener cualquier nú mero arbitrario de campos de cualquier tamaño y tipo, y puede almacenar múltiples valores. Un ejemplo de documento sería un objeto JSON o un objeto XML. Las bases de datos orientadas a documentos no requi eren de un esquema fijo de documento, flexibilizando así el modelado de objetos del mundo real. Si necesitamos crear un nuevo documento, éste podrá contener distintos campos al anterior. Una ventaja que proporciona este modelo es que para aquellos campos para los que no se disponga información (e.g. una persona para la que no tenemos el correo electrónico), no e s necesario almacenar un valor vacío o un nulo, reduciendo de manera considerable el espacio de alm acenamiento necesario. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 37 La seguridad en este tipo de bases de datos se asig na a nivel de documento individual, proporcionando mayor control sobre los accesos al m ismo. De manera similar, se proporciona la capacidad de búsqueda por texto completo de manera eficiente, algo que en las bases de datos relacionales puede resultar prohibitivo. Algunos ej emplos de bases de datos de este tipo son las siguientes: • IBM Lotus : siendo su primera versión de 1989, es una de las pioneras y fuente de inspiración para otras bases de datos orientadas a documentos como las que se describen a continuación. El modelo de documento es propietar io y no necesita esquema. Los documentos, conocidos como notas, se almacenan en u n formato nativo llamado Notes Storage File (NFS). Se integra en toda una suite de herramientas (Lotus Notes, Lotus Domino, etc.) y se puede acceder mediante APIs cons truidas en C, C++ y Java. • Apache CouchDB : nace entre 2005 y 2008 con el objetivo de ser la base de datos de la web. Su iniciador trabajó previamente para IBM en e l proyecto Lotus Notes, por lo que tienen ciertas similitudes, como la no necesidad de disponer de un esquema de datos. El formato de documentos es JSON y se puede acceder a los datos mediante una API RESTful vía peticiones HTTP. Una característica int eresante es que soporta MapReduce. • MongoDB : es quizás la base de datos orientada a documentos más conocida y usada en la actualidad, propiciado por características como ser open source, ser sencilla de instalar y mantener, o proporcionar soporte para MapReduce. MongoDB almacena los documentos en formato JSON, aunque permite la utilización de e squemas dinámicos, así como combina capacidades de almacenamiento clave/valor, base de datos orientada a objetos o base de datos relacional. Es utilizada por SourceFo rge, Bit.ly, Foursquare o GitHub, entre otros. 5.1.2. Almacenes clave/valor A diferencia de las bases de datos relacionales, do nde se define un esquema para modelar el dominio de información que se desea almacenar, con restricciones y normalizaciones, en los almacenes clave/valor no se especifica nada de lo a nterior. Simplemente se convierten en espacios donde almacenar cualquier información y de cualquier tipo, identificados por una clave y una serie de atributos. Así pues, cualquier objeto que se desee almacenar en un modelo clave/valor únicamente debe ser identificado por un a clave y una serie de atributos que lo definan. Al no existir estructura previa ni restricciones, p or ejemplo, un objeto tipo persona podrá almacenarse con unos atributos diferentes a otro ob jeto de tipo persona, y en ambos casos será la clave seleccionada la que identifique y haga accesi ble al objeto. Es por ello que se denominan también almacenes hash distribuidos, ya que como una función hash , a partir de una clave se obtiene un valor como por ejemplo el conjunto de at ributos que definen al objeto. Algunos almacenes clave/valor son los siguientes: • Dynamo DB : Nacida para dar soporte a las tiendas Amazon como base de datos escalable y de alto rendimiento, en la actualidad se ofrece c omo servicio a los clientes de Amazon Web Services (AWS). Dynamo es base de otras tecnolo gías como las siguientes. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 38 TEMARIO OPOSICIONES COIICV | TEMA 36 • Riak : Es una base de datos híbrida clave/valor y por co lumnas basada en Amazon Dynamo y desarrollada por Basho. Por otro lado, su sistema de tolerancia a fallos funciona de manera similar a Cassandra. Los datos se almacen an en buckets en parejas clave/valor, lo que la asemeja al sistema Google St orage. Se proporciona tanto licencia comercial como open source. • Voldermort : Proyecto de LinkedIn que se basa tanto en Dynamo como en Memcached, uno de sus principales objetivos es cubrir la alta demanda de lecturas y escrituras de una red social como LinkedIn. Voldemort permite definir esquemas clave-valor con los mismos tipos que permite JSON, lenguaje con el que se espe cifican. Se integra con Thrift, Avro y GPB (Google Protocol Buffers). Otros almacenes clave-valor son Memcached, Membase y Redis. 5.1.3. Bases de datos organizadas por columnas Son bases de datos que se organizan en torno a tabl as con familias de columnas predefinidas. Los datos pues se organizan en torno a columnas en luga r de en torno a filas. Esto propicia ciertas operaciones como las de agregar datos, tan utilizad as en los almacenes de datos orientados a OLAP. Ejemplos de bases de datos de este tipo tenem os: • Google Big Table (Chang et al., 2008): Es una base de datos de uso interno por Google con el principal objetivo de poder tratar con grand es volúmenes de datos (del orden del Petabyte) de manera escalable y tolerante a fallos. Se construye sobre el sistema de ficheros de Google File System (GFS) y soporta gran parte de los proyectos de Google como Gmail, Youtube, Analytics, Earth o el propio b uscador. • HBASE : Es un clon de Google Big Table pensado para ser i ntegrado con Hadoop y poder aplicar procesos MapReduce. Una de sus principales diferencias con el resto de bases de datos orientadas a columnas es que asegura la consi stencia de manera completa. • Cassandra : Es un proyecto open source de Apache para constru ir una base de datos distribuida, descentralizada, elástica, escalable, de alta disponibilidad, tolerante a fallos, personalizable y consistente que se ha diseñado sob re el modelo Amazon Dynamo en cuanto a consistencia y tolerancia se refiere, pero el modelo de datos se toma de Google Bigtable (Hewitt, 2011). Otras bases de datos organizadas por columnas son S ybase IQ o Hypertable. 5.1.4. Bases de datos basadas en grafos Las bases de datos NoSQL anteriores permiten la ins erción masiva de datos no estructurados y su rápida recuperación en base a claves únicas que ide ntifican la información. Sin embargo, este tipo de bases de datos sigue adoleciendo de problemas pa ra manejar relaciones. Por ejemplo, partiendo del modelo de compras de una empresa dond e tenemos personas que efectúan pedidos Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 39 y que dichos pedidos incorporan productos, en un mo delo de base de datos clave valor tendríamos las siguientes tres conjuntos de datos: personas, p edidos y productos. Mediante la agregación de campos de relación a cada uno de esos tres conjunto s podemos indicar cuál es la lista de pedidos que realiza una persona y cuál es la lista de produ ctos que incorpora cada pedido. La principal desventaja de este modelo es que se tiene que asegu rar por software el mantenimiento de estas relaciones, añadiendo, modificando o eliminando cua lquier nueva circunstancia. Esto, complica el desarrollo. Pero el principal problema viene cuando queremos re sponder a la pregunta que planteábamos con la base de datos relacional: ¿qué personas han comp rado determinado producto? Puesto que este modelo no dispone de relación, simplemente la hemos emulado mediante los enlaces agregados, y dichos enlaces no tienen una relación hacia atrás, esta pregunta no podemos contestarla sin recorrer por software toda la base de datos buscand o y memorizando las personas que compraron dicho producto, o bien añadiendo otro campo agregad o hacia atrás que almacene cada producto, por el pedido en el que ha sido incorporado, por qu é persona ha sido comprando, teniendo así en cada producto una lista de personas que lo compraro n. Esto es tremendamente costoso y complejo de manejar a nivel de software y nos hace plantearn os si no estamos simulando con NoSQL lo que ya nos proporcionaba el SQL. En este punto es donde las bases de datos basadas e n grafo aportan su valor, ya que almacenan inherentemente no sólo la información de los elemen tos del modelo (e.g. personas, pedidos, productos), sino también la información de las rela ciones entre ellos (e.g. amigo de, pide, incluye, es_pedido, es_incluido), lo que va a permitir no só lo consultar sobre un elemento (base de datos NoSQL clave/valor), o una relación simple de primer nivel (base de datos relacional), sino también sobre la propia estructura de la red (operaciones s obre el grafo). Para ello, una base de datos basada en grafos debe permitir modelar la realidad en función de los siguientes elementos: nodos, relaciones y propiedades. • Nodos, que representan entidades del mundo real (e.g. pe rsonas, pedidos, productos, ciudades, computadores, direcciones físicas, etcéte ra), y que pueden contener propiedades , generalmente representadas por parejas clave/valo r (e.g. una persona tiene nombre, teléfono y DNI; una computadora tiene una d irección IP y un sistema operativo). • Relaciones , que conectan a los nodos entre sí y dotan de estr uctura a la red. Una relación siempre tendrá un nodo de origen y un nodo destino (e.g. una persona es amiga de otra persona; una carretera lleva de una dirección a otr a), y puede ser dirigido (e.g. que yo te considere mi amigo no implica lo contrario; una cal le de un sentido lleva de una dirección a otra, pero no al revés) o no dirigido/bidireccional (e.g. si eres hermano de alguien ese alguien es también tu hermano; dos ordenadores cone ctados al mismo hub). Las relaciones también pueden tener propiedades que las especifiquen. Por ejemplo, el peso de una relación de amistad (muy amigo, amigo, conoc ido), o el peso de una línea de transmisión. Una representación basada en grafos implica que las relaciones forman caminos entre las entidades, y la consulta al grafo implica consultar dichos caminos. Quién es amigo de quién, quién ha comprado qué, qué ha sido comprado por quién, cu ántos saltos hay de un nodo a otro, son Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 40 TEMARIO OPOSICIONES COIICV | TEMA 36 algunos de los ejemplos de consulta que se nos ocur ren al visualizar un grafo. Por lo tanto, la consulta a una base de datos de este tipo se convie rte en la búsqueda de caminos entre nodos. Para ello, se han propuesto lenguajes de consulta c omo Cypher, que se basa en consultar la base de datos mediante la búsqueda de concordancia entre patrones (e.g. encuentra algo como esto). Esto es lo que se conoce la especificación por ejemplo . Se sugiere la realización de los tutoriales en línea de Neo4J y la bibliografía propuesta, para profundizar en bases de datos basadas en grafos y su consulta mediante Cypher. Ejemplos de bases de datos basadas en grafos están FlockDB, OrientDB, AllegroGraph y Neo4J, entre otras. Destaca sin embargo la última: • Neo4J es una base de datos de grafos desarrollada en Jav a por Neo Technology. Dispone de una versión comercial y de una versión bajo lice ncia AGPL V3. Es un motor de persistencia embebido, basado en disco, y es comple tamente transaccional. Los datos se almacenan en forma de grafos de manera nativa. 5.1.5. Resumen de tecnologías Tabla V: Ejemplo de predicciones. Fuente: Elaboraci ón propia DOCUMENTOS CLAVE/VALOR COLUMNAS GRAFOS MongoDB CouchDB Riak Riak Voldemort Redis Memcached Membase DynamoDB Google Bigtable HBase Cassandra Sybase IQ Hypertable FlockDB OrientDB AllegroGraph Neo4J 5.2. Infraestructura de procesamiento En la introducción a big data se mostraron las diferentes Vs que definen el conc epto. Desde la perspectiva del procesamiento tenemos dos posibles aproximaciones, dependiendo de la V dominante, y una aproximación híbrida. Figura 5: Procesamiento batch vs. streaming vs. híb rido. Fuente: Elaboración propia • Procesamiento batch : Su principal orientación es hacia el procesamient o de grandes volúmenes de datos estáticos de manera escalable. S in embargo, no es importante que se produzca una elevada latencia en el procesamiento. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019