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

<<>>
Imágen de pdf Gestión y Almacenamiento de Datos Masivos - Tema 2 - Arquitectura y Tecnologías en BD

Gestión y Almacenamiento de Datos Masivos - Tema 2 - Arquitectura y Tecnologías en BDgráfica de visualizaciones

Actualizado el 21 de Marzo del 2018 (Publicado el 14 de Diciembre del 2017)
227 visualizaciones desde el 14 de Diciembre del 2017. Una media de 7 por semana
6,4 MB
89 paginas
Big Data Architectures and Technologies

Gestión y Almacenamiento

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

@IsaacLera!

isaac.lera@uib.es!

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
  • Links de descarga
http://lwp-l.com/pdf7867

Comentarios de: Gestión y Almacenamiento de Datos Masivos - Tema 2 - Arquitectura y Tecnologías en BD (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios
Es necesario revisar y aceptar las políticas de privacidad

Revisar política de publicidad