Material para el curso de Big Data

1. CURSO SISTEMAS DISTRIBUIDOS
Introducción
Tema 1 ­ Hadoop
Tema 2 ­ Hive
Tema 3 ­ Sistemas NoSQL
Tema 4 ­ Cassandra
Tema 5 ­ MongoDB

2. Introducción
Durante esta documentación se hablará, a grandes rasgos, sobre diferentes sistemas que
ayudan a las organizaciones a gestionar grandísimas cantidades de datos. Todas estas
tecnologías surgieron por una necesidad, un problema, cuya solución era completamente
necesaria. Actualmente se generan en aproximadamente 2 días tanta información como hasta
el año 2003. Esa información hay que, primero, almacenarla. Esto es relativamente sencillo ya
que el espacio de almacenamiento es razonablemente barato. El problema viene cuando hay
que escribir cantidades de datos gigantes, operación que puede tardar muchísimo, e igual de
crítico: la lectura de datos. Hay que imaginarse por ejemplo un usuario, con su navegador web,
intentando obtener una información sacada de esta gigantesca “nube”. Si el proceso tarda
“mucho”, el usuario se irá de nuestro sitio. Un ejemplo más concreto: un usuario quiere saber
sus datos de Facebook a través de una de sus APIs. Facebook dispone de muchísima
información guardada (se verá más adelante), por lo que le búsqueda de un dato pequeño entre
tantísima información puede hacerse imposible. En cambio, tal y como lo tienen montado, la
llamada tarda normalmente alrededor de un segundo. ¿Cómo es posible esto?
Para responder a la pregunta anterior hay que explicar muchísimas tecnologías, tantas que
hacen falta varios libros y muchísimas horas. Aquí se van a explicar algunas de las más
importantes como Hadoop, Hive, Cassandra y MongoDB, siempre desde un aspecto general
para conocer un poco cada herramienta. Empecemos.

3. Tema 1 ­ Hadoop
Hadoop es un nombre que engloba una serie de herramientas, de las que solo se verá una de
ellas durante este documento. Cada una de ellas ayuda en diferentes objetivos. Todas estas
aplicaciones se han construido para solventar el problema de “Big Data”. Por lo que, lo que hay
que hacer primero, es describir la problemática.
El problema es el siguiente: tenemos una cantidad de información muy grande y queremos leer
algo de esa información. Hasta ahora, si querías más funcionalidades, lo que se hacía era un
escalado vertical, es decir, que el ordenador que realiza la operativa sea más potente. Esto,
además de ser económicamente costoso, tiene un límite, ya que el nivel de procesamiento de
una única máquina no es infinito. Entonces, lo que sucedió para solventar dicha problemática
fue un escalado horizontal: más máquinas trabajando conjuntamente para realizar una única
operación. Esto se ve mejor con un ejemplo. Supongamos que tenemos un único ordenador,
por ejemplo, un portátil. Este portátil es capaz de leer de su único disco duro a 100MB/s, lo que
hace aproximadamente 1Gbps. En cambio, si tenemos un servidor con 12 discos duros, la
velocidad de lectura simultánea sería de 1,2 GB/s (unos 12Gbps). Subiendo un nivel más, un
rack de servidores. Con 20 servidores, el rack es capaz de leer a 24GB/s (240Gbps). Un clúster
medio, con 6 racks de estos, podría leer a 144GB/s (1,4Tbps). Un clúster grande, de 200 racks,
podría leer a 4,8TB/s (unos 48Tbps). Por comparar: un archivo de 4,8TB sería leído en 1
segundo por el clúster grande; ese mismo archivo, por el portátil inicial, tardaría 13 horas en
leerse. ¿Parece mucha información? ¿Algo imposible de alcanzar? 1 Petabyte son 1024
Terabytes. Facebook tiene más de 70 Petabytes de información. ¿Es necesario este tipo de
esquemas? Como se ha visto, es obligatorio.
Se ha descrito la problemática, se ha visto como, teóricamente, el escalado horizontal es la
solución. Pero ¿cuáles son los retos? Principalmente son cuatro:
● Velocidad
● Volumen
● Variedad
● Veracidad
La velocidad y el volumen ya están vistos con el ejemplo anterior. La variedad hace
referencia a que lo mismo tienes que guardar usuarios, como archivos de audio, vídeos y un
largo etc. La veracidad hace referencia a la información guardada. 1 de cada 3 negocios
líderes no confía en la información que tiene guardada (por la razón que sea, por ejemplo,
desactualización). De esta forma, es imposible tomar una decisión si los datos que tienes no
son veraces. Si además de esto, las herramientas al escribir información no lo hacen bien, la
información no será correcta.

4. Hadoop es un software bajo la licencia Apache mantenido por una compañía que se llama
Cloudera. Su objetivo es solventar los cuatro puntos vistos anteriormente. Como definición
podría decirse que es “un sistema distribuido altamente escalable y tolerante a fallos”. Fue
creado por Doug Cuttin (en algunos sitios pone que también participó Michael Cafarella),
trabajadores de Yahoo!, como apoyo al proyecto Nutch de Apache (robot y motor de búsqueda
basado en Lucene). El nombre de Hadoop vino por un elefante de peluche que tenía su hijo y
que llevaba ese nombre (de ahí también el logotipo del producto). Su construcción fue posible
debido a que Google publicó unos Whitepapers con los siguientes elementos:
● GFS, un sistema de archivos.
● Mapreduce.
● BigTable.
GFS, como veremos más adelante, es lo que en Hadoop se conoce como HDFS. El primero
viene de Google Filesystem; el segundo de Hadoop Filesystem. Mapreduce mantiene su
nombre con respecto al elemento de Google. BigTable en Hadoop es una herramienta llamada
HBase. Aunque no se hable de HBase en este documento, vale la pena decir que HBase es un
software perteneciente a Hadoop (una herramienta) que permite almacenar bases de datos
gigantes. Según su propia descripción, el sistema es capaz de almacenar billones filas de por
billones de columnas.Aquíi la clave está en que hay filas y columnas. Como se verá, no todas
las bases de datos NoSQL poseen esta característica.
A pesar de que los whitepapers no contienen una sola línea de código, Doug fue capaz de crear
este sistema para beneficio de muchísimas personas que lo utilizan. Como curiosidad, decir
que Hadoop está escrito en java.
Dentro de las herramientas de Hadoop, existen los siguientes proyectos, uno de ellos
comentadas en este documento:
● Hive
● HBase
● Mahout
● Pig
● Oozie
● Flume

5. ● Scoop
Cada uno de ellos es un pedazo de software que añade un valor a un área relacionada con
Hadoop.
¿Qué componentes tiene Hadoop? Hadoop dispone de dos componentes que le permiten dividir
los “elementos” en pedazos más pequeños para poder trabajar mejor con ellos de una forma
distribuida: Mapreduce y un sistema de ficheros (HDFS o Hadoop FileSystem).
Los datos son divididos y se entregan a varias máquinas Linux interconectadas entre sí. Aquí el
primer concepto son los costes, y es que es muy caro un supercomputador, en cambio, varias
máquinas pequeñas trabajando juntas es mucho más barato. En este sistema distribuido hay
dos componentes por máquina:
● Task tracker: encargado de procesar una pequeña porción de los datos.
● Data node: encargado de gestionar una pequeña porción de los datos.
Todo esto existirá en los nodos denominados slaves o esclavos. Habrá además un master o
maestro que tendrá dos componentes adicionales:
● Job tracker
● Name node
El primero de ellos, junto al task tracker, hacen lo que se llama Mapreduce. Los elementos

6. inferiores forman el sistema HDFS.
¿Cómo funciona todo esto? Una aplicación contactará con el nodo maestro. Esta aplicación
proporciona una tarea que realizar a dicho nodo e irá a una cola de trabajo (procesamiento
batch). El Job tracker, al coger la tarea de la cola, dividirá la tarea en pequeñas piezas. Dichas
piezas serán distribuidas sobre diferentes nodos (task tracker) que ejecutarán la sub­tarea. Al
terminar los nodos esclavos, devolverán su respuesta al Job tracker y este procesará las
respuestas obtenidas. ¿Qué hace el name node? Se encarga de mantener un índice sobre qué
datos están en qué nodos.
El sistema de ficheros HDFS tiene una característica fundamental: la tolerancia a los fallos. Por
defecto, aunque se puede modificar, el sistema mantiene 3 copias de cada fichero repartidas
por la estructura distribuida. Aún así hay un punto único de fallo: el nodo maestro. Si este se
cae, ¿que pasa? Normalmente suele haber otro nodo maestro pasivo por si el primero falla
(algo así como un daemon). Al ocurrir, habrá un tiempo de no respuesta pequeño hasta que el
nodo pasivo pase a ser activo. Es algo asumible e indudablemente mejor que quedarse sin
nodo maestro para nunca. Para que funcione, las tablas que mantiene el name node son
copiadas (backup) al nodo maestro pasivo. Otra funcionalidad del nodo pasivo es, por defecto,
cada hora traer del nodo primario los datos por si, el primero cae, el segundo tiene la
información casi completa del primero. Al persistir los cambios, se persisten en ambos nodos.
Aunque, indudablemente, las tareas que estaban en ejecución deberán volver a repetirse. En la
última versión de Hadoop esto ha cambiado, y es posible distribuir el nodo maestro en varios
nodos.
La mejor manera de ver gran parte de lo mencionado anteriormente es mediante un ejemplo.
Supongamos que tenemos dos ficheros: data1.txt y data2.txt. Ambos ficheros quieren ser
almacenados en un sistema Hadoop, siendo el factor de replicación igual a 3. Este factor de
replicación se configura en el archivo hdfs­site.xml. En el primer paso, supongamos que

7. tenemos los bloques 1, 2 y 3 para el primer archivo y 4 y 5 para el segundo, y el estado de los
nodos de la siguiente forma:
Cada color corresponde a un nodo. Como se puede ver, están todos vacíos. Tras almacenar el
primer archivo, la situación sería la siguiente:
3 3 3 1
2
2 1 1 2
En la imagen anterior, hay tres copias de cada bloque distribuidas por los nodos. Tras
almacenar el segundo archivo, la situación sería así:
3 3 5 3 1 4
5 4 5 2
2 1 4 1 2
De nuevo, tres réplicas de cada bloque. Utilizando este ejemplo, se puede explicar otro
concepto que tiene Hadoop. En el caso de que el último nodo se caiga, conteniendo las réplicas
1, 4 y 2, dichas réplicas se perderían. El sistema es capaz de detectar esta pérdida, y si
pasados 10 minutos el nodo no vuelve a estar activo, se colocarán tres nuevas réplicas en otros
nodos.
Además, el caso anterior supone que están los 4 nodos en el mismo rack. ¿Qué pasaría en el
caso de que el rack tenga, por ejemplo, un problema de corriente? Todas las réplicas se
perderían. Por eso existe el concepto de rack awareness, en el que las réplicas son distribuidas

8. en diferentes nodos de diferentes racks. Si se ha configurado correctamente, el sistema
mantendrá una copia (normalmente la primera de ellas) en uno de los racks y las otras dos en
otro rack. ¿Porqué? Porque si están las 3 en el mismo rack y hay un corte de corriente, las tres
copias se pierden, como ya se ha visto. Entonces la siguiente pregunta lógica sería, ¿porqué no
separar las 3 en 3 racks diferentes? La respuesta es porque los racks suelen tener una
conexión entre ellos de 1Gbps, pero internamente suelen tener una conexión de 10Gbps. Esto
permite tener una estabilidad entre tolerancia de fallos (separar 2 de las réplicas de la primera) y
velocidad de lectura (mantener dos en un rack). Pongamos un ejemplo de este concepto.
Disponemos de un archivo file.txt que queremos guardar en Hadoop. El sistema lo parte en dos
bloques, con tres réplicas por cada bloque, y nos da la siguiente lista: bloque A en los data node
1, 7 y 8; bloque B en los data node 8, 12 y 14. Cada rack tiene 5 data nodes, por lo que el
resultado final será así:
A
A B
AB
B
En la figura anterior, las columnas son los racks y las filas los nodos. ¿Qué se ha conseguido?
En el caso de que se caiga un rack completo, existirá al menos una réplica del bloque en el
sistema.
Mantener tres réplicas hace que el sistema sea algo más lento, ya que hasta que no se han
escrito en disco las 3, el sistema no devuelve un estado positivo. Si se pusiera el factor de
replicación a 1, obviamente sería más rápido pero se perdería la tolerancia a fallos. En cambio,
a la hora de leer es justo lo contrario. Si se quisiera leer este archivo file.txt, el sistema nos diría
que hay dos bloques, y que están en los nodos correspondientes. La lista que nos devuelve está
ordenada por tráfico ya que se sabe cuáles son los nodos que están ocupados. Al poder leer el
archivo de varios sitios a la vez y además, sabiendo que estos sitios son los que menos tráfico
tienen la velocidad de lectura es muy superior.
Básicamente, esto es lo que hace Hadoop. Por lo que, resumiendo, existe una problemática que
se puede dividir en tres partes:
● Cantidad de datos gigante, lo que hace su procesamiento imposible.

9. ● Almacenamiento de todos estos datos, lo que hace difícil el mantenerlos vivos (caro).
● Obtener los archivos originales, ya que normalmente los datos son procesados.
Hadoop consigue solventar estos tres puntos anteriores, otorgando una serie de beneficios:
● Escalabilidad sobre los datos.
● Es más económico mantener los datos mucho más tiempo.
● Flexibilidad y agilidad para los datos no procesados (raw data).
Todo esto es muy bonito sobre papel, pero en el caso de tener un sistema Hadoop, ¿cómo es
posible visualizar todo esto? Por suerte, Hadoop posee un servidor web embebido que por
defecto escucha por el puerto 54310. Este servidor web muestra cuándo se ha arrancado, la
versión, la capacidad, el número de nodos activos, el número de nodos muertos, etc. No es algo
muy visual como tiene DataStax con la base de datos Cassandra, visto más adelante, pero
permite ver ciertos valores clave para conocer la situación global del sistema e incluso contiene
un navegador de archivos sencillo, parecido a un cliente web FTP.
Durante repetidas veces ha salido el nombre del sistema de ficheros HDFS. Un disco duro no
puede formatearse en este formato. Para su utilización en Hadoop, se pueden utilizar tres
formatos diferentes. El primero de ellos es ext3. Este sistema salió a la luz en 2001 y es el que
utiliza Yahoo! entre otros. En 2008 salió su sucesor: ext4. También es posible utilizar este
formato, y es el que utiliza Google. Al igual que el siguiente formato, es muy rápido. El último
formato utilizado es XFS. Es un formato antiguo, creado en 1993 que tiene problemas como el

10. borrado de archivos de gran tamaño. Como ya se ha dicho, su ventaja es que, a excepción de
este punto, es muy rápido. La parte de discos duros es muy importante ya que los clústeres
mundiales almacenan entre 20 y 30 Petabytes utilizando unas 4000 máquinas. Hay excepciones
como Facebook, que, como ya se ha visto, almacenan más de 70 Petabytes.
La siguiente imagen está sacada de Yahoo! y muestra un cluster de la compañía.
En cuanto a su uso, es muy parecido a los comandos de Linux tradicionales. Simplemente hay
que hacer uso del binario bin/hadoop seguido de un comando. Los comandos de la shell de fs
(filesystem) son los siguientes (http://hadoop.apache.org/docs/r0.18.3/hdfs_shell.html):
● cat
● chgrp
● chmod
● chown
● copyFromLocal
● copyToLocal
● cp
● du
● dus
● expunge
● get
● getmerge
● ls
● lsr
● mkdir
● movefromLocal
● mv
● put
● rm

11. ● rmr
● setrep
● stat
● tail
● test
● text
● touchz
Muchos de ellos son fáciles de reconocer. Por ejemplo, si se quiere copiar un archivo que está
en nuestro ordenador al sistema de Hadoop, podría ser algo como esto:
● bin/hadoop fs ­copyFromLocal /ruta/local/archivo /ruta/hdfs
En la imagen a continuación se pueden ver algunos de los comandos que admite Hadoop:
Todo esto parece un sistema muy complicado pero, en realidad, es totalmente transparente. Es
decir, para los programadores es muy fácil hacer su trabajo ya que no necesitan realizar código
a bajo nivel para que sus programas funcionen: no necesitan saber dónde está el archivo, no
necesitan realizar una gestión de errores o fallos, no necesitan saber cómo romper el fichero en
partes y cómo distribuirlas, mucho menos necesitan saber sobre el escalado del sistema... y un
largo etc. Simplemente han de centrarse en realizar programas tal y como lo hacían antes, sin
fijarse en el escalado. ¿Por qué? Es el software que está por detrás, Hadoop, el que se

12. encarga de todo esto. Aquí salen dos claras ventajas. La primera de ellas ya se ha nombrado
anteriormente: reducción de costes. Es mucho más barato comprar muchas máquinas
pequeñas y hacer con ellas un cálculo conjunto gracias a Hadoop que comprar un
superordenador para llegar a hacer el mismo propósito. Además, puede que sea imposible
llegar al propósito por limitaciones de hardware, por lo que se hace obligatorio un sistema de
este tipo. La segunda ventaja es sobre el escalado, y es que no hace falta tocar una línea de
código de los programas para escalar más el sistema. Basta con comprar otra máquina,
enchufarla a uno de los racks (si se dispone, u otro sitio correcto) y la velocidad se verá
incrementada linealmente. Esto quiere decir que si un ordenador es capaz de leer a una
velocidad ‘X’, dos ordenadores leerán a velocidad ‘2X’, tres a ‘3X’, etc. No habrá un punto de
inflexión ni aparecerá una curva en la gráfica: es totalmente lineal.
En Hadoop hay dos tipos de roles: los usuarios y los administradores. El primero de ellos, los
usuarios, tiene las siguientes tareas:
● Diseñar aplicaciones
● Importar datos
● Exportar datos
● Trabajar con herramientas
En cambio, los administradores son responsables de:
● Instalación
● Monitorización y gestión del sistema
● Tuning del sistema
Bien es cierto que, llevada la teoría de los roles a la práctica, hay una parte que comparten y es
que, por ejemplo, gracias a las aplicaciones que hacen los usuarios estos son capaces de ver
que el sistema se puede mejorar (tuning) y le pasan esta información a los administradores; y
viceversa, gracias a una monitorización de utilización, por ejemplo, se pueden ver
modificaciones necesarias a realizar en el código.
La utilización de Hadoop se puede ver en varios sectores:
● Social media
● Retail
● Financiero
● Herramientas de búsqueda
● Gobierno
● Agencias de inteligencia
● Etc.
Entre sus usuarios más famosos se encuentran: Yahoo!, Facebook, Amazon, ebay, American
Airlines, The New York Times, Federal Reserve board, Chevron, IBM, etc.
¿Qué utilizaciones tiene? Por ejemplo: de una serie de datos gigante, sacar comportamientos

13. de los usuarios para generar recomendaciones. O en un motor de búsqueda, agrupar los
resultados según documentos relacionados. O en temas de seguridad: buscar patrones que se
salgan de lo común.
Por último, decir que según los cálculos de Yahoo!, en 2015, el 50% de los datos empresariales
los procesará Hadoop.
Una imagen resumen del funcionamiento de Hadoop:

14. Tema 2 ­ Hive
Hive es un software que, al formar parte de las herramientas Hadoop, también está bajo la
licencia Apache. Como ya se ha visto, Hadoop permite un sistema distribuido para archivos,
pero no el sistema de archivos no permite realizar consultas.
Hive se está basado en la infraestructura Hadoop y es una de las herramientas base. Utiliza
SQL simple como DDL y queries. Es fácil de aprender y, al igual que Hadoop, no es necesario
utilizar Java de bajo nivel para usarlo. El “tipo SQL” que utiliza se llama HQL, y gracias a un
driver JDBC/ODBC permite un sistema de acceso fácil a la par que extensible.
Su principal diferencia con los RDBMS (sistemas de gestión de base de datos relacionales) es
que, en los tradicionales, el esquema se hace en tiempo de carga (schema on write), mientras
que en Hive, el esquema se hace con las queries (schema on read). Otra gran diferencia es que
no está preparado para transacciones.
En cuanto a la arquitectura, su parte principal el driver, encargado de compilar, optimizar y
ejecutar las sentencias. ¿Qué quiere decir esto? El driver recibe una query, optimiza la query y
posteriormente se realizan las tareas de map reduce.

15. Como se puede ver en la imagen anterior, el siguiente componente a destacar es el metastore.
Este componente guarda toda la información sobre tablas y tipos de datos en un almacén
relacional separado. Además, también se dispone de una serie de interfaces que serían en
cliente de comandos (CLI en la imagen) y un interfaz web (Web GUI). Por último, existe un thrift
server que se encarga de la comunicación cliente servidor gracias a JDBC/ODBC.
¿Qué es lo bueno de todo esto? Muchas herramientas de reporte actual están basadas en el
driver JDBC/OBDC, por lo que cualquiera de estas herramientas funcionará perfectamente
sobre Hive, que a su vez está sobre Hadoop. Y todo esto de una forma transparente para el
usuario.
El siguiente tema a tratar es el modelo de datos. Como Hadoop está sobre HDFS, Hive
también lo está. Por ejemplo, la ruta podría ser /user/hive/warehouse. El concepto de base de
datos sigue siendo el mismo: un espacio que agrupa tablas y otras unidades de datos. Las
tablas son colecciones de columnas, con operaciones totalmente normales. Las columnas
pueden ser varios tipos, como tinyint, float, … y algún tipo nuevo, como timestamp. Además,

16. también acepta:
● Array de primitivos
● Mapa de primitivos
● Estructuras
Para estos tres, se puede utilizar el punto para acceder a sus valores. A continuación se ve un
ejemplo:
● CREATE TABLE ejemplo_clase (alumnos ARRAY<STRING>, aprobados MAP
<STRING, STRING>, examen STRUCT<curso: STRING, nota: FLOAT);
En este ejemplo ejemplo, se podría utilizar “examen.nota” para obtener dicho dato.
Hive además soporta el particionado de sus datos. Es decir, partir los datos, basándose en las
claves (que puede ser una o más) sobre el cluster de Hadoop. Hay dos tipos de particiones:
● Static columns, cuando la clave se sabe a la hora de compilar.
● Dynamic columns, cuando la clave no se sabe a la hora de compilar.
Por otro lado, existe el concepto de buckets, que es una extensión de las particiones. Las
particiones se dividen en buckets basándose en el hash de la columna. Es muy eficiente y hace
que operaciones como mapside join se realicen en menos tiempo.
HQL se parece mucho a SQL, pero no lo cumple al 100% . Por ejemplo, las sentencias join
solo se permite hacer con el operador igual. Tampoco existe insert into, update o delete. Por
último, tampoco existe ACL. ¿Y como se insertan datos? Existen dos opciones. La primera es
mediante la carga de un archivo, bien sea local o un archivo en HDFS. La siguiente es mediante
la inserción basada en una sentencia select a una partición estática o dinámica.
¿Y por qué se parece tanto HQL a SQL? Hive fue inicialmente desarrollado por Facebook.
Facebook y sus desarrolladores eran bastante fans de MySQL. Esto les hizo basar parte de
Hive en MySQL, incluyendo su lenguaje de queries.
A la hora de instalar Hive, existen principalmente dos opciones. La primera es tener tu propio
datacenter y configurar todos los elementos tanto en Hadoop como en Hive para que funcione
correctamente. Mucha gente no tiene la necesidad de tener su propio datacenter o simplemente
no les sale rentable bien mantener uno o bien, en el caso de ser necesario, comprar los
componentes para montar uno. Por eso, la segunda opción es pagar por uno ya montado.
Amazon dispone de servicios en la nube donde se puede montar Hive con una serie de pasos
medianamente sencillos. Si se desea más información sobre este tema, visitar la web de

17. Amazon para visualizar sus servicios y su ayuda sobre “runnning Hive on Amazon”.
Para terminar, ¿qué beneficios tiene Hive?
● Construido sobre Hadoop, por lo que tiene todos los beneficios de Hadoop.
● No es necesario realizar código de bajo nivel Java para el mapreduce, ya lo hace
Hadoop.
● Driver ODBC/JDBC, por lo que entre otras cosas, todas las herramientas de reporte
funcionan perfectamente.
● Escalabilidad y rendimiento
● Extensible (por ejemplo, UDF, SerDe, etc.).

18. Tema 3 ­ Sistemas NoSQL
En este apartado, al igual que en todo el documento, se comparte más o menos la misma
problemática. La cuestión estaba en que mediante el escalado vertical se había llegado a un
límite que no se podía superar. Por eso, varios expertos se reunieron y utilizaron el hashtag
#NoSQL en Twitter para dicha reunión. Sin embargo, aunque se haya quedado con este
nombre, no es el más indicado. Muchos de los expertos dicen que sería más adecuado decir
not only SQL (no solo SQL).
La historia hasta llegar a este punto es la siguiente. A mediados de los 80, hubo un incremento
notable en el tema relacional. Los conceptos de persistencia, SQL, transacciones, reporting,
etc. cobraron gran valor. Pero, poco a poco se fue descubriendo un problema y era el “esquema
lógico” (impedance mismatch). A mediados de los 90, surgieron las bases de datos de objetos.
No tuvieron mucho éxito y años más tarde, a mediados de los 2000, no consiguieron desbancar
a las bases de datos relacionales quienes dominaron claramente el mundo de las bases de
datos.
Pero a su vez, hubo otro movimiento masivo que había que tener en cuenta: el crecimiento de
Internet. Cada vez más gente tenía Internet, no sólo en casa, sino también en dispositivos
móviles. Esto hizo que el tráfico de sitios como Google o Amazon, entre otros, fuese gigante. El
escalado vertical ya no era una solución posible, primero porque en cuanto al tema económico
los supercomputadores son únicos y muy caros y porque, hablando de bases de datos, los
RDBMS en un solo nodo (sistemas de gestión de base de datos relacionales) no podían con
tanto tráfico.
Es por esto que se buscó una solución para poder meter estos sistemas en clusters, y así
poder hacer un escalado horizontal. Google obtuvo BigTable y Amazon Dynamo. Pero, ¿de
donde salieron estas ideas? Como ya se ha visto, hubo una reunión con las personas y grupos
más influyentes del mundo de base de datos. Dicha reunión recibió, como ya se ha visto, el
hashtag #NoSQL, por lo que “accidentalmente” estas bases de datos recibieron este nombre.
¿Qué son estas bases de datos? En realidad, no hay una descripción que englobe a todas
ellas, pero sí que hay ciertas características comunes. Como por ejemplo:
● Son no relacionales.
● La mayoría son Open Source.
● Es posible que funcionen sobre clusters (cluster friendly)
● Todas salieron para poder dar cabida a la web del siglo 21 (información gigante)
● No tienen esquema fijo.
Dentro del mundo de NoSQL, existen los siguientes sistemas:
● HBase
● MongoDB
● Riak

19. ● Voldemort
● Neo4j
● Cassandra
● Hypertable
● HyerGraph DB
● Memcached
● Tokyo Cabinet
● Redis
● CouchDB
● Etc.
De todos estos, los especialmente diseñados para Big Data son: HBase, Cassandra e
Hypertable.
¿Qué modelos de datos pueden tener? Como se ve en la siguiente imagen, pueden ser
cuatro:
Algunos dividen el tipo key­value en dos: persistente y volátil. Los de tipo key­value almacenan
datos por cada clave. A la base de datos no le importa lo que vaya en el valor, tan sólo tiene en
cuenta la clave. Aunque hay algunos softwares que disponen de metadatos para saber qué tipo
de datos se están almacenando. Está basado en Amazon Dynamo, y permite tener muchísima
información y una alta carga de trabajo. Un ejemplo de este tipo es Voldemort (LinkedIn).

20. Los documentos son estructuras de datos complejas. Normalmente se utiliza JSON para
almacenar los datos, pero se pueden utilizar otros formatos como por ejemplo XML. No poseen
esquema pero aceptan sentencias de búsqueda, actualización, etc. Los documentos poseen
por lo general un id, que viene a ser una clave única. Dichos objetos se mapean exactamente a
los objetos de la programación orientada a objetos. Un ejemplo de este tipo es CouchDB.
Los de tipo BigTable también se denominan column­family. Ahora, por cada clave se
almacenan una serie de datos relacionados, datos que están agrupados por columnas, y no por

21. filas. Como se ve en la imagen, cada columna tiene tres campos: nombre, valor y timestamp.
Un ejemplo de este tipo es Cassandra.
El último tipo, en forma de grafo, es bastante diferente al resto. Se basa en la teoría matemática
de grafos. Almacena la información en nodos, los que están conectados al resto con una serie
de relaciones. En comparación con las bases de datos relacionales, tienen claramente una
cosa muy buena: al no poseer claves externas, los nodos se pueden mover de un lado al otro
simplemente modificando sus relaciones. Esto no dará ningún problema como pasaría en un
sistema relacional tradicional. Un software de este tipo es FlockDB. A continuación un ejemplo
muy sencillo:
Antes se han visto muchas bases de datos NoSQL, pero ¿a qué modelo corresponden cada
una? La siguiente imagen muestra tanto bases de datos relacionales como NoSQL, además de

22. algún otro dato interesante:
De todo esto, aunque se repita el concepto, lo más importante es que no poseen esquema. Se
pueden ver unas comparativas en la dirección URL:
● http://kkovacs.eu/cassandra­vs­mongodb­vs­couchdb­vs­redis
Otro tema importante sobre el NoSQL es la consistencia. Se pretende conseguir que mucha
gente pueda tanto leer como escribir al mismo tiempo en estas bases de datos. Las bases de
datos relacionales cumplen un conjunto de características denominado ACID: atomicidad,
consistencia, aislamiento y durabilidad (en castellano). Este concepto también se cumple en las
bases de datos de tipo grafo, pero ¿y el resto? La respuesta es que no es necesario.
Existen dos tipos de consistencia: la consistencia lógica y la consistencia física. Para la
consistencia lógica, imaginemos el siguiente caso. Dos personas obtienen una web con los
datos de la persona A. El primero de ellos modifica el nombre y envía el formulario. Se
almacena con el nuevo nombre. En cambio, el segundo que es un poco más lento, modifica el
apellido. Al enviar, guardará su versión, modificando el nombre por el original y perdiendo el
cambio que había hecho el otro usuario. ¿Cómo se arregla esto? Hay tres posibilidades:
1. Realizar una transacción desde la lectura a la escritura. Esto no es viable, ya que si un
usuario lo lee y deja el navegador abierto, nadie más podrá leerlo, cuando es posible que
ni siquiera lo modifique.
2. Envolver la transacción a la hora de escribir. Esto significa que a la hora de escribir
solicite la versión que está en el servidor antes de almacenar. Aquí lo que pasará es que

23. detectará un conflicto, y no permitirá escribir.
3. Version stamp (offline lock): aquí, a la hora de descargar el usuario a leer, también
recibimos una versión del usuario. Por lo que el usuario A guarda los cambios. Al
guardar, se comprueban la versión leída con la que está en el servidor. Como es la
misma, no hay error, se guarda sin problema. En cambio, el B, al enviar sus cambios,
su versión es una anterior a la que está en el servidor, por lo que hay un conflicto y se
realiza la acción que corresponda.
En la consistencia física se implican varias máquinas. En replicación de bases de datos, como
se verá más adelante, existen dos posibilidades:
● Sharding, que permite tener los datos distribuidos en diferentes máquinas.
● Replicating, que permite tener los datos repetidos en diferentes máquinas.
La primera de ellas tiene los mismos problemas que con una máquina. En cambio, la segunda
añade un problema nuevo. Imaginémonos que disponemos de un sistema de alquiler de
habitaciones de hotel distribuido. El usuario A conecta con el nodo 1 y el usuario B con el nodo
2. Ambos nodos deben estar siempre conectados para mantener sus datos consistentes. Si
todo funciona bien, el usuario A reserva la última habitación y el usuario B no puede reservar.
Pero, ¿y si hay un fallo de conexión entre los servidores? Aquí es donde hay que escoger la
solución:
● Mostrar un mensaje de “en este momento no se pueden reservar habitaciones por
problemas técnicos”.
● Ignorar la desconexión y permitir a los usuarios reservar habitaciones. Esto puede
conllevar a que dos usuarios tengan la misma habitación.
Escoger una u otra depende del tipo de negocio y aplicación que esté funcionando. Esto es lo
que se llama El teorema de CAP, que dice que en un sistema distribuido se tiene:
● Consistencia
● Disponibilidad (Availability)
● Tolerancia a fallos (Partition tolerance)
Pero que simultáneamente solo se puede ofrecer 2 de las tres características.
¿Cuándo utilizar NoSQL? Lo primero a destacar es la cantidad de información. Cada vez hay
que manejar más y más datos, por lo que este tipo de bases de datos son muy buenas cuando
las cantidades son gigantes. El segundo punto clave a destacar es cuando los datos con
complejos. Se pueden almacenar agregados de información, haciendo que sea mucho más
fácil el almacenamiento de estructuras complejas. Por último, la distribución de estos datos y
del número de servidores que los manejan es sencilla. Además, no hace falta parar los
servicios para añadir o eliminar un servidor.
Por último, si se quiere instalar Hadoop, Cloudera dispone de un software llamado CDH con el
que se hace sencillo la instalación del pack (todas las herramientas nombradas anteriormente).

24. Además, disponen de un instalador wizard que ayuda notablemente a realizar esta instalación
(SCM).

25. Tema 4 ­ Cassandra
Cassandra es un proyecto bajo la licencia Apache que lo lleva una compañia llamada DataStax.
Está dentro del grupo de bases de datos NoSQL. Sus cuatro características principales son:
● Distribuida
● Alto rendimiento
● Extremadamente escalable
● Tolerante a fallos
Su existencia es gracias a los whitepapers de Google donde explicaban su base de datos
BigTable y a una estructura tipo Dynamo de Amazon. Facebook es quien inicialmente desarrolló
esta tecnología, y ahora la usan otros grandes como Twitter. Entre todos están consiguiendo
mejorar el sistema.
Por lo que, conectando con lo anterior, Cassandra cogió un poco lo mejor de cada lado,
quedando en medio de las tecnologías BigTable y Dynamo. Softwares como HBase o
Hypertable son únicamente de tipo BigTable mientras que Riak o Voldemort son de tipo
Dynamo.
La problemática era la misma que en Hadoop: muchísimos datos en una base de datos SQL
que era imposible de procesar. Cassandra es tan solo una de las soluciones que hay en el
mercado para esta problemática. Algunos conceptos sobre Cassandra:
● Diseñada entendiendo fallos del sistema y de hardware.
● Distribución peer­to­peer
● Todos los nodos son iguales (no hay nodos maestro ­ esclavo)
● Los datos se particionan por los nodos
● Existe un replicación de datos configurable
● Se puede leer y escribir de y a cualquier nodo
● Existe un commit log y memtable
Cassandra se agrupa dentro de las bases de datos NoSQL de clave ­ valor. Además de esto,

26. su esquema se puede definir como una estructura de columnas orientadas a filas, pero flexible.
Hasta este punto se ha visto un poco por encima Cassandra a modo de introducción. La
pregunta a responder ahora más en detalle es, ¿por qué usar Cassandra?
● Para manejar Big Data gracias a su escalabilidad (Gigabytes incluso Petabytes), ya que
su escalabilidad es lineal.
● No hay un único punto de fallo, se puede leer y escribir a cualquier nodo (esto se puede
configurar) y además admite sistema de racks.
● La replicación es sencilla a la vez que transparente, se puede usar un único datacenter o
varios, incluso un sistema en la nube o todo a la vez.
● Gracias al sistema peer­to­peer no es necesario ningún sistema de cacheo software.
● Consistencia de datos configurable (por ejemplo, que todos los nodos respondan, o con
que responda uno vale, etc.).
● Flexibilidad en el esquema, más que un sistema de gestión de base de datos relacional,
permitiendo cambiar la estructura sin necesidad de que haya un tiempo de caída.
● Compresión de datos muy fuerte: hace uso de Google Snappy como algoritmo de
compresión y no tiene penalidad en el rendimiento.
Cuando se comenzó a desarrollar Cassandra, lo primero en lo que se concentraron fue en la
escritura. Esta debía ser segura pero a la vez muy rápida. Es en lo que fallaban muchos otros
sistemas. Una vez que esto se consiguió, se centran en la lectura, que era un tema más
sencillo. De una versión a otra, los cambios fueron espectaculares.
Otro de los conceptos que más tuvieron en cuenta fue la frase “el tiempo de desconexión no es
una opción”. Por eso se diseñó la estructura en anillo peer­to­peer. Esta estructura permite,
además de no tener maestro esclavo, meter un nuevo nodos sin necesidad de este tiempo de
baja (bootstrap).
Para poder utilizar esta base de datos, obviamente no vale saber sentencias SQL como las que
se utilizarían en un sistema relacional. Cassandra utiliza su propio lenguaje llamado CQL:
Cassandra Query Language. Este lenguaje es muy similar al típico de los sistemas de gestión
de bases de datos relacionales:
● Se crean los objetos con DDL (Data Definition Language)
● Existen comandos DML (Data Management Language) en el núcleo: insert, update,
delete.
● Se realizan queries con el comando SELECT.
Muchísimas empresas conocidas hacen uso de Cassandra, como por ejemplo:
● Digg, uso por completo.
● eBay, lo utiliza para sus aplicaciones.
● eBuddy, para la búsqueda de usuarios.
● GoDaddy, para las aplicaciones.
● HP.

27. ● IBM.
● Navteq, para usuarios e información demográfica.
● Netflix, para el sistema en la nube.
● OpenFeint, para su sistema de juegos en tiempo real.
● Reddit.
● Soundcloud.
● Spotify,
● Symantec,
● Twitter, para su equipo de geolocalización.
● Etc.
La lista completa de las empresas que utilizan Cassandra está en la siguiente dirección URL
http://planetcassandra.org/Company/ViewCompany.
La imagen a continuación, por parte de Netflix, muestra cómo se distribuye Cassandra en
formato peer­to­peer:
Como se ve en la imagen, no hay un nodo maestro que controle el resto, como pasaba en
Hadoop. Esto hace que el sistema sea completamente distribuido. A la hora de dar
conferencias, la gente de DataStax suele poner un tweet de una persona que dice “me ha
costado 10 horas darme cuenta de que un nodo de #cassandra tenía un fallo de hardware”, lo

28. que demuestra claramente lo bien que funciona la escalabilidad en el sistema.
Por otro lado, imaginémonos que los nodos de la imagen anterior contienen cada uno una letra:
A, B, C, D, E y F. Sabiendo que el sistema no es de maestro esclavo, puedo preguntar por la
letra A justo al nodo que la contiene, por lo que me puede responder fácilmente. Pero, ¿y si no
tiene él la A? El cliente no tiene que preguntar a otro nodo, sino que internamente, el nodo es
capaz de preguntar al nodo que sí contiene la A y devolver la respuesta al cliente. Por eso, se
dice que cada nodo hace de router, y que no tiene sentido el tema de maestro esclavo.
Pero, ¿cómo se estructura la información en Cassandra? Ya hemos dicho que no es una base
de datos de tipo clave ­ valor. Esto nos da la primera pista: necesita una clave, y esto es
obligatorio. Es necesaria puesto que se utiliza para la partición de los datos. Dicha clave
contendrá una serie de columnas. La siguiente imagen muestra mejor la arquitectura de
Cassandra:

29. Una vez se tengan las claves, ya se sabe a qué nodo del cluster irán. ¿Por qué? Puesto que a
los nodos se les asigna un token (una clave de 128 bits). Las claves entonces se comparan con
el token, y la primer réplica va a parar al nodo que contemple esa clave. Las siguientes réplicas
van a parar, por defecto, a los siguientes nodos del anillo. Si se sabe más sobre el cluster, se
puede configurar Cassandra para que distribuya las réplicas en diferentes racks. Además, esta
replicación puede ser tanto síncrona (hasta que todas no hayan sido escritas, no hay un OK)
como asíncrona. Un ejemplo para ver esto de una forma un poco reducida. Imaginémonos que
tenemos cuatro nodos, y unas claves que van de 0 a 100. El nodo A contendrá las claves de 0
al 24; el nodo B del 25 al 49; el nodo C del 50 al 74; y el nodo D del 75 al 100. Por tanto, si se
quiere almacenar los datos cuya clave es 27, la primera réplica irá al nodo B.

30. Por otro lado, Cassandra no necesita de ningún software de cacheo. Al mantener la última
versión de cada fila en memoria (row cache), el uso de memcache es inútil. Por lo que, además,
se gana velocidad, al no tener que invalidar la copia y tener que hacer una búsqueda (fetch) en
una caché separada (arquitectura a dos niveles).
A la hora de instalar Cassandra, se puede hacer de varias formas. La primera es dirigirse a la
web oficial, un subdominio de Apache, pulsar sobre Download y descargarse el paquete
correspondiente. Sin embargo, dentro de esta misma sección de descargas también hay un
apartado denominado “third party distributions” en el que señalan la comunidad de DataStax. En
dicha comunidad se pueden descargar dos paquetes de Cassandra, siempre en su última
versión, uno de ellos gratis y el otro de pago. El gratuito dispone de la última versión de
comunidad de Cassandra y un sistema de monitorización llamado OpsCenter. Esta versión es
bastante inferior con respecto a la que trae la versión de pago mediante suscripción. Además,
esta versión trae otras muchas ventas, se pueden ver en la siguiente dirección URL, pulsando
donde pone compare: http://planetcassandra.org/Download/DataStaxCommunityEdition.
Una vez instalado, este software posee un webserver que ofrece muchísima información
interesante. A continuación se muestra una imagen de la pantalla inicial:

31. Disponer de este tipo de elementos posibilita el tener a la vista muchísimos datos que permiten
monitorizar cada parte de nuestro sistema Cassandra. Obviamente, para algo personal, la
utilización de un sistema como este es casi por diversión o por disponer de una gran cantidad
de datos, o incluso para ver si existe algún fallo en el sistema. Pero empresas como Facebook
que hacen uso de Cassandra necesitan tener monitorización de cada una de las cosas que
pasan. No solo porque disponen de este sistema distribuido, sino porque su distribución no está
localizada en un sitio, sino porque se encuentra en varios sitios.
A continuación se muestra otra imagen del OpsCenter. En este caso, se pueden observar
gráficas de rendimiento. Como se puede apreciar, hay muchísima información que se puede
obtener:

32. Para terminar, uno de los casos de uso de Cassandra: Netflix. Esta compañía dispone de más
de 57 clusters de Cassandra, compuestos por cientos de máquinas. Gracias a Cassandra, hoy
en día pueden funcionar con normalidad, ya que, cuando comenzaron, su base de datos era
Oracle DB. Como ya se ha visto, el escalado vertical impedía que Netflix diera el soporte que
tiene ahora. Se pasaron en un principio a Amazon SimpleDB como base de datos NoSQL, pero
terminaron usando Cassandra puesto que necesitaban aún más potencia de la que les daba
SimpleDB. Una de sus primeras aplicaciones de Cassandra fue la aplicación que permitía ver
películas de Netflix en la PlayStation 3.

33. Tema 5 ­ MongoDB
Mongo es una palabra que viene de humongous. Es una base de datos Open Source cuyo
desarrollo está liderado por la compañía 10gen. Es una base de datos NoSQL, es decir, sin
esquema, de tipo documental. Es altamente escalable en sus últimas versiones y posee una
funcionalidad de mapreduce propia. Además, el sistema de replicación y sharding es muy fácil
de poner en marcha. Todo esto hace que sea una base de datos de alto rendimiento.
Cada instancia de MongoDB posee una serie de bases de datos. Cada base de datos está
compuesta por colecciones. Las colecciones, a su vez, contienen documentos. Todo esto se
puede comparar con las bases de datos relacionales tradicionales. La siguiente imagen
muestra dicha comparativa:
La instalación de MongoDB es muy sencilla. Una vez instalado, se posee de un shell o interfaz
de línea de comandos que permite manejarse dentro del software adquiriendo poco
conocimiento si se conoce Javascript. ¿Por qué? Mongo utiliza un motor de Javascript. Antes
utilizaba Spidermonkey pero actualmente utiliza V8 de Google. Esto permite, por ejemplo,

34. declarar variables, realizar bucles, etc.
Otro elemento, el cual puede verse en la imagen anterior, es el BSON. BSON viene de Binary
JSON, y permite tener algún otro tipo de dato como fechas o arrays. Que JSON permita tener,
por ejemplo, el formato de fecha de forma nativa permite realizar operaciones como “dame
todos los artículos cuya fecha de publicación este entre A y B”.
Otra de las funcionalidades comentadas es el mapreduce. Lo que permite esta funcionalidad es
realizar una manipulación de datos en el lado del servidor antes de que estos sean devueltos.
Para ello hace uso de colecciones temporales para el manejo de datos o agregaciones. Con
esta funcionalidad se podría realizar, por ejemplo: obtener por cada cliente el dinero que se ha
gastado en total en la tienda.
En cuanto al sistema de réplicas, Mongo permite una estructura maestro esclavo configurable.
Es muy fácil de poner en marcha. Este sistema permite que si un servidor se cae, el otro se
ponga activo automáticamente.
Sobre el sistema de sharding, es un sistema que permite dividir la información de una base de
datos lógica sobre varias máquinas físicas. Para ello, el administrador escogerá una clave que
determina cómo se distribuyen los datos en la colección. Gracias a esta clave, los datos pueden
ser divididos en rangos, y cada rango distribuido en un shard diferente. Junto con el concepto
anterior, se puede tener un sistema de alto rendimiento tolerante a fallos. La siguiente imagen
muestra el concepto de sharding o balanceo de carga en conjunto con el sistema de réplicas en
MongoDB:

35. Además, Mongo posee la capacidad de almacenar archivos gracias a GridFS. Este sistema
permite dividir el archivo en partes o chunks y almacenar la información en dos colecciones:
● Una para guardar los datos en sí.
● Otra para guardar los metadatos (por ejemplo, el archivo A son los datos 1,2,3 y 4).
Esta funcionalidad está incluida por defecto en los drivers de Mongo. También posee
modificadores de actualización atómicos, por lo que no es necesario realizar locks.
Por último, al igual que MySQL (entre otros), soporta indexación. Se pueden declarar uno o
varios índices por colección, de esta forma las consultas realizadas por estos “campos” serán
mucho más rápidas.
Otra de las cosas buenas que tiene MongoDB es que está en constante desarrollo. Eso permite
que, cada poco tiempo, aparezcan nuevas funcionalidades en el software.
Por otro lado, Mongo no posee un webserver como Cassandra donde se pueda ver qué está
pasando. Sí que posee un puerto, por defecto el 28017, que muestra una web en la que se
puede ver el estado del sistema. Pero, los que conocen MySQL, ¿no existe un software tipo
MySQL Workbench o PhpMyAdmin? Efectivamente, Mongo dispone de varias GUIs para poder
navegar por el sistema:
● http://docs.mongodb.org/ecosystem/tools/administration­interfaces/
En la URL anterior se ven prácticamente la mayoría de ellas. Hayalgunass muy buenas. Por
ejemplo, para sistemas Windows, es muy famosa la herramienta de escritorio MongoVue.

36. Si no se posee un sistema Windows, otra alternativa es por ejemplo uMongo:

37. Pero también dispone de herramientas web para su gestión. Las dos más conocidas son
PhpMoAdmin y Rockmongo. A continuación unas imágenes de cada una de ellas: