PDF de programación - Gestión y Almacenamiento de Datos Masivos - Tema 2 - Arquitectura y Tecnologías en BD

Big Data Architectures and Technologies

Gestión y Almacenamiento

de Datos Masivos
Tema 2- Arquitectura y Tecnologías en BD

@IsaacLera!

[email protected]!

Moraleja

Necesidad —>Nuevas Tecnologías!

Capacidad de diseñar

Isaac Lera - Máster Universitario en Ingeniería Informática

2

BigData comes from BigCompanies?

Sí, y son las que han invertido capital en innovación y desarrollo!

Aparición de conceptos

Ecosistemas de:

‘Arquitectura para gestionar datos’
Requiere:
• Almacenamiento de datos
• Tolerancia a fallos
• Computación paralela
• Coherencia

Modelo de
Programación

Coherencia

Datos

Coherencia

Gestor de datos

Coherencia:!
CAP theorem

Sistema de almacenamiento:!
Distribuido

Físico

HD, SSD, RAM, etc…

Isaac Lera - Máster Universitario en Ingeniería Informática

5

Data in anywhere

¿Modelos de
representación?
SQL & NoSQL

!

SQL vs NoSQL

SQL - Datos estructurados

Edgard Codd, 1970

❖ RDMS: Oracle, MySQL,…!
❖ Características:!

❖ ACID transactions.


Atomicity you can guarantee that all of a transaction
happens, & state 

Consistency you guarantee that your data will be
consistent; none of the constraints you have on related data
will ever be violated.

Isolation, one transaction cannot read data from another
transaction that is not yet completed.

Durability once a transaction is complete, it is
guaranteed that all of the changes have been recorded to a
durable medium!

❖ Join - Duplicación de información (algebra

relacional)

Isaac Lera - Máster Universitario en Ingeniería Informática

7

NoSQL - Datos no Estructurados

NoSQL == Not Only SQL!
❖ Cualquier tipo de información: documentos, grafos, csv, json, xml, etc.!
❖ Características:!

❖ Escalar las operaciones horizontalmente sobre multiples fuentes!
❖ Capacidad de replicar y particionar los datos!
❖ Un API - no un lenguaje de Queries!
❖ Soporte débil de transacciones ACID !
❖ Uso eficiente de índices distribuidos!
❖ Habilidad de incrementar dinámicamente el número de atributos

Isaac Lera - Máster Universitario en Ingeniería Informática

8

NoSQL DDBB

Isaac Lera - Máster Universitario en Ingeniería Informática

9

SQL & NoSQL

❖ SQL!

❖ Productividad Alta!
❖ Baja tolerancia a fallos!
❖ Latencia: Real-time!
❖ Reads/Inserts!
❖ Modelo estable!

❖ NoSQL!

❖ Productividad Baja!
❖ Alta tolerancia a fallos!
❖ Latencia: Baja!
❖ Better Reads!
❖ Modelo inestable

No hay debate en el manejo de datos másivos

Reflexión ¿Quién fue primero?

❖ DBMS: 1960 & RDMS: 1970!!
❖ Auge del volumen y fuente de datos!
❖ Incapacidad de transformarlos a EERR!
❖ No había necesidad…

Isaac Lera - Máster Universitario en Ingeniería Informática

11

Big Data y NoSQL

❖ BigData project requieres: High data velocity, Data

variety, Data volume, Data complexity!

❖ NoSQL en Sistemas Distribuidos: disponibilidad,

escalabilidad!

❖ Real location independence: memory or permanent

storage? Geographical localisation!!

❖ No Joins!! entonces No ACID-Consistencia!!
❖ Proyectos a largo plazo -> Datos flexibles

Isaac Lera - Máster Universitario en Ingeniería Informática

12

DB Concepts & Technologies I

Isaac Lera - Máster Universitario en Ingeniería Informática

13

+ Timeline

Rick Cattell

Isaac Lera - Máster Universitario en Ingeniería Informática

14

Ejercicio

❖ Riak!
❖ Neo4j!
❖ Picolo!
❖ Drizzle!
❖ JustOne!
❖ Terracota

Isaac Lera - Máster Universitario en Ingeniería Informática

15

‘Arquitectura para gestionar datos’
Requiere:
• Almacenamiento de datos
• Tolerancia a fallos
• Computación paralela
• Coherencia

Modelo de
Programación

Coherencia

Datos

Coherencia

Gestor de datos

Coherencia:!
CAP theorem

Sistema de almacenamiento:!
Distribuido

Físico

HD, SSD, RAM, etc…

Isaac Lera - Máster Universitario en Ingeniería Informática

16

Consistencia: CAP Theorem

❖ Consistency:!

❖ Todas las aplicaciones ven los

mismos datos; al menos una copia
actualizada!

I = Isaac

❖ Availability!

❖ Capacidad de interactuar en caso de

fallos; cada petición debe de ser
atendida!

❖ Partition Tolerance!

❖ Capacidad de continuar con un

trabajo aunque se haya perdido la
comunicación

I?

Isaac

Isaac Lera - Máster Universitario en Ingeniería Informática

17

CAP & NoSQL

Bigtable!
HBase!

Hypertable!
Megastor!
MongoDB!
Terrastore!
Berkely DB

C

P

RDBMS:!
MySQL,…

Dynamo!
Cassandra!
CouchDB!
Cassandra!
SimpleDB!

Riak!
KAI

A

Reflexión

¿Cómo analizar el cumplimiento del CAP?

Isaac Lera - Máster Universitario en Ingeniería Informática

19

‘Arquitectura para gestionar datos’
Requiere:
• Almacenamiento de datos
• Tolerancia a fallos
• Computación paralela
• Coherencia

Modelo de
Programación

Coherencia

Datos

Coherencia

Gestor de datos

Coherencia:!
CAP theorem

Sistema de almacenamiento:!
Distribuido

Físico

HD, SSD, RAM, etc…

Isaac Lera - Máster Universitario en Ingeniería Informática

20

Actividad

Crear un sistema distribuido de datos
Es broma… pero tenemos que ser capaces

Isaac Lera - Máster Universitario en Ingeniería Informática

21

“De la necesidad a la creación”

El ecosistema de
Google

Inicios - Tendencia

BigData issues

Paralelización

Distribución HW/SW

Integración de resultados

Latencia

Estructuración de datos

2003

2006

2007

¿Por qué un Google File System?
❖ Google requiere de un sistema distribuido de ficheros!
❖ Redundancia de almacenamiento en grandes cantidades

de datos en computadoras baratas y no confiables.!

❖ Carga de trabajo única y prioridades de negocio

enfocada a Google Apps/Maps

Isaac Lera - Máster Universitario en Ingeniería Informática

24

Google File System

Consideraciones del sistema!
❖ Un SD basado en componentes commodity!

❖ Constantemente monitorizados: detección, tolerancia y capacidad de recuperación en caso de fallos!

❖ Almacena un número “modesto” de ficheros grandes (100MB). Ficheros MultiGB son los comunes !
❖ Tres tipos principales de carga de trabajo: !

❖ large streaming reads,!
❖ small random reads,!
❖ and large, sequential writes. !
“Our files are often used as producer- consumer queues or for many-way merging. Hundreds of producers,

running one per machine, will concurrently append to a file. Atomicity with minimal synchronization

overhead is essential.”!

❖ Es más importante un ancho de banda alto y sostenido que una latencia baja. !

❖ “

Isaac Lera - Máster Universitario en Ingeniería Informática

25

GFS Cluster

@{64bits}File = {Chunks fixed-size} x 3

1

2

3n

4

No Caches: large file sizes

“Clients never read and write file data through the master. Instead, a client asks the master which
chunkservers it should contact. It caches this information for a limited time and interacts with the
chunkservers directly for many subsequent operations.”!

Isaac Lera - Máster Universitario en Ingeniería Informática

26

GFS - Chunk Size

❖ Key design: 64MB (paper 2003) > @64bits!
❖ Chunk replica -> plain linux file!
❖ Lazy space allocation: Se reserva el espacio en la creación pero

no se escribe hasta el flush de datos de la memoria al disco.!

❖ A mayor tamaño del trozo:!

❖ menor es la interacción con el master. !
❖ menor es el tráfico TPC con el chunk server!
❖ menor el tamaño de los metadatos en el master

Isaac Lera - Máster Universitario en Ingeniería Informática

27

GFS - Metadata

Todo la información se mantiene en memoria!
Metadata:!
❖ El fichero!
❖ Chunk namespaces: /home/hola !
❖ El mapeado del “fichero to chunks”!
❖ La localización de cada “chunks”

+Persistencia en Log!
+guardado en las múltiples 

replicas del Masters

Sync. durante el arranque!
Sync. a periodos

Isaac Lera - Máster Universitario en Ingeniería Informática

28

Funciones del GFS Master

❖ Se encarga del almacenamiento !
❖ Control del direccionamiento de los chunks!
❖ Control periódico con los chunkservers.!

❖ Instrucciones, Estado!

❖ Creación, replicación y balanceo de los chunks!

❖ Balance por: espacio, velocidad de acceso y carga.!
❖ Replicación y re-replicación: MTTF!

❖ La re-replicación se realiza lejanamente de la original!

❖ Garbage Collection!

❖ Para eliminar un fichero, elimina el nombre !

❖ Eliminación de replicas desactualizadas

Isaac Lera - Máster Universitario en Ingeniería Informática

29

GFS - Read Operation

Application

1) Nombre del fichero, Rango de bytes

6) data

GFS Client

5) data

2) Nombre del fichero, Chunk index

Master

3) Chunk-handle, localización de replicas

4) Chunk-handle, Rango bytes

Chunk Server

Chunk Server

Chunk Server

Isaac Lera - Máster Universitario en Ingeniería Informática

30

GFS - Write Operation I

4) Chunk-handle, Rango bytes

Application

6) data

1) Nombre del fichero, data

2) Nombre del fichero, Chunk index

GFS Client

Master

3) Chunk-handle, localización de replicas: primaria y secundaria

4) data

4) data

4) data

Buffer

Chunk Server

Buffer

Chunk Server

Buffer

Chunk Server

Secundario

Primario

Secundario

Isaac Lera - Máster Universitario en Ingeniería Informática

31

GFS - Write Operation II

4) Chunk-handle, Rango bytes

Application

6) data

GFS Client

5) flush

Master

6) Write

Buffer

Chunk Server

Buffer

Chunk Server

Buffer

Chunk Server

Secundario

Primario

Secundario

7) Write on secondaries
Isaac Lera - Máster Universitario en Ingeniería Informática

32

GFS - ‘Lease’ Write Operation III

…!
4. Once all the replicas have ACK data,
the client sends a write request to the
primary. The request identifies the data
pushed earlier to all of the replicas. !
5. Forecast of Writes !
6. Secondaries responden al primario
indicando que han realizado la operación!
7. El primario responde al cliente. En
caso de error se repite el proceso!
!

Isaac Lera - Máster Universitario en Ingeniería Informática

33

El master no es el cuello de botella

Modelo de consistencia

❖ Todos han de ver los mismos datos,

independientemente de la replica a la que se dirijan!
❖ En modo lectura se bloquea el directorio!
❖ En modo escritura se bloquea el fichero!

❖ Se identifica la mutación (cambio) sufrido por l