Bi y Nosql

Sistemas de Big Data
El nuevo paradigma de los datos masivos
Jordi Casas Roma

Carles Garrigues Olivella
Índice
1. Contextualización
2. Definición de Big Data
3. El Big Data en escenarios de Business Intelligence

Índice

Antecedentes (I)
¿Qué inició la revolución de los datos masivos?
§ Principios s. XXI…
§ El proyecto Sloan Digital Sky Survey
§ El proyecto del genoma humano
§ Después…
§ Internet, redes sociales, etc
§ IoT (Internet Of Things)

Antecedentes (II)
¿Qué inició la revolución de los datos masivos?
§ Problemas en las empresas de Internet
1. Gran cantidad de datos acumulados hacía inviable su
procesamiento en un único ordenador
2. Heterogeneidad de datos. Necesidad de insertar, consultar

y procesar datos en diferentes estructuras
3. Necesidad de procesar rápidamente los datos
• Ejemplo: queries del buscador web

El paradigma del Big Data
Causalidad Correlación
• Hipótesis • Toda la población
• Muestra aleatoria
• ¿Verificación? • Correlación entre variables
“¿Por qué?” “¿Qué?”

Índice

Definición de Big Data (I)
En el 2001, el analista Doug Laney de META Group (ahora
Gartner) utilizaba y definía el término Big Data como:
“el conjunto de técnicas y tecnologías para el tratamiento

de datos, en entornos de gran volumen, variedad de
orígenes y en los que la velocidad de respuesta es crítica”.
Definición de Big Data (II)
Podemos definir el término Big Data como:
• Conjunto de técnicas y tecnologías para
• el tratamiento y almacenamiento de datos, en
entornos de
• gran volumen,
• variedad de orígenes
• y en los que la velocidad de respuesta es crítica
3 V’s del Big Data
Volumen
§ Crecimiento exponencial de datos
§ Gigabytes à Terabytes de información diaria

Velocidad
§ Tiempo de respuesta crítico
§ P.ej. sistemas de tránsito
§ Procesado en tiempo (casi) real
§ Consideramos dos tipos de velocidad:
§ Velocidad de carga (procesos ETL)

§ Velocidad de procesamiento
Variedad
§ Diferentes formatos y estructuras de los datos
§ Orígenes de datos estructurados

§ Bases de datos, hojas de cálculo o ficheros CSV
§ Orígenes de datos semiestructurados

§ Documentos XML o páginas web
§ Orígenes de datos no estructurados

§ Documentos de texto, audio, imágenes o vídeo
Veracidad
§ IBM introdujo una cuarta V
§ La gran cantidad de datos y la diversidad de orígenes
provoca que la veracidad debe ser considerada
§ 2 tipos:
§ Exactitud del dato
§ Exactitud del cálculo
¡No hay unanimidad sobre esta 4ª V!

Índice

Escenarios de Big Data
¿Cuándo aplicar una solución BI basada en Big Data?
Si existe un gran volumen de datos, alta velocidad de
generación de datos o necesidad de tratar todo tipo de
datos. No es necesario que se cumplan las 3 condiciones.
¿Puede Big Data aplicarse en cualquier proyecto BI?

Big data puede utilizarse en cualquier escenario para
analizar información obtenido de diferentes sistemas de
información. Hay que tener en cuenta el incremento de
complejidad y coste respecto a una solución BI tradicional.
BI tradicional + Big Data
Una solución Big Data debe utilizarse como complemento
a un sistema BI tradicional.
• Big Data: obtención y análisis de datos basada en 3V’s.
• BI tradicional: obtención y análisis de datos no 3V’s.
Fuente: “Big Data”. Àlex Caminals Sánchez de la Campa -‐ FUOC
Diferencias: BI tradicional y Big Data
Naturaleza de los datos
• Volumen, Variedad y Velocidad.
Granularidad
• BI tradicional datos almacenados en el DW en su
mínima granularidad.
• Big Data datos almacenados en el DW son derivados o
filtrados.
Tecnología
• Hadoop + base de datos NoSQL
• SGBDR + herramienta BI
El nuevo paradigma de los datos masivos
Jordi Casas Roma

Técnicas y herramientas para el análisis
de datos masivos
Jordi Casas Roma
Índice
1. El modelo MapReduce
2. Apache Hadoop
3. Apache Spark
4. Bases de datos NoSQL

Índice
2. Apache Hadoop
3. Apache Spark

Herramientas de Big Data
Hemos definido Big Data como:
“el conjunto de técnicas y tecnologías para el tratamiento y
almacenamiento de datos, en entornos de gran volumen, variedad de
orígenes y en los que la velocidad de respuesta es crítica”.
Técnicas/herramientas para:
• Almacenamiento datos masivos (distribuido)
• Procesado de datos masivos (distribuido)
El modelo MapReduce (I)
Pasos del modelo
§ Map: La función Map convierte el fichero de
información de gran tamaño en una secuencia de pares
<clave, valor>
§ Shuffle: Los resultados son recolectados y ordenados

según el valor de la clave
§ Reduce: combinando todos los valores asociados a la

clave de forma especifica a cada problema
El modelo MapReduce (II)
Fuente: http://www.cs.uml.edu/~jlu1/doc/source/report/MapReduce.html
Ejemplo MapReduce
Mapping Shuffling Reducing
word1 <word1,1> <word1,1>

word2 <word2,1> <word1,1> <word1,3>
word3 <word3,1> <word1,1>
word1
word2
word3 word4 <word4,1>
<word2,1> word1, 3
word4 word5 <word5,1> <word2,2>
<word2,1> word2, 2
word5 word1 <word1,1>
…
word1
word5, 1
…
word3
word1
… … … …
word2
word3 <word3,1>
word1 <word1,1> <word5,1> <word5,1>
word2 <word2,1>
Índice
2. Apache Hadoop
3. Apache Spark

Apache Hadoop
Hadoop distributed file system (HDFS)
• Los datos son distribuidos por diferentes nodos.
• Los datos se pueden tratar en paralelo.
• Existe tolerancia a fallos puesto que existen múltiples
copias de los datos en diferentes nodos.
Hadoop MapReduce engine

Por encima del sistema de ficheros, Hadoop incorpora un
motor de ejecución de trabajos MapReduce. MapReduce
permite el procesado a gran escala de conjuntos de datos.
Apache Hadoop: ecosistema
Alternativas al modelo MapReduce
§ Apache Storm es un sistema de computación
distribuida en tiempo real
§ Apache Giraph es un sistema de procesamiento

distribuido de grafos
Lenguajes programación
§ Apache Pig es un lenguaje de programación de alto
nivel diseñado y desarrollado para eliminar la
complejidad de la codificación de las aplicaciones
MapReduce
§ Apache Hive es una infraestructura de data

warehouse en entorno distribuido.
Extracción de conocimiento
§ Apache Mahout es una plataforma de aprendizaje
automático y minería de datos construida sobre Hadoop
§ RHadoop es un conjunto de cuatro paquetes en

lenguaje R que permiten analizar y gestionar datos
usando Hadoop.
Índice
2. Apache Hadoop
3. Apache Spark

Apache Spark
Características básicas
• Enfocado al procesamiento en streaming
• MapReduce es ineficiente para procesos de algoritmos
iterativos o consultas interactivas.
• Almacenamiento distribuido basado en:
• Hadoop Distributed File System (HDFS)
• Cassandra
• etc
Apache Spark
Módulos del sistema
• Spark Core Engine es el motor de ejecución de Spark
• Spark SQL es el módulo encargado de dar soporte a
consultas interactivas
• Spark Streaming permite a las aplicaciones procesar y
analizarlos datos en tiempo (casi) real
• MLlib es la librería de aprendizaje automático
• GraphX es un motor para el análisis de grafos
• SparkR permite integrar el lenguaje estadístico R
Índice
2. Apache Hadoop
3. Apache Spark

Bases de datos NoSQL
¿Qué diferencias hay entre NoSQL y los SGBDR?
• Se almacenan datos de cualquier tipo indexados por una
única clave.
• Los datos no son analizados antes de ser almacenados
• No existen procesos para asegurar la integridad
Resultado:
Almacenaje y procesado de datos en tiempo muy reducido
Bases de Datos NoSQL
Los datos pueden encontrarse en una BD NoSQL
Los datos procesados mediante trabajos MapReduce
pueden almacenarse en bases de datos NoSQL.
MapReduce
NoSQL DB
(Job Scheduling/Execution)
(HBase)
HDFS
(Hadoop Distributed File System)
Técnicas y herramientas para el análisis
de datos masivos
Jordi Casas Roma
Bases de datos NoSQL:
introducción
M. Elena Rodríguez González

Jordi Conesa i Caralt
Índice
¿Qué es NoSQL?
Características de las BD NoSQL
Inconvenientes de las BD NoSQL
¿Qué es NoSQL?
Bajo la denominación NoSQL se engloba un
conjunto de BD para gestionar datos en entornos
de aplicación donde las BD relacionales no son la
mejor solución:
– Entornos de aplicación que requieren
esquemas de datos más flexibles.
– Sistemas altamente distribuidos que
necesitan gestionar grandes volúmenes de
datos con alta disponibilidad.
¿Qué es NoSQL?
Las primeras implementaciones de BD NoSQL
son BigTable (Google, 2003) y Marklogic (2005).
Otras BD NoSQL emblemáticas son DynamoDB
(Amazon, 2007) o Cassandra (Facebook, 2008).
No hay un modelo de datos único
Proporcionan un esquema de datos flexible.
No ofrecen SQL como lenguaje estándar.
En general son distribuidas.
Acostumbran a no garantizar las propiedades del
modelo ACID.
Frecuentemente son de código abierto.
Inconvenientes de las BD NoSQL

Falta de estándares
Gestionar el esquema de la BD puede ser complejo
Dificultades en la administración de la BD
Existen funcionalidades que no están
implementadas
Falta de madurez y soporte por parte de los
fabricantes
Falta de especialistas y curva de aprendizaje
Es complicado saber quién es el mejor
Referencias
P. Atzeni, C.S. Jensen, G. Orsin & S.Ram (2013). “The relational model is dead, SQL is
dead, and I don’t feel so good myself”, SIGMOD Record 42(2), pp. 64-68.
(http://www.sigmod.org/publications/sigmod-
record/1306/pdfs/11.reports.atzeni.pdf)
R. Catell (2010). “Scalable SQL and NoSQL Data Stores”. SIGMOD Record 39(4), pp 12-
27. (http://dl.acm.org/citation.cfm?id=1978919).
I. Katsov (2012). Highly Scalable Blog. Articles on Big Data, NoSQL, and Highly
Scalable Software Engineering. (https://highlyscalable.wordpress.com/)
E. Redmond, J Wilson (2012). Seven Databases in Seven Weeks: A Guide to Modern

Databases and the NoSQL Movement, The Pragmatic Bookshelf.
P.J. Sadalage & M. Fowler. (2013). NoSQL Distilled. A brief Guide to the Emerging
World of Polyglot Persistence, Pearson Education.
W. Vogel (2009). “Eventually Consistent”, Communications of the ACM 52(1), pp 40-

44. (http://dl.acm.org/citation.cfm?id=1435432)
Bases de datos NoSQL:
características


No hay un modelo de datos único
Proporcionan un esquema de datos flexible.
No ofrecen SQL como lenguaje estándar.
En general son distribuidas.
Acostumbran a no garantizar las propiedades del
modelo ACID.
Frecuentemente son de código abierto.
Modelos de datos
Expresividad semántica
Orientado a Orientado a
Clave-valor En grafo
columnas documentos
Útil para datos no estructurados Útil para dominios donde se

y semiestructurados. establecen múltiples y complejas
interrelaciones entre los datos.
Se basan en el concepto de
agregado. Utiliza estructuras de grafo para
representar y almacenar los datos.
Cada agregado se identifica por
una clave.
Ejemplos de BD NoSQL
columnas documentos
BerkeleyDB Cassandra MongoDB Neo4J

Riak HBase Couchbase Infinite Graph
Redis Amazon MarkLogic Sparksee
SimpleDB
Ejemplos de BD NoSQL
columnas documentos
Multimodelo
ArangoDB
OrientDB
Listado BD NoSQL http://nosql-database.org/
Esquema de datos flexible

(schemaless)
La BD no tiene un esquema de datos predefinido.
El esquema puede variar para instancias de datos
que pertenecen a una misma entidad.
En ocasiones el gestor de la BD no es consciente
del esquema de la BD.
Permite reducir los problemas de concordancia
entre las estructuras de datos usadas por las
aplicaciones y la BD.
Frecuentemente se aplican técnicas de
desnormalización de los datos.
No ofrecen SQL como lenguaje
Algunas BD NoSQL ofrecen su propio lenguaje de manipulación
y consulta de los datos.
Acceso vía API REST: ejecución de peticiones HTTP del tipo
POST, GET, PUT, DELETE
Cada BD NoSQL proporciona drivers de acceso a la BD para
multitud de lenguajes de programación (C, C++, C#, Java, PHP,
Python, Perl, Erlang…).
Proporcionan operaciones que permiten la integración con
sistemas de computación distribuida (p.e. el framework
MapReduce).
Distribución: escalabilidad
Escalabilidad horizontal (modo

de trabajo preferido BD NoSQL)
Escalabilidad vertical (modo

de trabajo preferido BD
relacional)
Images by Vecteezy, license CC BY SA (from https://www.iconfinder.com/icons/532734/)
Distribución de datos
Las BD NoSQL (sobre todo las basadas en modelos de
agregación) promueven principalmente la fragmentación
horizontal (sharding) y la replicación de los datos.
La fragmentación (y posterior distribución de los datos) se
puede realizar aplicando técnicas de hash o en función del valor
que toman ciertos atributos.
Acercar los datos allá donde se necesitan

Incrementar la disponibilidad de los datos
Mejorar la eficiencia de las operaciones de consulta
Incrementar el nivel de paralelismo
Teorema CAP
Consistencia (Consistency): los usuarios del sistema tienen que
poder recuperar siempre los mismos valores para unos mismos
datos en un mismo instante de tiempo.
Disponibilidad (Availability): las peticiones de servicio enviadas
por los usuarios a un nodo que está disponible deben obtener su
debida respuesta.
Tolerancia a particiones (tolerance to network Partitions): el
sistema debe proporcionar servicio a los usuarios a pesar de que se
puedan producir situaciones de avería que causen que el sistema
quede particionado en diferentes componentes.
El teorema CAP enuncia que es imposible garantizar

simultáneamente las tres características.
Teorema CAP y BD NoSQL
AP: el sistema siempre está disponible,
aunque temporalmente puede mostrar
datos inconsistentes en presencia de
particiones.
Ejemplos: Riak, DynamoDB, Cassandra
CP: el sistema siempre contiene una visión consistente de los

datos, aunque no esté totalmente disponible en presencia de
particiones.
Ejemplos: MongoDB, HBase, Redis
ACID versus BASE

Atomicidad Disponibilidad limitada
Consistencia (Basic Availability)
Estado flexible (Soft-state)
aIslamiento Consistencia final en el
Definitividad tiempo (Eventual consistency)
Soportar un modelo de transacciones ACID en BD que almacenan

grandes volúmenes de datos, que están distribuidas y con
replicación de datos es complejo y puede causar problemas de
rendimiento.
Referencias
P. Atzeni, C.S. Jensen, G. Orsin & S.Ram (2013). “The relational model is dead, SQL is
dead, and I don’t feel so good myself”, SIGMOD Record 42(2), pp. 64-68.
(http://www.sigmod.org/publications/sigmod-
record/1306/pdfs/11.reports.atzeni.pdf)
R. Catell (2010). “Scalable SQL and NoSQL Data Stores”. SIGMOD Record 39(4), pp 12-
27. (http://dl.acm.org/citation.cfm?id=1978919).
I. Katsov (2012). Highly Scalable Blog. Articles on Big Data, NoSQL, and Highly
Scalable Software Engineering. (https://highlyscalable.wordpress.com/)
E. Redmond, J Wilson (2012). Seven Databases in Seven Weeks: A Guide to Modern

Databases and the NoSQL Movement, The Pragmatic Bookshelf.
P.J. Sadalage & M. Fowler. (2013). NoSQL Distilled. A brief Guide to the Emerging
World of Polyglot Persistence, Pearson Education.
W. Vogel (2009). “Eventually Consistent”, Communications of the ACM 52(1), pp 40-

44. (http://dl.acm.org/citation.cfm?id=1435432)
Modelos de datos
Modelos de datos NoSQL
¿Qué es un modelo de datos y modelos

de datos NoSQL?
Ejemplo
Modelos de datos de Agregación
Modelos de datos Orientados a Grafo
¿Qué son los modelos de datos y qué

modelos de datos se usan en NoSQL?
Ejemplo
Modelo de datos
 Un modelo conceptual de datos es una descripción de la parte
del mundo real que nos interesa conceptualizar.
Un modelo de datos: conjunto de componentes que proporciona

el sistema gestor de la base de datos para estructurar y manipular
los datos, e incluye los siguientes elementos:
 Estructuras de datos para construir la base de datos
 Operaciones para manipular y consultar los datos
 Mecanismos para definir restricciones de integridad
columnas documentos
Los modelos de agregación se basan en la noción de agregado.

 Un agregado es una colección de objetos relacionados que
deseamos tratar como una unidad independiente a efectos de:
 Acceso y manipulación
 Consistencia y control de concurrencia
 Distribución de datos
 ¿Qué son los modelos de datos y qué modelos

de datos se usan en NoSQL?
Ejemplo
El carro de la compra
Modelo conceptual en UML
Imaginemos que queremos

recuperar toda la
información relativa a un
pedido (Order) a efectos de
gestión de envío.
La carro de la compra
Modelo relacional
recuperar toda la
gestión de envío.
Será necesario hacer la

combinación (join) entre
pedido (Order), línea de
pedido (OrderLine),
producto (Product), cliente
(Customer) y dirección
(Address).
La carro de la compra
Modelo relacional
recuperar toda la
gestión de envío.
Los modelos de datos de agregación

Será necesario hacer la
usados en NoSQL facilitan combinación
la resolución (join) entre
pedido (Order), línea de
de consultas como la indicada. Veamos
pedido (OrderLine),
cómo… producto (Product) y
dirección (Address).
 ¿Qué son los modelos de datos y qué

Ejemplo motivador
Referencias
Joe Celko's (2013). Complete Guide to NoSQL. Elsevier.

(http://www.sciencedirect.com/science/book/9780124071926)
E. Redmond, J Wilson (2012). Seven Databases in Seven Weeks: A Guide to

Modern Databases and the NoSQL Movement, The Pragmatic Bookshelf.
(http://pragprog.com/book/rwdata/seven-databases-in-seven-weeks)
Representación de datos en modelos
de agregación

Ejemplo
Modelos de agregación
Consideraciones de diseño de agregados
Modelo clave-valor
Modelo orientado a documentos
Modelo orientado a columnas

Ejemplo
Consideraciones de diseño
 El diseño de agregados es de vital importancia y está
guiado por las funcionalidades de la aplicación.
Son una buena solución cuando:
 Las funcionalidades que tiene que proveer la aplicación
están claramente fijadas y no se esperan variaciones
significativas.
 Pocos solapamientos en cuanto a necesidades de datos.
 No existen interrelaciones complejas
 Los datos están sujetos a pocos cambios, especialmente en
aquellos datos que aparecen repetidos en diferentes
agregados.
El carro de la compra
Modelo de agregación genérico
Order
orderId= order1 Imaginemos que queremos
No se puede mostrar la imagen. Puede que su equipo no tenga suficiente memoria para abrir la imagen o que ésta esté dañada. Reinicie el equipo y , a continuación, abra el archiv o de nuev o. Si sigue apareciendo la x roja, puede que tenga que borrar la imagen e insertarla de nuev o.
date= date1
ref customerId= customer1
recuperar toda la
ref paymentId= paymentCustomer1 información relativa a un
OrderLines pedido (Order) a efectos de
gestión de envío.
OrderLine Product
OrderLine Product
El agregado creado causa

ShippingAddress que accedamos a la
información necesaria para
Address la gestión del envío del

pedido a la vez.

Modelo clave-valor: Introducción
 Es el modelo más simple dentro de los modelos de agregación.
 El agregado consiste en un par (clave, valor), donde:
 El valor representa el agregado, y
La clave es un identificador usado para identificar univocamente el
agregado.
 La clave se puede extraer del dominio de aplicación
Nombres de usuario, direcciones de correo electrónico, números de la
seguridad social, DNI, latitud y longitud, etc.
 La base de datos ignora la estructura asociada al contenido del
agregado (valor)
 A pesar de ello, algunas bases de datos clave-valor (p.e. Riak)
permiten estructurar un mínimo el contenido del agregado.
El carro de la compra según un
modelo clave-valor
OrderID Clave
orderId= order1
date= date1
ref paymentId= paymentCustomer1
OrderLines
OrderLine Product
Valor
OrderLine Product
ShippingAddress
Address
Interpretación de un agregado en
bases de datos clave-valor
Aplicación
Modelo de datos en Riak
Modelo Relacional Riak
Base de datos Base de datos
Tabla, vista Bucket
Fila Objeto = <clave, valor,…>
Columna No tiene un equivalente
directo
≈ metadato
Clave primaria clave

Clave foránea Link
Combinación ≈ Link Walking
(join)
Representación de datos en Riak
Objeto
Customer
Customer1
Link
PaymentCustomer
PaymentInfo PaymentCust1

Modelo orientado a documentos:
Introducción
Se puede ver como una extensión del modelo clave-valor:
Los agregados tienen una estructura interna que
recibe el nombre de documento.
Los documentos se acceden mediante una clave única,
o mediante atributos de los mismos, permitiendo:
 La recuperación de una parte del documento
 La definición de índices
 Suelen almacenar documentos en formato JSON, pero
también en XML, entre otros formatos.
 Algunas bases de datos relacionales también permiten
almacenar y manipular documentos tales como
PostgreSQL, DB2, MS SQL Server u Oracle.
modelo orientado a documentos
Customer
customerId= customer1
customerName= name1
Addresses
Address
Order
orderId= order1 Address
date= date1
Address
ref paymentId= paymentCustomer1
OrderLines
OrderLine Product
Payment
paymentId= paymentCustomer1
payment1
paymentMethod= VISA
OrderLine Product
creditCardNumber=12345678
ref orderId= order1 billingAddress
ShippingAddress No se puede mostrar la imagen. Puede que su equipo no tenga suficiente memoria para abrir la imagen o que ésta esté dañada. Reinicie el equipo y , a continuación, abra el archiv o de nuev o. Si sigue apareciendo la x roja, puede que tenga que borrar la imagen e insertarla de nuev o.
Address
Address
Modelo de datos en MongoDB
Modelo Relacional MongoDB
Base de datos Base de datos
Tabla, vista Colección
Fila Documento
Columna Campo
Clave primaria _id

Clave foránea Referencia
Combinación Documento
(join) incrustado
Representación de datos en MongoDB
Clave
primaria
Referencias
Documento
Documentos
incrustados
Campo

Modelo orientado a columnas:
Introducción
El modelo de datos puede verse como una
matriz:
 Las filas representan agregaciones de datos y se
acceden mediante su clave.
 Las columnas representan atributos de la
agregación y se representan mediante :
<nombre, valor, timestamp>
 Las columnas pueden agruparse en familias de
columnas.
modelo orientado a columnas
orderId
modelo orientado a columnas
Obtener la información general de todos
los pedidos (los valores de la familia de
columnas para todas las filas)
124
...
263
Obtener la información del pedido

número 263 (todos los datos de una fila)
 ¿Qué son los modelos de datos y qué

Referencias
P.J. Sadalage & M. Fowler. (2013). NoSQL Distilled. A brief Guide to the
Emerging World of Polyglot Persistence, Pearson Education.
Little Riak Book http://littleriakbook.com/
K. Banker (2011). MongoDB in Action. Manning.
Representación de datos en modelos
orientados a grafo
¿Qué son los modelos de datos y qué modelos de
datos se usan en NoSQL?
Ejemplo
Introducción a los grafos
Modelo orientado a grafos
Representación del carro de la compra en un
modelo en grafo
Representación del carro de la compra en Neo4j
Ejemplo
modelo en grafo
Modelos en grafo y grafos
 El modelo en grafo utiliza estructuras de grafo
para representar y almacenar los datos.
 ¿Grafos?
Nodos
Aristas
Grafos: conceptos básicos
 Tipos de aristas
 Tipos de grafos
 Si se usan aristas dirigidas…

B es sucesor de A
A es antecesor de B
A B Grado de Salida(A)=1
Grado de Salida(B)=0
Grado de Entrada(B)=1
Grafos: etiquetas
tiene frontera con Portugal
loves
Paul
España José
tiene frontera con loves
hates
tiene loves Jen
frontera Andorra Hugo
con
loves
tiene frontera con loves
Bea Pol
Francia
Grafo no dirigido etiquetado Grafo dirigido etiquetado

Grafos: propiedades
 Pueden asignarse tanto a nodos como a aristas.
 Están formadas por un par <clave, valor>.
email: Jose_the_lonely@example.com
age: 33
loves
Paul
José
loves
hates email: Jen_the_cool@example.com
loves Jen
Hugo
loves
loves until: 21/12/2013
Bea Pol
Ejemplo
modelo en grafo
Modelos orientados a grafo
 Utilizan estructuras de grafo para representar y
almacenar los datos.
No hay un modelo estándar,
Supongamos un grafo de propiedades etiquetado.
 Las relaciones son explícitas entre entidades.
 Mejora el tiempo de respuesta al navegar entre
relaciones (no es necesario calcular las operaciones
de join).
 Schemaless: el esquema está implícito en la estructura
del grafo.
 Suelen utilizar lenguajes de consulta de alto nivel.
Elementos básicos
 Nodos: permiten representar conceptos generales u
objetos del mundo real.
Marqués
Moscatel de Portal Rioja
Crianza
 Aristas: permiten representar de forma explícita las

relaciones entre los nodos.
Use Grapes of Type
Xarelo
Marqués
Moscatel de Portal Rioja
Crianza
q.d.o
Use Grapes of Type
 Los nodos y las aristas se pueden etiquetar (bautizar).

Elementos básicos
 Se pueden añadir propiedades a los nodos y a las
aristas
Porcentaje: 40-60% Precio: 10 a 20
euros
Use Grapes of Type Tamaño: 75 cl.
Xarelo
Marqué…
s de
Moscatel Rioja
Portal
Crianza q.d.o
Use Grapes of Type
Porcentaje: 10-30%
 Restricciones del modelo:

− No permite definir aristas sin nodos origen ni destino.
− Los nodos sólo pueden eliminarse cuando quedan
huérfanos.
Ejemplo
modelo en grafo
modelo orientado a grafo
customerId: 100
name: ...
address
orderId: 100 customer Customer
date: 01/03/2014
Order payment info

Payment
customerId:
order line shippingAddress paymentCustomer1
address paymentMethod: VISA
...
OrderLine Shipping
productId: 27 Address
productName: “Le pere Goriot” street: “Champs Elysées 156”
numberOfUnits: 1 city: “Paris”
Price: 18.5 zipcode: “75008”
country: France
Ejemplo
modelo en grafo
Modelo de datos en Neo4J
Modelo Relacional Neo4j
Base de datos Grafo
Tabla, vista Etiqueta de Nodo
Fila ≈ Nodo
Columna Propiedad
Clave primaria Propiedad + restricción de

unicidad
Clave foránea relación
Combinación Graph traversing
(join)
Representación de datos en Neo4J
Etiquetas de Nodo
nodo
Relación
Restricción
de unicidad
Propiedades
Consultando datos usando Cypher
Obtener todos los pedidos donde se hayan comprado más de 10

boligrafos de colores (nombre=coloredPen):
MATCH (o:Order)-[:ORDERLINE]->(pl:ProductLine)-
[:PRODUCT_BOUGHT]->(p:Product)
WHERE p.name=“ColoredPen” AND pl.numberOfUnits>=10
RETURN o
Obtener todos los nombres de los clientes que hayan gastado más
de 50000€:
MATCH (c:Customer)<-[:CUSTOMER]-(:Order)-
[:ORDERLINE]->(pl:ProductLine)
WITH c.name AS cliente, sum(pl.price) AS total_compras
WHERE total_compras > 50000
RETURN cliente
¿Qué son los modelos de datos y qué

Ejemplo
Referencias
I. Robinson, J. Webber & E. Eifren (2013). Graph Databases. O’Reilly.

P.J. Sadalage & M. Fowler. (2013). NoSQL Distilled. A brief Guide to the
Emerging World of Polyglot Persistence, Pearson Education.
Documentación oficial: http://docs.Neo4j.org/

Bi y Nosql

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Bi y Nosql

Hochgeladen von

Copyright:

Verfügbare Formate

Sistemas de Big Data

El nuevo paradigma de los datos masivos

Jordi Casas Roma

2. Definición de Big Data

3. El Big Data en escenarios de Business Intelligence

2. Definición de Big Data

3. El Big Data en escenarios de Business Intelligence

§ El proyecto Sloan Digital Sky Survey

§ El proyecto del genoma humano

§ Internet, redes sociales, etc

§ IoT (Internet Of Things)

2. Heterogeneidad de datos. Necesidad de insertar, consultar

3. Necesidad de procesar rápidamente los datos

• Ejemplo: queries del buscador web

• ¿Verificación? • Correlación entre variables

“¿Por qué?” “¿Qué?”

2. Definición de Big Data

3. El Big Data en escenarios de Business Intelligence

“el conjunto de técnicas y tecnologías para el tratamiento

§ Gigabytes à Terabytes de información diaria

§ P.ej. sistemas de tránsito

§ Procesado en tiempo (casi) real

§ Consideramos dos tipos de velocidad:

§ Velocidad de carga (procesos ETL)

§ Orígenes de datos estructurados

§ Orígenes de datos semiestructurados

§ Orígenes de datos no estructurados

¡No hay unanimidad sobre esta 4ª V!

2. Definición de Big Data

3. El Big Data en escenarios de Business Intelligence

¿Puede Big Data aplicarse en cualquier proyecto BI?

Jordi Casas Roma

4. Bases de datos NoSQL

4. Bases de datos NoSQL

§ Shuffle: Los resultados son recolectados y ordenados

§ Reduce: combinando todos los valores asociados a la

word1 <word1,1> <word1,1>

4. Bases de datos NoSQL

Hadoop MapReduce engine

§ Apache Giraph es un sistema de procesamiento

§ Apache Hive es una infraestructura de data

§ RHadoop es un conjunto de cuatro paquetes en

4. Bases de datos NoSQL

4. Bases de datos NoSQL

M. Elena Rodríguez González

Inconvenientes de las BD NoSQL

E. Redmond, J Wilson (2012). Seven Databases in Seven Weeks: A Guide to Modern

W. Vogel (2009). “Eventually Consistent”, Communications of the ACM 52(1), pp 40-

M. Elena Rodríguez González

Características de las BD NoSQL

Útil para datos no estructurados Útil para dominios donde se

BerkeleyDB Cassandra MongoDB Neo4J

Listado BD NoSQL http://nosql-database.org/

Esquema de datos flexible

Escalabilidad horizontal (modo

Escalabilidad vertical (modo

Acercar los datos allá donde se necesitan

El teorema CAP enuncia que es imposible garantizar

CP: el sistema siempre contiene una visión consistente de los

ACID versus BASE

Soportar un modelo de transacciones ACID en BD que almacenan

E. Redmond, J Wilson (2012). Seven Databases in Seven Weeks: A Guide to Modern

W. Vogel (2009). “Eventually Consistent”, Communications of the ACM 52(1), pp 40-