Sistemas distribuidos
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Sistemas distribuidos

on

  • 896 views

Material para el curso de Big Data

Material para el curso de Big Data

Statistics

Views

Total Views
896
Views on SlideShare
896
Embed Views
0

Actions

Likes
1
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Sistemas distribuidos Document Transcript

  • 1. CURSO SISTEMAS DISTRIBUIDOSIntroducciónTema 1 ­ HadoopTema 2 ­ HiveTema 3 ­ Sistemas NoSQLTema 4 ­ CassandraTema 5 ­ MongoDB
  • 2. IntroducciónDurante 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 ­ HadoopHadoop 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● VeracidadLa 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. ● ScoopCada 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 nodeEl 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 122 1 1 2En 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 45 4 5 22 1 4 1 2De 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í:AA BABBEn 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● touchzMuchos 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/hdfsEn 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 herramientasEn cambio, los administradores son responsables de:● Instalación● Monitorización y gestión del sistema● Tuning del sistemaBien 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 ­ HiveHive 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● EstructurasPara 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 NoSQLEn 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­redisOtro 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 ­ CassandraCassandra 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 fallosSu 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 memtableCassandra 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 ­ MongoDBMongo 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: