CURSO SISTEMAS DISTRIBUIDOS

Transcripción

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 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: 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í: 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 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 ( 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: 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 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: 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: 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: