Este documento habla sobre Cloud Computing y Big Data. Explica que Cloud Computing proporciona servicios a través de Internet y tiene diferentes tipos como pública, privada, híbrida y comunitaria. También explica qué es Big Data, cómo llegar a él, y que convivimos con Big Data a diario aunque no seamos conscientes. Finalmente, discute cómo usar Big Data en la nube.

1. “CLOUD” & “BIG DATA”
Trabajando el “CLOUD”, explotando
“BIG DATA”.
¿Cómo pueden ayudarnos estas
tecnologías?.
¿Convivimos con ellas?.

2. ‣ Introducción.
‣ ¿Qué es “CLOUD”.
‣ Tipos de “CLOUD”.
‣ Pública.
‣ Privada.
‣ Comunitaria.
‣ Híbrida.
‣ Proveedores de “CLOUD” pública.
‣ ¿Qué es “BIG DATA”?.
‣ Convivimos con “BIG DATA”.
Índice. (I)

3. ‣ Como llegar a “BIG DATA”.
‣ Bases de datos “SQL”.
‣ Productos “SQL”.
‣ Bases de datos “NoSQL”.
‣ Productos “NoSQL”.
‣ Bases de datos “SQL” Vs “NoSQL”.
‣ A.C.I.D. Vs B.A.S.E.
‣ ¿Podemos usar siempre “NoSQL”.
‣ Entornos mixtos “SQL” & “NoSQL”.
‣ ¿cómo usar“BIG DATA” en “CLOUD”?.
‣ P & R.
Índice. (II)

4. ‣ Tecnologías independientes pero
relacionadas.
‣ Orígenes.
‣ Cloud.
No es fácil definir el origen del “Cloud Computing”, pero si
tiene claros predecesores: SOA, VM, etc.
‣ Big Data.
El origen de “Big Data”, como lo conocemos hoy día, puede
ubicarse en las VLDB que fueron creciendo (escalando) de
manera horizontal. Pero su origen es tan antiguo como las
BBDD “tradicionales” como puedan ser las RDBMS, JDB, etc.
No se ofrecían como una alternativa a estas ni de manera
“popular”.
Introducción.

5. ‣ Es complicado
encontrar una
definición universal.
‣ Existen puntos
comunes que hacen
aceptables
diferentes
aproximaciones a
definir “CLOUD”.
‣ Convivimos con
“CLOUD” a diario.
¿Qué es “CLOUD”?.

6. ‣ Según los estándares, CLOUD consta de:
‣ Según las necesidades particulares, se pueden
implementar las soluciones adecuadas a cada caso.
‣ Existen “Service Models” muy particularizados:
DBaaS, MaaS y DaaS, derivados de los tres generales.
¿Qué necesita? “CLOUD”.

7. ‣ Nueve requisitos de almacenamiento en
“CLOUD”.
‣ Escalabilidad y elasticidad “MASIVA”.
‣ Almacenamiento de objetos.
‣ Asignación bajo demanda.
‣ “Agnóstico” en cuanto a aplicaciones.
‣ Seguridad multi-propietario.
‣ Cobro por uso.
‣ Acceso primario (a datos) REST o SOAP.
‣ Localización geográfica no importante.
‣ Accesible vía internet.
¿Qué necesita? “CLOUD”.

8. ‣ SaaS.
Software as a Service.
‣ PaaS.
Platform as a Service.
‣ IaaS.
Infrastructure as a Service.
‣ Evoluciones.
‣ DBaaS.
DataBase as a Service.
‣ MaaS.
Mobility as a Service.
‣ DaaS.
Desktop as a Service.
Modelos de servicio (I)

9. Modelos de servicio. (II)

10. ‣ “CLOUD” pública.
‣ “CLOUD” privada.
‣ “CLOUD” comunitaria.
‣ “CLOUD” hibrida.
Tipos de “CLOUD” (I).

11. ‣ Cuando los sistemas de BBDD “tradicionales” no son
suficientes para gestionar enormes volúmenes de
datos.
‣ Cuando los sistemas disponibles son heterogéneos
pero queremos aprovecharlos.
‣ Cuando la cantidad de sistemas es amplia y la
cantidad de fallos a ocurrir es elevada.
‣ Cuando el software a utilizar es capaz de asegurar la
disponibilidad mínima requerida.
ESTAMOS ANTE UN ESCENARIO PARA
“BIG DATA”.
¿Qué es “BIG DATA”?.

12. ‣ Aunque no seamos conscientes de este hecho, en
nuestro día a día USAMOS “BIG DATA”.
‣ Ejemplos de “BIG DATA”:
Convivimos con “BIG DATA”

13. ‣ Existen 5 puntos a tener en cuenta para poder llegar a
implantar o aprovechar “BIG DATA”:
1. Definir las necesidades y comprender los
requisitos y limitaciones de “BIG DATA”.
2. Descubrir los datos que necesitamos y donde se
encuentran.
3. Obtener los recursos necesarios para
implementar “BIG DATA”.
4. Dar con la tecnología más adecuada para nuestra
casuística.
5. Asegurar que contamos con el equipo y las
habilidades necesarias.
¿Como llegar a “BIG DATA”?

14. ‣ Una vez en “BIG DATA” encontraremos un desafío
principal: E S C A L A B I L I D A D.
‣ Existen 2 posibilidades: Vertical u Horizontal, cada una
de ellas con sus pros y sus contras.
¿Como llegar a “BIG DATA”?
VERTICAL.
+ Rápido y sencillo.
− Hasta un límite.
− Caro.
− Suele “casarnos” con un
proveedor.
HORIZONTAL.
+ Rápido y sencillo *.
+ Límite más lejano.
+ Flexible.
− Añade complejidad.

15. ‣ RDBMS: Bases de datos RELACIONALES.
‣ Son los sistemas de BBDD más extendidos en
la actualidad.
‣ Transacciones que deben cumplir ACID.
‣ A.C.I.D.
‣ Atomicity.
‣ Concurrency.
‣ Isolation.
‣ Durability.
‣ Son dinámicas y escalables hasta unos límites.
Bases de datos “SQL”.

16. Productos “SQL”.

17. Bases de datos “NoSQL”.
‣ BBDD NO relacionales y distribuidas.
‣ Muchos nodos componen la misma BBDD.
‣ Cumplen 2 de 3 requisitos C.A.P.
‣ Consistency: Todos los clientes ven los mismos datos.
‣ Availability: Todos los clientes SIEMPRE acceden a los
datos.
‣ Partition tolerance: Habilidad para continuar
trabajando ante un fallo.
‣ No dependen del “TODO o NADA” de RDBMS.
‣ Elegiremos entre varios niveles de C.A.P.
‣ Estrictos con A + P minimizamos el riesgo de fallos
en C.

18. Bases de datos “NoSQL”.
‣ B.A.S.E.
‣ Basically Available
‣ Soft State
‣ Eventually Consistent.
‣ Las NoSQL escalan gracias a B.A.S.E.
‣ Clases de NoSQL:
‣ Key / Value. Ej: Riak, Voldemort, Redis.
‣ Column (BigTable). Ej: Cassandra, Hbase,Hypertable.
‣ Document. Ej: MongoDB, CouchDB.
‣ Graph. Ej: Neo4j, Pregel, AllegroGraph.

19. Productos “NoSQL”.

20. ‣ Estructuras de datos:
“SQL” Vs “NoSQL”. (I)
‣ SQL:
‣ Tablas, columnas y
filas.
‣ Todas las filas tienen
la misma estructura.
‣ NoSQL:
‣ Eliges tu estructura de
datos.
‣ Estructura natural
para los datos.
‣ Esquemas:
‣ SQL:
‣ Esquemas monolíticos
‣ Mantiene relaciones y
fuerza la integridad de
los datos.
‣ NoSQL:
‣ Estructuras de datos
pueden cambiar
dinámicamente.
‣ Estructura de datos
puede ser opaca.

21. ‣ Normalizaciones y relaciones:
“SQL” Vs “NoSQL”. (II)
‣ SQL:
‣ El modelo de datos se
normaliza para eliminar
duplicidades.
‣ La normalización
establece las relaciones
entre tablas.
‣ NoSQL:
‣ La denormalización no es mala.
‣ Las relaciones no son definidas
explícitamente.
‣ Datos relacionados se suelen
encontrar agrupados y
almacenados como una
unidad.
‣ Acceso a los datos:
‣ SQL:
‣ Operaciones C.R.U.D.
‣ Obtener datos de varias
tablas necesitan JOINS.
‣ APIS genéricas.
‣ NoSQL:
‣ APIS propietarias.
‣ Usan algoritmos
“MapReduce” y
“Graph traversals”.

22. ‣ Capacidades para “reporting”:
“SQL” Vs “NoSQL”. (III)
‣ SQL:
‣ División “slice & dice” y
reunificación “ad-hoc”.
‣ Cubos y datamining.
‣ “Drill down”, “Roll up”,
“Pivot”.
‣ NoSQL:
‣ Dificultad en
reformatear “ad-hoc”.
‣ Todo reporte debe
estar “pensado” por
adelantado.
‣ Resumen:
‣ Elegir la BBDD adecuada a cada caso.
‣ SQL no debería ser preeminente.
‣ NoSQL es superior para determinados casos.
‣ Podemos hacer que trabajen juntas.

23. ‣ PROS:
‣ RDBMS con tablas grandes y creciendo.
‣ Alcanzamos limites en la RDBMS incluso usando
técnicas para VLDB.
‣ NoSQL usada para almacenar datos viejos.
‣ Uso de “vistas materializadas” con esos datos en la
“NoSQL” actualizando durante la noche.
‣ Migrar ciertas partes de las aplicaciones para
acomodarse a la distribución de datos de la
“NoSQL”.
Entornos mixtos “PolyGlot”.

24. ‣ CONS:
‣ Las “VM” en la “NoSQL” consumen mucho
almacenamiento.
‣ Determinadas funcionalidades (Querys) no pueden
ser sustituidas por “VM” en “NoSQL”.
‣ Indexar documentos para busquedas por texto es
muy costoso en tiempo en “NoSQL”.
‣ El desarrollo para “NoSQL” requiere más tiempo y
los modelos “MapReduce” más planificación.
‣ Los cambios de las “VM” en “NoSQL” no es algo
sencillo.
Entornos mixtos “PolyGlot”.

25. ‣ Los factores principales, pero no únicos:
‣ La cantidad de almacenamiento de “BIG DATA”.
‣ La disponibilidad inherente a “CLOUD”.
‣ El origen de los datos a integrar en “NoSQL”.
‣ Aumentaremos la disponibilidad.
‣ Adquirimos la posibilidad de agregar nuevas
funcionalidades.
‣ Nos permite analizar esas cantidades de datos
en un tiempo “razonable”.
‣ Nos permite usar varias “NoSQL” diferentes.
“BIG DATA” en “CLOUD”.

26. Preguntas & Respuestas.