PDF de programación - Big Data con Cassandra

Linux Málaga
@linux_malaga www.linux-malaga.org



Big Data

Bienvenido - Welcome - Witam

Juan Miguel Taboada Godoy
@centrologic_es
http://linkedin.com/user/centrologic

1/47

Juan José Soler Ruiz
@soleronline
http://es.linkedin.com/in/soleronline

Linux
Málaga

Big Data



Bio

Juan Miguel Taboada Godoy ( 1980 - … )

Juan José Soler Ruiz



1996 – Primer ordenador y primera LAN (cable coaxial)

1999 – Universidad de Málaga y Linux Málaga
2001 – Grupo de investigación GEB.uma.es (4 años)

Cluster computación +20 nodos (OpenMosix)

2002 – Presidente de Asociación Málaga Wireless
2003 – Beca en Neurociencia en SUNY
Teleruta (Ministerio de Fomento – 2 años)

2005 – Autónomo:
- Nace Centrologic
- Polonia (2 años)
- Likindoy (Axaragua + Junta Andalucía)

2008 – Responsable Sistemas en PontGrup
2011 – Adquisición Datos en Bética Fotovoltáicas
2012 – SAFECLON y SCRUM/KANBAN

2013 – Executive MBA

2014 – Aeronáutica: Django + AngularJS
2015 – Industria: Likindoy + Big Data

2001-2003 – CFGS Administración Sistemas Informáticos

2003 – Primer premio en el concurso “Javier Benjumea”
2003 – Montaje y configuración
de “Cluster Heterogéneo De Computadoras”
bajo SO Red Hat 7.2.

2005-2012 – STEA Telemática
2007-2009 – Primer CRM en PHP

2010-2011 – Administrador de BBDD / Programador
Web en Bética Fotovoltáicas

2010-2012 – Opositometro

2012-.... – Centrologic

2013 – Dailymarkets
2013-2014 – CRM en Python/Django

2014-... – Centrologic

2/47



Linux
Málaga

Big Data



¿Por qué?

3/47



Linux
Málaga

Big Data

Likindoy

The monitoring company



Software de adquisición masiva de datos:

- 1 dato (Fecha+Valor) cada minuto por señal
- 1000 señales por dispositivo
- 20 dispositivos por nodo
- 40 nodos por cliente
800.000 registros por minuto

(8.000.000 tomas por minuto)

- 48M por hora
- 1.152M por día
0,4 Billones por año y cliente

4/47



Linux
Málaga

Big Data

Grandes números
2012



5/47



Linux
Málaga

Big Data

Grandes números
2014



6/47



Linux
Málaga

Big Data

Año 2016



- La gestión de datos crece de momento EXPONENCIALMENTE

- SEAGATE anuncia que el año 2016 será el año del Zettabyte

- 1 ZB equivale al espacio que ocupa 2 billones de años de música

- 1 ZB = 1024 exabytes = casi 1.1 trillones de Gbytes

- 1 zB = 1 sixtillón de bytes

- Ahora estamos en la época del quintillón de bytes...

7/47



Linux
Málaga

Big Data

¿Cuanto es un quintillón?

- Una única gota de agua contiene:
1.7 quintillones de moléculas de agua.



- La distancia de la Via Láctea hasta Andrómeda es de:
2 millones de años luz
18,87 quintillones de kilómetros
11,73 quintillon miles

- La tierra completa contiene unos:
1.234 quintillones de litros de agua
326 quintillon gallons of water

- Si cortamos la tierra por la mitad, la sección tendría
un área aproximada de:
1.275 quintillones de centímetros cuadrados

- ¿Cuanto es un quintillón de céntimos o peniques de dólar?

8/47



Linux
Málaga

Big Data

¿Cuanto es un quintillón... de peniques?



9/47



Linux
Málaga

Big Data

¿Cuanto es un quintillón... de peniques?



1.000.067.088.384.000.000 peniques

1 quintillón, 67 trillones, 88 billones, 384 millones de peniques

Un cubo de 8,32 kilómetros de lado

10/47



Linux
Málaga

Big Data

Teorema de CAP



Eric Brewer (2000)

C: Consistency → Consistencia

A: Availability → Disponibilidad

P: Partition tolerance → Tolerancia al particionado

Sólo puedes llegar a 2 de las 3

Es imposible para un sistema de cómputo distribuido garantizar

simultáneamente la consistencia, la disponibilidad y ser tolerante

al particionado de los datos (separación y distribución).

11/47



Linux
Málaga

Big Data

Teorema de CAP

Lo que la mayoría
Lo que la mayoría
piensa que tiene
que tiene



Siempre se puede

leer y escribir

A

C

Todos los clientes

ven siempre lo mismo

P

Funcionará incluso
cuando haya errores

en el sistema

12/47



Linux
Málaga

Big Data

Teorema de CAP

Lo que la mayoría
Lo que la mayoría
de de verdad tiene
tiene



Siempre se puede

leer y escribir

A

C

Todos los clientes

ven siempre lo mismo

P

Funcionará incluso
cuando haya errores

en el sistema

13/47



Linux
Málaga

Big Data

Teorema de CAP



Lo cierto es que todos buscamos la disponibilidad (A)

Pero ... ¡¡¡ tenemos que elegir entre... !!!

Escalabilidad (P)

y

Consistencia (C)

14/47



Linux
Málaga

Big Data

Teorema de CAP



ACID
A: Atomicidad

C: Consistencia

I: Aislamiento (Isolation)

D: Durabilidad

En grandes sistema ocurre que:

Disponibilidad y Rendimiento

15/47



Linux
Málaga

Big Data

Teorema de CAP



BASE

BA: Básicamente disponible

S: Flexible (Soft state)

E: Consistencia eventual

Da menos importancia a la consistencia
en pro de la tolerancia al particionado

aparece la consistencia eventual

16/47



Linux
Málaga

Big Data

Teorema de CAP



¿Qué es la consistencia eventual?

Que ... eventualmente será consistente

Podemos introducir un dato y que

no esté disponible inmediatamente después

Convergencia natural a la consistencia

17/47



Linux
Málaga

Big Data

Teorema de CAP



Resolución de conflictos

Anti-entropía (control de versiones)

Reconciliación (elección de estado final)

[ generalmente: “last write wins” ]

Garantizar la seguridad de una operación

Strong eventual consistency (SEC)

18/47



Linux
Málaga

Big Data

Teorema de CAP



CA

MySQL Postgres
Oracle SQLServer

Todos los clientes

ven siempre lo mismo

C

Siempre se puede

leer y escribir

A

CP

MongoDB Redis
MemcacheDB Hbase
Berkely DB

AP

Dynamo Cassandra
SimpleDB CouchDB

P

Funcionará incluso
cuando haya errores

en el sistema

19/47



Linux
Málaga

Big Data

Teorema de CAP



CA

MySQL Aster Data
Postgres Greenplum
Oracle Vertica
SQLServer

A

AP

Dynamo Cassandra
Voldemort SimpleDB
Tokyo Cabinet CouchDB
KAI Riak

Tipo

Relacional
Clave-Valor

Orientado a columna
Orientado a documento

P

C

CP

BigTable MongoDB Berkely DB
Hypertable Terrastore MemcacheDB
HBase Scalaris Redis

20/47



Linux
Málaga

Big Data



¡Hey tío!, somos 1023,

¿te vienes y nos hacemos un Peta?

. . . B R E A K . . .
TB
TB
TB
TBTBTB
TBTB
TB
TBTB
TB
TB
TBTBTB
TB
TBTBTB
TBTB TB
TBTB
TBTBTB
TBTB
TB
TBTB
TB
TBTBTB
TB
TB
TBTBTB
TBTBTBTBTBTB
TB
TB
TBTBTB
TB
TB
TBTBTBTBTB
TBTB TB
TBTBTB
TB
TBTB
TBTB
TB
TB
TB
TBTBTBTBTB
TB
TBTBTB
TBTB
TB
TB
TB
TB
TBTB
TB
TB
TBTB
TB
TBTB
TBTB
TB
TBTBTBTBTB
TB
TB
TB
TBTBTB
TBTBTB
TBTBTB
TB

TB

¡Hecho!



Linux
Málaga

Big Data

21/47



Disponibilidad contínua

Simplicidad en la gestión entre servidores
Sin un único punto de fallo

Escalabilidad linear
- Si 2 nodos procesan 100 transacciones/seg
- 4 nodos procesan 200 transacciones/seg
- 8 nodos procesan 400 transacciones/seg

Sistema descentralizado (sin master)

Relaciones por grupo: Nodo → Datacenter → Cluster
Replicación personalizada

22/47



Linux
Málaga

Big Data



Gossip: mantiene la red informada

Partitioner: deciden como se distribuyen los datos

Replication factor: número de réplicas en el cluster

Replica placement strategy: donde poner las réplicas

Snitch: define grupo de máquinas destinadas a réplicas

23/47



Linux
Málaga

Big Data



Gossip:

- Protocolo punto a punto

- Comunicación entre nodos

- Detección de fallos y recuperación

- Autodetección de topología e información

24/47



Linux
Málaga

Big Data



Particionador: encargado de “esparcir” los datos.

Desaconsejados:
Random: Hashes con MD5 (mejor usar Murmur3)
ByteOrdered: orden lexicográfico sobre las claves
OrderPreserving: se asumen claves en formato UTF8

Murmur3: Funcionalmente idéntico a Random
pero es más rápido sin efectos colaterales. Se
centra en la distribucción espacial.

25/47



Linux
Málaga

Big Data



Planificar el deploy de un cluster

Hardware:
- RAM: 16GB-64Gb (mínimo 8Gb)
- CPU: 8-cores dedicados o 4-8 cores en virtuales
- Disco: mejor entre 500Gb y 1Tb por nodo (según I/O)
- 2 discos (commit log + data)
- Sistema de ficheros XFS
- Red mínimo Gigabit

26/47



Linux
Málaga

Big Data



Planificar el deploy de un cluster

Espacio útil disco: 45%-70% de espacio total RAW

Antipatrones:
- Usar un NAS
- Sistemas de ficheros compartidos
- SELECT … IN
- Leer antes de escribir (multiples hits)
- Balanceadores de carga
- Falta de testing
- Bajo conocimiento de Linux

27/47



Linux
Málaga

Big Data

CQL

SQL



CQL

USE myDatabase;

USE myDatabase;

/* Creating Tables */
CREATE TABLE IF NOT EXISTS myTable (id INT PRIMARY KEY);

/* Creating Tables */
CREATE TABLE IF NOT EXISTS myTable (id INT PRIMARY KEY);

/* Altering Tables /*
ALTER TABLE myTable ADD myField INT;

/* Creating Indexes */
CREATE INDEX myIndex ON myTable (myField);

/* Inserting Data */
INSERT INTO myTable (id, myField) VALUES (1, 7);

/* Selecting Data */
SELECT * FROM myTable WHERE myField = 7;

/* Counting Data */
SELECT COUNT(*) FROM myTable;

/* Deleting Data */
DELETE FROM myTable WHERE myField = 7;

/* Altering Tables /*
ALTER TABLE myTable ADD myField INT;

/* Creating Indexes */
CREATE INDEX myIndex ON myTable (myField);

/* Inserting Data */
INSERT INTO myTable (id, myField) VALUES (1, 7);

/* Selecting Data */
SELECT * FROM myTable WHERE myField = 7;

/* Counting Data */
SELECT COUNT(*) FROM myTable;

/* Deleting Data */
DELETE FROM myTable WHERE myField = 7;

28/47



Linux
Málaga

Big Data

Lenguaje CQL



CQL

USE miBaseDatos;

/* Creando Tablas */
CREATE TABLE IF NOT EXISTS miTabla (id INT PRIMARY KEY);

/* Cambiando Tablas /*
ALTER TABLE miTabla ADD miCampo INT;

/* Creating Indexes */
CREATE INDEX miIndice ON miTabla (